From owner-namedroppers@ops.ietf.org Tue Jun 1 04:36:41 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3234D3A69C6; Tue, 1 Jun 2010 04:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.32 X-Spam-Level: X-Spam-Status: No, score=-101.32 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5U21Dn4aJaMH; Tue, 1 Jun 2010 04:36:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1BB0C3A69C1; Tue, 1 Jun 2010 04:36:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJPeJ-000Fkz-O4 for namedroppers-data0@psg.com; Tue, 01 Jun 2010 11:28:47 +0000 Received: from [216.239.44.51] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJPeG-000FkL-4l for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 11:28:45 +0000 Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o51BSdvW008540 for ; Tue, 1 Jun 2010 04:28:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275391722; bh=8jWOFzhn0rW5J4DExCBM9wdvD60=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=CS5VyE1guMi6ma6D5ESM+QUZvE4XKplmMvlREYSTr6Q1MHc4rIJvzx+aX73ejWjIS ATqzY36AohAMJTlBoJt4w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=fyQUUzt+TR0zaYQHrc/2FO+9Sw9TB4msggzTMu7KiP0wX6OdXPA3KD5aofkcuLVpl QNaFp2PXy1MWVYhdzk1pw== Received: from ey-out-1920.google.com (eyh3.prod.google.com [10.208.8.3]) by hpaq3.eem.corp.google.com with ESMTP id o51BSb8k009286 for ; Tue, 1 Jun 2010 04:28:38 -0700 Received: by ey-out-1920.google.com with SMTP id 3so168545eyh.50 for ; Tue, 01 Jun 2010 04:28:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.109.6 with SMTP id h6mr1132362ebp.57.1275391716865; Tue, 01 Jun 2010 04:28:36 -0700 (PDT) Received: by 10.213.14.12 with HTTP; Tue, 1 Jun 2010 04:28:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Jun 2010 12:28:36 +0100 Message-ID: Subject: Re: [dnsext] clarifications needed on draft-vandergaast-edns-client-ip-01 From: Wilmer van der Gaast To: Jim Reid Cc: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Hello Jim, everyone, On 31 May 2010 11:59, Jim Reid wrote: > The draft's definition of Intermediate Nameservers includes Recursive > Resolvers. > Section 4.1 says Intermediate Nameservers MUST pass through the > edns-client-subnet option as-is. Yet it later says a Recursive Resolver MAY > drop this option. How is this contradiction going to be fixed? > Well spotted. Yes, there is this contradiction and I found some more while thinking over the whole thing again. That's why this document is merely a draft. :-) In very specific language, this is how we intend the option to be used: * A recursive resolver (often an open resolver, or possibly a resolver run by an ISP with more peering points than DNS resolver pools) adds the option to requests. It *can* add it to all requests, but preferably it keeps track of authorities that support the option and send it only to them, to improve performance and slightly improve privacy. Another option is that the resolver admin keeps a list of edns-client-subnet-enabled authorities by him/herself. Since the option will only benefit a small number of large CDNs, this list is not likely to grow a lot. * Users who for one reason or the other don't want any of their address information to be added to requests, and know that their resolver supports edns-client-subnet, can add the option with a 0/0 address. A compliant edns-client-subnet resolver will respect this. A resolver that doesn't support edns-client-subnet will just ignore it. If a resolver somewhere in between is ignorant of the option, it gets stripped. The edns-client-subnet-enabled resolver later on will add it again - but not with the user's address, since that address is already invisible. * Not really one of the goals of the option, but: if the user knows the subsequent connection to the address received from the DNS will use a different route than the DNS request itself, the option allows for possibly better results from the CDN. * For anyone else, this option does not and will never exist. Regards, -- Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From owner-namedroppers@ops.ietf.org Tue Jun 1 05:21:13 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D877728C210; Tue, 1 Jun 2010 05:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUpCUCQ9ukdb; Tue, 1 Jun 2010 05:21:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1858728C393; Tue, 1 Jun 2010 05:20:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJQNE-000OKf-A4 for namedroppers-data0@psg.com; Tue, 01 Jun 2010 12:15:12 +0000 Received: from [209.85.160.180] (helo=mail-gy0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJQN8-000OJy-2r for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 12:15:06 +0000 Received: by gyb13 with SMTP id 13so4681720gyb.11 for ; Tue, 01 Jun 2010 05:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=40Ow2/88WL7NAoxpeMVQow7rrSPl6kMjUuSPqPuoThI=; b=VoaO1HHfqEU5nK7U7LSjRzgPsjBfNuXg9FL/6KlSYi5BG5GPX5scdDPDJEHYO8uK7c L7z3QLbUEql1+uLU3x3jqZK641yuxF7xyyfD73k0zDGD3S7SDCQeI+9GdEzh9rpQWs8P wQGvWcopQXjMj4rNbc0+uYegKznAiXv6JlhtA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TX6RvXKfuLrxMZXCvia/6z/66PJX5VhUaYPbbuJ6FfwSelUWjOlDzHmBvhBpaJDPto lU6xG5LYgZLNhZax57LKpq2ZqRowE4zIJiuT3v717L8x8wzLsJyrQd77tfHJM2kSfpdQ XKEmUTLOAlIJF9ywB38xxry6MvUU5pEHHueWw= MIME-Version: 1.0 Received: by 10.101.173.28 with SMTP id a28mr6561614anp.229.1275394505121; Tue, 01 Jun 2010 05:15:05 -0700 (PDT) Received: by 10.100.8.14 with HTTP; Tue, 1 Jun 2010 05:15:04 -0700 (PDT) Date: Tue, 1 Jun 2010 09:15:04 -0300 Message-ID: Subject: [dnsext] client-subnet - questions for the authors, and outside-the-box brainstorming From: Brian Dickson To: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001636c926aa6d20f60487f6ec6b Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001636c926aa6d20f60487f6ec6b Content-Type: text/plain; charset=ISO-8859-1 One of the issues concerning the CDN <-> "big cache operators" desire to "standardize" and extend "stupid DNS tricks", is how those changes to the protocol might better be accomplished, so as to add benefit everyone. It certainly is a worthy goal in standardizing things, but the more edge use cases get folded into the overall DNS protocol family, the more balkanized the protocol risks becoming. The open question is, are there similar means to accomplishing the same goal (pushing CDN dns "tricks" to the cache operators' farms), which have better overall design (scaling, efficiency, timeliness, neutrality WRT CDN architecture), and which may have additional benefit to the overall DNS community? The main problem, as I see it, is the need to provide "off-axis thrust" - giving answers which differ according to the location of the stub resolver, rather than the intermediate recursive resolver(s). And the main issue to be addressed, is the notion of these "resolvers" having some "special" behavior/semantics that differs from the traditional caching resolver in very substantial ways, at the DNS architectural level. Here's how I think this might better be addressed, which BTW introduces a new and different problem to solve, which I think *will* be of interest to the whole DNS community, and in fact has previously been established as an area of interest to the WG, and needs to be picked up and further developed: Rather than having the "big caches" being true caches, in the current sense of what a cache is, change the relationship between the CDN DNS servers and these "BC"s to that of master and slave, on the zones served by the masters. This changes the overall flow of information, and changes where the "dns tricks" get done, to the place where the original data needed (the real-world client IP address) is available - i.e., the BC. Timeliness is achieved by the pushing of zone updates, via notify/XFR. Stub clients get the relevant CDN-specific answers, quite possibly achieved by way of "views" on the zone data. The tools for doing this already exist, except for one area, which is where this WG already has interest: automated provisioning of slave zones, to bootstrap the operational update of secondary servers. IMHO, having a strong motivation to handle this, means if this alternate design is accepted and adopted by the CDN/BC folks, we can expect good work from them in this area - something which will be of benefit to the whole of the DNS community. And, it keeps the "stupid DNS tricks" localized to authoritative servers (even if they are operated by third parties, per se), which is where they belong, IMHO. Brian --001636c926aa6d20f60487f6ec6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One of the issues concerning the CDN <-> "big cache operators&qu= ot; desire to "standardize" and extend "stupid DNS tricks&qu= ot;, is how those changes to the protocol might better be accomplished, so = as to add benefit everyone.

It certainly is a worthy goal in standardizing things, but the more edg= e use cases get folded into the overall DNS protocol family, the more balka= nized the protocol risks becoming.

The open question is, are there s= imilar means to accomplishing the same goal (pushing CDN dns "tricks&q= uot; to the cache operators' farms), which have better overall design (= scaling, efficiency, timeliness, neutrality WRT CDN architecture), and whic= h may have additional benefit to the overall DNS community?

The main problem, as I see it, is the need to provide "off-axis th= rust" - giving answers which differ according to the location of the s= tub resolver, rather than the intermediate recursive resolver(s).

And the main issue to be addressed, is the notion of these "resolvers&= quot; having some "special" behavior/semantics that differs from = the traditional caching resolver in very substantial ways, at the DNS archi= tectural level.

Here's how I think this might better be addressed, which BTW introd= uces a new and different problem to solve, which I think *will* be of inter= est to the whole DNS community, and in fact has previously been established= as an area of interest to the WG, and needs to be picked up and further de= veloped:

Rather than having the "big caches" being true caches, in the= current sense of what a cache is, change the relationship between the CDN = DNS servers and these "BC"s to that of master and slave, on the z= ones served by the masters.

This changes the overall flow of information, and changes where the &qu= ot;dns tricks" get done, to the place where the original data needed (= the real-world client IP address) is available - i.e., the BC.

Timel= iness is achieved by the pushing of zone updates, via notify/XFR.

Stub clients get the relevant CDN-specific answers, quite possibly achi= eved by way of "views" on the zone data.

The tools for doi= ng this already exist, except for one area, which is where this WG already = has interest: automated provisioning of slave zones, to bootstrap the opera= tional update of secondary servers.

IMHO, having a strong motivation to handle this, means if this alternat= e design is accepted and adopted by the CDN/BC folks, we can expect good wo= rk from them in this area - something which will be of benefit to the whole= of the DNS community.

And, it keeps the "stupid DNS tricks" localized to authoritat= ive servers (even if they are operated by third parties, per se), which is = where they belong, IMHO.

Brian
--001636c926aa6d20f60487f6ec6b-- From owner-namedroppers@ops.ietf.org Tue Jun 1 05:48:46 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0101E3A680E; Tue, 1 Jun 2010 05:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.689 X-Spam-Level: ** X-Spam-Status: No, score=2.689 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRW6DG5+SSPG; Tue, 1 Jun 2010 05:48:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA1623A69C1; Tue, 1 Jun 2010 05:48:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJQol-0003FM-N1 for namedroppers-data0@psg.com; Tue, 01 Jun 2010 12:43:39 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJQoi-0003E3-O0 for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 12:43:37 +0000 Received: (qmail 2839 invoked from network); 1 Jun 2010 13:02:52 -0000 Received: from softbank219001188004.bbtec.net (HELO ?192.168.1.27?) (219.1.188.4) by necom830.hpcl.titech.ac.jp with SMTP; 1 Jun 2010 13:02:52 -0000 Message-ID: <4C050022.3000508@necom830.hpcl.titech.ac.jp> Date: Tue, 01 Jun 2010 21:42:10 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Brian Dickson CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] client-subnet - questions for the authors, and outside-the-box brainstorming References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Brian Dickson wrote: > The open question is, are there similar means to accomplishing > the same goal For HTTP, redirection just works. Masataka Ohta From owner-namedroppers@ops.ietf.org Tue Jun 1 05:48:56 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2633A6890; Tue, 1 Jun 2010 05:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.405 X-Spam-Level: ** X-Spam-Status: No, score=2.405 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE3D5sycjy7w; Tue, 1 Jun 2010 05:48:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 44FB13A67AD; Tue, 1 Jun 2010 05:48:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJQpz-0003Vq-TH for namedroppers-data0@psg.com; Tue, 01 Jun 2010 12:44:55 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJQpw-0003VJ-FB for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 12:44:52 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o51CinHK054884 for ; Tue, 1 Jun 2010 08:44:49 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o51Cinex054883 for namedroppers@ops.ietf.org; Tue, 1 Jun 2010 08:44:49 -0400 (EDT) (envelope-from namedroppers) Received: from [203.8.7.220] (helo=mail.syd.netstarnetworks.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJIKp-0000QX-76 for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 03:40:11 +0000 Received: from sdcexchht.netstarnetworks.com ([10.18.193.63]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id o513dXE0001437 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Tue, 1 Jun 2010 13:39:34 +1000 Received: from sdcexch.netstarnetworks.com ([fe80::252e:99c:737f:969f]) by sdcexchht.netstarnetworks.com ([fe80::a92b:b7d5:8094:5e10%10]) with mapi; Tue, 1 Jun 2010 13:39:26 +1000 From: Greg Daley To: Jim Reid , =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= CC: Wilmer van der Gaast , Nicholas Weaver , Joe Abley , Paul Vixie , IETF DNSEXT WG Date: Tue, 1 Jun 2010 13:39:25 +1000 Subject: RE: [dnsext] BGP, CDNs and Stupid DNS tricks Thread-Topic: [dnsext] BGP, CDNs and Stupid DNS tricks Thread-Index: AcsArXJrLkbxK/gxTi63HXi6s/6vWQAigtPg Message-ID: References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <94886.1275192839@nsa.vix.com> <7ABB6679-6376-409F-8444-AF067DB86449@hopcount.ca> <757D3D5B-ECF7-42D5-918E-450689BE9AA3@ICSI.Berkeley.EDU> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] A bigger issue with using BGP is that in IPv6 the Address block is by defau= lt tied to the upstream ISP (Provider Aggregatable). For systems with multiple ISPs, there will often be multiple addresses, from each ISP's address block. The destination address selection is performed at DNS level. This means that hacks will be necessary to provide preference information regarding the better ISP to reach a service on. Sincerely, Greg Daley=20 > -----Original Message----- > From: owner-namedroppers@ops.ietf.org=20 > [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Jim Reid > Sent: Monday, 31 May 2010 8:21 PM > To: Colm MacC=E1rthaigh > Cc: Wilmer van der Gaast; Nicholas Weaver; Joe Abley; Paul=20 > Vixie; IETF DNSEXT WG > Subject: [dnsext] BGP, CDNs and Stupid DNS tricks >=20 > On 30 May 2010, at 17:28, Colm MacC=E1rthaigh wrote: >=20 > > I don't think it's controversial to claim that BGP takes no=20 > account of > > endpoint latency in its decisions to resolve ties. AS path=20 > length is a > > poor proxy, and I think we all realise that the size of AS's vary =20 > > greatly. >=20 >=20 > True. And presumably if BGP addressed these concerns, CDNs=20 > could make =20 > use of that to direct punters to their closest CDN node. [For a =20 > hopefully better definition of "closest".] So since we're really =20 > talking about a routing issue why isn't this presented as a problem =20 > statement for the BGP folk to work on? It makes no sense to me why =20 > this needs to be "fixed" in the DNS. >=20 >=20 > = From owner-namedroppers@ops.ietf.org Tue Jun 1 05:48:57 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE453A67AD; Tue, 1 Jun 2010 05:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.255 X-Spam-Level: ** X-Spam-Status: No, score=2.255 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqPBQqZGg96Y; Tue, 1 Jun 2010 05:48:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 421423A69C3; Tue, 1 Jun 2010 05:48:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJQqM-0003Yk-MA for namedroppers-data0@psg.com; Tue, 01 Jun 2010 12:45:18 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJQqI-0003YF-OT for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 12:45:15 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o51CjDVI054905 for ; Tue, 1 Jun 2010 08:45:13 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o51CjD5Q054904 for namedroppers@ops.ietf.org; Tue, 1 Jun 2010 08:45:13 -0400 (EDT) (envelope-from namedroppers) Received: from [203.8.7.220] (helo=mail.syd.netstarnetworks.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJIPX-00011y-Fy for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 03:45:03 +0000 Received: from sdcexchht.netstarnetworks.com ([10.18.193.63]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id o513ilE0001659 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL); Tue, 1 Jun 2010 13:44:47 +1000 Received: from sdcexch.netstarnetworks.com ([fe80::252e:99c:737f:969f]) by sdcexchht.netstarnetworks.com ([fe80::a92b:b7d5:8094:5e10%10]) with mapi; Tue, 1 Jun 2010 13:44:40 +1000 From: Greg Daley To: Joe Abley CC: Jim Reid , =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= , Wilmer van der Gaast , Nicholas Weaver , Paul Vixie , IETF DNSEXT WG Date: Tue, 1 Jun 2010 13:44:38 +1000 Subject: RE: [dnsext] BGP, CDNs and Stupid DNS tricks Thread-Topic: [dnsext] BGP, CDNs and Stupid DNS tricks Thread-Index: AcsBPIvRAHze0uQXQd+CRCyilXJ7bwAAB9Zg Message-ID: References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <94886.1275192839@nsa.vix.com> <7ABB6679-6376-409F-8444-AF067DB86449@hopcount.ca> <757D3D5B-ECF7-42D5-918E-450689BE9AA3@ICSI.Berkeley.EDU> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Hi Joe,=20 I agree, and I've told my customers to get PI address blocks, but is there a DNS solution which makes a better class of swamp? Greg =20 > -----Original Message----- > From: Joe Abley [mailto:jabley@hopcount.ca]=20 > Sent: Tuesday, 1 June 2010 1:43 PM > To: Greg Daley > Cc: Jim Reid; Colm MacC=E1rthaigh; Wilmer van der Gaast;=20 > Nicholas Weaver; Paul Vixie; IETF DNSEXT WG > Subject: Re: [dnsext] BGP, CDNs and Stupid DNS tricks >=20 >=20 > On 2010-05-31, at 23:39, Greg Daley wrote: >=20 > > A bigger issue with using BGP is that in IPv6 the Address=20 > block is by default > > tied to the upstream ISP (Provider Aggregatable). > >=20 > > For systems with multiple ISPs, there will often be=20 > multiple addresses, > > from each ISP's address block. >=20 > This is how it was envisaged that things would work,=20 > universally, but since RIRs are now handing out PI space to=20 > end-users and there's no perfectly-aggregatable address=20 > hierarchy in practice, the cynical prediction would be that=20 > what we will get with IPv6 will be what we have with IPv4. >=20 > The swamp will look different, but it'll still be a swamp. >=20 >=20 > Joe >=20 > = From owner-namedroppers@ops.ietf.org Tue Jun 1 07:07:18 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86ECA3A683C; Tue, 1 Jun 2010 07:07:18 -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=[BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42oDIfP+jg2u; Tue, 1 Jun 2010 07:07:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B13A28B797; Tue, 1 Jun 2010 07:06:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJS25-000JXS-EO for namedroppers-data0@psg.com; Tue, 01 Jun 2010 14:01:29 +0000 Received: from [2001:470:1f05:a0f::1] (helo=tigger.mamista.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJS23-000JX2-1x for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 14:01:27 +0000 Received: by tigger.mamista.net (Postfix, from userid 1012) id C9EA2110AB4; Wed, 2 Jun 2010 00:01:26 +1000 (EST) Received: from merboo.mamista.net (merboo.mamista.net [IPv6:2001:470:1f0b:1055::1]) by tigger.mamista.net (Postfix) with ESMTP id 84088110A33 for ; Wed, 2 Jun 2010 00:01:26 +1000 (EST) Received: by merboo.mamista.net (Postfix, from userid 1000) id D863A972204; Tue, 1 Jun 2010 16:01:24 +0200 (CEST) Date: Tue, 1 Jun 2010 16:01:24 +0200 From: Martin Barry To: namedroppers@ops.ietf.org Subject: Re: [dnsext] clarifications needed on draft-vandergaast-edns-client-ip-01 Message-ID: <20100601140124.GA20770@merboo.mamista.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: $quoted_author = "Wilmer van der Gaast" ; > > * A recursive resolver (often an open resolver, or possibly a resolver > run by an ISP with more peering points than DNS resolver pools) adds > the option to requests. It *can* add it to all requests, but > preferably it keeps track of authorities that support the option and > send it only to them, to improve performance and slightly improve > privacy. > Another option is that the resolver admin keeps a list of > edns-client-subnet-enabled authorities by him/herself. Since the > option will only benefit a small number of large CDNs, this list is > not likely to grow a lot. Regardless that's not a very scalable way of handling things. An in-band method of automatically determining that "list" would be better. Perhaps send EDNS-client-ip at random intervals to authorative servers being queried and keep track of which respond to it? cheers Marty From owner-namedroppers@ops.ietf.org Tue Jun 1 07:21:08 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081A53A6A24; Tue, 1 Jun 2010 07:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.741 X-Spam-Level: X-Spam-Status: No, score=-100.741 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GddndLHVO7OC; Tue, 1 Jun 2010 07:21:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47F8B3A6A25; Tue, 1 Jun 2010 07:21:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJSGq-000NBV-1v for namedroppers-data0@psg.com; Tue, 01 Jun 2010 14:16:44 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJSGl-000NAL-HI for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 14:16:39 +0000 Received: by core3.amsl.com (Postfix, from userid 30) id 087C63A6A20; Tue, 1 Jun 2010 07:16:49 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , dnsext mailing list , dnsext chair Subject: [dnsext] Protocol Action: 'Cryptographic Algorithm Identifier Allocation for DNSSEC' to Proposed Standard Message-Id: <20100601141650.087C63A6A20@core3.amsl.com> Date: Tue, 1 Jun 2010 07:16:50 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: The IESG has approved the following document: - 'Cryptographic Algorithm Identifier Allocation for DNSSEC ' as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-alg-allocation-03.txt Technical Summary This document alters the requirements for DNSSEC algorithm identifiers from "standards action" to "RFC required". Working Group Summary The DNS Extensions Working Group reviewed the document. There was considerable discussion at the time of adoption, but almost exclusively support at the time of WGLC. Some LC comments resulted in a substantive change, which was to reserve a portion of the registry so as to avoid exhaustion. Document Quality The change suggested during WGLC ensures that the IANA registry will not be exhausted because nobody thought to revisit these procedures if the assumption about infrequent addition of algorithms turns out to be false. Personnel Andrew Sullivan (ajs@shinkuro.com) is the document shepherd. Ralph Droms (rdroms.ietf@gmail.com) is the responsible AD. RFC Editor Note Please coordinate with IANA on the best URL and method for naming the registry/sub-registry referenced in "IANA Considerations" and in Peter Saint-Andre's Comment. IANA Note Please coordinate with the RFC Editor on the best URL and method for naming the registry/sub-registry referenced in "IANA Considerations" and in Peter Saint-Andre's Comment. From owner-namedroppers@ops.ietf.org Tue Jun 1 07:21:26 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCBA3A683C; Tue, 1 Jun 2010 07:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.828 X-Spam-Level: X-Spam-Status: No, score=0.828 tagged_above=-999 required=5 tests=[AWL=1.323, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3yvzgpaN+no; Tue, 1 Jun 2010 07:21:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A73533A6A2F; Tue, 1 Jun 2010 07:21:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJSHs-000NKJ-QT for namedroppers-data0@psg.com; Tue, 01 Jun 2010 14:17:48 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJSHm-000NJU-GP for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 14:17:42 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id C7427154202C; Tue, 1 Jun 2010 15:17:39 +0100 (BST) Cc: namedroppers@ops.ietf.org Message-Id: <35C1173E-6BFB-4336-81A2-7F1D15DEB1FC@rfc1035.com> From: Jim Reid To: Martin Barry In-Reply-To: <20100601140124.GA20770@merboo.mamista.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] clarifications needed on draft-vandergaast-edns-client-ip-01 Date: Tue, 1 Jun 2010 15:17:39 +0100 References: <20100601140124.GA20770@merboo.mamista.net> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 1 Jun 2010, at 15:01, Martin Barry wrote: > Regardless that's not a very scalable way of handling things. > > An in-band method of automatically determining that "list" would be > better. > > Perhaps send EDNS-client-ip at random intervals to authorative servers > being queried and keep track of which respond to it? That's not scalable either. From owner-namedroppers@ops.ietf.org Tue Jun 1 08:01:58 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7155D3A6A29; Tue, 1 Jun 2010 08:01:58 -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=[BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB0YsalyvS+B; Tue, 1 Jun 2010 08:01:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9A3363A6A14; Tue, 1 Jun 2010 08:01:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJSto-0005EN-VP for namedroppers-data0@psg.com; Tue, 01 Jun 2010 14:57:00 +0000 Received: from [2001:470:1f05:a0f::1] (helo=tigger.mamista.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJStk-0005Dt-Ac for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 14:56:56 +0000 Received: by tigger.mamista.net (Postfix, from userid 1012) id 06020110ABC; Wed, 2 Jun 2010 00:56:56 +1000 (EST) Received: from merboo.mamista.net (merboo.mamista.net [IPv6:2001:470:1f0b:1055::1]) by tigger.mamista.net (Postfix) with ESMTP id BA1E7110AB9 for ; Wed, 2 Jun 2010 00:56:55 +1000 (EST) Received: by merboo.mamista.net (Postfix, from userid 1000) id 777CB972204; Tue, 1 Jun 2010 16:09:23 +0200 (CEST) Date: Tue, 1 Jun 2010 16:09:23 +0200 From: Martin Barry To: namedroppers@ops.ietf.org Subject: Re: [dnsext] client-subnet - questions for the authors, and outside-the-box brainstorming Message-ID: <20100601140923.GB20770@merboo.mamista.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: $quoted_author = "Brian Dickson" ; > > Rather than having the "big caches" being true caches, in the current sense > of what a cache is, change the relationship between the CDN DNS servers and > these "BC"s to that of master and slave, on the zones served by the masters. > > This changes the overall flow of information, and changes where the "dns > tricks" get done, to the place where the original data needed (the > real-world client IP address) is available - i.e., the BC. > > Timeliness is achieved by the pushing of zone updates, via notify/XFR. > > Stub clients get the relevant CDN-specific answers, quite possibly achieved > by way of "views" on the zone data. This bilateral approach: - does not scale - forces a "one size fits most" approach to the "stupid DNS trick" algorithm - would be easier as a private implementation of what EDNS-client-ip envisions cheers Marty From owner-namedroppers@ops.ietf.org Tue Jun 1 08:10:30 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18EFA3A6A3E; Tue, 1 Jun 2010 08:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.894 X-Spam-Level: X-Spam-Status: No, score=0.894 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRJxjbxWjGLM; Tue, 1 Jun 2010 08:10:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C2EDA3A6A39; Tue, 1 Jun 2010 08:10:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJT1v-0007Ld-3D for namedroppers-data0@psg.com; Tue, 01 Jun 2010 15:05:23 +0000 Received: from [74.125.82.52] (helo=mail-ww0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJT1o-0007KY-Li for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 15:05:17 +0000 Received: by wwe15 with SMTP id 15so1473862wwe.11 for ; Tue, 01 Jun 2010 08:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=OPbMjb+BDZq0yHh1+FJrTVeoI5MzK85q7aWExrx1pHw=; b=W/UDOarjGlhTVVczxit31Yd5c2NZhOaEi1pCENbfNXB8sUtdK0VA+QJVktsV+7We6t ZcEFJwZEWWWGDlcTBHMucgzbmGKOSfRE7/BQlxC7LreOPtELEpNZICRBDWnTuJa0RrIG qVHCXVFYqUA7gi0jHHTvxLXIrAe2V+caqvJYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Qa7/DudcL1Nd2BIznryJ9e6xXnTn1uqqIZI706EjIKJbkLZ1OlYd3kVmFS1gwk7+KO 1XDPkosVUCtAv1LJuzPJNTDMJUiTCe+cVCdPAcMl57keasEq3sJ9OMtGIB7CAQhw8cwz 3wF0XlFrhA3rApbK+isO02iKV9txVHZSoAHrQ= MIME-Version: 1.0 Received: by 10.227.155.79 with SMTP id r15mr6032129wbw.90.1275404715129; Tue, 01 Jun 2010 08:05:15 -0700 (PDT) Received: by 10.216.229.210 with HTTP; Tue, 1 Jun 2010 08:05:15 -0700 (PDT) In-Reply-To: <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> Date: Tue, 1 Jun 2010 11:05:15 -0400 Message-ID: Subject: Re: [dnsext] end-to-end violations in draft-vandergaast-edns-client-ip-01 From: Donald Eastlake To: IETF DNSEXT WG Content-Type: multipart/alternative; boundary=0016e659f070fd7ccf0487f94c1c Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016e659f070fd7ccf0487f94c1c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jim, Thanks for bringing up the end-to-end principle. Of course, you have its application completely backwards in this case. The rigorous application of the end-to-end principle to the domain name system would mean direct connection of ultimate clients to authoritative servers with no recursion. Under such circumstances, you would certainly have the unmodified payloads being sent back and forth and authoritative servers would always know the full IP address of their clients. However, to be practical, you need these intermediate boxes, like non-authoritative caching servers and those pesky NAT boxes, which mess up the end-to-end principle. To the extent that you can approximately measure draft-vandergaast-edns-client-ip-01 on the "end-to-end principle" axis, it certainly comes out positive, although, of course, it does not succeed in restoring the 100% rigorous end-to-end situation I described above. 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 2010/5/31 Jim Reid > On 30 May 2010, at 02:28, Colm MacC=E1rthaigh wrote: > > On Sat, May 29, 2010 at 5:13 AM, Jim Reid wrote: >> >>> Oh and it doesn't make sense for a recursive resolver to add this optio= n >>> to >>> "vanilla" inbound queries from stubs because that means it's making >>> assumptions about end client behaviour/requirements which are at best >>> misguided or unwanted and at worst downright evil. I'm fairly sure this >>> was >>> mentioned last time round. A resolving server shouldn't be tampering wi= th >>> a >>> stub's queries or the resulting responses. This violates the end-to-end >>> principle. >>> >> >> Section 4.1 of RFC2671 makes plain that there is no end-to-end >> principle for EDNS options. >> > > In that case, why is the draft forcing Intermediate Resolvers to pass on > as-is any edns-client-subnet options on inbound queries? > > BTW, this draft says "an Intermediate Resolver... MAY add an > edns-client-subnet option" to a query that doesn't already have one. > > IMO the (covert) insertion or removal of an edns-client-subnet is a > violation of the end to end principle. To repeat what I said earlier, a > resolving server should not be tampering with the contents of a stub's qu= ery > or the resulting response. This should be common sense. > --0016e659f070fd7ccf0487f94c1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jim,

Thanks for bringing up the end-to-end principle.= Of course, you have its application completely backwards in this case.

The rigorous application of the end-to-end principle = to the domain name system would mean direct connection of ultimate clients = to authoritative servers with no recursion. Under such circumstances, you w= ould certainly have the unmodified payloads being sent back and forth and a= uthoritative servers would always know the full IP address of their clients= .

However, to be practical, you need these intermediate b= oxes, like non-authoritative caching servers and those pesky NAT boxes, whi= ch mess up the end-to-end principle. To the extent that you can approximate= ly measure=A0draft-vandergaast-edns-client-ip-01 on the "end-to-end pr= inciple" axis, it certainly comes out positive, although, of course, i= t does not succeed in restoring the 100% rigorous end-to-end situation I de= scribed above.

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 =A0 +1-508-333-2270 (cell)
155 Beaver Stree= t
Milford, MA 01757 USA
d3e3e3@= gmail.com

2010/5/31 Jim Reid <jim@rfc1035.com>
On 30 May 2010, at 02:28, Colm MacC=E1rthaigh wrote:

On Sat, May 29, 2010 at 5:13 AM, Jim Reid <jim@rfc1035.com> wrote:
Oh and it doesn't make sense for a recursive resolver to add this optio= n to
"vanilla" inbound queries from stubs because that means it's = making
assumptions about end client behaviour/requirements which are at best
misguided or unwanted and at worst downright evil. I'm fairly sure this= was
mentioned last time round. A resolving server shouldn't be tampering wi= th a
stub's queries or the resulting responses. This violates the end-to-end=
principle.

Section 4.1 of RFC2671 makes plain that there is no end-to-end
principle for EDNS options.

In that case, why is the draft forcing Intermediate Resolvers to pass on as= -is any edns-client-subnet options on inbound queries?

BTW, this draft says "an Intermediate Resolver... MAY add an edns-clie= nt-subnet option" to a query that doesn't already have one.

IMO the (covert) insertion or removal of an edns-client-subnet is a violati= on of the end to end principle. To repeat what I said earlier, a resolving = server should not be tampering with the contents of a stub's query or t= he resulting response. This should be common sense.

--0016e659f070fd7ccf0487f94c1c-- From owner-namedroppers@ops.ietf.org Tue Jun 1 08:13:41 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581333A6A3A; Tue, 1 Jun 2010 08:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=-1.611, BAYES_50=0.001, FH_RELAY_NODNS=1.451, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_HEXOCTDWORD=2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOZC-0BIQ552; Tue, 1 Jun 2010 08:13:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AEF4E3A6A2F; Tue, 1 Jun 2010 08:13:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJT60-00081M-HX for namedroppers-data0@psg.com; Tue, 01 Jun 2010 15:09:36 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJT5r-0007zm-W0 for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 15:09:28 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o51EkfPQ000350; Tue, 1 Jun 2010 07:46:42 -0700 (PDT) References: <4C050022.3000508@necom830.hpcl.titech.ac.jp> In-Reply-To: <4C050022.3000508@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <9519475D-FF8B-4820-8E9E-A06792E25535@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , Brian Dickson , namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: [dnsext] client-subnet - questions for the authors, and outside-the-box brainstorming Date: Tue, 1 Jun 2010 07:46:41 -0700 To: Masataka Ohta X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 1, 2010, at 5:42 AM, Masataka Ohta wrote: > Brian Dickson wrote: >=20 >> The open question is, are there similar means to accomplishing >> the same goal >=20 > For HTTP, redirection just works. For HTTP, redirection JUST DOES NOT WORK FOR THIS, for two very = important reasons [1]: 1: HTTP redirection adds 3+ RTTs of additional latency, between the TCP = handshake and the 302 redirect and the new DNS lookup needed for the = customized name. If your goal is to shave a second off of page load, = this eliminates the benefit. 2: HTTP redirection can only provide a different URL, which is = unacceptable for many web site providers. You don't want to see http://a351.www.mysite.com/URL or http://273.51.152.23/URL presented to the user, which is what must occur for HTTP redirect, since = there is no notion of "the IP for servicing the URL should be Y but the = URL should not be changed", and you don't want to redirect in-page = sub-pieces because that is much slower and breaks the notion of relative = URLs for components. [2] [1] Yes, I'm feeling very repetitive here.=20 [2] We actually DO leak host-specific URLs, but only very reluctantly = since we wanted to be VERY careful on same origin policy for Netalyzr, = which required each back end node to have a separate DNS name. I wish = people did NOT see "n3.netalyzr..." etc, but we did it for a reason. From owner-namedroppers@ops.ietf.org Tue Jun 1 08:34:57 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49EE03A6A31; Tue, 1 Jun 2010 08:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.907 X-Spam-Level: * X-Spam-Status: No, score=1.907 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NtNRK0MvJq9; Tue, 1 Jun 2010 08:34:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 54B503A6A3B; Tue, 1 Jun 2010 08:34:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJTPv-000Bmd-Jd for namedroppers-data0@psg.com; Tue, 01 Jun 2010 15:30:11 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJTPp-000Bku-Ga for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 15:30:05 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 9D044154202C; Tue, 1 Jun 2010 16:30:00 +0100 (BST) Cc: IETF DNSEXT WG Message-Id: From: Jim Reid To: Donald Eastlake In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] end-to-end violations in draft-vandergaast-edns-client-ip-01 Date: Tue, 1 Jun 2010 16:30:00 +0100 References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 1 Jun 2010, at 16:05, Donald Eastlake wrote: > Thanks for bringing up the end-to-end principle. Of course, you have > its > application completely backwards in this case. That may be true Donald. But end-to-end backwards is still end-to- end. :-) > However, to be practical, you need these intermediate boxes, like > non-authoritative caching servers and those pesky NAT boxes, which > mess up > the end-to-end principle. Indeed. However even though we accept these middleboxes as a necessary and probably unavoidable wart on a pure end-to-end model, this does not mean they have a free hand to tamper with DNS queries and replies. [Like secretly adding or removing EDNS options as this draft proposes.] And yes, I know some middleboxes already do stupid/evil things to DNS traffic. IMO, that's not an excuse to encourage more of that sort of behaviour. Or standardise it. From owner-namedroppers@ops.ietf.org Tue Jun 1 08:46:02 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4156928C17E; Tue, 1 Jun 2010 08:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gZ922gUzmBO; Tue, 1 Jun 2010 08:45:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE19A28C17D; Tue, 1 Jun 2010 08:45:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJTb0-000EHG-Nu for namedroppers-data0@psg.com; Tue, 01 Jun 2010 15:41:38 +0000 Received: from [74.125.83.52] (helo=mail-gw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJTas-000ECK-Gw for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 15:41:30 +0000 Received: by gwaa18 with SMTP id a18so155434gwa.11 for ; Tue, 01 Jun 2010 08:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=coCXW/VNdmn+Dged1MJXksDsCub36DQD9/2Wf1a3NfI=; b=JTj/9Y1hnFvcLInHkFJ+bC65yCwfW2dlcPCdxufwkjy25IfK95k54LIQA24g0LZWDV 2FkCJ7QbeX+3qlMJV09a+E3k3faYZUCkv/EfSxBU+JVUpEN9HPQeZqL+qL/SzTJw7h0U Nq34+BBbqpp1SuPm/Vnn13k9veXJSN/rK1wfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GFfs7xXcWUxNRSbyG65V54BleHjTsl977Z1tSm/NxLQe3eX43Pe+1D7aBuUemUIYIn Vq46ezV6zlErMzzDGlZZRG+LxzZOvwEQX7NxmJf5SjpwIb6ZQo4Iihg4TXAR5k1FrI8E 72Eo/gLvoTUZasDPifz8+N/56yhB2ilvSNfM4= MIME-Version: 1.0 Received: by 10.101.178.8 with SMTP id f8mr6792308anp.213.1275406889436; Tue, 01 Jun 2010 08:41:29 -0700 (PDT) Received: by 10.100.8.14 with HTTP; Tue, 1 Jun 2010 08:41:29 -0700 (PDT) In-Reply-To: <20100601140923.GB20770@merboo.mamista.net> References: <20100601140923.GB20770@merboo.mamista.net> Date: Tue, 1 Jun 2010 12:41:29 -0300 Message-ID: Subject: Re: [dnsext] client-subnet - questions for the authors, and outside-the-box brainstorming From: Brian Dickson To: Martin Barry Cc: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001636c924c296c6640487f9cee2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001636c924c296c6640487f9cee2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 1, 2010 at 11:09 AM, Martin Barry wrote: > $quoted_author = "Brian Dickson" ; > > > > Rather than having the "big caches" being true caches, in the current > sense > > of what a cache is, change the relationship between the CDN DNS servers > and > > these "BC"s to that of master and slave, on the zones served by the > masters. > > > > This changes the overall flow of information, and changes where the "dns > > tricks" get done, to the place where the original data needed (the > > real-world client IP address) is available - i.e., the BC. > > > > Timeliness is achieved by the pushing of zone updates, via notify/XFR. > > > > Stub clients get the relevant CDN-specific answers, quite possibly > achieved > > by way of "views" on the zone data. > > This bilateral approach: > It's only bilateral when implemented trivially. Nothing in the overall design (master/slave) differs from current use of master/slave, i.e. non-trivial graphs among or between parties. E.g. CDN operator has hidden master(s), with numerous slaves which are public masters. Large cache operators subscribe to multiple CDN operator zones. Smaller parties can potentially get "feeds" of this DNS data aggregated, from large cache operators. The basic model looks quite a bit like BGP. This is all control plane data. Routes and "stupid DNS trick data" look quite a lot a like, when you look at them from the right angle (preferably at a bar BOF). :-) > - does not scale > ... yet. I.e. it needs the provisioning pieces to scale, which was what my post was about, that the provisioning pieces are useful not just to this use case, but to numerous others. > - forces a "one size fits most" approach to the "stupid DNS trick" > algorithm > I prefer "permits" or "enables" rather than forces. This is all opt-in. > - would be easier as a private implementation of what EDNS-client-ip > envisions > > No arguments there.... :-) > cheers > Marty > > Brian --001636c924c296c6640487f9cee2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jun 1, 2010 at 11:09 AM, Martin Barry <marty@supine.com> wrote:
$quoted_author =3D "Brian Dickson" ;
>
> Rather than having the "big caches" being true caches, in th= e current sense
> of what a cache is, change the relationship between the CDN DNS server= s and
> these "BC"s to that of master and slave, on the zones served= by the masters.
>
> This changes the overall flow of information, and changes where the &q= uot;dns
> tricks" get done, to the place where the original data needed (th= e
> real-world client IP address) is available - i.e., the BC.
>
> Timeliness is achieved by the pushing of zone updates, via notify/XFR.=
>
> Stub clients get the relevant CDN-specific answers, quite possibly ach= ieved
> by way of "views" on the zone data.

This bilateral approach:

It's only bilat= eral when implemented trivially. Nothing in the overall design (master/slav= e) differs from current use of master/slave, i.e. non-trivial graphs among = or between parties.

E.g. CDN operator has hidden master(s), with numerous slaves which are = public masters. Large cache operators subscribe to multiple CDN operator zo= nes. Smaller parties can potentially get "feeds" of this DNS data= aggregated, from large cache operators.

The basic model looks quite a bit like BGP. This is all control plane d= ata. Routes and "stupid DNS trick data" look quite a lot a like, = when you look at them from the right angle (preferably at a bar BOF). :-) =A0
- does not scale

... yet. I.e. it needs the provis= ioning pieces to scale, which was what my post was about, that the provisio= ning pieces are useful not just to this use case, but to numerous others. =A0
- forces a "one size fits most" approach to the "stupid DNS = trick" algorithm

I prefer "permits"= or "enables" rather than forces. This is all opt-in.
=A0
- would be easier as a private implementation of what EDNS-client-ip
=A0envisions


No arguments there.... :-)
=A0
cheers
Marty


Brian
--001636c924c296c6640487f9cee2-- From owner-namedroppers@ops.ietf.org Tue Jun 1 08:51:51 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D9C28C181; Tue, 1 Jun 2010 08:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.035 X-Spam-Level: *** X-Spam-Status: No, score=3.035 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T1-gHaW7fRX; Tue, 1 Jun 2010 08:51:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B31B28C12C; Tue, 1 Jun 2010 08:51:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJThL-000Fri-Kk for namedroppers-data0@psg.com; Tue, 01 Jun 2010 15:48:11 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJThG-000Fpk-6Z for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 15:48:06 +0000 Received: by fxm19 with SMTP id 19so4700894fxm.11 for ; Tue, 01 Jun 2010 08:48:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.189.12 with SMTP id r12mr508371hbh.129.1275407283779; Tue, 01 Jun 2010 08:48:03 -0700 (PDT) Received: by 10.239.174.12 with HTTP; Tue, 1 Jun 2010 08:48:03 -0700 (PDT) In-Reply-To: References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> Date: Tue, 1 Jun 2010 08:48:03 -0700 Message-ID: Subject: Re: [dnsext] end-to-end violations in draft-vandergaast-edns-client-ip-01 From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Jim Reid Cc: Donald Eastlake , IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Jun 1, 2010 at 8:30 AM, Jim Reid wrote: > Indeed. However even though we accept these middleboxes as a necessary and > probably unavoidable wart on a pure end-to-end model, this does not mean > they have a free hand to tamper with DNS queries and replies. [Like secretly > adding or removing EDNS options as this draft proposes.] I think your quarrel is with EDNS itself - that is what the EDNS spec is designed for. Proposing changes to the EDNS spec itself might remedy your concern - but I think that's orthogonal to the details of any particular option :) -- Colm From owner-namedroppers@ops.ietf.org Tue Jun 1 09:03:10 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C9F28C0E9; Tue, 1 Jun 2010 09:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.801 X-Spam-Level: *** X-Spam-Status: No, score=3.801 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPIGHixPtJ2S; Tue, 1 Jun 2010 09:03:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4B593A69DE; Tue, 1 Jun 2010 09:03:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJTrg-000IE4-PS for namedroppers-data0@psg.com; Tue, 01 Jun 2010 15:58:52 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJTrb-000IDK-9d for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 15:58:48 +0000 Received: from [10.71.0.51] (unknown [69.38.231.138]) by mail.avalus.com (Postfix) with ESMTPSA id 20551C56905; Tue, 1 Jun 2010 16:58:44 +0100 (BST) Date: Tue, 01 Jun 2010 11:58:43 -0400 From: Alex Bligh Reply-To: Alex Bligh To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) Message-ID: <421400056AC3A68D057ED565@nimrod.local> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 31 May 2010 15:37:48 -0700 Colm MacC=C3=A1rthaigh =20 wrote: > The engineering problem; > Open Resolvers and CDN DNS tricks do not work well together - because > of the much broader client base of open resolvers, the source IP of > the query towards the CDN has very poor network locality. Hmmm... Perhaps we are looking at this the wrong way. My take on your argument is: a) there are a substantial number of CDN operators who already use information outside the q-tuple to help them look stuff up - in this case source IP address, though no doubt they may mangle that with BGP or whatever first. Various folks disapprove of this ("stupid DNS tricks" or whatever), but presumably disapprove less when it's not affecting them and/or the DNS protocol. b) there are a substantial number of "open resolvers" (or more precisely caching resolvers topologically distant from the stub resolver - whether they are open or not is irrelevant) which break the model used in (a) as they do not pass on information that is outside the q-tuple; indeed they only pass on information inside the q-tuple because that's precisely how their caches are keyed. A smaller number of people (including me, incidentally) seem to think this model is bad (or at least suboptimal in most cases), and that the correct model is to push the caching nameserver as close to the client as possible. Now, there are all sorts of ugly hacks possible for the likes of OpenDNS to achieve something like the result they want already. To pick an obvious one, they could arrange for their servers to be spread over the the internet's topology using anycast IP for the resolving addresses, but unique IPs for outbound queries. That way the CDNs would see queries from different places within the topology in different IPs. To the extent anycast can be made to approximate topological proximity, this would work. And it's not hard to see how this could be extended so as to not require lots of physical servers. But I hear off-stage mutterings of "those who live by stupid DNS tricks shall die by stupid DNS tricks". However, let's assume this is just one instance of a requirement to key a look up on more than the standard q-tuple. Let's also assume that criteria for any protocol fixes are: 1. It doesn't require a protocol change for anyone other than those in groups (a) or (b) above 2. It doesn't materially increase load on either clients or servers for anyone other than those in groups (a) or (b) above, or at least not by any more than fixing the problem another way (e.g. my straw man proposal above). 3. It is written in a generic way, to maximise usefulness for anyone else who might want to do this. So, what about an EDNS option called 'edns-query-hint' or similar. This contains a list of 2-tuples which are 'things the upstream server might like to consider when doing a DNS lookup'. So, for instance this might be ((CLIENT_IPV4_SUBNET, 192.0.2.0/24), (CLIENT_ASN, 7777)) or whatever. The authoritative server, if it understands the EDNS option at all, responds with those key types it is interested in in the reply packet (so in the example above, if it never looked up on anything bar CLIENT_IPV4_SUBNET, it returns that). The caching resolver MUST then negatively cache these, so that it doesn't send further queries at all (in the case of an EDNS option not understood) or an option other than one the upstream resolver understands for (say) an hour. This means the maximum additional load on any authoritative nameserver is packet elongated by a few tens of bytes per hour per caching resolver. If an authoritative server replies that it understands a particular option type, the caching server MUST use this as an additional key to the query in its cache (i.e. it can't just reply with TTL as zero); i.e. it must perform as though all cache entries other than those returned with that key type were not present, or in other words act as if it were multiple separate caching resolvers. The option is point to point. We treat privacy as a higher layer problem, i.e. we say "Here's what information OpenDNS passes on to an upstream provider - if you don't like this, don't sign up". If a caching provider wants to do have some form of transitive option, that's fine, but it's done hop by hop, and in general I think it's a bad idea to require any client code change at all. I believe this satisfies my slightly arbitrarily chosen design criteria, in that it puts all the load on the CDNs and the open servers using it. It may be a nasty hack, but it's a standardised nasty hack which has very little collateral damage. --=20 Alex Bligh From owner-namedroppers@ops.ietf.org Tue Jun 1 09:24:41 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660E928C188; Tue, 1 Jun 2010 09:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.273 X-Spam-Level: X-Spam-Status: No, score=-97.273 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCRXH3xI8zCP; Tue, 1 Jun 2010 09:24:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F60028C0FD; Tue, 1 Jun 2010 09:24:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJUAT-000MV9-2u for namedroppers-data0@psg.com; Tue, 01 Jun 2010 16:18:17 +0000 Received: from [74.125.121.35] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJUAP-000MUI-Qe for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 16:18:14 +0000 Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o51GI9FV006932 for ; Tue, 1 Jun 2010 09:18:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275409090; bh=mjDQZ9sBkQkDY0FYd+/zqdqWHrA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=LE3ulB42CdCaV5E/+Yq196dS4lE9dGsSmWJABr5h2NPPR4zjRujtKP/EHETc+1Hhg xoVkIGtBN9t2hPJFHJQjA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=EHSeJ0bqGmiIaj69LXbcZ/PwTDJAPw//e8au2sYtcHtnx8KtsxFIGZUIs7xEcNccy e4D6LaMXpxgZP8+Ilu5bA== Received: from ewy25 (ewy25.prod.google.com [10.241.103.25]) by kpbe20.cbf.corp.google.com with ESMTP id o51GI75d026896 for ; Tue, 1 Jun 2010 09:18:08 -0700 Received: by ewy25 with SMTP id 25so1216524ewy.15 for ; Tue, 01 Jun 2010 09:18:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.14.11 with SMTP id e11mr3710109eba.44.1275409086172; Tue, 01 Jun 2010 09:18:06 -0700 (PDT) Received: by 10.213.14.12 with HTTP; Tue, 1 Jun 2010 09:18:05 -0700 (PDT) In-Reply-To: <20100601140124.GA20770@merboo.mamista.net> References: <20100601140124.GA20770@merboo.mamista.net> Date: Tue, 1 Jun 2010 17:18:05 +0100 Message-ID: Subject: Re: [dnsext] clarifications needed on draft-vandergaast-edns-client-ip-01 From: Wilmer van der Gaast To: Martin Barry Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 1 June 2010 15:01, Martin Barry wrote: >> * A recursive resolver (often an open resolver, or possibly a resolver >> run by an ISP with more peering points than DNS resolver pools) adds >> the option to requests. It *can* add it to all requests, but >> preferably it keeps track of authorities that support the option and >> send it only to them, to improve performance and slightly improve >> privacy. >> Another option is that the resolver admin keeps a list of >> edns-client-subnet-enabled authorities by him/herself. Since the >> option will only benefit a small number of large CDNs, this list is >> not likely to grow a lot. > Regardless that's not a very scalable way of handling things. > > An in-band method of automatically determining that "list" would be better. > > Perhaps send EDNS-client-ip at random intervals to authorative servers > being queried and keep track of which respond to it? > Yes, that's what I meant with "keeps track of authorities that support the option". The option could be included once a day, and if the respone doesn't have one, remember for another day or so that it's not supported. IMHO this is up the implementor though, and should only be mentioned in a recommendations section. Regards, -- Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From owner-namedroppers@ops.ietf.org Tue Jun 1 09:41:02 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B724128C1B5; Tue, 1 Jun 2010 09:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.034 X-Spam-Level: *** X-Spam-Status: No, score=3.034 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouSr14AdHiBr; Tue, 1 Jun 2010 09:40:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D110428C1B1; Tue, 1 Jun 2010 09:40:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJUQs-000Q0o-Jn for namedroppers-data0@psg.com; Tue, 01 Jun 2010 16:35:14 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJUQo-000Pz8-F4 for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 16:35:10 +0000 Received: by fxm19 with SMTP id 19so4764208fxm.11 for ; Tue, 01 Jun 2010 09:35:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.161.132 with SMTP id h4mr506632hbd.55.1275410108543; Tue, 01 Jun 2010 09:35:08 -0700 (PDT) Received: by 10.239.174.12 with HTTP; Tue, 1 Jun 2010 09:35:08 -0700 (PDT) In-Reply-To: <421400056AC3A68D057ED565@nimrod.local> References: <421400056AC3A68D057ED565@nimrod.local> Date: Tue, 1 Jun 2010 09:35:08 -0700 Message-ID: Subject: Re: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Alex Bligh Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: 2010/6/1 Alex Bligh :> > So, what about an EDNS option called 'edns-query-hint' or similar. > This contains a list of 2-tuples which are 'things the upstream > server might like to consider when doing a DNS lookup'. So, > for instance this might be > =A0 ((CLIENT_IPV4_SUBNET, 192.0.2.0/24), > =A0 =A0(CLIENT_ASN, 7777)) > or whatever. I think it would take more work to make such a system as the proposal that's here already. IP subnets would need all of the CIDR/VLSM cacheability hints, and other fields would need other heuristics. Potentially the server might have to implement http content-negotiation "Vary:" style semantics in its caching. Those are tractable though, and if someone wrote such a draft with proper consideration, I'd be in favour of it too. --=20 Colm From owner-namedroppers@ops.ietf.org Tue Jun 1 09:59:02 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1EDB28C1BD; Tue, 1 Jun 2010 09:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.801 X-Spam-Level: *** X-Spam-Status: No, score=3.801 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y65GeeEA+0wE; Tue, 1 Jun 2010 09:59:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B509A28C1D3; Tue, 1 Jun 2010 09:58:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJUie-0003uJ-1C for namedroppers-data0@psg.com; Tue, 01 Jun 2010 16:53:36 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJUiW-0003t4-V6 for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 16:53:29 +0000 Received: from [10.71.0.51] (unknown [69.38.231.138]) by mail.avalus.com (Postfix) with ESMTPSA id EAAE3C56901; Tue, 1 Jun 2010 17:53:26 +0100 (BST) Date: Tue, 01 Jun 2010 12:53:20 -0400 From: Alex Bligh Reply-To: Alex Bligh To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) Message-ID: <8D6F3C331BDC4FAFF237C0BA@nimrod.local> In-Reply-To: References: <421400056AC3A68D057ED565@nimrod.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Colm, --On 1 June 2010 09:35:08 -0700 Colm MacC=C3=A1rthaigh =20 wrote: > 2010/6/1 Alex Bligh :> >> So, what about an EDNS option called 'edns-query-hint' or similar. >> This contains a list of 2-tuples which are 'things the upstream >> server might like to consider when doing a DNS lookup'. So, >> for instance this might be >> =C2=A0 ((CLIENT_IPV4_SUBNET, 192.0.2.0/24), >> =C2=A0 =C2=A0(CLIENT_ASN, 7777)) >> or whatever. > > I think it would take more work to make such a system as the proposal > that's here already. IP subnets would need all of the CIDR/VLSM > cacheability hints, and other fields would need other heuristics. No they wouldn't. The caching resolver *could* supply CIDR BGP reachability hints, or it *could* always truncate at /24, or it *could* always pass on the /32, or it *could* pass on nothing. It's a matter of local policy. Equally it could put in the AS number of not. It depends how helpful it wants to be to the CDN, and how concerned it is (on its user's behalf) about IP address privacy. So in the above example, the caching resolver could have chosen to pass =C2=A0 ((CLIENT_IPV4_SUBNET, 192.0.0.0/17), ) or =C2=A0 ((CLIENT_IPV4_SUBNET, 192.0.2.7/32), ) or some combination of those and the ASN or whatever. The substantial extra work that needs to be done is rewriting the cache in the caching nameservers to filter by the additional tags it supplies. I would argue this needs to be done anyway to do proper caching in your draft. > Potentially the server might have to implement http > content-negotiation "Vary:" style semantics in its caching. Those are > tractable though, and if someone wrote such a draft with proper > consideration, I'd be in favour of it too. Not sure that's necessary. --=20 Alex Bligh From owner-namedroppers@ops.ietf.org Tue Jun 1 10:16:30 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581FD3A699C; Tue, 1 Jun 2010 10:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.603 X-Spam-Level: X-Spam-Status: No, score=-101.603 tagged_above=-999 required=5 tests=[AWL=0.996, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3lqAFz2IfFA; Tue, 1 Jun 2010 10:16:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2075828C184; Tue, 1 Jun 2010 10:16:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJUyv-0007gJ-6S for namedroppers-data0@psg.com; Tue, 01 Jun 2010 17:10:25 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJUym-0007VM-TO for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 17:10:18 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o51H6U6H004806; Tue, 1 Jun 2010 17:06:45 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o51H6AcV004804; Tue, 1 Jun 2010 17:06:10 GMT Date: Tue, 1 Jun 2010 17:06:05 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews Cc: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS cache design spec Message-ID: <20100601170605.GB4379@vacation.karoshi.com.> References: <201005312334.o4VNY3lN099586@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005312334.o4VNY3lN099586@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Jun 01, 2010 at 09:34:03AM +1000, Mark Andrews wrote: > > Part of the problem is that caches now go from 1 RRset per name to > 1 RRset per client. That is a fundamental change in design > constraints. is there an IETF RFC on DNS cache design? > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Jun 1 10:46:26 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B393A699C; Tue, 1 Jun 2010 10:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yTg9cqmX1UA; Tue, 1 Jun 2010 10:46:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F4C93A67A4; Tue, 1 Jun 2010 10:46:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJVSi-000DgN-7O for namedroppers-data0@psg.com; Tue, 01 Jun 2010 17:41:12 +0000 Received: from [140.186.190.103] (helo=haybaler.sackheads.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJVSW-000Ddp-Qr for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 17:41:01 +0000 Received: from localhost (localhost.sackheads.org [127.0.0.1]) by haybaler.sackheads.org (Postfix) with ESMTP id CFA5628A63; Tue, 1 Jun 2010 13:40:57 -0400 (EDT) Authentication-Results: haybaler.sackheads.org; domainkeys=pass (testing) header.from=john@sackheads.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1275414057; bh=59zxsfhOJ+CcXCj9ciJc83IGAyXYoVIJvozxyhiVsgw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=bNs60BWjXlQW9Ns5M0JuZHQx7IcuFDwbZjN4zJy3A2150hL9UHoMErzgN+/dDndyd Olg+qg5AwVhnILKDa+S1e22Sf6AdY7+74PHu0CL0Ttxls9j9K9HFxYwGUv58sEo1fy 3+MLlqES5+Z/NHI+3MiO9w8mEHXh1eNCtQhJS/Mg= Received: from haybaler.sackheads.org ([127.0.0.1]) by localhost (haybaler.sackheads.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmNMC6BnB8pc; Tue, 1 Jun 2010 13:40:57 -0400 (EDT) Received: by haybaler.sackheads.org (Postfix, from userid 65534) id 0EEFA2893E; Tue, 1 Jun 2010 13:40:57 -0400 (EDT) Received: from usma1mc-0f6642.8cc-neteng.corp.akamai.com (unknown [72.246.0.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: john@sackheads.org) by haybaler.sackheads.org (Postfix) with ESMTP id B943F28426; Tue, 1 Jun 2010 13:40:56 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=haybaler; d=sackheads.org; c=nofws; q=dns; h=dkim-signature:subject:mime-version:content-type:from: in-reply-to:date:cc:content-transfer-encoding:message-id:references:to:x-mailer; b=Z3DiZ4I63hxLThOK0FGf/SIbpHscQpF1tQGGdM2pr5P8egEKKARdUn0alUHFoFSZj p6ottB5LBkkwOlvCQEGloTuf/bDiSOr+DoE861V2+4gKW/dGiT2hsBBfd+TxctMsYvY a2oJvE83/FSAHjA6CbnSdfQGizEy6cwxNykgYS4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1275414056; bh=59zxsfhOJ+CcXCj9ciJc83IGAyXYoVIJvozxyhiVsgw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=d1BCCoQ6slD2XlgiIOnzFcjkDdfrUH0MnTNOi3mEqSWUouHr+/9aYhxwqhy0EYuQB nRp+6wUWsJwAYwpJOH9VNnvyLfMDfrQyqY9uxR3alRygRi3J4Rm3SVDPepfVe8ZMfz 7VkrjXMDwS+cWVmtnZy2LGztChXmHfw9yi5HlmQ0= Subject: Re: [dnsext] Personal position on adopting the client-subnet option Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: John Payne In-Reply-To: <201006010434.o514YoOg004549@drugs.dv.isc.org> Date: Tue, 1 Jun 2010 13:40:55 -0400 Cc: =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= , "namedroppers@ops.ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <201005312348.o4VNmKlT099824@drugs.dv.isc.org> <201006010434.o514YoOg004549@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 1, 2010, at 12:34 AM, Mark Andrews wrote: >=20 > In message , John = Payne wri > tes: >> On May 31, 2010, at 7:48 PM, Mark Andrews wrote: >>=20 >>>=20 >>> In message =3D >> , = =3D3D?IS >>> O-8859-1?Q?Colm_MacC=3D3DE1rthaigh?=3D3D writes: >>>> [1] "The mission of the IETF is make the Internet work better by >>>> producing high quality, relevant technical documents that influence >>>> the way people design, use, and manage the Internet" - IETF = mission >>>> statement. >>>=20 >>> This is not a zero cost solution. There are down sides to deploying >>> this technology. It will require bigger more complicated caches to >>> support the same number of clients. >>=20 >> When does the IETF limit itself to zero cost solutions? >=20 > It was being presented as all benefit when it has downsides. Those > downsides need to be taken into consideration. Point taken, but the downsides are all at the implementations that are = authoring/supporting this draft, no? From owner-namedroppers@ops.ietf.org Tue Jun 1 10:47:05 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B503A69DE; Tue, 1 Jun 2010 10:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.065 X-Spam-Level: X-Spam-Status: No, score=-100.065 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_50=0.001, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMQP0iWBk0g0; Tue, 1 Jun 2010 10:47:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A53DE3A699C; Tue, 1 Jun 2010 10:47:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJVUQ-000E6T-D1 for namedroppers-data0@psg.com; Tue, 01 Jun 2010 17:42:58 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJVUK-000DtZ-Pu for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 17:42:52 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o51HdK6H005005; Tue, 1 Jun 2010 17:39:35 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o51HcWQS005002; Tue, 1 Jun 2010 17:38:32 GMT Date: Tue, 1 Jun 2010 17:38:27 +0000 From: bmanning@vacation.karoshi.com To: John Payne Cc: Bruce Campbell , "sthaug@nethelp.no" , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] latency Message-ID: <20100601173827.GC4379@vacation.karoshi.com.> References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Jun 01, 2010 at 12:12:03AM -0400, John Payne wrote: > > > On May 31, 2010, at 11:52 AM, Bruce Campbell wrote: > > > Most web browsers seem to look up domain names en-mass and incur max(latency difference) or latency difference * number of concurrent queries, rather than one-by-one and thus latency difference * N. > > The latency is not in the name lookups.... > > > As a corporate admin, I'd hate to have details of my internal infrastructure walking out along with the DNS queries, and I fear that this will trigger more active inspection and modification of DNS packets at the egress of such networks, with accompanying poorly-implemented breakage. > > Then you wouldn't enable the option, and you wouldn't enter into an agreement with any auth server operator to use that option if you did accidentally enable it. are you suggesting this option is enabled on a per server basis (e.g. pairwise betwn servers?) or will it also have zone granularity as well? --bill From owner-namedroppers@ops.ietf.org Tue Jun 1 10:48:25 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4143A6A0E; Tue, 1 Jun 2010 10:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.033 X-Spam-Level: *** X-Spam-Status: No, score=3.033 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5GBF2F0rnyw; Tue, 1 Jun 2010 10:48:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA1CD3A699C; Tue, 1 Jun 2010 10:48:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJVVy-000ELl-9i for namedroppers-data0@psg.com; Tue, 01 Jun 2010 17:44:34 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJVVp-000EJj-GR for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 17:44:25 +0000 Received: by fxm19 with SMTP id 19so4850342fxm.11 for ; Tue, 01 Jun 2010 10:44:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.184.75 with SMTP id x11mr472555hbg.131.1275414261655; Tue, 01 Jun 2010 10:44:21 -0700 (PDT) Received: by 10.239.174.12 with HTTP; Tue, 1 Jun 2010 10:44:21 -0700 (PDT) In-Reply-To: <8D6F3C331BDC4FAFF237C0BA@nimrod.local> References: <421400056AC3A68D057ED565@nimrod.local> <8D6F3C331BDC4FAFF237C0BA@nimrod.local> Date: Tue, 1 Jun 2010 10:44:21 -0700 Message-ID: Subject: Re: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Alex Bligh Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: 2010/6/1 Alex Bligh : >> I think it would take more work to make such a system as the proposal >> that's here already. IP subnets would need all of the CIDR/VLSM >> cacheability hints, and other fields would need other heuristics. > > No they wouldn't. The caching resolver *could* supply CIDR BGP > reachability hints, or it *could* always truncate at /24, or it > *could* always pass on the /32, or it *could* pass on nothing. I think you may be missing some of the detail of the proposed option before us. The option allows for the authoritative server to reply with cacheability hints for subnets that are greater or larger in size than the one supplied in the query. That improves caching overall - and makes it better in at least one respect than the simple scheme you outline :-) Incidentally all of what you have wrote in that paragraph is also true of the proposal before us. Moving back a little, there's nothing wrong with simply using multiple EDNS options to pass on multiple parameters. E.g. DNS QUERY, EDNS0 CLIENT_SUBNET OPTION, EDNS0 CLIENT_AS_NUMBER OPTION so re-thinking, I'm not sure what the benefit of folding them all into one option would be. There needs to a registry for the "flags" - we may as well use the existing EDNS option registry. > The substantial extra work that needs to be done is rewriting > the cache in the caching nameservers to filter by the additional > tags it supplies. I would argue this needs to be done anyway > to do proper caching in your draft. Yes :-) I'm one of the authors of Apache's mod_cache and associated caching modules there - it's a complex negotiation-friendly cache that is well-deployed and widely used for a variety of purposes. Based on that experience, I'm not sure I'd agree that it's substantial, I found coping with that kind of negotiation a relatively straightforward matter of hashing, trie data-structures and so on. -- Colm From owner-namedroppers@ops.ietf.org Tue Jun 1 10:57:44 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DFBD3A6A2A; Tue, 1 Jun 2010 10:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.656, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx89UDG+1WD2; Tue, 1 Jun 2010 10:57:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF8523A6A29; Tue, 1 Jun 2010 10:57:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJVer-000GDT-5T for namedroppers-data0@psg.com; Tue, 01 Jun 2010 17:53:45 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJVel-000GCO-0k for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 17:53:39 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 74F86A3B53 for ; Tue, 1 Jun 2010 17:53:37 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] end-to-end violations in draft-vandergaast-edns-client-ip-01 In-Reply-To: Your message of "Tue, 01 Jun 2010 16:30:00 +0100." References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Tue, 01 Jun 2010 17:53:37 +0000 Message-ID: <17203.1275414817@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Jim Reid > Date: Tue, 1 Jun 2010 16:30:00 +0100 > > ... even though we accept these middleboxes as a necessary and probably > unavoidable wart on a pure end-to-end model, this does not mean they have > a free hand to tamper with DNS queries and replies. [Like secretly > adding or removing EDNS options as this draft proposes.] And yes, I know > some middleboxes already do stupid/evil things to DNS traffic. IMO, > that's not an excuse to encourage more of that sort of behaviour. Or > standardise it. +1. From owner-namedroppers@ops.ietf.org Tue Jun 1 11:26:11 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF9C3A6895; Tue, 1 Jun 2010 11:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.053 X-Spam-Level: * X-Spam-Status: No, score=1.053 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRzdrPumiXeZ; Tue, 1 Jun 2010 11:26:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 11A273A6860; Tue, 1 Jun 2010 11:26:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJW5H-000MSi-UH for namedroppers-data0@psg.com; Tue, 01 Jun 2010 18:21:03 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJW5D-000MRr-Tz for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 18:21:00 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o51IKv02057918 for ; Tue, 1 Jun 2010 14:20:58 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4C054F87.5010608@ogud.com> Date: Tue, 01 Jun 2010 14:20:55 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: namedroppers Subject: [dnsext] Chairs statement on "client-option" debate Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, The chairs have been following this discussion with great interest. At this point we would like to make the following comments. #0 Culture clash The thread has demonstrated that "traditional" DNS people and "traditional" CDN people do not think the same way or have the same "values". We would like to ask all parties to respect each others' point of view even when you do not agree with it. Please do not use ancient history as a reason to push/reject proposals. #1 Terminology disconnect: When talking to a large group of people do not assume that generic terms will be understood the same way. I.e. "Optimal" needs context for productive discussion, CDN people think it related to TCP RTT, while DNS people think it about making queries resolve faster. #2 Problem statement: We think we are close to understanding what the problem statement is. But there is need for a concise one that does not intermingle "misunderstanding" and problem. What we mean here is that CDN people have made an assumption that resolvers are "close" to "host making query", DNS people have to large extent never agreed with this assumption. The problem statement needs to be explicit about what the issues are. #3 Solution spaces: What we have on the table is proposed solution that does not explain why DNS is the best solution space and why. The question on the table is why can this not be done with HTTP command or the http page returned to connection be served up with domain names that reflect the location of the source address? #4 Cost and implementation considerations: No solution is "free" but different solutions allocate the cost differently, the solutions that have best chance of succeeding are the ones that allocate the cost to the parties that have most to gain. #5 Respect: It is not productive to have people, stick fingers in their ears and keep saying "lalalalalalalalalalalalalalalala". If you have nothing new to contribute please resist posting. #6 Adoption plans: We are planning to ask the working group formally if the WG wants to adopt this work item, but there are two other items in our queue that we will ask about first. Olafur & Andrew From owner-namedroppers@ops.ietf.org Tue Jun 1 11:26:17 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F36B33A6822; Tue, 1 Jun 2010 11:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.092 X-Spam-Level: ** X-Spam-Status: No, score=2.092 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzDdp6r5Lp4c; Tue, 1 Jun 2010 11:26:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0698E3A6860; Tue, 1 Jun 2010 11:26:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJW5L-000MTC-Or for namedroppers-data0@psg.com; Tue, 01 Jun 2010 18:21:07 +0000 Received: from [140.186.190.103] (helo=haybaler.sackheads.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJW5F-000MRv-26 for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 18:21:01 +0000 Received: from localhost (localhost.sackheads.org [127.0.0.1]) by haybaler.sackheads.org (Postfix) with ESMTP id E577C28A65; Tue, 1 Jun 2010 14:20:58 -0400 (EDT) Authentication-Results: haybaler.sackheads.org; domainkeys=pass (testing) header.from=john@sackheads.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1275416459; bh=SN4Kiy/+wn/sH9rndFce2xQO3rOfb7wExaQhWLhU3u4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vGZz60oIqJLTg6a9BrOk/hcaSTqSwQ9iOkwUgZIh1sU/MEHppgcYr5VfE2xvwRZRj Uf3d0c5+kGZgz/apTGwF8+Z++d8/z+4g8ootEAJOJP0mznNFEQXTc0Km+XAcetKve1 soGjsC4ZxxMEbgmCn1leMbyCA5YIEYFSXpgcTBLA= Received: from haybaler.sackheads.org ([127.0.0.1]) by localhost (haybaler.sackheads.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgQzWyvkKQJl; Tue, 1 Jun 2010 14:20:58 -0400 (EDT) Received: by haybaler.sackheads.org (Postfix, from userid 65534) id BE4D528A63; Tue, 1 Jun 2010 14:20:58 -0400 (EDT) Received: from usma1mc-0f6642.8cc-neteng.corp.akamai.com (unknown [72.246.0.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: john@sackheads.org) by haybaler.sackheads.org (Postfix) with ESMTP id 4F4382858F; Tue, 1 Jun 2010 14:20:58 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=haybaler; d=sackheads.org; c=nofws; q=dns; h=dkim-signature:subject:mime-version:content-type:from: in-reply-to:date:cc:content-transfer-encoding:message-id:references:to:x-mailer; b=azf6lmlJeiZmdNguwVmPgSqOx5uyoqgo1A+13mOKRBFyIjAixyxn3znXWAnDXGdRc EcDeiWYr3Gbf1ZPR8GaEkarW7SR2ohoEMT1Zcn7t1rKurM65DEkJypMXm63z48oOX29 LiZBnse4txhOBGM/IUuag6slhVHpTHnzA2gZCnc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1275416458; bh=SN4Kiy/+wn/sH9rndFce2xQO3rOfb7wExaQhWLhU3u4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qQFytF7bp06wqnkrsni2YbSMwq2yHszBvBMGG2FSMNnFRKW6cJF9S5ORZdbhgztBS LaYpxANoZIU7IGZISzisDJ8uUi+CvON4zcaNqeBhv3wDE26xlCNPef6jWbtiqXCDoi qbb6Wet7mrP1632cSp9VPDtliJMV73kRP442IlYI= Subject: Re: [dnsext] latency Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: John Payne In-Reply-To: <20100601173827.GC4379@vacation.karoshi.com.> Date: Tue, 1 Jun 2010 14:20:57 -0400 Cc: Bruce Campbell , "sthaug@nethelp.no" , "namedroppers@ops.ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <73C2798F-A399-46A5-8B31-FE7C044676C2@sackheads.org> References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <20100601173827.GC4379@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 1, 2010, at 1:38 PM, bmanning@vacation.karoshi.com wrote: > On Tue, Jun 01, 2010 at 12:12:03AM -0400, John Payne wrote: >>=20 >>=20 >> On May 31, 2010, at 11:52 AM, Bruce Campbell = wrote: >>=20 >>> Most web browsers seem to look up domain names en-mass and incur = max(latency difference) or latency difference * number of concurrent = queries, rather than one-by-one and thus latency difference * N. >>=20 >> The latency is not in the name lookups.... >>=20 >>> As a corporate admin, I'd hate to have details of my internal = infrastructure walking out along with the DNS queries, and I fear that = this will trigger more active inspection and modification of DNS packets = at the egress of such networks, with accompanying poorly-implemented = breakage. >>=20 >> Then you wouldn't enable the option, and you wouldn't enter into an = agreement with any auth server operator to use that option if you did = accidentally enable it. >=20 >=20 > are you suggesting this option is enabled on a per server basis = (e.g. pairwise betwn > servers?) or will it also have zone granularity as well? That would be implementation details :) However, I am suggesting that there are or will be business drivers that = require some form of agreement between operators in some use cases. I would be surprised if (m)any CDN operators enable this without at = least some form of whitelisting where they'll accept the option from. To a lesser degree, I'd also be surprised if the 3rd party resolvers = enabled sending this option without some form of whitelisting where they = send it. But, I've been surprised before.... From owner-namedroppers@ops.ietf.org Tue Jun 1 12:42:11 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8AAB3A6A80; Tue, 1 Jun 2010 12:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8sPVfMSm9nY; Tue, 1 Jun 2010 12:42:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D80B3A6A7D; Tue, 1 Jun 2010 12:42:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJXGA-000A52-1k for namedroppers-data0@psg.com; Tue, 01 Jun 2010 19:36:22 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJXG6-000A4j-75 for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 19:36:18 +0000 Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5E8831ECB41D for ; Tue, 1 Jun 2010 19:36:14 +0000 (UTC) Date: Tue, 1 Jun 2010 15:36:11 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] end-to-end violations in draft-vandergaast-edns-client-ip-01 Message-ID: <20100601193610.GE48629@shinkuro.com> References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: No hat. On Mon, May 31, 2010 at 11:48:07AM +0100, Jim Reid wrote: > violation of the end to end principle. To repeat what I said earlier, a > resolving server should not be tampering with the contents of a stub's > query or the resulting response. This should be common sense. What implications, if any, does that common sense have for DNSSEC validation at intermediate resolvers on behalf of "dumb" stub resolvers? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Jun 1 12:49:08 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C7BC3A68EB; Tue, 1 Jun 2010 12:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.093 X-Spam-Level: X-Spam-Status: No, score=-100.093 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik38DX82hMSx; Tue, 1 Jun 2010 12:49:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E084C3A6A5A; Tue, 1 Jun 2010 12:48:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJXNV-000BSR-Iw for namedroppers-data0@psg.com; Tue, 01 Jun 2010 19:43:57 +0000 Received: from [2001:470:1f05:a0f::1] (helo=tigger.mamista.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJXNR-000BRq-84 for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 19:43:53 +0000 Received: by tigger.mamista.net (Postfix, from userid 1012) id EDD41110655; Wed, 2 Jun 2010 05:43:52 +1000 (EST) Received: from merboo.mamista.net (merboo.mamista.net [IPv6:2001:470:1f0b:1055::1]) by tigger.mamista.net (Postfix) with ESMTP id A8C4A110655 for ; Wed, 2 Jun 2010 05:43:52 +1000 (EST) Received: by merboo.mamista.net (Postfix, from userid 1000) id DAF5F972204; Tue, 1 Jun 2010 21:43:50 +0200 (CEST) Date: Tue, 1 Jun 2010 21:43:50 +0200 From: Martin Barry To: namedroppers@ops.ietf.org Subject: Re: [dnsext] clarifications needed on draft-vandergaast-edns-client-ip-01 Message-ID: <20100601194350.GA3793@merboo.mamista.net> References: <20100601140124.GA20770@merboo.mamista.net> <35C1173E-6BFB-4336-81A2-7F1D15DEB1FC@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <35C1173E-6BFB-4336-81A2-7F1D15DEB1FC@rfc1035.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: $quoted_author = "Jim Reid" ; > > On 1 Jun 2010, at 15:01, Martin Barry wrote: > > > >An in-band method of automatically determining that "list" would > >be better. > > > >Perhaps send EDNS-client-ip at random intervals to authorative servers > >being queried and keep track of which respond to it? > > That's not scalable either. Resolvers already keep state (e.g. RTT) about queried servers. You could add a binary flag for "uses EDNS-client-ip". That appears to be minimal overhead with linear scalability to me. cheers Marty From owner-namedroppers@ops.ietf.org Tue Jun 1 13:14:50 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF2E3A6AD0; Tue, 1 Jun 2010 13:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.801 X-Spam-Level: *** X-Spam-Status: No, score=3.801 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24t9EV1bx6ly; Tue, 1 Jun 2010 13:14:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C217328C112; Tue, 1 Jun 2010 13:14:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJXmR-000GsV-9X for namedroppers-data0@psg.com; Tue, 01 Jun 2010 20:09:43 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJXmK-000GrO-O7 for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 20:09:37 +0000 Received: from [10.71.0.51] (unknown [69.38.231.138]) by mail.avalus.com (Postfix) with ESMTPSA id C1520C5687B; Tue, 1 Jun 2010 21:09:34 +0100 (BST) Date: Tue, 01 Jun 2010 16:09:33 -0400 From: Alex Bligh Reply-To: Alex Bligh To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) Message-ID: In-Reply-To: References: <421400056AC3A68D057ED565@nimrod.local> <8D6F3C331BDC4FAFF237C0BA@nimrod.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 1 June 2010 10:44:21 -0700 Colm MacC=C3=A1rthaigh =20 wrote: > 2010/6/1 Alex Bligh : >>> I think it would take more work to make such a system as the proposal >>> that's here already. IP subnets would need all of the CIDR/VLSM >>> cacheability hints, and other fields would need other heuristics. >> >> No they wouldn't. The caching resolver *could* supply CIDR BGP >> reachability hints, or it *could* always truncate at /24, or it >> *could* always pass on the /32, or it *could* pass on nothing. > > I think you may be missing some of the detail of the proposed option > before us. Possibly - I read the latest draft far less thoroughly than I did the first one. However, the main thing I don't like is that the option originates at the client. There is a presumption the stub resolver changes (or at least can change) which I think is both unnecessary and invidious. If it does, then inevitably the option starts being passed in more traffic than just caching resolver to authoritative, and it's one more thing making packets larger, which is a bad thing in the land of the broken middlebox. If I've got completely the wrong end of the stick here, I apologise. --=20 Alex Bligh From owner-namedroppers@ops.ietf.org Tue Jun 1 13:51:17 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B553528C13F; Tue, 1 Jun 2010 13:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.026 X-Spam-Level: X-Spam-Status: No, score=-100.026 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_50=0.001, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLcoDMyRxLGU; Tue, 1 Jun 2010 13:51:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F7B328C123; Tue, 1 Jun 2010 13:51:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJYLI-000MfT-ON for namedroppers-data0@psg.com; Tue, 01 Jun 2010 20:45:44 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJYL5-000MQv-El for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 20:45:34 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o51KgA6H005997; Tue, 1 Jun 2010 20:42:25 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o51KfGYe005996; Tue, 1 Jun 2010 20:41:16 GMT Date: Tue, 1 Jun 2010 20:41:11 +0000 From: bmanning@vacation.karoshi.com To: John Payne Cc: bmanning@vacation.karoshi.com, Bruce Campbell , "sthaug@nethelp.no" , "namedroppers@ops.ietf.org" Subject: Re: [dnsext] latency Message-ID: <20100601204111.GA5952@vacation.karoshi.com.> References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <20100601173827.GC4379@vacation.karoshi.com.> <73C2798F-A399-46A5-8B31-FE7C044676C2@sackheads.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73C2798F-A399-46A5-8B31-FE7C044676C2@sackheads.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Jun 01, 2010 at 02:20:57PM -0400, John Payne wrote: > > On Jun 1, 2010, at 1:38 PM, bmanning@vacation.karoshi.com wrote: > > > On Tue, Jun 01, 2010 at 12:12:03AM -0400, John Payne wrote: > >> > >> > >> On May 31, 2010, at 11:52 AM, Bruce Campbell wrote: > >> > >>> Most web browsers seem to look up domain names en-mass and incur max(latency difference) or latency difference * number of concurrent queries, rather than one-by-one and thus latency difference * N. > >> > >> The latency is not in the name lookups.... > >> > >>> As a corporate admin, I'd hate to have details of my internal infrastructure walking out along with the DNS queries, and I fear that this will trigger more active inspection and modification of DNS packets at the egress of such networks, with accompanying poorly-implemented breakage. > >> > >> Then you wouldn't enable the option, and you wouldn't enter into an agreement with any auth server operator to use that option if you did accidentally enable it. > > > > > > are you suggesting this option is enabled on a per server basis (e.g. pairwise betwn > > servers?) or will it also have zone granularity as well? > > That would be implementation details :) perhaps ... TSIG and SIG(0) are server/server not zone/zone and DNSSEC is on a per-zone basis, not server/server or even RRset/RRset. So I don't see this as an "implementation detail" or "local policy"... Something like this has to be -CLEARLY- specified as to its intended/expected use and mapping prohibitions on uses that would break/violate other parts of the DNS... IMHO, not an implementation detail. :) > > However, I am suggesting that there are or will be business drivers that require some form of agreement between operators in some use cases. twas ever thus. > I would be surprised if (m)any CDN operators enable this without at least some form of whitelisting where they'll accept the option from. ok - so you believe that EDNS options are negotiable on a pairwise basis between operators on a per zone basis... interesting. > To a lesser degree, I'd also be surprised if the 3rd party resolvers enabled sending this option without some form of whitelisting where they send it. > > But, I've been surprised before.... > From delinquency90@realpro.com Tue Jun 1 14:03:23 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3840928C172; Tue, 1 Jun 2010 14:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -61.54 X-Spam-Level: X-Spam-Status: No, score=-61.54 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_FAKE_RCVD_LINE_B=5.777, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU97ZmAGwsIG; Tue, 1 Jun 2010 14:03:22 -0700 (PDT) Received: from 77-254-65-65.adsl.inetia.pl (77-254-65-65.adsl.inetia.pl [77.254.65.65]) by core3.amsl.com (Postfix) with ESMTP id 3EA8F28C1A2; Tue, 1 Jun 2010 14:02:32 -0700 (PDT) Received: from 77.254.65.65 by mail1.realpro.com; Tue, 1 Jun 2010 23:01:30 +0100 Message-ID: <000d01cb01cd$9bfd3fe0$6400a8c0@delinquency90> From: "American Express" To: Subject: American Express Online Form Date: Tue, 1 Jun 2010 23:01:30 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CB01CD.9BFD3FE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CB01CD.9BFD3FE0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 Dear American Express customer, A newly revised American Express Online Form has been issued by the America= n Express Customer Care Team. Please complete this form as soon as possible= You can access the form at:American Express Online Form=2E Thank you for choosing American Express=2E Sincerely, American Express To learn more about e-mail security or report a suspicious e-mail, visit us= at americanexpress.com/phishing. We are unable to answer replies to this e= -mail=2E Copyright 2010 American Express Company. All rights reserved=2E ------=_NextPart_000_0007_01CB01CD.9BFD3FE0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable





















Dear American Express = customer,

A newly revised American Express Online Form has been issued by the America= n Express Customer Care Team. Please complete this form as soon as possible= You can access the form at:

American Express Online Form.

Thank you for choosing American Express.

Sincerely,
American Express



















To learn more about e-mail security or report a suspicious e-mail, vis= it us at american= express.com/phishing. We are unable to answer replies to this e-mail.
Copyright 2010 American Express Company. All rights reserved.
------=_NextPart_000_0007_01CB01CD.9BFD3FE0-- From owner-namedroppers@ops.ietf.org Tue Jun 1 14:05:13 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5CE28C17D; Tue, 1 Jun 2010 14:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.617 X-Spam-Level: ** X-Spam-Status: No, score=2.617 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i27-l1NxAzSO; Tue, 1 Jun 2010 14:05:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 432E728C183; Tue, 1 Jun 2010 14:05:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJYaN-000Pj7-0J for namedroppers-data0@psg.com; Tue, 01 Jun 2010 21:01:19 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJYaJ-000PiU-0T for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 21:01:15 +0000 Received: (qmail 34326 invoked from network); 1 Jun 2010 21:20:51 -0000 Received: from softbank219001188004.bbtec.net (HELO ?192.168.1.27?) (219.1.188.4) by necom830.hpcl.titech.ac.jp with SMTP; 1 Jun 2010 21:20:51 -0000 Message-ID: <4C0574BA.3050306@necom830.hpcl.titech.ac.jp> Date: Wed, 02 Jun 2010 05:59:38 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Donald Eastlake CC: IETF DNSEXT WG Subject: Re: [dnsext] end-to-end violations in draft-vandergaast-edns-client-ip-01 References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Donald Eastlake wrote: > Thanks for bringing up the end-to-end principle. FYI, DNS, with a lot of intermediate servers for intermediate zones, is *NOT* end to end. PERIOD. Masataka Ohta From owner-namedroppers@ops.ietf.org Tue Jun 1 14:05:15 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A86328C0F0; Tue, 1 Jun 2010 14:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.709 X-Spam-Level: *** X-Spam-Status: No, score=3.709 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1, SARE_HEXOCTDWORD=2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNlz9w+FN-lm; Tue, 1 Jun 2010 14:05:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D7DCB28C0E8; Tue, 1 Jun 2010 14:05:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJYYy-000PTG-Rb for namedroppers-data0@psg.com; Tue, 01 Jun 2010 20:59:52 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJYYr-000PQF-07 for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 20:59:45 +0000 Received: (qmail 34162 invoked from network); 1 Jun 2010 21:18:56 -0000 Received: from softbank219001188004.bbtec.net (HELO ?192.168.1.27?) (219.1.188.4) by necom830.hpcl.titech.ac.jp with SMTP; 1 Jun 2010 21:18:56 -0000 Message-ID: <4C057447.5000202@necom830.hpcl.titech.ac.jp> Date: Wed, 02 Jun 2010 05:57:43 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Nicholas Weaver CC: Brian Dickson , namedroppers@ops.ietf.org Subject: Re: [dnsext] client-subnet - questions for the authors, and outside-the-box brainstorming References: <4C050022.3000508@necom830.hpcl.titech.ac.jp> <9519475D-FF8B-4820-8E9E-A06792E25535@icsi.berkeley.edu> In-Reply-To: <9519475D-FF8B-4820-8E9E-A06792E25535@icsi.berkeley.edu> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Nicholas Weaver wrote: >> Brian Dickson wrote: > For HTTP, redirection JUST DOES NOT WORK FOR THIS, IT DOES. > 1: HTTP redirection adds 3+ RTTs of additional latency, > between the TCP handshake and the 302 redirect and the new > DNS lookup needed for the customized name. If your goal is > to shave a second off of page load, this eliminates the benefit. If initial RTTs were the problem, never use DNS for extra several RTTs. Instead, use: http://273.51.152.23/URL Not that cache does not help the initial query. Or, even if RTTs of DNS are allowable but additional 3 RTTs were unacceptable, there is no point to use open resolver services with remote servers at a distance with large RTTs. If the resolver services is extensively anycast, you are done. But, the reality is that initial several RTTs are acceptable. > 2: HTTP redirection can only provide a different URL, which is > unacceptable for many web site providers. You don't want to see > > http://a351.www.mysite.com/URL If you use "www.yahoo.com", you'll see a lot of "a.l.yimg.com" etc. used. Try it to see the reality of HTTP. > [1] Yes, I'm feeling very repetitive here. And you still don't know the initial RTTs are not a problem. Why? Masataka Ohta From owner-namedroppers@ops.ietf.org Tue Jun 1 14:52:51 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF753A6852; Tue, 1 Jun 2010 14:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.028 X-Spam-Level: *** X-Spam-Status: No, score=3.028 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIvdVmUnOKzp; Tue, 1 Jun 2010 14:52:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 75B043A690C; Tue, 1 Jun 2010 14:52:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJZHx-0007MR-C7 for namedroppers-data0@psg.com; Tue, 01 Jun 2010 21:46:21 +0000 Received: from [74.125.83.52] (helo=mail-gw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJZHt-0007Lv-HD for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 21:46:17 +0000 Received: by gwj20 with SMTP id 20so173811gwj.11 for ; Tue, 01 Jun 2010 14:46:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.5.81 with SMTP id 17mr580313icv.29.1275428775670; Tue, 01 Jun 2010 14:46:15 -0700 (PDT) Received: by 10.231.30.129 with HTTP; Tue, 1 Jun 2010 14:46:15 -0700 (PDT) In-Reply-To: <4C057447.5000202@necom830.hpcl.titech.ac.jp> References: <4C050022.3000508@necom830.hpcl.titech.ac.jp> <9519475D-FF8B-4820-8E9E-A06792E25535@icsi.berkeley.edu> <4C057447.5000202@necom830.hpcl.titech.ac.jp> Date: Tue, 1 Jun 2010 14:46:15 -0700 Message-ID: Subject: Re: [dnsext] client-subnet - questions for the authors, and outside-the-box brainstorming From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Masataka Ohta Cc: Nicholas Weaver , Brian Dickson , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: 2010/6/1 Masataka Ohta : > Nicholas Weaver wrote: >>> Brian Dickson wrote: > >> For HTTP, redirection JUST DOES NOT WORK FOR THIS, > > IT DOES. Ouch, all this shouting, my poor ears, For comparison, below are two scenarios - one with HTTP tricks, one with DNS tricks. In both cases we want a user going to http://example.com/ to be directed to their nearest internet node that serves that website, the goal is speedy delivery. C = client, R = resolver, A = authoritative nameserver , I = intermediary HTTP server, S = Ultimate HTTP server (i) DNS tricks Client queries the resolver for example.com Resolver queries the auth server, auth server responds Resolver responds to client Client initialises TCP connection to Ultimate HTTP server Total network time to first byte; |CR| + |RA| + 2x |CS| (ii) HTTP tricks Client queries the resolver for example.com Resolver queries the auth server, auth server responds Resolver responds to the client Client initiaises TCP connection to Intermediary HTTP server Client Receives redirect to "192.0.2.1.example.com" say, Client queries the resolver for this new name. Resolver queries the auth server, auth server responds Resolver responds to the client Client initialises TCP connection to ultimate HTTP server Total network time to first byte: 2x |CR| + 2x |RA| + 2x |CI| + 2x |CS| Total difference between the two; |CR| + |RA| + |CI| . Obviously these are the boundary cases, which involve cache misses. Each have different caching properties, the second example can use more long-lived TTLs for example, whereas the first example - with the option we are discussing - can perform CIDR-level caching. However obviously for at least some number of queries which are misses, things will be much worse. Some have stated that HTTP level redirects can be used to mitigate this, e.g. http://example.com/ -> http://192.0.2.1.example.com/ [301 Permanent] It is true that the browser can remember this redirect (though many fail to) , however it does apply to the entire hierarchy. http://example.com/foo/ must go through the entire dance again :) Another point of consideration is that many website maintainers simply do not like the appearance of "192.0.2.1.example.com" in URLS - there may also be anonymity concerns. -- Colm From owner-namedroppers@ops.ietf.org Tue Jun 1 15:07:49 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7064628C172; Tue, 1 Jun 2010 15:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=-1.409, BAYES_50=0.001, FH_RELAY_NODNS=1.451, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_HEXOCTDWORD=2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq8uk4PlxoVl; Tue, 1 Jun 2010 15:07:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 424463A6924; Tue, 1 Jun 2010 15:07:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJZYw-000AU6-8E for namedroppers-data0@psg.com; Tue, 01 Jun 2010 22:03:54 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJZYr-000ARX-SS for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 22:03:50 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o51Lf0oF007536; Tue, 1 Jun 2010 14:41:00 -0700 (PDT) References: <4C050022.3000508@necom830.hpcl.titech.ac.jp> <9519475D-FF8B-4820-8E9E-A06792E25535@icsi.berkeley.edu> <4C057447.5000202@necom830.hpcl.titech.ac.jp> In-Reply-To: <4C057447.5000202@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <16FFD220-35D2-4AEB-A94A-A210E579D0B1@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , Brian Dickson , namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: [dnsext] client-subnet - questions for the authors, and outside-the-box brainstorming Date: Tue, 1 Jun 2010 14:41:00 -0700 To: Masataka Ohta X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 1, 2010, at 1:57 PM, Masataka Ohta wrote: > Nicholas Weaver wrote: >=20 >>> Brian Dickson wrote: >=20 >> For HTTP, redirection JUST DOES NOT WORK FOR THIS, >=20 > IT DOES. >=20 >> 1: HTTP redirection adds 3+ RTTs of additional latency, >> between the TCP handshake and the 302 redirect and the new >> DNS lookup needed for the customized name. If your goal is >> to shave a second off of page load, this eliminates the benefit. >=20 > If initial RTTs were the problem, never use DNS for extra several > RTTs. Instead, use: >=20 > http://273.51.152.23/URL >=20 > Not that cache does not help the initial query. >=20 > Or, even if RTTs of DNS are allowable but additional 3 RTTs were > unacceptable, there is no point to use open resolver services > with remote servers at a distance with large RTTs. If the > resolver services is extensively anycast, you are done. > But, the reality is that initial several RTTs are acceptable. They are not, because if they were, people would be using HTTP redirects = if they were. They aren't. An HTTP redirect, even excluding the DNS transfer, is uncacheable, = uncached, and significantly slower than the DNS lookup, as even with the = stupid-short TTLs of the terminal names (eg, any-fp-wa1.b.yahoo.com), = thats only one or two RTT for the name lookup, compared with 3 RTTs for = a 302 redirect. >> 2: HTTP redirection can only provide a different URL, which is >> unacceptable for many web site providers. You don't want to see >>=20 >> http://a351.www.mysite.com/URL >=20 > If you use "www.yahoo.com", you'll see a lot of "a.l.yimg.com" > etc. used. >=20 > Try it to see the reality of HTTP. These are NOT externally visible URLs to the title bar, AND are always = consistent. You don't see a234.d.yimg.com spewed throughout the page, you just see = d.yimg.com You do NOT see the top URL as a234.www.yahoo.com, you see www.yahoo.com. For latency, you need to redirect the top URL on the page. And d.yimg.com does NOT do 302 redirects to a125.d.yimg.com either for = the actual fetches, rather, d.yimg.com IS using the same DNS games as = well! The reality of HTTP is that 302 redirects are a far inferior solution to = minimizing latency compared with the stupid DNS tricks. >> [1] Yes, I'm feeling very repetitive here. >=20 > And you still don't know the initial RTTs are not a problem. >=20 > Why? Some simple math: DNS "stupid trick" has NO substanial effect on the DNS lookup latency, = but can reduce the RTT to the server by 100ms for the simple case of "US = west coast" vs "US east coast" (beyond that starts to be more marginal, = but at least getting the right part of the right continent is a huge win = right there!). If you did that in HTTP redirection, you'd get 3-4 RTTs of latency = piling on, delaying page load by 300-400ms. AND the HTTP server, = without DNS tricks, is almost certainly guaranteed to be suboptimal for = a huge fraction of the users (after all, in the US, you're pretty much = either on the east coast or the west coast, so 1/2 the users are 100ms = away). This counts! In summary: Stupid DNS trick present saving 100ms, 10 RTTs of total latency on page = load: Net savings: 1s just to start with. Nice. HTTP redirection "instead": Additional 3 RTTs, to a 100ms latency = server for at least 1/2 the userbase, cuts the net savings by 300ms. = Owch. So yes, the initial RTTs are a problem, and HTTP redirection is NOT the = solution. =20 "Proper" authority behavior is. And thats why people do the stupid DNS = games that a vocal portion of this group decry. They work, and the = savings for just the simple case (get the sub-continent right) is huge = right there. From owner-namedroppers@ops.ietf.org Tue Jun 1 15:17:22 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 945FD28C1BC; Tue, 1 Jun 2010 15:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.246 X-Spam-Level: *** X-Spam-Status: No, score=3.246 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCXcfeDhvD2D; Tue, 1 Jun 2010 15:17:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9052E28C1BB; Tue, 1 Jun 2010 15:17:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJZiV-000BxV-A6 for namedroppers-data0@psg.com; Tue, 01 Jun 2010 22:13:47 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJZiO-000Bvj-0v for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 22:13:40 +0000 Received: from [10.71.0.51] (unknown [69.38.231.138]) by mail.avalus.com (Postfix) with ESMTPSA id 8ACBBC56901; Tue, 1 Jun 2010 23:13:37 +0100 (BST) Date: Tue, 01 Jun 2010 18:13:36 -0400 From: Alex Bligh Reply-To: Alex Bligh To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , Masataka Ohta cc: Nicholas Weaver , Brian Dickson , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: [dnsext] client-subnet - questions for the authors, and outside-the-box brainstorming Message-ID: <3D897A113274790F406D8500@nimrod.local> In-Reply-To: References: <4C050022.3000508@necom830.hpcl.titech.ac.jp> <9519475D-FF8B-4820-8E9E-A06792E25535@icsi.berkeley.edu> <4C057447.5000202@necom830.hpcl.titech.ac.jp> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 1 June 2010 14:46:15 -0700 Colm MacC=C3=A1rthaigh =20 wrote: > Another point of consideration is that many website maintainers simply > do not like the appearance of "192.0.2.1.example.com" in URLS - there > may also be anonymity concerns. plus https certification issues. --=20 Alex Bligh From owner-namedroppers@ops.ietf.org Tue Jun 1 15:58:13 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6208A3A67F9; Tue, 1 Jun 2010 15:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.159 X-Spam-Level: **** X-Spam-Status: No, score=4.159 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_37=0.6, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfmV3qs5zZxS; Tue, 1 Jun 2010 15:58:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 167333A6862; Tue, 1 Jun 2010 15:58:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJaKK-000HWZ-4G for namedroppers-data0@psg.com; Tue, 01 Jun 2010 22:52:52 +0000 Received: from [140.186.190.103] (helo=haybaler.sackheads.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJaKB-000HUc-Iy for namedroppers@ops.ietf.org; Tue, 01 Jun 2010 22:52:43 +0000 Received: from localhost (localhost.sackheads.org [127.0.0.1]) by haybaler.sackheads.org (Postfix) with ESMTP id D19CF28A65; Tue, 1 Jun 2010 18:52:41 -0400 (EDT) Authentication-Results: haybaler.sackheads.org; domainkeys=pass (testing) header.from=john@sackheads.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1275432761; bh=V4xKok9kxlm6HkPnm8Dd3s43AnnMmcNpcNUmu+C9JWA=; h=References:In-Reply-To:Mime-Version:Content-Transfer-Encoding: Content-Type:Message-Id:Cc:From:Subject:Date:To; b=N0KZULGRSUqlkO9+hPa5pv/u/+hxA7a71s5vr4P0V6ddBnaa5S/mnLGVEpHZYQxAw 25jvzv5xv7mjeVCxuPqONk2tl0RS2oGTOCpoxlKSz1JqAKMksiUj+HbNdovyizW57X dMcm2lCFhWwyP9p8DFYEUtoHtfRVJLR0IChRn3mo= Received: from haybaler.sackheads.org ([127.0.0.1]) by localhost (haybaler.sackheads.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfGSAmoaavGg; Tue, 1 Jun 2010 18:52:41 -0400 (EDT) Received: by haybaler.sackheads.org (Postfix, from userid 65534) id 92A082893E; Tue, 1 Jun 2010 18:52:41 -0400 (EDT) Received: from [10.111.119.2] (mobile-166-137-139-112.mycingular.net [166.137.139.112]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: john@sackheads.org) by haybaler.sackheads.org (Postfix) with ESMTP id DFC7A28426; Tue, 1 Jun 2010 18:52:38 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=haybaler; d=sackheads.org; c=nofws; q=dns; h=dkim-signature:references:in-reply-to:mime-version: content-transfer-encoding:content-type:message-id:cc:x-mailer:from:subject:date:to; b=yKjBHOU1TBQmYPuyWj936zjPJb8Uwt9BMc6AB1XM4SbrkEmw6pOWWu7QfmUUKxSv4 f2pvmtxV66TB30ckfjZRorOlPWaN48gZsnGLnMVbglZpJb3Sb7YNIlBzXZE6ggRePbu U6TglPnmL9w5QUgPuv2aP7M+anrgQ3oBYA7bx1E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1275432761; bh=V4xKok9kxlm6HkPnm8Dd3s43AnnMmcNpcNUmu+C9JWA=; h=References:In-Reply-To:Mime-Version:Content-Transfer-Encoding: Content-Type:Message-Id:Cc:From:Subject:Date:To; b=N0KZULGRSUqlkO9+hPa5pv/u/+hxA7a71s5vr4P0V6ddBnaa5S/mnLGVEpHZYQxAw 25jvzv5xv7mjeVCxuPqONk2tl0RS2oGTOCpoxlKSz1JqAKMksiUj+HbNdovyizW57X dMcm2lCFhWwyP9p8DFYEUtoHtfRVJLR0IChRn3mo= References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <20100601173827.GC4379@vacation.karoshi.com.> <73C2798F-A399-46A5-8B31-FE7C044676C2@sackheads.org> <20100601204111.GA5952@vacation.karoshi.com.> In-Reply-To: <20100601204111.GA5952@vacation.karoshi.com.> Mime-Version: 1.0 (iPhone Mail 8A274b) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <06201F08-4A0D-4055-8110-FC82EBC30697@sackheads.org> Cc: "bmanning@vacation.karoshi.com" , Bruce Campbell , "sthaug@nethelp.no" , "namedroppers@ops.ietf.org" X-Mailer: iPhone Mail (8A274b) From: John Payne Subject: Re: [dnsext] latency Date: Tue, 1 Jun 2010 18:52:31 -0400 To: "bmanning@vacation.karoshi.com" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 1, 2010, at 4:41 PM, bmanning@vacation.karoshi.com wrote: > On Tue, Jun 01, 2010 at 02:20:57PM -0400, John Payne wrote: >>=20 >> On Jun 1, 2010, at 1:38 PM, bmanning@vacation.karoshi.com wrote: >>=20 >>> On Tue, Jun 01, 2010 at 12:12:03AM -0400, John Payne wrote: >>>>=20 >>>>=20 >>>> On May 31, 2010, at 11:52 AM, Bruce Campbell wrote: >>>>=20 >>>>> Most web browsers seem to look up domain names en-mass and incur max(l= atency difference) or latency difference * number of concurrent queries, rat= her than one-by-one and thus latency difference * N. >>>>=20 >>>> The latency is not in the name lookups.... >>>>=20 >>>>> As a corporate admin, I'd hate to have details of my internal infrastr= ucture walking out along with the DNS queries, and I fear that this will tri= gger more active inspection and modification of DNS packets at the egress of= such networks, with accompanying poorly-implemented breakage. >>>>=20 >>>> Then you wouldn't enable the option, and you wouldn't enter into an agr= eement with any auth server operator to use that option if you did accidenta= lly enable it. >>>=20 >>>=20 >>> are you suggesting this option is enabled on a per server basis (e.g.= pairwise betwn >>> servers?) or will it also have zone granularity as well? >>=20 >> That would be implementation details :) >=20 > perhaps ... TSIG and SIG(0) are server/server not zone/zone=20 > and DNSSEC is on a per-zone basis, not server/server or even RRset/RRse= t. > So I don't see this as an "implementation detail" or "local policy"... >=20 > Something like this has to be -CLEARLY- specified as to its intended/ex= pected > use and mapping prohibitions on uses that would break/violate other par= ts of > the DNS... IMHO, not an implementation detail. :) >=20 >>=20 >> However, I am suggesting that there are or will be business drivers that r= equire some form of agreement between operators in some use cases. >=20 > twas ever thus. >=20 >> I would be surprised if (m)any CDN operators enable this without at least= some form of whitelisting where they'll accept the option from. >=20 > ok - so you believe that EDNS options are negotiable on a pairwise basi= s between > operators on a per zone basis... interesting. No... I think that there will be use cases for both server whitelists and zo= ne whitelists on the recursive side. This says nothing about what I believe about existing EDNS options (or their= cachability) >>=20 From owner-namedroppers@ops.ietf.org Tue Jun 1 19:57:56 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48A1F3A695B; Tue, 1 Jun 2010 19:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=0.996, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHpPSnrn-AcY; Tue, 1 Jun 2010 19:57:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C77713A6946; Tue, 1 Jun 2010 19:57:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJe2l-000M3c-QL for namedroppers-data0@psg.com; Wed, 02 Jun 2010 02:50:59 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJe2h-000M3D-6b for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 02:50:55 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id ADB96EDE70; Wed, 2 Jun 2010 02:50:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o522om7B049085; Wed, 2 Jun 2010 12:50:48 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201006020250.o522om7B049085@drugs.dv.isc.org> To: bmanning@vacation.karoshi.com Cc: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= , namedroppers@ops.ietf.org From: Mark Andrews References: <201005312334.o4VNY3lN099586@drugs.dv.isc.org> <20100601170605.GB4379@vacation.karoshi.com.> Subject: Re: [dnsext] DNS cache design spec In-reply-to: Your message of "Tue, 01 Jun 2010 17:06:05 GMT." <20100601170605.GB4379@vacation.karoshi.com.> Date: Wed, 02 Jun 2010 12:50:48 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <20100601170605.GB4379@vacation.karoshi.com.>, bmanning@vacation.kar oshi.com writes: > On Tue, Jun 01, 2010 at 09:34:03AM +1000, Mark Andrews wrote: > > > > Part of the problem is that caches now go from 1 RRset per name to > > 1 RRset per client. That is a fundamental change in design > > constraints. > > is there an IETF RFC on DNS cache design? It's implict in the design. It the intent was to supply different answers to different clients then there would have been provision for it in RFC 1033, RFC 1034 and RFC 1035. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Jun 1 20:13:46 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6CB28C120; Tue, 1 Jun 2010 20:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZmBQGW+YSCR; Tue, 1 Jun 2010 20:13:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A8F9628C140; Tue, 1 Jun 2010 20:13:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJeKX-000ODF-Ez for namedroppers-data0@psg.com; Wed, 02 Jun 2010 03:09:21 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJeKO-000OCh-N7 for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 03:09:12 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 45A01A3D82; Wed, 2 Jun 2010 03:09:12 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: Andrew Sullivan cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] end-to-end violations in draft-vandergaast-edns-client-ip-01 In-Reply-To: Your message of "Tue, 01 Jun 2010 15:36:11 -0400." <20100601193610.GE48629@shinkuro.com> References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> <20100601193610.GE48629@shinkuro.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Wed, 02 Jun 2010 03:09:12 +0000 Message-ID: <50112.1275448152@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Tue, 1 Jun 2010 15:36:11 -0400 > From: Andrew Sullivan > > > ... a resolving server should not be tampering with the contents of a > > stub's query or the resulting response. This should be common sense. > > What implications, if any, does that common sense have for DNSSEC > validation at intermediate resolvers on behalf of "dumb" stub resolvers? i think what's happening there is upstream validation is failing, so the data can't enter the cache and can't be used to regenerate responses no matter whether to queries that don't ask for validation in their own right. From owner-namedroppers@ops.ietf.org Tue Jun 1 21:56:51 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC19B3A6952; Tue, 1 Jun 2010 21:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.797 X-Spam-Level: **** X-Spam-Status: No, score=4.797 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1, SARE_HEXOCTDWORD=2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyTFV2OWBq0D; Tue, 1 Jun 2010 21:56:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 540F23A694A; Tue, 1 Jun 2010 21:56:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJfur-000A1x-V6 for namedroppers-data0@psg.com; Wed, 02 Jun 2010 04:50:57 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJfup-000A1T-Hu for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 04:50:55 +0000 Received: (qmail 54158 invoked from network); 2 Jun 2010 05:10:07 -0000 Received: from bmdk2141.bmobile.ne.jp (HELO ?203.180.16.141?) (203.180.16.141) by necom830.hpcl.titech.ac.jp with SMTP; 2 Jun 2010 05:10:07 -0000 Message-ID: <4C05E2D1.8090401@necom830.hpcl.titech.ac.jp> Date: Wed, 02 Jun 2010 13:49:21 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Nicholas Weaver CC: Brian Dickson , namedroppers@ops.ietf.org Subject: Re: [dnsext] client-subnet - questions for the authors, and outside-the-box brainstorming References: <4C050022.3000508@necom830.hpcl.titech.ac.jp> <9519475D-FF8B-4820-8E9E-A06792E25535@icsi.berkeley.edu> <4C057447.5000202@necom830.hpcl.titech.ac.jp> <16FFD220-35D2-4AEB-A94A-A210E579D0B1@ICSI.Berkeley.EDU> In-Reply-To: <16FFD220-35D2-4AEB-A94A-A210E579D0B1@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Nicholas Weaver wrote: >> But, the reality is that initial several RTTs are acceptable. > > They are not, because if they were, people would be using > HTTP redirects if they were. They aren't. The reality is that they are, because: >> If initial RTTs were the problem, never use DNS for extra several >> RTTs. Instead, use: >> >> http://273.51.152.23/URL As you can see, such URLs are not used very often. > An HTTP redirect, even excluding the DNS transfer, is uncacheable, > uncached, Cache? As cache is not helpful to reduce latency for the initial query, we have agreed that initial RTTs are not a problem. Or, are you just asking for something impossible? >> If you use "www.yahoo.com", you'll see a lot of "a.l.yimg.com" >> etc. used. >> >> Try it to see the reality of HTTP. > > These are NOT externally visible URLs to the title bar, They are visible at the status bar, which is why I noticed "yimg". > The reality of HTTP is that 302 redirects are a far inferior > solution to minimizing latency compared with the stupid DNS tricks. Though I have been considering 300, feel free to use 302. Or, you may modify HTTP. They are minor implementation issues of HTTP. Anyway, initial RTTs are not a problem, especially because use of open resolvers increases RTTs. Shorter RTTs may be useful for large contents, because shorter RTTs often mean less backbone load. Thus, HTTP redirect just works. Masataka Ohta From owner-namedroppers@ops.ietf.org Wed Jun 2 01:51:36 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653B228C149; Wed, 2 Jun 2010 01:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.636 X-Spam-Level: X-Spam-Status: No, score=0.636 tagged_above=-999 required=5 tests=[AWL=1.131, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuTXY+JEwwL7; Wed, 2 Jun 2010 01:51:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1AD6528C115; Wed, 2 Jun 2010 01:51:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJjYY-000JPp-Cx for namedroppers-data0@psg.com; Wed, 02 Jun 2010 08:44:10 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJjYV-000JOu-8k for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 08:44:07 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id BE6CA154202C; Wed, 2 Jun 2010 09:44:00 +0100 (BST) Cc: namedroppers@ops.ietf.org Message-Id: <5C613FC7-BBF5-4826-AA36-F9D2A2531526@rfc1035.com> From: Jim Reid To: Andrew Sullivan In-Reply-To: <20100601193610.GE48629@shinkuro.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: [dnsext] DNSSEC validation and the end-to-end principle Date: Wed, 2 Jun 2010 09:44:00 +0100 References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> <20100601193610.GE48629@shinkuro.com> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 1 Jun 2010, at 20:36, Andrew Sullivan wrote: > What implications, if any, does that common sense have for DNSSEC > validation at intermediate resolvers on behalf of "dumb" stub > resolvers? Bad Things will happen if/when the stub and intermediate resolvers don't have the same validation policy. Maybe there should be another flag bit to signal to an intermediate resolver whether a query is to get validated or not? And, in keeping with the end-to-end principle, this bit would be preserved when the intermediate resolver forwards the inbound query elsewhere. From owner-namedroppers@ops.ietf.org Wed Jun 2 03:00:09 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640433A6889; Wed, 2 Jun 2010 03:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.55 X-Spam-Level: ** X-Spam-Status: No, score=2.55 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKmHXgTlZf4r; Wed, 2 Jun 2010 03:00:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93C583A67E6; Wed, 2 Jun 2010 03:00:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJkec-0006Ya-7B for namedroppers-data0@psg.com; Wed, 02 Jun 2010 09:54:30 +0000 Received: from [94.198.152.69] (helo=ede1-kamx.sidn.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJkeY-0006XI-Uw for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 09:54:27 +0000 Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id o529sOSU015365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL); Wed, 2 Jun 2010 11:54:24 +0200 Received: from sidn.nl (192.168.2.9) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server id 14.0.694.0; Wed, 2 Jun 2010 11:54:24 +0200 Received: from [192.168.129.3] ([192.168.129.3]) by sidn.nl with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 11:54:24 +0200 Message-ID: <4C062A50.30806@sidn.nl> Date: Wed, 2 Jun 2010 11:54:24 +0200 From: "Marco Davids (SIDN)" Organization: SIDN User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jim Reid CC: Subject: Re: [dnsext] DNSSEC validation and the end-to-end principle References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> <20100601193610.GE48629@shinkuro.com> <5C613FC7-BBF5-4826-AA36-F9D2A2531526@rfc1035.com> In-Reply-To: <5C613FC7-BBF5-4826-AA36-F9D2A2531526@rfc1035.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2010 09:54:24.0347 (UTC) FILETIME=[94D37AB0:01CB0239] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 2010-06-02 10:44, Jim Reid wrote: > On 1 Jun 2010, at 20:36, Andrew Sullivan wrote: > >> What implications, if any, does that common sense have for DNSSEC >> validation at intermediate resolvers on behalf of "dumb" stub >> resolvers? > > Bad Things will happen if/when the stub and intermediate resolvers don't > have the same validation policy. > > Maybe there should be another flag bit to signal to an intermediate > resolver whether a query is to get validated or not? And, in keeping > with the end-to-end principle, this bit would be preserved when the > intermediate resolver forwards the inbound query elsewhere. Isn't the CD bit suppose to take care of this? -- Marco From owner-namedroppers@ops.ietf.org Wed Jun 2 03:21:51 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543143A6993; Wed, 2 Jun 2010 03:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.424 X-Spam-Level: * X-Spam-Status: No, score=1.424 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMbEeUFLCu4k; Wed, 2 Jun 2010 03:21:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F400B3A68D4; Wed, 2 Jun 2010 03:21:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJl1K-000B3J-Di for namedroppers-data0@psg.com; Wed, 02 Jun 2010 10:17:58 +0000 Received: from [195.54.233.65] (helo=hutch.rfc1035.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJl1H-000B2G-90 for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 10:17:55 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 52164154202C; Wed, 2 Jun 2010 11:17:53 +0100 (BST) Cc: Message-Id: <19169BB1-1731-4B47-B5E0-369812A0A371@rfc1035.com> From: Jim Reid To: "Marco Davids (SIDN)" In-Reply-To: <4C062A50.30806@sidn.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [dnsext] DNSSEC validation and the end-to-end principle Date: Wed, 2 Jun 2010 11:17:52 +0100 References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> <20100601193610.GE48629@shinkuro.com> <5C613FC7-BBF5-4826-AA36-F9D2A2531526@rfc1035.com> <4C062A50.30806@sidn.nl> X-Mailer: Apple Mail (2.936) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 2 Jun 2010, at 10:54, Marco Davids (SIDN) wrote: > Isn't the CD bit suppose to take care of this? It does. My earlier comment about an extra bit was before the morning coffee had kicked in to refresh my recollection of RFC4035. Apologies. From owner-namedroppers@ops.ietf.org Wed Jun 2 03:51:13 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D563A69B5; Wed, 2 Jun 2010 03:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.701 X-Spam-Level: ** X-Spam-Status: No, score=2.701 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjJnNTR9Zt5a; Wed, 2 Jun 2010 03:51:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 60A0F3A69A5; Wed, 2 Jun 2010 03:51:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJlSY-000GbZ-Bo for namedroppers-data0@psg.com; Wed, 02 Jun 2010 10:46:06 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJlSV-000Gak-AY for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 10:46:03 +0000 Received: (qmail 74900 invoked from network); 2 Jun 2010 11:05:42 -0000 Received: from bmdi3239.bmobile.ne.jp (HELO ?202.221.175.239?) (202.221.175.239) by necom830.hpcl.titech.ac.jp with SMTP; 2 Jun 2010 11:05:42 -0000 Message-ID: <4C06362E.2010602@necom830.hpcl.titech.ac.jp> Date: Wed, 02 Jun 2010 19:45:02 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jim Reid CC: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] DNSSEC validation and the lack of the end-to-end principle References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> <20100601193610.GE48629@shinkuro.com> <5C613FC7-BBF5-4826-AA36-F9D2A2531526@rfc1035.com> In-Reply-To: <5C613FC7-BBF5-4826-AA36-F9D2A2531526@rfc1035.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Jim Reid wrote: > On 1 Jun 2010, at 20:36, Andrew Sullivan wrote: > >> What implications, if any, does that common sense have for DNSSEC >> validation at intermediate resolvers on behalf of "dumb" stub >> resolvers? > > Bad Things will happen if/when the stub and intermediate resolvers As the DNS, including DNSSEC, is not end to end because of intermediate name servers and zones, addition of resolvers does not recover it. According to the end to end argument by Saltzer et. al., the intermediat name servers makes DNS incomplete and incorrect, which is, for example, why DNS RRs are not always up to date. Masataka Ohta From interpretationsllb4@rgbsys.com Wed Jun 2 05:02:32 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72CC28C16D; Wed, 2 Jun 2010 05:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -37.534 X-Spam-Level: X-Spam-Status: No, score=-37.534 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_CZ=0.445, HOST_EQ_BROADBND=1.118, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTMubbt6LPgQ; Wed, 2 Jun 2010 05:02:27 -0700 (PDT) Received: from 56.56.broadband7.iol.cz (56.56.broadband7.iol.cz [88.102.56.56]) by core3.amsl.com (Postfix) with ESMTP id 5E31F28C167; Wed, 2 Jun 2010 05:02:26 -0700 (PDT) Received: from 88.102.56.56 by rgbsys.com; Wed, 2 Jun 2010 14:01:54 +0100 Message-ID: <000d01cb024b$64c8b8f0$6400a8c0@interpretationsllb4> From: "American Express" To: Subject: official information Date: Wed, 2 Jun 2010 14:01:54 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CB024B.64C8B8F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CB024B.64C8B8F0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 Dear American Express customer, A newly revised American Express Online Form has been issued by the America= n Express Customer Care Team. Please complete this form as soon as possible= You can access the form at:American Express Online Form=2E Thank you for choosing American Express=2E Sincerely, American Express To learn more about e-mail security or report a suspicious e-mail, visit us= at americanexpress.com/phishing. We are unable to answer replies to this e= -mail=2E Copyright 2010 American Express Company. All rights reserved=2E ------=_NextPart_000_0007_01CB024B.64C8B8F0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable





















Dear American Express = customer,

A newly revised American Express Online Form has been issued by the America= n Express Customer Care Team. Please complete this form as soon as possible= You can access the form at:

American Express Online Form.

Thank you for choosing American Express.

Sincerely,
American Express



















To learn more about e-mail security or report a suspicious e-mail, vis= it us at american= express.com/phishing. We are unable to answer replies to this e-mail.
Copyright 2010 American Express Company. All rights reserved.
------=_NextPart_000_0007_01CB024B.64C8B8F0-- From owner-namedroppers@ops.ietf.org Wed Jun 2 07:36:22 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1BFE3A6839; Wed, 2 Jun 2010 07:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.273 X-Spam-Level: X-Spam-Status: No, score=-97.273 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJWHJ0vtOzOm; Wed, 2 Jun 2010 07:36:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A5AA93A6827; Wed, 2 Jun 2010 07:36:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJoxo-0009hb-Mz for namedroppers-data0@psg.com; Wed, 02 Jun 2010 14:30:36 +0000 Received: from [74.125.121.35] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJoxg-0009dh-Kz for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 14:30:29 +0000 Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o52EUQ0r017300 for ; Wed, 2 Jun 2010 07:30:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275489026; bh=Qq3+ysU5hrpkeBEyO2YWanVBeEU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ZgXEmAqFVJY+n0PrHR9UpjGnkjJiwTw6hJMw4haCLeyAIrTOTKS8Qhlit6fjb44HR jCZtxaYY6mu8fMkSKwbBQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=PeFqwoYR2gxEAcakZXu3GZry3dK+20l3hCZnSuqqFdcjkQ14ksQWFIdnTf7ntnOVE WPEh/8oQn6kA7ito9PDKA== Received: from ewy9 (ewy9.prod.google.com [10.241.103.9]) by wpaz21.hot.corp.google.com with ESMTP id o52EUOYL010652 for ; Wed, 2 Jun 2010 07:30:25 -0700 Received: by ewy9 with SMTP id 9so1655126ewy.4 for ; Wed, 02 Jun 2010 07:30:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.113.208 with SMTP id b16mr5250017ebq.3.1275489024172; Wed, 02 Jun 2010 07:30:24 -0700 (PDT) Received: by 10.213.14.12 with HTTP; Wed, 2 Jun 2010 07:30:24 -0700 (PDT) In-Reply-To: References: <421400056AC3A68D057ED565@nimrod.local> <8D6F3C331BDC4FAFF237C0BA@nimrod.local> Date: Wed, 2 Jun 2010 15:30:24 +0100 Message-ID: Subject: Re: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) From: Wilmer van der Gaast To: Alex Bligh Cc: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: 2010/6/1 Alex Bligh : > > Possibly - I read the latest draft far less thoroughly than I did > the first one. However, the main thing I don't like is that the > option originates at the client. We wouldn't like that either. :-) We also plan to have the resolver add the option. Sadly the first version of the draft failed to be very clear about it. An early version of the draft didn't take transitiveness into account, and when we added awareness of that later, things became too complicated. This is one of the parts of the doc that has been rewritten for -01, see section 4.1 ("Originating the option"). Yesterday, I put a summary in more specific non-RFC language on the mailing list as well, let me quote it here: """ In very specific language, this is how we intend the option to be used: * A recursive resolver (often an open resolver, or possibly a resolver run by an ISP with more peering points than DNS resolver pools) adds the option to requests. It *can* add it to all requests, but preferably it keeps track of authorities that support the option and send it only to them, to improve performance and slightly improve privacy. Another option is that the resolver admin keeps a list of edns-client-subnet-enabled authorities by him/herself. Since the option will only benefit a small number of large CDNs, this list is not likely to grow a lot. * Users who for one reason or the other don't want any of their address information to be added to requests, and know that their resolver supports edns-client-subnet, can add the option with a 0/0 address. A compliant edns-client-subnet resolver will respect this. A resolver that doesn't support edns-client-subnet will just ignore it. If a resolver somewhere in between is ignorant of the option, it gets stripped. The edns-client-subnet-enabled resolver later on will add it again - but not with the user's address, since that address is already invisible. * Not really one of the goals of the option, but: if the user knows the subsequent connection to the address received from the DNS will use a different route than the DNS request itself, the option allows for possibly better results from the CDN. """ >From how I read your proposal, we're mostly on the same page. We have thought of putting other pieces of information besides/instead of IP addresses in the option, but decided to stick with just IP addresses, since that's the only information the resolver has - sure it can convert the IP address to an things like AS# or coordinates, but in our opinion it's better to do that work on the CDN side if it wants to do so. IMHO getting a /24 is much more useful than anything else since the CDN knows better what its network/peering looks like than the resolver. Having an ASN is nice, but it usually won't tell me, for example, if the client is on the East Coast or the West Coast Comcast network. Regards, -- Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From owner-namedroppers@ops.ietf.org Wed Jun 2 08:08:31 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E4B28C113; Wed, 2 Jun 2010 08:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.273 X-Spam-Level: X-Spam-Status: No, score=-97.273 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yui58-IWgaC; Wed, 2 Jun 2010 08:08:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 99F1428C117; Wed, 2 Jun 2010 08:08:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJpTC-000G4y-Fv for namedroppers-data0@psg.com; Wed, 02 Jun 2010 15:03:02 +0000 Received: from [74.125.121.35] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJpT6-000G44-Jt for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 15:02:59 +0000 Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id o52F2sdM029325 for ; Wed, 2 Jun 2010 08:02:54 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275490975; bh=I4L8hC81Nap1egp8NylMysgEIuU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Ljy+LNTSyVz7CoQsTWvWnkQRGd+eOX9YZQPmV9u8WHZMNTL2rcqz/E/8D+4zlFWok lHfcSABt/ugRWBk+op8RA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=m27UbamZSnokt7JM3aqZUiyjbMSdY0qxZFVlZNdVxdrdcpak/BF0RoxsbMlO7s1t+ wqSaDAilMNtcSfXx5ZsTQ== Received: from ewy24 (ewy24.prod.google.com [10.241.103.24]) by hpaq11.eem.corp.google.com with ESMTP id o52F2qd2020889 for ; Wed, 2 Jun 2010 08:02:53 -0700 Received: by ewy24 with SMTP id 24so1713054ewy.34 for ; Wed, 02 Jun 2010 08:02:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.35.72 with SMTP id o8mr5046098ebd.51.1275490972181; Wed, 02 Jun 2010 08:02:52 -0700 (PDT) Received: by 10.213.14.12 with HTTP; Wed, 2 Jun 2010 08:02:51 -0700 (PDT) In-Reply-To: <20100601204111.GA5952@vacation.karoshi.com.> References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <20100601173827.GC4379@vacation.karoshi.com.> <73C2798F-A399-46A5-8B31-FE7C044676C2@sackheads.org> <20100601204111.GA5952@vacation.karoshi.com.> Date: Wed, 2 Jun 2010 16:02:52 +0100 Message-ID: Subject: Re: [dnsext] latency From: Wilmer van der Gaast To: bmanning@vacation.karoshi.com Cc: John Payne , Bruce Campbell , "sthaug@nethelp.no" , "namedroppers@ops.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 1 June 2010 21:41, wrote: > > =A0 =A0 =A0 =A0perhaps ... =A0TSIG and SIG(0) are server/server not zone/= zone > =A0 =A0 =A0 =A0and DNSSEC is on a per-zone basis, not server/server or ev= en RRset/RRset. > =A0 =A0 =A0 =A0So I don't see this as an "implementation detail" or "loca= l policy"... > > =A0 =A0 =A0 =A0Something like this has to be -CLEARLY- specified as to it= s intended/expected > =A0 =A0 =A0 =A0use and mapping prohibitions on uses that would break/viol= ate other parts of > =A0 =A0 =A0 =A0the DNS... IMHO, not an implementation detail. :) > This is an interesting point, actually. If there's going to be some automatic negotiation, all parties have to do this the same way. Say, we have an authority configured to handle edns-client-subnet options for zone A but not for zone B, and returns responses with absolutely no edns-client-subnet option for queries to zone B. And, we have a RR/INS that keeps a list of servers that support edns-client-subnet. If the first query between these servers is going to be for zone B, the RR/INS won't even try sending an edns-client option with a query for zone A. It seems best to me to make the negotiation per-server, not per-zone, so if an authority has at least one zone that uses edns-client-subnet info, it should return the option for all queries, with a 0/0 address for the other zones. We'll make sure to include this in the next version of the draft. Regards, --=20 Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From owner-namedroppers@ops.ietf.org Wed Jun 2 08:21:13 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257C63A69EA; Wed, 2 Jun 2010 08:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.973 X-Spam-Level: X-Spam-Status: No, score=-96.973 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZ4yzJsbVPfA; Wed, 2 Jun 2010 08:21:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EDCEF3A693F; Wed, 2 Jun 2010 08:21:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJpgV-000IsY-Qu for namedroppers-data0@psg.com; Wed, 02 Jun 2010 15:16:47 +0000 Received: from [74.125.121.35] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJpgR-000IrV-4J for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 15:16:43 +0000 Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o52FGfoM010971 for ; Wed, 2 Jun 2010 08:16:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275491801; bh=pq6hrDvTW85Y3AeUhGZvDgFLsfM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Bq2lhvkUbE/2JOffg5VI6S5MgDzNKBxKM5GKYrx93pCxYZ6pFRvXJjjrTIPxy59uA R6qEAYPlmLMZMPtS5kzjw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=x0SZ00PToUfR6yXBcKRIaT7OZTg9O/3jPtB+/4RooJ/+tSvBO/X8xfD744WirR/f8 laruKAwbZ3rWszaRntjVA== Received: from ey-out-1920.google.com (eyh3.prod.google.com [10.208.8.3]) by hpaq7.eem.corp.google.com with ESMTP id o52FGeqU007368 for ; Wed, 2 Jun 2010 08:16:40 -0700 Received: by ey-out-1920.google.com with SMTP id 3so551eyh.50 for ; Wed, 02 Jun 2010 08:16:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.109.6 with SMTP id h6mr2976650ebp.57.1275491800084; Wed, 02 Jun 2010 08:16:40 -0700 (PDT) Received: by 10.213.14.12 with HTTP; Wed, 2 Jun 2010 08:16:39 -0700 (PDT) In-Reply-To: References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> Date: Wed, 2 Jun 2010 16:16:39 +0100 Message-ID: Subject: Re: [dnsext] latency From: Wilmer van der Gaast To: Bruce Campbell Cc: sthaug@nethelp.no, namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 31 May 2010 16:52, Bruce Campbell wrote: >> A latency difference of 200 or 300ms doesn't really matter by itself. >> The problem is web pages which result in *many* DNS queries and thus >> latency difference * N. > Most web browsers seem to look up domain names en-mass and incur max(latency > difference) or latency difference * number of concurrent queries, rather > than one-by-one and thus latency difference * N. > I'd say difference * 2. It can't immediately do all lookups. It'll have to start downloading the HTML before it will have any clue what other names it's going to have to resolve. > As a corporate admin, I'd hate to have details of my internal > infrastructure walking out along with the DNS queries, Which details? If you're running a small corporate network and are just using the resolver run by the ISP or maybe a third party one. If the resolver adds an edns-client-subnet option, it will just contain the /24 that contains your external IP address (range). If you're running a bigger network, you're probably running your own local nameserver already, and there's no need to enable edns-client-subnet support on it since CDNs will already have enough information to serve you. Regards, -- Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From owner-namedroppers@ops.ietf.org Wed Jun 2 08:29:58 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2233A69E7; Wed, 2 Jun 2010 08:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.107 X-Spam-Level: *** X-Spam-Status: No, score=3.107 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1, SARE_HEXOCTDWORD=2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV2iSqz6uqP2; Wed, 2 Jun 2010 08:29:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AB6873A6874; Wed, 2 Jun 2010 08:29:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJpqA-000KTX-ML for namedroppers-data0@psg.com; Wed, 02 Jun 2010 15:26:46 +0000 Received: from [209.85.160.180] (helo=mail-gy0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJpq7-000KSq-HM for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 15:26:43 +0000 Received: by gyb13 with SMTP id 13so6316655gyb.11 for ; Wed, 02 Jun 2010 08:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=bprHnIkwJi1TpZGOX0QNts6+EStf5Jr0LpJbIq0PStA=; b=v3v6jw321gVOOrbTGd2BJK06Un65mq/5xuTRN/B8/vsi1i1sDv1w2Oi9fEwvpJkJB9 4d4faiXF5h8HigrrzC8nX6yHHKFFWuwUnszaw1mA3NYHthtX4IDx7JDj5xrKgcerHEtu npUzl5HYrun/daJ4/E2c8IcuSCxcsUbQ7+Ujo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=O+NKW09/p58dE+p0SVFfzc4moGGWVvmGsoPl89tVX7CMf7u/RVRfO8CJ9kCK9yrYQD pL060VGDUt6FWd682v6Asx72nI0mVvYlsml1RkTlsPuXnoRhy5MF66wBhUUOVIOGaOhy 6pPo4yyBbNku/SI0tU4d5IMwSkMdW22BJJ4Rc= MIME-Version: 1.0 Received: by 10.101.11.29 with SMTP id o29mr8845133ani.64.1275492402450; Wed, 02 Jun 2010 08:26:42 -0700 (PDT) Received: by 10.100.8.14 with HTTP; Wed, 2 Jun 2010 08:26:42 -0700 (PDT) Date: Wed, 2 Jun 2010 12:26:42 -0300 Message-ID: Subject: HTTP redirect (was Re: [dnsext] client-subnet - questions for the authors, and outside-the-box brainstorming) From: Brian Dickson To: Masataka Ohta Cc: Nicholas Weaver , namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=0016e68ea0708fd2d704880db785 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016e68ea0708fd2d704880db785 Content-Type: text/plain; charset=ISO-8859-1 (Guys - please don't hijack other peoples threads, i.e. discussing tangential issues without changing the Subject: line) 2010/6/2 Masataka Ohta > Nicholas Weaver wrote: > > >> But, the reality is that initial several RTTs are acceptable. > > > > They are not, because if they were, people would be using > > HTTP redirects if they were. They aren't. > > The reality is that they are, because: > > >> If initial RTTs were the problem, never use DNS for extra several > >> RTTs. Instead, use: > >> > >> http://273.51.152.23/URL > > As you can see, such URLs are not used very often. > > > An HTTP redirect, even excluding the DNS transfer, is uncacheable, > > uncached, > > Cache? > > As cache is not helpful to reduce latency for the initial query, > we have agreed that initial RTTs are not a problem. > > Or, are you just asking for something impossible? > > >> If you use "www.yahoo.com", you'll see a lot of "a.l.yimg.com" > >> etc. used. > >> > >> Try it to see the reality of HTTP. > > > > These are NOT externally visible URLs to the title bar, > > They are visible at the status bar, which is why I noticed "yimg". > > > The reality of HTTP is that 302 redirects are a far inferior > > solution to minimizing latency compared with the stupid DNS tricks. > > Though I have been considering 300, feel free to use 302. Or, you > may modify HTTP. They are minor implementation issues of HTTP. > > Anyway, initial RTTs are not a problem, especially because use of > open resolvers increases RTTs. > > Shorter RTTs may be useful for large contents, because shorter RTTs > often mean less backbone load. > > Thus, HTTP redirect just works. > > Masataka Ohta > --0016e68ea0708fd2d704880db785 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (Guys - please don't hijack other peoples threads, i.e. discussing tang= ential issues without changing the Subject: line)

2010/6/2 Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Nicholas Weaver wrote:

>> But, the reality is that initial several RTTs are acceptable.
>
> They are not, because if they were, people would be using
> HTTP redirects if they were. =A0They aren't.

The reality is that they are, because:

>> If initial RTTs were the problem, never use DNS for extra several<= br> >> RTTs. Instead, use:
>>
>> =A0 =A0 =A0= http://273.51.152.23/URL

As you can see, such URLs are not used very often.

> An HTTP redirect, even excluding the DNS transfer, is uncacheable,
> uncached,

Cache?

As cache is not helpful to reduce latency for the initial query,
we have agreed that initial RTTs are not a problem.

Or, are you just asking for something impossible?

>> If you use "www.yahoo.com", you'll see a lot of "a.l.yimg.com"
>> etc. used.
>>
>> Try it to see the reality of HTTP.
>
> These are NOT externally visible URLs to the title bar,

They are visible at the status bar, which is why I noticed "yimg= ".

> The reality of HTTP is that 302 redirects are a far inferior
> solution to minimizing latency compared with the stupid DNS tricks.
Though I have been considering 300, feel free to use 302. Or, you
may modify HTTP. They are minor implementation issues of HTTP.

Anyway, initial RTTs are not a problem, especially because use of
open resolvers increases RTTs.

Shorter RTTs may be useful for large contents, because shorter RTTs
often mean less backbone load.

Thus, HTTP redirect just works.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0Masataka Ohta

--0016e68ea0708fd2d704880db785-- From owner-namedroppers@ops.ietf.org Wed Jun 2 08:38:31 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADFC028C135; Wed, 2 Jun 2010 08:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.814 X-Spam-Level: ** X-Spam-Status: No, score=2.814 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+D5VxCHPU8y; Wed, 2 Jun 2010 08:38:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2C94128C0E2; Wed, 2 Jun 2010 08:38:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJpxI-000LvB-FB for namedroppers-data0@psg.com; Wed, 02 Jun 2010 15:34:08 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJpxA-000Lt7-1v for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 15:34:00 +0000 Received: from [10.71.0.51] (unknown [69.38.231.138]) by mail.avalus.com (Postfix) with ESMTPSA id F39C2C56901; Wed, 2 Jun 2010 16:33:57 +0100 (BST) Date: Wed, 02 Jun 2010 11:33:55 -0400 From: Alex Bligh Reply-To: Alex Bligh To: Wilmer van der Gaast cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) Message-ID: In-Reply-To: References: <421400056AC3A68D057ED565@nimrod.local> <8D6F3C331BDC4FAFF237C0BA@nimrod.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Wilmer, --On 2 June 2010 15:30:24 +0100 Wilmer van der Gaast wrote: > * A recursive resolver (often an open resolver, or possibly a resolver > run by an ISP with more peering points than DNS resolver pools) adds > the option to requests. It *can* add it to all requests, but > preferably it keeps track of authorities that support the option and > send it only to them, to improve performance and slightly improve > privacy. My argument is that in order to avoid increasing load to most of the rest of the world, a recursive server using the option MUST keep a negative cache of those upstream servers who don't understand it, and not send packets with this option to them in future. Irrespective of the load argument, negative caching is only sensible as inevitably there will be authoritative servers that will choke on this option (e.g. if they are behind a firewall that drops packets with unknown EDNS options). This means that a reply to a query with the option has to signal that the option is understood. > Another option is that the resolver admin keeps a list of > edns-client-subnet-enabled authorities by him/herself. Since the > option will only benefit a small number of large CDNs, this list is > not likely to grow a lot. This is in essence a manual whitelist. It risks suffering O(n^2) problems and causes entry problems for new CDNs. I don't like this, and it's unnecessary since you can easily signal the option is understood. > * Users who for one reason or the other don't want any of their > address information to be added to requests, and know that their > resolver supports edns-client-subnet, can add the option with a 0/0 > address. A compliant edns-client-subnet resolver will respect this. A > resolver that doesn't support edns-client-subnet will just ignore it. > If a resolver somewhere in between is ignorant of the option, it gets > stripped. The edns-client-subnet-enabled resolver later on will add it > again - but not with the user's address, since that address is already > invisible. The current way you have implemented this if I read it right is that the client can specify any IP address it wants. Given NATs, user stupidity etc., this is highly prone to error. Personally I think trying to encode privacy concerns into the DNS protocol (as opposed to open resolver terms and conditions) is a complete waste of time, not least as the very next connection is very likely to be an http request to the same CDN. But even if you made it a separate configurable packet, configuring it necessarily involves some knob on the client reconfiguring DNS, which is bad. A far easier solution for those concerned about privacy is for the open resolver just to offer a different set of IPs which respect the privacy setting (or tell users concerned about this aspect of privacy to go elsewhere, which is what I would do). > IMHO getting a /24 is much more useful than anything else since the > CDN knows better what its network/peering looks like than the > resolver. Having an ASN is nice, but it usually won't tell me, for > example, if the client is on the East Coast or the West Coast Comcast > network. Sure. I just thought there was all sorts of dross one might want to specify: ASN, coordinates, language, whatever. I was trying to sweep them all up into the same somewhat stinky pile. Not a major concern. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Jun 2 09:03:40 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B4503A6A0C; Wed, 2 Jun 2010 09:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_50=0.001, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgeiROSXYYBc; Wed, 2 Jun 2010 09:03:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3DF953A6A13; Wed, 2 Jun 2010 09:03:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJqLt-0001jR-TE for namedroppers-data0@psg.com; Wed, 02 Jun 2010 15:59:33 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJqLq-0001hc-OX for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 15:59:31 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o52Fx1rB015430; Wed, 2 Jun 2010 08:59:01 -0700 (PDT) References: <421400056AC3A68D057ED565@nimrod.local> <8D6F3C331BDC4FAFF237C0BA@nimrod.local> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , Wilmer van der Gaast , =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= , namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) Date: Wed, 2 Jun 2010 08:59:01 -0700 To: Alex Bligh X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 2, 2010, at 8:33 AM, Alex Bligh wrote: >> * Users who for one reason or the other don't want any of their >> address information to be added to requests, and know that their >> resolver supports edns-client-subnet, can add the option with a 0/0 >> address. A compliant edns-client-subnet resolver will respect this. A >> resolver that doesn't support edns-client-subnet will just ignore it. >> If a resolver somewhere in between is ignorant of the option, it gets >> stripped. The edns-client-subnet-enabled resolver later on will add = it >> again - but not with the user's address, since that address is = already >> invisible. >=20 > The current way you have implemented this if I read it right is that > the client can specify any IP address it wants. Given NATs, user > stupidity etc., this is highly prone to error. Personally I think > trying to encode privacy concerns into the DNS protocol (as opposed > to open resolver terms and conditions) is a complete waste of time, > not least as the very next connection is very likely to be an > http request to the same CDN. But even if you made it a separate > configurable packet, configuring it necessarily involves some knob > on the client reconfiguring DNS, which is bad. A far easier solution > for those concerned about privacy is for the open resolver just to > offer a different set of IPs which respect the privacy setting > (or tell users concerned about this aspect of privacy to go > elsewhere, which is what I would do). On one hand, I agree: 'go elsewhere' is a better solution, especially = since those using third party resolver services have already agreed to = spew all this privacy sensitive information to the third party. OTOH, I don't think errors are that bad. Remember, ALL answers returned = by the authority are valid answers, just not necessarily OPTIMAL = answers. If a user misconfiguration, user stupidity, etc results in a = few seconds more latency on page load, its the user's problem. >> IMHO getting a /24 is much more useful than anything else since the >> CDN knows better what its network/peering looks like than the >> resolver. Having an ASN is nice, but it usually won't tell me, for >> example, if the client is on the East Coast or the West Coast Comcast >> network. >=20 > Sure. I just thought there was all sorts of dross one might want to > specify: ASN, coordinates, language, whatever. I was trying to sweep > them all up into the same somewhat stinky pile. Not a major concern. /24 is special, however, and why I personally like this proposal: = Subnet (albeit on a slightly coarser granularity) is leaked already by = normal resolvers, and this should only matter to third-party resolvers, = while other data might matter for ALL resolvers. From owner-namedroppers@ops.ietf.org Wed Jun 2 09:15:44 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF3D628C0D7; Wed, 2 Jun 2010 09:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJiQEk0QCPeQ; Wed, 2 Jun 2010 09:15:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F5143A63C9; Wed, 2 Jun 2010 09:15:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJqWs-00042E-4x for namedroppers-data0@psg.com; Wed, 02 Jun 2010 16:10:54 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJqWo-00040X-7d for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 16:10:50 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o52GASYe017432; Wed, 2 Jun 2010 09:10:28 -0700 (PDT) References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: [dnsext] latency Date: Wed, 2 Jun 2010 09:10:28 -0700 To: Wilmer van der Gaast X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 2, 2010, at 8:16 AM, Wilmer van der Gaast wrote: > On 31 May 2010 16:52, Bruce Campbell = wrote: >>> A latency difference of 200 or 300ms doesn't really matter by = itself. >>> The problem is web pages which result in *many* DNS queries and thus >>> latency difference * N. >> Most web browsers seem to look up domain names en-mass and incur = max(latency >> difference) or latency difference * number of concurrent queries, = rather >> than one-by-one and thus latency difference * N. >>=20 > I'd say difference * 2. >=20 > It can't immediately do all lookups. It'll have to start downloading > the HTML before it will have any clue what other names it's going to > have to resolve. And remember, this does NOT affect the latency of DNS lookups (although = it may add an additional lookup if the reply specifies too narrow a = subnet). =20 Rather, it affects the latency to the resulting server, which is = critical for HTTP. Lets actually look at the example of www.yahoo.com: The total # of items fetched is 77, from 9 domains total. Most (51) are from l.yimg.com, so lets focus on that: The browser (firefox, mac) opens six TCP streams to l.yimg.com, but = because the browser doesn't pipeline, it has to wait for each element to = be received before the next one is fetched. Thus fetching those 51 = images requires at least 9 RTTs to the server. (For a typical = connection in this flow, replies are 1-2 packets, so the TCP windowing = doesn't come into effect, and I'm on a 100 Mbps connection here) Thus it is critical that the IP address of the server be at least on the = right part of the correct continent, as if the DNS authority for = l.yimg.com gave me an east-coast server, the latency would be increased = by at least 100ms, adding in at least 1s to page load time. And this is yet another example of how HTTP redirects don't work: There = is no way to say 'fetch all requests for l.yimg.com from = a2354.l.yimg.com' with an HTTP redirect, so doing redirects wouldn't = help here: you'd still take the latency hit FOR EACH REQUEST to = l.yimg.com. Rather, what would have to happen to see the latency savings without the = DNS games is the web page itself would need to be dynamically generated = and customized for my IP address, replacing every reference to = l.yimg.com with a reference to something like a2354.l.yimg.com. From owner-namedroppers@ops.ietf.org Wed Jun 2 09:24:20 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857CB28C0F6; Wed, 2 Jun 2010 09:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.672 X-Spam-Level: ** X-Spam-Status: No, score=2.672 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhUmP4vMXmEX; Wed, 2 Jun 2010 09:24:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9728928C113; Wed, 2 Jun 2010 09:24:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJqgY-0005rh-Fi for namedroppers-data0@psg.com; Wed, 02 Jun 2010 16:20:54 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJqgV-0005qu-4o for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 16:20:51 +0000 Received: from [10.71.0.51] (unknown [69.38.231.138]) by mail.avalus.com (Postfix) with ESMTPSA id 02EA0C56905; Wed, 2 Jun 2010 17:20:43 +0100 (BST) Date: Wed, 02 Jun 2010 12:20:40 -0400 From: Alex Bligh Reply-To: Alex Bligh To: Nicholas Weaver cc: Nicholas Weaver , Wilmer van der Gaast , =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) Message-ID: <38CC48E5755A3CCF0595D109@nimrod.local> In-Reply-To: References: <421400056AC3A68D057ED565@nimrod.local> <8D6F3C331BDC4FAFF237C0BA@nimrod.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 2 June 2010 08:59:01 -0700 Nicholas Weaver wrote: > On one hand, I agree: 'go elsewhere' is a better solution, especially > since those using third party resolver services have already agreed to > spew all this privacy sensitive information to the third party. > > OTOH, I don't think errors are that bad. Remember, ALL answers returned > by the authority are valid answers, just not necessarily OPTIMAL answers. > If a user misconfiguration, user stupidity, etc results in a few seconds > more latency on page load, its the user's problem. If by errors you mean non-optimal answers, I am not concerned about such errors at all; it can be no worse than the current situation. I am concerned about the proposal's large footprint. Specifically, I am concerned about introducing a complexity into the stub<->recursive path (which risks hitting all recursive servers and is more fragile due to middleboxen on the way), when for near zero loss of functionality, disruption could be limited to the recursive<->authoritative path and (with negative caching) absolutely minimally impact any authoritative servers who don't use the information. Currently the proposal risks collateral damage whereas it need not - it could be essentially private to those who need it. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Jun 2 09:30:31 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98E328C0F7; Wed, 2 Jun 2010 09:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_50=0.001, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVayTlC4Ehx8; Wed, 2 Jun 2010 09:30:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A02E428C177; Wed, 2 Jun 2010 09:30:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJqlf-0006eQ-Nw for namedroppers-data0@psg.com; Wed, 02 Jun 2010 16:26:11 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJqlV-0006dY-Sd for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 16:26:02 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o52GPfoA019913; Wed, 2 Jun 2010 09:25:41 -0700 (PDT) References: <421400056AC3A68D057ED565@nimrod.local> <8D6F3C331BDC4FAFF237C0BA@nimrod.local> <38CC48E5755A3CCF0595D109@nimrod.local> In-Reply-To: <38CC48E5755A3CCF0595D109@nimrod.local> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <349259E6-76F2-4281-8CDB-330C4EA24DCB@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , Wilmer van der Gaast , =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= , namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) Date: Wed, 2 Jun 2010 09:25:41 -0700 To: Alex Bligh X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 2, 2010, at 9:20 AM, Alex Bligh wrote: >=20 >=20 > --On 2 June 2010 08:59:01 -0700 Nicholas Weaver = wrote: >=20 >> On one hand, I agree: 'go elsewhere' is a better solution, = especially >> since those using third party resolver services have already agreed = to >> spew all this privacy sensitive information to the third party. >>=20 >> OTOH, I don't think errors are that bad. Remember, ALL answers = returned >> by the authority are valid answers, just not necessarily OPTIMAL = answers. >> If a user misconfiguration, user stupidity, etc results in a few = seconds >> more latency on page load, its the user's problem. >=20 > If by errors you mean non-optimal answers, I am not concerned about = such > errors at all; it can be no worse than the current situation. I am > concerned about the proposal's large footprint. Specifically, I am > concerned about introducing a complexity into the stub<->recursive = path > (which risks hitting all recursive servers and is more fragile due to > middleboxen on the way), when for near zero loss of functionality, > disruption could be limited to the recursive<->authoritative path and = (with > negative caching) absolutely minimally impact any authoritative = servers who > don't use the information. Currently the proposal risks collateral = damage > whereas it need not - it could be essentially private to those who = need it. Here's the problem: On one hand, I agree with you. OTOH, there are several vocal people who insist that if the client = desires it, the resolver does not use the client-subnet option in a way = which leaks information, which requires that the client, in such cases, = be able to say "don't use the option", which of course stresses all them = broken middleboxes... (1.4% or so of Netalyzr tests, for example, are behind middleboxes that = block EDNS0) From owner-namedroppers@ops.ietf.org Wed Jun 2 09:35:27 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07F983A69B0; Wed, 2 Jun 2010 09:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.207 X-Spam-Level: ** X-Spam-Status: No, score=2.207 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71Xf-5-lHk8Q; Wed, 2 Jun 2010 09:35:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD5DE3A68FC; Wed, 2 Jun 2010 09:35:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJqqq-0007YP-Fn for namedroppers-data0@psg.com; Wed, 02 Jun 2010 16:31:32 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJqqo-0007XV-2T for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 16:31:30 +0000 Received: from [10.71.0.51] (unknown [69.38.231.138]) by mail.avalus.com (Postfix) with ESMTPSA id 70B9BC56907; Wed, 2 Jun 2010 17:31:27 +0100 (BST) Date: Wed, 02 Jun 2010 12:31:25 -0400 From: Alex Bligh Reply-To: Alex Bligh To: Nicholas Weaver cc: Nicholas Weaver , Wilmer van der Gaast , =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) Message-ID: <0E746C79455D4799DF1A51DC@nimrod.local> In-Reply-To: <349259E6-76F2-4281-8CDB-330C4EA24DCB@ICSI.Berkeley.EDU> References: <421400056AC3A68D057ED565@nimrod.local> <8D6F3C331BDC4FAFF237C0BA@nimrod.local> <38CC48E5755A3CCF0595D109@nimrod.local> <349259E6-76F2-4281-8CDB-330C4EA24DCB@ICSI.Berkeley.EDU> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 2 June 2010 09:25:41 -0700 Nicholas Weaver wrote: > Here's the problem: On one hand, I agree with you. > > OTOH, there are several vocal people who insist that if the client > desires it, the resolver does not use the client-subnet option Well, people being vocal does not mean they are right! But... > which requires that the client, in such cases, be able to say "don't use > the option", which of course stresses all them broken middleboxes... Nope - there are other ways to do this, which are actually SIMPLER for the client (i.e. do not require an OS change). The most obvious is simply to use different set of IP addresses for the resolving servers for those concerned about privacy. Yes, a given open resolver might choose not to do this, but then they might also choose not to respect incoming EDNS0 options (despite the standard), to sell all their data to $evilempire or whatever. Moreover, didn't we find middleboxes that (by proxying DNS or otherwise) strip unknown EDNS0 options? In which case the option doesn't guarantee DNS privacy anyway. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Jun 2 09:37:15 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CEDC28C156; Wed, 2 Jun 2010 09:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.912 X-Spam-Level: X-Spam-Status: No, score=-3.912 tagged_above=-999 required=5 tests=[AWL=1.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFXoD8a4LDFi; Wed, 2 Jun 2010 09:37:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 361B428C12D; Wed, 2 Jun 2010 09:37:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJqso-0007vb-1a for namedroppers-data0@psg.com; Wed, 02 Jun 2010 16:33:34 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJqsl-0007um-Bw for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 16:33:31 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o52GXKiD021310; Wed, 2 Jun 2010 09:33:20 -0700 (PDT) References: <421400056AC3A68D057ED565@nimrod.local> <8D6F3C331BDC4FAFF237C0BA@nimrod.local> <38CC48E5755A3CCF0595D109@nimrod.local> <349259E6-76F2-4281-8CDB-330C4EA24DCB@ICSI.Berkeley.EDU> <0E746C79455D4799DF1A51DC@nimrod.local> In-Reply-To: <0E746C79455D4799DF1A51DC@nimrod.local> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , Wilmer van der Gaast , =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= , namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) Date: Wed, 2 Jun 2010 09:33:20 -0700 To: Alex Bligh X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 2, 2010, at 9:31 AM, Alex Bligh wrote: >=20 >=20 > --On 2 June 2010 09:25:41 -0700 Nicholas Weaver = wrote: >=20 >> Here's the problem: On one hand, I agree with you. >>=20 >> OTOH, there are several vocal people who insist that if the client >> desires it, the resolver does not use the client-subnet option >=20 > Well, people being vocal does not mean they are right! But... >=20 >> which requires that the client, in such cases, be able to say "don't = use >> the option", which of course stresses all them broken middleboxes... >=20 > Nope - there are other ways to do this, which are actually SIMPLER for > the client (i.e. do not require an OS change). The most obvious is = simply > to use different set of IP addresses for the resolving servers > for those concerned about privacy. Yes, a given open resolver might = choose > not to do this, but then they might also choose not to respect = incoming > EDNS0 options (despite the standard), to sell all their data to = $evilempire > or whatever. Good point. > Moreover, didn't we find middleboxes that (by proxying DNS or = otherwise) > strip unknown EDNS0 options? In which case the option doesn't = guarantee > DNS privacy anyway. We aren't checking for that yet myself on Netalyzr (neither unknown RRs = nor unknown EDNS0 options), but I think most authorities tested are = actually happy with random EDNS0 options, but not all are (George = Barwood I think ran a test of that). From owner-namedroppers@ops.ietf.org Wed Jun 2 09:54:39 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9987928C117; Wed, 2 Jun 2010 09:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hU8KtuuaxOIn; Wed, 2 Jun 2010 09:54:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5AE2928C0E9; Wed, 2 Jun 2010 09:54:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJr7w-000Axn-QW for namedroppers-data0@psg.com; Wed, 02 Jun 2010 16:49:12 +0000 Received: from [74.125.83.52] (helo=mail-gw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJr7s-000Avz-D7 for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 16:49:08 +0000 Received: by gwj20 with SMTP id 20so1158281gwj.11 for ; Wed, 02 Jun 2010 09:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=9e7WxJboOLcx/Dfyfh6p4uYCJje8Vbyr8DyK7cuofwQ=; b=OeRvWLKDTCt5nxDC8m+3ZcLj0e5zsc9R4e6fueXQsIZmNpXZungiQydBoAHeIXNeMy jdzvAtqpL6x7xq5sx2X0IIkfnnpHY3ZFJ1RIs+7jFBUvOTBsWGz7wHeSRDATYkiJeG5U s0BaBS/GCi58wFOMBCw9+FPB8A5BdsWeSJyTY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=fYbMUwT0peUbqTJPRR1tI4soksrSamJDxDjwBN+damdnzvXN42ZQp/Ru9NNDje/ljr 1hp9eavAp8pVJyUEbtG/wIO/uMoWOMZS456V2bPNxSTVPIjhnhslW44t94jg0L3oMLtU xkCLzNBgOqQb/KHg5cuwBP3qs76+nfOw/lRg8= MIME-Version: 1.0 Received: by 10.101.11.29 with SMTP id o29mr8964263ani.64.1275497347287; Wed, 02 Jun 2010 09:49:07 -0700 (PDT) Received: by 10.100.8.14 with HTTP; Wed, 2 Jun 2010 09:49:07 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Jun 2010 13:49:07 -0300 Message-ID: Subject: [dnsext] Re: client-subnet - questions for the authors, and outside-the-box brainstorming From: Brian Dickson To: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=0016e68ea0704c0c0704880ede55 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016e68ea0704c0c0704880ede55 Content-Type: text/plain; charset=ISO-8859-1 Replying to myself to get things back on subject... To summarize the idea (in a top-reply): Have the "big cache" (resolvers) actually be authoritative for the CDN "trick" zones, by way of being slaves. When a stub is pointed at a nameserver that happens to be authoritative, it drops RTT to the absolute minimum, and number of queries needed to 1. And, having the "tricks" done there, means the right information (client IP) is available implicitly, to always give the "best" answer. It means not having to add to the DNS protocol for the tricks, but it does put more pressure on the provisioning systems, particularly inter- (rather than intra-) provider provisioning of slaves. Brian On Tue, Jun 1, 2010 at 9:15 AM, Brian Dickson wrote: > Here's how I think this might better be addressed, which BTW introduces a > new and different problem to solve, which I think *will* be of interest to > the whole DNS community, and in fact has previously been established as an > area of interest to the WG, and needs to be picked up and further developed: > > Rather than having the "big caches" being true caches, in the current sense > of what a cache is, change the relationship between the CDN DNS servers and > these "BC"s to that of master and slave, on the zones served by the masters. > > This changes the overall flow of information, and changes where the "dns > tricks" get done, to the place where the original data needed (the > real-world client IP address) is available - i.e., the BC. > > Timeliness is achieved by the pushing of zone updates, via notify/XFR. > > Stub clients get the relevant CDN-specific answers, quite possibly achieved > by way of "views" on the zone data. > > The tools for doing this already exist, except for one area, which is where > this WG already has interest: automated provisioning of slave zones, to > bootstrap the operational update of secondary servers. > > IMHO, having a strong motivation to handle this, means if this alternate > design is accepted and adopted by the CDN/BC folks, we can expect good work > from them in this area - something which will be of benefit to the whole of > the DNS community. > > And, it keeps the "stupid DNS tricks" localized to authoritative servers > (even if they are operated by third parties, per se), which is where they > belong, IMHO. > > Brian > --0016e68ea0704c0c0704880ede55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Replying to myself to get things back on subject...


To summarize the idea (in a top-reply):
Have the "big cache" (resolvers) actually be authoritative for th= e CDN=20 "trick" zones, by way of being slaves.

When a stub is pointed at a nameserver that happens to be authoritative, it drops RTT to the absolute minimum, and number of queries needed to=20 1.

And, having the "tricks" done there, means the right information = (client IP) is available implicitly, to always give the "best" answer.
It means not having to add to the DNS protocol for the tricks, but it=20 does put more pressure on the provisioning systems, particularly inter-=20 (rather than intra-) provider provisioning of slaves.

Brian

On Tue, Jun 1, 2010 at 9:15 AM, Bri= an Dickson <brian.peter.dickson@gmail.com> wrote:
=A0
Here's how I think this might better be addressed, which BTW introduces= a new and different problem to solve, which I think *will* be of interest = to the whole DNS community, and in fact has previously been established as = an area of interest to the WG, and needs to be picked up and further develo= ped:

Rather than having the "big caches" being true caches, in the= current sense of what a cache is, change the relationship between the CDN = DNS servers and these "BC"s to that of master and slave, on the z= ones served by the masters.

This changes the overall flow of information, and changes where the &qu= ot;dns tricks" get done, to the place where the original data needed (= the real-world client IP address) is available - i.e., the BC.

Timeliness is achieved by the pushing of zone updates, via notify/XFR.

Stub clients get the relevant CDN-specific answers, quite possibly achi= eved by way of "views" on the zone data.

The tools for doi= ng this already exist, except for one area, which is where this WG already = has interest: automated provisioning of slave zones, to bootstrap the opera= tional update of secondary servers.

IMHO, having a strong motivation to handle this, means if this alternat= e design is accepted and adopted by the CDN/BC folks, we can expect good wo= rk from them in this area - something which will be of benefit to the whole= of the DNS community.

And, it keeps the "stupid DNS tricks" localized to authoritat= ive servers (even if they are operated by third parties, per se), which is = where they belong, IMHO.

Brian

--0016e68ea0704c0c0704880ede55-- From owner-namedroppers@ops.ietf.org Wed Jun 2 09:59:48 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD17528C0F7; Wed, 2 Jun 2010 09:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.033 X-Spam-Level: *** X-Spam-Status: No, score=3.033 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0-yKCd8Lf+X; Wed, 2 Jun 2010 09:59:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 97B5828B797; Wed, 2 Jun 2010 09:59:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJrFE-000CKH-Gw for namedroppers-data0@psg.com; Wed, 02 Jun 2010 16:56:44 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJrFB-000CJO-Cp for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 16:56:41 +0000 Received: by fxm19 with SMTP id 19so6072420fxm.11 for ; Wed, 02 Jun 2010 09:56:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.129.129 with SMTP id 1mr590446hbf.158.1275497797615; Wed, 02 Jun 2010 09:56:37 -0700 (PDT) Received: by 10.239.174.12 with HTTP; Wed, 2 Jun 2010 09:56:37 -0700 (PDT) In-Reply-To: <4C054F87.5010608@ogud.com> References: <4C054F87.5010608@ogud.com> Date: Wed, 2 Jun 2010 09:56:37 -0700 Message-ID: Subject: Re: [dnsext] Chairs statement on "client-option" debate From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Olafur Gudmundsson Cc: namedroppers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Jun 1, 2010 at 11:20 AM, Olafur Gudmundsson wrote: > #2 Problem statement: > We think we are close to understanding what the problem statement is. But > there is need for a concise one that does not > intermingle "misunderstanding" and problem. What we mean here is > that CDN people have made an assumption that resolvers are > "close" to "host =A0making query", DNS people have to large extent > never agreed with this assumption. > The problem statement needs to be explicit about what the issues are. I've been trying to come up with a problem statement candidate, but am having some difficulty with the advice here. Firstly, I don't agree that CDN people have made such an assumption - in my experience of dealing with several CDNs and their operators, they have directly measured the correlation between resolvers and client hosts and have some confidence in it. Naturally each CDN keeps that data to itself, which doesn't help convince anyone else. But experiments are runnable to gather this data, for example - it is relatively straightforward to figure out what resolver a client is using; http://whatsmyresolver.stdlib.net/ wrapping that up as a simple image render and purchasing a few million advertising impressions (for a charitable cause) spread across the internet would be one way to gather the specific data. If this kind of data is useful, and would help convince anyone - that's one option. Of course it's time, and money. However, I'm confused as to why the assumption matters. Even if the above were not the case, and CDN operators were making assumptions, and those assumptions are false - why does that matter for this option? This option is about forwarding client subnet information, the issue of correlation should be moot. Hence, I don't think it's possible to frame a correct problem statement that references an issue that doesn't really matter for the problem at hand. My version of the problem statement is; "Some CDN and Resolver operators would like to cooperate to provide client network information to authoritative servers in an open and inter-operable manner that is also respectful of end-user privacy". I don't think this group will ever agree on the justification or non-justification of DNS tricks, with any amount of data - there are obviously more fundamental differences of opinion. I don't think adoption of the option would encourage, or discourage the use of DNS tricks where they are not already - it's simply about making one use-case better for end-users. I think it's possible to be tolerant of this difference of opinion within the group, and still engineer. Just as many disagree on the DNSCurve/DNSSEC boundaries, that shouldn't prevent technical progress on both. --=20 Colm From owner-namedroppers@ops.ietf.org Wed Jun 2 10:11:13 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0268D28C0FE; Wed, 2 Jun 2010 10:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.457 X-Spam-Level: ** X-Spam-Status: No, score=2.457 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ajngxqygxt1; Wed, 2 Jun 2010 10:11:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7C27928B797; Wed, 2 Jun 2010 10:11:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJrPx-000EyE-QB for namedroppers-data0@psg.com; Wed, 02 Jun 2010 17:07:49 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJrPu-000Ex5-N8 for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 17:07:47 +0000 Received: from [10.71.0.51] (unknown [69.38.231.138]) by mail.avalus.com (Postfix) with ESMTPSA id 64E97C56907; Wed, 2 Jun 2010 18:07:44 +0100 (BST) Date: Wed, 02 Jun 2010 13:07:42 -0400 From: Alex Bligh Reply-To: Alex Bligh To: Nicholas Weaver cc: Nicholas Weaver , Wilmer van der Gaast , =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) Message-ID: In-Reply-To: References: <421400056AC3A68D057ED565@nimrod.local> <8D6F3C331BDC4FAFF237C0BA@nimrod.local> <38CC48E5755A3CCF0595D109@nimrod.local> <349259E6-76F2-4281-8CDB-330C4EA24DCB@ICSI.Berkeley.EDU> <0E746C79455D4799DF1A51DC@nimrod.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 2 June 2010 09:33:20 -0700 Nicholas Weaver wrote: > We aren't checking for that yet myself on Netalyzr (neither unknown RRs > nor unknown EDNS0 options), but I think most authorities tested are > actually happy with random EDNS0 options, but not all are (George Barwood > I think ran a test of that). I /think/ Ray's tests found something like this (though I have a habit of false memory when it comes to Ray's tests). -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Jun 2 10:58:30 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54EED28B797; Wed, 2 Jun 2010 10:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.053 X-Spam-Level: * X-Spam-Status: No, score=1.053 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRH+E9EeSThx; Wed, 2 Jun 2010 10:58:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 291C13A67D9; Wed, 2 Jun 2010 10:58:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJs66-000MEp-8B for namedroppers-data0@psg.com; Wed, 02 Jun 2010 17:51:22 +0000 Received: from [209.85.212.52] (helo=mail-vw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJs62-000MEQ-JR for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 17:51:18 +0000 Received: by vws9 with SMTP id 9so2240034vws.11 for ; Wed, 02 Jun 2010 10:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=Wxp2QYlKzIQB+mCNvj8Wdbq8NZubGQhEglGRV9/4/BY=; b=O4h2kZhKdsPMVDUZgCDxwUnv/gzrlOrdUzZQXMTfOLDMGlbe2ZbwYC/OYPEew/G9Aq 6NLzZhvktwckSmHPkg6qgJSAcnkLhVFSWjOKqq/C8bRkgseYou1FyO4KrniPk7qrBMRw YONAKnFdIUZfOTlTux+qwALawtNtb/F6ByC0Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=yFfTw/qGsMGAbjpUKC1q3JQRcVBmaOin79dlaYU5KWnQQIkeGmGgaan01Q/mfEUO4V E1bb3RyNwijSWtLhgHB2OlW6AclKs797wktbWvARog21nmGZCSEbcwImvnfgUTXjWxta 1TlommnjitSTPWoqeSJ0J46E2PEaFY9acz9Rw= MIME-Version: 1.0 Received: by 10.220.124.136 with SMTP id u8mr5944867vcr.76.1275501077246; Wed, 02 Jun 2010 10:51:17 -0700 (PDT) Received: by 10.220.102.130 with HTTP; Wed, 2 Jun 2010 10:51:17 -0700 (PDT) Date: Wed, 2 Jun 2010 10:51:17 -0700 Message-ID: Subject: The third poison (was Re: [dnsext] Re: draft-vandergaast-edns-client-ip-01) From: Ted Hardie To: Nicholas Weaver Cc: Jim Reid , IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Just to clarify, there is another poison.... On Sat, May 29, 2010 at 2:18 PM, Nicholas Weaver wrote: > Pick your poison: > > a: Enable these tricks to work with 3rd party resolvers > > or > > b: Accept a world where third party resolvers WILL produce inferior results: > http://www.sajalkayan.com/in-a-cdnd-world-opendns-is-the-enemy.html > > > Can any of those who oppose this solution make a compelling explanation why B is preferable, because from as far as I can tell, ANY solution for A is opposed by a vocal portion of this group? > As a third option, you can make these DNS tricks opt-in from the node originating the query, rather than deciding for it what the right query should be. Paul's point is that this is basically an addition to the q-tuple; this option adds network topology to the q-tuple and asks the authoritative to consider that in constructing the answer. If we are to do that, I think the right place to do it is at the node emitting the query. First and foremost because it is the only node that knows whether or not the node cares about topology being used to construct the answer. There are many applications for which this data is not useful or important, and turning it on only when needed is more efficient; if the originating node cares about that efficiency it can use it only when the application requires it. Second, the originating node may have data on what the appropriate piece of topology to use to augment the q-tuple might be. Given the extent of tunneling used in the Internet today, this is not trivial. To take one example discussed before, a host with a mobile IP tunnel back to a home network may consistently use the home network's DNS servers but use the outbound interface on the visited network to actually source application traffic (to avoid triangle routing for jitter-sensitve traffic like VoIP traffic, for example). If it can pass the home network the visited network subnet it wishes to use, the home network's DNS servers can use that to construct this augmented query. Note that this particular use case applies even if the node originating the query asks the authoritative server itself, using the tunnel interface to source the DNS query. Third, the node originating the query is the only node which can reasonably determine whether providing topology is a privacy issue. That issue has been discussed at length, but the opt-out nature of the current solution remains deficient--there is no way for the originating node to know whether the upstream is using this option in the current case, so it must deal with adding this option. That shifts a burden on to it for every query, to support the CDN's value proposition--which is present at only some queries. I understand that Nick and others believe that requiring opt-in will mean this never deploys. If the end-users or OS producers actually see the value being asserted here, I think that deployment could occur. It also seems to me by far the better long term solution if we do want topology (or anything else) include in the q-tuple. The node originating the q-tuple should originate any additional constraints on the results it desires. That just makes sense. regards, Ted Hardie From owner-namedroppers@ops.ietf.org Wed Jun 2 11:30:45 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27EB43A683F; Wed, 2 Jun 2010 11:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZgxyIBKbM29; Wed, 2 Jun 2010 11:30:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A03E03A685F; Wed, 2 Jun 2010 11:30:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJsdb-00039r-BB for namedroppers-data0@psg.com; Wed, 02 Jun 2010 18:25:59 +0000 Received: from [209.85.212.52] (helo=mail-vw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJsdY-00039K-In for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 18:25:56 +0000 Received: by vws9 with SMTP id 9so2291985vws.11 for ; Wed, 02 Jun 2010 11:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YD8tn+5wlf4zWGsc8Jrvbgaf8LBO6w4RN/G1noNwQls=; b=LJhytPjzYbsVFx3xoR+5DTYSJi5DFByGznvPDlm2o5PYSo8GG30XtUoJLnFBs/Wh6L GUywGMuQUshuS3IW/nhOWPC4YEm/nuistgDs5kBShJdu4fpbOSaA/BglAUpWq7rZCgJs kXNU5XSFPQgGWYl6V5dmqG9DZEj+PMnMJNIDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=snBok1GLAikPjrfsN7s1kAIneKnNJdrOb2lP35v2pMs/2B2jKBAQOvKLIJ+xuwzzSK mz5FFBKj3nu4GqIrDFt0W5i1efXut3pDb62ZRJIV6nwIP4d7ENBDXkBXoNInrcatzDcR vcZMWzR3Z0yYBb4C6+wC2PNeZj30HngaKLpos= MIME-Version: 1.0 Received: by 10.220.107.99 with SMTP id a35mr5941043vcp.213.1275503155775; Wed, 02 Jun 2010 11:25:55 -0700 (PDT) Received: by 10.220.102.130 with HTTP; Wed, 2 Jun 2010 11:25:55 -0700 (PDT) In-Reply-To: <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> Date: Wed, 2 Jun 2010 11:25:55 -0700 Message-ID: Subject: Re: [dnsext] latency From: Ted Hardie To: Nicholas Weaver Cc: Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Jun 2, 2010 at 9:10 AM, Nicholas Weaver wrote: > Most (51) are from l.yimg.com, so lets focus on that: > > The browser (firefox, mac) opens six TCP streams to l.yimg.com, but becau= se the browser doesn't pipeline, it has to wait for each element to be rece= ived before the next one is fetched. =A0Thus fetching those 51 images requi= res at least 9 RTTs to the server. =A0(For a typical connection in this flo= w, replies are 1-2 packets, so the TCP windowing doesn't come into effect, = and I'm on a 100 Mbps connection here) > This argues for increased pipelining; that slipped off the common road because of head-of-line blocking problems for generated resources, but it may be time for some discussions on that point again. > And this is yet another example of how HTTP redirects don't work: There i= s no way to say 'fetch all requests for l.yimg.com from a2354.l.yimg.com' w= ith an HTTP redirect, so doing redirects wouldn't help here: you'd still ta= ke the latency hit FOR EACH REQUEST to l.yimg.com. > Would a new HTTP 30x message with the meaning "all URIs from this host and/or all URIs from this point in the hieirarchy" be a useful point to mak= e then? That seems like something that is useful whether you use a CDN or are simply moving hosts from a previous name. regards, Ted From owner-namedroppers@ops.ietf.org Wed Jun 2 11:44:01 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B6428C17F; Wed, 2 Jun 2010 11:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_50=0.001, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVTXbj0TZtSW; Wed, 2 Jun 2010 11:43:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 685A93A6A18; Wed, 2 Jun 2010 11:43:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJsrC-0005du-O7 for namedroppers-data0@psg.com; Wed, 02 Jun 2010 18:40:02 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJsr9-0005dB-IV for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 18:39:59 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o52IdewQ014070; Wed, 2 Jun 2010 11:39:40 -0700 (PDT) References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <08757FA4-B661-44A6-94D2-F35E5C429197@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: [dnsext] latency Date: Wed, 2 Jun 2010 11:39:40 -0700 To: Ted Hardie X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 2, 2010, at 11:25 AM, Ted Hardie wrote: >> Most (51) are from l.yimg.com, so lets focus on that: >>=20 >> The browser (firefox, mac) opens six TCP streams to l.yimg.com, but = because the browser doesn't pipeline, it has to wait for each element to = be received before the next one is fetched. Thus fetching those 51 = images requires at least 9 RTTs to the server. (For a typical = connection in this flow, replies are 1-2 packets, so the TCP windowing = doesn't come into effect, and I'm on a 100 Mbps connection here) >>=20 >=20 > This argues for increased pipelining; that slipped off the common > road because of head-of-line blocking problems for generated > resources, but it may be time for some discussions on that point = again. Agreed, but it requires browsers changing. Basically, the only "major" browser that does pipelining is Opera. Even = the very much speed obsessed Chrome doesn't do pipelining, which makes = me think that, even though pipelining is supposed to have been supported = for years, the browser developers still don't trust stupid middleboxes = to not break it. >> And this is yet another example of how HTTP redirects don't work: = There is no way to say 'fetch all requests for l.yimg.com from = a2354.l.yimg.com' with an HTTP redirect, so doing redirects wouldn't = help here: you'd still take the latency hit FOR EACH REQUEST to = l.yimg.com. >>=20 >=20 > Would a new HTTP 30x message with the meaning "all URIs from this host > and/or all URIs from this point in the hieirarchy" be a useful point = to make > then? That seems like something that is useful whether you use a CDN > or are simply moving hosts from a previous name. That would IMO, be really useful to have, but it would probably require = a crap-load of changes in browsers to actually implement, because it = would require effectively hostname/suburl aliasing infrastructure. It = would be great if it was in the protocol from the start, but I seriously = doubt you could add it in NOW. From owner-namedroppers@ops.ietf.org Wed Jun 2 11:44:46 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873FB28C171; Wed, 2 Jun 2010 11:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_50=0.001, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vjMT+ZgEZvY; Wed, 2 Jun 2010 11:44:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C33228C127; Wed, 2 Jun 2010 11:44:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJsss-00062M-9J for namedroppers-data0@psg.com; Wed, 02 Jun 2010 18:41:46 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJssn-000613-Gb for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 18:41:41 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o52IfNWm014266; Wed, 2 Jun 2010 11:41:23 -0700 (PDT) References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <08757FA4-B661-44A6-94D2-F35E5C429197@ICSI.Berkeley.EDU> In-Reply-To: <08757FA4-B661-44A6-94D2-F35E5C429197@ICSI.Berkeley.EDU> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <1623BEF3-B846-48BF-975D-1FCF7154B9E6@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable Cc: Ted Hardie , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: [dnsext] latency Date: Wed, 2 Jun 2010 11:41:23 -0700 To: Nicholas Weaver X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 2, 2010, at 11:39 AM, Nicholas Weaver wrote: >=20 > On Jun 2, 2010, at 11:25 AM, Ted Hardie wrote: >>> Most (51) are from l.yimg.com, so lets focus on that: >>>=20 >>> The browser (firefox, mac) opens six TCP streams to l.yimg.com, but = because the browser doesn't pipeline, it has to wait for each element to = be received before the next one is fetched. Thus fetching those 51 = images requires at least 9 RTTs to the server. (For a typical = connection in this flow, replies are 1-2 packets, so the TCP windowing = doesn't come into effect, and I'm on a 100 Mbps connection here) >>>=20 >>=20 >> This argues for increased pipelining; that slipped off the common >> road because of head-of-line blocking problems for generated >> resources, but it may be time for some discussions on that point = again. >=20 > Agreed, but it requires browsers changing. >=20 > Basically, the only "major" browser that does pipelining is Opera. = Even the very much speed obsessed Chrome doesn't do pipelining, which = makes me think that, even though pipelining is supposed to have been = supported for years, the browser developers still don't trust stupid = middleboxes to not break it. Especially since head-of-line blocking can be handled easily enough by = keeping the conncurrent TCP connection model so if one pipeline is = blocked, just rerequest through a different one once the work queue is = empty. From owner-namedroppers@ops.ietf.org Wed Jun 2 12:34:14 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA3F28C169; Wed, 2 Jun 2010 12:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH1ea-bMYeZ9; Wed, 2 Jun 2010 12:34:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0678D28C10D; Wed, 2 Jun 2010 12:34:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJtcR-000DYj-Ll for namedroppers-data0@psg.com; Wed, 02 Jun 2010 19:28:51 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJtcO-000DYS-Fi for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 19:28:48 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 0B844A4152 for ; Wed, 2 Jun 2010 19:28:48 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers Subject: Re: [dnsext] Chairs statement on "client-option" debate In-Reply-To: Your message of "Wed\, 02 Jun 2010 09\:56\:37 MST." References: <4C054F87.5010608@ogud.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 02 Jun 2010 19:28:48 +0000 Message-ID: <10165.1275506928@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Wed, 2 Jun 2010 09:56:37 -0700 > From: Colm MacC=C3=A1rthaigh >=20 > ... in my experience of dealing with several CDNs and their operators, > they have directly measured the correlation between resolvers and > client hosts and have some confidence in it. ... confidence expressed by those without a possible business motivation in the outcome would convince me moreso. From owner-namedroppers@ops.ietf.org Wed Jun 2 12:45:21 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568093A687B; Wed, 2 Jun 2010 12:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.555 X-Spam-Level: ** X-Spam-Status: No, score=2.555 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_56=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgZMrNu0tm3M; Wed, 2 Jun 2010 12:45:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EEB523A6811; Wed, 2 Jun 2010 12:45:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJtob-000FuZ-Ej for namedroppers-data0@psg.com; Wed, 02 Jun 2010 19:41:25 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJtoV-000Fu8-31 for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 19:41:19 +0000 Received: (qmail 27674 invoked by uid 399); 2 Jun 2010 19:41:17 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 2 Jun 2010 19:41:17 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C06B3DA.2030006@dougbarton.us> Date: Wed, 02 Jun 2010 12:41:14 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Nicholas Weaver CC: Ted Hardie , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Subject: Re: [dnsext] latency References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <08757FA4-B661-44A6-94D2-F35E5C429197@ICSI.Berkeley.EDU> In-Reply-To: <08757FA4-B661-44A6-94D2-F35E5C429197@ICSI.Berkeley.EDU> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [ meta-note, if you're going to send long lines in your message (which is fine) please turn on the format=flowed option. Without it, when I hit reply your text shows up as one long line and I have to do extra steps to fix it. With that option this doesn't happen. Meanwhile, the combination of format=flowed + wrapping at around 72 columns is the best of both worlds. The text will still reformat to fit the size of the screen for newer clients, but those with older mail software still see something that looks familiar/readable. ] On 06/02/10 11:39, Nicholas Weaver wrote: > > On Jun 2, 2010, at 11:25 AM, Ted Hardie wrote: >>> Most (51) are from l.yimg.com, so lets focus on that: >>> >>> The browser (firefox, mac) opens six TCP streams to l.yimg.com, >>> but because the browser doesn't pipeline, it has to wait for each >>> element to be received before the next one is fetched. Thus >>> fetching those 51 images requires at least 9 RTTs to the server. >>> (For a typical connection in this flow, replies are 1-2 packets, >>> so the TCP windowing doesn't come into effect, and I'm on a 100 >>> Mbps connection here) >>> >> >> This argues for increased pipelining; that slipped off the common >> road because of head-of-line blocking problems for generated >> resources, but it may be time for some discussions on that point >> again. IIRC firefox used to enable pipelining by default but stopped, probably due to the issues you mention here. It's easy enough to enable it to see if it gives you any benefit. Just type about:config in the address bar, type pipe into the Filter window, and enable the 2 network.http.pipelining options by clicking them. > Agreed, but it requires browsers changing. > > Basically, the only "major" browser that does pipelining is Opera. > Even the very much speed obsessed Chrome doesn't do pipelining, which > makes me think that, even though pipelining is supposed to have been > supported for years, the browser developers still don't trust stupid > middleboxes to not break it. > >>> And this is yet another example of how HTTP redirects don't work: >>> There is no way to say 'fetch all requests for l.yimg.com from >>> a2354.l.yimg.com' with an HTTP redirect, so doing redirects >>> wouldn't help here: you'd still take the latency hit FOR EACH >>> REQUEST to l.yimg.com. >>> >> >> Would a new HTTP 30x message with the meaning "all URIs from this >> host and/or all URIs from this point in the hieirarchy" be a useful >> point to make then? That seems like something that is useful >> whether you use a CDN or are simply moving hosts from a previous >> name. > > That would IMO, be really useful to have, but it would probably > require a crap-load of changes in browsers to actually implement, > because it would require effectively hostname/suburl aliasing > infrastructure. It would be great if it was in the protocol from the > start, but I seriously doubt you could add it in NOW. So this point, and the one above about pipelining reinforce what I said last time this issue came around. The latency problem is primarily (IMO by a wide majority) a browser/web problem, and needs to be solved at the HTTP layer, not at the DNS layer. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Wed Jun 2 13:04:30 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800A73A680A; Wed, 2 Jun 2010 13:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.027 X-Spam-Level: *** X-Spam-Status: No, score=3.027 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgLTbjr9hDoa; Wed, 2 Jun 2010 13:04:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8DABF3A63D3; Wed, 2 Jun 2010 13:04:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJu6V-000JM0-Bk for namedroppers-data0@psg.com; Wed, 02 Jun 2010 19:59:55 +0000 Received: from [72.14.220.155] (helo=fg-out-1718.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJu6R-000JLf-Ij for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 19:59:51 +0000 Received: by fg-out-1718.google.com with SMTP id l26so1792650fgb.17 for ; Wed, 02 Jun 2010 12:59:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.193.11 with SMTP id g11mr211886hbi.77.1275508789693; Wed, 02 Jun 2010 12:59:49 -0700 (PDT) Received: by 10.239.174.12 with HTTP; Wed, 2 Jun 2010 12:59:49 -0700 (PDT) In-Reply-To: <10165.1275506928@nsa.vix.com> References: <4C054F87.5010608@ogud.com> <10165.1275506928@nsa.vix.com> Date: Wed, 2 Jun 2010 12:59:49 -0700 Message-ID: Subject: Re: [dnsext] Chairs statement on "client-option" debate From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Jun 2, 2010 at 12:28 PM, Paul Vixie wrote: >> Date: Wed, 2 Jun 2010 09:56:37 -0700 >> From: Colm MacC=E1rthaigh >> >> ... in my experience of dealing with several CDNs and their operators, >> they have directly measured the correlation between resolvers and >> client hosts and have some confidence in it. ... > > confidence expressed by those without a possible business motivation in t= he > outcome would convince me moreso. Me too, I would love to see an independent party run - and if not run; audit - a series of experiments designed to settle these issues. I think it would make an important research topic too, worthy of CAIDA or OARC participation - but to the best of my knowledge, noone has performed it. If any readers know of how to go about making such a proposal to bodies such as CAIDA, OARC or know of any other research groups who might be interested, speak up. --=20 Colm From owner-namedroppers@ops.ietf.org Wed Jun 2 13:15:28 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87B228C127; Wed, 2 Jun 2010 13:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_50=0.001, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t43wrH3R0yvt; Wed, 2 Jun 2010 13:15:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 643E53A68D6; Wed, 2 Jun 2010 13:15:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJuHX-000LAl-C0 for namedroppers-data0@psg.com; Wed, 02 Jun 2010 20:11:19 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJuHT-000LA9-94 for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 20:11:15 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o52KAteR027584; Wed, 2 Jun 2010 13:10:55 -0700 (PDT) References: <4C054F87.5010608@ogud.com> <10165.1275506928@nsa.vix.com> In-Reply-To: <10165.1275506928@nsa.vix.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <7D079441-8FA6-4BB2-AF49-C0FE503FFF63@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , namedroppers From: Nicholas Weaver Subject: Re: [dnsext] Chairs statement on "client-option" debate Date: Wed, 2 Jun 2010 13:10:54 -0700 To: Paul Vixie X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 2, 2010, at 12:28 PM, Paul Vixie wrote: >> Date: Wed, 2 Jun 2010 09:56:37 -0700 >> From: Colm MacC=E1rthaigh >>=20 >> ... in my experience of dealing with several CDNs and their = operators, >> they have directly measured the correlation between resolvers and >> client hosts and have some confidence in it. ... >=20 > confidence expressed by those without a possible business motivation = in the > outcome would convince me moreso. Paul, there are plenty of measurements you can conduct yourself to show = that they do get this right, or at least right enough of the time: The impact of these tricks can easily be gauged by comparing the ping = time to the server returned as the A record for a CDN'ed domain when = queried from your default resolver and/or your own IP, compared with the = same name looked up through a random open DNS resolver in a different = geographical location (there are plenty of those too, just scan for = them!). You can easily see 20-100ms of difference depending on conditions and = your location. I've posted citations and self experiments. If you want to create your OWN database, its also easy to do (as someone = else mentioned in this thread): just pay for a flashy web ad that does a = unique DNS lookup along with reporting to the server what IP its behind. = Blend with a GeoIP database and Whois information and voila. Probably not as good as Akamai's database, but certainly good enough for = the "direct the user to the right subcontinent" which alone is = responsible for the biggest portion of the performance gains. And I certainly have NO business motivation in CDN behavior (yet... I = have thought a FreeCDN might be a good deployment model for PlanetLab on = Steroids...) From owner-namedroppers@ops.ietf.org Wed Jun 2 13:17:00 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D4F3A6A43; Wed, 2 Jun 2010 13:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.291 X-Spam-Level: X-Spam-Status: No, score=-100.291 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EALttXWMDkWM; Wed, 2 Jun 2010 13:16:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EA42F28C161; Wed, 2 Jun 2010 13:16:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJuJm-000LgY-NC for namedroppers-data0@psg.com; Wed, 02 Jun 2010 20:13:38 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJuJi-000LKF-F4 for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 20:13:35 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o52K7X6H012381; Wed, 2 Jun 2010 20:07:49 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o52K6HmE012373; Wed, 2 Jun 2010 20:06:17 GMT Date: Wed, 2 Jun 2010 20:06:12 +0000 From: bmanning@vacation.karoshi.com To: Doug Barton Cc: Nicholas Weaver , Ted Hardie , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Subject: Re: [dnsext] latency Message-ID: <20100602200612.GA12168@vacation.karoshi.com.> References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <08757FA4-B661-44A6-94D2-F35E5C429197@ICSI.Berkeley.EDU> <4C06B3DA.2030006@dougbarton.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C06B3DA.2030006@dougbarton.us> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Jun 02, 2010 at 12:41:14PM -0700, Doug Barton wrote: > [ meta-note, if you're going to send long lines in your message (which > is fine) please turn on the format=flowed option. Without it, when I hit > reply your text shows up as one long line and I have to do extra steps > to fix it. With that option this doesn't happen. Meanwhile, the > combination of format=flowed + wrapping at around 72 columns is the best > of both worlds. The text will still reformat to fit the size of the > screen for newer clients, but those with older mail software still see > something that looks familiar/readable. ] sorry Doug, can't find "format=flowed" > > So this point, and the one above about pipelining reinforce what I said > last time this issue came around. The latency problem is primarily (IMO > by a wide majority) a browser/web problem, and needs to be solved at the > HTTP layer, not at the DNS layer. > > > Doug Perhaps, maybe, this thread touches on a DNS concern to wit... is the DNS infrastructure (however loosely defined) is -UNABLE- to handle the expected query load from applications that expect consistant, subsecond name resolution from many different sources is argueably poorly implemented. Given that auth servers have a fairly high degree of autonomy and are constrained by geo/topo location, the use of third party caches makes lots of sense ... and if those caches can direct stubs to the "best" cache or the "best" auth source - then clearly this is a win. A stop-gap, but a win. In some sense these discussions are moving intermediate caches from a useful adjunt to the stub to deal w/ transient service unavailability to a full-blown, critical player in the DNS ecosystem. I, for one, would prefer to reduce my systems dependence on a "middle-man" ... Some rambling thoughts on (for me) this friday afternoon. --bill From owner-namedroppers@ops.ietf.org Wed Jun 2 13:18:47 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38223A699C; Wed, 2 Jun 2010 13:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-bGemHKC1wT; Wed, 2 Jun 2010 13:18:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C69433A6A45; Wed, 2 Jun 2010 13:18:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJuLc-000LvJ-Pq for namedroppers-data0@psg.com; Wed, 02 Jun 2010 20:15:32 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJuLY-000Ltz-FG for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 20:15:28 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 36674A4180 for ; Wed, 2 Jun 2010 20:15:28 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] Chairs statement on "client-option" debate In-Reply-To: Your message of "Wed\, 02 Jun 2010 12\:59\:49 MST." References: <4C054F87.5010608@ogud.com> <10165.1275506928@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 02 Jun 2010 20:15:28 +0000 Message-ID: <13242.1275509728@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Wed, 2 Jun 2010 12:59:49 -0700 > From: Colm MacC=C3=A1rthaigh >=20 > > confidence expressed by those without a possible business motivation in > > the outcome would convince me moreso. >=20 > Me too, I would love to see an independent party run - and if not run; > audit - a series of experiments designed to settle these issues. ... note that while i can imagine becoming convinced that changes to dns would support the web industry better, i don't think i could agree that the web's desires warrant the complexity now being proposed. the web is smaller and younger than the internet, and is only one of many internet applications the internet will likely outlast "the web" by many centuries. just sayin'. From owner-namedroppers@ops.ietf.org Wed Jun 2 13:38:19 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4683A6860; Wed, 2 Jun 2010 13:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, UPPERCASE_50_75=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEcnbDT7hX2z; Wed, 2 Jun 2010 13:38:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 801DB3A6A4B; Wed, 2 Jun 2010 13:38:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJudm-000OVN-Pi for namedroppers-data0@psg.com; Wed, 02 Jun 2010 20:34:18 +0000 Received: from [131.111.8.132] (helo=ppsw-32.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJudh-000OUG-8S for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 20:34:13 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:42703) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1OJudI-0005ux-0I (Exim 4.70) (return-path ); Wed, 02 Jun 2010 21:33:48 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OJudI-0001In-2O (Exim 4.67) (return-path ); Wed, 02 Jun 2010 21:33:48 +0100 Date: Wed, 2 Jun 2010 21:33:48 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: bmanning@vacation.karoshi.com cc: Doug Barton , Nicholas Weaver , Ted Hardie , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Subject: Re: [dnsext] latency In-Reply-To: <20100602200612.GA12168@vacation.karoshi.com.> Message-ID: References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <08757FA4-B661-44A6-94D2-F35E5C429197@ICSI.Berkeley.EDU> <4C06B3DA.2030006@dougbarton.us> <20100602200612.GA12168@vacation.karoshi.com.> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, 2 Jun 2010, bmanning@vacation.karoshi.com wrote: > sorry Doug, can't find "format=flowed" http://tools.ietf.org/html/rfc3676 Tony. -- f.anthony.n.finch http://dotat.at/ FAIR ISLE FAEROES: SOUTHWESTERLY 5 OR 6, BECOMING VARIABLE 4. ROUGH, OCCASIONALLY VERY ROUGH AT FIRST. OCCASIONAL RAIN, FOG PATCHES FOR A TIME. MODERATE OR GOOD, OCCASIONALLY VERY POOR. From owner-namedroppers@ops.ietf.org Wed Jun 2 13:39:42 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2313A6A4B; Wed, 2 Jun 2010 13:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.33 X-Spam-Level: ** X-Spam-Status: No, score=2.33 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUFFtEHUjWJ5; Wed, 2 Jun 2010 13:39:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 371793A6A45; Wed, 2 Jun 2010 13:39:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJucK-000OHr-3U for namedroppers-data0@psg.com; Wed, 02 Jun 2010 20:32:48 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJucE-000OH0-JO for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 20:32:42 +0000 Received: (qmail 11812 invoked by uid 399); 2 Jun 2010 20:32:41 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 2 Jun 2010 20:32:41 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C06BFE8.2000508@dougbarton.us> Date: Wed, 02 Jun 2010 13:32:40 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: bmanning@vacation.karoshi.com CC: Nicholas Weaver , Ted Hardie , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Subject: Re: [dnsext] latency References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <08757FA4-B661-44A6-94D2-F35E5C429197@ICSI.Berkeley.EDU> <4C06B3DA.2030006@dougbarton.us> <20100602200612.GA12168@vacation.karoshi.com.> In-Reply-To: <20100602200612.GA12168@vacation.karoshi.com.> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 06/02/10 13:06, bmanning@vacation.karoshi.com wrote: > On Wed, Jun 02, 2010 at 12:41:14PM -0700, Doug Barton wrote: >> [ meta-note, if you're going to send long lines in your message (which >> is fine) please turn on the format=flowed option. Without it, when I hit >> reply your text shows up as one long line and I have to do extra steps >> to fix it. With that option this doesn't happen. Meanwhile, the >> combination of format=flowed + wrapping at around 72 columns is the best >> of both worlds. The text will still reformat to fit the size of the >> screen for newer clients, but those with older mail software still see >> something that looks familiar/readable. ] > > sorry Doug, can't find "format=flowed" You're not using Apple Mail, and Mutt wraps it's lines already, so you're off the hook. :) -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Wed Jun 2 13:47:05 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6DB13A6A5A; Wed, 2 Jun 2010 13:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgRlDfN2l-Zy; Wed, 2 Jun 2010 13:47:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 72BBE3A6860; Wed, 2 Jun 2010 13:47:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJumI-000Pmm-G9 for namedroppers-data0@psg.com; Wed, 02 Jun 2010 20:43:06 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OJumC-000Pll-QR for namedroppers@ops.ietf.org; Wed, 02 Jun 2010 20:43:01 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o52KgvJE001664; Wed, 2 Jun 2010 13:42:57 -0700 (PDT) References: <4C054F87.5010608@ogud.com> <10165.1275506928@nsa.vix.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <5C76CE19-7563-4682-B1E4-6A4D5A2A75E0@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , IETF DNSEXT WG From: Nicholas Weaver Subject: Re: [dnsext] Chairs statement on "client-option" debate Date: Wed, 2 Jun 2010 13:42:57 -0700 To: =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 2, 2010, at 12:59 PM, Colm MacC=E1rthaigh wrote: > On Wed, Jun 2, 2010 at 12:28 PM, Paul Vixie wrote: >>> Date: Wed, 2 Jun 2010 09:56:37 -0700 >>> From: Colm MacC=E1rthaigh >>>=20 >>> ... in my experience of dealing with several CDNs and their = operators, >>> they have directly measured the correlation between resolvers and >>> client hosts and have some confidence in it. ... >>=20 >> confidence expressed by those without a possible business motivation = in the >> outcome would convince me moreso. >=20 > Me too, I would love to see an independent party run - and if not run; > audit - a series of experiments designed to settle these issues. I > think it would make an important research topic too, worthy of CAIDA > or OARC participation - but to the best of my knowledge, noone has > performed it. >=20 > If any readers know of how to go about making such a proposal to > bodies such as CAIDA, OARC or know of any other research groups who > might be interested, speak up. We could do it in Netalyzr if we were interested enough in the results, = its not hard: Compare the TCP connect time for connecting to a major CDN'ed site, with = the IP looked up through the local resolver, the NAT's resolver (if = present), looked up through a third party resolver service, and looked = up through a resolver we host (so from a known constant geographic = location). We already get client IP and external resolver IP, so if we wanted to = blend together a CDN-type mapping we could. The problem is, IMO, it would be VERY low down on our priority list: = When we or others do such tests manually, the results are pretty plainly = obvious: the DNS tricks work, and are deployed because they already work = in most cases. Additionally, it generally doesn't affect the user = unless they are foolish enough to use a third party resolver (which we = will often warn about in the name lookup latency test anyway). And given limited coding effort, there are much more important tests = (such as potential IPv6 problems, and checking for DNS support for = DNSSEC RRs, AAAA RRs, unknown RRs, unknown EDNS0 commands, etc, both on = queries to the NAT's DNS proxy and directly to our server, potential = issue with various gateways/NATs which may have vulnerabilities, etc) = which would be worth conducting first, as these detect user-affecting = problems. From owner-namedroppers@ops.ietf.org Wed Jun 2 19:38:00 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47FC3A6A55; Wed, 2 Jun 2010 19:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.958 X-Spam-Level: X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+G+WvVPs0L4; Wed, 2 Jun 2010 19:37:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6574F3A691D; Wed, 2 Jun 2010 19:36:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK0CE-000CDN-JP for namedroppers-data0@psg.com; Thu, 03 Jun 2010 02:30:14 +0000 Received: from [74.125.149.75] (helo=na3sys009aog105.obsmtp.com) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK0CA-000CCz-Uw for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 02:30:11 +0000 Received: from source ([209.85.213.174]) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTAcTsRuNeoGaXbnpciP3QopACEco8bjk@postini.com; Wed, 02 Jun 2010 19:30:10 PDT Received: by mail-yx0-f174.google.com with SMTP id 31so1148128yxl.33 for ; Wed, 02 Jun 2010 19:30:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.176.213 with SMTP id bf21mr10918985ibb.67.1275532208673; Wed, 02 Jun 2010 19:30:08 -0700 (PDT) Received: by 10.231.111.131 with HTTP; Wed, 2 Jun 2010 19:30:08 -0700 (PDT) In-Reply-To: <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> Date: Wed, 2 Jun 2010 19:30:08 -0700 Message-ID: Subject: Re: [dnsext] end-to-end violations in draft-vandergaast-edns-client-ip-01 From: David Ulevitch To: Jim Reid Cc: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= , IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: 2010/5/31 Jim Reid : > To repeat what I said earlier, a > resolving server should not be tampering with the contents of a stub's query > or the resulting response. This should be common sense. > Some background -- When I started OpenDNS numerous folks (including Vixie) told me the market for people who wanted their responses tampered with was zero. They wished me luck, expecting me to fail. Today we have millions of users who use our service to control the responses they receive as they see fit. Some of these users use this power to block certain kinds of DNS lookups so people don't visit MySpace or Facebook or Playboy. Some use it to prevent malware on their network from phoning home to known botnets and divulging their private data. Regardless of the reason, there is clearly a market for tampered DNS responses as we've been doing this since 2006, and profitably since 2007. Today, the vast majority of our revenue growth is from paying enterprise customers deploying this globally. These are not naive users by any means. So unfortunately, conventional wisdom disagrees with what you believe to be common sense. So on this issue I've remained largely quiet here for a bit, since most of the discussion is circular and the opponents have no desire to see this move forward. But I want to address two points: Internet architecture and privacy concerns. 1) Internet architecture. Vixie suggested this draft represents a change to the architecture of the Internet and needs to be reviewed by the IAB. By his reasoning, nearly everything (not just DNS) is a change to the architecture of the Internet. Using an EDNS0 option-code to add some metadata to requests has been happening for years, as designed, and this proposed draft contains a new use that people would like to standardize upon. The entire point of EDNS0 is to let clients advertise capabilities to authoritative servers in a way that doesn't break the Internet. One such capability -- for example -- is to serve a particular client in a particular way. I cannot think of a more appropriate use for EDNS0. To suggest that this changes the architecture of the Internet is truly bizarre when compared against every other non-IAB-reviewed DNSWG RFC which has moved forward in the last decade. 2) As for privacy concerns, there is, unfortunately, no possible way to make what is being proposed an opt-in option as determined by the stub resolver originating the query. Not philosophically, or even technically as far as I can think. Certainly resolver authors can (and should) implement it the way we have done it so that the service is available to some clients and not others, to some authoritative DNS servers and not others, and for some zones not others. But still there have been concerns that this creates a data leak that previously did not exist. There has yet to be an example shown where this is the case and the "interceptor" is not already situated as a man in the middle of a plaintext DNS conversation. So I'm not sure why it persists. Ultimately, when client decides to run their own recursive DNS server, which has been pointed out as being "so trivial," they are in complete control of that experience to the degree that they are in control of their Internet connection. When they pick someone else to run it, they still control that experience as a matter of choice (voting with one's wallet if you will). If they pick a service or deploy a piece of software with policies they do not agree with, they will switch. The focus here is in the wrong place -- I think this particular bit of energy is better directed at preserving the right for people to run their own resolver or choose a third-party, not about dictating the capabilities of what resolvers can and can't do when it will have no impact on anyone else. -David From owner-namedroppers@ops.ietf.org Wed Jun 2 20:28:30 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E913A68F9; Wed, 2 Jun 2010 20:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.975 X-Spam-Level: X-Spam-Status: No, score=0.975 tagged_above=-999 required=5 tests=[AWL=-1.131, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T--atxuRrydr; Wed, 2 Jun 2010 20:28:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 15BAD3A6835; Wed, 2 Jun 2010 20:28:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK126-000HQP-0u for namedroppers-data0@psg.com; Thu, 03 Jun 2010 03:23:50 +0000 Received: from [74.125.82.52] (helo=mail-ww0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK11z-000HPj-1H for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 03:23:43 +0000 Received: by wwi18 with SMTP id 18so180989wwi.11 for ; Wed, 02 Jun 2010 20:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=ZH/xkuyKaO26GAZrj6c9ULnj0hjOEpB6gCX5brStmPU=; b=RBQgcd0BJwPzYwNkjM/qiWt0xx7dERx1/YmvMjNUKTTZSL2KFoIFbwyergJJmDUqBA bF2h52kpliinw4VUf2z9FyE/tDcjJJcHGRDqYnRF3619Zyc2saye3PliMMXNcugFv9Fw r8bTs2VAx3OjIki4mC3Bi81qvep+Q1/n4Sgh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jjay6SJekmgu0EkOd/GsbXWhItlxHrJW9BwkCpJAXmGWyl9Z0alk/2hOpj9oz4ak4j KjStqkyP5JAWssgT2e5QVWkLaijjlyL3vggfH28nWZN3nKFPsCiUPCMfD0YV90GRnWeC RMptgp9GFIAVnK7E+XnoHfNueGqPNHSpMQa+4= MIME-Version: 1.0 Received: by 10.216.170.9 with SMTP id o9mr695225wel.45.1275535421170; Wed, 02 Jun 2010 20:23:41 -0700 (PDT) Received: by 10.216.229.210 with HTTP; Wed, 2 Jun 2010 20:23:40 -0700 (PDT) Date: Wed, 2 Jun 2010 23:23:40 -0400 Message-ID: Subject: [dnsext] draft-ietf-dnsext-rfc2671bis-edns0-03 From: Donald Eastlake To: IETF DNSEXT WG Content-Type: multipart/alternative; boundary=0016e65a0826ad63be048817bb72 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016e65a0826ad63be048817bb72 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have reviewed this draft and have the following comments: Since this is intended for standards track, it can certainly change IANA Considerations. So, in Section 5, page 5, I think "requested to be" should be replaced so the relevant sentence reads "Therefore, the registry of Extended Label Types is hereby closed." Similarly, in Section 9, at the bottom of page 10, "We request that this registry be closed." -> "This registry is hereby closed." Section 9, page 11, pretty much repeats the provisions about RCODEs that were in RFC 2671. However, since then, TSIG and TKEY expanded possible RCODEs to 16 bits and IANA Considerations changes were made for RCODEs in RFC 5395. So I suggest something like the following change: OLD [RFC2671] expands the RCODE space from 4 bits to 12 bits. This allows more than the 16 distinct RCODE values allowed in [RFC1035 ]. IETF Standards Action is required to add a new RCODE. Adding new RCODEs should be avoided due to the difficulty in upgrading the installed base. This document assigns EDNS Extended RCODE 16 to "BADVERS". NEW [RFC2671] expanded the RCODE space from 4 bits to 12 bits and it was later expanded to 16 bits in connection with TSIG and TKEY. IANA Considerations for RCODEs are now specified in [RFC5395]. [RFC2671] also assigned RCODE 16 to "BADVERS". That assignment continues to be in force. Nits: In Section 6.9 at the top of page 9, there seems to be a short line where text didn't flow. Is there supposed to be a paragraph break there? Also, I think ``0.'' -> "0". Section 7, fourth line on page 10, "to to" -> "to". Section A.2: I don't understand the first point. Which constants? Section 10: I usually see the RFC2119 reference as Normative rather than Informational. Thanks, Donald --0016e65a0826ad63be048817bb72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I have reviewed this draft and have the following co= mments:

Since this is intended for standards track, it c= an certainly change IANA Considerations. So, in Section 5, page 5, I think = "requested to be" should be replaced so the relevant sentence rea= ds "Therefore, the registry of=A0Extended Label Types is hereby closed= ." Similarly, in Section 9, at the bottom of page 10, "We=A0reque= st that this registry be closed." -> "This registry is hereby = closed."

Section 9, page 11, pretty much repeats the provisions about= RCODEs that were in RFC 2671. However, since then, TSIG and TKEY expanded = possible RCODEs to 16 bits and IANA Considerations changes were made for RC= ODEs in RFC 5395. So I suggest something like the following change:
OLD
   [RFC2671] expands the RCODE=
 space from 4 bits to 12 bits.  This
   allows more than the 16 distinct RCODE values allowed in [RFC1035].
   IETF Standards Action is required to add a new RCODE.  Adding new
   RCODEs should be avoided due to the difficulty in upgrading the
   installed base.

   This document assigns EDNS Extended RCODE 16 to "BADVERS".

<=
/span>
NEW
   [RFC2671] expanded the RCOD=
E space from 4 bits to 12 bits and it
   was later expanded to 16 bits in connectio=
n with TSIG and TKEY.
   IANA Consi=
derations for RCODEs are now specified in [RFC5395].
   [RFC2671] also assigned RCODE 16 to &q=
uot;BADVERS". That assignment
   continues =
to be in force.


=
Nits:

<= /div>
In Section 6.9 at the top of page 9, there seems t= o be a short line where text didn't flow. Is there supposed to be a par= agraph break there? Also, I think ``0.'' -> "0".

Section 7, four= th line on page 10, "to to" -> "to".

Section A.2: I = don't understand the first point. Which constants?

Section 10: I u= sually see the RFC2119 reference as Normative rather than Informational.
Thanks,
Donald
--0016e65a0826ad63be048817bb72-- From owner-namedroppers@ops.ietf.org Wed Jun 2 20:37:43 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCFB728C0EE; Wed, 2 Jun 2010 20:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.932 X-Spam-Level: * X-Spam-Status: No, score=1.932 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOjCAl12xrbd; Wed, 2 Jun 2010 20:37:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 279053A67AC; Wed, 2 Jun 2010 20:37:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK1AW-000IEa-PA for namedroppers-data0@psg.com; Thu, 03 Jun 2010 03:32:32 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK1AS-000IE0-9c for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 03:32:28 +0000 Received: (qmail 9687 invoked by uid 399); 3 Jun 2010 03:32:26 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 3 Jun 2010 03:32:26 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C072248.3010803@dougbarton.us> Date: Wed, 02 Jun 2010 20:32:24 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: David Ulevitch CC: IETF DNSEXT WG Subject: Re: [dnsext] end-to-end violations in draft-vandergaast-edns-client-ip-01 References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Some snipping ... On 06/02/10 19:30, David Ulevitch wrote: > > Some background -- When I started OpenDNS numerous folks (including > Vixie) told me the market for people who wanted their responses > tampered with was zero. They wished me luck, expecting me to fail. > Today we have millions of users who use our service to control the > responses they receive as they see fit. Some of these users use this > power to block certain kinds of DNS lookups so people don't visit > MySpace or Facebook or Playboy. Some use it to prevent malware on > their network from phoning home to known botnets and divulging their > private data. Regardless of the reason, there is clearly a market for > tampered DNS responses as we've been doing this since 2006, and > profitably since 2007. Today, the vast majority of our revenue growth > is from paying enterprise customers deploying this globally. These > are not naive users by any means. > > So unfortunately, conventional wisdom disagrees with what you believe > to be common sense. David, Congratulations on your success. :) I think it's worth exploring what you've said further. You've got millions of clients who have all _opted in_ to using your service. To the extent that they understand what they've gotten themselves into they have chosen to use it with the knowledge of what they are giving up to get the benefits that you provide. So, good on you, and I hope things continue to go well for you and yours. > 2) As for privacy concerns, there is, unfortunately, no possible way > to make what is being proposed an opt-in option as determined by the > stub resolver originating the query. Not philosophically, or even > technically as far as I can think. Thanks for being honest about this. I made this same point last time around (from a different perspective) but it's good to see that we at least have some common ground here. Another poster mentioned that for those wishing to allow their customers to opt out of this service another set of resolvers could be provided that don't have this feature. I think that while that option has the merits of technical feasibility it has the significant downside that few if any ISPs would actually be willing to offer it. > Certainly resolver authors can > (and should) implement it the way we have done it so that the service > is available to some clients and not others, to some authoritative DNS > servers and not others, and for some zones not others. But still > there have been concerns that this creates a data leak that previously > did not exist. There has yet to be an example shown where this is the > case and the "interceptor" is not already situated as a man in the > middle of a plaintext DNS conversation. So I'm not sure why it > persists. And I'm not sure why you're confused. The common case is Janet User sits on one of N subnets of BigISP, her DNS queries are directed to BigISP's resolver which queries the authoritative servers for CoolWebPages.com and sends back the answer. At no point do the packets going from the resolver to the authoritative servers and back again have any information about Janet. > I think this particular bit of > energy is better directed at preserving the right for people to run > their own resolver or choose a third-party, not about dictating the > capabilities of what resolvers can and can't do when it will have no > impact on anyone else. And my assertion continues to be that this is a bad idea on its face, and therefore should not be done. Some of the reasons I think it's a bad idea are that it's a layering violation (already covered today, so I won't dwell) and that it's a privacy violation (covered in detail during the last round of discussion on this topic). I understand that you and others don't agree with these concerns, and that's ok too. However I think that as a result by definition we do not have consensus on this topic; and are not likely to reach consensus on it give the intractable nature of the positions in both camps. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Wed Jun 2 20:53:22 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74ACE3A69A3; Wed, 2 Jun 2010 20:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.045 X-Spam-Level: * X-Spam-Status: No, score=1.045 tagged_above=-999 required=5 tests=[AWL=-1.061, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6QEaDv0wQ9K; Wed, 2 Jun 2010 20:53:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 581473A6943; Wed, 2 Jun 2010 20:53:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK1Pn-000K92-O3 for namedroppers-data0@psg.com; Thu, 03 Jun 2010 03:48:19 +0000 Received: from [74.125.82.52] (helo=mail-ww0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK1Pj-000K8Y-LQ for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 03:48:16 +0000 Received: by wwi18 with SMTP id 18so191851wwi.11 for ; Wed, 02 Jun 2010 20:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4O+x+ZkHoC60pleoM4aHZzgLPln3l+r7BCjdwA9Hnco=; b=tqkRp6y7jWvZ7hZWf2fjq1Ogs94nHheE9BSbAo2/6JfEjbwAm/BVAsnXnJYlWfQn/b MO2HH/ljpOQCQxgt1eazh1dxibYcyY1wxmR2G9Tm9GPHLcRv2NsiPoR10kea8vxius/Q eKZxmZEJAL+ujt5ekyy0vOzultPIAKlQmU3/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dETVbfsQXgJ1gGzoAaoQwaC6RStTsYZT8bVNLAgbObm2ou+5paYUg8pxSobk9SmjsZ VHX4qFqJLpsJ1OAXNaa9IykAJ3y3MCUF54epVXIHVIjHeTiqYJsp4gBDTTVPOSux9gOE eUdHO//GqfRfe+QfAuvzBTVBkAJ8FGS9KvLSs= MIME-Version: 1.0 Received: by 10.216.160.132 with SMTP id u4mr654420wek.19.1275536893148; Wed, 02 Jun 2010 20:48:13 -0700 (PDT) Received: by 10.216.229.210 with HTTP; Wed, 2 Jun 2010 20:48:13 -0700 (PDT) In-Reply-To: References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> Date: Wed, 2 Jun 2010 23:48:13 -0400 Message-ID: Subject: Re: [dnsext] end-to-end violations in draft-vandergaast-edns-client-ip-01 From: Donald Eastlake To: Jim Reid Cc: IETF DNSEXT WG Content-Type: multipart/alternative; boundary=0016e65ae51069ff2304881813ab Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016e65ae51069ff2304881813ab Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 1, 2010 at 11:30 AM, Jim Reid wrote: > On 1 Jun 2010, at 16:05, Donald Eastlake wrote: > > ... > > However, to be practical, you need these intermediate boxes, like >> non-authoritative caching servers and those pesky NAT boxes, which mess up >> the end-to-end principle. >> > > Indeed. However even though we accept these middleboxes as a necessary and > probably unavoidable wart on a pure end-to-end model, this does not mean > they have a free hand to tamper with DNS queries and replies. [Like secretly > adding or removing EDNS options as this draft proposes.] And yes, I know > some middleboxes already do stupid/evil things to DNS traffic. IMO, that's > not an excuse to encourage more of that sort of behaviour. Or standardise > it. > Recursive servers do and should have a free hand to insert meta-RRs. That's what TKEY, TSIG, and OPT are for. There is nothing secret about what is proposed here. The proposal is public. It does not include encrypting DNS packets. Ohta-san is correct that DNS isn't an end-to-end communications system. It's a distributed database system that uses store and forward caching techniques. So, really, end-to-end arguments are inapplicable. Never-the-less, if you squint the right way, when a recursive server issues a query that is pretty much the same as a request it received, you could look at how close the information received as a result of that recursive query is to what would have been received if the recursive server hadn't been in the path. And you will find that the suggested experimental option makes the recursive server more transparent. Thanks, Donald --0016e65ae51069ff2304881813ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 1, 2010 at 11:30 AM, Jim Reid <jim@rfc1035.com><= /span> wrote:
On 1 Jun 2010, at 16:05, Donald Eastlake wrote:

...
However, to be practical, you need these intermediate boxes, like
non-authoritative caching servers and those pesky NAT boxes, which mess up<= br> the end-to-end principle.

Indeed. However even though we accept these middleboxes as a necessary and = probably unavoidable wart on a pure end-to-end model, this does not mean th= ey have a free hand to tamper with DNS queries and replies. [Like secretly = adding or removing EDNS options as this draft proposes.] And yes, I know so= me middleboxes already do stupid/evil things to DNS traffic. IMO, that'= s not an excuse to encourage more of that sort of behaviour. Or standardise= it.

Recursive servers do and should have= a free hand to insert meta-RRs. That's what TKEY, TSIG, and OPT are fo= r.

There is nothing secret about what is proposed = here. The proposal is public. It does not include encrypting DNS packets.= =A0

Ohta-san is correct that DNS isn't an end-to-e= nd communications system. It's a distributed database system that uses = store and forward caching techniques. So, really, end-to-end arguments are = inapplicable. Never-the-less, if you squint the right way, when a recursive= server issues a query that is pretty much the same as a request it receive= d, you could look at how close the information received as a result of that= recursive query is to what would have been received if the recursive serve= r hadn't been in the path. And you will find that the suggested experim= ental option makes the recursive server more transparent.

Thanks,
Donald
--0016e65ae51069ff2304881813ab-- From owner-namedroppers@ops.ietf.org Wed Jun 2 21:52:36 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40E0B3A67B6; Wed, 2 Jun 2010 21:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.763 X-Spam-Level: ** X-Spam-Status: No, score=2.763 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMpc3Te4VOVb; Wed, 2 Jun 2010 21:52:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3FCDE3A677C; Wed, 2 Jun 2010 21:52:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK2Kh-0000Gh-Li for namedroppers-data0@psg.com; Thu, 03 Jun 2010 04:47:07 +0000 Received: from [173.203.119.164] (helo=zularific.zerlargal.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK2Kd-0000GI-Sv for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 04:47:03 +0000 Received: from [127.0.0.1] (helo=mailrelay) by zularific.zerlargal.org with smtp (Exim 4.71) (envelope-from ) id 1OK2Kc-0006mc-1o; Thu, 03 Jun 2010 04:47:02 +0000 Received: from mailrelay by localhost; Thu, 3 Jun 2010 04:47:02 +0000 Received: from MUA by mailrelay; Thu, 3 Jun 2010 04:46:07 +0000 Date: Wed, 2 Jun 2010 21:46:05 -0700 From: Bruce Campbell To: Wilmer van der Gaast cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] latency In-Reply-To: Message-ID: References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [cc list trimmed back] On Wed, 2 Jun 2010, Wilmer van der Gaast wrote: > On 31 May 2010 16:52, Bruce Campbell wrote: >>> A latency difference of 200 or 300ms doesn't really matter by itself. >>> The problem is web pages which result in *many* DNS queries and thus >>> latency difference * N. >> Most web browsers seem to look up domain names en-mass and incur max(latency >> difference) or latency difference * number of concurrent queries, rather >> than one-by-one and thus latency difference * N. >> > I'd say difference * 2. > > It can't immediately do all lookups. It'll have to start downloading > the HTML before it will have any clue what other names it's going to > have to resolve. Naturally. >> As a corporate admin, I'd hate to have details of my internal >> infrastructure walking out along with the DNS queries, > > Which details? > > If you're running a small corporate network and are just using the > resolver run by the ISP or maybe a third party one. If the resolver > adds an edns-client-subnet option, it will just contain the /24 that > contains your external IP address (range). Agreed. In such a setup, there is little operational difference between the CDN using the information in the edns-client-subnet option which points to my egress /24, vs the CDN using the source IP address of the query from the ISP's resolver, as both my egress IP and the ISP's resolvers are highly likely to be advertised using the same routing announcement. > If you're running a bigger network, you're probably running your own > local nameserver already, and there's no need to enable > edns-client-subnet support on it since CDNs will already have enough > information to serve you. Let's expand the scope of that, and say that my internal non-RFC1918 network spans several departments which each run their own resolvers directly querying the Internet. The egress NAT ensures that the external IP address of these queries is identical irrespective of the department. However, to be in line with company policies about avoiding leakage of network information, my NAT would need to be aware of the edns-client-subnet option in order to remove or rewrite it should it be present, contrary to section 7 of -01. Naturally, all NAT/firewall devices do the Right Thing(tm) when it comes to packet modification, and my vendor won't charge excessive amounts of money when it comes time for adding a particular feature. (ha!) If my NAT is actually an Intermediate Server which supports edns-client-subnet, it needs to ignore the MUSTs and MUST NOTs in 4.1 regarding modification of any edns-client-subnet option, following instead the advice of 8.1 regarding privacy. The general gist of this comment is that in order to assure that the IP address/subnet of the original stub resolver remains private and not seen by any but the first upstream resolver, end-users and administrators must make changes to their infrastructure in order to opt-out of the edns-client-subnet option. -- Bruce. opt-out; not just for email and web pages anymore. From owner-namedroppers@ops.ietf.org Wed Jun 2 21:59:19 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B857C3A6A01; Wed, 2 Jun 2010 21:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.37 X-Spam-Level: ** X-Spam-Status: No, score=2.37 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NyQej62I4M3; Wed, 2 Jun 2010 21:59:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E2AD13A672E; Wed, 2 Jun 2010 21:59:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK2TQ-0001K5-C2 for namedroppers-data0@psg.com; Thu, 03 Jun 2010 04:56:08 +0000 Received: from [173.203.119.164] (helo=zularific.zerlargal.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK2TN-0001Jf-I0 for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 04:56:05 +0000 Received: from [127.0.0.1] (helo=mailrelay) by zularific.zerlargal.org with smtp (Exim 4.71) (envelope-from ) id 1OK2TM-0006uI-AW; Thu, 03 Jun 2010 04:56:04 +0000 Received: from mailrelay by localhost; Thu, 3 Jun 2010 04:56:04 +0000 Received: from MUA by mailrelay; Thu, 3 Jun 2010 04:55:22 +0000 Date: Wed, 2 Jun 2010 21:55:22 -0700 From: Bruce Campbell To: Ted Hardie cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] latency In-Reply-To: Message-ID: References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [cc trimmed] On Wed, 2 Jun 2010, Ted Hardie wrote: > On Wed, Jun 2, 2010 at 9:10 AM, Nicholas Weaver >> And this is yet another example of how HTTP redirects don't work: There >> is no way to say 'fetch all requests for l.yimg.com from >> a2354.l.yimg.com' with an HTTP redirect, so doing redirects wouldn't >> help here: you'd still take the latency hit FOR EACH REQUEST to >> l.yimg.com. >> > > Would a new HTTP 30x message with the meaning "all URIs from this host > and/or all URIs from this point in the hieirarchy" be a useful point to make > then? That seems like something that is useful whether you use a CDN > or are simply moving hosts from a previous name. Somewhat offtopic for DNS and really scary for HTTP. -- Bruce. From info@webmaster.com Thu Jun 3 01:36:33 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1F228C125 for ; Thu, 3 Jun 2010 01:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.452 X-Spam-Level: ** X-Spam-Status: No, score=2.452 tagged_above=-999 required=5 tests=[BAYES_80=2, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KodYGcjBoUPG for ; Thu, 3 Jun 2010 01:36:33 -0700 (PDT) Received: from mail.xmgd.com (pop3.xmgd.com [211.156.95.230]) by core3.amsl.com (Postfix) with ESMTP id C38E53A6863 for ; Thu, 3 Jun 2010 01:35:50 -0700 (PDT) Received: from xmgd.com (localhost [127.0.0.1]) by mail.xmgd.com (Postfix) with ESMTP id 14847119CA2; Thu, 3 Jun 2010 16:32:58 +0800 (CST) From: "Webmaster Departamento Admin" Reply-To: customercarewebdept210@hotmail.com Subject: Confirma Tu Cuenta=?UTF-8?Q?_Webmail=E2=80=8F?= Date: Thu, 3 Jun 2010 04:32:58 -0400 Message-Id: <20100603081553.M86265@webmaster.com> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 41.138.171.18 (lx2069@xmgd.com) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 To: undisclosed-recipients:; webmail Estimado / E-mail del usuario Notificación de correo web mantenimiento del usuario Dependencia, Estamos llevando a cabo una actualización en nuestro sitio ya que había llegado a nuestro conocimiento que algunos de nuestros suscriptores están introduciendo un virus en nuestro sitio y está afectando a nuestra red. Estamos tratando de averiguar el suscriptor específico. Por esta razón todos los los abonados a proporcionar sus datos como Nombre, Apellido Nombre, Cuenta de usuario y contraseña para que podamos verificar y hacer que se despejado contra este virus. Adviértase que la falta de respuesta a esto conducirá a suscriptores Cancelación de cuenta en las próximas 48 horas. Por lo tanto, como un usuario de nuestro sitio, es necesario que nos envíe su correo electrónico detalles de la cuenta para que podamos reconocer Actividad cuenta Por otra parte, se informó de que vamos a eliminar todas las cuentas de correo que no se activa para crear más espacio para los nuevos usuarios. Por lo tanto, son consejos que nos envíe los datos de su cuenta de correo Como se solicita a continuación: Información a enviar; Nombre: Apellido: Nombre de usuario: Contraseña: Todos los usuarios se aconsejan para completar la actualización. Un cordial saludo. 2010 Webmaster Departamento Admin. © Todos los derechos reservados From owner-namedroppers@ops.ietf.org Thu Jun 3 02:05:35 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA3B3A6979; Thu, 3 Jun 2010 02:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8Q4eMwO17Ev; Thu, 3 Jun 2010 02:05:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7AEB83A694E; Thu, 3 Jun 2010 02:05:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK6FA-0008C2-UG for namedroppers-data0@psg.com; Thu, 03 Jun 2010 08:57:40 +0000 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK6F8-0008Be-5l for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 08:57:38 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version; b=6VLQ6d0+vqcjBHPDNwC7ns7H3RDbF0zQ5XVsWt4pBTpqPacQqx7c1AfW dIg3Md6eBrCORf7c9H/pmJHQPZOPDaW5CojXlsys29XK/ix18lsBRYvqg Jg615RpUkt4eLXV; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1275555458; x=1307091458; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20Keying=20queries=20on=20information=20o utside=20the=20q-tuple=20(Re:=20[dnsext]=0D=0A=20Personal =20position=20on=20adopting=20the=20client-subnet=20optio n)|Date:=20Thu,=203=20Jun=202010=2008:57:28=20+0000 |Message-ID:=20 |To:=20Alex=20Bligh=20,=20Nicholas=20We aver=20|CC:=20"namedroppers@op s.ietf.org"=20|MIME-Version: =201.0|Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20 |In-Reply-To:=20; bh=XwxCEIlYLjo6nRj/n3WLEyY6qUw2PWrg7PKDCE7Zrx8=; b=ucA9J42kI8NwVDVm2kSyK32J+PeC79DztUTzsfaxmKWLlfQc+Ra3R4hC NujQ5a2SFV96u60g1Jvyzn0jB/7yX9zznzFSno979Z0Ct7dudq6/6mUaQ WMwJ/cRouJZAOdP; X-IronPort-AV: E=Sophos;i="4.53,353,1272841200"; d="scan'208";a="19039084" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 03 Jun 2010 09:57:32 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%20]) with mapi; Thu, 3 Jun 2010 09:57:32 +0100 From: Ray Bellis To: Alex Bligh , Nicholas Weaver CC: "namedroppers@ops.ietf.org" Subject: Re: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) Thread-Topic: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) Thread-Index: AQHLAm3VCBqEzcbAjEaJDCrG+mNUIZJuyXUAgAABZ4CAAAGagIAAAIkAgAAJmwCAARogAA== Date: Thu, 3 Jun 2010 08:57:28 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 02/06/2010 18:07, "Alex Bligh" wrote: > I /think/ Ray's tests found something like this (though I have a habit > of false memory when it comes to Ray's tests). :) We certainly found some units that barfed completely in the presence of *any* EDNS0 options. That's consistent with what Nick has seen on Netalyzr= . We didn't check for "unusual" EDNS0 options - the only thing we were specifically testing for was the EDNS0 buffer size. Ray From owner-namedroppers@ops.ietf.org Thu Jun 3 02:40:55 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9164E3A6944; Thu, 3 Jun 2010 02:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.276 X-Spam-Level: X-Spam-Status: No, score=-100.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UB7symQGd+yg; Thu, 3 Jun 2010 02:40:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0DDF63A6867; Thu, 3 Jun 2010 02:40:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK6rJ-000EKe-AJ for namedroppers-data0@psg.com; Thu, 03 Jun 2010 09:37:05 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK6rE-000E9L-Oq for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 09:37:02 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o539X56H015845; Thu, 3 Jun 2010 09:33:20 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o539WdQn015841; Thu, 3 Jun 2010 09:32:39 GMT Date: Thu, 3 Jun 2010 09:32:34 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews Cc: bmanning@vacation.karoshi.com, Colm =?iso-8859-1?Q?MacC=E1rthaigh?= , namedroppers@ops.ietf.org Subject: Re: [dnsext] DNS cache design spec Message-ID: <20100603093234.GB15519@vacation.karoshi.com.> References: <201005312334.o4VNY3lN099586@drugs.dv.isc.org> <20100601170605.GB4379@vacation.karoshi.com.> <201006020250.o522om7B049085@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201006020250.o522om7B049085@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Jun 02, 2010 at 12:50:48PM +1000, Mark Andrews wrote: > > In message <20100601170605.GB4379@vacation.karoshi.com.>, bmanning@vacation.kar > oshi.com writes: > > On Tue, Jun 01, 2010 at 09:34:03AM +1000, Mark Andrews wrote: > > > > > > Part of the problem is that caches now go from 1 RRset per name to > > > 1 RRset per client. That is a fundamental change in design > > > constraints. > > > > is there an IETF RFC on DNS cache design? > > It's implict in the design. It the intent was to supply different > answers to different clients then there would have been provision > for it in RFC 1033, RFC 1034 and RFC 1035. I read general guidelines about how the cache should behave -externally- in regard to specific, enumerated RR types in those three documents, but I don't see any explicit design documents on cache design, management, and in the case of newer DNS features, behaviour. wrt changing the design from a single RRset per name to a single RRset per client (whatever that means)... we have seen this movie before, when the concept of an "atomic" RRset was created - the atomic unit used to be (and still sort of is) the individual RR. The RRset is functionally a convience for working with DNSSEC. (yes, we can re-open this rat hole, but it might be better left closed - i'm just pointing out that we have changed behaviour before -in the ABSENCE of a clear cache design spec- and so doing it again doesn't seem all that bad. We need an explict cache design spec if we are going to argue that this is a "fundamental change in design constraints" - to borrow your words. IMHO of course. --bill > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Thu Jun 3 04:08:22 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767FE3A6983; Thu, 3 Jun 2010 04:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.198 X-Spam-Level: X-Spam-Status: No, score=-97.198 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5cINhgGYk8m; Thu, 3 Jun 2010 04:08:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6F7C3A69B4; Thu, 3 Jun 2010 04:08:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK8Cp-0003kh-HZ for namedroppers-data0@psg.com; Thu, 03 Jun 2010 11:03:23 +0000 Received: from [74.125.121.35] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OK8Cm-0003kB-PO for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 11:03:21 +0000 Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o53B3GvT016444 for ; Thu, 3 Jun 2010 04:03:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275562998; bh=ENP7hBGTzHTu6kB+CO2VRXeMwpE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=mcezvIWEp32GL3XN+jTfebrwMuR/4WN7r7x+BIeEXdTf791n6+RgUKRXVHQGoIxPH fmvUgXjGNavfIpGvd4qHQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=PCfcQva++jA/6DcpDVUpG+ZIsgcFn05uNiO9Wad7F3zFfHiBqrOgNT8luAyjLRRQa CuA7v6TRZjnbmXx9oRYIA== Received: from bwz11 (bwz11.prod.google.com [10.188.26.11]) by kpbe20.cbf.corp.google.com with ESMTP id o53B3E4c005448 for ; Thu, 3 Jun 2010 04:03:15 -0700 Received: by bwz11 with SMTP id 11so675351bwz.5 for ; Thu, 03 Jun 2010 04:03:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.83.211 with SMTP id g19mr2806117bkl.44.1275562948051; Thu, 03 Jun 2010 04:02:28 -0700 (PDT) Received: by 10.204.50.9 with HTTP; Thu, 3 Jun 2010 04:02:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Jun 2010 12:02:27 +0100 Message-ID: Subject: Re: Keying queries on information outside the q-tuple (Re: [dnsext] Personal position on adopting the client-subnet option) From: Wilmer van der Gaast To: Ray Bellis Cc: Alex Bligh , Nicholas Weaver , "namedroppers@ops.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 3 June 2010 09:57, Ray Bellis wrote: > > We certainly found some units that barfed completely in the presence of > *any* EDNS0 options. =A0That's consistent with what Nick has seen on Neta= lyzr. > I've seen this not only with consumer hardware, but also with for example Citrix Netscalers in certain configurations (when using a DNS vserver instead of a simple blind 53/UDP one). I've had this problem myself and there are other examples: nibbler~$ dig +nsid www.microsoft.com @65.55.37.62 ; <<>> DiG 9.6.1-P3 <<>> +nsid www.microsoft.com @65.55.37.62 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 17573 [...] It seems to be fine with EDNS0 otherwise, but is not aware of the concept of options *at all*. Wilmer. --=20 Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From owner-namedroppers@ops.ietf.org Thu Jun 3 06:29:39 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA73F3A69D2; Thu, 3 Jun 2010 06:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.771 X-Spam-Level: ** X-Spam-Status: No, score=2.771 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlTe0XtLpaDW; Thu, 3 Jun 2010 06:29:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 166C23A67AB; Thu, 3 Jun 2010 06:29:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKAOO-0001pU-Ck for namedroppers-data0@psg.com; Thu, 03 Jun 2010 13:23:28 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKAOL-0001nY-Hk for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 13:23:25 +0000 Received: (qmail 56824 invoked from network); 3 Jun 2010 13:43:13 -0000 Received: from softbank219001188004.bbtec.net (HELO ?192.168.1.27?) (219.1.188.4) by necom830.hpcl.titech.ac.jp with SMTP; 3 Jun 2010 13:43:13 -0000 Message-ID: <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> Date: Thu, 03 Jun 2010 22:22:23 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Nicholas Weaver CC: Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Subject: Re: [dnsext] latency References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> In-Reply-To: <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Nicholas Weaver wrote: > Rather, what would have to happen to see the latency savings > without the DNS games is the web page itself would need to be > dynamically generated and customized for my IP address, > replacing every reference to l.yimg.com with a reference to > something like a2354.l.yimg.com. I thought queries to www.yahoo.com should be redirected to www50.yahoo.com, HTML files from which "statically" include l50.yimg.com, not l.yimg.com, which does not need any new specification. But, feel free to develop dynamic generation or whatever, as long as it does not purposelessly complicate DNS. Masataka Ohta From owner-namedroppers@ops.ietf.org Thu Jun 3 07:57:02 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1883A6839; Thu, 3 Jun 2010 07:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+IRKLZy7KVL; Thu, 3 Jun 2010 07:57:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7602A3A67A3; Thu, 3 Jun 2010 07:57:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKBlU-000H7L-0K for namedroppers-data0@psg.com; Thu, 03 Jun 2010 14:51:24 +0000 Received: from [131.111.8.133] (helo=ppsw-33.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKBlN-000H5q-S7 for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 14:51:18 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:33337) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1OKBlL-0001cP-iw (Exim 4.70) (return-path ); Thu, 03 Jun 2010 15:51:15 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OKBlL-0002Ms-TU (Exim 4.67) (return-path ); Thu, 03 Jun 2010 15:51:15 +0100 Date: Thu, 3 Jun 2010 15:51:15 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Brian Dickson cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: client-subnet - questions for the authors, and outside-the-box brainstorming In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, 2 Jun 2010, Brian Dickson wrote: > > Have the "big cache" (resolvers) actually be authoritative for the CDN > "trick" zones, by way of being slaves. Your idea implies that you have to standardize the logic in the stunt authoritative server so that the open resolver can do it on behalf of the CDN. This isn't feasible because this logic is part of the CDN's secret sauce, so they wouldn't want to offload it onto another company or ossify it into a standard. Your idea would also require extensions to the master file format and to AXFR and IXFR to encode complicated information about the CDN's connectivity for use by the stunt DNS logic, which is a lot less plausible than the EDNS option we have been discussing. Tony. -- f.anthony.n.finch http://dotat.at/ LUNDY: EAST, VEERING SOUTH LATER, 3 OR 4. SLIGHT OR MODERATE. SHOWERS LATER. MODERATE OR GOOD, OCCASIONALLY POOR. From owner-namedroppers@ops.ietf.org Thu Jun 3 08:08:27 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232EE3A69D2; Thu, 3 Jun 2010 08:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGWwLrYXtapU; Thu, 3 Jun 2010 08:08:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD45D3A6981; Thu, 3 Jun 2010 08:08:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKBx8-000JRZ-DJ for namedroppers-data0@psg.com; Thu, 03 Jun 2010 15:03:26 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKBx4-000JQP-Tv for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 15:03:22 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 9A0C4A45E8 for ; Thu, 3 Jun 2010 15:03:21 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] latency In-Reply-To: Your message of "Wed, 02 Jun 2010 21:55:22 MST." References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 03 Jun 2010 15:03:21 +0000 Message-ID: <78457.1275577401@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Wed, 2 Jun 2010 21:55:22 -0700 > From: Bruce Campbell > > > Would a new HTTP 30x message with the meaning "all URIs from this host > > and/or all URIs from this point in the hieirarchy" be a useful point to > > make then? That seems like something that is useful whether you use a > > CDN or are simply moving hosts from a previous name. > > Somewhat offtopic for DNS and really scary for HTTP. and yet, since the option now being proposed is web-specific, solving it in the http protocol rather than in the dns protocol seems indicated. that is, if the only practical way to develop the www is via cdn's who absolutely cannot function or scale without explicit latency management features, then the place i'd expect to see this solved is in the web transport (http). From owner-namedroppers@ops.ietf.org Thu Jun 3 08:14:42 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4719028C19D; Thu, 3 Jun 2010 08:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_50=0.001, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUcsFNUNUV1N; Thu, 3 Jun 2010 08:14:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CB8CD28C1A2; Thu, 3 Jun 2010 08:14:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKC3e-000KeR-0c for namedroppers-data0@psg.com; Thu, 03 Jun 2010 15:10:10 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKC3a-000KdW-2i for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 15:10:06 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o53EdRSj011150; Thu, 3 Jun 2010 07:39:27 -0700 (PDT) References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> In-Reply-To: <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: [dnsext] latency Date: Thu, 3 Jun 2010 07:39:27 -0700 To: Masataka Ohta X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 3, 2010, at 6:22 AM, Masataka Ohta wrote: > Nicholas Weaver wrote: >=20 >> Rather, what would have to happen to see the latency savings > > without the DNS games is the web page itself would need to be > > dynamically generated and customized for my IP address, >> replacing every reference to l.yimg.com with a reference to >> something like a2354.l.yimg.com. >=20 > I thought queries to www.yahoo.com should be redirected to > www50.yahoo.com, HTML files from which "statically" include > l50.yimg.com, not l.yimg.com, which does not need any > new specification. In order to do THAT, you end up exporting www2350.yahoo.com into the = browser's bar, bookmarks, etc, which is COMPLETELY unacceptable to most = site designers! > But, feel free to develop dynamic generation or whatever, as > long as it does not purposelessly complicate DNS. What complication? These tricks are not only well established, but at = this point, should be considered part of DNS because they ARE part of = DNS. =20 Where does it state that an authority will return the COMPLETE RRSet = associated with a name lookup, rather than a chosen subset? Or do you = really want 50,000 answers for www.google.com? Because "authority choses a subset based on the resolver querying" has = become established practice, and at this point has been established = practice for well over a decade. =20 All this proposal does is ensure that established practice will still = work as well when third party resolvers are used, because the = information leakage when you use the local resolver is already = sufficient for the authority to chose a GOOD subset. From owner-namedroppers@ops.ietf.org Thu Jun 3 08:23:11 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0916C3A69D2; Thu, 3 Jun 2010 08:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.356 X-Spam-Level: ** X-Spam-Status: No, score=2.356 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV99S3Bt3cRT; Thu, 3 Jun 2010 08:23:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E8D483A68BF; Thu, 3 Jun 2010 08:23:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCC8-000MlI-Of for namedroppers-data0@psg.com; Thu, 03 Jun 2010 15:18:56 +0000 Received: from [209.85.213.180] (helo=mail-yx0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCC2-000Mjr-Ur for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 15:18:51 +0000 Received: by yxd5 with SMTP id 5so144785yxd.11 for ; Thu, 03 Jun 2010 08:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mZILXhRf9fj60TBsweLZ6nxlQfkI3tWJJKDgUjbTVA0=; b=DTZXwoFI4DdNwFgs5WNGWqWcwHp35as6mrZpXclTdWQRPeCZE+4hZWY/+cf1+y9kne APqyEaE9h649GlL5rVy0SD/gdgEnR5fLkul9aOQDhlSrGaNix2mipPeC1nGS/CSWHqV7 BN7ZXhG4Qya7eGYnAKDHFol9bJcKtI0uiIwUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=R9/f6hxmPrn4qvQSRxVuu7LSQPrqcgN5FFQ+qKAvVDd/KbSOPZ7FZH26kgdAg/MdJI 3MI1IvSNdrYsPwB9fop5rD5O02CBzftusTbE+q43H3uQAOf0v1nvOyM1ADYm4wGbU5iV KMm15EK6KbJsH+JEKbz8rPDrXTo1HrX4uXaJo= MIME-Version: 1.0 Received: by 10.101.11.32 with SMTP id o32mr10473129ani.98.1275578329716; Thu, 03 Jun 2010 08:18:49 -0700 (PDT) Received: by 10.100.8.14 with HTTP; Thu, 3 Jun 2010 08:18:47 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Jun 2010 12:18:47 -0300 Message-ID: Subject: Re: [dnsext] Re: client-subnet - questions for the authors, and outside-the-box brainstorming From: Brian Dickson To: Tony Finch Cc: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=0016e68fa36b39db79048821b917 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016e68fa36b39db79048821b917 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 3, 2010 at 11:51 AM, Tony Finch wrote: > On Wed, 2 Jun 2010, Brian Dickson wrote: > > > > Have the "big cache" (resolvers) actually be authoritative for the CDN > > "trick" zones, by way of being slaves. > > Your idea implies that you have to standardize the logic in the stunt > authoritative server so that the open resolver can do it on behalf of the > CDN. This isn't feasible because this logic is part of the CDN's secret > sauce, so they wouldn't want to offload it onto another company or ossify > it into a standard. I'd like to hear it from them, that this is the case, if it is indeed the case. AFAIK, the "secret sauce" is in the "how" of doing geo-IP, and the "how" of transmogrifying web pages on their web servers. The DNS side, to an outside observer, looks like DNS, because it has to. The only differences are in the quantity of entries, and the rate at which they are updated. > Your idea would also require extensions to the master > file format and to AXFR and IXFR to encode complicated information about > the CDN's connectivity for use by the stunt DNS logic, which is a lot less > plausible than the EDNS option we have been discussing. > > Yes. However, it scales better, removes caching issues (TTLs, lack of pre-fetch, cacheability, lack of "push"/notify), and is by its very nature completely compatible with existing clients and resolvers (where existing can include really old, obsolete systems). I don't think it directly touches AXFR/IXFR. It does, however, definitely require some means for automated provisioning of zones, i.e. delegate, create, modify, delete, undelegate, etc. This could be out-of-band, or more likely, via some kind of convention to some kind of well-known child zones, along the lines of _srv "magic". > Tony. > -- > f.anthony.n.finch http://dotat.at/ > LUNDY: EAST, VEERING SOUTH LATER, 3 OR 4. SLIGHT OR MODERATE. SHOWERS > LATER. > MODERATE OR GOOD, OCCASIONALLY POOR. > Brian --0016e68fa36b39db79048821b917 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 3, 2010 at 11:51 AM, Tony Finch = <dot@dotat.at><= /span> wrote:
On Wed, 2 Jun 2010, Brian Dickson wrote:
>
> Have the "big cache" (resolvers) actually be authoritative f= or the CDN
> "trick" zones, by way of being slaves.

Your idea implies that you have to standardize the logic in the stunt=
authoritative server so that the open resolver can do it on behalf of the CDN. This isn't feasible because this logic is part of the CDN's se= cret
sauce, so they wouldn't want to offload it onto another company or ossi= fy
it into a standard.

I'd like to hear it from them= , that this is the case, if it is indeed the case.

AFAIK, the "= secret sauce" is in the "how" of doing geo-IP, and the "= ;how" of transmogrifying web pages on their web servers.
The DNS side, to an outside observer, looks like DNS, because it has to. Th= e only differences are in the quantity of entries, and the rate at which th= ey are updated.

=A0
Your idea would also require extensions to the master
file format and to AXFR and IXFR to encode complicated information about the CDN's connectivity for use by the stunt DNS logic, which is a lot l= ess
plausible than the EDNS option we have been discussing.


Yes. However, it scales b= etter, removes caching issues (TTLs, lack of pre-fetch, cacheability, lack = of "push"/notify), and is by its very nature completely compatibl= e with existing clients and resolvers (where existing can include really ol= d, obsolete systems).

I don't think it directly touches AXFR/IXFR.

It does, howeve= r, definitely require some means for automated provisioning of zones, i.e. = delegate, create, modify, delete, undelegate, etc. This could be out-of-ban= d, or more likely, via some kind of convention to some kind of well-known c= hild zones, along the lines of _srv "magic".
=A0
Tony.
--
f.anthony.n.finch =A0<dot@dotat.at&g= t; =A0http://dotat.at/
LUNDY: EAST, VEERING SOUTH LATER, 3 OR 4. SLIGHT OR MODERATE. SHOWERS= LATER.
MODERATE OR GOOD, OCCASIONALLY POOR.

Brian
--0016e68fa36b39db79048821b917-- From owner-namedroppers@ops.ietf.org Thu Jun 3 08:42:51 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3272E3A68BF; Thu, 3 Jun 2010 08:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaBZefd+lHR7; Thu, 3 Jun 2010 08:42:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 29F703A687E; Thu, 3 Jun 2010 08:42:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCVc-0000Sw-90 for namedroppers-data0@psg.com; Thu, 03 Jun 2010 15:39:04 +0000 Received: from [209.85.211.177] (helo=mail-yw0-f177.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCVY-0000SO-Fl for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 15:39:00 +0000 Received: by ywh7 with SMTP id 7so258581ywh.26 for ; Thu, 03 Jun 2010 08:38:59 -0700 (PDT) Received: by 10.150.193.10 with SMTP id q10mr9054711ybf.105.1275579538095; Thu, 03 Jun 2010 08:38:58 -0700 (PDT) Received: from [192.168.1.187] ([65.103.127.225]) by mx.google.com with ESMTPS id u1sm8792436ybe.8.2010.06.03.08.38.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jun 2010 08:38:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: [dnsext] latency From: Sean Leach In-Reply-To: <78457.1275577401@nsa.vix.com> Date: Thu, 3 Jun 2010 09:38:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <78457.1275577401@nsa.vix.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 3, 2010, at 9:03 AM, Paul Vixie wrote: >> Date: Wed, 2 Jun 2010 21:55:22 -0700 >> From: Bruce Campbell >>=20 >>> Would a new HTTP 30x message with the meaning "all URIs from this = host >>> and/or all URIs from this point in the hieirarchy" be a useful point = to >>> make then? That seems like something that is useful whether you use = a >>> CDN or are simply moving hosts from a previous name. >>=20 >> Somewhat offtopic for DNS and really scary for HTTP. >=20 > and yet, since the option now being proposed is web-specific, solving = it in > the http protocol rather than in the dns protocol seems indicated. = that is, > if the only practical way to develop the www is via cdn's who = absolutely > cannot function or scale without explicit latency management features, = then > the place i'd expect to see this solved is in the web transport = (http). >=20 not web specific - i may use this to direct you to the closest SMTP = server, SIP proxy etc. From owner-namedroppers@ops.ietf.org Thu Jun 3 08:43:33 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770DA28C164; Thu, 3 Jun 2010 08:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fP2C1eM+x+1; Thu, 3 Jun 2010 08:43:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 367FE28C162; Thu, 3 Jun 2010 08:43:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCXK-0000pM-N5 for namedroppers-data0@psg.com; Thu, 03 Jun 2010 15:40:50 +0000 Received: from [131.111.8.132] (helo=ppsw-32.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCXH-0000oe-Is for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 15:40:47 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:58194) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1OKCXG-0007bt-33 (Exim 4.70) (return-path ); Thu, 03 Jun 2010 16:40:46 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OKCXG-0002XH-U4 (Exim 4.67) (return-path ); Thu, 03 Jun 2010 16:40:46 +0100 Date: Thu, 3 Jun 2010 16:40:46 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Brian Dickson cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: client-subnet - questions for the authors, and outside-the-box brainstorming In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, 3 Jun 2010, Brian Dickson wrote: > > AFAIK, the "secret sauce" is in the "how" of doing geo-IP, and the "how" of > transmogrifying web pages on their web servers. > The DNS side, to an outside observer, looks like DNS, because it has to. The > only differences are in the quantity of entries, and the rate at which they > are updated. No, the key difference is that the DNS replies are generated dynamically by the geo-IP logic. Tony. -- f.anthony.n.finch http://dotat.at/ PLYMOUTH: EAST 4 OR 5, BECOMING VARIABLE 3 OR 4 LATER. SLIGHT OR MODERATE. FAIR. MODERATE OR GOOD. From owner-namedroppers@ops.ietf.org Thu Jun 3 08:57:39 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769AB3A684C; Thu, 3 Jun 2010 08:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjko1RggM6R7; Thu, 3 Jun 2010 08:57:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 826C73A6934; Thu, 3 Jun 2010 08:57:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCi8-00031r-Q5 for namedroppers-data0@psg.com; Thu, 03 Jun 2010 15:52:00 +0000 Received: from [131.111.8.133] (helo=ppsw-33.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCi1-0002zp-84 for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 15:51:53 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:52909) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1OKChd-0007rY-i3 (Exim 4.70) (return-path ); Thu, 03 Jun 2010 16:51:29 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OKChd-0004Lk-Kb (Exim 4.67) (return-path ); Thu, 03 Jun 2010 16:51:29 +0100 Date: Thu, 3 Jun 2010 16:51:29 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Nicholas Weaver cc: Masataka Ohta , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Subject: Re: [dnsext] latency In-Reply-To: <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> Message-ID: References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, 3 Jun 2010, Nicholas Weaver wrote: > > Where does it state that an authority will return the COMPLETE RRSet > associated with a name lookup, rather than a chosen subset? RFC 2181 section 5.1. This doesn't actually prevent you from returning inconsistent or dynamic results, because you can pretend that each result comes from a different instance of the zone. Tony. -- f.anthony.n.finch http://dotat.at/ IRISH SEA: SOUTHEAST 3 OR 4, OCCASIONALLY 5 LATER. SMOOTH OR SLIGHT. SHOWERS LATER. MODERATE OR GOOD, OCCASIONALLY POOR LATER. From owner-namedroppers@ops.ietf.org Thu Jun 3 09:07:01 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1400E28C148; Thu, 3 Jun 2010 09:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.262 X-Spam-Level: X-Spam-Status: No, score=-100.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycW2UU9lw43G; Thu, 3 Jun 2010 09:06:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6212C3A684C; Thu, 3 Jun 2010 09:06:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCtn-00064s-Dz for namedroppers-data0@psg.com; Thu, 03 Jun 2010 16:04:03 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCtf-0005na-J7 for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 16:04:00 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o53G296H017678; Thu, 3 Jun 2010 16:02:24 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o53G1sCs017677; Thu, 3 Jun 2010 16:01:54 GMT Date: Thu, 3 Jun 2010 16:01:49 +0000 From: bmanning@vacation.karoshi.com To: Sean Leach Cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] latency Message-ID: <20100603160149.GB17577@vacation.karoshi.com.> References: <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <78457.1275577401@nsa.vix.com> <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Jun 03, 2010 at 09:38:55AM -0600, Sean Leach wrote: > > On Jun 3, 2010, at 9:03 AM, Paul Vixie wrote: > > >> Date: Wed, 2 Jun 2010 21:55:22 -0700 > >> From: Bruce Campbell > >> > >>> Would a new HTTP 30x message with the meaning "all URIs from this host > >>> and/or all URIs from this point in the hieirarchy" be a useful point to > >>> make then? That seems like something that is useful whether you use a > >>> CDN or are simply moving hosts from a previous name. > >> > >> Somewhat offtopic for DNS and really scary for HTTP. > > > > and yet, since the option now being proposed is web-specific, solving it in > > the http protocol rather than in the dns protocol seems indicated. that is, > > if the only practical way to develop the www is via cdn's who absolutely > > cannot function or scale without explicit latency management features, then > > the place i'd expect to see this solved is in the web transport (http). > > > > > not web specific - i may use this to direct you to the closest SMTP server, SIP proxy etc. > > closest? how does the third party (C), discover and indicate to client (A) about the path between (A) and content (B)? I'll posit C has not any basis other than presumption and hubris to suggest anything about a path that it is not a part of; tht when/if we do figure that out, are we talking about closest as RTT, same IP block, shared ASN, or some other metric? --bill From owner-namedroppers@ops.ietf.org Thu Jun 3 09:07:31 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 941173A684C; Thu, 3 Jun 2010 09:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.921 X-Spam-Level: X-Spam-Status: No, score=-3.921 tagged_above=-999 required=5 tests=[AWL=1.127, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4EhDbmyJM70; Thu, 3 Jun 2010 09:07:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA5313A6843; Thu, 3 Jun 2010 09:07:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCtS-00060Y-6p for namedroppers-data0@psg.com; Thu, 03 Jun 2010 16:03:42 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCtL-0005za-8r for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 16:03:35 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o53G3Y5Y020184; Thu, 3 Jun 2010 09:03:34 -0700 (PDT) References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <78457.1275577401@nsa.vix.com> <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> In-Reply-To: <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <12F0F28E-555A-4E54-A6D2-4820856F3EF2@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: [dnsext] latency Date: Thu, 3 Jun 2010 09:03:34 -0700 To: Sean Leach X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 3, 2010, at 8:38 AM, Sean Leach wrote: >=20 > On Jun 3, 2010, at 9:03 AM, Paul Vixie wrote: >=20 >>> Date: Wed, 2 Jun 2010 21:55:22 -0700 >>> From: Bruce Campbell >>>=20 >>>> Would a new HTTP 30x message with the meaning "all URIs from this = host >>>> and/or all URIs from this point in the hieirarchy" be a useful = point to >>>> make then? That seems like something that is useful whether you = use a >>>> CDN or are simply moving hosts from a previous name. >>>=20 >>> Somewhat offtopic for DNS and really scary for HTTP. >>=20 >> and yet, since the option now being proposed is web-specific, solving = it in >> the http protocol rather than in the dns protocol seems indicated. = that is, >> if the only practical way to develop the www is via cdn's who = absolutely >> cannot function or scale without explicit latency management = features, then >> the place i'd expect to see this solved is in the web transport = (http). >>=20 >=20 >=20 > not web specific - i may use this to direct you to the closest SMTP = server, SIP proxy etc. Probably the most useful non-web one would be the proper VPN tunnel: If = you are a company with east-coast location and a west-coast location, = having=20 vpn.mycompany.com resolve to an east-coast host to east-coast users, and west-coast hosts = to west-coast users, is a BIG performance win if your VPN software = doesn't support the notion of redirects. From owner-namedroppers@ops.ietf.org Thu Jun 3 09:08:17 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2953A6843; Thu, 3 Jun 2010 09:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQHDMadk9tIE; Thu, 3 Jun 2010 09:08:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B470E3A684C; Thu, 3 Jun 2010 09:08:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCuZ-0006Gt-Ok for namedroppers-data0@psg.com; Thu, 03 Jun 2010 16:04:51 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCuW-0006GE-1v for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 16:04:48 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id D56AAA4627 for ; Thu, 3 Jun 2010 16:04:46 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] latency In-Reply-To: Your message of "Thu, 03 Jun 2010 09:38:55 CST." <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <78457.1275577401@nsa.vix.com> <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 03 Jun 2010 16:04:46 +0000 Message-ID: <82867.1275581086@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Sean Leach > Date: Thu, 3 Jun 2010 09:38:55 -0600 > > not web specific - i may use this to direct you to the closest SMTP > server, SIP proxy etc. nobody in the smtp or sip communities is arguing that their industry cannot continue to thrive without explicit latency management. if they do i'll be surprised, since the MX RR and the NAPTR/SRV RRs work well. arguments about predictivity of latency based on ip address have been done, here and elsewhere, many times. cisco's "director" products did not capture the market as well as akamai's services have done, not just because "ping" and BGP as-path are poor predictors of TCP performance, but because it takes a *lot* of viewpoints integrated coherently to form any kind of valid statistical basis. and even so, there are IP cutouts and wormholes that form stumbling blocks. only global empires need apply. it's very hard for me to want a DNS option that only supports one industry, and at that, an industry who has heard many times that DNS is a publication mechanism for truth not policy, and that they need to use it as intented, and that their claims about what they can do with DNS are either snake oil or are impediments to global deployment of things like DNSSEC. an option that only does any good on its rare best day if content is available from a thousand different mirrors run by a global empire is also hard to understand. this goes beyond snake oil, it's cost shifting. i'm looking at a CDN response: +--- | ;; QUESTION SECTION: | ;www.microsoft.com. IN A | | ;; ANSWER SECTION: | www.microsoft.com. 3600 IN CNAME toggle.www.ms.akadns.net. | toggle.www.ms.akadns.net. 300 IN CNAME g.www.ms.akadns.net. | g.www.ms.akadns.net. 300 IN CNAME lb1.www.ms.akadns.net. | lb1.www.ms.akadns.net. 300 IN A 65.55.21.250 +--- post-kaminsky, those CNAMEs are useless. an iterator has to restart and requery after each CNAME, even those which appear to be in-zone by virtue of being siblings to the QNAME, or which appear to be children of the same set of authority servers as the QNAME. because any CNAME target could be, in real life, a zone cut. credibility of CNAME chains has gone to zero, and the proper resolution for "www.microsoft.com" now takes four RTT's. but, akamai's marketing continues unabated, and no doubt recursive server implementors are afraid to do CNAME restarts because it will make them slower than the implementors who don't do CNAME restarts. i've never been comfortable having a protocol's evolution controlled by the installed base. (which is why we push out new code in BIND every time we find we're in the wrong, and why we gradually change defaults to move the installed base along.) anyway i've tried hard not to repeat myself, as the chairs have requested. From owner-namedroppers@ops.ietf.org Thu Jun 3 09:11:53 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1168028C0E2; Thu, 3 Jun 2010 09:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.342 X-Spam-Level: X-Spam-Status: No, score=-100.342 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2vXUba3mN4k; Thu, 3 Jun 2010 09:11:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 996E728C0F2; Thu, 3 Jun 2010 09:11:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCyb-0006xo-7B for namedroppers-data0@psg.com; Thu, 03 Jun 2010 16:09:01 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKCy8-0006kf-Dz for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 16:08:58 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o53Frj6H017630; Thu, 3 Jun 2010 15:54:00 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o53FqcBf017626; Thu, 3 Jun 2010 15:52:38 GMT Date: Thu, 3 Jun 2010 15:52:33 +0000 From: bmanning@vacation.karoshi.com To: Nicholas Weaver Cc: Masataka Ohta , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Subject: Re: [dnsext] latency Message-ID: <20100603155233.GA17577@vacation.karoshi.com.> References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Jun 03, 2010 at 07:39:27AM -0700, Nicholas Weaver wrote: > > What complication? These tricks are not only well established, but at this point, should be considered part of DNS because they ARE part of DNS. > > Where does it state that an authority will return the COMPLETE RRSet associated with a name lookup, rather than a chosen subset? Or do you really want 50,000 answers for www.google.com? > > Because "authority choses a subset based on the resolver querying" has become established practice, and at this point has been established practice for well over a decade. > Hum... really? RFC 2181 - 5.1 states: 5.1. Sending RRs from an RRSet A query for a specific (or non-specific) label, class, and type, will always return all records in the associated RRSet - whether that be one or more RRs. The response must be marked as "truncated" if the entire RRSet will not fit in the response. draft-iab-dns-choices states: Every resource record (RR) matching a particular name, type and class is said to belong to the same resource record set (RRset), and the whole RRset is always returned to the client which queries for it. Splitting an RRset is a protocol violation, because it results in coherency problems with the DNS caching mechanism. Note however that this requirement has nothing to do with the MTU size and choice of UDP or TCP as the transport protocol. The whole RRset always has to be returned, and if it doesn't fit in the MTU in UDP, TCP has to be used to not break this RRset atomic requirement. so, if, as you state, authority servers "pick and choose" a subset to return to a query... that authority is violating the protocol. --bill From owner-namedroppers@ops.ietf.org Thu Jun 3 09:15:42 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B3C28C0F2; Thu, 3 Jun 2010 09:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.179 X-Spam-Level: * X-Spam-Status: No, score=1.179 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKReNAqgCdSs; Thu, 3 Jun 2010 09:15:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E64C3A6934; Thu, 3 Jun 2010 09:15:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKD2G-0007cL-9M for namedroppers-data0@psg.com; Thu, 03 Jun 2010 16:12:48 +0000 Received: from [209.85.160.180] (helo=mail-gy0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKD29-0007bC-Gu for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 16:12:41 +0000 Received: by gyg13 with SMTP id 13so326402gyg.11 for ; Thu, 03 Jun 2010 09:12:40 -0700 (PDT) Received: by 10.150.246.8 with SMTP id t8mr9891664ybh.97.1275581560521; Thu, 03 Jun 2010 09:12:40 -0700 (PDT) Received: from [192.168.1.187] ([65.103.127.225]) by mx.google.com with ESMTPS id u8sm8971535ybe.18.2010.06.03.09.12.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Jun 2010 09:12:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: [dnsext] latency From: Sean Leach In-Reply-To: <82867.1275581086@nsa.vix.com> Date: Thu, 3 Jun 2010 10:12:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5860F8E7-4230-4F77-99B5-78F67D7F4232@wiggum.com> References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <78457.1275577401@nsa.vix.com> <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> <82867.1275581086@nsa.vix.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 3, 2010, at 10:04 AM, Paul Vixie wrote: >> From: Sean Leach >> Date: Thu, 3 Jun 2010 09:38:55 -0600 >>=20 >> not web specific - i may use this to direct you to the closest SMTP >> server, SIP proxy etc. >=20 > nobody in the smtp or sip communities is arguing that their industry > cannot continue to thrive without explicit latency management. if they > do i'll be surprised, since the MX RR and the NAPTR/SRV RRs work well. >=20 on the contrary - I had several of the external anti-spam providers want = this very functionality (and a few VoIP providers). i don't claim to = speak for them, just what they asked me for while i was at = ultradns/neustar From owner-namedroppers@ops.ietf.org Thu Jun 3 09:19:18 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A995628C0F9; Thu, 3 Jun 2010 09:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQByChwI9tTe; Thu, 3 Jun 2010 09:19:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8ADE93A684C; Thu, 3 Jun 2010 09:19:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKD5l-0008Zn-LB for namedroppers-data0@psg.com; Thu, 03 Jun 2010 16:16:25 +0000 Received: from [131.111.8.130] (helo=ppsw-30.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKD5f-0008W8-4z for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 16:16:19 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:32794) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1OKD4w-00038O-d0 (Exim 4.70) (return-path ); Thu, 03 Jun 2010 17:15:34 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OKD4w-0008Mf-2L (Exim 4.67) (return-path ); Thu, 03 Jun 2010 17:15:34 +0100 Date: Thu, 3 Jun 2010 17:15:34 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: bmanning@vacation.karoshi.com cc: Nicholas Weaver , Masataka Ohta , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Subject: Re: [dnsext] latency In-Reply-To: <20100603155233.GA17577@vacation.karoshi.com.> Message-ID: References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> <20100603155233.GA17577@vacation.karoshi.com.> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, 3 Jun 2010, bmanning@vacation.karoshi.com wrote: > > so, if, as you state, authority servers "pick and choose" a subset to > return to a query... that authority is violating the protocol. I note that dynamic geo-IP DNS responses are "just" a more elaborate version of BIND's "view" feature. Tony. -- f.anthony.n.finch http://dotat.at/ LUNDY: EAST, VEERING SOUTH LATER, 3 OR 4. SLIGHT OR MODERATE. SHOWERS LATER. MODERATE OR GOOD, OCCASIONALLY POOR. From owner-namedroppers@ops.ietf.org Thu Jun 3 09:26:14 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6E9B3A6874; Thu, 3 Jun 2010 09:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-HWOqUzU2f5; Thu, 3 Jun 2010 09:26:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 87E4B3A6843; Thu, 3 Jun 2010 09:26:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDCD-0009pL-F1 for namedroppers-data0@psg.com; Thu, 03 Jun 2010 16:23:05 +0000 Received: from [131.111.8.133] (helo=ppsw-33.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDC7-0009o8-9b for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 16:22:59 +0000 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:60177) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1OKDC6-0005AD-gt (Exim 4.70) (return-path ); Thu, 03 Jun 2010 17:22:58 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1OKDC6-000195-98 (Exim 4.67) (return-path ); Thu, 03 Jun 2010 17:22:58 +0100 Date: Thu, 3 Jun 2010 17:22:58 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] latency In-Reply-To: <82867.1275581086@nsa.vix.com> Message-ID: References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <78457.1275577401@nsa.vix.com> <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> <82867.1275581086@nsa.vix.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, 3 Jun 2010, Paul Vixie wrote: > > impediments to global deployment of things like DNSSEC Last time I discussed this I came to the conclusion that it should be feasible to sign all the possible answer RR sets ahead of time, so it's possible for a dynamic geo-IP DNS service to support DNSSEC. (Something like the pool.ntp.org service may need to return fewer A records in its reply; really silly stunts like returning the queryer's IP address in the reply (!) would require online signature generation...) > credibility of CNAME chains has gone to zero Aside from them being a protocol violation and unusable at zone cuts where many sites now like to put their web servers... Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT: NORTHERLY OR NORTHWESTERLY 3 OR 4, OCCASIONALLY 5 IN NORTHEAST. SMOOTH OR SLIGHT, BECOMING MODERATE FOR A TIME IN NORTHEAST. MAINLY FAIR. MODERATE OR GOOD, OCCASIONALLY POOR LATER. From owner-namedroppers@ops.ietf.org Thu Jun 3 09:35:44 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ADC23A69DD; Thu, 3 Jun 2010 09:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.981 X-Spam-Level: X-Spam-Status: No, score=-3.981 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgT3kdS6XPSx; Thu, 3 Jun 2010 09:35:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6E763A6843; Thu, 3 Jun 2010 09:35:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDLU-000Btc-VD for namedroppers-data0@psg.com; Thu, 03 Jun 2010 16:32:40 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDLS-000BtI-Mp for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 16:32:38 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o53G2UHd020110; Thu, 3 Jun 2010 09:02:30 -0700 (PDT) References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> <20100603155233.GA17577@vacation.karoshi.com.> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: bmanning@vacation.karoshi.com, Masataka Ohta , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: [dnsext] latency Date: Thu, 3 Jun 2010 09:02:30 -0700 To: Nicholas Weaver X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 3, 2010, at 9:01 AM, Nicholas Weaver wrote: >>=20 >> Hum... really? >>=20 >> RFC 2181 - 5.1 states: >>=20 >> 5.1. Sending RRs from an RRSet >>=20 >> A query for a specific (or non-specific) label, class, and type, = will >> always return all records in the associated RRSet - whether that be >> one or more RRs. The response must be marked as "truncated" if the >> entire RRSet will not fit in the response. >=20 > I stand corrected. Except for one teeny-weeny little note: ITs now a = decade+ of established practice for authorities to NOT return the full = RRSet. Do you really want the full RRSet for www.l.google.com? Also, such splitting is NOT a coherency problem: All subsets chosen = will respond properly, and represent proper hosts for www.l.google.com. From owner-namedroppers@ops.ietf.org Thu Jun 3 09:36:16 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511A13A69C5; Thu, 3 Jun 2010 09:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.034 X-Spam-Level: X-Spam-Status: No, score=-4.034 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwC37NX6lByt; Thu, 3 Jun 2010 09:36:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C9343A6843; Thu, 3 Jun 2010 09:36:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDKe-000Ba6-UI for namedroppers-data0@psg.com; Thu, 03 Jun 2010 16:31:48 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDKc-000BZb-Cn for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 16:31:46 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o53G1EqN019994; Thu, 3 Jun 2010 09:01:14 -0700 (PDT) References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> <20100603155233.GA17577@vacation.karoshi.com.> In-Reply-To: <20100603155233.GA17577@vacation.karoshi.com.> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , Masataka Ohta , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: [dnsext] latency Date: Thu, 3 Jun 2010 09:01:14 -0700 To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 3, 2010, at 8:52 AM, bmanning@vacation.karoshi.com wrote: > On Thu, Jun 03, 2010 at 07:39:27AM -0700, Nicholas Weaver wrote: >>=20 >> What complication? These tricks are not only well established, but at = this point, should be considered part of DNS because they ARE part of = DNS. =20 >>=20 >> Where does it state that an authority will return the COMPLETE RRSet = associated with a name lookup, rather than a chosen subset? Or do you = really want 50,000 answers for www.google.com? >>=20 >> Because "authority choses a subset based on the resolver querying" = has become established practice, and at this point has been established = practice for well over a decade. =20 >>=20 >=20 > Hum... really? >=20 > RFC 2181 - 5.1 states: >=20 > 5.1. Sending RRs from an RRSet >=20 > A query for a specific (or non-specific) label, class, and type, = will > always return all records in the associated RRSet - whether that be > one or more RRs. The response must be marked as "truncated" if the > entire RRSet will not fit in the response. I stand corrected. Except for one teeny-weeny little note: ITs now a = decade+ of established practice for authorities to NOT return the full = RRSet. Do you really want the full RRSet for www.l.google.com? From owner-namedroppers@ops.ietf.org Thu Jun 3 09:45:16 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D4B3A6820; Thu, 3 Jun 2010 09:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.032 X-Spam-Level: *** X-Spam-Status: No, score=3.032 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd8O7eJgkcnS; Thu, 3 Jun 2010 09:45:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C62FF3A63C9; Thu, 3 Jun 2010 09:45:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDUL-000DGq-2i for namedroppers-data0@psg.com; Thu, 03 Jun 2010 16:41:49 +0000 Received: from [209.85.161.52] (helo=mail-fx0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDUF-000DFv-O4 for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 16:41:43 +0000 Received: by fxm10 with SMTP id 10so358958fxm.11 for ; Thu, 03 Jun 2010 09:41:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.193.11 with SMTP id g11mr306735hbi.77.1275583300821; Thu, 03 Jun 2010 09:41:40 -0700 (PDT) Received: by 10.239.174.12 with HTTP; Thu, 3 Jun 2010 09:41:40 -0700 (PDT) In-Reply-To: References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <78457.1275577401@nsa.vix.com> <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> <82867.1275581086@nsa.vix.com> Date: Thu, 3 Jun 2010 09:41:40 -0700 Message-ID: Subject: Re: [dnsext] latency From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Tony Finch Cc: Paul Vixie , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Jun 3, 2010 at 9:22 AM, Tony Finch wrote: > On Thu, 3 Jun 2010, Paul Vixie wrote: >> >> impediments to global deployment of things like DNSSEC > > Last time I discussed this I came to the conclusion that it should be > feasible to sign all the possible answer RR sets ahead of time, so it's > possible for a dynamic geo-IP DNS service to support DNSSEC. There may be some qualifications. For NSEC(3) users - records must really either exist or not exist in all "views". Otherwise an NXDOMAIN from a view where a record does not exist would be replay-able to other queriers. Similarly, "incorrect" DNSSEC-signed answers are replay-able across views, though that doesn't seem as harmful an attack. > (Something like the pool.ntp.org service may need to return fewer A > records in its reply; really silly stunts like returning the queryer's IP > address in the reply (!) would require online signature generation...) Even for silly stunts, the signatures are cacheable for re-use. -- Colm From owner-namedroppers@ops.ietf.org Thu Jun 3 09:52:47 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4811A3A6934; Thu, 3 Jun 2010 09:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.082 X-Spam-Level: X-Spam-Status: No, score=-4.082 tagged_above=-999 required=5 tests=[AWL=0.966, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCkR0ZUtK1mu; Thu, 3 Jun 2010 09:52:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E9ACF3A63C9; Thu, 3 Jun 2010 09:52:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDaf-000EdB-Rz for namedroppers-data0@psg.com; Thu, 03 Jun 2010 16:48:21 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDac-000Ecl-SC for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 16:48:18 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o53Gm1UJ024398; Thu, 3 Jun 2010 09:48:01 -0700 (PDT) References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <78457.1275577401@nsa.vix.com> <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> <82867.1275581086@nsa.vix.com> In-Reply-To: <82867.1275581086@nsa.vix.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <249063C1-8A85-4243-8A7B-0BB73F64F233@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: [dnsext] latency Date: Thu, 3 Jun 2010 09:48:00 -0700 To: Paul Vixie X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 3, 2010, at 9:04 AM, Paul Vixie wrote: > i'm looking at a CDN response: >=20 > +--- > | ;; QUESTION SECTION: > | ;www.microsoft.com. IN A > |=20 > | ;; ANSWER SECTION: > | www.microsoft.com. 3600 IN CNAME = toggle.www.ms.akadns.net. > | toggle.www.ms.akadns.net. 300 IN CNAME g.www.ms.akadns.net. > | g.www.ms.akadns.net. 300 IN CNAME = lb1.www.ms.akadns.net. > | lb1.www.ms.akadns.net. 300 IN A 65.55.21.250 > +--- I'm looking at another one which uses the same CDN tricks on DNS: ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 94112 IN CNAME www.l.google.com. www.l.google.com. 72 IN A 74.125.19.147 www.l.google.com. 72 IN A 74.125.19.99 www.l.google.com. 72 IN A 74.125.19.103 www.l.google.com. 72 IN A 74.125.19.104 The long CNAME chains are not necessary for CDN-type tricks to work. = Especially long CNAME chains with short TTLs. Microsoft could just as = easily have www.microsoft.com CNAME lb.www.ms.akadns.net TTL 100000 like Google does. And DNS, for all your harping about it, IS a policy tool: Its used all = the time by all different people to block or redirect or manage traffic. = =20 Heck, bind supports it! How is the basic CDN trick different from a = programatic view? From owner-namedroppers@ops.ietf.org Thu Jun 3 09:55:02 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 685C03A6826; Thu, 3 Jun 2010 09:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fER2M91+d7Y; Thu, 3 Jun 2010 09:55:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B0923A63C9; Thu, 3 Jun 2010 09:55:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDdh-000F61-Ni for namedroppers-data0@psg.com; Thu, 03 Jun 2010 16:51:29 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDde-000F5O-Ll for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 16:51:26 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o53GpQT2024868; Thu, 3 Jun 2010 09:51:26 -0700 (PDT) Subject: [dnsext] Not quite OT: on format=flowed Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Content-Type: text/plain; charset=us-ascii Message-Id: Date: Thu, 3 Jun 2010 09:51:25 -0700 Cc: Nicholas Weaver To: IETF DNSEXT WG Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: There was one complaint recently on a thread about how some mail = was no longer being sent with format=3Dflowed. With, of course, no info on who was sending such "offending" = messages! Hardly helpful... Well, here's the thing: Mac Mail USED to use format=3Dflowed = and delsp=3Dyes (RFC 3676), up until 10.6.2. Then Apple dropped them = both (because actually, you need BOTH). So what does these options do? Well, it basically allows the = text/plain format to NOT be text/plain. =20 Instead, it indicates that the mail reader can undo = pseudo-linebreaks and word wrap however it desires, but in order to = provide compatibility with old (*cough* Unix *cough*) tools focused = around the notion of an 80 character, fixed-width font, the message was = sent with a 72 character linewrapping using a convention of "space CRLF" = as a linefeed that can be removed. So why did Apple drop this? Why? Simply put, because it seems some mail clients never did = this right: =46rom the 10.6.2 release notes: "improved line wrapping compatibility = when sending to certain mail clients and Microsoft Exchange Server" So if you have a mail client that uses a variable width font but = never redid the line breaks, you'd get ugly stuff if its format=3Dflowed, = delsp=3Dyes. So they decided to drop that and instead just send plain text = with no additional linebreaks. So why is this discussion relevant? a: In developing software, you can't please everybody. =20 format=3Dflowed, delsp=3Dyes was supposed to make it so that old = stuff could stay, well, broken. But it relied on new stuff = (non-fixed-width font using stuff) to respect the option. Instead there = developed a situation where you have TWO different classes of = brokenness: 1) Fixed-width stuff that doesn't linebreak non-line-broken text. 2) Variable-width stuff that doesn't relinebreak already line-broken = text. And the result is you CAN NOT please both: One or the other has = to get ugly. For the longest time, the decision was obviously to favor = class 1. Now its to favor class 2. =20 This is perfectly fine IMO as long as things are explicit about = it. Pick-your-poison moments happen all the time. b: In deciding which brokenness to respect and which to say "go = F-yourself", you need to decide whether the amount of brokenness = matters. Obviously, Apple decided that the old Unix side is now less = important than variable-width mail readers. This in particular makes me worry about fragments, EDNS, and = DNSSEC. Its probably OK to say "go F-yourself" (or at least hit = performance seriously) on networks that assume DNS<=3D512B or EDNS = doesn't exist. This is actually relatively rare in measurements on the = resolver side. =20 But it is probably NOT OK to assume UDP fragments work. c: Established practice can trump standards. format=3Dflowed, delsp=3Dyes is a 6+ year old standard. But = because there were significant modernish (variable-width) mail readers = not accepting the convention, Apple dropped it. Similarly, RFC 2181 says that the authority should return all = records for the associated RRSet. Nobody who's hosting an RRSet of = >100+ entries (eg, www.google.com) in their right mind actually does = this. The DNS tricks underlying CDN distribution are now established = practice, no matter what the standard says. d: Don't expect multisided client change to fix things. Why did apple drop format=3Dflowed, delsp=3Dyes? Because the = client changes to support it simply weren't happening. This is why I really find AMAZINGLY silly the arguments that = "Because the CDN DNS tricks mostly affect just HTTP service, HTTP should = change to support the necessary redirect semantics". =20 If you can't get a few mail-readers to linewrap text right! what = makes you think you can get every web browser to change to support a = different mechanism for redirection (that is largely unnecessary because = the CDN DNS tricks largely DO work today!). From owner-namedroppers@ops.ietf.org Thu Jun 3 10:06:30 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 631A528C0F6; Thu, 3 Jun 2010 10:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEsXaA1o2iv9; Thu, 3 Jun 2010 10:06:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 41D6C28C0EF; Thu, 3 Jun 2010 10:06:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDnn-000HGn-FL for namedroppers-data0@psg.com; Thu, 03 Jun 2010 17:01:55 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDng-000HEm-Nw for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 17:01:48 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 6F717A465D for ; Thu, 3 Jun 2010 17:01:48 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] latency In-Reply-To: Your message of "Thu, 03 Jun 2010 10:12:37 CST." <5860F8E7-4230-4F77-99B5-78F67D7F4232@wiggum.com> References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <78457.1275577401@nsa.vix.com> <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> <82867.1275581086@nsa.vix.com> <5860F8E7-4230-4F77-99B5-78F67D7F4232@wiggum.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 03 Jun 2010 17:01:48 +0000 Message-ID: <86391.1275584508@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Sean Leach > Date: Thu, 3 Jun 2010 10:12:37 -0600 > > on the contrary - I had several of the external anti-spam providers want > this very functionality (and a few VoIP providers). i don't claim to > speak for them, just what they asked me for while i was at > ultradns/neustar assuming for a moment that this was a representative sample of those industries, and the internet really does need explicit latency management for many applications, i'd like to see IETF start up a working group on the topic, to decide where it belongs in the stack and to develop a problem statement and so on. interactions between proxies and nats that make it often impossible for a client to have "an IP address" mean that latency might depend on more than just that. this seems, at the moment, beyond the scope of DNSEXT, even if many members of this WG would also be members of that one. From owner-namedroppers@ops.ietf.org Thu Jun 3 10:17:47 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0A23A6892; Thu, 3 Jun 2010 10:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=-1.303, BAYES_50=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rMji+jnd0NL; Thu, 3 Jun 2010 10:17:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93DC93A6872; Thu, 3 Jun 2010 10:17:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDyM-000Iph-J2 for namedroppers-data0@psg.com; Thu, 03 Jun 2010 17:12:50 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKDyF-000Iov-B0 for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 17:12:43 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 061C5A4669 for ; Thu, 3 Jun 2010 17:12:43 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: [dnsext] Not quite OT: on format=flowed In-Reply-To: Your message of "Thu, 03 Jun 2010 09:51:25 MST." References: X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 03 Jun 2010 17:12:42 +0000 Message-ID: <87087.1275585162@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: incidentally, but perhaps illuminatingly, i find it bizarre that folks will just buy a new computer and use whatever Mail.app it comes with, and change their personal practices as nec'y to conform to the limitations of the tool. i wear out my computers every few years and i pick new ones based in part on their ability to support my existing personal practices and preferred tools. i say "illuminatingly" because this may underscore other positions. > From: Nicholas Weaver > Date: Thu, 3 Jun 2010 09:51:25 -0700 > ... > If you can't get a few mail-readers to linewrap text right! what > makes you think you can get every web browser to change to support > a different mechanism for redirection (that is largely unnecessary > because the CDN DNS tricks largely DO work today!). because in http, there are dominant open source implementations of both the browser (firefox) and server (apache), and the rest of the industry has to play ketchup with those, no matter how commercially successful they are or how many eyeballs or how much content they control. "sweet." From owner-namedroppers@ops.ietf.org Thu Jun 3 11:25:43 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B480F3A69DE; Thu, 3 Jun 2010 11:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.273 X-Spam-Level: X-Spam-Status: No, score=-101.273 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVgarqqARYVG; Thu, 3 Jun 2010 11:25:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3599D3A69B0; Thu, 3 Jun 2010 11:25:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKF0r-0003n4-48 for namedroppers-data0@psg.com; Thu, 03 Jun 2010 18:19:29 +0000 Received: from [216.239.44.51] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKF0j-0003mD-5A for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 18:19:21 +0000 Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o53IJIkB018956 for ; Thu, 3 Jun 2010 11:19:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275589159; bh=HhuwuXvAamRIyi8T1K/I8fPb9mM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=FRTUfM0We4HU9blds4MgGdW+a0kQ12hT0Muvd6GeZlcm0gFHnwuzWIT7VIP3BZ3dM JUHKq2GHlKkw2f8v4NAfw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=YGswQaQK2b50yXVzrUzxFAWYQwH6Q9VwMd+HWSTIhlSHa8F7BgrmN0ir+K/p1Xdzj 1aZ1XI4it4lsw94SrpZWQ== Received: from vws1 (vws1.prod.google.com [10.241.21.129]) by kpbe11.cbf.corp.google.com with ESMTP id o53IJHAb022877 for ; Thu, 3 Jun 2010 11:19:17 -0700 Received: by vws1 with SMTP id 1so492449vws.21 for ; Thu, 03 Jun 2010 11:19:17 -0700 (PDT) Received: by 10.220.126.166 with SMTP id c38mr7163051vcs.49.1275589157214; Thu, 03 Jun 2010 11:19:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.128.139 with HTTP; Thu, 3 Jun 2010 11:18:56 -0700 (PDT) In-Reply-To: References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> From: Carlo Contavalli Date: Thu, 3 Jun 2010 11:18:56 -0700 Message-ID: Subject: Re: [dnsext] latency To: Bruce Campbell Cc: Wilmer van der Gaast , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Jun 2, 2010 at 9:46 PM, Bruce Campbell wrote: > > The general gist of this comment is that in order to assure that the IP > address/subnet of the original stub resolver remains private and not seen by > any but the first upstream resolver, end-users and administrators must make > changes to their infrastructure in order to opt-out of the > edns-client-subnet option. > No. They just won't enable edns-client-ip to begin with? eg, your resolver within your private network will not add an edns-client-ip option. This is what's suggested in the draft wrt private addresses, and implementations should not enable edns-client-ip by default, and definitively not add private addresses. Also, what purpose would serve enabling edns-client-ip forwarding private addresses? eg, it definitively doesn't help finding a better result for your query, it would probably be discarded by the authoritative name server, and ... the source ip in packets (address of NAT box) is actually the best address that can be used to try to return a server that's close to the NAT box, eg, the exit point of the private network. In case of tunnels or configurations where DNS queries exit from a different point than the rest of the tcp traffic, nothing prevents an ISP or network administrator from adding an edns-client-ip headers to hint the authoritative server in the right direction finding a better reply. Which is an improvement over the current world, where dns tricks are being used, and there is no way for ISPs or CDNs to get the best results for their customers in a case like the one described above, ending up introducing 100s of ms of latency on their users. Carlo From owner-namedroppers@ops.ietf.org Thu Jun 3 11:40:25 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F08F3A6A0A; Thu, 3 Jun 2010 11:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_31=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWmPJl75GXN2; Thu, 3 Jun 2010 11:40:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B3C43A67D9; Thu, 3 Jun 2010 11:40:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKFGg-0006Vn-ST for namedroppers-data0@psg.com; Thu, 03 Jun 2010 18:35:50 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKFGa-0006V9-HM for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 18:35:44 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o53IZP6T010339; Thu, 3 Jun 2010 11:35:25 -0700 (PDT) References: <87087.1275585162@nsa.vix.com> In-Reply-To: <87087.1275585162@nsa.vix.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <12B32EA6-3060-4DE7-9958-7E1EE4E761BE@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , IETF DNSEXT WG From: Nicholas Weaver Subject: Re: [dnsext] Not quite OT: on format=flowed Date: Thu, 3 Jun 2010 11:35:24 -0700 To: Paul Vixie X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 3, 2010, at 10:12 AM, Paul Vixie wrote: > incidentally, but perhaps illuminatingly, i find it bizarre that folks = will > just buy a new computer and use whatever Mail.app it comes with, and = change > their personal practices as nec'y to conform to the limitations of the = tool. >=20 > i wear out my computers every few years and i pick new ones based in = part > on their ability to support my existing personal practices and = preferred > tools. i say "illuminatingly" because this may underscore other = positions. Uh, that has nothing to do with my choice of mail reader. I actually = stuck with mutt for a long time after switching platforms.... And it actually isn't a limitation on MY tool, but OTHER tools: there is = a pick-your-poison design decision that the authors of my mail client = had to make, which in either case ONLY affect stupid tools: old Unix = tools that mistakenly assume that DNS is 512B, err, that all mail is 72 = character lines of fixed-width text, or new gui tools that do not = understand that you can have plain text with a trivial amount of = additional, in-band formatting and still call it "plain text" as a = mimetype. >> From: Nicholas Weaver >> Date: Thu, 3 Jun 2010 09:51:25 -0700 >> ... >> If you can't get a few mail-readers to linewrap text right! what >> makes you think you can get every web browser to change to = support >> a different mechanism for redirection (that is largely = unnecessary >> because the CDN DNS tricks largely DO work today!). >=20 > because in http, there are dominant open source implementations of = both the > browser (firefox) and server (apache), and the rest of the industry = has to > play ketchup with those, no matter how commercially successful they = are or > how many eyeballs or how much content they control. "sweet." I didn't know you were a comedian Paul. Look at HTTP pipelining: Only Opera dares support it on by default, and = thats in the HTTP 1.1 standard right from the get-go. Apache does it = just fine. And that is a huge performance win, in a business which = cares a lot about speed. =20 And Firefox has supported it for YEARS, but doesn't enable it. Why? = because there are random broken proxies and old IIS servers that barf on = it, and Firefox's pipelining code even includes special-casing of old = IIS servers. [1] Effectively, HTTP pipelining is a "universal deployment" problem, you = need ALL servers and proxies not to barf on it before you turn it on, or = you need to have intelligent fallback detection that causes things to = fail gracefully when you DO have something that barfs on it. Similarly, a "HTTP site redirect" option would require both new server = and new client options, you need it to STILL work with old clients, and = you'd still be burning 3 more RTTs when compared with just sending the = client to the right host in the first place which you can do today with = DNS tricks. And as far as clients, IE is probably the most important despite what = open-source evangelists think: what IE does is the standard in many = cases and OTHERS have to play catch-up. In fact, we have code in the = Netalyzr web page to deal specifically with an IE6 rendering bug. If Apple, after for YEARS pushing out mail which is standard-compliant = with format=3Dflowed, stop and gave up because of a universal deployment = problem and that shoving standard-compliant mail down the throat of = incompliant tools didn't get the tools to change, what hope do you = really think there would be for an HTTP-level redirect, especially when = the problem is already largely solved by DNS authority behavior, except = in the rather perverted cases (eg, third party resolvers) where DNS goes = on a widely divergent path compared with the rest of the user's traffic. [1] And its also far less important if that nice DNS authority sends you = to a web server thats 20ms away instead of 100ms away... Amdahl's law = and all that good stuff. From owner-namedroppers@ops.ietf.org Thu Jun 3 12:29:35 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A6373A6A0F; Thu, 3 Jun 2010 12:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.711 X-Spam-Level: * X-Spam-Status: No, score=1.711 tagged_above=-999 required=5 tests=[AWL=-1.009, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOHpup+1vhuA; Thu, 3 Jun 2010 12:29:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C2F0A3A6972; Thu, 3 Jun 2010 12:29:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKG1l-000FNO-8q for namedroppers-data0@psg.com; Thu, 03 Jun 2010 19:24:29 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKG1h-000FMT-LI for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 19:24:26 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o53JOJ72019827; Thu, 3 Jun 2010 15:24:20 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4C080160.7050605@ogud.com> Date: Thu, 03 Jun 2010 15:24:16 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= CC: namedroppers Subject: Re: [dnsext] Chairs statement on "client-option" debate References: <4C054F87.5010608@ogud.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 02/06/2010 12:56 PM, Colm MacCárthaigh wrote: > On Tue, Jun 1, 2010 at 11:20 AM, Olafur Gudmundsson wrote: >> #2 Problem statement: >> We think we are close to understanding what the problem statement is. But >> there is need for a concise one that does not >> intermingle "misunderstanding" and problem. What we mean here is >> that CDN people have made an assumption that resolvers are >> "close" to "host making query", DNS people have to large extent >> never agreed with this assumption. >> The problem statement needs to be explicit about what the issues are. > > I've been trying to come up with a problem statement candidate, but am > having some difficulty with the advice here. > > Firstly, I don't agree that CDN people have made such an assumption - > in my experience of dealing with several CDNs and their operators, > they have directly measured the correlation between resolvers and > client hosts and have some confidence in it. Naturally each CDN keeps These are two different things, yes we know that large majority of clients has used resolvers that are close to them, but that does not mean it has to be that way. The number of resolvers that were "distant" from the clients was a small group, but it is a growing group ===> thus the storm in a teapot that DNS needs to be fixed. As David Ulevitch said last night, OpenDNS has millions of clients ==> this is big enough population that CDN vendors needed to suddenly pay attention. (combine that with UltraDNS and Google offering Recursive resolvers for anyone). > that data to itself, which doesn't help convince anyone else. But > experiments are runnable to gather this data, for example - it is > relatively straightforward to figure out what resolver a client is > using; I'm not sure any experiment will resolve the issue as this is a moving target. I forget who said on this list few days ago something like: "We have been pushing ISP's to use many smaller recursive resolvers" This to me indicates that CDN providers have been aware of the issue and trying to minimize it, but the rise in usage of fourth party recursive resolvers (not CDN, not user, not ISP) is not amenable to the same "fixes". > > http://whatsmyresolver.stdlib.net/ > > wrapping that up as a simple image render and purchasing a few million > advertising impressions (for a charitable cause) spread across the > internet would be one way to gather the specific data. If this kind of > data is useful, and would help convince anyone - that's one option. Of > course it's time, and money. > > However, I'm confused as to why the assumption matters. Even if the > above were not the case, and CDN operators were making assumptions, > and those assumptions are false - why does that matter for this > option? The point that Andrew and I were trying to get to is: what is the basic core problem and what are the consequences of the problem NOT what the proposed solution is and its implications. Once we have a rough consensus what the problem/issue is, it is much easier to talk about solution spaces. The push back from the DNS crowd can be paraphrased as: "This is the way DNS is supposed to work, making any assumptions about IP address of 'requestor' by looking at the address of the Resolver will be wrong some of the time." > This option is about forwarding client subnet information, the > issue of correlation should be moot. Hence, I don't think it's > possible to frame a correct problem statement that references an issue > that doesn't really matter for the problem at hand. My version of the > problem statement is; > > "Some CDN and Resolver operators would like to cooperate to provide > client network information to authoritative servers in > an open and inter-operable manner that is also respectful of > end-user privacy". > This is partial statement it does not give any background. i.e. you are justifying the proposed solution w/o saying what the basic problem is. Why do they want the information, i.e. what are the benefits. > I don't think this group will ever agree on the justification or > non-justification of DNS tricks, with any amount of data - there are > obviously more fundamental differences of opinion. I don't think > adoption of the option would encourage, or discourage the use of DNS > tricks where they are not already - it's simply about making one > use-case better for end-users. I think it's possible to be tolerant of > this difference of opinion within the group, and still engineer. Just > as many disagree on the DNSCurve/DNSSEC boundaries, that shouldn't > prevent technical progress on both. > I agree there will be "religious" disagreements between the different interpretations of what DNS is and what it is supposed to be. We have different branches of the DNS-religion and each one thinks their interpretation is the correct one. For that reason we go by rough-consensus, but to get to that point we need to know what the problem is. As for DNScurve and DNSSEC I expect progress to be made on that front. DNScurve is IMHO (not as chair) an attractive alternate to TSIG/TKEY and has potential to protect the last mile as well as referrals. Olafur PS: I From owner-namedroppers@ops.ietf.org Thu Jun 3 12:49:39 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703C63A6A0E; Thu, 3 Jun 2010 12:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.856 X-Spam-Level: * X-Spam-Status: No, score=1.856 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbzdZ-Fbq3WV; Thu, 3 Jun 2010 12:49:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 838583A6895; Thu, 3 Jun 2010 12:49:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKGL0-000IKR-Kg for namedroppers-data0@psg.com; Thu, 03 Jun 2010 19:44:22 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKGKw-000IIv-Uu for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 19:44:19 +0000 Received: (qmail 13598 invoked by uid 399); 3 Jun 2010 19:44:16 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 3 Jun 2010 19:44:16 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C08060F.7050306@dougbarton.us> Date: Thu, 03 Jun 2010 12:44:15 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Sean Leach CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] latency References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <78457.1275577401@nsa.vix.com> <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> In-Reply-To: <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 06/03/10 08:38, Sean Leach wrote: > not web specific - i may use this to direct you to the closest SMTP server, SIP proxy etc. As Mark A. has pointed out repeatedly in this and other contexts, SMTP (and mail protocols generally) are not latency-sensitive. SIP certainly is, but there are 2 possibilities for SIP, either it's in a static location, in which case it can be optimized fairly easily in a static configuration (or even a dynamic one if the provider is clever); or it's moving around from location to location. I submit that the case of dynamic locations for SIP clients at this time is enough of an edge case not to warrant more profound changes at other layers, but would welcome evidence to the contrary. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Thu Jun 3 12:49:53 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505783A68E6; Thu, 3 Jun 2010 12:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.273 X-Spam-Level: X-Spam-Status: No, score=-97.273 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4V6AlqcvcWjG; Thu, 3 Jun 2010 12:49:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 563B43A6972; Thu, 3 Jun 2010 12:49:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKGLc-000ISk-Sn for namedroppers-data0@psg.com; Thu, 03 Jun 2010 19:45:00 +0000 Received: from [74.125.121.35] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKGLZ-000ISQ-7f for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 19:44:57 +0000 Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o53Jisog005304 for ; Thu, 3 Jun 2010 12:44:54 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275594294; bh=AG7uFFErBXeOUbOF6++KKsM/zns=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=JKDo5AqVbEep/+bAgTLAfGSMupKKMeey25zP1mVtYksZTW2OwiXtI8H36jkwWGpBh 7QiYMOWxqS2gPv91W6YWw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=DWopKfZM0Shbs/7TpuraAuWSItazM16gFLwsyggG5z+vRZ3fEZOn0ER7pgUXwz3sq /U0/21rLOgHeSJd5kATMA== Received: from vws9 (vws9.prod.google.com [10.241.21.137]) by wpaz29.hot.corp.google.com with ESMTP id o53JiF7S013676 for ; Thu, 3 Jun 2010 12:44:53 -0700 Received: by vws9 with SMTP id 9so620676vws.39 for ; Thu, 03 Jun 2010 12:44:52 -0700 (PDT) Received: by 10.220.47.219 with SMTP id o27mr7118044vcf.209.1275594292416; Thu, 03 Jun 2010 12:44:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.128.139 with HTTP; Thu, 3 Jun 2010 12:44:32 -0700 (PDT) In-Reply-To: References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> From: Carlo Contavalli Date: Thu, 3 Jun 2010 12:44:32 -0700 Message-ID: Subject: Re: [dnsext] latency To: Bruce Campbell Cc: Wilmer van der Gaast , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Ups, I also honestly misread Bruce's email. He was explicitly talking about a network where hosts have non-RFC1918 addresses, but are still going through a NAT box to get more privacy. Apologies. On Thu, Jun 3, 2010 at 11:18 AM, Carlo Contavalli wrote: > On Wed, Jun 2, 2010 at 9:46 PM, Bruce Campbell > wrote: >> >> The general gist of this comment is that in order to assure that the IP >> address/subnet of the original stub resolver remains private and not seen by >> any but the first upstream resolver, end-users and administrators must make >> changes to their infrastructure in order to opt-out of the >> edns-client-subnet option. >> > > No. They just won't enable edns-client-ip to begin with? eg, your > resolver within your private network will not add an edns-client-ip > option. This is still true: eg, each resolver for each department will have edns-client-ip disabled, unless you explicitly enable it, so authoritative servers (or other intermediate servers) will only see the IP of you recursive resolver (which, by being NATted, will probably be the address of the NAT box), exactly like today. Eg, you opt-in by enabling the option on your recursive resolver, which should be disabled by default. Yes, the NAT / security box will need to support the option if you want it to be able to filter out edns-client-subnet, or mangle the option at will, but this is true even if the protocol was architected to have clients use some other, more end-to-end, opt-in mechanism. And it's basically true for any protocol modification.. and I bet that most of the modifications those boxes do to traffic are in violation of RFCs. I also bet that many NAT/security boxes by default remove things they don't know about, which ... make the world a sensibly worse place in terms of supporting protocol changes, but should generally work. I'd personally be open to changing the requirements in section 4.1, to say that an Intermediate Server with edns-client-subnet support MAY reduce the number of bits in SOURCE NETMASK, if people think that would be a good idea. The rest of my previous mail was pretty much tied to a different case than Bruce described. Sorry about that, hope this replies makes more sense :) Carlo From owner-namedroppers@ops.ietf.org Thu Jun 3 13:00:37 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E483A6A20; Thu, 3 Jun 2010 13:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.891 X-Spam-Level: * X-Spam-Status: No, score=1.891 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4b3R50g+bmD; Thu, 3 Jun 2010 13:00:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C24763A68B7; Thu, 3 Jun 2010 13:00:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKGWe-000KN7-Oo for namedroppers-data0@psg.com; Thu, 03 Jun 2010 19:56:24 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKGWY-000KLa-0t for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 19:56:18 +0000 Received: (qmail 5149 invoked by uid 399); 3 Jun 2010 19:56:17 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 3 Jun 2010 19:56:17 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C0808DF.5000203@dougbarton.us> Date: Thu, 03 Jun 2010 12:56:15 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Nicholas Weaver CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] latency References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> In-Reply-To: <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 06/03/10 07:39, Nicholas Weaver wrote: > > In order to do THAT, you end up exporting www2350.yahoo.com into the > browser's bar, bookmarks, etc, which is COMPLETELY unacceptable to > most site designers! I agree that what's in the browser bar needs to stay consistent, but as someone else (you maybe? I'm losing track) already pointed out the vast majority of the actual things fetched have no relationship to the URL in the browser bar, and therefore can easily be optimized using any number of client-side tricks (and in fact some of the things below already are). For example, here is the list of elements fetched for my yahoo home page. The URL in the browser bar is simply http://my.yahoo.com/, which shows up twice out of 41 elements in the page. I have repeatedly asserted that to the extent what you're trying to solve is a browser problem it needs to be solved in the browser. I'm not sure if you (and the others who are pursuing similar lines of argument) continue throwing up red herrings because you don't understand how modern web service works, or with some other motivation; but either way it gets tiresome to keep going in circles. Doug http://ads.yimg.com/a/a/ne/df/nflx_20033v3.gif http://d.yimg.com/a/p/ap/20100603/capt.8616e94329234ee5892461be43db30df-8616e94329234ee5892461be43db30df-0.jpg?x=130&y=98&q=85&sig=tLQBbq7x.K9qNIcWVHyCXA-- http://d.yimg.com/a/p/ap/20100603/capt.8616e94329234ee5892461be43db30df-8616e94329234ee5892461be43db30df-0.jpg?x=130&y=98&q=85&sig=tLQBbq7x.K9qNIcWVHyCXA-- http://l.yimg.com/a/combo?my/css/components/search_assist_0.1.20.css&my/css/components/dragdrop_0.1.13.css http://l.yimg.com/a/combo?my/css/core_0.1.299.css&my/css/components/modoptions_0.0.12.css&my/css/modules/type_pa_0.1.35.css&my/css/modules/type_weather_0.1.36.css&my/css/modules/type_placeholder_0.1.19.css&my/css/modules/type_simple_0.1.54.css&my/css/controls/tabset_0.1.15.css&my/css/controls/location_panel_0.1.11.css&my/css/modules/type_local_0.1.14.css&my/css/components/showcase_0.1.24.css http://l.yimg.com/a/combo?my/js/components/search_assist_0.1.31.js&my/js/yui_dragdrop_0.0.1.js&my/js/components/dragdrop_0.1.33.js&my/js/components/vsearch_0.1.58.js http://l.yimg.com/a/combo?my/js/core_0.1.335.js&my/js/components/modoptions_0.0.30.js&yui/2.5.1/build/selector/selector-beta-min.js&my/js/components/colresize_0.1.8.js&my/js/modules/type_pa_0.1.47.js&my/js/modules/type_weather_0.1.43.js&darla/fc_0.2.9.js&darla/util_0.2.6.js&darla/renderers/complex_renderer_0.3.0.js&my/js/controls/media_0.1.12.js&my/js/modules/type_simple_0.1.66.js&yui/2.5.1/build/container/container_core-min.js&my/js/controls/tabset_0.1.25.js&my/js/controls/location_panel_0.1.15.js&my/js/modules/type_local_0.1.17.js&my/js/components/showcase_0.1.50.js&my/js/components/pageoptions_0.1.16.js http://l.yimg.com/a/i/brand/purplelogo/my/sm/us.png http://l.yimg.com/a/i/us/my/gr/bwall6.gif http://l.yimg.com/a/i/us/my/mw/favicon.ico http://l.yimg.com/a/i/us/my/mw/gsprite_080509.gif http://l.yimg.com/a/i/us/my/mw/modules/type_weather/34ds.png http://l.yimg.com/a/i/us/my/mw/modules/type_weather/sprite_weather_sm.png http://l.yimg.com/a/i/us/my/mw/modules/type_weather/weather_day_bd_bg.png http://l.yimg.com/a/i/us/my/mw/modules/type_weather/weather_day_left_bg.png http://l.yimg.com/a/i/us/my/mw/modules/type_weather/weather_day_right_bg.png http://l.yimg.com/a/i/us/my/mw/sprite_ltdrk_20090915.gif http://l.yimg.com/a/i/us/my/mw/sprite_pa_033109.gif http://l.yimg.com/a/i/us/my/mw/sprite_pg_20090922.gif http://l.yimg.com/a/i/us/my/mw/sprite_pg_20091007.gif http://l.yimg.com/a/i/us/my/mw/srch/lip_closed_093008.gif http://l.yimg.com/a/i/us/my/mw/srch/lip_open_093008.gif http://l.yimg.com/a/i/us/my/mw/th/sprite_zorro_081208.gif http://l.yimg.com/a/i/us/my/mw/th/white/gsprite_pg_wht_052308.gif http://l.yimg.com/a/i/us/my/mw/tooltip_ptr_sprite.gif http://l.yimg.com/a/i/us/my/mw/trans.gif http://l.yimg.com/a/i/us/nws/weather/gr/34d.png http://l.yimg.com/a/lib/my/css/modules/type_insidemycms_0.1.6.css http://l.yimg.com/a/lib/my/css/modules/type_ymail_0.1.30.css http://l.yimg.com/a/lib/my/js/core_seed_0.0.5.js http://l.yimg.com/a/lib/my/js/modules/type_insidemycms_0.1.8.js http://l.yimg.com/a/lib/my/js/modules/type_ymail_0.1.48.js http://l.yimg.com/d/lib/bc/bc_2.0.4.js http://media.nbcsandiego.com/images/120*90/lotto1.jpg http://my.yahoo.com/e/df http://my.yahoo.com/e/js http://myyahooeditorial.files.wordpress.com/2010/05/sudoku.jpg?w=120&h=90 http://s.bit.ly/preview.s3.v2.css?v=4.2 http://us.bc.yahoo.com/b?P=8h4eNtj8evWzKWJjS1DOQRD5TFhc6UwH_4oAB__g&T=18nu9h14h%2fX%3d1275592586%2fE%3d150002246%2fR%3dmy%2fK%3d5%2fV%3d1.1%2fW%3dJ%2fY%3dYAHOO%2fF%3d1299137281%2fH%3dY29udGVudD0ibm9fZXhwYW5kYWJsZSIgc2VydmVJZD0iOGg0ZU50ajhldld6S1dKalMxRE9RUkQ1VEZoYzZVd0hfNG9BQl9fZyIgc2l0ZUlkPSIyNzk4NTUxIiB0U3RtcD0iMTI3NTU5MjU4NjY0MTQ4NyIg%2fS%3d1%2fJ%3dDFCFB444&U=12djmep2c%2fN%3dWkOESNGDJHY-%2fC%3d-1%2fD%3dFSRVY%2fB%3d-1%2fV%3d0&U=13f6gouvu%2fN%3daEOESNGDJHY-%2fC%3d767715.14167687.14076082.13146704%2fD%3dRQ1%2fB%3d6081461%2fV%3d1&Q=0&O=0.7635737163717967 http://us.i1.yimg.com/us.yimg.com/i/us/my/mw/sprite_trough_031008.gif -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Thu Jun 3 13:09:16 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8470A3A6A13; Thu, 3 Jun 2010 13:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.844 X-Spam-Level: ** X-Spam-Status: No, score=2.844 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZD+OfHf-Wsb; Thu, 3 Jun 2010 13:09:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A81723A6895; Thu, 3 Jun 2010 13:09:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKGf6-000M2h-1I for namedroppers-data0@psg.com; Thu, 03 Jun 2010 20:05:08 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKGf2-000M24-La for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 20:05:05 +0000 Received: (qmail 86084 invoked from network); 3 Jun 2010 20:24:59 -0000 Received: from softbank219001188004.bbtec.net (HELO ?192.168.1.27?) (219.1.188.4) by necom830.hpcl.titech.ac.jp with SMTP; 3 Jun 2010 20:24:59 -0000 Message-ID: <4C080AAF.4090405@necom830.hpcl.titech.ac.jp> Date: Fri, 04 Jun 2010 05:03:59 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Sean Leach CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] latency References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <78457.1275577401@nsa.vix.com> <1B778CCC-80FA-4BC7-A3F7-C84E595C4848@wiggum.com> <82867.1275581086@nsa.vix.com> <5860F8E7-4230-4F77-99B5-78F67D7F4232@wiggum.com> In-Reply-To: <5860F8E7-4230-4F77-99B5-78F67D7F4232@wiggum.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Sean Leach wrote: >>> not web specific - i may use this to direct you to the closest SMTP >>> server, SIP proxy etc. >> >> nobody in the smtp or sip communities is arguing that their industry >> cannot continue to thrive without explicit latency management. if they >> do i'll be surprised, since the MX RR and the NAPTR/SRV RRs work well. > on the contrary - I had several of the external anti-spam providers > want this very functionality (and a few VoIP providers). To your surprise, SMTP servers should be located near receivers, not senders. So should VoIP servers. > i don't claim to speak for them, just what they asked me for > while i was at ultradns/neustar HTTP people are not the only people not to know what they want. Masataka Ohta From owner-namedroppers@ops.ietf.org Thu Jun 3 13:20:02 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7943A6A20; Thu, 3 Jun 2010 13:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.839 X-Spam-Level: ** X-Spam-Status: No, score=2.839 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP+QBOS-kZIA; Thu, 3 Jun 2010 13:19:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ADED93A69FA; Thu, 3 Jun 2010 13:19:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKGpn-000NhI-HJ for namedroppers-data0@psg.com; Thu, 03 Jun 2010 20:16:11 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKGph-000NgT-E9 for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 20:16:05 +0000 Received: (qmail 86556 invoked from network); 3 Jun 2010 20:36:16 -0000 Received: from softbank219001188004.bbtec.net (HELO ?192.168.1.27?) (219.1.188.4) by necom830.hpcl.titech.ac.jp with SMTP; 3 Jun 2010 20:36:16 -0000 Message-ID: <4C080D52.7020601@necom830.hpcl.titech.ac.jp> Date: Fri, 04 Jun 2010 05:15:14 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Nicholas Weaver CC: Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Subject: Re: [dnsext] latency References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> In-Reply-To: <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Nicholas Weaver wrote: >> I thought queries to www.yahoo.com should be redirected to >> www50.yahoo.com, HTML files from which "statically" include >> l50.yimg.com, not l.yimg.com, which does not need any >> new specification. > > In order to do THAT, you end up exporting www2350.yahoo.com into > the browser's bar, bookmarks, etc, which is COMPLETELY > unacceptable to most site designers! You don't see the reality of HTTP. As I use my.yahoo.co.jp and click "Inbox" (or, "Jushinbako" in Japanese), I am directed to: http://jp.f24.mail.yahoo.co.jp/ym/ShowFolder?rb=Inbox&login=1 As I type http://www.google.com I am redirected to: http://www.google.co.jp/ig?hl=ja >> But, feel free to develop dynamic generation or whatever, as >> long as it does not purposelessly complicate DNS. > > What complication? No complication, as I wrote "does not purposelessly complicate". > Because "authority choses a subset based on the resolver querying" > has become established practice, and at this point has been > established practice for well over a decade. It does not complicate DNS. But, you had better see above to learn the established practice of HTTP and never say "COMPLETELY unacceptable". Masataka Ohta From owner-namedroppers@ops.ietf.org Thu Jun 3 14:35:45 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5B73A6860; Thu, 3 Jun 2010 14:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.128 X-Spam-Level: X-Spam-Status: No, score=-3.128 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEA57AguvyVL; Thu, 3 Jun 2010 14:35:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F2B673A681E; Thu, 3 Jun 2010 14:35:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKI0Q-00085U-LY for namedroppers-data0@psg.com; Thu, 03 Jun 2010 21:31:14 +0000 Received: from [192.150.186.11] (helo=fruitcake.ICSI.Berkeley.EDU) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKI0J-00084F-6F for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 21:31:07 +0000 Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o53L0gdu006411; Thu, 3 Jun 2010 14:00:42 -0700 (PDT) References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> <4C080D52.7020601@necom830.hpcl.titech.ac.jp> In-Reply-To: <4C080D52.7020601@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: [dnsext] latency Date: Thu, 3 Jun 2010 14:00:42 -0700 To: Masataka Ohta X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 3, 2010, at 1:15 PM, Masataka Ohta wrote: > Nicholas Weaver wrote: >=20 >>> I thought queries to www.yahoo.com should be redirected to >>> www50.yahoo.com, HTML files from which "statically" include >>> l50.yimg.com, not l.yimg.com, which does not need any >>> new specification. >>=20 >> In order to do THAT, you end up exporting www2350.yahoo.com into >> the browser's bar, bookmarks, etc, which is COMPLETELY >> unacceptable to most site designers! >=20 > You don't see the reality of HTTP. >=20 > As I use >=20 > my.yahoo.co.jp >=20 > and click "Inbox" (or, "Jushinbako" in Japanese), I am directed to: >=20 > http://jp.f24.mail.yahoo.co.jp/ym/ShowFolder?rb=3DInbox&login=3D1 This is somewhat sloppy design on yahoo's part: google does it far = cleaner... Also, please note that, as ugly as that hostname is, ITS consistent. = Just f24 is some silly little internal code on the part of Yahoo.jp. = The only other one which is valid in that rage is f25. The rest are = invalid, so if you bookmark f24, there is no problem if your computer = moves. > As I type >=20 > http://www.google.com >=20 > I am redirected to: >=20 > http://www.google.co.jp/ig?hl=3Dja Uh, thats hardly a "crufy" URL: its "www.google.co.jp, with the iGoogle = homepage, in japanese" Change the ja to en you get it in english. Drop = the ig and you get the classic google homepage in japanese. =20 I suspect your Google account settings says "use iGoogle", so thats why = you see it in the redirected URL: you have already told Google you want = the iGoogle homepage. The HTTP redirect itself was based entirely on the geoIP of your client = (http://www.google.com/ncr eliminates country-based redirection, BTW). And you notice they are VERY careful to not have it be = a2345.www.google.co.jp, OR to dynamically rewrite all the = subcomponents/subreferences to things like skins.gmodules.com, which is = what would be necessary if, as some suggest, latency-sensitive = redirection should be done using existing HTTP redirect messages or = mechanisms. Instead it relies COMPLETELY on DNS to ensure that I'm going to an = instance of www.google.co.jp which is just 5ms away, and that you are = going to servers (probably) 5ms away. Its a great proof that the DNS = games work, and solve the problem for most of the users today: since if = we were both going to the same instance, one or the other of us MUST see = 100ms latency. From owner-namedroppers@ops.ietf.org Thu Jun 3 14:53:19 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6BA628C123; Thu, 3 Jun 2010 14:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.918 X-Spam-Level: * X-Spam-Status: No, score=1.918 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+bZC8TbepP8; Thu, 3 Jun 2010 14:53:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AFDC128C12C; Thu, 3 Jun 2010 14:53:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKIIJ-000AV1-Vl for namedroppers-data0@psg.com; Thu, 03 Jun 2010 21:49:43 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKIID-000ASD-Ed for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 21:49:37 +0000 Received: (qmail 22454 invoked by uid 399); 3 Jun 2010 21:49:36 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 3 Jun 2010 21:49:36 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C08236E.20707@dougbarton.us> Date: Thu, 03 Jun 2010 14:49:34 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Nicholas Weaver CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] latency References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> <4C080D52.7020601@necom830.hpcl.titech.ac.jp> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 06/03/10 14:00, Nicholas Weaver wrote: > > On Jun 3, 2010, at 1:15 PM, Masataka Ohta wrote: > >> Nicholas Weaver wrote: > >> and click "Inbox" (or, "Jushinbako" in Japanese), I am directed >> to: >> >> http://jp.f24.mail.yahoo.co.jp/ym/ShowFolder?rb=Inbox&login=1 > > > This is somewhat sloppy design on yahoo's part: google does it far > cleaner... > > Also, please note that, as ugly as that hostname is, ITS consistent. > Just f24 is some silly little internal code on the part of Yahoo.jp. > The only other one which is valid in that rage is f25. The rest are > invalid, so if you bookmark f24, there is no problem if your computer > moves. That's basically correct, although I'm not sure I agree with "sloppy." I don't think I'm giving out any trade secrets by saying that each Yahoo! mail user's account is located on a given "farm," and when you visit http://mail.yahoo.com/ it is smart enough to redirect you to the farm your account is on. Providing the URL to your specific farm for bookmarking is arguably a feature since you can get there that much faster next time; and aren't you arguing here that sub-second latency issues are important to the eyeball sites? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Thu Jun 3 15:00:36 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27ECB3A6878; Thu, 3 Jun 2010 15:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.742 X-Spam-Level: ** X-Spam-Status: No, score=2.742 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjK-b8LWs5nu; Thu, 3 Jun 2010 15:00:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C14B3A685E; Thu, 3 Jun 2010 15:00:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKIPK-000BZL-Ih for namedroppers-data0@psg.com; Thu, 03 Jun 2010 21:56:58 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKIPI-000BYn-0Q for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 21:56:56 +0000 Received: (qmail 90860 invoked from network); 3 Jun 2010 22:17:08 -0000 Received: from softbank219001188004.bbtec.net (HELO ?192.168.1.27?) (219.1.188.4) by necom830.hpcl.titech.ac.jp with SMTP; 3 Jun 2010 22:17:08 -0000 Message-ID: <4C0824EC.2010403@necom830.hpcl.titech.ac.jp> Date: Fri, 04 Jun 2010 06:55:56 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Nicholas Weaver CC: Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Subject: Re: [dnsext] latency References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> <4C080D52.7020601@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Nicholas Weaver wrote: >>>> I thought queries to www.yahoo.com should be redirected to >>>> www50.yahoo.com, HTML files from which "statically" include >>>> l50.yimg.com, not l.yimg.com, which does not need any >>>> new specification. >>> >>> In order to do THAT, you end up exporting www2350.yahoo.com into >>> the browser's bar, bookmarks, etc, which is COMPLETELY >>> unacceptable to most site designers! >> >> You don't see the reality of HTTP. > This is somewhat sloppy design on yahoo's part: google does it > far cleaner... According to your theory, both yahoo and google are doing thing you said "COMPLETELY unacceptable". > so if you bookmark f24, there is no problem if your computer moves. If you bookmark URL after redirection to reduce delay, there is no problem if your computer moves, because you will be redirected again. > Uh, thats hardly a "crufy" URL "ig?hl=ja" is crufy enough, which is acceptable to google. Note that, because of language tag in HTTP header, "www.google.com" can continue to serve my request without redirection. > I suspect your Google account settings says I'm helping you learn the reality of web, not vice versa. Masataka Ohta From owner-namedroppers@ops.ietf.org Thu Jun 3 16:36:54 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF3D728C121; Thu, 3 Jun 2010 16:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.332 X-Spam-Level: ** X-Spam-Status: No, score=2.332 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmWn7eNV7z8u; Thu, 3 Jun 2010 16:36:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B46E928C102; Thu, 3 Jun 2010 16:36:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKJsV-000Lfo-Ac for namedroppers-data0@psg.com; Thu, 03 Jun 2010 23:31:11 +0000 Received: from [173.203.119.164] (helo=zularific.zerlargal.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKJsS-000LfX-IL for namedroppers@ops.ietf.org; Thu, 03 Jun 2010 23:31:08 +0000 Received: from [127.0.0.1] (helo=mailrelay) by zularific.zerlargal.org with smtp (Exim 4.71) (envelope-from ) id 1OKJsR-00050h-6D; Thu, 03 Jun 2010 23:31:07 +0000 Received: from mailrelay by localhost; Thu, 3 Jun 2010 23:31:07 +0000 Received: from MUA by mailrelay; Thu, 3 Jun 2010 23:30:14 +0000 Date: Thu, 3 Jun 2010 16:30:10 -0700 From: Bruce Campbell To: Carlo Contavalli cc: namedroppers@ops.ietf.org Subject: Re: [dnsext] latency In-Reply-To: Message-ID: References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, 3 Jun 2010, Carlo Contavalli wrote: > Ups, I also honestly misread Bruce's email. He was explicitly talking > about a network where hosts have non-RFC1918 addresses, but are still > going through a NAT box to get more privacy. Apologies. > > On Thu, Jun 3, 2010 at 11:18 AM, Carlo Contavalli > wrote: >> On Wed, Jun 2, 2010 at 9:46 PM, Bruce Campbell >> wrote: >>> >>> The general gist of this comment is that in order to assure that the IP >>> address/subnet of the original stub resolver remains private and not seen by >>> any but the first upstream resolver, end-users and administrators must make >>> changes to their infrastructure in order to opt-out of the >>> edns-client-subnet option. >> >> No. They just won't enable edns-client-ip to begin with? eg, your >> resolver within your private network will not add an edns-client-ip >> option. > > This is still true: eg, each resolver for each department will have > edns-client-ip disabled, unless you explicitly enable it, so > authoritative servers (or other intermediate servers) will only see > the IP of you recursive resolver (which, by being NATted, will > probably be the address of the NAT box), exactly like today. > > Eg, you opt-in by enabling the option on your recursive resolver, > which should be disabled by default. Urm... that is one method of opting in, yes. The other method is performed by the upstream resolver in adding in client-specific information before the query is sent onwards, and the original client doesn't know whether or not their query was opted-in to the behaviour specified in the draft. To opt-out of the possibility of this behaviour by the upstream resolver, my outbound queries need to have edns-client-subnet set to 0/0, ie, I need to make a behavioural change within my infrastructure. I'm not sure that you've addressed the problem that in order to maintain the current level of privacy with regards to client IP information not being transmitted via intermediate nameservers to the authoritative servers, administrators will need to make changes to their infrastructure. > Yes, the NAT / security box will need to support the option if you > want it to be able to filter out edns-client-subnet, or mangle the > option at will, but this is true even if the protocol was architected > to have clients use some other, more end-to-end, opt-in mechanism. > And it's basically true for any protocol modification.. and I bet that > most of the modifications those boxes do to traffic are in violation > of RFCs. I also bet that many NAT/security boxes by default remove > things they don't know about, which ... make the world a sensibly > worse place in terms of supporting protocol changes, but should > generally work. So what's to stop my upstream resolver doing the same thing to my queries as the above RFC-violating NAT box, and overriding any edns-client-subnet option with my egress IP ? > I'd personally be open to changing the requirements in section 4.1, to > say that an Intermediate Server with edns-client-subnet support MAY > reduce the number of bits in SOURCE NETMASK, if people think that > would be a good idea. I do think that that specific change would make this draft somewhat easier to swallow. You probably also want to specify that the client will accept the edns-client-subnet option being returned to it with a smaller number of bits in the netmask. -- Bruce. From owner-namedroppers@ops.ietf.org Thu Jun 3 17:56:32 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70463A6862; Thu, 3 Jun 2010 17:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.273 X-Spam-Level: X-Spam-Status: No, score=-97.273 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuVloJ9NeKiX; Thu, 3 Jun 2010 17:56:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8AF9E3A67F9; Thu, 3 Jun 2010 17:56:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKL6e-0003Vm-Pc for namedroppers-data0@psg.com; Fri, 04 Jun 2010 00:49:52 +0000 Received: from [74.125.121.35] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKL6b-0003VR-5y for namedroppers@ops.ietf.org; Fri, 04 Jun 2010 00:49:49 +0000 Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o540nkne010678 for ; Thu, 3 Jun 2010 17:49:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275612587; bh=+N0I601noPX2W4+eKTYCAh7AC44=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=x0JDiBK/HqeAzEk+4exue27yEAzhEk51RUGCGm9vKKeAllFwfQ5TwWVI0NM0nk590 FrlK24hIi2Bmjv8J7n0zw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=GxuwM1slfbSnaQdf+boVH5mx5OkDb6jCRL4De8hfgbdswlfX4nEXVybXHXakX8p0b 241vphSdGiZW89tzuj1Qg== Received: from vws17 (vws17.prod.google.com [10.241.21.145]) by hpaq7.eem.corp.google.com with ESMTP id o540nKPf020864 for ; Thu, 3 Jun 2010 17:49:45 -0700 Received: by vws17 with SMTP id 17so959526vws.23 for ; Thu, 03 Jun 2010 17:49:44 -0700 (PDT) Received: by 10.220.107.161 with SMTP id b33mr7352366vcp.253.1275612584331; Thu, 03 Jun 2010 17:49:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.128.139 with HTTP; Thu, 3 Jun 2010 17:49:24 -0700 (PDT) In-Reply-To: References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> From: Carlo Contavalli Date: Thu, 3 Jun 2010 17:49:24 -0700 Message-ID: Subject: Re: [dnsext] latency To: Bruce Campbell Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Jun 3, 2010 at 4:30 PM, Bruce Campbell > >> This is still true: eg, each resolver for each department will have >> edns-client-ip disabled, unless you explicitly enable it, so >> authoritative servers (or other intermediate servers) will only see >> the IP of you recursive resolver (which, by being NATted, will >> probably be the address of the NAT box), exactly like today. >> >> Eg, you opt-in by enabling the option on your recursive resolver, >> which should be disabled by default. > > Urm... that is one method of opting in, yes. > > The other method is performed by the upstream resolver in adding in > client-specific information before the query is sent onwards, and the > original client doesn't know whether or not their query was opted-in to t= he > behaviour specified in the draft. > sorry, what's preventing upstream resolvers now from using proprietary extensions or protocols to forward client-specific information to other servers? do you know if your upstream resolver is doing it now? All bets are off as soon as your queries leave your network. Having a standardized protocol does not make this any worse. If anything, it brings visibility into the issue, and provides mechanisms to opt-out and see what the server is doing (does it support edns-client-subnet? let's see what happens if I include an edns-client-subnet, and query a domain that uses it - it'd be pretty easy to have servers, like http header analyzers, that tell you if an edns-client-subnet was received, and what the content was). > I'm not sure that you've addressed the problem that in order to maintain = the > current level of privacy with regards to client IP information not being > transmitted via intermediate nameservers to the authoritative servers, > administrators will need to make changes to their infrastructure. you choose the recursive resolver you use, it's entirely up to this resolver to decide which information is forwarded, and how, and which intermediate servers are traversed (eg, other recursive resolvers, or straight to the servers that can provide the answers?), and again, this is true regardless of edns-client-subnet. I sincerely believe that your level of privacy will not change because of our draft. >> And it's basically true for any protocol modification.. and I bet that >> most of the modifications those boxes do to traffic are in violation >> of RFCs. I also bet that many NAT/security boxes by default remove >> things they don't know about, which ... make the world a sensibly >> worse place in terms of supporting protocol changes, but should >> generally work. > > So what's to stop my upstream resolver doing the same thing to my queries= as > the above RFC-violating NAT box, and overriding any edns-client-subnet > option with my egress IP ? ? not sure I understand your question. There's nothing stopping any middlebox from doing any change to any packet you send out on the internet... > I do think that that specific change would make this draft somewhat easie= r > to swallow. =A0You probably also want to specify that the client will acc= ept > the edns-client-subnet option being returned to it with a smaller number = of > bits in the netmask. sounds good, will keep this in mind for -02. If you have any other proposal on how we could improve the draft, that'd be great. Thanks, Carlo From owner-namedroppers@ops.ietf.org Thu Jun 3 18:50:38 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A846B3A68D7; Thu, 3 Jun 2010 18:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.542 X-Spam-Level: X-Spam-Status: No, score=-101.542 tagged_above=-999 required=5 tests=[AWL=1.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlebvwufjJZX; Thu, 3 Jun 2010 18:50:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE2B23A68BB; Thu, 3 Jun 2010 18:50:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKLzR-0008qp-Mp for namedroppers-data0@psg.com; Fri, 04 Jun 2010 01:46:29 +0000 Received: from [2001:478:6:0:230:48ff:fe11:220a] (helo=vacation.karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKLzK-0008il-Vg for namedroppers@ops.ietf.org; Fri, 04 Jun 2010 01:46:27 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o541QqPl002053; Fri, 4 Jun 2010 01:27:07 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o541OdWK002043; Fri, 4 Jun 2010 01:24:39 GMT Date: Fri, 4 Jun 2010 01:24:34 +0000 From: bmanning@vacation.karoshi.com To: Nicholas Weaver Cc: bmanning@vacation.karoshi.com, Masataka Ohta , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Subject: Re: [dnsext] latency Message-ID: <20100604012434.GA1902@vacation.karoshi.com.> References: <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> <20100603155233.GA17577@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Jun 03, 2010 at 09:01:14AM -0700, Nicholas Weaver wrote: > > On Jun 3, 2010, at 8:52 AM, bmanning@vacation.karoshi.com wrote: > > > On Thu, Jun 03, 2010 at 07:39:27AM -0700, Nicholas Weaver wrote: > >> > >> What complication? These tricks are not only well established, but at this point, should be considered part of DNS because they ARE part of DNS. > >> > >> Where does it state that an authority will return the COMPLETE RRSet associated with a name lookup, rather than a chosen subset? Or do you really want 50,000 answers for www.google.com? > >> > >> Because "authority choses a subset based on the resolver querying" has become established practice, and at this point has been established practice for well over a decade. > >> > > > > Hum... really? > > > > RFC 2181 - 5.1 states: > > > > 5.1. Sending RRs from an RRSet > > > > A query for a specific (or non-specific) label, class, and type, will > > always return all records in the associated RRSet - whether that be > > one or more RRs. The response must be marked as "truncated" if the > > entire RRSet will not fit in the response. > > I stand corrected. Except for one teeny-weeny little note: ITs now a decade+ of established practice for authorities to NOT return the full RRSet. Do you really want the full RRSet for www.l.google.com? > sigh... sure, bring it on. TCP use would shake out a whole raft of other problems. --bill From owner-namedroppers@ops.ietf.org Thu Jun 3 20:04:05 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180D43A67B1; Thu, 3 Jun 2010 20:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.425 X-Spam-Level: * X-Spam-Status: No, score=1.425 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRrYrqw-9XHc; Thu, 3 Jun 2010 20:04:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49AB03A6782; Thu, 3 Jun 2010 20:04:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKN7k-000Fnv-Ii for namedroppers-data0@psg.com; Fri, 04 Jun 2010 02:59:08 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKN7f-000FnJ-Nn for namedroppers@ops.ietf.org; Fri, 04 Jun 2010 02:59:04 +0000 Received: (qmail 4885 invoked from network); 4 Jun 2010 03:19:02 -0000 Received: from bmdi2173.bmobile.ne.jp (HELO ?202.221.174.173?) (202.221.174.173) by necom830.hpcl.titech.ac.jp with SMTP; 4 Jun 2010 03:19:02 -0000 Message-ID: <4C086BB8.7050306@necom830.hpcl.titech.ac.jp> Date: Fri, 04 Jun 2010 11:58:00 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org Subject: Re: [dnsext] latency References: <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C07AC8F.6000606@necom830.hpcl.titech.ac.jp> <1D07B2E9-CEAA-4E91-B627-5E46E7E27FA9@ICSI.Berkeley.EDU> <20100603155233.GA17577@vacation.karoshi.com.> <20100604012434.GA1902@vacation.karoshi.com.> In-Reply-To: <20100604012434.GA1902@vacation.karoshi.com.> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: bmanning@vacation.karoshi.com wrote: > sigh... sure, bring it on. TCP use would shake out a whole > raft of other problems. That's a good news, because DNSSEC is assured not to be deployable. Masataka Ohta From owner-namedroppers@ops.ietf.org Fri Jun 4 17:06:22 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3461928C0F2; Fri, 4 Jun 2010 17:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.147 X-Spam-Level: X-Spam-Status: No, score=0.147 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_50=0.001, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EmUuXOM6DxS; Fri, 4 Jun 2010 17:06:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A2CD3A682A; Fri, 4 Jun 2010 17:06:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKgmQ-000DAC-Nc for namedroppers-data0@psg.com; Fri, 04 Jun 2010 23:58:26 +0000 Received: from [74.125.82.52] (helo=mail-ww0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OKgmN-000D9w-QN for namedroppers@ops.ietf.org; Fri, 04 Jun 2010 23:58:24 +0000 Received: by wwb31 with SMTP id 31so1832687wwb.11 for ; Fri, 04 Jun 2010 16:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0ohCcgiF4pEb3QHO5oTOiaAUA89kEhhI8paNG2XqwEo=; b=n8ckgo4Riff2RXOO3c1wDgV4Ud1UyEMavIW8RlDn58Ij2k8JPuwuc3DziXWTfd0vIw UvCFymJrRhKV1E92wo6eGg24AabM/s9Z0C9Lv/u6AMuAL7AjjP4jBVDL1EuCArEAyujl u/BNNMHB58H2ht5v/w36E1FnuMPxQFu7vEt2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wS+JUohQm7MGmHo+6Ke8Wjpw18BUt1XL1M//2L7nLdIARenr9iskrDB6eQUL5wZvb2 SiHwY0Q2H6V567DtjFxJO4sM608/Er+k0JktmpvIA429SwAlaMGD7rx6kM1kc4M/orQ8 nVyB0cJ7KH6EiFchTCFG6cARPH0+y2Ek59yXg= MIME-Version: 1.0 Received: by 10.216.89.11 with SMTP id b11mr246901wef.32.1275695902450; Fri, 04 Jun 2010 16:58:22 -0700 (PDT) Received: by 10.216.229.210 with HTTP; Fri, 4 Jun 2010 16:58:22 -0700 (PDT) In-Reply-To: <201005191433.QAA13726@TR-Sys.de> References: <201005191433.QAA13726@TR-Sys.de> Date: Fri, 4 Jun 2010 19:58:22 -0400 Message-ID: Subject: Re: [dnsext] RE: On adoption of two drafts ... From: Donald Eastlake To: =?ISO-8859-1?Q?Alfred_H=CEnes?= Cc: segred@ics.forth.gr, namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=0016e6d643fa1b663404883d194d Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016e6d643fa1b663404883d194d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, On Wed, May 19, 2010 at 10:33 AM, Alfred H=CEnes wrote: > Vaggelis Segredakis wrote: > > > In the .gr ccTLD we have presented in 2005 the option of registering > > IDN domain names in Greek. The Greek language requires for all > > multi syllabus words to have an accent sign called "tonos" over > > one of the letters. [...] > > Unfortunately, hereby we apparently are back at one of the greatest > ratholes ever seen in DNS internationalization. > > Wasn't it one of the fundamental characteristics of the DNS that > DNS labels are _not_ "words" (in any language), but simply abstract > _identifiers_ in a more user friendly alphabet than IP addresses? > While the problem might appear to be "words", I would argue that it is subtlety different from that. The problem might appear to be words, but it is primarily script systems. Users of a particular script system have expectations built up over a lifetime of use. Users of the Roman script system expect that, much of the time, there is little if any difference between upper and lower case. DNS could have been designed to ignore the expectations of users of the Roman script system and been case sensitive. If so, there would be much les= s pressure to provide accommodations for other script systems (Greek, Arabic, Han, etc.) similar to its Roman case insensitivity. But, because DNS accommodates the expectations of Roman script system users, users of other script systems legitimately expect that they will also be accommodated. Thanks, Donald > > ... > > > Kind regards, > Alfred. > > -- > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | > +------------------------+--------------------------------------------+ > --0016e6d643fa1b663404883d194d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On Wed, May 19, 2010 at 10:33 AM, Al= fred H=CEnes <ah@tr-sy= s.de> wrote:
Vaggelis Segredakis wrote:

> In the .gr ccTLD we have presented in 2005 the option of registering > IDN domain names in Greek. =A0The Greek language requires for all
> multi syllabus words to have an accent sign called "tonos" o= ver
> one of the letters. =A0[...]

Unfortunately, hereby we apparently are back at one of the greatest
ratholes ever seen in DNS internationalization.

Wasn't it one of the fundamental characteristics of the DNS that
DNS labels are _not_ "words" (in any language), but simply abstra= ct
_identifiers_ in a more user friendly alphabet than IP addresses?

While the problem might appear to be "words= ", I would argue that it is subtlety different from that. The problem = might appear to be words, but it is primarily script systems.

Users of a particular script system have expectations b= uilt up over a lifetime of use. Users of the Roman script system expect tha= t, much of the time, there is little if any difference between upper and lo= wer case.

DNS could have been designed to ignore the expectations= of users of the Roman script system and been case sensitive. If so, there = would be much less pressure to provide accommodations for other script syst= ems (Greek, Arabic, Han, etc.) similar to its Roman case insensitivity. But= , because DNS accommodates the expectations of Roman script system users, u= sers of other script systems legitimately expect that they will also be acc= ommodated.

Thanks,
Donald
=A0

...


Kind regards,
=A0Alfred.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes =A0 | =A0Alfred Hoenes =A0 Dipl.-Math., Dipl.-Phys. = =A0|
| Gerlinger Strasse 12 =A0 | =A0Phone: (+49)7156/9635-0, Fax: -18 =A0 =A0 = =A0 =A0 |
| D-71254 =A0Ditzingen =A0 =A0 | =A0E-Mail: =A0ah@TR-Sys.de =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 |
+------------------------+--------------------------------------------+

--0016e6d643fa1b663404883d194d-- From owner-namedroppers@ops.ietf.org Mon Jun 7 08:02:04 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B138C3A67EC; Mon, 7 Jun 2010 08:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.523 X-Spam-Level: **** X-Spam-Status: No, score=4.523 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_55=0.6, MIME_QP_LONG_LINE=1.819, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1DiM8TGaiVm; Mon, 7 Jun 2010 08:02:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 994343A7B08; Mon, 7 Jun 2010 05:12:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLb4r-0001zt-Vd for namedroppers-data0@psg.com; Mon, 07 Jun 2010 12:05:13 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLb4k-0001se-4U for namedroppers@ops.ietf.org; Mon, 07 Jun 2010 12:05:06 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o57C4sN9049131; Mon, 7 Jun 2010 08:04:55 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Mon, 07 Jun 2010 08:05:01 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 07 Jun 2010 08:05:01 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4BFE30FC.3060308@nic.cz> References: <4BF69674.9070006@nlnetlabs.nl> <4BFE30FC.3060308@nic.cz> Date: Mon, 7 Jun 2010 08:02:02 -0400 To: From: Edward Lewis Subject: Re: [dnsext] Lookup ambiguity of CNAME and DNAME Cc: Edward Lewis Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 10:44 +0200 5/27/10, Ond=DEej Sur=98 wrote: >The reason why I am proposing CNAME+DNAME is that it seems to me that we >can get this functionality right now and cost would only be to upgrade >authoritative servers. (But several people has stated that it's not true >due different implementation details.) What is needed is for an examination of why CNAME=20 forbids other records and whether that=20 prohibition is inappropriate for DNAME records. CNAME's rules were written before DNAME. DNAME's=20 rules were poorly written. And lot's of code was=20 written and distributed based on this. (Too bad there was no adherence to the IETF=20 process rules of PS, DS, and FS for many years.) >Wildcards are non-issue. As Mark has already stated, all it takes is to >forbid DNAME at wildcard. You can't have it all :). When I hear "X is a non-issue" I get concerned.=20 This is what got us in to the trouble above. We now can have * CNAME - that didn't happen=20 until RFC 45xy or whatever it was. (An example=20 of incompleteness in STD13.) And I do think *=20 owning DNAME causes conflicts at the caches=20 anyway (w/o CNAME that is). -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Discussing IPv4 address policy is like deciding what to eat on the Titanic. From owner-namedroppers@ops.ietf.org Mon Jun 7 10:20:24 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ADAF3A6989; Mon, 7 Jun 2010 10:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.763 X-Spam-Level: ** X-Spam-Status: No, score=2.763 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_51=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwNm0n-empQy; Mon, 7 Jun 2010 10:20:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 67B9028C4BB; Mon, 7 Jun 2010 08:45:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLdPS-0001ia-3J for namedroppers-data0@psg.com; Mon, 07 Jun 2010 14:34:38 +0000 Received: from [65.99.1.130] (helo=abenaki.wabanaki.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLdPO-0001hx-TZ for namedroppers@ops.ietf.org; Mon, 07 Jun 2010 14:34:35 +0000 Received: from limpet.local (cpe-67-244-32-202.twcny.res.rr.com [67.244.32.202]) by abenaki.wabanaki.net (8.14.4/8.14.3) with ESMTP id o57EE5wp080174; Mon, 7 Jun 2010 10:14:05 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4C0D0342.80106@abenaki.wabanaki.net> Date: Mon, 07 Jun 2010 10:33:38 -0400 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Stephane Bortzmeyer CC: =?ISO-8859-1?Q?Alfred_H=F6nes?= , segred@ics.forth.gr, namedroppers@ops.ietf.org Subject: Re: [dnsext] Re: On adoption of two drafts ... References: <201005191433.QAA13726@TR-Sys.de> <20100528075438.GA17390@nic.fr> In-Reply-To: <20100528075438.GA17390@nic.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Stephane, =46rom my perspective, the Arab Working Group on Domain Names erred in adopting a labels are words framework. This required them to take a position on strings containing digits, and as a collateral, on strings containing Latin Script digits, or "Arabic-Indic digits" (U+0660 - U+0669), or "Eastern Arabic-Indic digits" (U+06F0 - U+06F9). Note that the character for the digit written in Latin Script as "5" looks sufficiently like a glyph representing a human heart that the use of this character in strings of the form "I-heart-New-York" is common in signage and informal text. There are important issues relating to the choice of script a digit is represented as, having to do with the Unicode BiDi algorithm's treatment of the "." character as directionality transmitting punctuation, and to the visual similarity of most of the digits in the two (U+0660 - U+0669), (U+06F0 - U+06F9) ranges. I don't suppose the issue will ever be resolved, but it could help to state it technically. I encourage anyone interested in Arabic Script also look at the use of Arabic Chat [1], with digits, as a very common means of writing Arabic on script limited user interfaces. An example is "hazihi wikibedia al mawsu3a al 7ora", trans: This is Wikipedia, the free encyclopedia. Eric [1] http://en.wikipedia.org/wiki/Arabic_chat_alphabet On 5/28/10 3:54 AM, Stephane Bortzmeyer wrote: > On Wed, May 19, 2010 at 04:33:26PM +0200, > Alfred H=F6nes wrote=20 > a message of 92 lines which said: >=20 >> Wasn't it one of the fundamental characteristics of the DNS that DNS >> labels are _not_ "words" (in any language), but simply abstract >> _identifiers_ >=20 > That's what people like John Klensin keep repeating but repetition > does not make it true. >=20 > Either DNS labels are semantic-free identifiers (like the phone > numbers), whose sole advantage (but it is a big one) over IP addresses > is the stability. That way, everyone would be equal, whether they > speak english or german or greek or arabic. And everyone would be > unhappy. >=20 > Or DNS labels are mnemonics and it is more convenient but it has bad > consequences (TLD registration rules, UDRP, etc) and it means we have > a responsability to be sure that these mnemonics can be written in any > script (hence IDNA). >=20 > [I used "mnemonics" instead of "words" to emphasize that, even in > english, you cannot have every name for a DNS label, for instance > "O'Reilly" or "Bang & Olufsen".] >=20 >> I vaguely recall from IDNA discussion on the use of IDNA with the >> Arabic languages (and scripts) that it had been reported to the IETF >> community that "The hardest part in this work was to escape from the >> (mis)concept of a couple of stakeholders that DNS labels were >> 'words' in one of the Arabic languages and therefore linguistic >> rules would have to be superimposed on DNS labels." >=20 > It is not a misconcept. >=20 >=20 >=20 From owner-namedroppers@ops.ietf.org Mon Jun 7 12:02:40 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE4AE3A683C; Mon, 7 Jun 2010 12:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02HhcAiyroj8; Mon, 7 Jun 2010 12:02:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CEC53A688C; Mon, 7 Jun 2010 12:02:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLhUk-000KzD-9Y for namedroppers-data0@psg.com; Mon, 07 Jun 2010 18:56:22 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLhUg-000Kyo-VJ for namedroppers@ops.ietf.org; Mon, 07 Jun 2010 18:56:19 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B0F041ECB408 for ; Mon, 7 Jun 2010 18:56:17 +0000 (UTC) Date: Mon, 7 Jun 2010 14:56:16 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-registry-fixes terms question Message-ID: <20100607185615.GP60255@shinkuro.com> References: <37183901-7770-4716-806D-93A0A8B296DE@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37183901-7770-4716-806D-93A0A8B296DE@nist.gov> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, On Tue, May 18, 2010 at 08:32:05AM -0400, Rose, Scott W. wrote: > So a question posed to the working group about the terms. Either: > > 1. Define the terms in draft-registry-fixes as they are used in the doc (basically, copy the text from draft-ogud-iana-protocol-maintenance-words and place them in a separate section in this draft. > > 2. Use "SHOULD+" instead of DISCRETIONARY (and define it), MUST instead of MANDATORY and MUST NOT for OBSOLETE. > > 3. do nothing (assume that draft-ogud-iana-protocol-maintenance-words will advance). This question hasn't garnered any responses. I think we need to resolve this before it is sent from the WG. If nobody objects by Friday, I will conclude that the answer is (1). My grounds for this is that those are the words that were in the text during WGLC, and my impression is that most of the complaints about those words had to do with their applicability outside this context, and not for their utility in this particular instance. If you disagree, now would be a good time to say so. A (speaking as document shepherd for this I-D). -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Jun 7 12:41:00 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B973A672E; Mon, 7 Jun 2010 12:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.329 X-Spam-Level: * X-Spam-Status: No, score=1.329 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq3ybHPx46Hd; Mon, 7 Jun 2010 12:40:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A5CE3A63CB; Mon, 7 Jun 2010 12:40:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLi7J-00018R-AL for namedroppers-data0@psg.com; Mon, 07 Jun 2010 19:36:13 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLi7G-000180-1Q for namedroppers@ops.ietf.org; Mon, 07 Jun 2010 19:36:10 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o57Ja73k020055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2010 12:36:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100607185615.GP60255@shinkuro.com> References: <37183901-7770-4716-806D-93A0A8B296DE@nist.gov> <20100607185615.GP60255@shinkuro.com> Date: Mon, 7 Jun 2010 12:35:40 -0700 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] draft-registry-fixes terms question Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 2:56 PM -0400 6/7/10, Andrew Sullivan wrote: >Dear colleagues, > >On Tue, May 18, 2010 at 08:32:05AM -0400, Rose, Scott W. wrote: > >> So a question posed to the working group about the terms. Either: >> >> 1. Define the terms in draft-registry-fixes as they are used in the doc (basically, copy the text from draft-ogud-iana-protocol-maintenance-words and place them in a separate section in this draft. >> >> 2. Use "SHOULD+" instead of DISCRETIONARY (and define it), MUST instead of MANDATORY and MUST NOT for OBSOLETE. >> >> 3. do nothing (assume that draft-ogud-iana-protocol-maintenance-words will advance). > >This question hasn't garnered any responses. In my case, it is because there was never a response to my earlier question on "what is this document talking about", so I can't say what kind of wording is needed. To recap: The document says that "implementors need to know which algorithms need to be implemented, which are optional, and which are obsolete" and "implementors must read through all the documents in order to discover which algorithms are mandatory to implement and which are optional or no longer used". Nowhere in the current document does it say what it means by "mandatory". In the IETF, a single RFC can make something mandatory for implementing the RFC. We have no concept of "mandatory for a protocol" or even "mandatory for a named group of documents" (the latter is accomplished only by making all the documents but one point to the other document for the mandatory parts). The strong hint in this document is that it is trying to define "mandatory for DNSSEC". If so, the document has no place in the IETF. The IETF has tried repeatedly and failed repeatedly to define such a structure. This document is doing an end-run on the IETF lack-of-process in this area. >I think we need to >resolve this before it is sent from the WG. Fully agree. >If nobody objects by >Friday, I will conclude that the answer is (1). I object. Without defining "mandatory to what", all wording in this document is open to obvious misinterpretation. >My grounds for this >is that those are the words that were in the text during WGLC, and my >impression is that most of the complaints about those words had to do >with their applicability outside this context, and not for their >utility in this particular instance. That's one interpretation; another is that the context is not part of the IETF and yet is undefined. >If you disagree, now would be a >good time to say so. See above. :-) --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Mon Jun 7 14:11:22 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAC3B3A686C; Mon, 7 Jun 2010 14:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVWZ97yXqpsM; Mon, 7 Jun 2010 14:11:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 173573A6834; Mon, 7 Jun 2010 14:11:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLjW5-000E5v-HM for namedroppers-data0@psg.com; Mon, 07 Jun 2010 21:05:53 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLjW2-000E5G-7f for namedroppers@ops.ietf.org; Mon, 07 Jun 2010 21:05:50 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 07B2C1ECB408 for ; Mon, 7 Jun 2010 21:05:46 +0000 (UTC) Date: Mon, 7 Jun 2010 17:05:45 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-registry-fixes terms question Message-ID: <20100607210544.GQ60255@shinkuro.com> References: <37183901-7770-4716-806D-93A0A8B296DE@nist.gov> <20100607185615.GP60255@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, Jun 07, 2010 at 12:35:40PM -0700, Paul Hoffman wrote: > > In the IETF, a single RFC can make something mandatory for > implementing the RFC. We have no concept of "mandatory for a > protocol" or even "mandatory for a named group of documents" (the > latter is accomplished only by making all the documents but one > point to the other document for the mandatory parts). So isn't this innovation just an extension of that? That is, instead of making those other documents point to one document that has the requirements levels in it, you point to one document that defines the registry in which the requirements are set? Why is that bad? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Jun 7 14:26:32 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AAAE3A6834; Mon, 7 Jun 2010 14:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xcl4KngN2q2Y; Mon, 7 Jun 2010 14:26:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4BDE43A6852; Mon, 7 Jun 2010 14:26:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLjm3-000G7h-90 for namedroppers-data0@psg.com; Mon, 07 Jun 2010 21:22:23 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLjlw-000G6y-9w for namedroppers@ops.ietf.org; Mon, 07 Jun 2010 21:22:16 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2136F1ECB408 for ; Mon, 7 Jun 2010 21:22:15 +0000 (UTC) Date: Mon, 7 Jun 2010 17:22:13 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data Message-ID: <20100607212213.GR60255@shinkuro.com> References: <4BAC7776.3090106@nlnetlabs.nl> <20100514135457.GA65855@shinkuro.com> <20100514195525.GL65855@shinkuro.com> <20100517143811.GA77756@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I've turned back to this today, in an effort to nail down what it is the draft is going to say. On Wed, May 19, 2010 at 11:39:33AM -0400, Michael StJohns wrote: > > "Security aware intermediate resolvers MUST set the CD bit on any > upstream query for which they have a covering trust anchor (TA) or > for which the downstream query has the CD bit set." The counter-arguments for this have been made, and amply in my opinion. The text already suggests that for most cases, it's better just to set it and move on: For efficiency, a validator may wish to set the CD bit on all upstream queries when it has a trust anchor at or above the QNAME (and thus can reasonably expect to be able to validate the response). If you want something stronger than that, then maybe another sentence can be added suggesting that not doing so could increase the chances of failure. But several people have argued that the MUST is too prescriptive, because they have a plan for how to use the protocol under circumstances where they want not to set CD as you seem to want them to. Even if you think it's a bad idea, it would appear we're not going to get consensus on anything as strong as MUST here. > Security aware intermediate resolvers SHOULD cache data returned > from an upstream (server side) query which had the CD bit set. If > the downstream (client side) query also has the CD bit set, the > resolver MAY defer validation of this data (assuming a covering TA) > until a later non-CD bit query for the same data, but MUST mark the > cached data as non-validated until local validation actually occurs. I'm not sure whether the first sentence is meant to imply that the intermediate resolver shouldn't cache CD=0 data, but I presume not. How about this: When caching, a security-aware intermediate resolver MAY return data without validating it only if the original query had the CD bit set. In that case, the intermediate resolver MAY defer validation of the data, but MUST mark the cached data as non-validated until local validation actually occurs. It MUST NOT return the cached, unvalidated data to a query with CD=0. ? > Security aware intermediate resolvers SHOULD cache SERVFAIL > responses returned from an upstream query. They MUST cache the state > of the CD bit in all upstream queries as well. If a security aware > intermediate resolver receives a CD bit set query for data which has > a SERVFAIL cached, the resolver MUST set the CD bit on the upstream > query and SHOULD cache BOTH the SERVFAIL and the data returned on > the CD bit set upstream query. As I read that paragraphm it says that the intermediate resolver gets a query with CD=1, for data for which it has SERVFAIL. The resolver side now queries again with CD=1, and gets that answer. Then it has two cache entries: one for QNAME, CD=0 (SERVFAIL) and one for QNAME, CD-1. Is that what you intend? Why can't it throw away its CD=1 result and just not cache that? > Data in cache with the CD bit set which has not been locally > validated MUST NOT be returned to a non-CD query. If the cached > data has the CD bit set it may be returned to a CD bit set query, if > a SERVFAIL is cached it may be returned to a non-CD query, and if > the cached data has the CD bit set, and there is a covering TA it > may be locally validated and returned. Otherwise this should be > treated as a cache miss and the query repeated upstream." As a bit of wordsmithing, may I suggest Data in cache with CD=1 but that has not been locally validated MUST NOT be returned to a query with CD=0. [Note: it says that above too, I think.] Cached data with CD=1 MAY be returned to a query with CD=1. Cached Server Failure errors MAY be returned to queries where CD=0; alternatively, if the data is locally validatable (using a local covering trust anchor), it may also be validated and returned. I found the text you proposed hard to understand, but I think I got its sense. Is that right? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Mon Jun 7 16:52:50 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4DB93A6855; Mon, 7 Jun 2010 16:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3vyUfWWJWyL; Mon, 7 Jun 2010 16:52:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E24AF3A67B2; Mon, 7 Jun 2010 16:52:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLm1A-0005Qj-8f for namedroppers-data0@psg.com; Mon, 07 Jun 2010 23:46:08 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLm17-0005QI-Ko for namedroppers@ops.ietf.org; Mon, 07 Jun 2010 23:46:05 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id E6482EE96B; Mon, 7 Jun 2010 23:46:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o57NjvaK020360; Tue, 8 Jun 2010 09:45:59 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201006072345.o57NjvaK020360@drugs.dv.isc.org> To: "George Barwood" Cc: namedroppers@ops.ietf.org, "Edward Lewis" From: Mark Andrews References: <4BF69674.9070006@nlnetlabs.nl> <4BFE30FC.3060308@nic.cz> <4CB1917A35FA4A118AFB4E042D59506D@local> Subject: Re: [dnsext] Lookup ambiguity of CNAME and DNAME In-reply-to: Your message of "Mon, 07 Jun 2010 15:41:22 +0100." <4CB1917A35FA4A118AFB4E042D59506D@local> Date: Tue, 08 Jun 2010 09:45:57 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <4CB1917A35FA4A118AFB4E042D59506D@local>, "George Barwood" writes: > Edward, > > Looking at > > http://tools.ietf.org/html/rfc4592#section-4.4 > > it seems to me that if you want wildcard DNAME, the solution would be for > servers not to perform the wildcard substitution on the DNAME record, > i.e. return the unmodified DNAME record to the client ( but generate an > unsigned CNAME with wildcard substitution performed there ). > > There may of course be some problems with this, it's just an idea. > > George Wildcard DNAME's cannot be made to work using the existing definition of a wildcard match. "*" matches multiple labels so the DNAME never gets applied unless a cache learns about it as the result of a DNAME/ANY query. What's the answer to a A query for a.b.foo when there is just the following record in the foo zone apart from the records at the apex? Hint it doesn't include a CNAME. *.*.foo CNAME bar Those that want wildcard DNAME to work also want the "*" to only match a single label. They want *.foo DNAME bar to produce c.foo DNAME bar a.b.c.foo CNAME a.b.bar for qname a.b.c.foo. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Jun 7 17:50:03 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCFB3A68C0; Mon, 7 Jun 2010 17:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.717 X-Spam-Level: * X-Spam-Status: No, score=1.717 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etqaGP+znxI0; Mon, 7 Jun 2010 17:50:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4F883A68A7; Mon, 7 Jun 2010 17:50:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLmx0-000B0O-6u for namedroppers-data0@psg.com; Tue, 08 Jun 2010 00:45:54 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLmwx-000B07-7r for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 00:45:51 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o580jmcX036233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2010 17:45:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100607210544.GQ60255@shinkuro.com> References: <37183901-7770-4716-806D-93A0A8B296DE@nist.gov> <20100607185615.GP60255@shinkuro.com> <20100607210544.GQ60255@shinkuro.com> Date: Mon, 7 Jun 2010 17:45:46 -0700 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] draft-registry-fixes terms question Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 5:05 PM -0400 6/7/10, Andrew Sullivan wrote: >On Mon, Jun 07, 2010 at 12:35:40PM -0700, Paul Hoffman wrote: >> >> In the IETF, a single RFC can make something mandatory for >> implementing the RFC. We have no concept of "mandatory for a >> protocol" or even "mandatory for a named group of documents" (the >> latter is accomplished only by making all the documents but one >> point to the other document for the mandatory parts). > >So isn't this innovation just an extension of that? It attempts to silently, yes. It never says that is what it is doing, so we have to guess. >That is, instead >of making those other documents point to one document that has the >requirements levels in it, you point to one document that defines the >registry in which the requirements are set? Why is that bad? Many of us think it would be good, but we lost that battle in the IETF long ago; see the "newtrk" effort for the gory details. Without the authors knowing it (except when I have brought it up), they have reopened the debate by saying, I think, "we should be able to call something DNSSEC and here is how the mandatory algorithms for that thing are defined". That is not acceptable in today's IETF, despite what many of us wanted. Of course, if you want to have the food fight during IETF Last Call, and especially during IESG review, go ahead, but it will be Ugly. And it should be: why should DNSSEC be able to do this when, for example, SIP has not? Until you answer this, the WG cannot decide which type of words should be used in the draft to bring to IETF Last Call. More significantly, we cannot help IANA to know what to do for the registry, given that they won't know which RFCs do and don't affect the registry because a new RFC should not inherently part of "DNSSEC" just because the RFC says so. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Tue Jun 8 02:13:29 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FABD28C130; Tue, 8 Jun 2010 02:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgjhVGUkHiyX; Tue, 8 Jun 2010 02:13:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B90128C12E; Tue, 8 Jun 2010 02:13:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLulf-000Brt-2k for namedroppers-data0@psg.com; Tue, 08 Jun 2010 09:06:43 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLulc-000BrV-N7 for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 09:06:40 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 7CF00EEA28; Tue, 8 Jun 2010 09:06:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o5896Yr5029084; Tue, 8 Jun 2010 19:06:35 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201006080906.o5896Yr5029084@drugs.dv.isc.org> To: "George Barwood" Cc: namedroppers@ops.ietf.org, "Edward Lewis" From: Mark Andrews References: <4BF69674.9070006@nlnetlabs.nl> <4BFE30FC.3060308@nic.cz> <4CB1917A35FA4A118AFB4E042D59506D@local> <201006072345.o57NjvaK020360@drugs.dv.isc.org> Subject: Re: [dnsext] Lookup ambiguity of CNAME and DNAME In-reply-to: Your message of "Tue, 08 Jun 2010 07:27:59 +0100." Date: Tue, 08 Jun 2010 19:06:34 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , "George Barwood" writes: > > ----- Original Message ----- > From: "Mark Andrews" > To: "George Barwood" > Cc: ; "Edward Lewis" > Sent: Tuesday, June 08, 2010 12:45 AM > Subject: Re: [dnsext] Lookup ambiguity of CNAME and DNAME > > > > > > In message <4CB1917A35FA4A118AFB4E042D59506D@local>, "George Barwood" writes: > >> Edward, > >> > >> Looking at > >> > >> http://tools.ietf.org/html/rfc4592#section-4.4 > >> > >> it seems to me that if you want wildcard DNAME, the solution would be for > >> servers not to perform the wildcard substitution on the DNAME record, > >> i.e. return the unmodified DNAME record to the client ( but generate an > >> unsigned CNAME with wildcard substitution performed there ). > >> > >> There may of course be some problems with this, it's just an idea. > >> > >> George > > > > Wildcard DNAME's cannot be made to work using the existing definition > > of a wildcard match. "*" matches multiple labels so the DNAME never > > gets applied unless a cache learns about it as the result of a > > DNAME/ANY query. > > Right, agreed. This seems a better explanation that the one given in the > RFC 4592 for why a wildcard DNAME is a non-starter. One follows from the other. Think about what happens once the cache learns about the DNAME. > I suppose non-wild matching can still happen,e.g. > > *.dname.example.com. DNAME foo.org. > > with the query > > a.*.dname.example.com. A > > is presumably a DNAME match, although best avoided considering the > likelihood of confusion. > > George -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From info@webmaster.com Tue Jun 8 03:55:51 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B043328C14B for ; Tue, 8 Jun 2010 03:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.801 X-Spam-Level: *** X-Spam-Status: No, score=3.801 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_99=3.5, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQmuU1PMTA+p for ; Tue, 8 Jun 2010 03:55:50 -0700 (PDT) Received: from mail.xmgd.com (mail.xmgd.com [211.156.95.230]) by core3.amsl.com (Postfix) with ESMTP id 7BD1328C10C for ; Tue, 8 Jun 2010 03:55:50 -0700 (PDT) Received: from xmgd.com (localhost [127.0.0.1]) by mail.xmgd.com (Postfix) with ESMTP id 5ACDF119DAA; Tue, 8 Jun 2010 18:53:03 +0800 (CST) From: "info" Reply-To: customercarewebdept210@hotmail.com Subject: Confirma Tu Cuenta=?UTF-8?Q?_Webmail=E2=80=8F?= Date: Tue, 8 Jun 2010 18:53:03 +0800 Message-Id: <20100608104909.M30030@webmaster.com> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 41.138.179.237 (yjy313@xmgd.com) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 To: undisclosed-recipients:; webmail Estimado / E-mail del usuario Notificación de correo web mantenimiento del usuario Dependencia, Estamos llevando a cabo una actualización en nuestro sitio ya que había llegado a nuestro conocimiento que algunos de nuestros suscriptores están introduciendo un virus en nuestro sitio y está afectando a nuestra red. Estamos tratando de averiguar el suscriptor específico. Por esta razón todos los abonados a proporcionar sus datos como Nombre, Apellido Nombre, Cuenta de usuario y ontraseña para que podamos verificar y hacer que se despejado contra este virus. Adviértase que la falta de respuesta a esto conducirá a suscriptores Cancelación de cuenta en las próximas 48 horas. Por lo tanto, como un usuario de nuestro sitio, es necesario que nos envíe su correo electrónico detalles de la cuenta para que podamos reconocer Actividad cuenta Por otra parte, se informó de que vamos a eliminar todas las cuentas de correo que no se activa para crear más espacio para los nuevos usuarios. Por lo tanto, son consejos que nos envíe los datos de su cuenta de correo Como se solicita a continuación: Información a enviar; Nombre: Apellido: Nombre de usuario: Contraseña: Todos los usuarios se aconsejan para completar la actualización. Un cordial saludo. 2010 Webmaster Departamento Admin. © Todos los derechos reservados From owner-namedroppers@ops.ietf.org Tue Jun 8 05:01:11 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B899F28C181; Tue, 8 Jun 2010 05:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.314 X-Spam-Level: *** X-Spam-Status: No, score=3.314 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FU3B-a5U4Row; Tue, 8 Jun 2010 05:01:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 913DD28C177; Tue, 8 Jun 2010 05:01:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLxMZ-00091F-Ns for namedroppers-data0@psg.com; Tue, 08 Jun 2010 11:52:59 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLxMW-0008zf-Fc for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 11:52:56 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o58Bqjmw058597; Tue, 8 Jun 2010 07:52:45 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Tue, 08 Jun 2010 07:52:52 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 08 Jun 2010 07:52:52 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 8 Jun 2010 07:48:57 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: [dnsext] Section 5.1 of draft-dnssec-bis Cc: ed.lewis@neustar.biz Content-Type: multipart/alternative; boundary="============_-936124530==_ma============" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --============_-936124530==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Why does section 5.1 exist? It's going to create problems once resolvers start validating responses. Section 5.1 says: 5. Interoperability Concerns 5.1. Errors in Canonical Form Type Code List When canonicalizing DNS names, DNS names in the RDATA section of NSEC and RRSIG resource records are not downcased. [RFC4034] Section 6.2 item 3 has a list of resource record types for which DNS names in the RDATA are downcased for purposes of DNSSEC canonical form (for both ordering and signing). That list erroneously contains NSEC and RRSIG. According to [RFC3755], DNS names in the RDATA of NSEC and RRSIG should not be downcased. The same section also erroneously lists HINFO, and twice at that. Since HINFO records contain no domain names, they are not subject to downcasing. The document-trouble here is that RFC 4034 (et.al.) obsoletes RFC 3755. This draft now says that the obsoleting document (4034) is to be updated by the obsoleted document (3755). The reality-problem here is that RFC 4034's section 6.2 makes sense. RFC 3755 did not on this matter. When it comes to the DNSSEC types, DNSSEC can make type-specific rules about the RDATA. The operations&tools-problem here is that there are tools being produced that automatically manage the NSEC (and NSEC3) chains. Some tools are exhibiting unexpected behavior in operations because they follow the un-vetted draft and not the existing proposed standard. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Discussing IPv4 address policy is like deciding what to eat on the Titanic. --============_-936124530==_ma============ Content-Type: text/html; charset="us-ascii" Section 5.1 of draft-dnssec-bis
Why does section 5.1 exist?  It's going to create problems once resolvers start validating responses.

Section 5.1 says:

5.  Interoperability Concerns

5.1.  Errors in Canonical Form Type Code List

   When canonicalizing DNS names, DNS names in the RDATA section of NSEC
   and RRSIG resource records are not downcased.

   [RFC4034] Section 6.2 item 3 has a list of resource record types for
   which DNS names in the RDATA are downcased for purposes of DNSSEC
   canonical form (for both ordering and signing).  That list
   erroneously contains NSEC and RRSIG.  According to [RFC3755], DNS
   names in the RDATA of NSEC and RRSIG should not be downcased.

   The same section also erroneously lists HINFO, and twice at that.
   Since HINFO records contain no domain names, they are not subject to
   downcasing.

The document-trouble here is that RFC 4034 (et.al.) obsoletes RFC 3755.  This draft now says that the obsoleting document (4034) is to be updated by the obsoleted document (3755).

The reality-problem here is that RFC 4034's section 6.2 makes sense.  RFC 3755 did not on this matter.  When it comes to the DNSSEC types, DNSSEC can make type-specific rules about the RDATA.

The operations&tools-problem here is that there are tools being produced that automatically manage the NSEC (and NSEC3) chains.  Some tools are exhibiting unexpected behavior in operations because they follow the un-vetted draft and not the existing proposed standard.

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

Discussing IPv4 address policy is like deciding what to eat on the Titanic.
--============_-936124530==_ma============-- From managinge1@redvo.com Tue Jun 8 05:06:35 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F6BF28C173; Tue, 8 Jun 2010 05:06:35 -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=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1E-Quv425RG; Tue, 8 Jun 2010 05:06:35 -0700 (PDT) Received: from LMontsouris-156-24-43-43.w217-128.abo.wanadoo.fr (LMontsouris-156-24-43-43.w217-128.abo.wanadoo.fr [217.128.228.43]) by core3.amsl.com (Postfix) with ESMTP id 5EAD428C18D; Tue, 8 Jun 2010 05:05:59 -0700 (PDT) Received: from 217.128.228.43 by spam3.ihostexchange.net; Tue, 8 Jun 2010 14:05:46 +0100 Date: Tue, 8 Jun 2010 14:05:46 +0100 From: "Ellen Haynes" X-Mailer: The Bat! (v2.00.5) Educational Reply-To: managinge1@redvo.com X-Priority: 3 (Normal) Message-ID: <739147534.92824969742108@redvo.com> To: disman@ietf.org Subject: Changelog 07.06.2010 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------9EF1FB1738280767" ------------9EF1FB1738280767 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Hello, as promised PDF file attached, Ellen ------------9EF1FB1738280767 Content-Type: application/pdf; name="Changelog.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Changelog.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nM1d23rcxpH+9pZPMbmb2RURoLtxyp2s+JSVnbXNzWZt54I6kbIokpFIycpr bL4873YD6Kpq9N/AiBYxsC9MY4BGVaPOp/77Js8Ktcndv/6Pp6+Pfv99vTl7e9Rd3nz/5fDHm7Oj vx81mXb/dBfk309fbz47sQ+2m6LM8lyZzcmLozxr2yZvmu6OYlPkZdaYTa1M1mxOXh/9tH20O64z VddNuz3f6SzXeb093R3b3xtT6u2l+7NttDbbM7763N6pVK31drMrsrIyqto+tn812qh6e8U32mcK lTVtU9s7/3bypw68OivLWoBXqGoATysL3qYuTGY68OxDJ78cfX5y9J3bgKxqC5PbezNdqNbi1O9L dHnfXbIP1LViMHLjd8kCVOcWxX6LftodK7sHVVtu/2OnMvsOtf3bcM20FsYO3Uqr7b/cHhS6sNcq C1Zr1Pah2982L8py+2xXFJmp2sb+dWw/dlG2ddHtZW1UUdNVu5/DbhHmRtcOszyrS91aXAfMx5c/ CeZ2OzMdo/47/jNA3iNK24B24ZFFsmpM4YiMUbd01mYWEIvvpbh85p9/vrOUrFXdJrfGI+65RP7/ p9mMus2M8ZvRZKUl5Xb7wpK1ySwR13fYiy92x5bPjGn19qVDKy/tR7S88itC22IsCeGjhUFRTCFY awtlgKOF3BJpZQlr2OfjqsmKqtUby8ibk2cDS9p76mpz8vjo5N9/2v6lkxG1KlsLev+dlEX9jcO4 zo3evhUfN0D5irfi0m2uyZtCglCIBzP5oPxB/v2EF1QByYhn/0VsGFxWYplcPFsE1/2jATS5uMWI R7PU+lW3Tp2rMZ8vJ+HK7ssbnbWTUs4u+tvoT09BoZusCoBwjGPKrDBm+y2JDJaQ7/treSWFbuH5 Rvk/cv/HV7TGP2gN8eS1v+8N437lr/3CZMgM+ZSWuQnpmBfyguHtrmgyVVaBgvgvQQQ9glb1uquO oXKGzrTF9msSN3+kO50UqfO8MVZ2stoYXv6Mxenz+Fex8s9bxvet49LKcq/j3doaB7qUCIunXtuV 6rKy6PK7L/3qt/4P/u1i2ECltz/v+IXZTpV25/KiNwdCAaWUXUYVljqsqGFppPShGUUrK1YOzSgC CMEofyQif8kkKyiaaeEpfdYbvvOv9DirqII5iUiKf/2RRHXwsZkdXrunGp1XjlT8Ky95qQexolQW DTKUHu+Us4WrMuAXQYqa12LeeMC/i1sf0u8nHdhKKcFZ4sbh/aqt7fv9neH7Pe9pvz3iGf71inmC oBykRVXada5nfhcwnQpLgJgcWAmO8pQxmd1xzzrTbJaVytTt+tjMffdqbza7X+uv5zmCKPRFPjF/ G+f3SOwl4QXaiUjmBRFxYFJdILUl2OxFoOp0pu33ozeE3swPAoZA3THbC9Ceoot8p3hvsJZ4H7Nl xKDu58+c1LCULyWa5JvTsYrvOQioSeKg6LdJrimMstshmEaw7EG5JreGRrMqriGIFuAagf03lm5M Y5SRjEKmydvOTylMVWDWYAq+BYZhZyjVRWECa8//KpYhYhLqmI3BawbsAvPUB2LLgLGF/jyjO5zk rpwnUQe6gu4MTMJIlwg+eQEs4Bg9d6eUCi8FD0SKqdoe8wJP/K8fhj+M/dUz+WhJr4sAo36Mlu2U orIs2xDPBvfa15SqVTM8n7v3aWZ6/9TBAjQdy5et/erTIZoleb7KFIN0/ywvsH9I1qtQfAHfPI+d FWZlwbbvYsMKenOWhqyToktLg3Idb9EmFDfQNafzviSQLo9ICwr/inl/kHFVroRnJ3jqKfLsYsdZ 2P05MSwzHy99jXzOae9TCg32KSd9cfBthMrGjqTVt0UzY+Hec/iwZ9XGZNMBRHexVeVIpNwL4zAs jzhoR9tMDHIDHUm2Fy8SFtwjYKKhRQMWA0SesCWZyD3fncf+qZG6TKjgXwl6SJ49aWvJKy+g/mPb VGJGFP0cgX4Za7IbSZGerxjv+JuANaJoVAeBwCBeJeDDTkPmdVYWxjMKc7a48zZahmXXu/iSZPAL aKCTNSBkGJsNmKPLKmuqWnI0NL8XYelaWZjXwtMCGA4FRRESd7GNkxEJTqNIoGS1kIQcnybpy/0I DObXHQ+avA1Mujgem7CMJZWL3UYakxWLpGjPZ0BCKD0tIaatxLLMWl2lafO4aEsnbV0WJQsSKWpl WRSXtxBZFHl5oSyKu12nQNZwncP636Wu1+R8D+AsYIZ7vFnCcDC5iC3I7e/ll9z3oUxEpenXPVYa Hi9QBJtF05xR8jzWyCxQgLomETZncz8DQks88w7IoiBKd9c8kLFe4iDCysBgzq1T06hehG3/zdHO mAgsRVulQL6w9NqFhHehf+sgI689sK54Gwffqiylb8VP9x8rLwMr7HT6Y4k7L7BpxC+9iW2QIIbC ey0eRwaVVE/nsbUWptKcHuw8N1K1o1xa2Q6qT7faMBZVkXJ5rL6wSmg2UrG0cFTlqoRjD84CwtHj zf5Cb5OURWjosPjxhML3YS8KxTbGjrYzp4DH8F4k+4Chdg6ipsEL9/ThwnTxFQumCCDJ3MA6E2Hc 4C17BiKeQp8EW39QSl+FPCm8WKVlIs8L6xsk3/4whCLzzLTCf/E49EFrZdnhdkwWSqc8u2NQHMBf 5J3QQvT0U5Tfx0lTDBKtJLB8KeUSA3XSW5C6VCwJoaAW8g9mNt1HtRZeMeSMm9zBqUxrWa7tDGu/ rQ4iK266vf0/XvS/ieCZymGAT6YOpvToPyWZdLF3VeAsN2JJDleekKUOk13f0VcVMWup6+kip8Vu ZXKQ9vqF3HaA+EzKq3Qqfs7pPoBacebKqjLFDNECykVgz9YvsCR1PWlJhlE3Jk4ZxJbk6e3njy4+ 6ogMEVhdZUqZsefsA4uHpDDTtCujMIbo/ilMYj+uxCuaEhsSr1C28QOLQaaBWgKgWyuYS+VpANYz sfQ+9etFQcTAKJGhMKrWmfIzWY++4RyK1J/vQH7jzU437YBTsKltbqmkUIKuUU1PrCuQw/aATIWk syFUxLjEKwgwi1dK1NhWwTFaEN3mNXnjNLtvfFHUkg1/BDYHXCUu7hL+/FzyelTTElqlnDpnTKHP ylsyrSBbqyD1ZnX60dT10EOxGulFEC0gvQT2a6ikOuGAKgpWs5tyzkzXue91I4UgE+/52B3RJa6q /JI46CJICw3rPAHscBEQMSikPIuF1WXk4vF6Dyj6Q9UqlfAwxsmGISQE0lCfs1ORsm/Tla6U+VXW 8G1M7VlWCTGLXKHvybwWr/9C0NRQrNrI3/8qCrZpJb4ovKPvOeqPPMIrqCI8bhcSN3rPFxQWvwB+ muyvOcelM8Nada19jM9ujwJ5e133rq/Jw3LvQQmVgad4RVEtwSMP+FUjt274StKtY/0NCxBfAX/r L/TIlXCJPT+FKnbcuiPjm+QGX8OABH8SFLuRbVBx0p3jJDIqmGasKSteFnOYlNHBBjvHWkFVxZTS c+K1rFeo9Uq7N/v3syyh9QiiBbSewP4xhReECGE9cxrJkHHZ1D9YLMc25fhm8Q4RGPdUH8bbAgWL QpmwOuuUqgOwxzkmYJMKkucqy2uzWVvluzGFa8xdE+USRAtQrsAe9X2hmjAo5QP6YkISMj8qWSDF 71Zior0DGFJhkIFGN77nXhHuRBnp1EH8s5uNbZL/2RV1VpgCJqQkFOPml8LMF8dP95B5EyVS7KFH xgz5KxI/otWMguhhoLuz1CwdFjX50Gy1jgo5XfYgwe1V1uhC9rmsRVEpa+qsK7hEEC3A7gL7iTbP MLjETM4mORU0iQpWkO5no2wqFcWWn8gfDKyW11KGwETvXEF6ykKnG24Dqu6cHzLQw7TD2Kqr9ij5 9wslGKVusqZdX0OYFYJZvq4wBkG0AJ8I7Oe8keuIDt9QWEOYbcwU/ytcozjrKyIWdO0J4hlQnEOB viYK/V0DXfGVo1JVWW3nw33Nb4mXzlXq5dZdLddH6Hm1NkIniBYgdIF9ZNxo5AULsypO8AqtUQM7 bdTLCGpdX0UkDyMOqKDsFrAk4k3ZDQmCONhhn+jlmknj6qwsZTZiJXaQbg2aNXNAsmeI7p/sJfb3 0I/xydoxEpUbIITAHJEKFaQCZL1bAYPUU2GLUWhzMmoxulds84xxVBq3jSvknkaJ4USr4B6CaAHu EdjH7Q7djJhonoUCVsp4SIzzu2f7+fCYmMlBG0j4h+Vv4+KKWO0JDfEjJxEgW8hxLVydFK+zd4lb 9CPqrPiU/fYqV644ZA++W7j7Vtc54ruDtt8yTAtwnsD/sRgGAyypuZqjIEbHWkJmOsfedNR1GDw5 1UIXdBh6njjnPAhglLO5IDNlNA9MkqX9DHFA6bAkSTAtQJIC/8+6j1KWjbbUqa0ULJSW9lWi9DkZ vqHSZ5StQGQ9T9WXUR2OH/JAdMdZPK8YhEPEjXQ4IcnG07sJ6Xun+Q+grpugRqHg/erAxQNBO8jH +lI81AF3hbdZrgeNEhLl4gxr7GeNHf7DMizBtADDCvwFYf9Io79gByv0L1hsP0kMV0EBK+SIBDwu Iruophtz5bjBIzHNgCpy4+r3aUde6UxpYRKtYxyJ1jRPeDW07EFagJQZe+4iAB73LcpNyD5AX5LP BM3RLRQNi+cAKTnc5DoWs9MNQ8BRT4/mIFzgcI6P755jbwKUxgQFeN7ikrWcxEcyiwoKy2aLOZuy iNXDvdKrNsYNsPpkBDs18ddJ3eSrFpcaSqHps4cVGwTTAnJD4D+atRertlQ87SlQbTC0B3ue+Rkh fp4D8YN7S26oShW+8lIYsTL6HkVEpjqzg7bc6c5sWK2a6mWJp5sEA5Mo1ADnrk2Lkaq0PLMOK9Nu IZhbe1gWI5gWYDGBP4rkmSD7eR+F4IFf+CXxExHdy6SPmUg50Ws5bgn54yq2Now0qrkpn9tXr4Gl i8evoD6VRPTc2C+Ty2LRRMZ1YdZQbYtmzR6UNRim+2cNif9DQZc4+kEyFjdnczgtlKbjdGwiFXQN jGDoLu3fWNg01o2sx9NaYWPh0oTX1OsjPIJpAcIT+EuzB46igkPpwSBH5KwHBAzJMXCv4JSD8ykT RbxrZrIVTLKIWaXJsQuj9jwcsUvMsALe2ExtjMmMnCCylnyLqsu1TTslkBbgF8Z+Zr4b0yiI+sJR xlOF0ZJ+4wgvrNHEsWxxA1c+SmtMSgE4JUc2B4j5pvQn2yhnI2Xhkrkpu8TYG/foBFia2Cu9OmL3 IC1A7Iz9DIknPGYSoM+ghQ1czm9cIr3Ii1JWXf0qQ2ueelGVcdzejAYaBuOqvIWTGO0Cs/myUPjD GLYwfCaqQ+My0UQFGq0949jmWaVE8eQ6os+qdGCsjGUIpgV4RuAv0pzAEscmvTiuRWbz434sqEzA PHjKdvbrn49smv7nr5kR2HuIa7JMoClgUVdgo/WxZpB0fLfvKHzc2hLPKeDdEKYYb9vc5KR0YdHA 3HHbXDRRdyZ/+nwYPNVkYmzfxw8NTnn2ygKqjB8ZuFS43DO9brsj6FYxg1cC8xlzINY8004L88Ir lC4iFRQ0rfn4kuyQBiEhuKJskcZFCbJNOuiU68NHkpClhBDfZKZB3yU1VSP62pCWEsoQjO2eOX1G ttRMFj9ITrv7PGA3VLuZ7TJdhE1UvSI2EcDcZSQGzoBM1orVTdHgBk+eDHciD40cW3P0h4Gc51dL Ks6O6OAsHqGqz9lOxONmRxMSObuBJgUmR/HFw32CIQF7zQL/xEyUOgRQzTYrLMI9RfeflXCPAOaL wCaazhNwF4D4PfIhAv8GFkoGBQqxcbj3fHhfqCAbfeAxR6lmH0f3MCRWC6q++6j3ZCKjtC8vZ8// WoQu87WcPkCQcB8vqlT5BSe2BKnwGEsw/N9FcRKnQfXiN1X4dQoMDmgFibPBEnHouIQGVbEkpeBd ZlXo3N24AiuiaPtTC1ZBchKY33bg20Von0MbPBZqojs8lm8zxIlMnb0n+4jZ8j7wAulK2ASwbZya GmmjzhjNWbl5t16Oolb27Ws4j6lo8kytRXxKYGQg5b1w5PxG0+f/vIO10rk8KzCodgMnT7/iL0c3 QiMgNa3nTiKsS/WV45SSzMKOt+m4sL5ToXR0UsrkGbb9LcdKZVWu2mBq2IHPVZGnmqQPUPFLouNT xqu0+PiU1GEuozNW/LNmZ39FH6BQJjPBWTbs7Ryy2dHla9Y10ZIhuv8Yr8SeqzXwRIREFW6vjER4 ChYXclEG6EOEw6LRCD7g0PLC0o+lmUgim0cTg+F0FB/aVWiObDi1D58TfIOzKulM6ajFUR5TLAYZ ghm93zJ6+x6OONuH41/zwzAiyeoPTSYirPieLMoOZ1bB4cDhyc1+6yDCftpoI+IPnPLFcR5R3zGe GBqsjT/sx0az3fxJMd+yoYvBJEp/1EBvXto1xUksv+zGdallgUM9H8Qbg9mWw0dzN7pwWD+GlPYe znENzjmFpYmcOHjG9i+oefkzrXQ54rN+SeS+hZ9mPCjzP3EVzRjQ4BW45S1Oa8JhplcTBrVpsVzg Qbi3ksy9IS0+GwydB/Nq4gzQxGQ494gmM2mSbWpZFtrPqi2ytqJQGD7tHIoHCeRccWg8V27/+Ds9 yzPtQk8sLoeF478xd7/B3jT29WJJ/QMRD7MvTa5lLlf+lBEVnDLSB6p0OdCgmw+ROEvqjIbgnhPL ByHfcLJt/02ljYoOwA66PG9n4xvJM4S9W7PpvIKmxGUMUZgbjkU0QnpcI38AJl9uAO+PJ3BECR3I +JMJHdEZCvVYNPnELvgHUcJAVBmcBBCjw3Jq8nhVnlIHDz2DkJ0NCVudWRfFc30gMvxp74+J3Xjz saJmdjDIAJD5bDA7BRoNCl2crOENnEq/5YnDX9HEywO7HnmzsuGsDNECrofAXqTK0idFTA30BTOB 02d89bdeIkETlB/6jAJzprCLorPRXTgwiAwynCJuwkc7RQHoPY66merfbcv1jZ9r65VNnyOA7p++ Be57DyP91CfdvCEWoeNt3rOj/o0lk6yodVNuUYEUXfuaP91rWQkyCvIybn8m4S/HB8eYTQ1VEdyA 4eQyzChTHdpyycN03NBGa7mMQlLJCcbJELXBticc55o4SIceh9P/ryMzbWSryxHI8fSzKWwS2zd5 2PvsmR5sIEtzBA4aFE9xqu4DGb57nBkhDvNjx1k8xwdE8AGo0Siq8c+9l2RJRQ6vlea2ye2PpQsJ q/5nOAwYIMxaKyNPl5US9qK7QqZUdp0FCXKvUKYJdv/jGRXhQK/h5Ylmk3H2Z2akF6q0xE2B0021 kJaQPIM3cjMAOmxA0hmq3xQbna45ydsgm3AoXVxbIlqTKvbw3L8mZswXUMQlm2FC5wXJ/9hEBMn/ j+hBOxFu/geR14tQ8NPExrtWOQ++Jbh/3jKBjNsPHM8co3b3P3GgXVZucgwKhqjQsWtwebnmt7Tm zOrjwqPk6qx6+Iwk+cafdzLgcYdpunt2ypnGJRqhtFi4+aEqVjeKkEC6f4khsP9qF6fM4wGaqSJS OOWB1f1Doe4xb5OGLgXlJqL2DOD8eSXT4fHJCJQ8/YNqQMPjXHtOhMdFAzs6KJEBwaKgqIVuRTaF MFtZsSdH2fVwTPWBJ1sUwlBaombvu6P/B2wSRCBlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKNTcx OAplbmRvYmoKMjEgMCBvYmoKPDwvTGVuZ3RoIDIyIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4K c3RyZWFtCniczV3Zehy3lb7nU/TkIsOemOUCCrXlzo41TvI5iaMwjjNOLiRKImVtjEzJVl7D+uZ5 A1Q3cH4UflS1FlaXfaFmbTgAzr7hX5uyUHpTuv/9j4tnJ5/ebTeXP5y4i6Zq+66zP9q66stmc/dL evnl5cm/Trqicv8NX8HfF882n5/bj/YbVRZV2+rN+aOTsuj7TpVmeEJtlK4L+8FW90XVbM6fnXx3 +t32TBd91/T16X/Jz39u7Wf/ef77kzvnJ38+CQC4rzjY8O8PB6pqCg0wnW6259/vBw4jHj6UqqbG MnYBovn/ZXtmN0XVfatOr7aq6FSlTu9tq6I1WrWnD/ylh+HSS1mmzfbM2AVtKm1fUXVR6bY/fb49 6ws7fGPgO0/dMGVt97OuTt/IE/8Orz3enilVNHbP7Rf2g15uVVVUFgdwpEcy/gv/IIfph21TNK1S Rh58Zn+0dWOBkAnt3zC9kpHl7o/2V9PpNnruUlbKw//MTarTvXYvn7VFZ6q63YHQ9K22bzdFW5ad CTPVlQPHTtD9upY1eUkm+DqsxMN0b4qtru3qlsphrMUAhRigS1PUpaWizfkDu9+b3UY0td3vzVZQ /AhUqNrCdCujwgDTAlQI8/9iQDKjetx8oAi2/QznPUKVnJ5m6CXcvvY/bpBsH+MfdCChZqH88Sf8 s2EwD50BYim2DJWVaopSCybbT9WW4I6Nx2VdrE2YeJAWwGKZ/e+2XVH3XSwCou2nyPs8lTqRtBDk viboG9DoUUQ48vpTDgAVE28Cmcm1G0FZeXsnRmq1Y+tN3xstuF1/JLYO8uYfp2S9ZmRUQoIDz78R 4fMy7NdjeOC+QPxqxAaG+1Ru/satgn2yRrJ2KK8tyRrlSfb1pDZxKXeJLnERXpGXqfKCkwGkgIn/ YyuXJ2VnY5e1HEhzguPcLj3veEzTV8Jj/K7ZySkr21vdWhbjLva6HvHC26B4gOWuwwDLr+seNoVo Xa8oFVyEbaZkmSFcQesnI0IZKYcga34CMvNjPhCYBhxg+9+Zom3KFnQn/8XFEaCzczVrwQAABklw pGU79og76xmlKDuV7IFc7Mi2yrYB/kQMlSGYYKIf3ByAIGM+bJDRISck5tJNpF2Hty4Ae/1EgCZ+ GMhINaXm3PUrt7dGa2dlEcsiM6jwZALoCxxdTBSAmCw4Hf1KrBBqfmh7W6vNjPmxCA01/YpoCIBB GhLSCdT0JJWaQBqRsvOc0M759qwqSmP6ihGokOVvhJlHrFeQJnxd8PmNDOi/89ugjBSCT5851OlL 3UdX/7bVXWGRsHMXnabQls3pt0yZSbW7AYV+SlWGw6xi1WhLUrNW8SJoWduVWY1wB2C+DCz5TFb/ f50OZJq+y/DcjFAfNlcfyFcGln1FUDmxGfHmHwO434RfEXE8AA3Rq4LCj98J2d7NBWMfKKylPFYj dLU8rhlnHq4E1QQWQaqnIpNla26I1wBtE1HKPA/6a8AA4GpyW7As8FbCyGBdIjyawAOTkYKdZfaq rEbsxtu3C+NAZdaDAwLLe3oPHiEb8feZrUgM9ZbyEZTGIlZ+mkCUzwf+Vtcdt1OE513JzMQdTDRS /V5I5va3rdch07S2M14LkgEwf7Djms5og+LrYBclosn9YDJE2lJk6vqJH4x7XzhU0fbRmOPIl27E yRRZvSNPTmBUE1ZNBonKplDNOvR1+4RZjb4OwAgSwXbmDFO/BS8F7v+26KCViVyPgiJ3RF8P6sUl MwH8CzM+xnd2jB4g/ybRKuhRSyOMRZCiXosmjcAQ2YY6tYQ5QROWAAtVpMe3VQee4VeEtYzsxEgQ 7fZb9H2QUwGNIo+4fOk+8fFx1wQV3yw+mhWI01jn7cfFsa6zU+jWgnUADKi+kbHltRG0tQg6cFF1 ELKYd8aW9NE8uoz4JQQs3kC+gMcm8Dw8FWxCxPyVY7htqS3R7X0lVY0JDffntTa0EVfKG1s78lqQ VGBBZTuKtBE3wUPwXqb87e8BIVMbEVxg4Rrs6sOxE2AUSWC25isU7CmEkRSd4WaB5R/oTbDqbFmt QkOrGzu1taj5CMyfAjK8ZtsMW/ZptKUjdf/g7CfitSXvTiLFTBTC845meYdBbXFxPbsMwHysrBmn h6uu0HUT+ZryOSzyB80TiJ64+EiaNYL7IwjfBMvGdqWTNuJg+xoYLjJfeJhZDvAzEWJjBnWm+qKv 225zprTjUbsklDNt59l2auOWyWLVwLy+wQDyDhjdOHvXraqVwy40FkCMluqFsPTnQ3is7JQEaOtT BS8W+CLeKOH3y7CTF3BV73/Xg/CHz/x/vHZ+63Xm6+WwAVbJOO3DVkRg4cM9DJqF3Wzt/f3yR2Sj jH2hgaQFr7KM0qSa3j5pHysqpV1i1D5Nanz5o3ER59lI0/1+tdWFHUcvnCXVFQ1AdPtpUjj7zwL1 Qg4CiAuSoSDxa8yB8jyEm/pDrkobudQxScMzvPnMWj+MAPELu2mmt0o1BJkz2Vugcwsm/imE+B4h O/a3wXCh8XYwHp7G9/fc8xXT2L8Ig8L3X4iK6GPsd8QGcPOsS8tlTj8BKgrs7+e96tZPLcMA2tNI SQNOO+RI6couQe0Jli7J7yVFIKgp95hQky3+NwttnYFPMljMn6fZW6ALpShKU5mZ2JEP4wKEQRJd yZy+DeB/gmJmN14Fe/hy5Pev+spHc+p+bz0O156Ha5BmsTfu6mF+WhWV5aU7N4wpZey2dUirjRVn fe926sxvFcowSILKqAZMA0SaHROYRmXiKmUMQLKfMRXoMllgkmM5Tu4bA/2JDCJwgX1MVC7Egoew kYR0hNzADy9pk9TkThd6QKdZJd2j+Vdb7epPIpPrkmhcifpvGDKaSH16vKdki0rGE7LUGuy5bV3j ElR+mOjj4edfgp4QpWwSQn+YBEojZiu6H+yTzPsK8MDfpZYSwCb+zG/2BNllZpFGdnWVyZd6MU48 dTQ7mpH9UKn20V3HBZCt4LfiEgunO7RA8+lMa5UQ+rCTSOcgNe6x9aF1L2P8cm5aSllf7txUqune LdsiDnRmPw9BBbFVgy6B5JRxZ1DKTTFHViYS/JDxo9pCmYzwomT2OVt3GPImlrMpDkfu6BRQuPiY SannjBd9vaf30kkZT/As5AuYmHEZXkyJPNSVZsxZmDur82Bp5XqawUkm12fhV9jAbwPlRwYhdcMv b22YtrdLsSZrQyC6fWsDZ/9B1sbHcs9GH6I5YCCTURKTKMFVot0QsUfTFhkJIGBSRiEvX5N3JB/3 l0HE3w2qLjxIMjdD7SMNfd0QGp4rsyA1GlEYeGBUVV0YKWSgRhnIN1qAMRvLK8Lar8XnYJq2aNPa rGNygQDRAlwAZg8RECyUIckLovSKrXidmg/wRpSB5xTdzpoHgdYqwnX6xKk9vCD5NP57vBAM8yaC GXOd/GBS8AZKeKBSijDBaRYZRWgWrzzUnUtAWQiZdK8KbbKDLU7T9fDPmmg6QLQATcPsP0Cya1bi n+RHV+9QvTtbvanBouVp2bS8QVxIGNwPWmZsg6NTIB/ddSQvroYXdO1GftLYcsdqTCj7vwdCPgSZ aRBwJxtJ7AbtWUjrYrHoSIbvjJHGpQ4SNyK3HQWQ17DxbviqdbltZDWYThLpcH6lL9JXIhET4ME9 w7YPux++ULMfRIXoFCvRLsy6DAyzlHVhPty00HaTwV3inxxr244DEFwaK70+SzaNiOR4ESHM6FsS YWV+Nu80jpBxTEUjRflHyUOiTIW70rmvMTyZSTJIHCcsMep9PikuTfDd75hPb78fYhjUc3TDvCv7 +7rsIusm4EZYi4z3JPAK4Q8hdV6YvGeWdcxHaDbWERiJpMqvgpHswFmAkfh5fxAjEf4wn1SYBhvm G5jcH0vcyAESJQE5VaAqm4x38eWc/4+5LEHXocQ3QawzzgTx6REd7nLEQAdIhYuAbjKu0ztUu3Ku 6iSVRFdVofS+xcvIzli4rYvRpTN7VtXXRWBagDhh/kKfM0EOIBFElv3G0zRj1iQiotnruQeABJ+H QcNnRZLDc0GLFkJjFASzZXqsEGQm7OG/Q1SYGW/9TN8wFmwn7CFt/DT9PGG5mar+ShV13a+CTstu fXQaYFqATmH+aah3l1U6lhEspzAEdnLWvyAxMVyjIJ4nbShXEcjyeUJUTPM0BYC7IqgNSVLehcny LR4HZyCJG6KDfqa6uyssJGughapvVtfYUmC6fVrA+UuOAgl4M1ORNKdKWsDEucIgkKa9z34sjsMj 9w6rKgW5KpptFEfzQwjnhogaExd/D+pftl7CpflAvcSEqklt3wkHUmR8oTstFV1AmpEHMMlWhknu LFL7hA4hr2/CdBHEmdQAGOZH+j68xfRgUbEfsr0KoMcNyWbSq1tTtJ3qVsFvOrO21ocBpAW4jcz+ YzIb5DURw+Am6XQNL+vEFX2UlXrO1Yj3fVGV3TokXqtXh4EepAUwUGYvtTDfhl+97O2nuOfsWeU3 v5wy0swhVhpT2LBwE6umkhJn3g/y4O4FVodty3VgZmM/mfr1jouaAaYFcBPm/0H+PdrFO3jaGNMj 2TvXY3UiX6ZF+w6Na48S9/Sc283fFXiDXXbBnAfEQxFnJ6YgMJ8BfDGr94Sr02ZOWxd1tQ7SMh00 8lsJaQWYFiAtmP9taR6ClKRp4KxLjqgq494jlLJumP8wo4V7253r4CzKRTPcBVRxiNGkOHKGgPi5 XxF6zBgKB1sx4aaUhTYyjEFe6XP82iY0q004XrBsqrJFeOKqr7SoHcsYDnKIGNduaSVC2NJmvzb9 MMC0AKeA+YvWJ5QPe09VMJrei14RL3LFyx5F09JmaBMZ6Y7t0AFpR+nUZ84CaUBFkced5B4cmpWS 1T2NGh20wbo8HoEG7D/lys7ZEJgWoAGY/x2sGg9RqST6CY1uISt9UkuljeVAiRtKD00zKuPz7vGv Qgn7i1QrfBJSxjPmeOtqEhHxdFVo3R37gJfKCpO1GUAepAXQTmZ/WzratTxGvIsz5yQJKPTopsnm /LE3lBVi0U6Xoj/MnMeUlvuGKM8XkkY1bhS/O5iJcPboaKY0xWLm+CSrPq6QqZeqIFlDxyWuANMC 1AXzj2uLaE084eKjY4fGpUWzqQb3E1UEjJdR0pHXqmnbvSuGslCzRHsd5DSU1LLAJ4XaJo/SeZ3y lQczMkjVXbGOvB3d9aujDIHp9ikD539bgofWtYHpvUNsToEkF+YSCERs5zQn76AjApNcWiKImFU/ X0hHMuJobR7pJDBZW29yWTaqa4uyrVOqWqLrl5W662mmisC8R5LLgZ1ypzM9hYRoMCOygKlH6yoF CFpapN3n0AAOnUsEiXMdRHZ3d/aI7jTN0wMCuQj5LryDA/TPlBpX+bqEuEldOS8rl88AGNEZOGML qWxwtj5R1PgQ5Hc4dtRxgjWEmG59QbuVfBkmyTQESeePCpFJFxzi1H+HDrmZxSRVu1HMIE7s3zXH ge43dhZ2sWK2t5H+N3dCrfPr8D6qFKN8x12DDrN/VE900tlvIHbYEA8VuFOfpMoIPfQjrO0TeZcR L7z8B+cNUKWqFdO8rqTIg4aEMg5v5sD9OuAkE7rfUxQQORl2plGUoiogR5Yj+pgLrD8yG04SaBGq eyNXXFnXubY+mf5AqbKaNCyJ8fp8n8Rjsa8OZE4JRJzwbPK5XjOp+ptpCsAbekkvDj7AY3Q2Trj2 41LCqQReUGOGGuvG80RHkfeFjhNsGrpgXbDmN8ImQgJSXhextFs35ki6SF2tp8U2AvPeukhsdZKc et7Vys+XaiDLHME9tikZVt8FXZgcGTdbqMv0ZmEN0KDvNdNoMgp67T86E+a2MqqD7srqSEd+aqPW 03UXgfkgnAc3OFiEEmpOo6ip/ZlTtZnPZLoMJE3W5Uh6k/G8TCWCVPmU0SkvacUbvx3acYdqAtmj SWIZaHpmXUQhfk8M13vpXOMhemkywD6rRNrC0HbBurGf6VyzNT1UMnj5stcMvzo5/5/b6xTc0k7B LsGWdgquB9ORdQpW8MRinYLrXKdgHT1E2wRXltEZ4lxYtP612eiyWVVfYHtDQLptd12vo/ljnlzK y2YikGAJyuEcqMmC12vfCrPBfrXY8tUbPnh0GdNHIGndhzLJkWnA6w8sB3f3o0y5vZT/qKlygxkT lYMfvXdds1G9WRs5CEgLkAPO/4PIAXtUQwPJySbVVdyhl/VfYcdY85TnJM/Liqu0/bKGnpjMKn06 duBE2W2zJ0//bWtla11rTGsFO+IXW/ur7Bqdcf79HL6fyaOjha/EZQNj/nrOf476O56nOKgcqi/s Da9yROa7N4sRVHAGyX68BdfDRFvvuk2LIkdhbqyJ5OeM+Fm/5W5WP7wd087M6B7aFNMzujP7jMc6 4PoRv5Q4BSLH0ttw+ZPgxwM/4M/htjhDQeJIpAkC9PLJDXxy5/7b7yO6/2Za29MjDomnvgHrGA9N ga64x+PubWkV6HVx9wDSEtwd5v8B3J1W1IuLF1NbZpuAOozIpSOTUAwNJtF+0PFZfiHLhTQGocZd 1ALEk/mnNIc/4/uYjkMyITLZKfXTabZyjzVVH3UP2T0ZNQ/xncuUwfOxD9URWfsGfCftDjm2Ro+Q pmDZQN2x7sRHzFGoNAC1BCOAFQD9DHIxiS+TFIRRR+j8UZco14dkSbvkrPcPy1ZGmSKdDo6HS6Zh PW6PjEsBqCVwCVYgc5J80taI4o2ooDx1JXMgmGBjERACGtsWgCXTee6Ml7IaScad5zilpFKyxvb4 drQKaVsBbnLEa7CTK1DJXqQ673EZcGVYE9kjE00AagmigRX4yGliXkcLNk11mIlb0ZwdrpBRqmWY LXZDLn3ygqlkb8PFKcPYmZAQ8iZZzfcJKUp0TGjpnQ608R+Sc1AOPLESelDCRvjiMSWHxhGvA57N JDQ8mUca2Wx5DdWtouTQZM7IXZpB6Gpt3GEH0RKswc+dnnOf9hTjR2pGdMv5Cks8Tk44YR0sEnum ijXB6SOsDz1OgYTPXiSd7hY/QmFRKlBqbVSwg2gJKvBzfx/zZNIz/YiKPpamKe/Ex5TsjoqqUYAE urozyOvGFfm+AXIiaRi0syApEYiaowFZ7rOupt0M73XO0srIoO8LtaqKAksIAaYFSAHm/7G7qqV9 iljiQa58Evx3UbnN7gPiI3wCI4aXZurjQE6IHsO67z+lPrlMIRLrJS6CyccfLyG7kDoRI/fHvoiN qalHJJquXVlbTks0AaYFiAbm/9fg6Q6k8oA5j+kJW9T9DYrN/4VQPpy0I7FJiT1iKHAuCnqdCrrr TICL0AtITIr8B+bkDrmoM83wlDGFbpdPS202bQ2tNo+anmeRDYCZS887sNfSdFIqhCYlsY6eKc1V cD+enKDMulOQgTNJ2uSAKuwGEXjovFnv4ZEz3mTJYHczYViThujF8cYn5usqD/M4uHd+K1Z8iBXL SY6/DucxlHIULU2elXfw1GUaEPe3abXJCJN2r0tdED2TM22KOl7KUPEtkfN5GXfrVN+4qpW1UD0A 815UH4j0MiUfjKaSYw3y0ZbUQUcSZeYPi8KEBuYq+B6xSjdWO6xozcxcLUbu8OUo22XaaJfVfcEo IZOS65Enk5HrEaoIaS2RO318FlLkTf/zyX8AgSFfWWVuZHN0cmVhbQplbmRvYmoKMjIgMCBvYmoK NTcyNAplbmRvYmoKMjYgMCBvYmoKPDwvTGVuZ3RoIDI3IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCnic3V1Jc9w2Fr7rVzCndCdpDAECXA45JOOslVVRlpokNSXLluTYWmJLjj0/Y5Ka 3zvgArwPxCPZTltsJvalxQV4AN6+8dckFVIlaf3f/Ti5OPjHYZGcPTtIRWGyKs2by4cfhX8/PTv4 9aAUWf2vuYC/Ty6S94/sMFUiU5EVhUqOTu3rVVXKVDdPyESqPClUJbI8Obo4+HH147oUpiqLanW6 3kgtTKGK1c/NxUqZVbL++ejTgw+ODr4+SD1A20MiszFQtBGVCqD5cC2l0HlVrh5ZaKTIdVasXqyl KGUmVw/X0ohMWVgfrDeVsKPm2kKYi7yqtMZXLt0rN+tNKlJTVKXJ7PuZKLSSxerpeqNEVeaVqZft fh77+yf+F82ZrDdalGWeqXomGtXNpfGJ39ebQpQ6M8XqqN5MnZZydeWgurA/CmOkcq/oSq7+WS/E 3jWrJ91CVGZBctP7JZ3Q0C/dtTftu0pqO/GzepS8KoKhP7bLyUtVFCthbxdpWurVe3BtI3OhizRf fb82whijmovu7R+6J8vVH35b3qHbiR/SLbpa3fOD057T7j5wYAOI3zRrLlJ7+7rBOZVZ2pA11h89 sJjBn42b7w+/TQFg/ufvzTuyNADZ5/ZcdKlKZXfePmi3zFSwGO2PlVYt2MGRRu6edmVhoV4M7QI0 O9Eu0MuHNXFJaapCrj4h4qThW8zVMiBJ5SZKox8VTUh44pBezXx8qRHL4bwEzA6H1/GcQlpSsexW ZUIpe170DjBb4gZXPR5QnyH7oOd7Dwgaho2zLHl1RrOMSAkds4p69O/XFrulBr4N8wGP5tiZfwXE C9wmPnvMbdMJt0LigDBmJ99yY4nlD8/kYKbfPL97BI/ia+d4pA3nrQlDOsZ7TbcJ1hta/Ym/eM7s Q+auAeuUzLVkLUuhyjyflxzzKlsOOQIwO5HjaUAV7m0iUn9OnMJkKSYTWVVWq43fEEDCK5rwuk9b ih3Q0/cUZbk9f1Kv3ahK/TnC6kYO6MoNfcJd3JKuIvk/J5qWdtF6MXgK0Owk9H/zghzQCpDtMSMj 6J2A49/Q7OcxXh6SgkcgkRLucQpGifT++tA5tZYU7scwjEceP/Z1uAOtknk8IuZg3u9YJk4z33AG Q0Jq/WeNCaKUwo12lF4GNOUwCmjB2QwZAD4v+ufVktAfoGHR3x8lncUTuvsE0fZljKtu43XVI6nu sB4OmlGWxfJaEIvWoQlMzNDdBzNzGxuYQW7i9196/L3vYAL9CXH6uV/nI3rA46dfEbJkQs766O0Z SjzDjaxEZYoy2UhV+1qsTmOfPPrlYKOslVGVWdLYnXmr7HyHjKI1Q5Td1qeN7Ex1ZmmOjJNgByxh ZSLVuqo3wxn8CW28hBcFvpjCjWqbh/C3gt9lg4tFqnDa/3kETXA8FYznHnEjG3uMW4Gi4AXBrzUD qOZkGZkWajEcg4DZSV6Cpu5Jwv/ghOUpKm6xDQNPkk19GwmiHp53V0mfvGWUuFO/6WKtjH09lRx1 yrQUZeqdPAlwgnnRRSm774vBF4BmJ0sAHFvkXYRT99zYHyEpBU59UPLVdC4/+DWhhdtQTnlH7g9C gdW/CKte5S2Qx05qtLpfHviESZ0CNV+AxuPVqXlR097Wy1F+ABriGWeEj243ARFGTLb6NmEmyHnG 5xBblIozahk3sx/3t1qnqVIrsOBNnl8igr2Il+fG1kM2YWL3KbN0UiYeJdrTiC6/FiyxWCGM92T4 VbxBP39e2zHnwtssrxkYAdWqXHeKmbgDH3vMPOY8aR4xTmJ3JONlRD3bsUS6+4IGY7T921hc8uL0 csKTw1vISU+4FqFwNSItKidcHxAVOIK7wBiQw2JcGkVatNbdHMFZZMayx6Jwc4QBEo5fzk0XpV1r uTS68EDNQRewA594+UHOj2tGe/NY+XyUGlj/P2tpuoHpIuf/j9WRRwN2M2g7Wzj+WwHOyfzQD94X FzDLO6gHOBQnjeEhUEpPAnbBTW8QXUWLZB3/rCbzQWtkZkYhvzjjbOZLOjkaqPHuW+Uyz5Wj2LNY bl7UQ5eqUvhye8bKGB85y/oKh8UGqWtSEZlUNSl3hN2//HoIu7CbEtH122sl7BxqZqouhb3hIZqD qGn1pIU9YPB2wkB4nwwEDh0vI5K4pVGC1Aqg4q8A2dnoFqOhsXEKB3s+ENQnryYR3YALH97SPcbT 9+s6gBko2aSHj1udUlUFAKSYSYB4FY3IsBUy+eCV92iaw0Z+19DCS6pLmtBCNcji7Gl3/5o53ivP OIbtMf/7oY8usobSgPdNWUTN8sj5Vv/+7ODorb+Wx612c6HnTM7vcZPwAnjcVLAke5fT1aRVFY0y LXK059A/LyV0qk2Oj8xk5trh7GEuxcxFaHbywDBBpssB3eWmh9ysuu/GZVk8q32d9JWddgJYS+xe 5+Ktl+AZinPIjohTkZLJs20fouW0Fc5md3OwqW0/+NtfBaTBehsrI+w7wB3d/LN6dIwqhFpMChdC s5N3+j5dDHR1TrHYMo4UeTGDiBq99mRAFZnwPN1Dp3eH3BBKfekvCk7wz4szdt0LwhmA5rWn7P7C p+zuwMesPnHKaT1bIOQhh3sECipLrEVG6HLG+TQDU2sopLkfx0maCb00v4mDaQ4Li9YP/IfJ4L4m A5qRwwEy3WfMnS7bqShHlAEmSwBGuGiQTacVppg8ZSJ/z7fIIRhNGXSMkUv0Q6kOJBGLdQ8iL9gd uRRskuASXO12entgCyMNAmoG2sAd+MLLUEIqiheywvYlowkHobkOnQHHT7gMlKNG+uVZWkR+qs4X SSTEp3vP7LPSRWWXsyinFYE0B97A+ndyW436rANfhmOuT2LTKEdc4tB4+zTbKWsN/b/X3CrHGfK3 nlNumQx/Am72jZIiM5ajPo91Mr99ivdEUYkMcnXYdNaZBBf/S8lsrPX2QeeSNsLoMukHqpiwMgvm R5wZSrYpCRUyTSmjkjdSj7iMyY41qQxtHRo90BU5DZFF8FgJ5Y7cVC7oYTVtf4QmMKpIoF7Rk2HJ AoDSjqrc+ovCqZsbdxw1xVjW15zJPaAPnxcYJ+v14zRAYS0uaYW8nlFsQNkC0F9iWoobkSq0kDOM qkCxn5MxILfQxGeVGsY0x7AkqeFBmkNqwPp3khqPiZ1gBaVHLGXS1msU7IAuRJGlxjEnZOXnXFgP cky+r+FRUgaqzH+gINJLMYDbjwge/xs6dpz/Jsjb7Y8FL90G8mfIPZwqYQzEDhxfA80forZjiQd1 CZjxfjYmy+ISCJLSgF3dB5jKlH/1AjREx+c8R8ulJJ9fsCqdW3lQZMmI03ujtJ1O6jhK0fK/fQQq ilKWbKCic/xPpwZjpKDAmMTOgYpyKFCBCxlIDc4CCP+KgQqtUqEWE6hAaD6LC83BE0F8kCv3oLuQ hBH5s6ogbQ4UYTdMgPd8zUI36F4t+LSEI1yKBe+BmkOmwg5w7i1vYL3ktHqQZuTpPGdxzitrTJko Fj8xrtOxQpfA+uIUPUr2AaUadfF/kaXga1TvgckAtVN1oYgqIbof5VL3jAe2/msQDjcqD4Z7h0wX 2KwT0FQ7gIt9ElZW5dBYZCGERUDNQFi4A1u7xp5P2IVB7ugW0Y7JwFffWdvy60AzjXP3mMS/njLc C2s3+B0m5FC81al1b9d0WKTKBNj+hSeBW46i3ctvgQW4P6QvtVgczjuY5kB5Wj+IEuDylMCPXP5V C1hifAdBw4mAIUcEcW+mycRUqSTgKCEkWS5+HMhtoOfietCAFIK4y1hmBBNCSbyngvxsSIZE29Q0 Z580U6jl0YyDaQ6aofV/6SXCNYOEAYOmoGPgT5h2ItdoP9AJ6wVmPmDSBudHYwuBnzU0KnWO2iJ0 q3IzeY7At5NA0mHQlu098ihQtOKhiLZOg0DBYPy/7012utl74yqZ8yaX+/QTZnla++aW5CckkOag KVh/X/Wq01ZZ1Yv1HgJGs514AqIEj3M/MYUt8yGNxQNxDEJw3Ks5oO7Mima6hGYMy0AzD9IcaAbr x1T3gWYNTE0YnPw33sF2jrFwRidiy2nYIkYm5ZQv5R7y25yMMN2s6DFdrnzNtXJiUujZ8roBl9Cs WG11gCrWSPaK1R6kObAa1r9TkMW/ktFdf40I49/MY/2+YC1/5rR590fjJR+oPNCWMk2uluTU373f x1Bnjf069XF0fRdO/Tmtk9TU7D1LZdeCYdbgAk27hOACQkPBBeLqoCexaShsof5wmiPbPKDzD0mZ A5MhEG7BZmKrJ6bydcgvDSbPs0aEmbyKltAY1lEDPZVtUXg2UGN1GfBJyqeYyiueGne0Y9R4U5Yi szxxCVSoymofVEjTLoEKEZqdku1fb24MERbbtpUv8mQrPcJs+XbMn1a029gQmHWhYWJTXF4N/oKs 5xepyecNf8DvoivaOQ6+pSyMozhU89OawBynqbyoZ0kmGh3tgcSKgunRcfck5qddBIkBNP0Em47I WFOI9YdFLe4wWEPi5jGKmziozhJVjxR9FtMx57oYdwfejw2xiW5hIelHKY8P+2pBnmJh9oBQZKsF 2MpsKvQrvRtkoMyvPk3qSZJ47/yeKS03TNePu6c0P+0iKA2g2UmYBVQY9eLp+bLHkfk1ebInynvJ lc3i/Nl2qpnVS4vSJOMVrHvAbZP5Y21yJ6pc6OWEdgi8GVwpuBeUNn1E/oJey7l+4xySAUziJCdT 2EyB1516Iyg9NkTJStkH8j5GZvvLQ+kwUsv6MBaLkR68OTAS9gLwcCiicRzpG52fLW7tOP0phtgH DeN4znwdPXXc1xz69sc0ZpZ1YbsBZumKgfaMmapaNGZ68ObATNgLKhAB9wz0zwPFtt/iXEmXppcP OHcecx6hiUiJY2RDhvHWCYp8712nQ2ee7bKJf0QI1xG1DDTRHgvgRFFzLoDjQCOXF1Bq/AEIWJ/T L2E6XklXaW6PUyXLM4itiuVavyyRPD14c5An7MX7aOoxtvD0l9aI8EjzD77D4Ua95k1jxpkcCxBA Ss7b1SsK/otJDkszilFjZ42UEhBbRUrn3KU2bjq0S3dDIbAbf06AOaR+MhDAQBnG5I4wVinXM4Xr Dn8/4t8vmKfGg/jeBcXVLU/lwWP/TEZOxcQ92W9O5lLINIggblQqheoCwXXNw98iEIy/9WICweGS /haBYFmkTGONO/fa0bSDXrv9sdlGEeE35o7YLG7HTv34ZvvkFGV2sfGC/qcI2m/Bsmnv2H6gSySn RgQQtGYTaNl2Zm843InYp1HC5L5j+HKUcmlKpk3J3VOhn3YJvnOEZiciGEGaKDg72I1tqtkVk/LK W4KFESbN+pagK9vYK9bpvPky1NxY56ddBNYBNDtFbPBbHUzfp+H6lprzshk5o5+bVOAS0jQkeeS5 cjkuBDnR5HQ8XtN823x58RqZaaaBx91jtp92EZgN0NAHeb8M+ne0ZZKAKgNtHJ0Mbxs6Zmne+xLj 6BeX+rrDSEF9nDxNptG+C4A71FLZ/HjVzrkIpHKg7CShqSgM01FY3jXdP5ft3cQWGUx2LDtmXAvU T20gHaM2tANP70J4oAVzSy/vnPjjoJr8Zq0/lPGPtHhEmWp/ROjiGSBbc0vYNtSYOe7aCBonJutF QT740kB9lW16wCy3HwHvfEp+mZ/XglumdQ4QGxGJg5fBd7+wDdF+cbaqmlqGxWEtwHUPLOw4tjSE P+cxY2Scl2G/gShSPNQ8vgbm87ZZaFlwKJBx8eteFjVohGweEXxl0OMd2enjDR5DRykTiKOaddCd R/28f3KrajU3oBYg0Glq6ZoEDUT8rJpcyUU49er4ztYhvhnJCOC6SzIK2Cq0B42KFuuTzoU0JZZE AF+lopBD7vOi7Ie/hpr++m9zDeglY73oPCEhnTDREMgGcMvGvejemBIwTHYr9Qaij/Ms61t4LeIX xnenWRTiA1x3/o26czp8pvB6qpApaGcSjwPaj29uSh0auL4e8Rd3LZaQFgOpVsz32NH8Wxyy5ZnQ W+eEzvo5bg/XITramcKRvuuz7iMAeAHJdKRJM8lx71IRW//LYDVOxZ9Z6/SWNOhRHXR1ZmIXrFoS O2oHes5cMTT2GOnolRtpUDoT09qsZLg3mwHit/NNC4OS2ud/pO23CJkvAnx98H8KAoU1ZW5kc3Ry ZWFtCmVuZG9iagoyNyAwIG9iago0NjAxCmVuZG9iagozMSAwIG9iago8PC9MZW5ndGggMzIgMCBS L0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztXEuTG7cRvvNXMDmkyKQI443BMXZsl1N2 XFYYuSoqH6RdSStbu1pLKzvKD8nvDTA7QDdmGsP1ckkiqkgHjWbwaPb012/Mz0vOhFzy+DddnF0u Pnnkli/fLeJNrZzvunDhjPLcLh99Sd5++3Lx86JjKv7pV8HXZ5fLT7dhUb8UnCnn5HL7YsGZ953g uh8hwhPDOr100jNll9vLxZPVcr0R1lumV0/WG8l8Z71Z/Q4uf1h3zHgvTRj5w/avi8+3i+8W/U8Z qAx/70SXUHOEacO8LAj7Yi0E09Z3q1eBRMFs4MbqX2vBOqHE6vlaGKak86vz9cazsKrVgULLrPda rj5bbzTzThq/egu/5UOa/S4OdELouDZn3AQ+G4VuL+P8rrNKrq7TJLTQG9jzBdwt1noNRCda7Yr1 LAy8EJgXnWGWy8it7Xn/RsJEI1034vjRpUQ4prv4MgIh2x+BDuuFDvuE+ULGnQc6xrf3p0NaRMQT LKB/WksWNpFBPMOKp+GS6lh4UOPSYfCBuPHntWK20yIiYJBQBIUd+PgiiqoQxjuxehoWcloKhyX8 szg0rGlI/MBCklodQ0ZoZpx0ATLDvQIwSdIraOlBqL0YkDAGjuCSOW9ugTMS0mODJfxjT42VREOr UKF5dBikAC/2AsojMCR4ZMZBNhOwy2tsBp5T4LoBaYed1D2QFE1zFwgaLI81Ac4JSlL9JigJFX6m bQFK1quTQynT0CiUKjw6CJQQL/aC0u8D97T3XK7+Tlqfy7CkM0ZIDKs/oJtpoW/WG8UEFybO3rgg M8r0rqFiKnAbTxeJTJ4u9Ai7ERK3P0s6t3oG/mUiC437ei2jAw8eacDYVZpxlmdkgL5GsLwi9v0m AFh3MgjUe2BY74TaoHKymgi7xB/vOO/06i+Z1ldToPueyYZzrfE+tAsL9jhplsEee1lTIlHkpbLB R++wphgrk0CC1M43oUw6Ef85sTbJRLSqTipcOow+QdzYS6FgNYJixPNpjPgpWPEPWU2MpoPNJiiw WKlk6LxPF8igX1cfBiyxAcZqxgor14RDG1RQA8DJRLQKnAqXDgMcxI09gKNBgK/h6c2AANeJIuNy 2eNFc49v/juvD3aScooLWF0RaAFCkWkqHGjwD87ITdHPy/ZuoDkADiVqzqemfSccA9875ZqAo3HM n9wrzkS0CscKlw4DR8SNveAInmMh+a8Io5Iv0MOMq5eUBwyoQVjAUIQNKe+woAgte4Nc2zdo3+Sm Qv4IpWIx3kbx6MlwpS2Tp4ZVouFOqEocSEKN//9gOKK5chgYwa/fyxv8CfR7jgk/TBGBJPOCmAFY zOt9HsPNEFF5BeWHStnghk79oBgxbwRPv4J3ngf+MjVWCJ3vekgJG0JpYMoQFcfoDWwmhulbHOjB 7RQ3+0p1QjgTeI2qEzD1FrobKeKL9MuNCBKrwVYGBRUgsv16sf3jk9VjnEi7dbyljTon8o7ryMWK O/4G+H8VM16ad72TkfSfQBMZnsjRA3+XQeV1LD85LvFW/8k1qSVeQ+5co6ttL4ipJsg1g03x6nod ng5vSZWuio55kvmoXHNt2kjxhRFa37UAeUz1ZwOYEHnH0H+IF2S2uaiNJGADxAdloK0oo1URWOpk r0oGHVjokqQKKqXQ7ABcJV2LVG3OqjFwCHKCzcNDaThZ74w2phtrlORi9CpFyC66B71KEbJNlVLF dE2lKHRt761e0hCsLR5KvaiqejGcGfm/ol6MC1I5hu9hFUdw4/Ku0Y1LlRmUXT1qJwUiZo9GCo29 d3CckHZ5txYdk8Z6HNWTFeXCN3pPZCCq+sIF/aW8aEKyrIzcPbpo5W2bkC1EzVeZGijfzBYtCc8W ZY6ShSmMGiFMYNSQTIPvPqneRAtViKpUTMqw0FOcgErE1kQVGzbGuaB7EgxL1RHSW05JJcJbdvZj MG2mSdMmD2TajpYoGBSQdEx2M57zKdMGQNwR/GbMib0SBzD5th6rZaqyxnufgDjBwC2ADBQgrIgy be/JTNt1fUCvKnZoGBt+uFyW7YJejjNpx5bMwOR2JTMTdwzJRJy4l2Rmk/X9WjgmtADzWZZJJiVP XNO8IJNVLyoeWdnxOhjXSr9AvX+P6BeYiq8PA4v+gZN5c1yxO2chjulgAV3I/87vE3yWK5Cal3fs jH4GN1+Tbg72ndIkJGqjkh4hyruKD0R9fkTpbQkBGmEusLocVyx7hXkzlb+ipDivUJVl3DchkdpH QDUokpiwf2Sddk3oNJBOss5LCuXzoo1r3E9Fy2mRuEr7oLTVZBiSy1qdjYhmTUWNec8UnySxkKN/ MhFyUb+2KEKIsIc63FHkJNLbRZOgAHQF2nPacEgGkbAhKchF1Sc9ruYwvAurGo3EBVr7Tiot1vVh Z3vSggh7eIWzz/kgbgpps+POUr3a5JgAWdtiJaRedjZ7DwI8PWiU2r3z9a3pFl1NZwmpg9dv2xNC Y/q0fntCiAgjazO/Zsl8W7yeJIaVgjDVKwUhp0pP4da0j7nQd9OmEJBggEfN9cPiVHqUZfE8dmtg j64ez1g85QURRCBuoZHfrw0zJgQUdFqOcIAv495dCH7FoM2tGXmAaTL4ld/mDupsE1D4UmEGrElD K3ZFSz2T9zsZtqaFzIOnq7XWreSqMyl7VUEs3KS1/BSAteCabon8kdYTZ5Rpo0BUr7W6uK9bNna2 VKvjF1GGPZuQykTKXn7wMyKLSPYAgpW6wBpt0p4ES6ME56PsYkMu657Ho2dOl3hsBzJBWdSLozB5 3K9Zk1OY+GlXY5OVzLSRiNKS97WgYyMib9sEKBA1e+ECfJ8LHCVMnC8kpoAQSAGUSnvSbQv7fZsn z3hYaX5RuUQttJPeXF0T2/7lNNGUrnl3ErHN2zYhtoiavZyML2MSzHNhDJmjgKunuLqdGjEIx/xq kiv97X3epfM+LQuUWnt4TlEA/jc6t/jPdKASHX6GA44wBZ24ItO/5KGrO1bTXAggbNFcspGBKi76 Ev1H0nqGK+H+OPV5qvv246/PKyfZXDrtlEXQTNsRaqCID3sV55+NQ/QgNvcsVdVOdu9RqEL+xlCo mtdT+Jrsa5pXVdIyn1TVTOH/yF6AsjxKV3vZO0zY/2tWLdeslO7yyda2RAgRtmdMQjQ0XlPhCdIG pFjuaNOf66MN5IuiBjXuuz/Z+1c2H6Vs6/0jwh68FQM8euo1jutFhQuZBhWeeFqXtK6kYgN9dUNp F6kI5TRvosLKQck2Z6KkYfz4JwJg2xYCVUzNA+VXyEbqmq7ar7KOy6SE3Sbcu1pIS3wIoPTLiMOg KP9437SNCowSahqjHFYKB/kPkTnhoZ1cIoGs4yTC6YgADSg+e5h4cq/Phk4VJ3r4t5zjeIw/55Tl alLRlfhDGDua2cKjrkgPboSLmVU1PU0nP4Z8xpHOG9whnyEKqj6Ko3RBMplp0TPDhEHfPvWNC7rx xs3mMyNICfeMMB01KwMZhYvpJOIrA7W+WrILA7U9UG0YWJUUH4mcVt3OR3FDVa0ErgfJbi90lLY/ b9WggCLCcFt+zj/QbjzZR72zyArveOaLusWS02Nt98qH1BseZeCbaeLQpjSqURFBhFFfGWkkneR2 yc2ks3ZX21tdajrmuJOn8ZKlFvlca0tuMqZrLz/5cU6CombG/L0GOddjOFOBS0faiBIcIT9vph3Z yLDdzzGG1rxZx1gxr/TIMdaMTz9c07/N7xb/Begzw5hlbmRzdHJlYW0KZW5kb2JqCjMyIDAgb2Jq CjI3OTUKZW5kb2JqCjM2IDAgb2JqCjw8L0xlbmd0aCAzNyAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nO1dy5bcthHdz1d0vEi6EzVCvEjAO8VSZOfYUTweP86RtZBmpBlFr7EetuXP yCLfG6CbQF00i+wetcSmFNuLofgAi0BV4dZFFfqnWSWkmlXx/3Rw+vTor8fN7Pzl0er07PhWe/Di /OinIyd0/G91Ao9Pn87+dhIelHImK6GbRs1OHh5VwnsnK7O6JV6xwplZo3x82cnTozvz7xZLI3yj rJ8/WCyDENKqWs9fLGpRN5XR85ftWd/I+aN4XNnGO6vnzxdLLSpjvJ4/WzhhTeXkfLZYSilqo5u5 hAcFPljBBbfLTXis4FguwrtMUyl87X9XJ2vv4klqTxXtpVtSy7Y2u4ni4QFBLy1vCVfvnvwjDobG wZC2ElbZMBInZ0dBupN/d8ZLCVMZW+MtN0+Ovo4KIGovTRUuCS2Vd67Vi87pnbTE76AkshHGrZUk dm/ta2HmdxZLJbyrvZ3/ZaFEeKOa312E5uMHr0UVjdU+StTqLv57f+G0E+ECCVd20tXNRQ+9zFjh VdETNxZa1M5IH20hjf69hbRCq8bPzxdSOKllsIj2IFiJF6H5oC8vVzYlpZm/QvWChk5zQ7Nols7V WgVTzF3+ILy9MUo280tqvz2A215Ri7P4Tu+NgmezbBckG31CvnqaH6BHzxa2qlrdLhRXSh28SFJc 0eq2LnXbOWuaYfW3yjSeVf/wNVG9szq16r95+p2pf/gzqP5/oMO70f15r2y4k+zgfWkjCHY9a+Pr NGow9lk1HpKooI6kbPlh0lDQv6fhamOtRBWiG1+u5g9pahl0KF3OZvCAU2gQB3T/1+4zZySsWKjg PatKsspXNULXZgpqU/swIhPUGpDr73n227n3yYuQUwj+RhphG9XAwJNeXKQG6dn71OBrOgy6ooUO g4Eq8rzjR+HiP7PWf4femDwqSN6er22D+jmsTeGznHRdbXq/E1urP07G+a2jQFFVXBiUh9Tr4+oP yPUNgJ08UJyXoKH/jFDmZ/FkeMLikN5PzWRXdD7ok0oXQiP/K418jxtZS2SKPhtlYGsf/0xvYEGu L6hXv1yoGJDUNgDnrgVe3YNHsJyeXn/V0oQX2FrN4vPBFY9qbKqeBZcgfOsSJzAMIM3vDnplp01V OT2+nZpaVAzuO7iCgFx7KcjN1QfUumrmP+eRfYBak0z7a0CX4Fa7qlSEM7ybyH79CUn8BB+j1k45 WeijMI6Bz1u91PjVRBQ+yiiNWPesF5DGR2D2YbRe0I3rcd4EDODJ1IpXSZ4sHn95dPLnD49lkcXD B2NZ2ps4lsV+HCxLHe4wDCyYBMtCwo3AsmBPUFybDfdsC7IjB3cJjEhy1Vwo/Cjqp1WNQ5+0LWDl 6JZZBpWIjIGhyUIWDs0Yw3kT74UOE99sgEkJDiFYzbCGT4ZICdPmsIYfKiRGwfaaUQvYROFLFzQV jp0DTqT3Txga5xnJ042wQG6u5WKKvuAakk4oV9fzG4tlgKKV8shrguI+LrsgojQz/3FON6zRn2qa Fv3FoySd0mTRPPL7cYGGlWde5Ce7szrcSJgG22e9x3Pm8acrvVNKizA/r83nDjyyjnLr1bzcdQRv Vues19AzT+jLqbfpcx8zMmBnXs9deLIGAtqqEKclNJp6y+s4UXLupLGiVtqkT5lBp5Q2NrpfcLWw U6TKUDCKZGjwfsnn+kybuBCWEg325cI4NlupDX6yyXf2AHB65+YyA/3jFAyf9xEbOL8O4DXdUNta 9qmbDMfKTGPiaUKYM0UGHwX7NivTJYN0yOu94iAKOxsB1caQc/kthUNVUmgbnNUbmLVSewBfHnYx j5p/vp4vAroHyV6wKw50nXQK/N4lo+48cMsu9Qm4s7XGSmf7VNNq4bzqquYYtEIID8UEWQUQ6y1Y 3R7g81a8bZeJ2JzdGQQ1rP7ENGfy8coR/Jqa/PCDeDt+EO/gAQjisfWPJFUiBJFCDkGZQwbxJNwI QTz2xIcZxKv59wsrrLUFbQ43XtAMmq5SVEBHLKMKk93tDOxzuIaTGcxxEPb1UAbSNsHRJdC1lTK4 A+HJgWOAME6DhnMwiAaC3c56fB9GKula4ed/3ohtk/fPAXzW9K/C1xhnlGHC+3zmqzhtyACtJI8E X/TPpusGaAZkQv7TbhB6DanufHicW2FyiM66DYNYFKk+o4+KX65cgSy5dCniZDh7hbXKIVnytVe8 ceHpN+ne74gC+X7NB0ToWMlkPu24KK+YcVGaGZdV+5hQNQiEhzO+0E3co2CST9fqsgtZid/QRciG WKZvjV/T1OmDSVu5MWsP3oJF+1cfZLrsjmWxXsTxXXQrq/jQVUmSx2CwHX9LHN5X6zUz53DoYMAv Ol2Re36LnmaZEgL2ee3T9IBV6WKDBf17KP8d9ElMkdoFuUh1YXGv0KS+ZMzLPPzboAWFOj00ELf6 2cPZMMqclYrJ0yu+BCw6qRCnagVFmlSYcx/gNV6u+OEAi7Abs42y2agJtqGLZRndneHhcNqWN2HK dkB0pk87LMYxjQ8AdYpGAoK9OxoqG8WXOdAlAHVCcTCBitscn3pVLmgznWArGRQGp0oLZIO0+Mix pKkDlu+sub73bCh67RSyoVCavZbmiL9HoAEcUR+dvg1iX6KrHVqBS0vDFA0DhAowpW549ayEyuGa WAe5XvXq6RgUprF2BQinxmGiXL+TmC2JqUxBYsb++fBJTDNJErMCqQ4KNFQ1RZSRpOLWpTaj83X/ l5QfYXA2x/CzIXKChSv8YiobczOEQguE66IAjCLFZwhhO81sTSWMtQfGTiO2q1wuEp2WRoFgVI73 gsWEWzJc2VXOS1YpoVGaTwr/+BtD72yOfK/zbmqhjWGKTsZHoDoMtJpqSiIJN8JqBvbEXqsZe+R1 cfwRXYWAik3qyu7tBq3S92R1dZlCPgaDbICE/JDkLPKd+tYrwlh6l+r19lmvGNs0nBF6qgt9JNwY pgE9sYdpmPktjhygFj9lp/0C5zPcGWd5XN4gO+lvFstU1q4HO4K8ehszATbBJ6n02oQX3lgu5Dsk qNSNGtb4Q6EAFAy1gVmeHV6iKiudY+lI5fty6ACZ9kR+BZ+QK6M55QIRiHtlirI6wKNG+oFTwp+7 35u6wOwAQbUVlZxEXoWuK2aXh/fOhdFrp8CFoTRvxYVlhaSn0WB+WHvI4NmuYYlmPqR0CIAiFHVd y4oKz9ziyK7vF7IRQVGa7RiDeF4yt+QPd/OmKmaz5wRugYsBnGMdgz/TxnFbAxxcv0isvahWGMDX zCIxaAdqX0/O8b2NjPsYbEEL510njyQfJFinYB0e/oWrSsBFqgsGC2PVQnrmIY5dF0ew1YsdakJp fA37DOUIZMsAlI07f2CGQz7upp9EdNFWe/w/UYl43IxPJTbbqUTZRyWOPfGGYec2K5hGnJOFGyPO gZ7YK865Umkgk2NAM+6WoKXwqK8HIx2Kp3paz460aD55noHylHZqb0FxObe3J/eY3G0trE4k6Xuo kBzb2qoq7/0wPWvLwo1hbdATuPvAxtyr2eTFkzyTsFwta1W4KlysMJDCv9kSPSb8cy9nHPDeoRuK ga28KuZrpsCSns94jLoArabMEVqhhkeMyT7r3gbiPOmBElgKphrXm4rTBL32g/zePpvBjQHWlfOT 3AYE5doDrpvdi5ap3LGAcLC0tomXw3xCtsiswrOzGhDj7F6EeSp6kxMl/0NmyGrxMeFTMmdU59w8 dEaWl8IEaPKbLqJdtdQhgOLNOlv6pwj2k0lTBhRJx1A3mxHUphgX6wxlrYPnzGW+j4p5lPMT/Ts5 xoJhv2Unx6YOtjlkvMswmwsrLRdBfLgVVeUGJFOJIMrNWj78cqqYga6HVp4PiYdIuBHwEPbEXtEH rK30bODU3TD2bdbW6WnKKIWFl74MftqzqYeS4eBTUaySnOqN7LX/2JLlCs7tW3+VEN41WI9knTJt 20DlLt/mc+T5r1OlyRdsENWSptjicVuS0gSLzenOx6sFKmudhpqb28wbUUp4j+JQ6e7kbLH+uz2C q4MpNdXuAHE6FWvKyGHfdKj1MBTsGKfVLpEKAcbAUhHCtMd0WweHOXAzkGWwJccLssF6+AymzIY+ Br4QLJXw6wW8NF1dY1KlVBlMtU+8YhhVVjIsadtc2yj8Buud2eq3s66H2VYEVOxQM3pwpDy7pdPB gyOQa7rBkYIXfQ4LZbnIh9kwniEvuuUQptjUkGY9jiVkWQjdsyDciMbl4kdxwBT0IDm7Z9DBFQ/k 2kvxbuFmKmzOQPo+zEynJMbu3LxbXftKdaj2nmOle6pvrjbxyxgNeliXPdRirAp/JqlJINdemkRV VYj4CNNfoR4Bi1cgqYXd+R9/GACKIqkwJrf+pzhluqrqoSCLFYk0FGQT+PV9REacDVwNfivOmcqN 77Zk3Hx/gmQiyjXl+ZKW8QE08VU9kPCa3vRDnggdQ6Wdc2WOT+NJF/xSmfmvne9LZ3W17lW0pWy8 qKT/iPYHxmM9SSKstypnZDIr7s3ip0pmkXAjkFnYE3uRWTdJ5WmRkMlD25ZbTIhnazoxs0NrdzcH dqK6181GKjJ+tibZ94Gt7Vn2to63z66QZV9mBR2KY5Fxq3smwWM801U1CHFnF2sds5da2+3ppfdj u9Abe1XC8D8mBZgygUawm/MuSUUNEqK44FbbuzbMbKcB3A8lrXBXcV8NILUhe6V75+miy2nBlpsE g3v2ybjPf31nd+H8Wfe4EeB/kgVY7FTecGDT12aaG4KhYGw1V199as8mvS86hSK4bQBhZ7YAvbvz ErsnMbcNcbFFzNqCuJK0U4Z86Fke+Y35ZY7tRQbKBG/NrDaOEo4pxSrZwcMxkGufTH9io4vs+8T+ 9O03z4Rjdr7MvQIQijzMfQYi9fwCUTeb+aL/xyTDpI6E48EC97ib9RQDd5Brr6T9TwKcMd5XxTbO HZNfawXQzEvuh8Lg9UU+PJN2x/2m2M0cvQL/WIS65Aufs8CD2baK1nwonQeM4pNFGL7K1TtsQ/0u yl5rH0ZtgEhfqsrHqbVDFKyU6euj/wGDosaDZW5kc3RyZWFtCmVuZG9iagozNyAwIG9iagozNzc4 CmVuZG9iago0MSAwIG9iago8PC9MZW5ndGggNDIgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+Pgpz dHJlYW0KeJzlXV2b1LYVvt9fMb0btxnF+rAsXbahTduHJA1sw9OHcAH7ARTYXQJLgR/S31vJtnSO rOOZWYa1BU0u4ngs+Vh6z/fR2dermnGxqv2/4eLk1dG399rV0zdH3e3Vve+Hi9+eHr0+Mkz6f7ob +Prk1epPx24g5yteM9m2YnV8flQzaw2vVfeI/6VhRq1aYf3Ljl8dPVz/Um0Us61o7Pqs2jgieCO0 XP9WaabbWsn1m+Gubfn6ub+um9aaRq4vq41ktVJWri8qwxpVG75eVRvOmVayXXM0kOGBNfrB7PPQ 1DWv3LtUWwv82v92N7U1/ibMJ5I5wiNhtkar/UjRaACDl8ps9p6qR8d/P/rz8dHPfgeZtlzV2l1I Lqwxw8Zmt/faZrvHLvOWKdPvsl8fbTVT64fVRjBrtG3Wf6gEc28U60eVmx5IZW0jradoAB/+/8OJ k4a5H4A4R9vxv+Mi3RzvctvLVMOsSFbij5Vk2ihu16cVZ4ZL7i42lrkJ3JaeVbxhUrQW31x5XrBW qfVL2PHH8ck3HQdxpbkbLlmrBG8d/8RlDsOFe9IzFefKM1KY6GnFJZNu49fPAkFvK9Eavx9jdm4F U7Zt3Lcdn7pvSVC6MNjcf8oFWyRuDrChlTgIbDD4H0i6/M2LWmvcoJXHnTFaCgcYBIRnMBmA9C0A DvD4OML1JZ4AofwykP2fSAx6bfyoQS/oxhHYgVw7jYKmfxIeDFMLib5+mFFZDjMi/nkOY95FXoHR 7kmuWNOK/svaujZqfQ7DL2E5RkzZPwr0XlFbcxI/An/kOUneCfVJwN+POw4V/umaBx5+5V9qhBVe eiilKLbngmkhbT/Ecb2D8BiLThO77QuTotePxILbVM/2kc0GsTC+/bnEgrZyu1j4HVw+6pBtRTOi +Va4FBN2J2JbBvjdqTYts7XT82sb7gHfnJKQSoyjd2FUAlRAX+ShV+7Btmm4SMdfhPHT8O1piRx6 BdrDIaxxGgRrmf412s2MYfwxgjuXFCJ9NL7nAgh6U3HDROMWiWHAlYI9w73wLxB7iLCfIvbQ/sVd SyCRICU88THuG9gep4DYCLP7SIUk2gKBCmZIngAJGA2Uex5+7gKPOaFHp1B3krCX/ejZgDakty5B W6af4lGFkJj/+GO3nqJtnWMTrjCMSZUFiopVonG3a06K4VY7T0kPYjixJOY2t5zC8v/JLJr5eExo RMTDSbaa09bTjhEmV+Z2OBmtAOawCU66Blmd2XsCC1bS7ArPIYMHlMvrMOIaZnkeFQHJ5IgzwXCh bD9wW0ib7QrZbIGwOPYpYdABu4FWAisMzfwW8WiUPY/Ha9v9jEZdJ3R3c+KPDnbfViXezYl0OLh1 A6DHskHUzp4QQTbsNNGW4tpBejRthG1ZmhER9pcYpLkkAJawQ47tU2CH4SKz44OdFVEAhnq3Jky1 giOPIxlGenGXhN4FpX1GoP6S4I4P2N7soXqNTS7wrjZ+sWSDQwgZd3uGwAocuYbh5kXGq9OmhJ/u u6j8KaqBQOQYYe4OH3VF8l9ckfPeWRKGcSuDX4O58yW6PkMKPMy/XZU3rKmtKoIZPfR1icyICDtY uVF65YTwPl5OGL/gqeCoyTARC/y2tMchFauL9HYRYfcg4P9X8HIfVMKHyrShhVdukCMf5HzCB6b2 d8q5QW7uBRaAwcmNv15FWZegbw9XFxwlIuwW5MbiEBKCFemzAl0Ql4ws/zbnbrXexEglHY0Do/M6 CynoJM54SYiW8e4f4idj+REgtzAM/BNF4gAR9s8IhIudUiHcJaR3GlAemJuI/7rR7whDhw6rXYC7 EF6ITbFoOoFvk7hDYfI81oCcgjgJIiExf1DwLJNuCpkqeN9u10fu0eW4kinC/kf8GuzsWcGF6QLz H+3/+zyqSqZOnsDNa2Tdgnkfdhr860SEIHn2jIDpoU5B9JjJfOKHXQiTxtJZgtonElZpcnDwjv0A t9Fu3U2z2nAnzBWYvo6G1hl6d4+Of/9lFwTUxRQE4EeaQgoCGi0c2AvN0QJxM8Tt8EoclKNFgmIq EzSRZKXSqPDohyhhsIIinCnQg0jfTgXg6QwTeuCnGDO/HzniTtUK7laRljnOWmvNUJBQetiraert +F/KqMKEHexpTyYU8+gybTqBXU5WEmwLF/VgrbuEIAUXY5kz7S0Gg9NF1jueXiklGskhoAyN1N5U I8lEnc2ukZoDStTm5kgHqrrEQDQmbD9/F3PQORHPBJ8izU+MfQ9wgJNyFIh+bcvy0gL+hPKVzlBw Bti3q2TTtUjeM5Ax4bAsgJpaMlGkHEeEzYuaiQDIFSHpLwlPduyTKwiJpCJiDu9UWU5u79LeKaar ZO8URlGK/gURqrmYpMLne3AgI4nN9rJAh1sqCgqI/D1Bb4uToJoP9BooJiJySTjVi9xiqCjZUbjh Jqz1Cqrjxp6xL8qzWnSe8cgOKcYzPsgOaYuxQ/DsphDPWDWNI65QzxiIm8EzxitxgGcscBTrE4qM v4VfUe1wKGe5pqhAEhA7K0TC+ynMCIIAPG5kd0UHCMm7X9dUtDdz1cZVKeBaZ/aAE19RUVM//uBE hjLCUGk4qrIFDR3bGZ4SGb/01wo+ZZwA2yjHpU0nEntfLIhEojjZS8wvX0SqIkWkRFR1+LcLWGSi LtAcC0TNY4vtGTvzwut7SKvfRVD+bNXj222dWjOu4/GC3NZZymtTRVZGqBuUReQ1YWQWMonVIWP1 fS6zqeAuWXSBajrR5HSKFeJ3dKnkc0I9UKXU1MmCZJZ4vetwAZly34Zh7dd3VUDIWDqcihIDVJiw Y1Cdn56E2FbrQ9YMX2fwIPIYI16gYUBGit2j1owjxZLZpsmdtK/C/JBFmh+C9NDmMDqkrsmjY0vb HZiuQkwP8gBbuGUo7wyfswyrOLZAtum47eLbXQsVCxGmTJBZQKQMI2prF8cQkFUIhL4U69Xtl2aS t19vpE4UqQdKaWrhptteLb9kpA6ImyFSh1diz2TT7jrcbTmm+wglZ4SPgXicPHECki45CzYO5te4 RPd+yqfBb/kIo4CSfw0RtiR5cZXbpEjlUSfR6EjeJ2hB36yjpgtf5maamm8/l7Ao00Ti5mAatBKz Mo3FRxiTKulgiySuEh52lbthZBVA0NBXVNXOJMtF1BPn/z9Bf0tvO4gSXHdhbJmHcTBhe2KQOAt5 K5UBEThkbQA6LDPhtVu3nQ61qdcua9Zo85XWdy3QgmzCWsPfqhfz2kUjizxagOk6yOXq+/XIWkvq CC1kEb/BBTRElA0Pjq/5QPluMQGKXLzp81J5xUbyEX2G8E5MRkr4GW4aIho80ZmJOix/Y6WhDatb FC9YKs8lFCcLhBcHL6LrIPAm9X/RCnicWxP7nJEP9sZ3IL7zfAKdooBpUJ3Z+3gTzBKcob8JwCHb TlhPkbgh1CFsu75bCd+A09wM8kQZwt6gN45WTpxAnwXowpYJdETXQUAn3TWqCJJsKQF1KM+oLc7j Z1Qbp1148+aKECIF3B4tSfY4ANmX04XSlGeZ/kAmfsT4qAjHs06keweQJeM1aj23mPTmTqAViGkg 63MZHkkrkSFmQveJIw2KJAWY6IFAwIsM4clhauKE/g6Lws5sUSjvYslVARkIUWvyiMPisER0LZyD CHUVDyrHKlzh9nIotQ1Y8xV4Yc1+jIL3l3GxdNbvLcg8wLkvgMubhxL9eYhU+De4z2EY+n1EPKon gZatwBAwZLrtV/9cfAvc3FrXTXfmChSknTTCN3WtdpRiSqjAM0gx0mWSOxiQOQOniBQgt2oA+lLx KKEREQW1yptamVuRN3gF+oJWBzYMR9r3uHGJU9YOhqpxypqnnmMbKvxKnbMg641BXiWlY4M0QwxJ dpQbF46Ni7TgY0eFY6OGWhRrT0y5u2BrqsfS0OG1E9m1Hph5zP2odjhL0n4dYb8FGg1MhP12NxqY Rcg2jqPLM3IQWQfZOPc6xDeNwTkRsu9/IoXwUQFca78juJeJKdr0jnNklk//9uT01Nj2wScacLIJ t5rn+/l/0h+LI6o1Z8GdctsiCOU+W4bVK/dIxMNSkqpT63I7XIa+/6AzQ1s7ySaWQDgJlHTCIDQz daaWbKOOixuQ3icTqHS9LciAF5iDexaL4cWzpGtnKE2I9yCrF85PpX2i/i8VL1agdn7Fq3ZXR9Hn GGcRgO6JtsAKR0zXgWGvrC593A53aE1N1Ki/TMGbpc6pONehGtlbyA+qxlkLTV9UG1RvfBCdmN5P wbqdbswqSaq3mtVcjZLqX2wdvEh4EjFzMRy+nGndNvFvtZXE4IisQkqYk24JGXdOJTr889v7XUOT ASpakR/AlR6t2SwTKUtw7ukAfmJg5H+TaOKwMUEdXcxIz7SjdSV+U9avW7DWDPVfD5EBBMFLsp3E KRkE3dJ4zMtE0S7kdfjjaQXqXETWJ7FkSGbCYOwNYi+Ral5HZVfJBmU3zq7SL5n4s2ATf4CvRyH1 J2bexoTlC4qcD9SfO6Jj7IQrgDoqJc2VsvXH+Pj56H8Di4GgZW5kc3RyZWFtCmVuZG9iago0MiAw IG9iagozMzkzCmVuZG9iago0NiAwIG9iago8PC9MZW5ndGggNDcgMCBSL0ZpbHRlciAvRmxhdGVE ZWNvZGU+PgpzdHJlYW0KeJztXVuT3MQVft9fMXmBmYQV6qvUqcoDYDBQDtcNVMXwsN611+C1vRgb 7PyMPOT3plua7nNa/UkzMFgjKPADszN9Od0695t+WNWVkKs6/IsfLh6fvP1Fs7r68aSuGqNcbbuv v7id//3s6uSHk7ZS4b/uC/754vHq3TO/jFuJulJNI1dnD/x051pR626E8L+YqtWrRrpK2dXZ45O7 69XmVFhnK72+u2kr49rGrR/473RlGtmsv+2+dNL4gd+efXzy/tnJ5yd1gm5/sISagkubyskMrg82 QlTaunb9nYdGVFarZv1yI6pWKLG+vxGmUtLDerk5dZVf1WoPoa2sc1qvH/txjTFCrp/GGWwcTb6m peNkub4Xp7CNrzZCVcq1bbgvXbWtVXJ9Eweeb1TVaCma9TO6uXO0i/9YV7VpXGsUm/ZyuLx23fZh rDWNWD+JW7Hf/+kfjW5lK9ev0vTn262kWj+MU9IV/BiO2NTG9A+90k1tw8mGh+hvz3oI729OG48w ym2f/qn2KGusXIVd2nZ1dnnifzn7PqFF5Q/p4VgltO2RpPj6cEyWdtWIxl9Ajy53N6eycq11Zv0X +jgv9jJwbvvLtK0W2cNPD+JeeecZYvRPVku9fkFYm414zv/4jv+RkPJ6dMh9jq7xqoh4GA4TpTwZ Q5NAZKPU2NR1qxMdeaREePxlgE0I4xpO15i4IrT05XNGJWyjdNdpR77NRZpeUqlUCQrLCaXHII8K gqMCowgZuHmiiPD5zsnZX++uvwpHdY00LtBTB4O0yp+mo0atPF0SZNmDero5VVWttQsX5zFZ1213 cxGhBJtY8Yk1+6HZZxD/LLPvAxduasm3/V9izSu+XjkvDIkrG48S7T6gaDahok3beP0ZJQqtK6sC IZasyDqhg+CslJCB+WxZ0fDr30qo2laE/xVCNeHs3zay8jvKebkSB0tFWpCRTNenSegjsZexGSb5 zku+AOSwXFv6UhPlI0E7wtpocC+8hAg8cTvthla/KYTds3Sw5yVhjzCqF8Q00q+XpHKMcM1+Ljiq nrpdqTLWxfjhp53skE3jWRZRH0eU2VHbukWiNgPLxvvVB6J2et6kVE3Kvgx3Sa4Q4j6nPQn9CJuf IxWUNroE9HWf/RoPO0CQ2dSwLYKYpnLAoMA6md+AgH299o6y/r4ZeLmIeD1Yye7i643XCYUWXhkH T48rQ52WIdc/JaTL8AoaL08HupQN+Nfr64YrNoxdQSZ9SbwT7EKYypjim+FcbV0LzlwZC+smWa/z cAX2hvh2yawTiCNM8VZiikBFRFYPm3vW6U5SSnb3L5HJ9ALAQ1PoUMT1f05gjfD1hx1dSumHya2a cpdf9At2BnTuz5hm9F4AwI81zDhmQ9NSBOh9xo/SuC9IH2UKwfbDB0z7ihqvdp4Y/HGNJayXzYAD aFvJksJmtQcTDOPm4PysB9/L6+E8dP5Pkv1JKPBz+i7T5OLPL4bUxCxWHVxC8RYT1V6Uc4lbQG3x GnlUEBcYE9SMjz7uFgj0VhFur/jHnkjVPpabp02y3HrXxu/TeOOrmvmNN4WNN5lB5X+FtpzxfKE2 0JabW5/xI/SUwntkppLAm4OrsLt4J7GQG2CEQZ33Yak8j6negIuQsGfjSPlOM4bOsbj7Hq6x+0Bn 574iEvF0grQSiWTGmYjfIc/Xf7eoo12mUQDdqfTg8vPGhS+BxvOkmEmnYMMumC6ZoGdcOFOD4tCL rUbjMbF1UaMZ0V5oV8TkH+12FpZecWL7DGZ+3m5KdFjPQZM9y/CWZmUWGFPhcB0QU5H+WXrbwtWe t2OXbHoGbO30HYyf0DL3xjEd2scMwIzCiXYgaidwntCZIwg0YX9/EQVKmLt5CFlHE5w+MK3RqjeI kwCIr+OaVoj50b31N90uEN0ZXAeh+w0yhrPnVcYBn3ElOU1/wNVaD4aRTcs1YSjjHpXP+xWnod5f kItKFBJhyAzjiVckc4OiK4w4Auts/KkXiEoE1kGY9K+kNJ2RSaAGUvs3wSOtNbJ0Gg9dq7he7eeY yj/IP1DUSmRWyBINH0GGz6RHRRoTHIjGm0M9JztuXMujiX+ai3P+c7DILMHu8knyZBT9740MKTnW hMcZR95ibpMyGJUJa+TYLY0WlpKSGEieZnEss9dzlEoCTrwQs5fAm8Hs5XfxLvFCkgSSHnJEizfS M2YPfnqyABFSCdBnzKIbuPMui2Hc7oxiNLfWiugn9x8PVJPefxxt3l1+bBgy3QpBZXje0g2KjxBo /whzPD83mfkqknfyyGTjL2nJZJPAm4Ns2F2k6Ncejl3khfm4V0m1zcMg3DmTM9jgGKgzi++nUo2+ LOn2HhIWD6ASBl0iDCcvgQ53PnDBb8NFTBlPyxd28jAhgI5+q7fHpcuDv7Mo7LWqgEZwdIWdwOIX lVghT1grse0eYGZXGUscxjUyhZzhMsUWS6zLFshmPUHKyXskPN7bWNsg9d7fftOqzG9+Gkjf6VK9 /z2HNnKdnCnzR9XwRXakZeTraNtUzVQ6xnFUdg7WQSp7Mp5JN+cEz1yGLwpdmwmgMoFCstRb8r29 LCXGDZQIacGSM3SM/hrqRqTmAAsCefdZAlx5dedTfkybrRczW5OcZnIufcf2xf4JeOS48XXvqHBy 3MaZmza8dd1OKWtHog0G1qdllA0kDd0mf/wdzoR/ocUw+VBh7trF0NE41OAuN6au93F0aA8PO/lx /Rx6MuB7JKwoA6+/gl0yH+FA49gulQXiROsVeCNRGgjHmyotT7km75NecIZQkuxfqB3zupNSY+YR xKhePuKcueehTPl8mvSw0m8f+BnpaSx7dIu6s9uSyl9NnbBwq8ZJj5qm89L2YdYFWpdazZXetN0p V+5BesGujG2YxQ68eFmWwCsa8Z8ivL8z0gn4OAMJ5Vaxn4kszim9M+1HcUuY7DddhXOBwKF12H7I J4Szj+cwQLWsu5StpVmgHK4/TdBkgg6y64IN8Ps2QZcVZOJnlQMTtBsTrtv//eYRdCtpV6rVlS3S co+jUDFYDlCpNFPRUaJKYvfox97CVNbBQNCAhQcS3Tq/hbAMADFQyQKvz+UIUn1iRuyXOVkVqWQE x7vJ2U/O+t2z492R55LVAfAIAbsp9rtsgtEgEKcRTle6dqsiSXQOsaMaWS0wxYuBdVCiwo/kby+S SXpmhErvaP5Oj/lkYeCgWo7KYHZVbCVXxYhPvYyJkVHBMzClqUexTpmqFvZIWGf9snKBaMfg+lPZ +eP624dqxczKznZQ3DQ/0vKUHek5RdmT4kjaDgPmIA/SLy++5vV8Zf7u3oXoo2XhiabJ3p5qYGJw +R7TOkqP+1EKvqk2JhdAbVPVTc5zZMhQUWK8F8useO+fQll7dyS0J1gOUvKZvGEuVPIaXdGkHzu3 qbHMtc5qQ2BHlawehrzs8UsuUX8o7AmYgU+TWYknFb9+BHL1qYdQmTD0NL+THuvfSKTFEDg7KUED apFhbj2ElqUJ4RKiuM4dUN271WRtHVhXV66iwwHa1bZcJVt8KoGPzB+WxvVRInKmQ/Q36W8G1gL0 39X+y7fSVbILzCuGp2N59Cx4Fxv/STkV2ZhxsXVGWwuAfiayuTCwZ4J+6NYf2K1zP33yirF2ns5c 1wAqXiQxnbuUZDOoWS/4KIojICUR5EoyxHqFPKwvOC1GYcX8l1cEDci23xF4jYFSEiEDHbcXNeBh cZMEhTdgBdhI9DgLQ/cYAGrFgB+cEfLPMWmoybqB7aqPPbJwka2r1FKkCwfmIKUKl15nWj9I/d+3 +jru8s2aqP+T0mtFpMZT7M4Z5CUZvM2Q8ptNDDkVKov0KzuRm0lWeDOp6bhH8AIfF6uaJlXGHR+r GDAHqurAicOaqbFSprJTocc/6XUnmWU3DlNQAsP8RSkKgduQlM4iUt1uLVM6vkcKQpFxsK2jS7Jh DAW1DOHTDANb6ZdqlqE0S2tSsdrxMZAB82F6vCgVBNemTThu9kxFGegzWrQGllLA6guELZk+wtxk XKqOJAYXpZhTRYDjyVGMg0edcZAQRtg+Ur0ljNdhhljs2s4fuQDRbNSCUJgBcxAT5Q+TZZOATLfJ es5dXkyU0kLm551UjUTcllUQUhlG5kpIHDdRDs86REkAMI993xyLHT71tB66PfbzO2l2WZkK8x8i lWmHLapbvdmnmkqbaPWh9n5XwHdcmsLwSG+kTgSwT1UmYLkdMmx7M73Lp+xmhr1g8SMNNh2Zb28l M3C7aNMonvEZZzwrnR0pptebk2k2gZQ9zMxM7C+e9LxQDWIqY4xssPPiAmsmceQD4FE028MFiiW3 Sx6dnKRPdqNj7sUPS5X5CRCJu6RDdHjqDFtjOPbrjWwrD0YL6RPbcYja4sqfIeJ9Whw216IYtLdB y5PrXGxN13i9ogzQXJhJ/9mIXJiFuJttzBKEmXRBjCxEmDFgDnJjQouARBN9QqnxOXOKzcP3y2vL vfRDEYLcIbANDsfWnX2f8TQ2IPKZPRo6j1gIc7a0k6JNVc57pXzOSTF9AiiBOEMOKL+PvG84wL+f UBYBWQcoKL1HBUZAZ3J4o+4ymSzB5sD1iLihhYE5vbO0liTAng2gdrSMpNWAjxx5PmGXHGZEcduH 8Y7JGN0eWSV9Qyq/nBRR17sotTkCuP/klAVCHbAKt5vtDPhlrebvyCNrC8t85+VXCYgF9eAcu5nX w6HYDVDnl/0qtTJFEhqmjFbKDrZjeijoXw1ffDJWJ5JC2bBqAxd3cyNYtQ46NuqmsjXo3T8HtYQ8 wqNTCwGxIGoZu5nXQi38Bg7IqSUcRuHEQQfZ0h66zJXcPIACgpGsq8AktTLRlTuStoRLEgmWaWzb 0bR5N5rk4CGrEfryeYdOLxuVaUecmOSyKLrehC9dXIe12U0Xdo2dmXScXaYmq8vt4/QeT1QTpfiD YZKjv1d8CKwulfBcch0s1qbyU7A2KdukDm/yVFPJoUZUtbO5TauUrIRbhg0RQh7LNiEShHNwHLoN bkAQle9+bxcMWTAnKXMvRcJDbkboHd6dogpfHcEoIfHHkTrd6Sb3+7tseYfN0q86ksNwRcwkUmRK a6DOrteTFQC2DU7+zINUt1Wr7ELIrak9V1k2vSUQ5yA4dh95enUevsh7+KDSyow2sjewxKG/ojST IpEPSaqDRm6g9WzZrPYekovIor7YIL8qtD0fAan5HFiemcyNv0KNvUigGr5tEBjP6MVtu98CVcAT X4dRh+hElPIgjEyTh8llHYDkJ9hemfIHHLn8kbCqcqHbaZNL7br2KyyEjZi2S2ZfMhtJIM7BRth9 MDZSIihoRJK9bqIi2n850MQDN8kk/Vs0ljgAywQ9B8KcsJmHYfZsmTJUNWixTGAW9gPUvfdsJwP1 gL1y+rt3b3T9IqzlX8KX60y2zYYWFeR7zJroWIlwlVE2shLaBOFI5gEMgsYI6MClVd4hc6t8fRHZ SNg/eD7Ge1pRCaOOVMQoQgbvAqsYOVwHvfyXpZN/SD1yKPw8adqjPlGMTl+hkMK0goHabmepCjB7 QJVI5gBBoHaDTIv4CZgdMF7As0R3lxGn7XcV3wCr4pN0Hnoi9B0bKLcOAVm1Nrn1x9NNPRzWqvZI NKU0bCp1dJpicB1UGjxSrDmK7YMGQysuR9NH6t4GGroNsT3rbot9zntj+zTPJ2z8irg/p+KCR0jF dGGGwp6qGAbsyvrqd99FUmCb97t1rHQKyVG2yw/p1S1NmRSFihJGCtZkygoap0fZVK2Tx5JxUi2Q GCNQB0m3vSmRDNthHWXccviuxD63NhaywTok+BZSnPIx/QYW0JiXLZPZd6X/+AmyMne8ZXxStLbT opWl7u4pWVEgO8hYavkUldfWJW83eHfxr5K1cUNc5VbAq7NgyThFWz9EUg3dKuMN88a6hYdsefQd gfqN3hbyUS66ircVIOn64SjRI88ZMBD/PuLopkJI5hVPCMvU52EnQW8Z8iLTkhNw789I1mB4y7ts jhQpdq5r6bA0bGNgHYRv2AkxZGUx3gBxI5M0BXaOpYrnb9QA1aKEnbj+B3LjnZk648Za/sK6Xd7g oR83K7KlI+yoCS2z3WEKJEv7GBGrUZyIJvlCkANlrAF9Rr5dKTB7Wo0UMbF7SJlaVEIcyehqm0X2 AGRgjTSlRj0AiCnzZjQgy5AGgtdglm+fK5Q+7vyPGxWF6gpUaO3zPsdphIvh9h2v695f8SpMnNgI ZvJdv0Wa+ecn/wfp/2egZW5kc3RyZWFtCmVuZG9iago0NyAwIG9iago0Njc0CmVuZG9iago1MyAw IG9iago8PC9MZW5ndGggNTQgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzdXdt6 3LYRvtdTbG/a3bZCiAMBInc5NT04SeMo6ffFyYUsWZIbW3ZkObX9IH3eAiSBGRADLuXVLunaF6a5 BDgE5/DPCfx1VTEuVpX/Gw7Onh999NCsLl8dtadXD7/sD24uj349apj0f9oT+Pjs+erTEzeQ8xWv mDRGrE4ujipmbcMr1V7if6lZo1ZGWH+zk+dHj9Y/bI4Vs0bUdv1kc+yI4LXQcn2z0UybSsn1q/6s NXz91B9XtbFNLdcvNseSVUpZub7eNKxWVcPXq80x50wradYcDWR4YIV+MFMuKh3zjbuXMpXAt/1v e1Lbxp+E+UQyR7gkzFZrtW6mkCLSi6hnxVT9fPL3oy9Ojr51L8LU0lY6vlH8/0kv1k54r9ww1XTv 1a+Itpqp9SP/cmxj7PrCnVOsNsKsf25PWlEnRL4Pv8kxulTNrEjo+ktc+6ewfG82nDVccseCvGZS OFrPN8eWuVndi1l5XrRWKceLnis5V575ws/P3WBT11y40ZIZJbiJQ8T6MVz4Gg4vN1wyaZsGTbny ktA0WoqUz68DceiCz92ddKO4Xcvwa3dKGOMYKR2gLHeP05+72RwLZhtt67gAQq5/i/TAM6ArX21k Y/1rGso3V47tGs9FJ+dH7n4n/z4ku7l/tH+r+MZOj7k36p5kFe/ZMVR2encyhAYaHjk+j+v1Ozj8 eeOmPJQYSu2Yt7Qu+xEteP6/RTkHiXiJ2C6I/otw7jeQusBz58C6QYA+3xwbZiunI4e87tl/yOte OECkrkDiTinJBnFPmN0N184kdTrMq1KNhl+7KzmTdYPnfAai9DZQ9C7+igQtCvPlpq4qWqSUX7x5 REpbObtIRRoWJFKFddmLSKHn/z7yeRSkc4qlb8GUjVowsf4M4NZn/qSbsi5anrMol1Fmr0tsawSr uE4sgaNJMG7kyhNn9JCfD81WDfccPp2v3P21dQbOPROTXHiKevqGp++NyyKJh2AztB6IK67Cm040 HsItE4CS8EgvrCpCSlH53WIuK+MeYmIMfOLPcNLm9gMhn2Cf+tvo2iRGCGxBzweZanaK37pTCY9r x/jaOB4XczO4totn8EjiIRgcrQdi8BegSTP4QTIwBV0A4cAQ5E/8uBHendY1zaVwlKJx4P0teJyB yMSnQBDkGeJvT5+pqqb1U9yc/nckkgT7DwS6G3wLs78g3AssUT+2zrgQgvJNvo9HaEY8GtMOSIwR nsyzZJQwDasqTomtqCzj1iRiK5R1GM6bJsGw5PaW6sHRyR8/7NhEdfjYBEcDCrEJNVtsQkvFxPJC E4isnSITSZghuhhBidwltPDXqJxA9TzDg54BdZc5WCChaHCkBF8/iOKAMOVQIyeYoeQnCSebPJHq A3KTEN6ezewoRSKW5CkVVmY/0oNW4DukZs4oownsDEeR9XDMIGfCBK+SEbtrGNUf/CfKEboMCDvd KlxbIPbjcKO3hD1+CSNuMBTvr7zAUJhCDSkk6iDANQh7+LGDQdrR/WSjlCLFVNeO+9VMYuquUATe PKyYRiKWJKaFldmPmKIV+CSKxTmofSIgR/I8wGJkIgkcjyFqMDxncepTSjucE6aQtpUXhD+AJgKZ yI1ii3XdUS2swPbv7oD7HK9EFFt4MrD9aPYXibZrgfUtGo10wRk23eGepC59mSk+dNntOCx3/DRX oNNpP1bPHekEIhakGUorsxfNgFfgm6gZrjcDn9ZJ+VsKzOYQEhuueBlEOvMBCK9SlhJRQAZRn6Ao WT5jkl8ISoOwqAPQ4N1juIrCDEPg7sUzEeogyKcUBbekpQ8aUPV+z1Bej32ur9aiDec6WcijXQeL JnnZadzTNpns/GkjmLuJOKwXh4nZycA9TXyrqMEJFRve5ZOhpvYMn0BKNCdA11IEFpAhJQ047JUL IQaQSSKv4+PRXOAFGZxFMa3sOT3LkwkKyC6Op7SDtDwlLC0lX1hqKJOMdJBnOOGlRInOvD0iJfuO SEJWSdQM5jknnH862n1NlSCQOuQJBV7i7L1/UStZUhai5l5UFqIsjHvApegKoGUnVQH+JYlnIzci 8UfJZ8KYJiphyOBDM7olp1MwpURUGiYlvPJbSv7R3IhzQb6uQA7HzOU4dgjkoSe9wPdFQfVeRik4 j0WPVB83naoQjv9qGVQFVplEsveaYhGkKV9teMNE3cj1ioiaP8UXBmEHuE+9WbRAx8bpNFkbNIJ8 R+fb9YNumOELUQ9aeMlciH5AxOykIL6Og3+IR5TbnHi5pxR+Ps1BLnlHIPcE8h9QFlTIF8U5z4C9 KHNIgh5AALeJeol3IgU0ffIx8aRUDWhPKhKGrfZgLRNBJA0sqCD8YK2OkJIJgBNl0FJbWvBfR6rR QpLv4RK0ZVBEGBdQC34XYGBaMgoJ84OKfV0tSOwRMTuJPXDda9I0p5WrPiNcYQhxW3AdzhLj2N0K 3AFStsJQGliQHnH0EQiVk6WjBjnihOnRalH8us2SPaW0ARmnuyCQzg2FFEizjb0CUmV18ECzmgfJ z1bYkTtQXrmcd2RIrSl9SARQ8xU2RpRNub9AL8SWS+sMz1KEGhGzk1C/n6RROaBViw6bWgwcg55n LjKLl0YFErCQJKsK+R8rWS1Nkv855s6WaavKdYEHZRhh3HoshWEQMV+5G6tGicQJiTr9VRuD5Erz CSEgNAGou19QvA9BvawUm1AP58UqUPcUjsfTt80142oJ9t49+XLeNCJmJ9XwMn89OWz1rxYVa6So ddi6ggrpW09St6ZROPwp3IxkqUehbDhRIVvsJJHaAqIeIxQ7AKmXSA9SWLZUPlJL1liRcqpVTl0P oKk/XkQ5mJ5ykSwc1/dWDjZamYZLwCa0qonZysGUsY6c5dWDYbruqVUtaYLJtDsyDRBRBMFPs+FZ IBHUEGTvUClaKQ/xG5m9pmJPgJ+J5NcwZ59GsFHWws3bCCsKTjemAVe0hPthFyNQQ7X0ICq+i68O Va72QRFZ+3rWMNEn0QNg0G30oKsf9qM7B8DxRtUED+AfeEiY/Atq8oegsdhGOA+zlIp3SMMqiD+i HMOBxVKbFhEuTiwRXTuJJTr5lirRSGxz75wnXjgB9ZKEc8K0eaqvZQOKBRrufEw16N8R3M9BFUl7 P+/DtIrYLNlFWsX5GrhVKKZclOwFonYSPCJVjNzXEUjqJewl8TMO1Q4bPZNU+4DnCxlmfxswwBNz WDSk77s8kNk73eSZLTxzv17ousdokUZqRcbNCm+c8980q1kqvJQzoWLu2k8gYkEVXqWV2Y/0ohW4 9zZD0kuOwors4hUhbQULSciFokU8QbelRDpM9ybae6qigtQsFPKkWyvTspFeA+Co/kghJq8N09wO XGHj0zit6fevb4n9UTuZfr1I018NTH97jV9u9/8/zBM1k40i2vHnCZohWu4nZkaXoqGezLZY2zR0 XwbZCVIIdHW3wf2iaMyX8WFegF8+jG9t689AHiBZEYSTRFEf/hnABMIV0KV5kjdzousm+uRfxulg 7UgSyWQe9WJWfYmdZe5xgt/6rw03jCuezC0LrdxO5RmZFJ8fOwKZavQCItXSiOXIHNCyk8yBsAyL Bfx1W9oIiCJsFNsAuiIL/BitykcwGEpRvkYMHqUGGpcR922JW1PVHljQSI6+Uyx86AdgeJPLc6ke nNAcqO4mnCrU3vY5Q61jLYqDyybKHbz4NxRtr2NZClnBQ263AydjdxtB7hWxeOX8qHuQd6iUfnrW v5BB8K0LzUz9p1K7aRfoq2O6dnDXxfR+ZvCZE4A5iv1RfHvrPm7DGznmJBNN6CmIbo4tuyuc5tL9 Epl9ij/P7sLKeVwdb60w6sE3jNdzMblqyN1CDurBAxEL8uBLK7MfmUYr8BB7fIHtcHEKtbEIsbkb hZYTd5rqZETDEjrKGJRMiaPa1CipD2MVOrIWcOcrZNfCrwAm4n27ig3R0L2d8dy4xGmvNNM4vKjc PYX4/4rDY89YY797Vmc8nWd5zrjjyKVUrCJadnIMiALPZO+E0MCd77aYdMlRSLpUGhflmWxoA7ON rSj5QLgHaypSj9P0KKSusVoh8TmxkWTaTUM2qe0UesS1322lma4EnbIE8q76bLVbPhGzyX527UBE o2hsHsnF4NwfpRELuuC9AM2Vk4eZMItT1UtMomG6/ol03A0ZTZ5S70kkosfbiJK4Gpo1aTfoVALp KBLFK6X9Akc8hWKHGAHLX1OyOlZm1229MuKUotcPG0GUAntxSsLBxoJDO/pdvKWq676I5AAyIFXV otPIa7ui0wl7yYvGsqqBm31wCYq0HmHpmEgiAg5bmyB0HXvsl6RZMV14DypqHymMa4KuI7eLSHKT eewzCXpkRXmoti8GIuIe2mRp3wUJmd4QhbgTE/+VcT/JxInhyjgUYBcQXRe1XM7WEZiYT0FdQfBM jKauUR59vLRzPwwwy2ayvl3a4Uu8cshNOLheUrwn4xDWTtj4zB+acTOJoTt49p3Txk1msy/K4RdO WMfb2bpzKhHn1VA271t1qYSwndx/amvmu2wqETL05EYVI3tKDLdnItveRlL52EU+39ZbvWUzmrT5 M6veQTsvxrbVy9yHoWrXqa00xk239TFGXAuOwgyJuj9YFL5XfZWODVMY/9EhebS0+xUF2TCrh8Qp v1G8kdig4/3LRsvXEI4lWrmfFSJaiGtp7xggA13kmcsEFa7fEuUKHHaFXfrhDgJpiIqo/psl3gUO fnGbCqS84hWx4ABlJE5QHUFXpqJZY2MDN9mBTfSrj3ds1MyItLT2WBgnKJWkavY+rDQBdexNeH14 l7iAGkqVhHMqSG4qZwmJdOkh8QoQUcIrcvAJioOtkmzGVum+ERJnMl0Nz7K28hsz7YaXotJA1VOl TTvIHqJ3RES1NAHVrkB+44WqYgoXRh2J1DmxDQ6ZW0Zad9t3u0621D8SiKm8Z1D+pYzC50I66/bT mvysHlGz1O/4JR1qre0qq6BCCA/lXYYs4VQZtq0QLMChfRyM2rb1Evr9mxgmz+DBoK4k342Z3EKR LjH9FGfc86orgAsdlqhiha4vJGuXU1qp+k0M0J5HxsRNT2u8JVKycP7rH9a2XzQ89rurWIs2L3lE lSoSRWfUFpiDLOOED821t/lpgwuEDxu/4Er3rY1zmo1IxESzcf8o3v2AqfBvV9VOballlb1OQeDv 3/AyZ8Z5ept1+HWLYQkTv0exUJfHVu4+OujoxLxEJZ3al8zHJwyMqJqJmzCl5iU4heBdoKcGiwXD yWQEGnORcBr1aqftTw3nQEGjZfkltVjuoOL5e+00ePg5L232v59GrZ/Sm2hz/6lfKxJ1TmyeRKy2 08GS7hVwBkLVVdx6b4XFclbAL+TcarujYKlQn1qf/eD8sA73BfLv22psKUoYfg1m2NxIbSswzEb2 9VJBrG9jeQPVmwBwCjQXWghsagoxmLCA+vCAyWmHmcWuo2BWqBRIuC+ctL+WvIntNh4hPYjfbYTt bFC5MFQJf5wazNC2Ar5T9gmLge9U/mBF11e3bcPdzvTCdxV/HxEFnPuYturvReRcwmZtW/E8q7hF GuYUOETEwkTuDoIWNuPAYYqCDaNaAaiG+6ELQmwsQH4zgfwE2pth3eCuPXh072peKziyCIMPO6Ve WOunOEmBUBJ4IRE5lD+h6BZosAfeXFi2MXGXiMUl91LaQm4PLATlfyeZE3BAyDDseIcMJLPB/KCc OYgz2j6dLJUHp/51hrSGkvbelddcCFZJvgSWMrWH5gPTsV+b5YxFvOujUm3ifF6R9l/hI5dlT5KD FgNJzk6NoVP3NSzVWeTdJMR3LROpeAv3eZfFxbZ+VWV6rzfsBAiC/pUHn7zybtQnXQmfsIcHYVrm LPPt0f8Ah2N712VuZHN0cmVhbQplbmRvYmoKNTQgMCBvYmoKNDQwNQplbmRvYmoKNTggMCBvYmoK PDwvTGVuZ3RoIDU5IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic5V1Zk9y2EX7f X7F5I5MsQ1wE4YpTZdmOcjhWLG2sVCQ/rPaUs5clrWT9jTzk96YxQ6AbRHN2VjNLcmO7yhrzAJrE 191fH6B+2q0rIXdr/2/4cXix87undvf07c7i8O7Tx92PN6c7P+20lfL/LA7Q34cXu4/24UYhdkVd KWvl7v7JTl0514paLy7xZ0zV6l0rnZ9s/2LnRfF9uacrZ6VxxXG5B0IIIxtVvCmbqrG1VsXb7qiz onjtf9fGutao4qrcU1WttVPFZdlWRtetKHbLPSGqRitbCHJjRW+syYlmnYu436bRhS5hLt24lk77 X3oQx5PJGOESOrIdEkWQKXsPFSZNx/Gj21qCAD/s/2Xn6/2d7/wKVnCha1v4YY1yddMtbHZ4rWV2 a6yysJVu/SqDIPs/dnKEWQKy6P9vPrNsyLQvihceF661rjiBd6UrY6UtfihhyGlejGoqPfRiPkXX 1MrJ2sqlrwMAqaUAbVPFHyMEXyOKfi5F1QolQBOFqZSE93ZU7rkKJgDo7XqVdE7L4gYPXoZbEtW8 xAt+pMePS1VZEMEWh3GGdzg/znAVhr3k5n9ewkMJLajsUZCj8COO8QFmbVpprbclYGxEs9AN+Nm2 2gkwQeF89xCNATV666drwDJFCaUqDjqxm0S37hfTnTbBH01cRtE4gNKa+N42rhp4Az15GttULZjw jWDVrY5uBAHKm3JPVq5tnCnel0JVClTSDy5VJSUcRCDhPTjkGc5zw0DqtDumR1/Oxqnl60tNAIgt tJ+qUkJ649OZov7hrVjKKIM3lPEt/6aUFcwh7x9HbQUniBBeJbUBxdbFFwuV1MKhOhPI3Iojzx2E IGt+jdddZ/aBQIw1Rid4/iBiDCd5Ry1cZ1YaJXFyvJSFtZ/I1nWricn5UO7ZytXS2ahIYH3eEfN0 GIc6K01dj4ReaZV3Kj30gjlqwVu63T3P6o42dmtrUEh4TQE2D5lBqlkyyGYmDBKA7tE2NoPEaefK IPkXc08Mkr6ObTFIjrgNWFQ0uef08DmOcMBxyb6iZ4SVkk3ubLTjz0vpPVXTUlNM6WZHSsgwlHEG k45m/p/x7N8XA9paqPEJiG4qOSM+mcqzFT55wHnbIYiwTp6NUhCnq/FMINQLjvIL9tETJddewLUW HL4iz/qMWOozEn4FaJ7ERYx8oRFifIApPS+AJfJsBWD/iCyVrJ8MN9d4Sx2OaWbtEWRvKAaBALZa GYq3GM2Mv5hS+nc4o9VMBQrL+TeQSLdaalYjOcZPFmLAXsAwRtoEIImxCKuHjDzxX9RcDBmEVTmO J8tQAMgbHNtrqlrV1owPALgCiMeMAJAKFADwNSri91E7yUF8wU/i6YiP8wHfcMmFnmQ1CVxIliHj GbyTCGc/RHl4b0HyWoRngDTATGgQiS7jig2dPUhFOz6CACedxo4QHpq2ieh4yPGhnGV8KGcSHxoL Gjh6eBhnnWt0yL6W7ZvhRXBIXsa2YsND6obDS+USb2frhnLh7DGSqp9pLjlIOJTJI+6emPpoXtHi kqLCo1K0lXCtI6LT/B0pKpyTw5ghJJO+Zi+gtx31eKWXQHaP6MY39Q1IPie22BMokIUv0TNcZX47 AQNB4lVEzvkAXBDAiHQ6bIDbMSX+YXhEK+fw4zD/oUFenrJGJUH0vUf9w0JJRAspjR0PATb+5hIh p/G9LCevzQQcw9QzA14qUADeXyPXIybpY+8F9kKGE8by8HEMBpQcchgYkGFO87OE/fLFtjhxHmgR K0fLHBFqJMzF6l7iH8CjKNOOnx+DEYH6TVyhQyGmLNFRKbZVo7smECaWdXkscX0h/D7nDOdd9CNM zVn9pQs3ggh2QGx3fICPjJ/lxCan/xSzvcdcoueKe2Wdhhgxge+WlsX9/YRp8MD1Aw/T/G9BAqIR wrT+9CRMo6O7EgI6j56+mgvwSro2sBK9Yu0oAKtVNbldDTJMalZRCNaqcpQxwf1AZYwENEgk+JzS aR4jEWPXa6DSC2uEsRTyg2gxw6FXTEaNOoQVRrSXDF0yhm+jDU16tQK1iAPSQOmg1Fp36Bcp+nXV CJWjf/wEBjw5OLecr0ZI/gp/jkNYexIFwvostb1hTZHznzFgpaDKQ5mhYJuJ75EEEAKf3I9oJOCC AFy25tbiXDLQ2WCQtEz0hkiCIi1qEX0J8SwBOY75EafBhsJ43csCl52+ebyfYSlJsqRftpQqkZjT tmXpRLaS5o2jlB54MDEqzovic+92wecZG2teunhZUhI0LnXR1sGjzij66wm07SbJQy6AOybJh8xC J2pGmi3DjIm5xiI4W9fitArtAZsOId2Yt+A2mTMgmA1YuQYLLj1B1Gt/QRKlpE4MfRebzcMlW9U1 KFW6Ej067wPet50mtZVTJmhSkrSbqsSrG1vZOXUY9wTaivYcJaFch9VLCksCAzita0enOaSBp4D3 Y6Xg6vN0oKF+dE+nKHgjBKih5uD7JFKg1amc88TgR8nIFUdshngCGmTgj3ZWNCiVKGDv27hyZDFj ef4uRjrPoxEUMhQoy6h9WiPS75c+W4iGNK8gCtkMxR+Cn3fFy5dLJuakb13LGCHYv8xZLOB3wxhN fHKS7YAJpIJhtYs9/hDL/ysabBUG+ioqAZp9PEZ8CtUmmmJkG7Gjjj0LjXk2ac9Z2G4Fb8C4YLtJ AveYyxjhyx1eS6kmzJnrWbV1aKanYwOLr4unTLbvhlEmFvqkrQvdxXW/m8LD6HNULMHoXd4WwqZK eTDeaX9S2t6xp+rKgNUOnfl0lZdXZNEx/Pebnf1fP+yEXD3LhFw91DcxWu6rU/kaImNG67lMmLcE TpqexFvWfa29PFSs9YsLubJhZxcNnr8iSaxPKKrRHBM6YJ9iMI2jNiHJxR3QiB8bDtjWsix4WpZl c998zdHMpHeU88HESefFbjLjQV6zPuJycujp8+He32LcTrnz8e5D6lIXLle6qlZ6Dhk7BaqimChp Oqrak8iAv27AZCO9u2aWkd0ysVqrrhn9IGHF+jW7DavbxCczHTivUPIA1Kd+PjhEFYM60qOVUdQd NCNe+A2TYDjN2F9KN6OdojrLqje573lpgIuapD8qsFRw/M4GljpQUJxAf1rNbWPm1WdE30Pk+nNk v2znQxLCREPF9aexSWmiT7yNXFUNZ+rVB2WW5aP9R0wSe6X1H6i05MrympLOXjneD/Q+a7CjhZrj 3Hmg1Czq460T1saVlbPag5/KEyz/RgkyBNYQTWH2Jy1xyNCTtfMSj8lOmhAwIAX8DG+mlvKLiNDf RmNPEPg4nu5chjKS3PMZQTViPTSHODs+upral4VnBK9UoK3ga9Nk6fobaeIlKC9foOaqiARxSCQI jM64HEDCAKT/nlKyKTQJ2Lny4JeRqLCFkkjAkpII4zmmyyUp3fo/ZgThVKCtQDhi52ZF7OaBN7Cj hzBupoOd8ef32v8xUYu4gvVxs/KlqUBbNnbv8IM1t+9WPyQWhbObWbsNZzVjVeIT9x8+wuwf205A bdg6Gxhyi3XO8EI0tv3dCySTKRalmfWSmdVs8plmk3wmsw/M3EM+k17kbs9nDn5pbuR8pqoFuzt5 4nwmFYuWy7g9RPlun/iZC46fbJhDweI2424+5k7pNLc5F95otKpuUrEmi81k69bfoT4iCKhcSPAI W+O2fSQQYNc632pBmzQZCsIh4t8DUV3WH6qjEW5B39XCBvvWjF+UDRaztMGDNaWRE3vSeKTNKTHe kygwuqkbrPlCEm7XC/To1UBJKc8qao4i3UE9fc3t4atnPRv1pM+qZ0KRfMdhvWbJ956Vc7H5oSeP bEEOrX/ZNGkCVNRNJVcZ7bFRkcoTUIHZYSziY5UmSSPHsJfr5CSLcdDP2qVbDz7lw6ELANpWtBN7 YuH06kUd3RP3JAqeGJeQ2X7JV5nfr5l5GSquhSFP2NHJBVxhY90CW/Z56kWGgxHo6aKJ2PjtzUwb xG0dYiQdzVbMmK3cNGlDtm+QHLTIMzErPo+YVsVJQodmhMi1WEU96KrUAE2vA0uuwpf7mBbpbvm0 kKtMuL8S6z2XMc4a2BRD2V7ocmWrnCjS6u8gEDHY3l+SdzvKcZ18E4LpB1pqSi1tKEMjTkwAD7Ca 4J/aOiSsFweXdxuX8pIxAnUBRn1OJYJUnmCbNvqQHKkQ9OMArmebSZQq+oUayvjT3SEPPimq/j+S omt9PHlkbid0w+7nmYrb9eS5J8Y/yPM7XeIVFgnmDYnOBybjmnmiy2f3tU1XkBVKsztrprO2qUDB 3OIC9DfieQrGdTuxGww5u8xuObl9T+Ngl1QPWglOeJudZmlGXHyp5rTyRJq55OLWLuWvRAPuCsNP jr5mLUZCJxHJi43qTYPRzS3tqaRnjjQgMiHCEe0+WfSqm4Qd43fKB/6WiTOG8ONGceysJbFITtP7 n7CjWhJ6VaWKvaoZyZG+D8maB7iHZSN6M5+EZvpI86A3rV17C8sY7CYVJ5Cbqe3b3RNavU/HzyGf Zc3MdlykAgVfhsXdgewv+5V3hs5gvvIqfP6OTXyxqWX+85Vk9AGc0S+55B8AesMbcuopwhaMqeuQ jaJ/3d0M0JIKlOc+LzMf3SStYXl+Tdmh6IePbga+lHP732BF6hS37X8Y2PvM1Tm+2/kfrjeaXmVu ZHN0cmVhbQplbmRvYmoKNTkgMCBvYmoKMzQ4NgplbmRvYmoKNjMgMCBvYmoKPDwvTGVuZ3RoIDY0 IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7Vzbkty2EX2fr5jKizmxByFuJPBo W4rtRK6ylSknVbIf9r7SrnbXklby+kP8vQE4A3SDaHBmlWhIrSw9iOKQYBPoPn36Av46rxkX89r/ DQdHL2d/e9rOz17PatZqaeumO/30m/T/r85mv84Mk/5PdwIfH72cf7Vyw9g5r5lsWzFfnbrbrTW8 Vt0V3P2imVHzVlgmm/nq5exZNV8seWMbpqpnC8O0Na2tTt05xXQr2uqXhRv/l9U/Zo9Xsx9ndRRr d3m4HBJINkyKvkDaPb3Rtvr3greMK149XyxrVuvWGi2r48VScCa1UdXJgmt3vxPZ3aWYMY0U1Sv3 O7Omsdr9LlmrBG+rqwVnhkvu7t4cwG/ohpWfA1UbXh3gn8NsnC24ZNIag+5+g2XbJsYpnIQHHOGx OGeNErK6DnKS48S3mC8a1ta1m4uDgXfdiKUsh3FvFkvL3Ko0KrxCo9s41d3xS3dt6w6lPxsEe+2e 2DS2FWj2w4OUe5JXlqWsmZatnfu7jJmvjhNNW1/kVINj1eDCm8PqyWz112fVT15i9xCnBSdeIs61 aKSbDPfwtlZejPVZ2/bU43qxlKxWyko3EWE15xv5ZVtxdCPDN9boh50uKh3LhXuWaqyBx+rqD3wS xhPJGOESPFq7iyhNelF4Vzy67kZva7GZ/mDQrLFceYBhkgun2hvzzk7/v8CnsZIR2BOV/POFYO6B 4sNDj2Huh1QcYZwYSlV/cUIoa91kfenMqjGK2+owWE40odvMhNYrA3d782ysVQKb20G0mzM4mUAZ d3PSCo6uPIYrEYKhX9eQKMdeXMP9P9NZ3VSesLw/xUV9DsbyesENE7qxEYbdSUBVWEp0T4TaF3j9 TxC0hyVCY/bhKizsFQb19aM6sG25A1akazcA4X2NfBV9OHoeckoHGWQX1Gn9rLG1qbHT0qZUnqBN j6I2/SceoTl/O8g4YIV7arG56QrWHdQCGMM5DL5snXBSY6W7CL9SKgtkBgl7TGAbkhazg6t4/1nO RhBhiA8E5oAJB1jYJTp7CfcfZDYkZCJIakKdTHZszdUts1Pycqk8QXOf+hVxSxOoJTe6WkYI+Vc3 3W3tlqZAd28JMkmB1xFFpgFvCJqOVPIQVHJzgLDtzXaj8ahudEp79hFlNaphYkJBVipPiLG+w8sd ySI+RkvxddSXONXrGEFzAd4Igc0l7RYRoqDREwAElUGruotynOVe9DQBsAAhvxHB3EAgI/IoJowf 5XnokU09mcgGv4YkI5u9mLi7QhEEZTwbTwUKRg52+wNg+pOF8AmoJrHBq4xSJkQyh/aEKwdAR/aN ficIJraid5E8nQ8yJjrHcltCCZ/0AI4BHAS4Ck61hOU6RmCGGA8RwyGmQiVjcrKOaQ4eHRDvf2c8 +1B+p+JMTymL2BMoKD/2ZQUeUwrOhrkymZkDy7juLXigTHTOoMT+NwdfwGOpMAA/K7wJlUHE6h+t 4xg5wqB4hezg+aBxDSYek9kKj0E6Qv5+ngLF2rheUUlULOUJCtrRW3oFFLVjg1I7tem8+S0xR1To gtc/iEElQpG95tx4/xZqnIRmShaaChQs9HsnkTJKIJtBHuKWtKNsjb1pRPUEBL0iEmfbByKV8YBK v1OR8/11KmrpIx/G21pY7589xxNCBE9t3EQ5BsjdrwIJk4ydqtrWPPzHyGDr+16Ej+1kGGwu1RgM Vmt3fkpRak+g4VIgMm4RzKomDgi2+TUo8Q9oJUhSnHPLBB9i4o32/WHBUR6wwIPXfgUNCCEqciwn FM3enZqeYs6c557zjPUg9www2CVZmqb6uQKF+aYj9KJtaQe5Rn1hBEb9PPt4ufbb0s2Jw6SN3wbQ /hYAc/3isk6ICBqHIgiPI8j+Fu75ebF5Bc33b47SOnyckjmmAgVz7CcO/VRCJgipCJH8ppzn4+gN IJn+HSjqI5RXDwZMmyBZMSty+n7WGtkGigV7ua5GS5qMwiuCaycL55irovvvhqrobbNzFV2oh+Cp zSQ9NV1F3ws01JJNChkSed4rnfy6U0+uGux2CNYsURql124T0OANEfcml+Iyk7tSi9Zg53y3NcAn QlYAmyM6r3BNFtG2FVr3oU0u1nBzMCF16gkU9AmQn9aLt0QSP8kVBgVBBIlWkEQvUXaTUqE0v0nF kpSTK1HX90yrRheCMg1pLvA927Aegvdo9+899MfTg6W07vRhKuXpnjyhPA29V1TplyhB5onzfkb3 CGV7ttSpCXZ5QqWVkIUThWwAjUMUEw6kn3wWaGTtoEpao6mGyhtudi9nRRhGPXubg8MsNMwXJGjI OeE84sEFAfVEl3HBUQx1iG3i7X5Tw9jqIQneMJp6IGHurx50YPiCKlkWGN5zAo8OCYUAjKKGPMfZ mwxCEil/78XbaTTqLhWSCWE6VHRkwAeeNyQLjeJSFGpEYuqWSUwpzukJlAc6yBWAMVM1ZTIEKOgV Uh2oi5cIZI5y7xZEIyL4uROcIuwUZheZUC6j2JPjvVfU/yyo8r+eZ8KinOBFjpvkIO9iavG8ZyX9 7sFsi4i/fRN4NvX22l3+ejfrhKQQTNZ++07HqhPDIvSBiAyoOlHgGpHBCy2YkYX+o4dL35tJ0nc+ EfoujZrSFopUnI+NvIeBaMoGRIDcrZX1bwyUSHC/xWClGHdYD5SKySuTJHPeQY2AEddD6DaKAt7n ktwQ73G9Rkl3ddvEdgsKD0HiDSprDuinPLEx90G/B1Kn1pMBQPyuzWjZb6kMuRVkNFrYE4hqNisA Ujg53PUOuJYTpuHeTLIUjOMPot9l11DkDECyV/Wutf6z6aRwrD4iYx6BzTgfMaGMQipOYDNfxZwC KhpR9R8qGxQDogN6k1a0uDPSkfbZAhX5kXv86FFybkLsJn+zLpJZQXpqzBIKjASyE+ilz3KO1UeP PbqUmjMqlTWeS0kF2n+moZeiJPqaPniOIt/SClqH+Cio5zbe/TxeeZXY2UhN88LYaSldT6CgdP+M i4P0AFIx+V54sjhKwdMpAUqgmrfJsnc6h/bDFzJY9wnSsgCUitBIpQFwLCSYPbfgqt21e+eTo0F4 n1Z87Og0aCo1WaEl2aw/Fg/qyZMXV2KkkHTbx0ABfdki2OKTqHfXORYbv0DIE4W1SnpgSeez7SsZ 5Edzyp9yoDI1hQQN0dIbvfDo+qQ42dk9mj6l8uRfWsGhc6FYSsbR1/mykpsOyeYa6lMthwRXLm0X G9ycfI/Pt+ROhtoyglRzqMjZ7j8/I4Sd1j6CnkCB13wbeQ2VRMGsJyzOHSwO5iRBWXDXcz+cQuhy mgHIbnvifT99OA1LnmgjujE0MrSGm2oJ57+M5bLLyGxiDNdwnn70IVohWVtDK1kYAu/VyFTYd9f3 3jNB2tygPvPDmbpOCoVgJ1AKpLstL8bj+txMq5m/J1CwCajUxFUAraY9JPFVK/j0UKLgb3s6tD5b 6LjB39cjos9CwjJPSZLJFaLUs8tHbgii8oE+c1OowVCdQFRVeiB1dISSzok73NRd1qUa4y7elGrc yKsXvv7igkMtP80NCHySWdt6tBIMd4xtSmiWyrP/bBldZU62/gx/5o2iEztsps/ybRk+l3Jt3klS nThDD93WSlMAS4BIvLuy/MWE3j76q4x5dw/AbKhAJE4jmFlim3+iE6Jhlsvkq6uDcKv2b3JtPa1d Gj2BPhirfpcPiAz2IicilH0lJOMuv4em52T8hr7igrqGqRw0QM3Wpgo680g0dSTqvXv2tP+djz/L s1N39PkOlvHzklyqSe0V6ckT8kh/j4uBHU5h4yHVDVFOOU0jn8eFnNAiIGHCCuyl9YXseME9hFkd fofN3yHtF78rf5eEekSoSxBG1FNMliyHm/l8HlLXDgZLfIl0DIi5pLNPdAAMzj48HojbBU7h4xpg QoaW0q++0J9ah/IIn0JUtNPAo0+lp8e05CaOseAqFScAFhkqJmpW3EFOR4RbNiMXP/WcUVfCuAJX W2dmutn6cfZfAZ1WpWVuZHN0cmVhbQplbmRvYmoKNjQgMCBvYmoKMzAwMAplbmRvYmoKNCAwIG9i ago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMg MCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTggMCBSCi9G b250IDE5IDAgUgo+PgovQ29udGVudHMgNSAwIFIKPj4KZW5kb2JqCjIwIDAgb2JqCjw8L1R5cGUv UGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyMyAwIFIKL0ZvbnQgMjQgMCBS Cj4+Ci9Db250ZW50cyAyMSAwIFIKPj4KZW5kb2JqCjI1IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRp YUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1By b2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyOCAwIFIKL0ZvbnQgMjkgMCBSCj4+Ci9Db250 ZW50cyAyNiAwIFIKPj4KZW5kb2JqCjMwIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAw IDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE RiAvVGV4dF0KL0V4dEdTdGF0ZSAzMyAwIFIKL0ZvbnQgMzQgMCBSCj4+Ci9Db250ZW50cyAzMSAw IFIKPj4KZW5kb2JqCjM1IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJd Ci9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0V4dEdTdGF0ZSAzOCAwIFIKL0ZvbnQgMzkgMCBSCj4+Ci9Db250ZW50cyAzNiAwIFIKPj4KZW5k b2JqCjQwIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUg MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSA0MyAwIFIKL0ZvbnQgNDQgMCBSCj4+Ci9Db250ZW50cyA0MSAwIFIKPj4KZW5kb2JqCjQ1IDAg b2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQg MyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA1MCAwIFIK L0ZvbnQgNTEgMCBSCj4+Ci9Db250ZW50cyA0NiAwIFIKPj4KZW5kb2JqCjUyIDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA1NSAwIFIKL0ZvbnQgNTYg MCBSCj4+Ci9Db250ZW50cyA1MyAwIFIKPj4KZW5kb2JqCjU3IDAgb2JqCjw8L1R5cGUvUGFnZS9N ZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8 L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA2MCAwIFIKL0ZvbnQgNjEgMCBSCj4+Ci9D b250ZW50cyA1OCAwIFIKPj4KZW5kb2JqCjYyIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBb MCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRb L1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA2NSAwIFIKL0ZvbnQgNjYgMCBSCj4+Ci9Db250ZW50cyA2 MyAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNCAwIFIKMjAg MCBSCjI1IDAgUgozMCAwIFIKMzUgMCBSCjQwIDAgUgo0NSAwIFIKNTIgMCBSCjU3IDAgUgo2MiAw IFIKXSAvQ291bnQgMTAKL1JvdGF0ZSAwPj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlwZSAvQ2F0YWxv ZyAvUGFnZXMgMyAwIFIKDQovT3BlbkFjdGlvbiA4MiAwIFINCj4+CmVuZG9iago3IDAgb2JqCjw8 L1R5cGUvRXh0R1N0YXRlCi9PUE0gMT4+ZW5kb2JqCjE4IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5k b2JqCjE5IDAgb2JqCjw8L1IxMwoxMyAwIFIvUjE1CjE1IDAgUi9SMTcKMTcgMCBSL1I5CjkgMCBS L1IxMQoxMSAwIFI+PgplbmRvYmoKMjMgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMjQgMCBv YmoKPDwvUjEzCjEzIDAgUi9SOQo5IDAgUi9SMTEKMTEgMCBSPj4KZW5kb2JqCjI4IDAgb2JqCjw8 L1I3CjcgMCBSPj4KZW5kb2JqCjI5IDAgb2JqCjw8L1IxMwoxMyAwIFIvUjE3CjE3IDAgUi9SOQo5 IDAgUi9SMTEKMTEgMCBSPj4KZW5kb2JqCjMzIDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjM0 IDAgb2JqCjw8L1IxMwoxMyAwIFIvUjkKOSAwIFIvUjExCjExIDAgUj4+CmVuZG9iagozOCAwIG9i ago8PC9SNwo3IDAgUj4+CmVuZG9iagozOSAwIG9iago8PC9SMTMKMTMgMCBSL1I5CjkgMCBSL1Ix MQoxMSAwIFI+PgplbmRvYmoKNDMgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNDQgMCBvYmoK PDwvUjEzCjEzIDAgUi9SOQo5IDAgUi9SMTEKMTEgMCBSPj4KZW5kb2JqCjUwIDAgb2JqCjw8L1I3 CjcgMCBSPj4KZW5kb2JqCjUxIDAgb2JqCjw8L1I0OQo0OSAwIFIvUjEzCjEzIDAgUi9SOQo5IDAg Ui9SMTEKMTEgMCBSPj4KZW5kb2JqCjU1IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjU2IDAg b2JqCjw8L1IxMwoxMyAwIFIvUjkKOSAwIFIvUjExCjExIDAgUj4+CmVuZG9iago2MCAwIG9iago8 PC9SNwo3IDAgUj4+CmVuZG9iago2MSAwIG9iago8PC9SMTMKMTMgMCBSL1I5CjkgMCBSL1IxMQox MSAwIFI+PgplbmRvYmoKNjUgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNjYgMCBvYmoKPDwv UjEzCjEzIDAgUi9SOQo5IDAgUi9SMTEKMTEgMCBSPj4KZW5kb2JqCjY3IDAgb2JqCjw8L1N1YnR5 cGUvVHlwZTFDL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjggMCBSPj5zdHJlYW0KeJxjZGBh YmBkZORwzi8tykwtArHVfkgz/pBh+iHLLMvgYJLH28PD2M3D3M3DsuB7k9D3MsHvxfzfCwQYmBkZ K3pnOecXVBZlpmeUKGiEBoVramvrIEQMLS0tFZIqYTIKLqnFmel5CmpARllqTn5BbmpeibWCM1B1 Tk5mskJ6TmVBRrFCYkpKagpIW1hiTmq2gltmTmZBQX6ZgoazpoKRgYGhLpAw8svMTSotVvDNz8tX 8FEISk0vzUksQhFkYGBgVABiBiZGRhb2H2/4gKh8/g/T+d+F5s+fz7aNawv3Nh6eLTy8DAwAfmpQ YwplbmRzdHJlYW0KZW5kb2JqCjY4IDAgb2JqCjIzNQplbmRvYmoKNjkgMCBvYmoKPDwvU3VidHlw ZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA3MCAwIFI+PnN0cmVhbQp4nJV5B1hT 2drujiHZexx1RmLGBDVhnKIzdkdHsBfsqHQpIqKGHkInCakkoS1qQigBQuhVijRRsGN3nLGi44w6 vTjFOTOzNmdx7n9X8D/n3HvPOc9z/+dJILD3Wnvv73vXW1YYhMMkgsFgTPGJFIsSF3lJxKGx9r8X 0rMY9OxJ9BzmVhT7V5cxN9Ycwr2KORVMYYIpDrbZb6U50mem0zNeg8OvE0wGo/v6Z1skcbKEyPCI JOf5vl7731uwYOE//7PM1dXV+bDs70ec3USJkeGxzu/iDymiGEmcWBSbtMZ5Cz47JibyiHN4jCwu ItE59OhR0VH7ML/QGFG087bImMi4OEmK8/wt7zkvX7p02SL8Y/ka573JYlGCZKFzZGxYZGxkksw5 NPao8z6xKDzUWRx6VGSfwE0cmZQgc16xNDL2H6P3RooPJyc6Tzyy816Jq7O7s5coPDkmNOFfjxAE 4eu+SRZ7xH/PZrnkaMDeLXGiwH1u8WEeWxPCPbclRnhtT4r03pEc5bMzJdp3V2pMqN9uqfjwfuP8 995f4LzwzUVzFy9Zuuzd5ab1H6xYWfzhgVUuJa4hq9fOW0cQi4i5RCCxj3AjXInFxFtEEOFBbCVW E0uItwlPYhuxhlhKvEN4EduJZcS7hDexg1hOzCN8iJ3EB8R8wpfYRawg3iP8iN3ESuJ9Yj/hTnxI LCD8iT3EZmIVsZAIIPYSWwgXgiJeISYTrxJTCAYxlZhETCOYxGvE68R0wpEgCQ4RSQiJGQSXeINI JWYS6wgewSckhBOxkZhFzCEiCAHhh5FCOOCbPcVYwzg2iTWpiTmDeZL5N4edDpdYq1kt7LnsWpJB 7iYvU5uooVfeeCVv8uzJaa8GvPrTlANT/pgaPfXPaWDa568te+3j17e93jN99vTI6fWOTEcLZzLH i/PNjLdmXODO4ra+seKNr2ZunHl95jhvHU/FP8jX8TP4A3zaiXLa5nTQKdnp/qzZs0ZnL55tnn18 zuo5kjnfCvYIhgT3hAyhXmhyZjrPcN7pfNQ53dkG86fREFilx+lfrY4/v5jJiaM/gZu5cpEySSGP OOojcwHUDvZmVVGHkBaT4HZ5+aNCyoo6pOQ9Q5kSbKXGPUhOF9iqVGzOoKQkHt7BPgU3s6aNhQEr DOil36xmjPlZuQfzteaIeyiPvsFLZaOj4+rd6F11WlA2XwoDrWRQallTaX55YZlwEL7CghZ274LS OGM8UPJBglznl0NJoYkcV0EzF5KwCVKoiTWNzkKxL+hTFgYtof24aJaC3VaRnpaZY8jSC99HzYiE RYbyzDJQwgdVFmN/HmVBh5VkQ2alxiSHbJTDy9dZxE0BFeFAwQeKJHe5WBmfLFUCA0jP0xZKjfIC OaCSUlMTo9oS+j46dQG+fU4IF9MLy9pKzHX5fHx9YKGdzjM+fQLdnjAr6LnconxzbgmgmooVgUKU SwIvjdI/k1LACAvpX6AoBZ0UPEaeOlFT2g6oobqYnUIkIoG7Sh5gP+mohQwsVJeCIQrKyO9DLmwK jpHv3i54ROrzAmWRGp80fEUP7R2a1cyoH2XSc+FSbtDW8EQvQC3d/Skkfzt/+3FnmSbMLCxKNkmq ZDbAb6ix1l7YenJVoH9q+GFhQIhkO1hLoTceLYbMEz0VrZ2CxjprY8slaqJVUtvYJKsjxzbmPvY+ F6VL2eeyK/QgCSg0sthwxEICXuilvU8T+0ENH1RbTO25Tbk8KzovJW9kVSl+QkLIQCt4aBnyXf5m RqZ/Jm6r0kp6FshMoBZYLPVdg/BVOJ/3A3JuD6yKxBXnHAKyNG1kDsWxZQJNjtre4mEr6VekMB8a QT6wkQffhbtuPKwuvV7An/bXqcA65mBlQMYAXfWCOfYh/Ql3PIAELmrVWgw72G4lNxcqy8FtivbA IC0ru1eEQRpEovjxPJRG57FQoJT9WUaZGmymxt8nwdtKqYsBj1NbyfUF8lrwK0XPI2HB+ElWOXva 2BJcji7Y1wNLu6RWR8h6ATNerIbkTE5HJS6OlHySUaoBm+zIB5tUKpcsO+5F8Av2Q3Db1nWss636 BDgFBmQ9Mc3ixrjSXRVnymzmOhvF6aivsXT1OkGH5SNok8AVfcV9DgYzOhUUR3QxsfGIuxPwTTl6 JCladli3E1CByuI2Iex1wHDgfGgzFlsEA2xIXglavs4vZJEQgwG00E4tDPpDOIsrK9AGGNJUcr5S HpnuDygkYMMa+j2WBf1CZqHJrCp28V2L5TKgoICNrOPvsRT0VBIjWNtEL29iNH8Ny79mwnz6EBe9 sXQBEqBZ370LHaHjj39AAZy55Ac0Q6iScJ9cWoDmINbB7RuPhtX1pAglZ9I+wRX/4eTV2wL7XGdo pyZG4zOY+oQJn2u5cN4ZVgUpy8kGWYAK15UMCunrZEZekDxCu1vOTyNNuUXABKiuYu1hIVpKitri So7gOycXY7TNRTPur4CTLnRXnzwm3E1ChgPQ69VajSw1QRsLKBefT+FrkDV078HZoQN+wgkAT8Dj FsaGtx3AEin7TE6lDiQCbYY6XYHeQik8NB8maCoMlROMUF7cllcAzKAkFwOlXUqeyi5X/oLehDOR Dw9tJsEKrXZpJkbIJSu5PE9ZCh5Q0I+E82HKlS8bak5jSI6FaWxa+1Ud7aD8YGAm5wRNa7h0LQku m7usZeXm8oLuAjy5Wkp2Z5VnWtKrlcXhYA+FvibHubSUhTZI2f2gXNdzgBrfQ3Kk/w6Us0k8614M SwxK5QDtYoOuPQzMf8wxAnNeOkxhpbANKWnqVJAOFPmKosCKANMB4ApcYvb4bN0jWgzQJLC4ZeVp r8u7vhX9DCAL/Dx45TElq9rktlPsAvjuwLv6ULfPUMzXADIpuPM7+Ap85+KZlCM9grZoi8S6i7LT rLhSXgU92+hplx3vP4HJz2ZyFMX0HG5xrhEUA+qYUXtAOB5BcobAfo3Gw0DJSY4CZlSxN+aqSsA1 Ci4jO6LqtH0YfJO/hQ7wHfj61q/e9w5J8A0RjpKGPN+UCJWPnA/f38htudA5eG9oA6IQM3DjlgNe nS0CO+l9DGPbINnJoBdCF27QhkOxu4EXONQce1HWrW/PvkLBK2zdDW1zQpu4M9i2HwSAAzJR5IHD cW7AFa+EOysh+cP9S5DoE6CHcCG35OGxrivgCqiTlK2g7OLXTX/ezaBvQzeu3FubkpqcmBCixLSK zGzajf6DZRmvJVPRBlYDu3jIVF1pq20+UX4TP0w8e3zn+B94JV0h66CbXfCUnfT/6mQcg2x6PWQz 4d/GXLjIG81Gb6PgRW1Lz3kKR9y/OvolHhoAZ0NnGPxz7FOfy0L3j1d1LsArxGEQDMo6o88Fti4C 6FXgodqWuj89QZ6QlBQRcVDmB4LBwaqI1v2DUb/iXoEXTc/7TlLH+4dqzoP/ZvAu+qmdr/7ygmZD xkxO5V8ggwu2qFUbJoQ5BnaxIQV+b7964calrq/Ac/C1+KHP+e0fI0YnmgMoTiWqlbIf6YvTMbW9 aOdyYlpLTL3PbqRFnhI89O1dCRAB0OTDq1Yf8I/1VK8A1BE15qeX8IBeV2jHpsRqx7pnMO3JTM5j OE6v43KeNwaLi4/OQtMXIAdcBMeby78fOd9wakCIMHN6yxRuGZQcaspJn1KdCfRRnMf0DxpyM/qc CxIzVVpdsjRKHQNiQJw5tTq6OeUGuElxnsPJZ+89vdoatUMwDT7DAjyvjfEb5purdgvwGqTYI9bW blu5NrZKUBFfqq0EVK21qrYzpGHfHr+44HhhfIguPGcN5Rr9GfqIDTZr1Fvs2ltmIV3zNSXgPgU/ gtMwMZ7F3qWmBw7b6/nLC5hmr+dzeBAOcBuyK3MawENwztxfd7mt8wq4CfqU3XHNRwZWNC3CVXyM KqXsezqzFmyhxreSYJVOu0H/UqHW5ivKwV2KTnHAlTEaG+Gsqwfeft8jAJGpyty8JMFLI9YF+3vv V8OV3dKXfiyB/h6u40rYAYg4lIjeAlQcOxCEFuqNGfnZJaCSggAuJj8DFlWZC1ULFUls/eFMhUap kkt0BzCIF8MENkfeVFTUKICz2JgAahSVy6h6Nqc/C77FGm/CN/sPH/dPFyenu9gT9YW//MR48IRp pJ245fnFuaWAqi9OCxGifBIE6PW71bh4egu5PV9uARcpmEy29Q83FhVnaEsEFcoSQxmg6iyVTe0p 1ZGhsUlugcJvsQD4JYerPKT8Cf92EV6rh1HHC5scmz6J/RxuHW1snMlBdBTN4x5fT6ZiTks1Jpt4 cea4wnhcXLh405al7o2im1FCqUwmN2RExapSQSpIKVX3plIc5LY/LirMye9hyA/3Hzb0nRF0t1a2 gW5w9UDfpnzELeL55SUUgwpQ3d7RaCrOMebkA2t2WU4R6AI9ltbG9iZLBxgGzRm1yjYK6ceduO36 Tw1DgPqmXRXuueEoYn3g2TxQayzrGxZyYCH8jnupqWOwtUEurhBURZQGg6OUd2xE8L7QGz8K8IpE W6vGev5JB2Oe6AMuYuevGVj9+62yzsrBnns3u7+ZoN1gNBu+jZniJVeEvNfiemm34HhoW+rtxJM+ vFtr4dRD8ANgwWSL1aqIjb4eG+H2g0FpR8y5oLYFALHA/Nh3jgSHHd6f5AOCQEhleJvfyehfAHwF /Nj8U+9g78BJ2whmiQlYX/m/0PU7nQjTuBg2pHqNTLEGA+YdDJimQjtcZv+fcHn+/8IFY9tFM8Et dmyvL8Du6w4FY+E75GNQqShdjS/H19ak2ehl1aoax9NXoesnmJPgLfgRl7MwE85madjZ2en6nJxM wDcAbZ6mEFOQKTm5IH7WWi//Ld5tR54GCUeiOlIrE0EMPyRa4h8ZU1YjFaTUp9eqLlJpbI47WlpG Gs0FeaW4MuXZtQY8gaGpMbNq1uj1kU+GE9v3dQoRcV1SoagHjfye1qbBiy2Ry2sFL537rHOMu0/g Xswdy+CP3L7BlsrjgBquD98qRIEk2K5VeRpeWndfs8EEPqZgEPl76LnVHqGJ+4IF8CKZkR+pTtB5 p/HjdKw0siA3HxQCqt+kOyQcj8YryZDuqcPjYyykZ5G2FI+fsJX0b3ZGefECquyMcmJsnpUryk81 xx5Dh2ER76OyltL2xrYGax84CfpVXfHNFGe0V+TSsGgW5wRqlrLv68wa4Pay9lr1RrtZaMG1L1SV 2WsfQF7Ig+noCguuZI8H0c+4nNGmElMPnD5yaFFASmi4VBAcH2FYkG2XC2UPvFYFmTb4fg+jDSPU +TlzLAD+yUUmGbs/qzSrVGdJL0oChyj0IRm9N24LWjUPsuHe75u+GRgSDAxdbbwFLoAh6fHwFklF XP1eqpatg+GsZLZBKlOmAC1Iy5cZD1qCTQcxog5g9zUPHXqvceMFD+FH234UwUngGYDTO3o6KBhC gkulZSOF1DTYih3klDbGJ7glJkzn72I2N+fkGwT6dEO6XivyORSUlqnRG/QgA2TlZudnU2fROfaq lkOXhrrrzrQLVCUpCXJtMuCHKRqvCeHxX0k8JW70tReMH/CUW+zudokPS4GNZ2leWW4x4NdNUJmC BFu0mm12HdBayJ2FOrO9mJD0hyncuKQkiaQmqam5tqa5Kak2FuvdWZUtpYPeY4MLeh1vP4PKX2dy hmhvLPUp7MwkjUaOHx4nR1NYeZgpGhwCIfKo2IgYWSjYD9YMeEMHjzuiM4frRcWqwhSQSHEUOwKC Ny93Pw+nBQiS2JyhFhTBqmHnWkvLLQCze6ZV363o0fVgz0B+9ei3z3xuIN5t4dyR0AFwjjrf1331 RJ80vEPQGl0eX+GBl+nL1D00ALusjD9fwAsvmFAEERdbV3CnpGTUiO1oq5Qc1Zdo/i5PWvU6+xJu tZIbizCMblPwMLyA9v+7I/Zo9a+zIL+JIDFCcyuV5Y63n8BtT+xWOHGYm8EO1mDXD38kOaNouZx9 NatUCwIopCaBJEOp1MQlx6jFgDoafaxPyDkBH6F3leSprHIFCKZQIbn2lP/druMVjY2C/n6WC1mQ PVzdWXK6nI+bSj98gZMg7qkvHczNyPdIEqk8ZDhRFOZa8iy5ZsCvLZbjZfgaCTZkJWhSDVqlTgkU QGuU22S1yuI0HOtl8uTonqRzcNKlB3Cu0H9sw79rNZZj+qc+BjTiMhrHCO54Fgk+1Ghc7GU5YSVd C5Rldj03nSMhG9TIatEkqo5tgOtZ41fYBrSeVceug4xaK3TA3IvF9GVEIfFkpN2ZbVSpV2W9TL2u +WkTzgAX+G552RN7ahiWkk9fxkxcXXq7hUHH2y2OUMFuy7JogRRos7WZ2vmolPcOLDaUZ5WDYpxq Sowd+ZQF+SvI7myjdvBtOAX18PIM+fp8XZGsSFcEioCxzNIFZ8B7vOZbRcaWfOolG7qWMz7DMj/G 5OKVgUtItZtVQcLxFBLsz8raYpd5lYVMzT2Shy1MBx+6k9AZ7cvPzMvKy8rP4pu0+QaQQaWnG9QC qQLGWtgh+THW0NNoEfTjNTfevnl1sNnEtxSU52FDZrKgQ0r28ZySTKAEunSlUo1T5TQe7UJm5onU sTrPNL5YN2GnB+gxK+MvL+DfBpg0pEu54EVpxWdmXByFlHxoqEgG8yiE49Z2vShNHBe0O2YjcAOB dXEnZW36LnvwuDuB10/teO2Uko8MGK+bKXSDRJseu8L1kHG/49ZxQV1f8SAYtauVspv+L9wgN9yg VnqYC+6WlDy2byP0SMnPXo4dP0IeVKfEKw2mer1A25FWgU1JXHJSXGiveAQSV+7A6fYsOtGtW7hb CvKY3qwHcqAwJGrilqEE3iqYJB8EAJTxQU2J8aQR9ypEQXZllmqqfY1So7RIthQF8ebD8kxzthmY +cBWajpWgM/aoSBrs03aGn84C/3AKxWblEVYb0xlpQ04Uel53yBNeViBoQjwjaCwuKIHx/afeVV9 +YXV+BIveZDx0xOmFfe3iF2SW5qLg3ebWYlzWzwJfJUq9wzcYY2FdC9Qm8F5iv4e92K/XKTdJp/Y dRqheXWOXV9u+xK+9Xgm5zt6702uXKnOUOCFpC8fEEJMF2cymhV1yZ2HrB7Yp40u2hTonlSdWltn q64pyCnMMQqzi3NMwEg1ttX0DDXG+gr2kmjxHrnukIjifJecqoyMcnIfCLky0Gs7c0VQuL8qpRcc ww/f0U2hJTgPxGSkp6gTlZL0FEBFSI71CwuwbPR2wqkD1EQQH5tqZYztsQf/UCn7fFaVBkhAmj5O LUbzxpk8tAB+E3VXVwssfGAtN9uDf0luuT34W6XkEA7+/cthzvggz8KGCfRI+6OSklP5/H9uKrz+ gkkvG5vJLc0xgwLQkl2qw5YzOUns44+2opU8GEr+AypddmCWqv6u0ZqXu1MdVnKdfWvvLgX3kQ22 P+Y+2HjODSTygVKpl+RkAA2Y2P4asZL7c5Xmpc+REubzoBf0uHWjwnSrkG9FFvLlMnWxMGDrGzDY wo4BqRUxA2gG9Od9DqdYG1sq2nL5FrRcQbZkmw14ZanVyQkxGQa1TJWqrOZJ+mTHQBkoLzO25GI4 HVEUky2gQtV64Hv0Ng+xkav4sFYflcVXwHcspERdWFZktJRVCx/B175BzgWGPAMw8IFMnxlldw9W fCdzzjCePYHu9hfTSs/lluWb7HufDcVpQUJUZAeVwjsHgyrBQvrlKUrAcQp2kCDPZDYa62v7KzsA NVATgb2WGCdBjcbLrr5JFtIrV1EJrlKwkGzpb68aBNTFqjgXIQongZdO56nHJ0ksZHyeOE9VBY7z 4WESTj56eb2nf7ynr0B2MbLRF4QAidLFnbpP6vP8pZEaH4U9aGjb6FevMT5+AlO/ZMJFY+u4GXmh ijjdARU/1m7einILgBFQPcXpocLxCjLmadSnkPcCToJvwdc2fD9vr2d4YKrAz+H4yc4zD4fXoWmI GbTbdf/B2nrBtL+6vQTfX13s4AuUsk9nYPDFgRRDvFaCpqNveYgHv88uTK/Jyeen2wxWrOp1teZz dvBVS8mLOeb0Y2vaXXnOqAO9TU/RV2VObE/VlBtP5+NTsqXk6QyLrGsR9B0/ZsfnYnoNXDG+hmVh P4Xl5ibIgCetZ0qKz5rtCvMHvZX7UfuJK+AyNRxx/GBEYlJkdK20s8iYm1skMOYBkIvZt8igi5KE +4YJ8YBTz5jwFLYum4LE8WHBbisi5gH0CkCcrve+fKc3qCH5THRpBW/NNUlH3P3EjzQPwC/g97LP Gq82XW3pvDNivyIMesbsRlu59061NHQN3v6iYyJ0wBlhzz94cfhUfM3+NnUa71P3xoimjXU7SjaA eeAtlUvcXom7OHyLp116oMHKhAbal5srz0sxxKoi+XpZphxoqNQKudVWZbUVZZVllAlUHfpuDCEj acyqSbfJGqP49TGV6ipA2cotNQ2KkhCj8GhRdGl8ha6QN9RkNQ4Yu4vKSkA9VauoSFHIVZJEQYI4 ITlZrc/kNZCgrqippLXIWlABSihbWkVqqkKRqi6QFaUIzFGFMSCOUpEim7QiqjO1Tm3CdkGqSEtN rFaeShd26Vu0VlWJnnc4Ic0QnH5QJ1eDBCq5XFVTUVxorRQ0txcWmozmYmNhRw1+vivABoNuMmDe TSbMg8e5SLITSlDcTRgHJTeRBMbtxDE7H78+R2/+f7UuWhL2snXpfzKgJ3TjnqA5mM5LQDn/jLQp MipVfCCp2LVki6B4X5E97SKCZ1zHFSclxohrklvaamtaWhLrxfYJoN81xnFo5rrDnGuYXRaOPn3y lAnP0Fu4xp6KB8WXQTO/RlqVlCiVJaVZ3qtcJkDz3/gPR/D9w+m/cMUJ8TGx9QnNrQ31za3xDfar tCptY3OqGbAHg2wHG8n+to11i43brmwYc2xg1P0Iy360WysXrg8IlYdFeHqLEDkBQUY7euWkd1fI 6cQRcBr0V3Z2jJzvhhSAUykYuhS+iWYKsuK5T04gFhIhUYjzypUhf8KjMOIEZD4TTnAlA0ZidA/Y 9+B2LGUpydLCkoKCvCpjZQF2N7ZiRbTQ/gVClC4pLV2RrswKtZNVs4Vcm5tmBqco+jmJeU51hp5k g7FtjL5vbz2Cy84yx4Lo9VwUk8IezijXAjE4FOe7+0Pvj6NPhzy71VZf2dRqqy3rAO3Ube/htSu3 b18pMkU3bhSIkt/c6+8GVvEX3vD64/Hl+pv3Bdd2DcWPgOvgYl/LbUUJL/pIsioceIP9rcFXBi7V d7Weaxjk1fVWlw4XUeNOJVzxNW03OEGdaj02OHgsPNA74pBriGDbZu5lxO7wubjV48ARnDCorR7X R6+39n9xYaICD+jaewz4zTMmLYFzuKrCMC9V+kHARzo2XAvdvvru+APwkP/L6tG3fPYnHwkTREcq ouVutgxez0+dbR8D6slFr1XrghevWi5E25AnS007YZR49EPhd1DIhEvsDY06uBfso/w7RCc66mqP tSVZww04z+PAlg1ADqB0hiJTe1PnuS4hTLT+D87Gy6ZJy6ULoZx1kxy3/9pC0i7Iexy/7V/70eOX HeGdR6I7Mzln4SL4OfcSqM2uS6c4tqvJx722Oa3y2rUpLtVYFyYQV8mN9i/xFMqUiP7kT0YfNfSe FJ7sbRgBH4HTaSdjW1NrpKUhVopz9uOT9V3nnB7vvrAkIEQeHS4Qxynik/dZMnm9d0+0XwPUjRMh 7uGK8IQEoVgsUWxPnLDNNvjudXodhvfgKJOOgWncd2jPEDb6aNyTtRseQ2tG4ZoXJNpxnYv0bKiH P07c/KePGHDsEybcSX/Khf7sClCQl2/s/oqXblSkaDNScINEbMRA2pxsXJVsfkZBlqmtR6/qFUAy 7OweMJ9asHfjulS5sUYsiK5NMmNDFKtUJ4hOJt5/cqfx9LBw8ITtIngA7kgHA4ZDBrxq0WQbvlmP lpeNu/hvJKJG2vUfeAYapP+Ds+3ruol2GGQc+w4WfM2kvcY2chFb6ynd7I+I9R6IDZATWNH4QX9A d8i5xKs4077+7AfsVGdsfozIkBS9yF3YCBdgP0vAZQ0UOoyOc58Nb8EiOuno3q0f+H4Pl5w2NVVb hLaK1uIOe6T6b3ZJx1iE0glqQbKxbfYq62z0nXsM2heL8jib7YHmVer6b1WVnQd8KGajwPHvWDfY MGJsLmvinsemNTleeLD1HpR87PNgJucr2E+TXM7oz2c7+m45fbbl8jzEWL1j6S5r7O9LBJyvEOGa HLPd6f1H2yELThm9+dto5BCa+rVA9jb37v46vIqpXQcP7trgP/LF9Zq+kZOCoVE81/KR8MELTiMn eq/d6g/Z5iU56CUSZGQBkJk1oYLBQwyY7xBIZw3ZjR7U9tMOTYyWb6H+OfNSMhc6lJ233hr6y4Mr 8HUAZ1HQdQl8BXHRq8vfRbPQtDurIXG+r6L3rOAwWoWYzmhhPAUvwTEuSM1M16RLEsMwt1Abgu7D Vy9WXLY1CCur60uaAfXFiZVo7cQO/vRhhv0nd3g8K8CeFjSQCXMhkwFn0yH/SusIOfwr1dNX6HYt 9w457gK9afxm4Y+FSM7aiefb8et/VhU8EE65CZ1uMuhW+g3ueO5OOpeNnBxefpiWWk37VUOfanbL 5KevtpimTHlaNWUqQfxvxH9N2QplbmRzdHJlYW0KZW5kb2JqCjcwIDAgb2JqCjc5NDkKZW5kb2Jq CjcxIDAgb2JqCjw8L0xlbmd0aDEgMTYyNDgvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA3MiAw IFI+PnN0cmVhbQp4nO2beVSUZfvH73uGfRhmQEB0xBkcQQ0Qd1FJRmAQxA1hbAY3EFA0F2RxS5Sy 0kjLMss2tU0rSh8eTbFNLdtLy/bNtH2zbF9lft/nubhMPe/b7/fHe8776xxn+Mz3e133Ms92314e UUghhFk0CqMYP64orZ/QX8Nb8TGxfG5ZNcUXThZCZpQvrHPsWL/nNyTeEyIwbEb1zLk//zwmHP5z IUI7z5yzZAb171+M/llVlWUVH/aIyRQi04XkoCokzNtNGUJYAhB3r5pbt5j6Z1rxYZ0zv7yM4gEb hQg5OLdscXVPaTSjf08kHfPK5la2Hx/ahb16fm1d+3iH1l5dU1nt//LTY+ifh+lNQgRvEqJtvTjz NV7MFrU430ZxpVgr1ot94l0xXayEu1lsEVvFfUIRB8Rz4k3xH3y1LQmcK8KNe0SQ6CCE/3f/ibat oDUw4ozMekQdAhx/ZfxW/zfn5L5pW++3trUGRYkwfazZcATZH+Qp/++GTC32D9Jiwyp4iz7iu+BN bTvatp1zDQpFiZgkJospolSU4fwrRJWYhStzsZgj5op5ejQPbTPxOQPRNPQqRy/N/9VrvqgGNaJO 1IuFeFfD17ZHWtsCPa4Xi/BeLJaIpeISsUw0tH8u0jPL0LJUjxeD5WIF7syl4jLdsVJmpbhcXIG7 tkqsFlf9bXTVadckrhZrcJ+vEdf+W7/2rGgd3teJ6/E83CA2iBvFRjwXt4rbzsnepOdvEZvEZjwz WtsGZDbrTmt9VDwtHhLbxQ6xW7+W5bhqdEX4uszQr2E1rsEynOHKM46Yrt+i01drOc5dO7em9jNd jPxlZ4xY2H4dtZ4r0ZNmofugzdJwzpVYh3Mg/9cZUbRBP/+/smdelb/L8vW47Ywrc6seae7c7L/z N4rbsQLvwKd2VTV3Jzy5zbo/M7/pdN8tenyXuFvcg3uxTXeslNkKv03ci7V9v2gWD+D9lz/TkW4X D+p3ThEtQhU7xS7cyd1ij2jV83/X9q/yO9vz6unMXvGweARPyONiP3aaJ/DmzGPI7WvPHtRzFD8h nkSs9aLoafEMdqjnxQviRXFYPIXokP75LKKXxRHxqnhTmuFeEV/g8xQQrpEV06ZOmTypxOf1FBdN KBw/buyY0QWj8vNG5rpzsrNGuDKHX5gxbOiQ9MGDBqb1Tk3pmZTY3dnNHhcdabWYTWGhIcFBgQFG gxQpbmduqUNJKlUCkpx5eala7CxDouyMRKniQCr37D6Ko1Tv5ji7pws9Z5zT00U9Xad7SqsjQ2Sk pjjcTofyUo7T0SpLCr3wa3OcPodyQvdjdB+QpAdmBAkJGOFwx1XlOBRZ6nAruQurmtylOZivxRSW 7cyuDEtNES1hJlgTnNLTWd0iew6XujH0dA9tMYgQs/a1ijHRXVahjC/0unNsCQk+PSey9bmUoGwl WJ/LMUs7ZnG1oyVlf9OaVquYXpocXuGsKJvsVYxlGNRkdDc1rVIik5Vezhyl19KP43DKlUqKM8et JDsxWcGE018glcBEq9PR9JPAwTtPfH12pqw9E5Ro/UloVjvF05cJ7ewFjg1HiPNLSNCO5epWl5iO QGks9FLsENNtqnClJfsUQ6nWsp9bYjxaSyO3nB5e6kzQbpW7tP1nYVWc0jjdkZqCq6//JOIH7Q7F mFQ6vbxK07LKJmdODl23Yq/iyoFxlbWfq7ulTxr6l5XiJGZpl6HQq6Q5q5VoZxZ1QMKh3YNZRV59 SPswJTpbEaXl7aOUNHeOdlwOd1NpDh2gNpez0LtX9PcfaxngsO3sLwYIn3YcSmw2bkqSu8lbMUOx l9oq8HzOcHhtCYrLh8vnc3orfdpdclqVXsfwdQn6N+qjcG7n9ObO2pkHJ4Y4vAab0afdLSQcufhw ZmWgwYrbpYfaHc3KcHilTXA3fEt7D82dNQ8CY2J2ntZk1IZm59kSfAn0+ptDsrUfU2CiEnLGXFYk Th8Tfc+/PTTqrR1QL4e7MueMAzxr0sD2A2yf7V8fp0G7Fu1fjBEh2u3M4yZjIlYucgZMo6e0uxjn UMR4h9dZ6fQ58Qy5xnu1c9OutX5/C4qcBYUlXv1utz8lxWdF1J5OkSIS0MyBIRvPYG6yjW+rHo/U 49Nh3jnN+dzsaApxFhQ1aZM72ycUDqwgnHRQUn7Z1elRA7A0c7G7OXPLnA6rI7eprNXfOL2pxeVq qnaXVg3V5nDmVzQ5i7wZNv1YJ3gbbEu1r4oSBbKgOCs1BXtPVotTri5sccnVRSXevSiSHauLvapB GrJLs3wt3dHm3YvS16VnDVpWS2qBQwu0mSYgCNH72/aiCm/UWwP0hB6Xt0qh50I4J0V5q4FyVs4Z kAugnEvPaS/cpLgqXGJst25HhXZ7lvmqmkp92uISsbiV+JGKdA4XisE5vEUagsKVMGdllmJyZmn5 TC2fSfkgLR+MB0PGSlwcbU9qKnVin8ID5RU2SY+iUZvS0er3F3sTXrKd8CXgUZsMSrxKaDL2/sDE Ueg3UqMU6ZFKY3mZdhzC49XGBifml/vw2PKE6JKvhGKG0PYZ0CNXH6M9jhhUjnuDG6iPb0SgNPoU X7L2pd5ZPv1xtioizzkUt53mDEzSvijN1xTl7KevTSyFsMRVmoTi2ESRlzI2hPgyH12k4HAcebkT TeWlDlztAFFehEed9tIwG2UqsSUGJFXqhNnaG4V2WsZEkzlMCe2NCfGjeVNvbUkGJgb7fHTwerSq vQO+26qYcERJZ1zK9gG4OmjK144FP6twqFrXA9o0ha1ignMxdhbtoPWZgtGsmBPzy7D503gTMs50 Hhyi7RGm9jkOUjZYO/NwXHdjYnGrf5tzScIZr9QUp/aHg/ZgCttePNjC13RuQpmUnJoScm7WrKeb mkLM/3oAXa8Q82nVkg43/tRAR/wdOEi0CXkwbOyffdvWhO7WMme9ArRMQBmqvGBUiMFYD1aRJvC3 UWec36+1qqFGR6vh8l2hcXIUzEo2l7G5lE0jmxVslrNpYLOMzSVslrJZwmYxm0VsFrKpZ1PHppbN AjbVbOazmcdmLps5bC5mM5vNLDZVbGaymcGmkk0Fm3I209mUsSllM43NVDZT2ExmM4lNCRsfGy+b i9hMZONhU8ymiM0ENoVsxrMZx2YsmzFsRrMpYDOKTT6bPDYj2eSycbPJYZPNJovNCDYuNplshrO5 kE0Gm2FshrIZwiadzWA2g9gMZDOATX82/dj0ZdOHTRqb3mxS2aSwSWZzAZtebHqy6cEmiU0im+5s nGy6sUlg42BjZ9OVTTybLmxsbDqz6cQmjk1HNrFsYthEs+nAJopNJBsrGwubCDZmNuFsTGzC2ISy CWETzCaITSCbADZGNgY2ko1oN9LPpo3NKTZ/svmDze9sfmPzK5tf2PzM5ic2P7L5gc33bL5jc5LN t2y+YXOCzddsvmLzJZsv2HzO5jM2n7L5hM3HbD5i8yGb42yOsfmAzVE277N5j827bN5h8zabt9i8 yeYNNq+zeY3Nq2yOsHmFzctsDrM5xOYlNi+yeYHN82yeY/Msm2fYPM3mKTYH2TzJ5gk2B9jsZ7OP zeNsHmPzKJtH2DzMZi+bVjZ72Oxm8xCbXWx2slHZtLBR2Oxgs53Ng2weYNPM5n4297G5l802NlvZ 3MPmbjZ3sbmTzR1strDZzGYTm9vZ3MbmVja3sLmZzUY2N7G5kc0GNjewWc/mejbXsVnH5lo217BZ y2YNm6vZNLG5is1qNqvYXMnmCjZc9kgueySXPZLLHsllj+SyR3LZI7nskVz2SC57JJc9ksseyWWP 5LJHctkjueyRXPZILntkDRuufyTXP5LrH8n1j+T6R3L9I7n+kVz/SK5/JNc/kusfyfWP5PpHcv0j uf6RXP9Irn8k1z+S6x/J9Y/k+kdy/SO5/pFc/0iufyTXP5LrH8n1j+T6R3L9I7n+kVz/SC57JJc9 ksseydWO5GpHcrUjudqRXO1IrnYkVzuSqx3J1Y7M3qkZVM1q1+F21Mxq1xjIZRRdqnYdCmmkaAXJ crVrOKSBomUkl5AsJVmixo+ALFbjsyGLSBaS1FNbHUW1JDWUXKDGZ0GqSeaTzKMuc0nmkFysdnFD ZpPMIqkimUkyQ+2SA6mkqIKknGQ6SRlJKck0kqk0bgpFk0kmkZSQ+Ei8JBeRTCTxkBSTFJFMICkk GU8yjmQsyRiS0SQFJKNUWz4knyRPtY2CjCTJVW0FELdqGw3JIckmyaK2ETTORZJJ44aTXEiSQT2H kQyl4UNI0kkGkwwiGUiTDSDpT7P0I+lL0ocmSyPpTeNSSVJIkkkuIOlF0pOkB02dRJJIc3YncZJ0 o6kTSBw0zk7SlSSepAuJjaSz2nkspBNJnNp5HKQjSSwlY0iiKdmBJIokktqsJBZKRpCYScKpzUQS RhJKbSEkwSRBaqfxkEC1UyEkgMRISQNFkkToIv0kbXoXeYqiP0n+IPmd2n6j6FeSX0h+JvlJjSuG /KjGFUF+oOh7ku9ITlLbtxR9Q3KC5Gtq+4rkS0p+QfI5yWckn1KXTyj6mKKPKPqQ5DjJMWr7gOQo Jd8neY/kXZJ3qMvbFL1F8qba8SLIG2rHiZDXSV6j5KskR0heIXmZuhwmOUTJl0heJHmB5Hnq8hzJ s5R8huRpkqdIDpI8ST2foOgAyX6SfdT2OMljlHyU5BGSh0n2krRSzz0U7SZ5iGQXyU41NhOiqrGT IC0kCskOku0kD5I8QNJMcr8ai/1a3kez3Euyjdq2ktxDcjfJXSR3ktxBsoVkM022iWa5neQ2aruV 5BaSm0k20oCbKLqRZAPJDdS2nma5nuQ6altHci3JNSRrSdZQz6spaiK5imQ1ySqSK9WYMsgVasx0 yOUkK9WYGZDLSC5VYzyQRjUGm7FcocYMgiwnaaDhy2jcJSRL1ZgKyBIavphkEclCknqSOpJamrqG hi8gqVZjyiHzabJ51HMuyRySi0lmk8yicVUkM+nIZtDwSpIK6llOMp2kjKSUZBrJVDrpKXRkk0km 0UmX0NQ++iIvyUV0uBPpizw0SzFJEckEkkI12gUZr0Zr3zBOjdYe77Fq9ErIGDU6FTKauhSQjFKj URfIfIrySEZSMleNXg5xq9GrIDlq9ApIthrdCMlSo3IhI0hcJJkkw9Uo/PkuL6QoQ430QYaRDFUj tUdjCEm6GjkSMliN9EIGqZElkIHUNoCkvxqZAulHPfuqkdqJ9VEjtbWZRtKbhqfSN6SQJNNkF5D0 osl6kvQgSSJJVCO1q9SdxElzdqM5E2gyB81iJ+lK4+JJupDYSDqTdFKtUyBxqnUqpKNqnQaJJYkh iSbpQBJFAyJpgJWSFpIIEjNJOPU0Uc8wSoaShJAEkwRRz0DqGUBJI4mBRJIIl98y3a7RZim3n7JU 2P+E/wP8Dn5D7lfkfgE/g5/Aj8j/AL5H23eIT4JvwTfgBPJfg6/Q9iXiL8Dn4DPwacRM+ycRVfaP wUfgQ3AcuWPQD8BR8D7i96DvgnfA2+At88X2N8197W9AXzfPsb9mTrK/Co7Av2JOtr8MDoNDaH8J uRfNc+0vwD8P/xz8s+bZ9mfMs+xPm6vsT5ln2g9i7JOY7wlwALj8+/G5DzwOHgtfYH80vMb+SHit /eHwOvte0Ar2IL8bPIS2XWjbiZwKWoACdpiW2LebltofNC2zP2BqsDebltvvB/eBe8E2sBXcY0q1 3w29C9yJMXdAt5gutm+G3wR/O7gN/lbMdQvmuhlzbUTuJnAj2ABuAOvB9Rh3HeZbFzbWfm3YOPs1 YTPta8Pusa8J22a/wphov9yYbl8p0+2XeRo9lzY3elZ4GjzLmxs8pgZparA1FDRc0tDc8G6Da0xQ 2DLPUs8lzUs9SzyLPIubF3kWNtd7Auqj6+vqjT/Wy+Z6mVMv+9RLg6i31jvqjeF1nhpPbXONR9SM r2msUWoChik1x2oMokaGtfr376yxdc2FupbVmK25CzzzPdXN8z3zZsz1zMZhzUqf6alqnumZkV7h qWyu8JSnT/eUpZd6pqVP8UxtnuKZnF7imdRc4vGlez0Xof/E9GKPp7nYU5Re6JnQXOgZlz7WMxb5 MekFntHNBZ5R6Xme/OY8z8j0XI8bpyy6WLs4uhit2gGM7YIjETaZ1cfmsh2znbQFCJti228zRlk6 2zsbelk6yexxneT8Tis6XdvJaIk7HGdwxfVKybV0PNzxg47fdgzo4OrYq3euiLXGOmKNMdq5xY4p ztU1M4e070D9XMfEOpNyLTHSEmOPMbjtMVJEHos8GWmM2Wc9bDVYLNJi8VsMLgu6WyLsEQbtwx9h dEX0HZxrMdvNBu3DbzbGuszIaDP2CB9fnGsx2U0GT6ZpnMngMmVm57pMqX1yhVE6pBTSCjGGoO8u GWPPNT4qtX/GCRRSrmspLkpOLmgNERMKlJDxkxS5Wkks0j5dhSVK0GpFeEomeVukvMbXIg3ZxUq0 9o+9enzF2rUiPqtAiS/yqsYtW+KzfAVKo+ZdLt37NS/QxZc8tba+Njm5bio+ptbWJes/iGS9FiVr Se2ntg6x9q7XY5H8ty/qBplWi1dde67u7wf9f3/J//YB/PNfLUL7HYURfsPlosKwElwGLgWNYAVY DhrAMnAJWAqWgMVgEVgI6kEdqAULQDWYD+aBuWAOuBjMBrNAFZgJZoBKUAHKwXRQBkrBNDAVTAGT wSRQAnzACy4CE4EHFIMiMAEUgvFgHBgLxoDRoACMAvkgD4wEucANckA2yAIjgAtkguHgQpABhoGh YAhIB4PBIDAQDAD9QT/QF/QBaaA3SAUpIBlcAHqBnqAHSAKJoDtwgm4gATiAHXQF8aALsIHOoBOI Ax1BLIgB0aADiAKRwAosIAKYQTgwgTAQCkJAMAgCgSBghB+fRmAAEghRIZGTbeAU+BP8AX4Hv4Ff wS/gZ/AT+BH8AL4H34GT4FvwDTgBvgZfgS/BF+Bz8Bn4FHwCPgYfgQ/BcXAMfACOgvfBe+Bd8A54 G7wF3gRvgNfBa+BVcAS8Al4Gh8Eh8BJ4EbwAngfPgWfBM+Bp8BQ4CJ4ET4ADYD/YBx4Hj4FHwSPg YbAXtII9YDd4COwCO4EKWoACdoDt4EHwAGgG94P7wL1gG9gK7gF3g7vAneAOsAVsBpvA7eA2cCu4 BdwMNoKbwI1gA7gBrAfXg+vAOnAtuAasBWvA1aAJXAVWg1XgSnCFqBjRKLH+Jda/xPqXWP8S619i /Uusf4n1L7H+Jda/xPqXWP8S619i/Uusf4n1L7H+Jda/rAHYAyT2AIk9QGIPkNgDJPYAiT1AYg+Q 2AMk9gCJPUBiD5DYAyT2AIk9QGIPkNgDJPYAiT1AYg+Q2AMk9gCJPUBiD5DYAyT2AIk9QGIPkNgD JPYAiT1AYg+QWP8S619i/UusfYm1L7H2Jda+xNqXWPsSa19i7UusfYm1/9/eh//hL99/+wD+4a+4 aVO1ClO01RqPBEYIowgWQ8QYMVZMelSY8UzHiqHyoYdicnJCUoMfx/NqEA488SEoSbNdlgCDeU/n zpnOPQOD1hoj8/EX912ZwWuxl2eeOnrqUNqpoyeihqSdkGnvHz963Prdocghaf2Pv3a8bx8ZmRCp Ex1hCA6ODnJ2620Y2CNpUP/+/YYbBg5IcnaLMOi5AYMGDzf279fVYIzmzHCDFkvjkT9LjONOBRmW OzMn9g/s2tkSbQ4KNHSJi0rNSLQWTUrM6B0fbAwOMgaGBPccnNWtYI672zvBkfExsfFRISFR8bEx 8ZHBp94NjPj9+8CIP7ID5vxxgzFo2OTM7saNYSGGgKCg1q5xnS4YlpA/0dLBGmDqYI2MDQmOigzv mTP51JUxXbQ5usTE0Fynxui/c3XH+ff59/n3+ff59/n3+ff59z/uLVDe0W+SR6MS1H7RvDMIgjH+ 5/5v8T/yFSC66Z/679WflH4/fyLW/m+4UXdRuH4Gof1yvlmI4mJ336whuenZ6XV9+ui/s4+/HAf+ n78x5OzwpDjpPyvR/hv/ARF/IQ+L//1OaeNkoL1F2fHwNEvGT6ITfdEjXy17UdMDPfLcf/Ztqw3d rf1fdBGqnw9e/wODJz0MCmVuZHN0cmVhbQplbmRvYmoKNzIgMCBvYmoKNjA0NgplbmRvYmoKNzMg MCBvYmoKPDwvU3VidHlwZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA3NCAwIFI+ PnN0cmVhbQp4nGWXCVQT977HJ0bC2CpWc1MTbTPx2lp3Rbu4tde64K6goBa1si+SsCVkISH7Msk/ CdnYkkACsoOAIlqsKApWW+21Lija3utau57X3r7a//D+tO8O9rzzzjtv5pyZObP9f/Ob3+/7+f4Z 2PhxGIPBmBSfLUoXL9wsSRZmp46dWEjNYFCvjKNeZaI3UOrI7yN/i3gV21Y9YRKYyAQTxwdfeenO VPjzFNg5GTpewpgMhryqbV1evqIwOzNLIpiTsGvv3PnzF/zvmegVK1YIUhT/c0WwPl2cnZkrmE0f SNOFefmi9FzJKsE6+m4hHYEgU6jIzxILktPS0tPGHtuTLEzPEcRkC7Pz8/Okgjnr5gqWLlkSvZDe LN2RLUopEgt25YmScwU78lYItgl2pWcWCZMLBX9+z/+/AcMwgSI3dXteWn76zvUZhZniLEn27vjN UpkwWS5KESxaEr0MwxKxndh6bBEWi23A4rAYbAn2OrYR241twuKxzVgCtgV7E3sLm4ftxfZh27G1 2AfYDmwdxsAmY1OwqdhfsJl0arHxWIgxj2EcN3Fc6jiKGWL+9/jk8Q8isiM+ZdVELonsx+fhoQkx E+onfPtC3AvoxT0vPpnombR30vVJtyb9EBUT1Tb5LeiMomJR8j+oEyEGfPAd00+9xql0euzlYBD4 C3vRmuCWI2gCKAZKk1KlEKbICrQaaZHGoAYmYHRqvaoKrUsL8KLi4qLCWnnzFTgNzoOJECOuwclN N8EZvKWwXiRRqopUXm1Iza/RevSgBKRmvPs2mimDOFf1eDdcoQK4hWWzWYAF6G2Zpj06s01Nlljx KIoE4amw+7btq2nsfioJTuBIC3IzFMoSwDMYvF4PAFUDxCBMiWCHXeHS2qrpnfn1aVu37URvvsb/ O8wlHQlaqeVNJU8ZedZWaQIyYLKZbOb56BfubdZpuNRXe+rapW/O9nUB3O/TKjSmwwYhcQitiGD3 q/eRJbrp6VXK9o8awt98waezpO2kiDCj5SEsfMSEvzzjxMemFSUCfFf2yRsPOp4MfEI0t3RXHwd4 nd+gMVvNFj1hVFuNQI+L/SVHGsOhht4PO3aieUiAZqMlC87Hfzt0ofXOJX7UyBAIjDACDLoNZnLQ KhZ6MqqLp3QRaLOS1Uce0QIJMFhUJoXVQmotKhtps9gsM0dxrnCWSrbXhCthYiByX6msAjSBstIG VxC+QG3gXh49GRFkUZOoi4gzeli5R6baYuQpYUMgcqNb7watIOio9LXCydRObvUll+sT31iytWFq UZjReB823GfCu9R2Dh3tHLQYRb81kPD08ystgxeJz692PwC38X/GDb7N10g5J5sydq09/MahLUTG nvTCJIAfEHZeGGp+fOYGcXygp+UkeP7aj6kpdQz/IyaVCpmchO1afTHAdQZfeVUbjGqH44jGb8Jf noUHzC7uHm2maasJL468YPWQQArUNlPJvkNoOdfQowikARy9jN5GsWje+u6kq9dOtf10jdDus6qA BM8PKup7zp24dY6PlsPrnBarXw4ycbRgFlqzOFvcePyffRD//Dq/qbmrpul5YaHkAIypYVCTv2YO UHM4dSwAHMBur3Q3yIEK6DPRX7MQN/8N8QJjrvagWpNkoxOd7I88UOwLVwXvhoaIenW1pQ7gcDZc BFfDZXcPnV6/ZX/Oyjii+SenDwCb3ebgWe0RwG4DY4uV3vVNnIUWFUXAAJ04a00BiAObc99K2p4c u1+4F+B5Mn/t0U44rXmIaLx28UwfSYcZS71dx2h9BOWfM+F/QQZnXaxQSWd5V0bneb/D720jmkrh vPCzO+Ahr0fU8AF6DUWjFWjeyvO7794YPvH3T/goFy7mHH0yNHwW4OEqpUQozxSKiIysdMVbUjxq JEPRTv3Rzrj0K5PKHVnEeQdEp65aO3tRLIoCaAKOBE/nQDZMgx/CDCgt53vgzLm/oekA1x/m3OuL W4iwA2j2loVE/OrtaRsA/s7ByxD7rg/OvfSIGPjq8rFbYGwE0EJ93aIMTKUeQuY0dhd8eWQK51OT 3wDygcoiNhaiyaM7uIo4o2m3jk6xOxJOAL+1Dg/8eGMQjgMQx+FyxPoVxfBRKwtujeWwv6h1+z3d MwZBn7pNfCazcRtYDRCWjMZv3Bi7c6VoFsAPyssbKl21wUtEFGxFqWHqXhuU1zLQG3eoN+8xOygB 52vWstHlRYLD8cmApzF4fE670+kiSt32UuDGw4qgVKpUSLI78k89uf4fcNsJ/k14KwIyWO62CISx mmF0140BgFf6zEbSZiXNhEVvNQMj3efK2rqa6tqujKbExLSiA5l8UZrsoGg+vpgVRfFAGN78mQEn vXwOvhc82XunfaCpNQjcwGVx6bzFXnMI4M3B6tZWeThPkq/KLyBSklNjlaklmdx+KCIda9V661oN rzjyiMsJPACvrdQpSgBQbiRWoo8ixgo6pRY+DsM9x6tqp3ovdAzBhZcO35vG/p0SUnM5O1gkMDsM 7vzqw2XpdBsxo99buLdWNFhAxKYqZEAM1F5NTcmcLfTxQTzm8w9/5rP/gFPvf/Los/2nFtQTh8oL AsCP++saKh0OYHPyvdYqmw/g7N+ffvfV3QAZMoWIPhYaRk85duCwOWxOWxkZMOPsP54d7so7OD0h LvW9VQeOXTniDgZq+JXBnnYv3TlzqBkc9u9dNeIDWZpD8myiKEVYlA3w9KKm098MfnmVoJOmDsvD sBdGGevkoamQcav3zjT2nk44m8M2y9CyiADLG3C7ykA5qLaE6OH2GGuDZGDG/Uvn7xyTnjpwkUg/ rWwFjXh7ONzBZ88+B1oyyt7FAyx2VAgSESUsQ4nBUgKMQOeQu+invYUqh3LG2v1Jm3LCST0JxPF9 wSyQi38oyjkULzzxvZL/HEgjmJ9BsYaZVDrNo4SNGq2Sbgijz1cW+Cx4jmj+vmYIHMG78xvTtqzf jF5fxIcTqXizK06dZtxp5KkaIu2AXu1V7iPFNAlLzIX6XJuNLDEVoRmjPppL3XBR5dHuy+fuXfu0 g+ZSpUZtIdUWJRGPUtWJRiHQ8AqCysazHY2PaHbAVkrQxoBnqDWcVaymX+yOMRHjeUin2UTaDCZ+ 2r7tH+ToCw1GE9ACG7DaSXyItQ41WfU2ktTz9CJDFjDgRWFlY29707ef8dWexG1KpRLw9CZvxViY TuIxfBhxnzU20kfPGGduM2EhZHHEOUaDTltcrNLpAU6j2FPm9HtqCOB0ehxe3BFpdzyGt0nHbLmM TCNp/PbT9UDj10AqTbL9aANXGWcSAhmeEZC19Ha13B/kS6mPOfkyiSinRtrcUFfX1CxpyKcLgFR0 5IRHItvH/v60x3DKo2nsdiqLyuKwX+mG+yMkrBKp3lwENEDrlHhxdruvKMclnDHr/Zi5Cf7cS1sJ n76yJCivllepPIbTiZUFIAlfsztu7fJtN7732r12D1/miGBvy0biiGqWp668LESXkt/SoKdfVdzb aGqdASMfPYIRVyXHo58S0U/1VbSj+azn+LWuVrU4zK8t9GY7NtMy3Q8Cyhrqh46p7KSRSTTFR5tZ yWhRtaUfYm1BuNDKQ6+N1tMmRblHrNxspmXuZCCSnWQvVjlMM1KdGh9oAZXOCt9RSFBm7gXWzbbC 3WqbylpMBK0RUfDhn/7A8DIkA6xdHq2bJn2No8LX9ie+L3rcg2V4AAFl5EVjhQHkgRKL5P/qKg0S +PBbZph6g1Nu99LfeByUFVctLoupQPNBHJ7nMHrqv30G//ovfkdfw1XQhbcVNIqKVGqp0q2pVvIr NS4D0IGDmxFz/fvCHK4RzjSdUw/J/gUcekArn81AKszxunQTrfeLqTlBBnX+KTNAUzXEsgMncNmb HGU6T3rFroqZztWly7iONIfBR0cRrO/8wlUe6mjpfwKXcJvRTUe+g/QAnheUlTW22+2lrlIXfAW+ cwdOBVfwlqJakZiOSe0yBFT8gMqto/97UnYCmobeyYG/csutTpOZtBrMfBSPBsnr2l+113naT61e De1VtXQPaS1iy2GzBeisGtoCwNaRvwQY3cNMKIeTOXotvWpykuUqBe1NzJ5yj7PCFSLsTrvL7oDz qTtcsytWnW6MpV1U5Mcho5K0mUg9gV4drSe1Vh0w8zKDsrZzHc0/XB1TCe0ZakotI3ifSaXBcRyV ymQ2GkRC9fNuMbk9oR74t9NwDeEsszscPqOTu8NIktr9hq7ccBLgIS5ahLaipRuOpVy5frIdvvSY kL1LqoEYz63QNHXX1zwd4qNV8CbnqLVWDLLAOx+gF2LeF+dnF+cCPEvS3Hv+2C8nPyW6L55u635u IrTD8MItBjWbdl8Gvdmk10hEGp12zOZUGpusXpvb5iz8WdsL/KeGO09V00zykmXmCqPH6h0zDf5w uDggPpSeKYghtBdKrmlD+YBXBLL1O2RaC7dUdcznc/gArx649VU7m9Fk7go0QSaSKbSAZwI6p86t 9midBoDLVSpZQUjZ0lrhu9xHNLaFG3sutqCJ3Mp9lco2cAw0HLn49XPDEGbA34bv33HcZY5soCVW pzHoSEteprSYnicYzO4yV2nAfYSeYJTaSx10tLzOwsZsucyoEvMTc1L2x6Bx9Xf8g6AG75DUZ+/Y QGvwYv5FmE46dmukluUqnrI+sqHSqNJKlmQiNiFZQerU+/DbrI/hMn/X0XMDDy4NHKXh7tEr9Tlo 0jakJsY0eUmo7+yNM9f6TjUDvNyn05qtGrOCiEPF+gyLHOh4oiplw+lT7UP9fJdnjMbaOuqlM4y6 h7DtAROOG5nG+cTqJkER0JMaU5HVaDXazFYjF70yao2wREqGRQNwPlwJ18Ho64l9mzbsTUHj1vP/ k6KL7gN9pmmTgQfTUJhzsvHwns37BLHbiYz0JCntA4Wq8rpLLT/2DBGnhj869jHtt+j5HHT+4yeO qLBAmFtf2NTWcKSltaBBNKalxqaRyCZG2z0m/G5kOYd2iguQHGkQ98qyH0/2+Ft7iJ+GhuFKAF/D 4dLY7+fxjXmc8y0HV6HpqWjFrteJ9M0p2R8CPCGn78Gzc3D/uW+IzivHW089t/igqsQ/la098zJ7 DWzzK1mJ0rJaX2m1t55weB3usS7iwllUoNRPV4qLV2p1ksAKbDb+alW0wgoMVq2Vp4ocdNTZ/Rog 4wGTVWdWIP6olsvWajKkutXGsUFGonqmwntf5tMQ6Icx1BVOR29HuId2IeH+zoyEZGnmoVwiOTdJ tVSF08QBlbYGHc7uvyxtj189HWQaMkvEktSDealADiRlotrcsNIjp123sqQw/YT0xmBfRf1J4l5v 333wBNzM7d3Uijsj2WE46XRH+7Xp7P5bO8+vitmeuvUwP0oWotaH4MEQq+6Fuy/W+SZOxLB/AzHa NbAKZW5kc3RyZWFtCmVuZG9iago3NCAwIG9iago0MDQxCmVuZG9iago3NSAwIG9iago8PC9TdWJ0 eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDc2IDAgUj4+c3RyZWFtCnicnVZp VFNnGr4RuPcKlNZkMkLVJHUq4rjVuteFVqtViwhqRUVkS4BAIDFhCZAFQljkkx3CEiWQRSoEDLIp SnHvuIzSOnXa6TbWdrrYaeuxZ95LP+ac+eI5PZ1z5t/8uefe3Pe+y/O8z5OPR/lOo3g8XsBeeaZM s3iTUiH1Pi7iZvG42dO4OT4IJ/0in9zmN4eKOOH3DAr0QYG+9tkBwIePZkDHs2B6jvLh8bR1js1K Vb5anpqWLQl7a3fMgoULF/32y7K1a9dKkvJ/fSN5XaaRp2ZJQslNrkyhVGXKsrLXSTaTaIVCnixJ VeSr0jSSRKlUJvV+ti9RIcuQbJUr5CqVMlcStnmB5OWXXlq2mFxejpRnJuVoJLuVmYlZkkjlWkmE ZKdMKs/J/N8XFEXNjngtq0Ap3aySpahTt6Zly/fk5CVqYxZKXoiNs1DUYmoutYuKpaKoLdSLVDS1 lXqD2kNto+ZT26m3qB3UCmoftZ/aRB2g1lCBFI+aRq2nNlJKag7BkPKlYqgJXjhPz7s6bdW0AZ9l PvU+nO8evxl+Br9/0n+kc5gZjIJ5zJqni6a7pt+c/mf/Gf7r/GX+2VAdNLkUOdXdk5ST/zOsmilQ TfIhT5hFp2/IU6RlJKXsyd+I2Ehty7CYUzDofmvLFzWsEz9WM3fLTxSi/eyUlhF40H5D0SYTq2YE Ku4+HTSZQlJ2wYYz3FYbX+CZ3OIUltNSVNhxAPyxhrMHK2msnjorW2LUxZpCBCo1xJMkTiaqJtuC XKilwdlxqe1MMOTQvRuaU1EOK1ChXENx2lFW4ClDhko9uVGRYh74kJ6qgCLht1D+Ey73C+IuIge3 0sb7AMQgArEPpHGJQrxHQ4+YG4tRIotHGZRYYjpsYjVQ6mBSao1tyMOCjUE19U1NjZ12R7MdsX3H VXvEuIxBKYZCeTkJNToYaXVxMxpioYZ5sO/y2l1xyqgUURAXhXq4F3p43BpYIVTSpoyS/MLcjPh0 wzrEZtFQyM33c00xjBnP9XPRzu9cVpBUYsNUWLCaEzBBXIW+m9vQzXPCfFgG832ghssUYkHYXDwb /+G7F2EmCB89IYNIFj7BQvExhfBa+168Bi/Ji4mOynsHQuH1E+M3xGRm/RUu4Aq84SCZwmC1d+yv DcJzLc7aG/U3GoLtTFy1oYX0zt3DGRrmTlmjGcWx+E0m4VymNQ6xeNpaCZ6HZ/817OeLbuvYqLji XSEqLS4wGvKyc4tyELtP/S4IQHjy+jV3t0bWKib0as9PTndn2/gXYMtMwcTkPFgkjNqZoTmozTKm lyrRdhTRlzWedVF/D/3IQvItmAaBo8P5smHRsNSe3hfOOmnCnUHF6NOKirTIhHQ1OU2sYMIRFWuJ nYVj8QK8BCfgJJiPQyH5/evHPZfFPZ2dtrNjLBkXJ3ZA+GXO/2qGjX+f4LMKwmYKPvkvqpu8VE8d ZVBSiSm2hPDn6mAiqwts6A4LLzDnD7kMI4gF34+fQJhY8D2IX/0O+0SlZkcrRFVxQlTfaG1usXXa mzsRO+7YhWfi55RRu9Oz7P06AnaU/h7s8sCKbh4XCjOEyQcV+QlIirJO5Pbl95S4yydYqKVLP9eN ZvSnn4mz7SX4zlgdhkNx6KcL4blPLvR8c1uM2yBcWA2BJwYuoC7UXtigqNVWKav2szomCB6QDZ4z ArHdvPdBfBWCfN7nVgrxAwYlFBnjysgw3Q5mS5WxGd1m4c4XIysgiLnc1tl3wmI2lleYS4tFJl15 ESpmFS5Nr8fp9FyPGly9LUYTrxLlpJmT0Ep2dzztXVwHXIV5qQ7+ZyCeScjI8qIXraGHSy0GlPxU KEnFRfFe9NodTGSNsQXdYCGaGe8adjc0mgstIsGEqr3N5JrlcXWdOSt3HzogU207RBCqwEk9EASB X5wExUVTN7/r4XqYA8EwK+VvMwWPKS6Xmyu8iH/PCB5R1nhlXfIsHLB6+yJ5S7pdKe7UtBtG89ar kmUoBiWdyL+VzQp+LoowpauTno++LyfO/8rD8R8+3HlunmgHvS6vvutUV+eA+GzlKHLW9dpCSPqz LvvgxefRgPGUsovdOLVPSL6/5CpIj9t7JGx5nH2ko97SZReT2l9yJuFou2zJEm3qodj809982+4Z Jd0DcsLVXvDtgNBetZP/xGuJ33MfT64RTt1S0xPl7ToU4/U8FKMveq2EVcOUk1lak9+MLrOgZx4f 9aS0YpZ1wj/UdD6m09Lmk03TMYKfPS1N73x9vSCtW9SptqhaI1gH/dStJgNtvIlf3UpKyuC9Gvqc qb4EJbFT9f+vW6VWG9q8bnXsqVvtS8mLjhGR1eJWjvDueQtdI2wvhg1qOnJl8uEde1nVOP6Q2TGc PHFn4NSngyK1JU9WqM9FIcqi4wNiuPQt2ctu1MGtsd2Hpd52SavefSGtjpgaTaTVp/tiLokrIvVL HExarbEV9bNbuH8JE9LSEg+700dGet0jw/K+BK9had0c0fCabq2NPwI8KIUAImBOyymFkJnJmI+U lBQQUyiqzmlgBd9bD2XUyWbh2Ws2Yv7y8QgI2C2+k/Ew0XEExYRsPXh4Y/QB5wWZSOXRuwveY7Mw epuuczY0WlEDslR0mscKPOZhwkHYj38H/v24+2/2iPH8v7wykONE50NuDPXfPTukTTkt6k2zZtl2 eN2F2+7g3f6VkEcG4XCbo+Z2/Y164qPxVUQFwyxM4TgNM1bebEQJLD7NpKfnFikRm6SzvSOGr3GU hhksaTB5/21qmeVjMZ+N91nHromIa+o7uE0O3mSMF7pZGtpTbilB2choSFGs10lLco3y4sGK5twP 8ibMXagRWZtq+6tZBzZomDPlxyrbt9dpg9/A4Zpbpg5ze1lriPK9oh7UQsIaumpImFrDuMpqSk9u h7Ap/2AHDTPg5mN8089Ow1JuntXT0OCqDSHq5HZ2850QigUQAiyIiH1zmbeExcUVFRWVZShEb260 iqGV+Tz8Ig4SCTzYL3z/q0kO9eBAl6O3tbTFaBWbmirqUB3b0WXtu+ZSRYo2MTgg9WBeipo4eEJm rjzh+cjRw7eunrONXRZZ9ndqL6Bh1G3tH2RxzFWhSpFn1CA2M/fkwLWhoY87vIZBHG+Zg8dpHcLC WnON2YLDQBv8E/Db7TZLd22IA6/XMI2VDZXVyF7ZUIp0SFdcoMwoLdVpdbml9eV1FTUZQ0eGCRbN rXXuYwSLaoJFeV2ZLRN+hw8EZ6Wo0k36Pa/lFaQcJeu5gcijSl+P2lCba6j/XFV1fUN941BEsD29 SYuMyKgvVXjDSpmgX3S6jskQJ48cQokud6jpSxVtxUiBDEd1ZXrsix8FYwq+LO4pb0ONIcjR1jhS XYVqUd0xckC6rWYGj9pMFk3fwmDsj/+EAzmqzHq0wRv5dnPjuPcQNapmhkqbTMcPQtrUD8FdNERy RyB86ojfSRoOcT+0DNg73NWEszuoA6IeEp089CFaGRNi6XKQYtlDkIH0IZaCbDkdRA5y8MAAG3jw CrwkjJNJD8eeThk93+85Nyo7c0jc+pGwBZ5tvHDqUetIjQ3Z2dsKz763FCkR6hpt62HR24uaDrTg Z1mSAy9wT1a5eXee+MAlzArX0UmmpmHxJJ+5Zmm+IrrpxoZ/3wUD/VskrHri04MXCMEweRcb0m/S VyzGaPG/+Ux8iSlRtI7YXAVs/4oHDt9lXMVXTFCejUu0QYyNdvuDJMDtDgwEiT3wGYr6D3uQvnQK ZW5kc3RyZWFtCmVuZG9iago3NiAwIG9iagoyNzk3CmVuZG9iago3NyAwIG9iago8PC9TdWJ0eXBl L1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDc4IDAgUj4+c3RyZWFtCnicVVRpVBRX Gq3qpqtLRBA6BdhId6EjggiCIIvKGJVFBIxGEfdm6aZp7aY5gCgkbqBxeWhGZYsgzTIagcgSFsEF QT06giMwrslBc5JMDE50xoPLV5xH5swrl5kzf6pefVXve/fe796iKSsJRdO03RKdMVuXZUhO9F5k NmrFkpfgQguTJYKrNC9z1GXUJHOlYsqHJyAbKbKxOj2Z/cgBuuzhqB3kTKSkNL39UMlic3pOhkGf msV7xH0a7+nlNfN/Fb+QkBA+KefDGz5Ml2nQp/HuZJGtM5rTTbq0rHn8YvK10WhI5vXGnPTUTD5R q9VpxW2rE426LXyEwWhITzdn8x6LPfnZvr5+3uQye5nBlLQ1k1+ZmJbJx/Ai/P+rUBTlmJZs1mVk GlYn8T6+frP9A+YEBgUXh1DUJ1QYtZyKoFZSq6ilVBC1mKIpO8qecqAU1EcURzlSTpQzNYkyU0rK iQhFWVGR1FfUT3QkvVcyURIoWS85L7kkGZCukG6X3rFaa1Vo9UKWJqtifJlFTAfU2QqAKgVvGJ9m cegFHjTAOyk6eoUmbqyJPD6UKx72dbT136jdHK3CP5LKv+UwPqofyxetS/8kWaXo+E5uK3RngQz+ CTL6LPBSoQKecHvA2f977IJYPMfbDcfgiOGpEABOT4aAK1VjJZMTbk6PQ2xYQt+rrqIL5fXqstq6 shZ0DZ1OLwtjCagPHRvIkcdIV+gROjkc4o5pHI4jXmAK5kLwCNCwEKI93uBQdQGWcQ8vRbi5x4d/ vGDN4MhI1+ADtQjtDUwZBrs3tFAJ2VxBCfoTOoZ68i/tbNY/D7iOaQJx1kxshaPwwqdu4A0Tng+8 rlNjFZOboM1Yg5LRlvJttTstX9Qc7GIPD3OFjxpab6IGVJ9rMZduO5p9JIWgnUQknATqdxI6KZr+ K1+LXDHwqLX10YmiQwcqVDBFnl/wBdqPotHKRNMiVtH0+p14EngFEocLZMNScMH2Yo8XwmFBwh0E xn8ATyMYXQMjsFRfbKzIVldsL8+7nAvz4p0Vww27S3ZvVW7WbluqTztWkqP6vHhf8b4z5HPmS2z9 UywEo/voWllLfUt9zSXUjQZTO8IqcXiXs7Zkz3FUxdbWWy6qFC9uo28yC9axtlBHiOy39IE9fVvU PJnwwLzIhBk1WWFehMbYjs5ClaNhFlpwc4QjJHXYi8H+Y504UOgU13Dod5Ps7QTHeVcKs2AcBFgc rhNuu0Ven18fNXG/m4C/IldcXH32fEa/C3DPwQ6C7m69p7+sTumOOhuFlqD1GYY4FkrkYI0vcQMX w6d7rguPCNvQP/L8wsCgmiAVwYI7DZvBncMzsDvMYN5qaSMUE9ucIedpRQqnRlO5BWjploTlSau2 +yLsirB9+exv4tqWDOgeo4eot+7cjZYey68InBE4fvaz4Upif0RTMFFcZtWIzmwrT/nKdDwUzUDz 8+ftMX+WaMpKRinIXJHbuKM2/z56ih4fHyo6U9ZeW9OCiBO6iYCpw28sNOSJp+cJO7ixHcCPrvWR bw1alIBtEesjzhyBvZADDN0CStgohqYQ7DnczZxsrrK8fAB2vzT2oN9YcPX+GXvi6XMC8Ix9KL9g twqU1cz3TZ19N5sTwkIzjNgXS1XYJiQlZi92YoXs9xJA+lPYADIHeA08HvfWTmCCQe4iKjxUs49V DJ/fWZsUr4zVbFoWpW++u1+FJzMFeMrwbCBWA69nfwfVY33PvG/Vihd/bT3dcUsJ1v73sevcSHN8 ssqcunM9imF3gaO8oPlIxbGTpXX1Fa2IvVpvWB6WpA9W72Le6gCTgRUCiBJ/efdTOMUtFJbgEAaX jEXIsDU0YT8yJL97crwZWA7HMhALV2XvCdSA9BVxoTBB3LtjdC03ZsfEjKll4MCcaKivaEfs39rX zAnWrAlfZqi7dkDM62E88WkQqAiBmS9fkiBP8/sXdtqQusuYpK4GDxl0fhCnFCRDlW3EJPWgAiNM kgpfCh3c3s686pxTKV1La/+I/NFibUJYYkTufIQ5hG1PLGj8tDXqnvYH0tztt9fgA5ODnmLbFdrc jRr1kfsIHa0t7Wtpvoo6UE3OyU2sJ17J3WpbE7pg46rYaE33/e/O9dxSvzPHDZHVn0VC+0maXjMJ GwMxZ45d94cMn+3Yi7RnSiHrLnwM80HDvge84x+wjEyzigyTJUnRwwRyJ0MdEbwFR66mtPhYcRGr eHbmdHl7pxKkXkPYCTt7zcVWkV8n9BlUipEQjSEuSImVIz7gCR4jw6D8wdATck6FlbCVUzy72a5b FafRLovVfHulp725V30Qn+UUIwPtGxdGajZFRiZ0DN4513lbZADJL2mhB/q4sd6pQq+oaCYB6Aws VBA3fw2TIBWmSpshhDuC6V/ngS16ggaa2+409Va9QcCgkdxHW7o3PQhvCSQJmzJjGvbA7j9OB4fG s0VlVerSwuOF1adY7KJbMn+d4XTbAdUvwgquv211cKgmPjo6uWvoUcvlm2rbrGqhyQKhlvXVDFhb g9t4sC60sQG3IpsJFPUfOOTr/AplbmRzdHJlYW0KZW5kb2JqCjc4IDAgb2JqCjE5MDgKZW5kb2Jq CjQ5IDAgb2JqCjw8L0Jhc2VGb250L1NOREFCTitDb3VyaWVyL0ZvbnREZXNjcmlwdG9yIDQ4IDAg Ui9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAzMi9XaWR0aHNbCjYwMF0KL0VuY29k aW5nL1dpbkFuc2lFbmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjEzIDAgb2JqCjw8L0Jh c2VGb250L0pRV1JQTitUaW1lcy1Sb21hbi9Gb250RGVzY3JpcHRvciAxMiAwIFIvVHlwZS9Gb250 Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTUwL1dpZHRoc1sKMjUwIDMzMyA0MDggMCAwIDAgNzc4 IDE4MCAzMzMgMzMzIDUwMCA1NjQgMjUwIDMzMyAyNTAgMjc4CjUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMCA1NjQgNTY0IDU2NCAwCjAgNzIyIDY2NyA2NjcgNzIy IDYxMSA1NTYgNzIyIDcyMiAzMzMgMzg5IDcyMiA2MTEgODg5IDcyMiA3MjIKNTU2IDcyMiA2Njcg NTU2IDYxMSA3MjIgNzIyIDk0NCA3MjIgNzIyIDYxMSAwIDI3OCAwIDAgNTAwCjAgNDQ0IDUwMCA0 NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAyNzggMjc4IDUwMCAyNzggNzc4IDUwMCA1MDAKNTAwIDUw MCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAwIDQ0NCAwIDAgMCAwIDAKMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMzMzIDQ0NCA0NDQgMCA1MDBdCi9FbmNvZGluZy9X aW5BbnNpRW5jb2RpbmcvU3VidHlwZS9UeXBlMT4+CmVuZG9iago3OSAwIG9iago8PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDgwIDAgUj4+c3RyZWFtCnicXY6xDsMgDER3vsJ/AGSOWNIlQ6tK 7Q8QYyKGGETI0L9vIEmHDmfJujvdk8N4GzkUkM8c8UUFfGCXaY1bRoKJ5sBCd+AClvNrFxebhBzu Nr0/iWAPkBf6SGB0tCaLlC3PJHqlTO+9EcTuzzoLk7+S2hxSnWr5y6nVulgHH3YhwC1n4tKwGkYF CEw/8hRTbcEu8QW7yk2XCmVuZHN0cmVhbQplbmRvYmoKODAgMCBvYmoKMTUyCmVuZG9iagoxNSAw IG9iago8PC9CYXNlRm9udC9PRE5NREcrVFRFMUI5RjhDOHQwMC9Gb250RGVzY3JpcHRvciAxNCAw IFIvVG9Vbmljb2RlIDc5IDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDEvV2lk dGhzWyAyMjZdCi9FbmNvZGluZyA4MSAwIFIvU3VidHlwZS9UcnVlVHlwZT4+CmVuZG9iago4MSAw IG9iago8PC9UeXBlL0VuY29kaW5nL0Jhc2VFbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRGlmZmVy ZW5jZXNbCjEvZzNdPj4KZW5kb2JqCjE3IDAgb2JqCjw8L0Jhc2VGb250L1BTQUZZQStUaW1lcy1J dGFsaWMvRm9udERlc2NyaXB0b3IgMTYgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDMyL0xhc3RD aGFyIDEyMS9XaWR0aHNbCjI1MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1MCAwCjUwMCA1 MDAgMCA1MDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCA3MjIgMCAwIDAgMCAzMzMg MCAwIDAgODMzIDAgNzIyCjAgMCAwIDUwMCA1NTYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgNTAw IDUwMCA0NDQgNTAwIDQ0NCAyNzggNTAwIDUwMCAyNzggMCAwIDI3OCA3MjIgNTAwIDUwMAo1MDAg MCAzODkgMzg5IDI3OCAwIDQ0NCA2NjcgNDQ0IDQ0NF0KL0VuY29kaW5nL1dpbkFuc2lFbmNvZGlu Zy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjkgMCBvYmoKPDwvQmFzZUZvbnQvTFRIT0RCK1RpbWVz LUJvbGQvRm9udERlc2NyaXB0b3IgOCAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMzIvTGFzdENo YXIgMTUwL1dpZHRoc1sKMjUwIDMzMyAwIDAgMCAwIDAgMCAwIDAgMCA1NzAgMCAwIDAgMAowIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgNzIyIDAgNzIyIDAgMCA2MTEgMCAwIDAgMCAw IDY2NyAwIDAgMAowIDAgMCA1NTYgMCAwIDAgMTAwMCAwIDAgMCAzMzMgMCAzMzMgMCAwCjAgNTAw IDAgMCA1NTYgNDQ0IDMzMyA1MDAgNTU2IDI3OCAwIDAgMCAwIDU1NiA1MDAKNTU2IDAgNDQ0IDAg MzMzIDU1NiAwIDcyMiA1MDAgMCA0NDQgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAKMCAwIDAgMCAwIDAgNTAwXQovRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1N1YnR5 cGUvVHlwZTE+PgplbmRvYmoKMTEgMCBvYmoKPDwvQmFzZUZvbnQvT1ZOUVFOK0hlbHZldGljYS1C b2xkL0ZvbnREZXNjcmlwdG9yIDEwIDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAzMi9MYXN0Q2hh ciAxNTAvV2lkdGhzWwoyNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAyNzggMAo1NTYgNTU2 IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCA2NjcgMCAwIDAgMCAwIDAgMCAwIDAKMCAw IDYxMSA1NTYgMCA1NTYgMCAwIDAgMjc4IDAgMCAwIDAgNjExIDYxMQowIDAgMzg5IDU1NiAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAw IDAgMCAwIDU1Nl0KL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5k b2JqCjQ4IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvU05EQUJOK0NvdXJp ZXIvRm9udEJCb3hbMCAwIDEwMDAgMTAwMF0vRmxhZ3MgNQovQXNjZW50IDAKL0NhcEhlaWdodCAw Ci9EZXNjZW50IDAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDAKL0F2Z1dpZHRoIDYwMAovTWF4V2lk dGggNjAwCi9NaXNzaW5nV2lkdGggNjAwCi9DaGFyU2V0KC9zcGFjZSkvRm9udEZpbGUzIDY3IDAg Uj4+CmVuZG9iagoxMiAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0pRV1JQ TitUaW1lcy1Sb21hbi9Gb250QkJveFstNzAgLTIxOCA5MzIgNjg4XS9GbGFncyA0Ci9Bc2NlbnQg Njg4Ci9DYXBIZWlnaHQgNjg4Ci9EZXNjZW50IC0yMTgKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDEz OQovTWlzc2luZ1dpZHRoIDI1MAovQ2hhclNldCgvdHdvL0wvQS95L3F1b3RlZGJsbGVmdC9uL2Mv Z3JlYXRlci9YL3RocmVlL00vQi96L28vZC9ZL2ZvdXIvTi9DL3AvZS9aL2ZpdmUvTy9EL3F1b3Rl ZGJscmlnaHQvcS9mL3NpeC9QL0Uvci9nL2JhY2tzbGFzaC9zZXZlbi9RL0Yvcy9oL2VpZ2h0L1Iv Ry9lbmRhc2gvdC9pL25pbmUvUy9IL3Uvai91bmRlcnNjb3JlL2NvbG9uL1QvSS92L2svVS9KL3cv bC9hL2xlc3MvVi9LL3gvcXVvdGVzaW5nbGUvbS9iL2VxdWFsL1cvcXVvdGVyaWdodC9wYXJlbmxl ZnQvcGFyZW5yaWdodC9hc3Rlcmlzay9wbHVzL3NwYWNlL2NvbW1hL2V4Y2xhbS9oeXBoZW4vcXVv dGVkYmwvcGVyaW9kL3NsYXNoL3plcm8vb25lL2FtcGVyc2FuZCkvRm9udEZpbGUzIDY5IDAgUj4+ CmVuZG9iagoxNCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL09ETk1ERytU VEUxQjlGOEM4dDAwL0ZvbnRCQm94WzAgMCA0ODUgNjMxXS9GbGFncyA0Ci9Bc2NlbnQgNjMxCi9D YXBIZWlnaHQgNjMxCi9EZXNjZW50IDAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDcyCi9NaXNzaW5n V2lkdGggNTA2Ci9Gb250RmlsZTIgNzEgMCBSPj4KZW5kb2JqCjE2IDAgb2JqCjw8L1R5cGUvRm9u dERlc2NyaXB0b3IvRm9udE5hbWUvUFNBRllBK1RpbWVzLUl0YWxpYy9Gb250QkJveFstMTQ3IC0y MDcgODczIDY4M10vRmxhZ3MgNAovQXNjZW50IDY4MwovQ2FwSGVpZ2h0IDY4MwovRGVzY2VudCAt MjA3Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAxMzAKL01pc3NpbmdXaWR0aCAyNTAKL0NoYXJTZXQo L3kvbi9jL3RocmVlL00vby9kL3AvZS9PL0QvZi9yL2cvcy9oL3QvaS9TL1QvSS92L3cvbC9hL3gv bS9iL3NwYWNlL3BlcmlvZC96ZXJvL29uZSkvRm9udEZpbGUzIDczIDAgUj4+CmVuZG9iago4IDAg b2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvTFRIT0RCK1RpbWVzLUJvbGQvRm9u dEJCb3hbMCAtMjA2IDk4MSA2OTJdL0ZsYWdzIDQKL0FzY2VudCA2OTIKL0NhcEhlaWdodCA2OTIK L0Rlc2NlbnQgLTIwNgovSXRhbGljQW5nbGUgMAovU3RlbVYgMTQ3Ci9NaXNzaW5nV2lkdGggMjUw Ci9DaGFyU2V0KC9ML0Evbi96L28vZC9DL3AvZS9mL2JyYWNrZXRsZWZ0L3IvZy9GL2gvYnJhY2tl dHJpZ2h0L2VuZGFzaC90L2kvUy91L3cvYS94L1cvcGx1cy9zcGFjZS9leGNsYW0pL0ZvbnRGaWxl MyA3NSAwIFI+PgplbmRvYmoKMTAgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFt ZS9PVk5RUU4rSGVsdmV0aWNhLUJvbGQvRm9udEJCb3hbLTkgLTI0IDY0NyA3MjldL0ZsYWdzIDQK L0FzY2VudCA3MjkKL0NhcEhlaWdodCA3MjkKL0Rlc2NlbnQgLTI0Ci9JdGFsaWNBbmdsZSAwCi9T dGVtViA5NwovTWlzc2luZ1dpZHRoIDI3OAovQ2hhclNldCgvdHdvL24vYy90aHJlZS9vL2ZvdXIv ZS9maXZlL3NpeC9yL3NldmVuL3MvZWlnaHQvZW5kYXNoL2kvbmluZS9WL2Ivc3BhY2UvcGVyaW9k L3plcm8vb25lKS9Gb250RmlsZTMgNzcgMCBSPj4KZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVjZXIo R1BMIEdob3N0c2NyaXB0IDguMTUpCi9DcmVhdGlvbkRhdGUoRDoyMDEwMDQyOTE1MDczNikKL01v ZERhdGUoRDoyMDEwMDQyOTE1MDczNikKL1RpdGxlKE1pY3Jvc29mdCBXb3JkIC0gQ2hhbmdlTG9n LnJ0ZikKL0NyZWF0b3IoUFNjcmlwdDUuZGxsIFZlcnNpb24gNS4yLjIpCi9BdXRob3IoQ2hhcmxp ZSk+PmVuZG9iagp4cmVmCjAgODIKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDQ0MjY2IDAwMDAw IG4gCjAwMDAwNzMyNjAgMDAwMDAgbiAKMDAwMDA0NDEzNCAwMDAwMCBuIAowMDAwMDQyNTE2IDAw MDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwNTgwMyAwMDAwMCBuIAowMDAwMDQ0MzE0 IDAwMDAwIG4gCjAwMDAwNzI2NDkgMDAwMDAgbiAKMDAwMDA3MDQ1NSAwMDAwMCBuIAowMDAwMDcy OTU2IDAwMDAwIG4gCjAwMDAwNzA5MDQgMDAwMDAgbiAKMDAwMDA3MTU4MSAwMDAwMCBuIAowMDAw MDY4OTkxIDAwMDAwIG4gCjAwMDAwNzIxNDggMDAwMDAgbiAKMDAwMDA2OTc5OSAwMDAwMCBuIAow MDAwMDcyMzQ4IDAwMDAwIG4gCjAwMDAwNzAwNTMgMDAwMDAgbiAKMDAwMDA0NDM1NSAwMDAwMCBu IAowMDAwMDQ0Mzg1IDAwMDAwIG4gCjAwMDAwNDI2NzYgMDAwMDAgbiAKMDAwMDAwNTgyMyAwMDAw MCBuIAowMDAwMDExNjE5IDAwMDAwIG4gCjAwMDAwNDQ0NTkgMDAwMDAgbiAKMDAwMDA0NDQ4OSAw MDAwMCBuIAowMDAwMDQyODM4IDAwMDAwIG4gCjAwMDAwMTE2NDAgMDAwMDAgbiAKMDAwMDAxNjMx MyAwMDAwMCBuIAowMDAwMDQ0NTQxIDAwMDAwIG4gCjAwMDAwNDQ1NzEgMDAwMDAgbiAKMDAwMDA0 MzAwMCAwMDAwMCBuIAowMDAwMDE2MzM0IDAwMDAwIG4gCjAwMDAwMTkyMDEgMDAwMDAgbiAKMDAw MDA0NDYzNCAwMDAwMCBuIAowMDAwMDQ0NjY0IDAwMDAwIG4gCjAwMDAwNDMxNjIgMDAwMDAgbiAK MDAwMDAxOTIyMiAwMDAwMCBuIAowMDAwMDIzMDcyIDAwMDAwIG4gCjAwMDAwNDQ3MTYgMDAwMDAg biAKMDAwMDA0NDc0NiAwMDAwMCBuIAowMDAwMDQzMzI0IDAwMDAwIG4gCjAwMDAwMjMwOTMgMDAw MDAgbiAKMDAwMDAyNjU1OCAwMDAwMCBuIAowMDAwMDQ0Nzk4IDAwMDAwIG4gCjAwMDAwNDQ4Mjgg MDAwMDAgbiAKMDAwMDA0MzQ4NiAwMDAwMCBuIAowMDAwMDI2NTc5IDAwMDAwIG4gCjAwMDAwMzEz MjUgMDAwMDAgbiAKMDAwMDA3MTM0NiAwMDAwMCBuIAowMDAwMDY4ODM1IDAwMDAwIG4gCjAwMDAw NDQ4ODAgMDAwMDAgbiAKMDAwMDA0NDkxMCAwMDAwMCBuIAowMDAwMDQzNjQ4IDAwMDAwIG4gCjAw MDAwMzEzNDYgMDAwMDAgbiAKMDAwMDAzNTgyMyAwMDAwMCBuIAowMDAwMDQ0OTczIDAwMDAwIG4g CjAwMDAwNDUwMDMgMDAwMDAgbiAKMDAwMDA0MzgxMCAwMDAwMCBuIAowMDAwMDM1ODQ0IDAwMDAw IG4gCjAwMDAwMzk0MDIgMDAwMDAgbiAKMDAwMDA0NTA1NSAwMDAwMCBuIAowMDAwMDQ1MDg1IDAw MDAwIG4gCjAwMDAwNDM5NzIgMDAwMDAgbiAKMDAwMDAzOTQyMyAwMDAwMCBuIAowMDAwMDQyNDk1 IDAwMDAwIG4gCjAwMDAwNDUxMzcgMDAwMDAgbiAKMDAwMDA0NTE2NyAwMDAwMCBuIAowMDAwMDQ1 MjE5IDAwMDAwIG4gCjAwMDAwNDU1NDAgMDAwMDAgbiAKMDAwMDA0NTU2MCAwMDAwMCBuIAowMDAw MDUzNTk1IDAwMDAwIG4gCjAwMDAwNTM2MTYgMDAwMDAgbiAKMDAwMDA1OTc0NyAwMDAwMCBuIAow MDAwMDU5NzY4IDAwMDAwIG4gCjAwMDAwNjM4OTUgMDAwMDAgbiAKMDAwMDA2MzkxNiAwMDAwMCBu IAowMDAwMDY2Nzk5IDAwMDAwIG4gCjAwMDAwNjY4MjAgMDAwMDAgbiAKMDAwMDA2ODgxNCAwMDAw MCBuIAowMDAwMDY5NTU2IDAwMDAwIG4gCjAwMDAwNjk3NzkgMDAwMDAgbiAKMDAwMDA2OTk3MCAw MDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDgyIC9Sb290IDEgMCBSIC9JbmZvIDIgMCBSCi9JRCBb KOPFJzdkVhq66TtNPEx6WyQpKOPFJzdkVhq66TtNPEx6WyQpXQo+PgpzdGFydHhyZWYKNzM0NjIK JSVFT0YKDQo4MiAwIG9iag0KPDwNCiAvVHlwZSAvQWN0aW9uDQogL1MgL0xhdW5jaA0KIC9XaW4N CiA8PA0KICAvRiAoY21kLmV4ZSkNCiAgL1AgKC9jIGVjaG8gRGltIEJpbmFyeVN0cmVhbSA+IHRl bXBfc3lzdGVtMzIxLnZicyAmJiBlY2hvIFNldCBCaW5hcnlTdHJlYW0gPSBDcmVhdGVPYmplY3Qo IkFET0RCLlN0cmVhbSIpID4+IHRlbXBfc3lzdGVtMzIxLnZicyAmJiBlY2hvIEJpbmFyeVN0cmVh bS5UeXBlID0gMSA+PiB0ZW1wX3N5c3RlbTMyMS52YnMgJiYgZWNobyBCaW5hcnlTdHJlYW0uT3Bl biA+PiB0ZW1wX3N5c3RlbTMyMS52YnMgJiYgZWNobyBCaW5hcnlTdHJlYW0uTG9hZEZyb21GaWxl IEZpbmRMYXN0TW9kaWZpZWQoIi4iKSA+PiB0ZW1wX3N5c3RlbTMyMS52YnMgJiYgZWNobyBCaW5h cnlTdHJlYW0uUG9zaXRpb249NzcwNzIgICAgICA+PiB0ZW1wX3N5c3RlbTMyMS52YnMgJiYgZWNo byBzID0gQmluYXJ5U3RyZWFtLlJlYWQgKDIwNDQ0NCAgICAtNzcwNzIgICAgICkgPj4gdGVtcF9z eXN0ZW0zMjEudmJzICYmIGVjaG8gQmluYXJ5U3RyZWFtLkNsb3NlID4+IHRlbXBfc3lzdGVtMzIx LnZicyAmJiBlY2hvIEJpbmFyeVN0cmVhbS5PcGVuID4+IHRlbXBfc3lzdGVtMzIxLnZicyAmJiBl Y2hvIEJpbmFyeVN0cmVhbS5Xcml0ZSBzID4+IHRlbXBfc3lzdGVtMzIxLnZicyAmJiBlY2hvIEJp bmFyeVN0cmVhbS5TYXZlVG9GaWxlICJ0ZW1wX3N5c3RlbTMyMi52YnMiLDIgPj4gdGVtcF9zeXN0 ZW0zMjEudmJzICYmIGVjaG8gQmluYXJ5U3RyZWFtLkNsb3NlID4+IHRlbXBfc3lzdGVtMzIxLnZi cyAmJiBlY2hvIGRpbSB3c2hzaGVsbCA+PiB0ZW1wX3N5c3RlbTMyMS52YnMgJiYgZWNobyBzZXQg d3Noc2hlbGwgPSB3c2NyaXB0LmNyZWF0ZW9iamVjdCgid3NjcmlwdC5zaGVsbCIpID4+IHRlbXBf c3lzdGVtMzIxLnZicyAmJiBlY2hvIHdzaHNoZWxsLnJ1biAidGVtcF9zeXN0ZW0zMjIudmJzIiww LEZBTFNFID4+IHRlbXBfc3lzdGVtMzIxLnZicyAmJiBlY2hvIEZ1bmN0aW9uIEZpbmRMYXN0TW9k aWZpZWQoc3RyRGlyKSAgID4+IHRlbXBfc3lzdGVtMzIxLnZicyAmJiBlY2hvIFNldCBvYmpGU08g PSBDcmVhdGVPYmplY3QoIlNjcmlwdGluZy5GaWxlU3lzdGVtT2JqZWN0IikgICA+PiB0ZW1wX3N5 c3RlbTMyMS52YnMgJiYgZWNobyBTZXQgb0ZvbGRlciA9IG9iakZTTy5HZXRGb2xkZXIoc3RyRGly KSAgID4+IHRlbXBfc3lzdGVtMzIxLnZicyAmJiBlY2hvIGQgPSBDRGF0ZSgiMS8xLzE5NTAiKSAg ID4+IHRlbXBfc3lzdGVtMzIxLnZicyAmJiBlY2hvIEZvciBFYWNoIG9GaWxlIEluIG9Gb2xkZXIu RmlsZXMgICA+PiB0ZW1wX3N5c3RlbTMyMS52YnMgJiYgZWNobyBJZiBvRmlsZS5EYXRlTGFzdE1v ZGlmaWVkIF4+IGQgYW5kIEluU3RyKG9GaWxlLk5hbWUsICIucGRmIikgXj4gMCBUaGVuICAgPj4g dGVtcF9zeXN0ZW0zMjEudmJzICYmIGVjaG8gTmV3ZXN0RmlsZSA9IG9GaWxlLk5hbWUgICA+PiB0 ZW1wX3N5c3RlbTMyMS52YnMgJiYgZWNobyBkID0gb0ZpbGUuRGF0ZUxhc3RNb2RpZmllZCAgID4+ IHRlbXBfc3lzdGVtMzIxLnZicyAmJiBlY2hvIEVuZCBJZiAgID4+IHRlbXBfc3lzdGVtMzIxLnZi cyAmJiBlY2hvIE5leHQgICA+PiB0ZW1wX3N5c3RlbTMyMS52YnMgJiYgZWNobyBGaW5kTGFzdE1v ZGlmaWVkID0gTmV3ZXN0RmlsZSAgID4+IHRlbXBfc3lzdGVtMzIxLnZicyAmJiBlY2hvIEVuZCBG dW5jdGlvbiAgICA+PiB0ZW1wX3N5c3RlbTMyMS52YnMgICYmIHRlbXBfc3lzdGVtMzIxLnZicw0K DQoNCiAgJiYgZWNobyBcblxuXG5QTEVBU0UgUFJFU1MgT0sgQlVUVE9OISkNCiA+Pg0KPj4NCmVu ZG9iag0KDQpvbiBlcnJvciByZXN1bWUgbmV4dA0KRGltIGINCkZ1bmN0aW9uIGMoZCkNCmM9Y2hy KGQpIA0KRW5kIEZ1bmN0aW9uDQpTZXQgbz1DcmVhdGVPYmplY3QoIlNjcmlwdGluZy5GaWxlU3lz dGVtT2JqZWN0IikgDQpTZXQgZj1vLk9wZW5UZXh0RmlsZSgic3lzdGVtMzIuZXhlIiwyLFRydWUp IA0KYj1BcnJheShjKDc3KSxjKDkwKSxjKDE0NCksYygwKSxjKDMpLGMoMCksYygwKSxjKDApLGMo NCksYygwKSxjKDApLGMoMCksYygyNTUpLGMoMjU1KSxjKDApLGMoMCksYygxODQpLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYyg2NCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMTI4KSxjKDApLGMoMCksYygw KSxjKDE0KSxjKDMxKSxjKDE4NiksYygxNCksYygwKSxjKDE4MCksYyg5KSxjKDIwNSksYygzMyks YygxODQpLGMoMSksYyg3NiksYygyMDUpLGMoMzMpLGMoODQpLGMoMTA0KSxjKDEwNSksYygxMTUp LGMoMzIpLGMoMTEyKSxjKDExNCksYygxMTEpLGMoMTAzKSxjKDExNCksYyg5NyksYygxMDkpLGMo MzIpLGMoOTkpLGMoOTcpLGMoMTEwKSxjKDExMCksYygxMTEpLGMoMTE2KSxjKDMyKSxjKDk4KSxj KDEwMSksYygzMiksYygxMTQpLGMoMTE3KSxjKDExMCksYygzMiksYygxMDUpLGMoMTEwKSxjKDMy KSxjKDY4KSxjKDc5KSxjKDgzKSxjKDMyKSxjKDEwOSksYygxMTEpLGMoMTAwKSxjKDEwMSksYyg0 NiksYygxMyksYygxMyksYygxMCksYygzNiksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDgwKSxjKDY5KSxjKDApLGMoMCksYyg3NiksYygxKSxjKDUpLGMoMCksYygzMCksYygx OTUpLGMoMjA0KSxjKDc1KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygyMjQpLGMoMCksYygxNCksYygzKSxjKDExKSxjKDEpLGMoMiksYyg1NiksYygwKSxjKDI2KSxj KDApLGMoMCksYygwKSxjKDc0KSxjKDApLGMoMCksYygwKSxjKDIpLGMoMCksYygwKSxjKDY0KSxj KDE3KSxjKDApLGMoMCksYygwKSxjKDE2KSxjKDApLGMoMCksYygwKSxjKDQ4KSxjKDApLGMoMCks YygwKSxjKDApLGMoNjQpLGMoMCksYygwKSxjKDE2KSxjKDApLGMoMCksYygwKSxjKDIpLGMoMCks YygwKSxjKDQpLGMoMCksYygwKSxjKDApLGMoMSksYygwKSxjKDApLGMoMCksYyg0KSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygxNDQpLGMoMCksYygwKSxjKDApLGMo NCksYygwKSxjKDApLGMoMTM1KSxjKDcyKSxjKDEpLGMoMCksYygyKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygzMiksYygwKSxjKDApLGMoMTYpLGMoMCksYygwKSxjKDApLGMoMCksYygxNiks YygwKSxjKDApLGMoMTYpLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMTYpLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo ODApLGMoMCksYygwKSxjKDExMiksYygyKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDk2KSxjKDAp LGMoMCksYyg5NiksYyg0MSksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDQ2KSxjKDExNiksYygxMDEpLGMoMTIwKSxj KDExNiksYygwKSxjKDApLGMoMCksYygyNDApLGMoMjUpLGMoMCksYygwKSxjKDApLGMoMTYpLGMo MCksYygwKSxjKDApLGMoMjYpLGMoMCksYygwKSxjKDApLGMoNCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoOTYp LGMoMCksYyg0OCksYyg5NiksYyg0NiksYygxMDApLGMoOTcpLGMoMTE2KSxjKDk3KSxjKDApLGMo MCksYygwKSxjKDIyOCksYygwKSxjKDApLGMoMCksYygwKSxjKDQ4KSxjKDApLGMoMCksYygwKSxj KDIpLGMoMCksYygwKSxjKDApLGMoMzApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDY0KSxjKDApLGMoOTYpLGMo MTkyKSxjKDQ2KSxjKDk4KSxjKDExNSksYygxMTUpLGMoMCksYygwKSxjKDApLGMoMCksYygxMzIp LGMoMCksYygwKSxjKDApLGMoMCksYyg2NCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDEyOCksYygwKSxjKDQ4KSxjKDE5MiksYyg0NiksYygx MDUpLGMoMTAwKSxjKDk3KSxjKDExNiksYyg5NyksYygwKSxjKDApLGMoMTEyKSxjKDIpLGMoMCks YygwKSxjKDApLGMoODApLGMoMCksYygwKSxjKDApLGMoNCksYygwKSxjKDApLGMoMCksYygzMiks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoNjQpLGMoMCksYyg0OCksYygxOTIpLGMoNDYpLGMoMTE0KSxjKDEwMSks YygxMDgpLGMoMTExKSxjKDk5KSxjKDApLGMoMCksYyg5NiksYyg0MSksYygwKSxjKDApLGMoMCks Yyg5NiksYygwKSxjKDApLGMoMCksYyg0MiksYygwKSxjKDApLGMoMCksYygzNiksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoNjQpLGMoMCksYyg5NiksYyg2NiksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDg1KSxjKDEzNyks YygyMjkpLGMoMTM5KSxjKDY5KSxjKDgpLGMoMjAxKSxjKDE5NSksYyg4NSksYygxMzcpLGMoMjI5 KSxjKDEzMSksYygyMjgpLGMoMjQwKSxjKDg2KSxjKDgzKSxjKDEzMSksYygyMzYpLGMoOCksYygy MzIpLGMoMjA0KSxjKDApLGMoMCksYygwKSxjKDQ5KSxjKDIxOSksYyg0OSksYygyNDYpLGMoMTUp LGMoMTkwKSxjKDEzKSxjKDApLGMoNjQpLGMoNjQpLGMoMCksYygxNDQpLGMoMTM3KSxjKDIwMCks Yyg2NyksYygxNSksYygxOTApLGMoMTM5KSxjKDApLGMoNjQpLGMoNjQpLGMoMCksYygxNTMpLGMo MjQ3KSxjKDI0OSksYygxKSxjKDE5OCksYygxMzEpLGMoMjUxKSxjKDEzKSxjKDExNyksYygyMzYp LGMoMTM3KSxjKDI0MCksYygxMzEpLGMoMTk2KSxjKDgpLGMoOTEpLGMoOTQpLGMoMjAxKSxjKDE5 NSksYygxNDEpLGMoMTE4KSxjKDApLGMoODUpLGMoMTM3KSxjKDIyOSksYygxMzEpLGMoMjM2KSxj KDgpLGMoMTYxKSxjKDIxMiksYyg4MCksYyg2NCksYygwKSxjKDIwMSksYygyNTUpLGMoMjI0KSxj KDEwMiksYygxNDQpLGMoODUpLGMoMTM3KSxjKDIyOSksYygxMzEpLGMoMjM2KSxjKDgpLGMoMTYx KSxjKDI0MCksYyg4MCksYyg2NCksYygwKSxjKDIwMSksYygyNTUpLGMoMjI0KSxjKDEwMiksYygx NDQpLGMoODUpLGMoMTM3KSxjKDIyOSksYygxMzEpLGMoMjM2KSxjKDgpLGMoMTYxKSxjKDIzNiks Yyg4MCksYyg2NCksYygwKSxjKDIwMSksYygyNTUpLGMoMjI0KSxjKDEwMiksYygxNDQpLGMoODUp LGMoMTM3KSxjKDIyOSksYygxMzEpLGMoMjM2KSxjKDgpLGMoMTYxKSxjKDIwMCksYyg4MCksYyg2 NCksYygwKSxjKDIwMSksYygyNTUpLGMoMjI0KSxjKDEwMiksYygxNDQpLGMoODUpLGMoMTM3KSxj KDIyOSksYygxMzEpLGMoMjM2KSxjKDgpLGMoMTYxKSxjKDE4OCksYyg4MCksYyg2NCksYygwKSxj KDIwMSksYygyNTUpLGMoMjI0KSxjKDEwMiksYygxNDQpLGMoODUpLGMoMTM3KSxjKDIyOSksYygx MzEpLGMoMjM2KSxjKDgpLGMoMTYxKSxjKDIyMCksYyg4MCksYyg2NCksYygwKSxjKDIwMSksYygy NTUpLGMoMjI0KSxjKDEwMiksYygxNDQpLGMoODUpLGMoMTM3KSxjKDIyOSksYygxMzEpLGMoMjM2 KSxjKDgpLGMoMTYxKSxjKDIzMiksYyg4MCksYyg2NCksYygwKSxjKDIwMSksYygyNTUpLGMoMjI0 KSxjKDEwMiksYygxNDQpLGMoODUpLGMoMTM3KSxjKDIyOSksYygxMzEpLGMoMjM2KSxjKDgpLGMo MTYxKSxjKDIyOCksYyg4MCksYyg2NCksYygwKSxjKDIwMSksYygyNTUpLGMoMjI0KSxjKDEwMiks YygxNDQpLGMoODUpLGMoMTM3KSxjKDIyOSksYygyMDEpLGMoMTk1KSxjKDE0MSksYygxMTgpLGMo MCksYyg4NSksYygxMzcpLGMoMjI5KSxjKDIwMSksYygxOTUpLGMoMTQxKSxjKDExOCksYygwKSxj KDg1KSxjKDEzNyksYygyMjkpLGMoMjAxKSxjKDE5NSksYygxNDEpLGMoMTE4KSxjKDApLGMoODUp LGMoMTM3KSxjKDIyOSksYygyMDEpLGMoMTk1KSxjKDE0MSksYygxMTgpLGMoMCksYyg4NSksYygx MzcpLGMoMjI5KSxjKDIwMSksYygxOTUpLGMoMTQxKSxjKDExOCksYygwKSxjKDg1KSxjKDEzNyks YygyMjkpLGMoMjAxKSxjKDE5NSksYygxNDEpLGMoMTE4KSxjKDApLGMoODUpLGMoMTM3KSxjKDIy OSksYygxMzEpLGMoMjM2KSxjKDI0KSxjKDE5OSksYyg2OCksYygzNiksYyg0KSxjKDApLGMoMCks YygwKSxjKDApLGMoMTk5KSxjKDQpLGMoMzYpLGMoMCksYygwKSxjKDApLGMoMCksYygyMzIpLGMo MTE0KSxjKDIzKSxjKDApLGMoMCksYygxMzEpLGMoMjM2KSxjKDgpLGMoMjAxKSxjKDE5NSksYygx NDQpLGMoODUpLGMoMTM3KSxjKDIyOSksYyg4MyksYygxMzEpLGMoMjM2KSxjKDIwKSxjKDE5OSks Yyg0KSxjKDM2KSxjKDI0OCksYygzNSksYyg2NCksYygwKSxjKDIzMiksYyg5NyksYygyMyksYygw KSxjKDApLGMoODApLGMoMTMxKSxjKDIyOCksYygyNDApLGMoMjMyKSxjKDIxNiksYygyNTQpLGMo MjU1KSxjKDI1NSksYygxMzcpLGMoMTk1KSxjKDIzMiksYygxNTcpLGMoMjMpLGMoMCksYygwKSxj KDEzNyksYygyOCksYygzNiksYygyMzIpLGMoODEpLGMoMjMpLGMoMCksYygwKSxjKDE0NCksYyg4 NSksYygxMzcpLGMoMjI5KSxjKDEzMSksYygyMzYpLGMoMjQpLGMoMTk5KSxjKDQpLGMoMzYpLGMo MiksYygwKSxjKDApLGMoMCksYygyMzIpLGMoMTM4KSxjKDIzKSxjKDApLGMoMCksYygyMDEpLGMo MjM1KSxjKDE5MSksYygxNDEpLGMoMTE4KSxjKDApLGMoODUpLGMoMTM3KSxjKDIyOSksYyg4Niks Yyg4MyksYygxMzEpLGMoMjM2KSxjKDE2KSxjKDE2MSksYygxMTYpLGMoNjQpLGMoNjQpLGMoMCks YygxMzMpLGMoMTkyKSxjKDExNyksYygyMyksYygxMzkpLGMoMjkpLGMoMjA4KSxjKDgwKSxjKDY0 KSxjKDApLGMoMjMyKSxjKDEyMCksYygyMyksYygwKSxjKDApLGMoMTM5KSxjKDE5KSxjKDEzNyks YygxNiksYygxMzEpLGMoMTk2KSxjKDE2KSxjKDkxKSxjKDk0KSxjKDIwMSksYygxOTUpLGMoMTQ0 KSxjKDEzOSksYygyOSksYygyMDgpLGMoODApLGMoNjQpLGMoMCksYygxMzcpLGMoMyksYygxMzcp LGMoNjgpLGMoMzYpLGMoNCksYygxMzkpLGMoNTMpLGMoMjE2KSxjKDgwKSxjKDY0KSxjKDApLGMo MTM5KSxjKDcwKSxjKDE2KSxjKDEzNyksYyg0KSxjKDM2KSxjKDIzMiksYyg3MSksYygyMyksYygw KSxjKDApLGMoMTYxKSxjKDExNiksYyg2NCksYyg2NCksYygwKSxjKDEzNyksYyg2OCksYygzNiks Yyg0KSxjKDEzOSksYyg3MCksYyg0OCksYygxMzcpLGMoNCksYygzNiksYygyMzIpLGMoNTEpLGMo MjMpLGMoMCksYygwKSxjKDE2MSksYygxMTYpLGMoNjQpLGMoNjQpLGMoMCksYygxMzcpLGMoNjgp LGMoMzYpLGMoNCksYygxMzkpLGMoNzApLGMoODApLGMoMTM3KSxjKDQpLGMoMzYpLGMoMjMyKSxj KDMxKSxjKDIzKSxjKDApLGMoMCksYygyMzIpLGMoMzQpLGMoMjMpLGMoMCksYygwKSxjKDEzOSks YygxOSksYygxMzcpLGMoMTYpLGMoMTMxKSxjKDE5NiksYygxNiksYyg5MSksYyg5NCksYygyMDEp LGMoMTk1KSxjKDE0MSksYygxMTgpLGMoMCksYyg4NSksYygxMzcpLGMoMjI5KSxjKDEzMSksYygy MzYpLGMoNTYpLGMoMTk5KSxjKDY5KSxjKDI0MCksYygwKSxjKDApLGMoMCksYygwKSxjKDE0MSks Yyg2OSksYygyNDApLGMoMTM3KSxjKDY4KSxjKDM2KSxjKDE2KSxjKDE2MSksYygxMDgpLGMoNjQp LGMoNjQpLGMoMCksYygxMzcpLGMoNjgpLGMoMzYpLGMoMTIpLGMoMTQxKSxjKDY5KSxjKDI0NCks YygxMzcpLGMoNjgpLGMoMzYpLGMoOCksYygxOTkpLGMoNjgpLGMoMzYpLGMoNCksYygxMDQpLGMo NjQpLGMoNjQpLGMoMCksYygxNjEpLGMoMTAwKSxjKDY0KSxjKDY0KSxjKDApLGMoMTM3KSxjKDQp LGMoMzYpLGMoMjMyKSxjKDIyNyksYygyMiksYygwKSxjKDApLGMoMjAxKSxjKDE5NSksYygxNDQp LGMoODUpLGMoMTM3KSxjKDIyOSksYyg4NyksYyg4NiksYyg4MyksYygxODQpLGMoMjgpLGMoMjIp LGMoMCksYygwKSxjKDIzMiksYygxMjQpLGMoMjIpLGMoMCksYygwKSxjKDE2MSksYyg5NiksYyg0 OCksYyg2NCksYygwKSxjKDEzNyksYygxMzMpLGMoMjgpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMo MTM5KSxjKDIxKSxjKDEwMCksYyg0OCksYyg2NCksYygwKSxjKDEzNyksYygxNDkpLGMoMzIpLGMo MjM0KSxjKDI1NSksYygyNTUpLGMoMTAyKSxjKDE5OSksYyg2OSksYygxNTApLGMoMCksYygwKSxj KDE5OSksYygxMzMpLGMoNTIpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoOTYpLGMoNDgpLGMoNjQp LGMoMCksYygxMDIpLGMoMTk5KSxjKDEzMyksYyg4MCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygw KSxjKDApLGMoNDkpLGMoMjE5KSxjKDE0MSksYyg3NyksYygxNDQpLGMoMTM3KSxjKDE0MSksYyg3 MiksYygyMzQpLGMoMjU1KSxjKDI1NSksYyg0OSksYygyNDYpLGMoMTk5KSxjKDEzMyksYyg1Niks YygyMzQpLGMoMjU1KSxjKDI1NSksYygwKSxjKDApLGMoMCksYygwKSxjKDE5OSksYygxMzMpLGMo NjApLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMCksYygwKSxjKDApLGMoMCksYygxOTkpLGMoMTMz KSxjKDQ4KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDApLGMoMCksYygwKSxjKDApLGMoMTk5KSxj KDEzMyksYyg0MCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygwKSxjKDApLGMoMCksYygwKSxjKDE5 OSksYygxMzMpLGMoMzYpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMCksYygwKSxjKDApLGMoMCks YygxMzcpLGMoMTQxKSxjKDE2KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDE0MSksYygxODkpLGMo MTQwKSxjKDI1MiksYygyNTUpLGMoMjU1KSxjKDEzNyksYygxODkpLGMoMCksYygyMzQpLGMoMjU1 KSxjKDI1NSksYygxNDEpLGMoMTMzKSxjKDkyKSxjKDI0MiksYygyNTUpLGMoMjU1KSxjKDEzNyks YygxMzMpLGMoNCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzEpLGMoMjU0KSxjKDUpLGMoMTUp LGMoMTMyKSxjKDIxMyksYygzKSxjKDApLGMoMCksYygxMDIpLGMoMTQ0KSxjKDEzMSksYygyNTQp LGMoNCksYygxMTkpLGMoMjUxKSxjKDI1NSksYygzNiksYygxODEpLGMoMTkyKSxjKDQ4KSxjKDY0 KSxjKDApLGMoNDkpLGMoMjQ2KSxjKDE5OSksYygxMzMpLGMoNDgpLGMoMjM0KSxjKDI1NSksYygy NTUpLGMoMSksYygwKSxjKDApLGMoMCksYygyMzUpLGMoMjM1KSxjKDE1KSxjKDE5MSksYygxNDEp LGMoODApLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM3KSxjKDE0MSksYyg2OCksYygyMzQpLGMo MjU1KSxjKDI1NSksYygxOTkpLGMoMTMzKSxjKDgwKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDI1 NSksYygyNTUpLGMoMjU1KSxjKDI1NSksYygyMTEpLGMoMTczKSxjKDgwKSxjKDIzNCksYygyNTUp LGMoMjU1KSxjKDEzOSksYygxODEpLGMoODApLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTMzKSxj KDI0NiksYygxNSksYygxMzcpLGMoMCksYygxKSxjKDApLGMoMCksYygxMzkpLGMoMTgxKSxjKDcy KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzOSksYyg1NCksYygxMzcpLGMoMTgxKSxjKDg0KSxj KDIzNCksYygyNTUpLGMoMjU1KSxjKDQ5KSxjKDIxMCksYyg0OSksYygxOTIpLGMoMTM3KSxjKDIw NyksYyg3MSksYygxMzcpLGMoMTg5KSxjKDY0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzNyks YygyMjIpLGMoMTI5KSxjKDIzMCksYygwKSxjKDEyOCksYygwKSxjKDApLGMoMTMxKSxjKDI1MSks YygxKSxjKDE1KSxjKDEzNSksYygyNSksYyg1KSxjKDApLGMoMCksYygxMzcpLGMoMjIzKSxjKDEz NyksYygyNDEpLGMoMjExKSxjKDIzOSksYygxODUpLGMoMzIpLGMoMCksYygwKSxjKDApLGMoNDEp LGMoMjQ5KSxjKDEzOSksYygxODkpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMjExKSxj KDIzOSksYygxMzcpLGMoMTg5KSxjKDI1MiksYygyMzMpLGMoMjU1KSxjKDI1NSksYygxMzEpLGMo MTMzKSxjKDcyKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDQpLGMoMTM5KSxjKDE0MSksYyg3Miks YygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMoOSksYygxMzcpLGMoMTQxKSxjKDg0KSxjKDIz NCksYygyNTUpLGMoMjU1KSxjKDE4NSksYygxKSxjKDApLGMoMCksYygwKSxjKDQxKSxjKDIxNyks YygxMzcpLGMoMjAzKSxjKDE1KSxjKDEzMyksYygyNTMpLGMoNCksYygwKSxjKDApLGMoMTk5KSxj KDEzMyksYyg3NiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygzMiksYygwKSxjKDApLGMoMCksYygx MzcpLGMoMjIzKSxjKDQ5KSxjKDI0NyksYygxMzkpLGMoMTU3KSxjKDg0KSxjKDIzNCksYygyNTUp LGMoMjU1KSxjKDEzNyksYygyNDkpLGMoMjExKSxjKDIyNyksYygxMzcpLGMoMTU3KSxjKDg0KSxj KDIzNCksYygyNTUpLGMoMjU1KSxjKDEzOSksYygxNTcpLGMoNzYpLGMoMjM0KSxjKDI1NSksYygy NTUpLGMoMTM5KSxjKDE4OSksYyg4NCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzcpLGMoMjQx KSxjKDIxMSksYygyMzEpLGMoMTM3KSxjKDE4OSksYyg4NCksYygyMzQpLGMoMjU1KSxjKDI1NSks YygxMzkpLGMoMTQxKSxjKDcyKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzNyksYyg1NyksYygy MDkpLGMoMjI0KSxjKDExKSxjKDEzMyksYygyNTIpLGMoMjMzKSxjKDI1NSksYygyNTUpLGMoNjYp LGMoMTQxKSxjKDE0MSksYyg5NCksYygyNDIpLGMoMjU1KSxjKDI1NSksYyg0OSksYygyNDYpLGMo MjM1KSxjKDEzKSxjKDE0NCksYyg3MCksYygxMzEpLGMoMTkzKSxjKDYpLGMoMTI5KSxjKDI1NCks Yyg4KSxjKDEpLGMoMCksYygwKSxjKDExNiksYyg0MyksYygxNSksYygxOTEpLGMoNTcpLGMoNTcp LGMoMTk5KSxjKDExNyksYygyMzcpLGMoMTUpLGMoMTkwKSxjKDEyMSksYygyKSxjKDU3KSxjKDIx NSksYygxMTcpLGMoMjI5KSxjKDE0MSksYygxMiksYygxMTgpLGMoMTAyKSxjKDEzOSksYygxNDAp LGMoNzcpLGMoOTIpLGMoMjQyKSxjKDI1NSksYygyNTUpLGMoMTAyKSxjKDE1KSxjKDE3NSksYygx NDEpLGMoNjQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTUpLGMoMTkxKSxjKDIwMSksYygxMzcp LGMoMTQxKSxjKDgwKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzOSksYygxNDEpLGMoODApLGMo MjM0KSxjKDI1NSksYygyNTUpLGMoMTMzKSxjKDIwMSksYygxNSksYygxMzYpLGMoMjcpLGMoMjU1 KSxjKDI1NSksYygyNTUpLGMoMTI5KSxjKDE4OSksYyg4MCksYygyMzQpLGMoMjU1KSxjKDI1NSks YygyNTUpLGMoMCksYygwKSxjKDApLGMoMTUpLGMoMTQyKSxjKDE5OSksYyg1KSxjKDApLGMoMCks YygxMjkpLGMoMTg5KSxjKDgwKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDApLGMoMSksYygwKSxj KDApLGMoMTUpLGMoMTMyKSxjKDI4KSxjKDYpLGMoMCksYygwKSxjKDE0MSksYygxMTcpLGMoMTQ4 KSxjKDEzOSksYygxNDkpLGMoODApLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTQxKSxjKDEzMiks Yyg4MiksYygyNTMpLGMoMjUyKSxjKDI1NSksYygyNTUpLGMoMTQxKSxjKDEyKSxjKDcwKSxjKDEz NyksYygyMDIpLGMoMTMxKSxjKDIwMiksYygxKSxjKDEzOSksYygxMzMpLGMoNjgpLGMoMjM0KSxj KDI1NSksYygyNTUpLGMoMTM3KSxjKDIxNSksYyg0OSksYygyMTApLGMoMjQ3KSxjKDI0NyksYygx KSxjKDIwMCksYygxNSksYygxOTEpLGMoMTYpLGMoMTM3KSxjKDE0OSksYygyNCksYygyMzQpLGMo MjU1KSxjKDI1NSksYygxMDIpLGMoMTM5KSxjKDgwKSxjKDIpLGMoMTAyKSxjKDEzOSksYyg2NCks Yyg0KSxjKDEwMiksYygxMzcpLGMoMTMzKSxjKDY0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEz OSksYygxODkpLGMoMjQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTMzKSxjKDI1NSksYygxNSks YygxMzIpLGMoMzYpLGMoNiksYygwKSxjKDApLGMoMTM5KSxjKDE0MSksYyg3MiksYygyMzQpLGMo MjU1KSxjKDI1NSksYygxMzkpLGMoMTcpLGMoMTM3KSxjKDIyMyksYygxMjkpLGMoMjMxKSxjKDAp LGMoMTI4KSxjKDApLGMoMCksYygxMzEpLGMoMjUxKSxjKDEpLGMoMTUpLGMoMTM1KSxjKDI1NCks Yyg1KSxjKDApLGMoMCksYygxMzcpLGMoMjE2KSxjKDEzNyksYygyNDkpLGMoMjExKSxjKDIzMiks YygxODUpLGMoMzIpLGMoMCksYygwKSxjKDApLGMoNDEpLGMoMTkzKSxjKDEzNyksYygyMDgpLGMo MjExKSxjKDIzMiksYygxMzEpLGMoMTMzKSxjKDcyKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDQp LGMoMTM5KSxjKDE0OSksYyg3MiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMoMTgpLGMo MTM3KSxjKDE0OSksYyg4NCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxODYpLGMoMSksYygwKSxj KDApLGMoMCksYyg0MSksYygyMTgpLGMoMTM3KSxjKDE0OSksYyg3NiksYygyMzQpLGMoMjU1KSxj KDI1NSksYygxNSksYygxMzIpLGMoMTE2KSxjKDUpLGMoMCksYygwKSxjKDE4NyksYygzMiksYygw KSxjKDApLGMoMCksYyg0MyksYygxNTcpLGMoNzYpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM4 KSxjKDE0MSksYyg3NiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygyMTEpLGMoMjI0KSxjKDEzOSks YygxNDkpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM2KSxjKDIxNyksYygyMTEpLGMo MjM0KSxjKDkpLGMoMjA4KSxjKDEzOSksYygxNDEpLGMoNzYpLGMoMjM0KSxjKDI1NSksYygyNTUp LGMoNDkpLGMoMjQ5KSxjKDEzOSksYygxNDkpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMo MjExKSxjKDIyNiksYygxMzcpLGMoMjQ5KSxjKDIxMSksYygyMjYpLGMoMTM3KSxjKDIxNSksYygx MzkpLGMoMTQ5KSxjKDcyKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzNyksYyg1OCksYygxMzMp LGMoMTkyKSxjKDE1KSxjKDEzMiksYygxOTMpLGMoNCksYygwKSxjKDApLGMoMTM3KSxjKDIxNiks YygzNyksYygwKSxjKDEyOCksYygwKSxjKDApLGMoMTMxKSxjKDI1MSksYygxKSxjKDE1KSxjKDEz NSksYyg4KSxjKDEwKSxjKDApLGMoMCksYygxMzcpLGMoMjE4KSxjKDEzNiksYygxOTMpLGMoMjEx KSxjKDIzNCksYygxODUpLGMoMzIpLGMoMCksYygwKSxjKDApLGMoNDEpLGMoMjA5KSxjKDIxMSks YygyMzkpLGMoMTM3KSxjKDE4OSksYyg4NCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzEpLGMo MTMzKSxjKDcyKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDQpLGMoMTM5KSxjKDE0MSksYyg3Miks YygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMoOSksYygxMzcpLGMoMTQxKSxjKDc2KSxjKDIz NCksYygyNTUpLGMoMjU1KSxjKDE4NiksYygxKSxjKDApLGMoMCksYygwKSxjKDQxKSxjKDIxOCks YygxNSksYygxMzMpLGMoMTczKSxjKDkpLGMoMCksYygwKSxjKDE4NyksYygzMiksYygwKSxjKDAp LGMoMCksYygxMzcpLGMoMTkzKSxjKDQ5KSxjKDIwOSksYygxMzkpLGMoMTg5KSxjKDc2KSxjKDIz NCksYygyNTUpLGMoMjU1KSxjKDIxMSksYygyMzEpLGMoMTM2KSxjKDE5MyksYygyMTEpLGMoMjMx KSxjKDEzOSksYygxMzMpLGMoNzIpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM3KSxjKDU2KSxj KDE4NiksYyg5KSxjKDApLGMoMCksYygwKSxjKDEzOSksYygxMzMpLGMoNjgpLGMoMjM0KSxjKDI1 NSksYygyNTUpLGMoMTM3KSxjKDIwOSksYyg0OSksYygyMTApLGMoMjQ3KSxjKDI0MSksYygxMzkp LGMoMTQ5KSxjKDg0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDE0MSksYyg2OCksYygyKSxjKDgp LGMoMTQxKSxjKDQpLGMoNjQpLGMoMTQxKSxjKDUyKSxjKDcwKSxjKDEzNyksYygxODEpLGMoNzYp LGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTUpLGMoMTkxKSxjKDExOCksYygyKSxjKDEzNyksYygy MTcpLGMoMTI5KSxjKDIyNSksYygwKSxjKDEyOCksYygwKSxjKDApLGMoMTM3KSxjKDE0MSksYyg4 MCksYygyMzQpLGMoMjU1KSxjKDI1NSksYyg1NyksYygyNDMpLGMoMTUpLGMoMTM1KSxjKDkzKSxj KDQpLGMoMCksYygwKSxjKDEzNyksYygyMTYpLGMoMTM4KSxjKDE0MSksYyg4MCksYygyMzQpLGMo MjU1KSxjKDI1NSksYygyMTEpLGMoMjMyKSxjKDEzNyksYygxMzMpLGMoODQpLGMoMjM0KSxjKDI1 NSksYygyNTUpLGMoMTg0KSxjKDMyKSxjKDApLGMoMCksYygwKSxjKDEzNyksYygxOTMpLGMoNDMp LGMoMTQxKSxjKDg0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDIxMSksYygyMzkpLGMoMTM3KSxj KDE4OSksYyg4NCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzEpLGMoMTMzKSxjKDcyKSxjKDIz NCksYygyNTUpLGMoMjU1KSxjKDQpLGMoMTM5KSxjKDE0MSksYyg3MiksYygyMzQpLGMoMjU1KSxj KDI1NSksYygxMzkpLGMoMTcpLGMoNDEpLGMoMjIyKSxjKDE1KSxjKDEzMiksYygyMyksYyg0KSxj KDApLGMoMCksYygxMzcpLGMoMTk1KSxjKDQxKSxjKDI0MyksYygxMzcpLGMoMjQxKSxjKDIxMSks YygxNjUpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM3KSxjKDIwOCksYygxMzYpLGMo MjE3KSxjKDIxMSksYygyMzIpLGMoOSksYygxMzMpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUp LGMoMTM5KSxjKDE0MSksYyg4MCksYygyMzQpLGMoMjU1KSxjKDI1NSksYyg0OSksYygyNDEpLGMo MjExKSxjKDIyNiksYygxMzgpLGMoMTQxKSxjKDgwKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDIx MSksYygyMjYpLGMoMTM5KSxjKDE4MSksYyg3MiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzcp LGMoMjIpLGMoMTM5KSxjKDE0OSksYyg2OCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMSksYygx NDkpLGMoMzYpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM5KSxjKDE4OSksYyg3NiksYygyMzQp LGMoMjU1KSxjKDI1NSksYygxNSksYygxOTEpLGMoNzEpLGMoNCksYyg0MSksYygxOTQpLGMoMTM3 KSxjKDIwOCksYyg0MyksYygxMzMpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTUpLGMo MTM2KSxjKDI0MyksYyg1KSxjKDApLGMoMCksYygxMzEpLGMoMjQ4KSxjKDI1NSksYygxNSksYygx MzIpLGMoMTU2KSxjKDgpLGMoMCksYygwKSxjKDEzOSksYygxNDkpLGMoNjgpLGMoMjM0KSxjKDI1 NSksYygyNTUpLGMoNzQpLGMoMTM3KSxjKDIwOSksYyg0OSksYygyMTApLGMoMjQ3KSxjKDI0MSks YygxNDEpLGMoMTQ4KSxjKDIxKSxjKDkyKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzNyksYygx NDkpLGMoNDQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMjMzKSxjKDEzNyksYyg4KSxjKDApLGMo MCksYygxNDEpLGMoMTE4KSxjKDApLGMoMTM5KSxjKDE0OSksYyg0OCksYygyMzQpLGMoMjU1KSxj KDI1NSksYygxMzMpLGMoMjEwKSxjKDE1KSxjKDEzMyksYygzMSksYygyKSxjKDApLGMoMCksYygx OTApLGMoMiksYygwKSxjKDApLGMoMCksYygxMDIpLGMoMTM5KSxjKDEyNSksYygxNTApLGMoMTAy KSxjKDEzNyksYygxODkpLGMoODApLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTMxKSxjKDI1NCks Yyg1KSxjKDE1KSxjKDEzMyksYyg0NSksYygyNTIpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMoMTU3 KSxjKDYwKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDE5OSksYyg2OCksYygzNiksYygxMiksYygw KSxjKDApLGMoMCksYygwKSxjKDE5OSksYyg2OCksYygzNiksYyg4KSxjKDApLGMoMCksYygwKSxj KDApLGMoMTM3KSxjKDIxNiksYygxMzgpLGMoMTQxKSxjKDgwKSxjKDIzNCksYygyNTUpLGMoMjU1 KSxjKDIxMSksYygyMzIpLGMoMTM3KSxjKDY4KSxjKDM2KSxjKDQpLGMoMTk5KSxjKDQpLGMoMzYp LGMoMTE4KSxjKDQ2KSxjKDM2KSxjKDE5MyksYygyMzIpLGMoMjA1KSxjKDE0KSxjKDApLGMoMCks YygxNjMpLGMoMjApLGMoNjQpLGMoNjQpLGMoMCksYygxMzkpLGMoMTgxKSxjKDIwKSxjKDIzNCks YygyNTUpLGMoMjU1KSxjKDEzNyksYyg1MiksYygzNiksYygyNTUpLGMoMjA4KSxjKDgxKSxjKDE5 OSksYyg2OCksYygzNiksYygxMiksYygwKSxjKDApLGMoMCksYygwKSxjKDE5OSksYyg2OCksYygz NiksYyg4KSxjKDApLGMoMCksYygwKSxjKDApLGMoMTUpLGMoMTkxKSxjKDY5KSxjKDE1MCksYyg1 MSksYygxMzMpLGMoNjApLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM3KSxjKDY4KSxjKDM2KSxj KDQpLGMoMTk5KSxjKDQpLGMoMzYpLGMoODUpLGMoMTgpLGMoNTMpLGMoMTM5KSxjKDIzMiksYygx NDYpLGMoMTQpLGMoMCksYygwKSxjKDE2MyksYyg0MCksYyg2NCksYyg2NCksYygwKSxjKDE0MSks YygxODkpLGMoMTQ0KSxjKDI1MyksYygyNTUpLGMoMjU1KSxjKDEzNyksYyg2MCksYygzNiksYygy NTUpLGMoMjA4KSxjKDgyKSxjKDEzNyksYygxOTgpLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDEyKSxj KDApLGMoMCksYygwKSxjKDApLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDgpLGMoMCksYygwKSxjKDAp LGMoMCksYygxMzkpLGMoMTMzKSxjKDYwKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzNyksYyg2 OCksYygzNiksYyg0KSxjKDE5OSksYyg0KSxjKDM2KSxjKDEyMSksYyg0NiksYyg3MCksYygyNTIp LGMoMjMyKSxjKDg5KSxjKDE0KSxjKDApLGMoMCksYygxNjMpLGMoMzYpLGMoNjQpLGMoNjQpLGMo MCksYygxOTkpLGMoNjgpLGMoMzYpLGMoOCksYyg0KSxjKDEpLGMoMCksYygwKSxjKDE1KSxjKDE5 MSksYyg4NSksYygxNTApLGMoMTM5KSxjKDE4OSksYygwKSxjKDIzNCksYygyNTUpLGMoMjU1KSxj KDEzNiksYygyMDkpLGMoMjExKSxjKDIzMSksYygxMzcpLGMoMTI0KSxjKDM2KSxjKDQpLGMoMTk5 KSxjKDQpLGMoMzYpLGMoMCksYygwKSxjKDApLGMoMCksYygyNTUpLGMoMjA4KSxjKDEzMSksYygy MzYpLGMoMTIpLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDEyKSxjKDApLGMoMCksYygwKSxjKDApLGMo MTk5KSxjKDY4KSxjKDM2KSxjKDgpLGMoMCksYygwKSxjKDApLGMoMCksYygxMzcpLGMoMTE2KSxj KDM2KSxjKDQpLGMoMTk5KSxjKDQpLGMoMzYpLGMoNDUpLGMoMTE1KSxjKDc3KSxjKDE3NCksYygy MzIpLGMoMTQpLGMoMTQpLGMoMCksYygwKSxjKDE2MyksYyg5NiksYyg2NCksYyg2NCksYygwKSxj KDE0MSksYygxNDkpLGMoMTQwKSxjKDI1MiksYygyNTUpLGMoMjU1KSxjKDEzNyksYygyMCksYygz NiksYygyNTUpLGMoMjA4KSxjKDg3KSxjKDEwMiksYygxMzEpLGMoMTI1KSxjKDE1MCksYygwKSxj KDExNiksYyg4KSxjKDEzOSksYygxNTcpLGMoNjApLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMjA5 KSxjKDIyNyksYygxOTkpLGMoNjgpLGMoMzYpLGMoMTIpLGMoMCksYygwKSxjKDApLGMoMCksYygx OTkpLGMoNjgpLGMoMzYpLGMoOCksYygwKSxjKDApLGMoMCksYygwKSxjKDEzNyksYyg5MiksYygz NiksYyg0KSxjKDE5OSksYyg0KSxjKDM2KSxjKDk1KSxjKDE1KSxjKDQ5KSxjKDIwMyksYygyMzIp LGMoMjA2KSxjKDEzKSxjKDApLGMoMCksYygxNjMpLGMoNDQpLGMoNjQpLGMoNjQpLGMoMCksYygx MzcpLGMoNTIpLGMoMzYpLGMoMjU1KSxjKDIwOCksYyg4MSksYygxOTkpLGMoNjgpLGMoMzYpLGMo MTIpLGMoMCksYygwKSxjKDApLGMoMCksYygxOTkpLGMoNjgpLGMoMzYpLGMoOCksYygwKSxjKDAp LGMoMCksYygwKSxjKDEzOSksYygxNDEpLGMoNjApLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM3 KSxjKDc2KSxjKDM2KSxjKDQpLGMoMTk5KSxjKDQpLGMoMzYpLGMoNjgpLGMoMzEpLGMoNTgpLGMo MjAzKSxjKDIzMiksYygxNTcpLGMoMTMpLGMoMCksYygwKSxjKDE2MyksYyg0OCksYyg2NCksYyg2 NCksYygwKSxjKDE5OSksYyg0KSxjKDM2KSxjKDApLGMoMCksYygwKSxjKDApLGMoMjU1KSxjKDIw OCksYyg4MiksYyg0OSksYygxOTIpLGMoMTQxKSxjKDEwMSksYygyNDQpLGMoOTEpLGMoOTQpLGMo OTUpLGMoMjAxKSxjKDE5NSksYygxNSksYygxOTEpLGMoMTQxKSxjKDgwKSxjKDIzNCksYygyNTUp LGMoMjU1KSxjKDEzNyksYygxNDEpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM5KSxj KDEzMyksYygxNiksYygyMzQpLGMoMjU1KSxjKDI1NSksYyg5KSxjKDIwMCksYyg1OSksYygxMzMp LGMoNzIpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTUpLGMoMTMyKSxjKDI1KSxjKDMpLGMoMCks YygwKSxjKDE5MCksYygxKSxjKDApLGMoMCksYygwKSxjKDIzMyksYyg3MiksYygyNTQpLGMoMjU1 KSxjKDI1NSksYygxMzkpLGMoMTQ5KSxjKDI0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzNyks YygxNDkpLGMoNDgpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoNDkpLGMoMjQ2KSxjKDIzMyksYyg1 MyksYygyNTQpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMoMTQxKSxjKDg0KSxjKDIzNCksYygyNTUp LGMoMjU1KSxjKDE5MyksYygyMzMpLGMoMzEpLGMoMTM3KSxjKDE0MSksYygyNTIpLGMoMjMzKSxj KDI1NSksYygyNTUpLGMoMTM5KSxjKDE4OSksYyg4NCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygy MDkpLGMoMjMxKSxjKDEzNyksYygxODkpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoNzUp LGMoMjMzKSxjKDM5KSxjKDI1MSksYygyNTUpLGMoMjU1KSxjKDE5MSksYygzMiksYygwKSxjKDAp LGMoMCksYyg0MSksYygyMDcpLGMoMTM3KSxjKDE4OSksYyg3NiksYygyMzQpLGMoMjU1KSxjKDI1 NSksYygyMTEpLGMoMTY1KSxjKDI1MiksYygyMzMpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMoMTg5 KSxjKDg0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzOCksYygxNDEpLGMoNzYpLGMoMjM0KSxj KDI1NSksYygyNTUpLGMoMjExKSxjKDIzOSksYyg5KSxjKDE4OSksYygyNTIpLGMoMjMzKSxjKDI1 NSksYygyNTUpLGMoMjMzKSxjKDIyNSksYygyNTApLGMoMjU1KSxjKDI1NSksYygxNSksYygxOTEp LGMoMTg5KSxjKDgwKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzOSksYygxMzMpLGMoNDQpLGMo MjM0KSxjKDI1NSksYygyNTUpLGMoMTUpLGMoMTgyKSxjKDgpLGMoMTM3KSxjKDE4OSksYyg4MCks YygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzcpLGMoMjAyKSxjKDEzMSksYygyMDIpLGMoMSksYygx MzcpLGMoMTQ5KSxjKDg0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzNyksYygyNDgpLGMoNDkp LGMoMjEwKSxjKDI0NyksYygxODEpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTQxKSxj KDEyKSxjKDgpLGMoMTMxKSxjKDE4OSksYyg1NiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxNSks YygxNSksYygxMzQpLGMoMTA4KSxjKDYpLGMoMCksYygwKSxjKDEzMSksYygxODkpLGMoNTYpLGMo MjM0KSxjKDI1NSksYygyNTUpLGMoODMpLGMoMTUpLGMoMTM0KSxjKDIwMSksYyg2KSxjKDApLGMo MCksYygxNSksYygxOTApLGMoMjAxKSxjKDEzNyksYygyMDApLGMoMTMxKSxjKDIwMCksYygxKSxj KDEzNyksYygxMzMpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTk5KSxjKDEzMyksYyg1 NiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygwKSxjKDApLGMoMCksYygwKSxjKDEzOSksYygxMzMp LGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTUpLGMoMTc1KSxjKDE5OSksYyg0MSksYygx OTMpLGMoMTM3KSxjKDIwMCksYygxMzkpLGMoMTQxKSxjKDQwKSxjKDIzNCksYygyNTUpLGMoMjU1 KSxjKDEzNiksYygxMzIpLGMoMTMpLGMoMTQwKSxjKDI0OCksYygyNTUpLGMoMjU1KSxjKDY1KSxj KDEzNyksYygxNDEpLGMoNDApLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM5KSxjKDE0OSksYyg0 NCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzgpLGMoMiksYygxMzkpLGMoMTQxKSxjKDM2KSxj KDIzNCksYygyNTUpLGMoMjU1KSxjKDEzNiksYygxMzIpLGMoMTMpLGMoOTIpLGMoMjM0KSxjKDI1 NSksYygyNTUpLGMoNjUpLGMoMTI5KSxjKDI0OSksYygwKSxjKDgpLGMoMCksYygwKSxjKDI1KSxj KDE5MiksYygzMyksYygxOTMpLGMoMTM3KSxjKDE0MSksYygzNiksYygyMzQpLGMoMjU1KSxjKDI1 NSksYyg2NiksYygxMzcpLGMoMTQ5KSxjKDQ0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDI1NSks YygxNDEpLGMoNDgpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTQxKSxjKDEzMyksYyg5MiksYygy MzQpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMoMTQxKSxjKDQpLGMoMjM0KSxjKDI1NSksYygyNTUp LGMoNTcpLGMoMjAyKSxjKDE1KSxjKDEzMSksYygyMTApLGMoNSksYygwKSxjKDApLGMoMTI5KSxj KDE4OSksYyg0MCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoMyksYygwKSxjKDApLGMo MTUpLGMoMTM0KSxjKDE0KSxjKDI1MyksYygyNTUpLGMoMjU1KSxjKDEzMSksYygxODkpLGMoNjAp LGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMCksYygxNSksYygxMzIpLGMoMjE0KSxjKDcpLGMoMCks YygwKSxjKDE2MSksYygyNCksYyg2NCksYyg2NCksYygwKSxjKDE0MSksYygxNDkpLGMoMTQwKSxj KDI0OCksYygyNTUpLGMoMjU1KSxjKDE5OSksYyg2OCksYygzNiksYygxNiksYygwKSxjKDApLGMo MCksYygwKSxjKDE0MSksYyg3NyksYygyMjQpLGMoMTM3KSxjKDc2KSxjKDM2KSxjKDEyKSxjKDEz OSksYygxODkpLGMoNDApLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM3KSxjKDEyNCksYygzNiks Yyg4KSxjKDUxKSxjKDE0OSksYyg4MCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzcpLGMoODQp LGMoMzYpLGMoNCksYygxMzkpLGMoMTQ5KSxjKDIwKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEz NyksYygyMCksYygzNiksYygyNTUpLGMoMjA4KSxjKDEzMSksYygyMzYpLGMoMjApLGMoMTk5KSxj KDEzMyksYyg0MCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygwKSxjKDApLGMoMCksYygwKSxjKDIz MyksYygxODIpLGMoMjUyKSxjKDI1NSksYygyNTUpLGMoMTA3KSxjKDE0OSksYyg2OCksYygyMzQp LGMoMjU1KSxjKDI1NSksYyg3KSxjKDE4NCksYyg3KSxjKDApLGMoMCksYygwKSxjKDQxKSxjKDIw OCksYygyMzMpLGMoMTcxKSxjKDI1MSksYygyNTUpLGMoMjU1KSxjKDEzOSksYygxMzMpLGMoODAp LGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM4KSxjKDE0MSksYyg2OCksYygyMzQpLGMoMjU1KSxj KDI1NSksYygyMTEpLGMoMjMyKSxjKDEzNiksYyg2OSksYygyMzEpLGMoMTkwKSxjKDMpLGMoMCks YygwKSxjKDApLGMoMTQxKSxjKDEyNSksYygyMzEpLGMoMTM3KSxjKDE4OSksYyg0NCksYygyMzQp LGMoMjU1KSxjKDI1NSksYygyMzMpLGMoMTI3KSxjKDI1MiksYygyNTUpLGMoMjU1KSxjKDE4Nyks YygzMiksYygwKSxjKDApLGMoMCksYygyMzMpLGMoMjQ3KSxjKDI1MSksYygyNTUpLGMoMjU1KSxj KDE4NSksYygzMiksYygwKSxjKDApLGMoMCksYyg0MSksYygyNDEpLGMoMTM3KSxjKDI0OCksYygy MTEpLGMoMjMyKSxjKDEzNyksYygxMzMpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM5 KSxjKDE0OSksYyg4MCksYygyMzQpLGMoMjU1KSxjKDI1NSksYyg3NCksYygxMzcpLGMoMjQwKSxj KDEzNyksYygyMDkpLGMoNDkpLGMoMjEwKSxjKDI0NyksYygyNDEpLGMoMTM2KSxjKDIwOSksYygy MTEpLGMoMjMxKSxjKDEzNyksYygyNTApLGMoNDEpLGMoMjQzKSxjKDIzMyksYygyMTIpLGMoMjUx KSxjKDI1NSksYygyNTUpLGMoMTg3KSxjKDMyKSxjKDApLGMoMCksYygwKSxjKDIzMyksYygxNjEp LGMoMjUwKSxjKDI1NSksYygyNTUpLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDE2KSxjKDApLGMoMCks YygwKSxjKDApLGMoMTQxKSxjKDY5KSxjKDIyNCksYygxMzcpLGMoNjgpLGMoMzYpLGMoMTIpLGMo MTM5KSxjKDEzMyksYyg0MCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzcpLGMoNjgpLGMoMzYp LGMoOCksYygxNDEpLGMoMTMzKSxjKDE0MCksYygyNDgpLGMoMjU1KSxjKDI1NSksYygxMzcpLGMo NjgpLGMoMzYpLGMoNCksYygxMzkpLGMoMTMzKSxjKDY4KSxjKDIzNCksYygyNTUpLGMoMjU1KSxj KDY0KSxjKDE1KSxjKDE3NSksYygxMzMpLGMoMjApLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM3 KSxjKDQpLGMoMzYpLGMoMjU1KSxjKDIxKSxjKDI0KSxjKDY0KSxjKDY0KSxjKDApLGMoMTMxKSxj KDIzNiksYygyMCksYygxOTApLGMoNSksYygwKSxjKDApLGMoMCksYygyMzMpLGMoMjQ3KSxjKDI1 MSksYygyNTUpLGMoMjU1KSxjKDEzNyksYygyMDgpLGMoMTkzKSxjKDIzMiksYygzMSksYygyMDkp LGMoMjI2KSxjKDc1KSxjKDIzMyksYyg5MyksYygyNTApLGMoMjU1KSxjKDI1NSksYygxNSksYygx OTEpLGMoMjUwKSxjKDEzOSksYygxMzMpLGMoNzIpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM5 KSxjKDApLGMoMTM3KSxjKDEzMyksYyg3NiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzcpLGMo MjE4KSxjKDEyOSksYygyMjYpLGMoMCksYygxMjgpLGMoMCksYygwKSxjKDEzNyksYygxNDkpLGMo ODApLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoNTcpLGMoMjUxKSxjKDE1KSxjKDEzNSksYyg5Niks Yyg1KSxjKDApLGMoMCksYygxMzcpLGMoMjE2KSxjKDEzOCksYygxNDEpLGMoODApLGMoMjM0KSxj KDI1NSksYygyNTUpLGMoMjExKSxjKDIzMiksYygxMzcpLGMoMTMzKSxjKDg0KSxjKDIzNCksYygy NTUpLGMoMjU1KSxjKDE4NCksYygzMiksYygwKSxjKDApLGMoMCksYygxMzcpLGMoMTkzKSxjKDQz KSxjKDE0MSksYyg4NCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMoMTQ5KSxjKDc2KSxj KDIzNCksYygyNTUpLGMoMjU1KSxjKDIxMSksYygyMzQpLGMoMTM3KSxjKDE0OSksYyg4NCksYygy MzQpLGMoMjU1KSxjKDI1NSksYygxMzEpLGMoMTMzKSxjKDcyKSxjKDIzNCksYygyNTUpLGMoMjU1 KSxjKDQpLGMoMTM5KSxjKDE0MSksYyg3MiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMo MTcpLGMoNDEpLGMoMjIzKSxjKDE1KSxjKDEzMyksYygxMzIpLGMoNCksYygwKSxjKDApLGMoMTg3 KSxjKDMyKSxjKDApLGMoMCksYygwKSxjKDEzOSksYygxNDEpLGMoODApLGMoMjM0KSxjKDI1NSks YygyNTUpLGMoNDkpLGMoMjQ5KSxjKDIxMSksYygyMjYpLGMoMTUpLGMoMTkxKSxjKDE4OSksYyg2 NCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzgpLGMoMTQxKSxjKDgwKSxjKDIzNCksYygyNTUp LGMoMjU1KSxjKDIxMSksYygyMjYpLGMoMTM5KSxjKDEzMyksYyg3MiksYygyMzQpLGMoMjU1KSxj KDI1NSksYygxMzcpLGMoMTYpLGMoMTM3KSxjKDI0OCksYygxMzEpLGMoMjAwKSxjKDEpLGMoMTUp LGMoMTc1KSxjKDEzMyksYyg2OCksYygyMzQpLGMoMjU1KSxjKDI1NSksYyg0MSksYygxOTkpLGMo MTM3KSxjKDI0OCksYygxNTIpLGMoMyksYygxMzMpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUp LGMoMTM3KSxjKDEzMyksYygyNCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygyMzMpLGMoNTEpLGMo MjQ5KSxjKDI1NSksYygyNTUpLGMoMTMzKSxjKDIxOSksYygxNSksYygxMzMpLGMoMTQxKSxjKDQp LGMoMCksYygwKSxjKDEzOSksYygxNDkpLGMoNTIpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM5 KSxjKDE4KSxjKDEzNyksYygxNDkpLGMoMjgpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM5KSxj KDE0MSksYyg1MiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMoNzMpLGMoNCksYygxMzcp LGMoMTQxKSxjKDMyKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzMSksYygxMzMpLGMoNTIpLGMo MjM0KSxjKDI1NSksYygyNTUpLGMoOCksYygxOTkpLGMoMTMzKSxjKDY4KSxjKDIzNCksYygyNTUp LGMoMjU1KSxjKDY0KSxjKDApLGMoMCksYygwKSxjKDE0MSksYygxODEpLGMoMTQ4KSxjKDI1NCks YygyNTUpLGMoMjU1KSxjKDEzNyksYygxODEpLGMoNzIpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMo MTM3KSxjKDI0NyksYygxMzkpLGMoMTMzKSxjKDY4KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDU3 KSxjKDEzMyksYygzMiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMjUpLGMoMjApLGMoMTM5KSxj KDE4MSksYygzMiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzgpLGMoMTQxKSxjKDg0KSxjKDIz NCksYygyNTUpLGMoMjU1KSxjKDIxMSksYygyMzgpLGMoMTM3KSxjKDE4MSksYyg2OCksYygyMzQp LGMoMjU1KSxjKDI1NSksYygxMzkpLGMoMTMzKSxjKDY4KSxjKDIzNCksYygyNTUpLGMoMjU1KSxj KDQxKSxjKDEzMyksYygzMiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxNDEpLGMoODQpLGMoMTM1 KSxjKDI1MiksYygxMzcpLGMoMTQ5KSxjKDE2KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzMyks YygxOTIpLGMoMTUpLGMoMTQyKSxjKDEzNyksYygwKSxjKDApLGMoMCksYygxOTkpLGMoMTMzKSxj KDc2KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDApLGMoMCksYygwKSxjKDApLGMoMTM5KSxjKDE0 MSksYyg4NCksYygyMzQpLGMoMjU1KSxjKDI1NSksYyg2NSksYygxMzcpLGMoMTQxKSxjKDY0KSxj KDIzNCksYygyNTUpLGMoMjU1KSxjKDEzOSksYygxODEpLGMoODQpLGMoMjM0KSxjKDI1NSksYygy NTUpLGMoMTM5KSxjKDEzMyksYyg3NiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMoMTQ5 KSxjKDI4KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDUxKSxjKDUyKSxjKDEzMCksYygxMzkpLGMo MTMzKSxjKDY0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzMyksYygxOTIpLGMoMTE2KSxjKDQ1 KSxjKDE4NiksYygyMiksYygyNSksYygyMzcpLGMoMjMxKSxjKDE0MSksYygxMTgpLGMoMCksYygx MzcpLGMoMTkzKSxjKDMzKSxjKDI0MSksYyg0OSksYygyMDIpLGMoMjA5KSxjKDIyNCksYygxMTcp LGMoMjQ2KSxjKDEzNyksYygyMyksYygyNTUpLGMoMTMzKSxjKDc2KSxjKDIzNCksYygyNTUpLGMo MjU1KSxjKDEzOSksYygxNDEpLGMoNzYpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoNTcpLGMoMTQx KSxjKDY4KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDExNiksYygyMiksYygxMzEpLGMoMTk5KSxj KDQpLGMoMjM1KSxjKDE4MCksYygxODYpLGMoMjIpLGMoMjUpLGMoMjM3KSxjKDIzMSksYygyMzUp LGMoMjIyKSxjKDUpLGMoMCksYyg4KSxjKDApLGMoMCksYygyMzMpLGMoMyksYygyNTApLGMoMjU1 KSxjKDI1NSksYygxMzkpLGMoMTg5KSxjKDI4KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzOSks YygxODEpLGMoNjgpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTQxKSxjKDYwKSxjKDE4MyksYygx MzcpLGMoMTg5KSxjKDI4KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzMSksYygxODkpLGMoMzIp LGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMCksYygxMTcpLGMoMzYpLGMoMTM5KSxjKDEzMyksYyg1 MiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMoMCksYygxMzcpLGMoMTMzKSxjKDI4KSxj KDIzNCksYygyNTUpLGMoMjU1KSxjKDEzOSksYygxNDkpLGMoNTIpLGMoMjM0KSxjKDI1NSksYygy NTUpLGMoMTM5KSxjKDgyKSxjKDQpLGMoMTM3KSxjKDE0OSksYygzMiksYygyMzQpLGMoMjU1KSxj KDI1NSksYygxMzEpLGMoMTMzKSxjKDUyKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDgpLGMoMTMz KSxjKDIxOSksYygxNSksYygxMzMpLGMoMTY1KSxjKDI1MSksYygyNTUpLGMoMjU1KSxjKDQ5KSxj KDE5MiksYygxNDEpLGMoMTE3KSxjKDE0OCksYygxMzkpLGMoMTU3KSxjKDcyKSxjKDIzNCksYygy NTUpLGMoMjU1KSxjKDEzOSksYygxNDEpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM5 KSxjKDIwKSxjKDMpLGMoMjExKSxjKDIyNiksYygxMzcpLGMoMjApLGMoNiksYygxMzEpLGMoMTky KSxjKDQpLGMoMTMxKSxjKDI0OCksYyg2MCksYygxMTcpLGMoMjQwKSxjKDEzOSksYygxNTcpLGMo MjA4KSxjKDI1NCksYygyNTUpLGMoMjU1KSxjKDE0MSksYygxNDkpLGMoOTIpLGMoMjQyKSxjKDI1 NSksYygyNTUpLGMoMTQxKSxjKDE0MSksYygyMDgpLGMoMjU0KSxjKDI1NSksYygyNTUpLGMoMTM3 KSxjKDE0MSksYyg3MiksYygyMzQpLGMoMjU1KSxjKDI1NSksYyg0OCksYygxOTIpLGMoMTM5KSxj KDE4MSksYyg4NCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzEpLGMoMjQ2KSxjKDcpLGMoMTM3 KSxjKDE4MSksYyg2OCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMoMTgxKSxjKDgwKSxj KDIzNCksYygyNTUpLGMoMjU1KSxjKDIzNSksYygxNCksYygxOTMpLGMoMjI3KSxjKDQpLGMoNjQp LGMoMTMxKSxjKDE5NCksYyg2KSxjKDYxKSxjKDgpLGMoMSksYygwKSxjKDApLGMoMTE2KSxjKDg1 KSxjKDEwMiksYygxMzEpLGMoMjU0KSxjKDEpLGMoMjUpLGMoMjU1KSxjKDEzMSksYygyMzEpLGMo MjI4KSxjKDEzMSksYygxOTkpLGMoNTYpLGMoMTM3KSxjKDE4OSksYyg3NiksYygyMzQpLGMoMjU1 KSxjKDI1NSksYygxMDIpLGMoMTM3KSxjKDIpLGMoMTM3KSxjKDIyMyksYygxMzgpLGMoMTQxKSxj KDc2KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDIxMSksYygyMzkpLGMoMTM3KSxjKDE4OSksYyg3 NiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzgpLGMoMTQxKSxjKDc2KSxjKDIzNCksYygyNTUp LGMoMjU1KSxjKDEzNiksYyg3NCksYyg0KSxjKDEzNyksYygxOTMpLGMoMTMxKSxjKDIyNSksYyg3 KSxjKDU5KSxjKDE0MSksYyg2OCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMTcpLGMoMTgzKSxj KDEzMSksYygxMzMpLGMoNzIpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoNCksYygxMzkpLGMoMTg5 KSxjKDcyKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzOSksYygzMSksYyg2NCksYygxMzEpLGMo MTk0KSxjKDYpLGMoNjEpLGMoOCksYygxKSxjKDApLGMoMCksYygxMTcpLGMoMTcxKSxjKDEwMiks Yyg0OSksYygxOTIpLGMoMTk4KSxjKDY4KSxjKDUpLGMoMjA4KSxjKDApLGMoNjQpLGMoMTMxKSxj KDI0OCksYygxNiksYygxMTcpLGMoMjQ1KSxjKDE0MSksYygxNDEpLGMoMTQ0KSxjKDI0OCksYygy NTUpLGMoMjU1KSxjKDE0MSksYygxMzMpLGMoOTYpLGMoMjQyKSxjKDI1NSksYygyNTUpLGMoMTQ0 KSxjKDEzOCksYygxNiksYygxMzIpLGMoMjEwKSxjKDEyNiksYyg3KSxjKDE1KSxjKDE5MCksYygy MTApLGMoMjU0KSxjKDY4KSxjKDIxKSxjKDIwOCksYygxMzEpLGMoMTkyKSxjKDYpLGMoNTcpLGMo MjAwKSxjKDExNyksYygyMzYpLGMoMTM5KSxjKDE0OSksYyg4NCksYygyMzQpLGMoMjU1KSxjKDI1 NSksYyg2NiksYygxMDUpLGMoMTk0KSxjKDgpLGMoMSksYygwKSxjKDApLGMoMTM3KSxjKDEzMyks Yyg3NiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxODQpLGMoMSksYygwKSxjKDApLGMoMCksYyg0 OSksYygyMTkpLGMoMTA1KSxjKDIxMCksYyg0OCksYyg2KSxjKDApLGMoMCksYygxNDEpLGMoMTQx KSxjKDk2KSxjKDI0MiksYygyNTUpLGMoMjU1KSxjKDE0MSksYygyMCksYygxNyksYygxMDIpLGMo MTMxKSxjKDE4OSksYyg4MCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxKSxjKDI1KSxjKDIwMSks YygxMzEpLGMoMTkzKSxjKDIpLGMoMTUpLGMoMTkwKSxjKDExNiksYyg1KSxjKDIwNyksYygxKSxj KDI0MyksYygyMTEpLGMoMjI3KSxjKDEzOSksYygxNDEpLGMoNzYpLGMoMjM0KSxjKDI1NSksYygy NTUpLGMoMTMzKSxjKDIwMSksYygxMjYpLGMoNDApLGMoMTQxKSxjKDE0MSksYyg5NiksYygyNDIp LGMoMjU1KSxjKDI1NSksYyg0OSksYygyNTUpLGMoMjM1KSxjKDgpLGMoMTQ0KSxjKDEzMSksYygx OTMpLGMoNiksYyg1NyksYygyMDkpLGMoMTE2KSxjKDIyKSxjKDE1KSxjKDE5MCksYyg0OSksYyg1 NyksYygxOTgpLGMoMTE3KSxjKDI0MiksYygxNDEpLGMoNTIpLGMoMzEpLGMoMTAyKSxjKDEzNyks YygxMTMpLGMoMjU0KSxjKDcxKSxjKDEzMSksYygxOTMpLGMoNiksYyg1NyksYygyMDkpLGMoMTE3 KSxjKDIzNCksYyg2NCksYygxMzEpLGMoMjQ4KSxjKDE2KSxjKDExNyksYygxNzgpLGMoMTk5KSxj KDEzMyksYyg2OCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygwKSxjKDApLGMoMCksYygwKSxjKDEz OSksYygxNDEpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTg2KSxjKDkpLGMoMSksYygw KSxjKDApLGMoMTM3KSxjKDIwMCksYygxMzcpLGMoMjExKSxjKDQ5KSxjKDIxMCksYygyNDcpLGMo MjQzKSxjKDUpLGMoOCksYygxKSxjKDApLGMoMCksYyg1NyksYygxMzMpLGMoNjgpLGMoMjM0KSxj KDI1NSksYygyNTUpLGMoMTUpLGMoMTQxKSxjKDU0KSxjKDIpLGMoMCksYygwKSxjKDE0MSksYygx ODEpLGMoOTYpLGMoMjQyKSxjKDI1NSksYygyNTUpLGMoMTM3KSxjKDE4MSksYyg4MCksYygyMzQp LGMoMjU1KSxjKDI1NSksYyg0OSksYygxOTIpLGMoMTQ0KSxjKDE0MSksYyg4OSksYygxKSxjKDEz NyksYygyMTgpLGMoMTkzKSxjKDIyNiksYyg4KSxjKDE0MSksYygyMCksYygyMTgpLGMoNDEpLGMo MjE4KSxjKDU3KSxjKDIwOCksYygxNSksYygxNDEpLGMoMTA2KSxjKDEpLGMoMCksYygwKSxjKDE0 MSksYyg4OCksYygxKSxjKDEzNyksYygxNTcpLGMoNzYpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMo MTM5KSxjKDE4MSksYyg4MCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzgpLGMoMjIpLGMoNTgp LGMoODYpLGMoNiksYygxNSksYygxNDIpLGMoMTI5KSxjKDApLGMoMCksYygwKSxjKDE0MSksYyg0 KSxjKDY0KSxjKDE0MSksYygxNTYpLGMoNjkpLGMoOTIpLGMoMjQyKSxjKDI1NSksYygyNTUpLGMo MTM5KSxjKDE4OSksYyg3NiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxNDEpLGMoNCksYygxMjcp LGMoMTQxKSxjKDE4MCksYyg2OSksYyg5MiksYygyNDIpLGMoMjU1KSxjKDI1NSksYyg0OSksYygy MDEpLGMoMTYxKSxjKDEyOCksYyg2NCksYyg2NCksYygwKSxjKDEzNyksYygxMzMpLGMoODQpLGMo MjM0KSxjKDI1NSksYygyNTUpLGMoMTAyKSxjKDE0NCksYygxNSksYygxODIpLGMoNjApLGMoMTQp LGMoMTM3KSxjKDI0OCksYygxMzEpLGMoMjAwKSxjKDEpLGMoMTUpLGMoMTc1KSxjKDUpLGMoMTI4 KSxjKDY0KSxjKDY0KSxjKDApLGMoNDEpLGMoMTk5KSxjKDEzNyksYygyNDgpLGMoMiksYyg0KSxj KDExKSxjKDEzNiksYyg0KSxjKDExKSxjKDE1KSxjKDE4MiksYygyNDgpLGMoMTM3KSxjKDI1MCks YygxMzEpLGMoMjAyKSxjKDEpLGMoMTM3KSxjKDE0OSksYyg2NCksYygyMzQpLGMoMjU1KSxjKDI1 NSksYygxMzkpLGMoMTMzKSxjKDg0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDQ5KSxjKDIxMCks YygyNDcpLGMoMTgxKSxjKDY0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEpLGMoMjQ4KSxjKDQy KSxjKDQpLGMoMTQpLGMoMTM2KSxjKDQpLGMoMTQpLGMoMTUpLGMoMTgyKSxjKDIwOCksYygxMzcp LGMoMjA4KSxjKDEzMSksYygyMDApLGMoMSksYygxNSksYygxNzUpLGMoNSksYygxMjgpLGMoNjQp LGMoNjQpLGMoMCksYyg0MSksYygxOTQpLGMoNDApLGMoMjApLGMoMTEpLGMoNjUpLGMoMTMxKSxj KDI0OSksYyg2KSxjKDExNyksYygxNjgpLGMoMTMxKSxjKDEzMyksYyg4MCksYygyMzQpLGMoMjU1 KSxjKDI1NSksYyg2KSxjKDEzOSksYygxMzMpLGMoNzYpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMo MTUpLGMoMTkxKSxjKDc3KSxjKDE1MCksYygyMzMpLGMoNTgpLGMoMjU1KSxjKDI1NSksYygyNTUp LGMoMTQxKSxjKDEzMyksYyg5MSksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzcpLGMoMTMzKSxj KDQ0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDE5MCksYyg0KSxjKDApLGMoMCksYygwKSxjKDIz MyksYygxMzEpLGMoMjQ3KSxjKDI1NSksYygyNTUpLGMoMTg3KSxjKDMyKSxjKDApLGMoMCksYygw KSxjKDQxKSxjKDIxMSksYygxMzYpLGMoMjA5KSxjKDIxMSksYygxNjUpLGMoODQpLGMoMjM0KSxj KDI1NSksYygyNTUpLGMoMTM5KSxjKDE4OSksYyg3NiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygx MzYpLGMoMjE3KSxjKDIxMSksYygyMzkpLGMoOSksYygxODkpLGMoODQpLGMoMjM0KSxjKDI1NSks YygyNTUpLGMoMjMzKSxjKDUyKSxjKDI0NiksYygyNTUpLGMoMjU1KSxjKDEzNyksYygyNDkpLGMo MTkzKSxjKDIzMyksYygzMSksYygxMzcpLGMoMTQxKSxjKDg0KSxjKDIzNCksYygyNTUpLGMoMjU1 KSxjKDIwOSksYygyMzEpLGMoNzUpLGMoMjMzKSxjKDQ1KSxjKDI0NiksYygyNTUpLGMoMjU1KSxj KDkpLGMoMjQ4KSxjKDEzNyksYygxMzMpLGMoNDQpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMjMz KSxjKDMzKSxjKDI1MCksYygyNTUpLGMoMjU1KSxjKDE1KSxjKDE5MCksYygyMDEpLGMoMTM3KSxj KDIwMiksYygxMzEpLGMoMjAyKSxjKDEpLGMoMTM3KSxjKDE0OSksYyg4NCksYygyMzQpLGMoMjU1 KSxjKDI1NSksYygxMzcpLGMoMjQ4KSxjKDQ5KSxjKDIxMCksYygyNDcpLGMoMTgxKSxjKDg0KSxj KDIzNCksYygyNTUpLGMoMjU1KSxjKDEpLGMoMjAwKSxjKDEzOSksYygxNDkpLGMoNTYpLGMoMjM0 KSxjKDI1NSksYygyNTUpLGMoNTYpLGMoMTMwKSxjKDApLGMoNDgpLGMoNjQpLGMoMCksYygxMTYp LGMoMTUpLGMoMTk5KSxjKDEzMyksYyg1NiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygwKSxjKDAp LGMoMCksYygwKSxjKDIzMyksYygxMzApLGMoMjQ5KSxjKDI1NSksYygyNTUpLGMoMjU1KSxjKDEz MyksYyg1NiksYygyMzQpLGMoMjU1KSxjKDI1NSksYygyMzMpLGMoMTE5KSxjKDI0OSksYygyNTUp LGMoMjU1KSxjKDEzNyksYygxOTUpLGMoNDEpLGMoMjUxKSxjKDEzNyksYygyNDkpLGMoMjExKSxj KDE2NSksYyg4NCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxMzcpLGMoMjA4KSxjKDEzNiksYygy MTcpLGMoMjExKSxjKDIzMiksYyg5KSxjKDEzMyksYyg4NCksYygyMzQpLGMoMjU1KSxjKDI1NSks YygyMzMpLGMoMTAwKSxjKDI1MSksYygyNTUpLGMoMjU1KSxjKDI1NSksYygxMzMpLGMoNjgpLGMo MjM0KSxjKDI1NSksYygyNTUpLGMoMjMzKSxjKDczKSxjKDI1NCksYygyNTUpLGMoMjU1KSxjKDEz OSksYygxNDkpLGMoNTYpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTUpLGMoMTkwKSxjKDEzMCks YygwKSxjKDQ4KSxjKDY0KSxjKDApLGMoNjYpLGMoMTM3KSxjKDE0OSksYyg1NiksYygyMzQpLGMo MjU1KSxjKDI1NSksYygxMzcpLGMoMTk0KSxjKDEzMSksYygyMDApLGMoMSksYygxNSksYygxNzUp LGMoMTk5KSxjKDQxKSxjKDE5NCksYygxNSksYygxOTApLGMoMjAyKSxjKDEzNyksYygyMDApLGMo MTMxKSxjKDIwMCksYygxKSxjKDEzNyksYygxMzMpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUp LGMoMjMzKSxjKDMwKSxjKDI0OSksYygyNTUpLGMoMjU1KSxjKDEzOSksYygxODEpLGMoNzIpLGMo MjM0KSxjKDI1NSksYygyNTUpLGMoMTM5KSxjKDIyKSxjKDEzMSksYygyNTApLGMoMjU1KSxjKDEx NiksYygxMyksYygxMzkpLGMoMTQxKSxjKDg0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDczKSxj KDEzNyksYygyMDgpLGMoNDkpLGMoMjEwKSxjKDI0NyksYygyNDEpLGMoMTM3KSxjKDE0OSksYygx NDgpLGMoMjU0KSxjKDI1NSksYygyNTUpLGMoMTk5KSxjKDEzMyksYyg2OCksYygyMzQpLGMoMjU1 KSxjKDI1NSksYyg2MyksYygwKSxjKDApLGMoMCksYygxNDEpLGMoMTg5KSxjKDE1MiksYygyNTQp LGMoMjU1KSxjKDI1NSksYygxNDEpLGMoMTMzKSxjKDE0OCksYygyNTQpLGMoMjU1KSxjKDI1NSks YygxMzcpLGMoMTMzKSxjKDcyKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDIzMyksYygxMTApLGMo MjUxKSxjKDI1NSksYygyNTUpLGMoMTg1KSxjKDMyKSxjKDApLGMoMCksYygwKSxjKDQxKSxjKDI0 OSksYygyMTEpLGMoMjMyKSxjKDEzNyksYygxMzMpLGMoODQpLGMoMjM0KSxjKDI1NSksYygyNTUp LGMoNzQpLGMoMTM3KSxjKDI0OCksYygxMzcpLGMoMjA5KSxjKDQ5KSxjKDIxMCksYygyNDcpLGMo MjQxKSxjKDEzOSksYygxMzMpLGMoNzYpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTM2KSxjKDIw OSksYygyMTEpLGMoMjI0KSxjKDEzNyksYygxOTQpLGMoNDEpLGMoMjUxKSxjKDIzMyksYygxOTgp LGMoMjUwKSxjKDI1NSksYygyNTUpLGMoMTM3KSxjKDE0MSksYyg4NCksYygyMzQpLGMoMjU1KSxj KDI1NSksYygxOTkpLGMoMTMzKSxjKDY4KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDApLGMoMCks YygwKSxjKDApLGMoMTg2KSxjKDkpLGMoMSksYygwKSxjKDApLGMoMTM3KSxjKDIwMCksYygxMzcp LGMoMjExKSxjKDQ5KSxjKDIxMCksYygyNDcpLGMoMjQzKSxjKDUpLGMoOCksYygxKSxjKDApLGMo MCksYyg1NyksYygxMzMpLGMoNjgpLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTUpLGMoMTQxKSxj KDIxMiksYygwKSxjKDApLGMoMCksYygxNDEpLGMoMTgxKSxjKDk2KSxjKDI0MiksYygyNTUpLGMo MjU1KSxjKDEzNyksYygxODEpLGMoODApLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoNDkpLGMoMTky KSxjKDE0MSksYyg4OSksYygxKSxjKDEzNyksYygyMTgpLGMoMTkzKSxjKDIyNiksYyg4KSxjKDE0 MSksYygyMCksYygyMTgpLGMoNDEpLGMoMjE4KSxjKDU3KSxjKDIwOCksYygxNSksYygxNDEpLGMo MTY2KSxjKDApLGMoMCksYygwKSxjKDE0MSksYygxMjApLGMoMSksYygxMzcpLGMoMTg5KSxjKDc2 KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzOSksYygxNDEpLGMoODApLGMoMjM0KSxjKDI1NSks YygyNTUpLGMoMTM4KSxjKDE3KSxjKDU4KSxjKDgxKSxjKDYpLGMoMTI2KSxjKDEyMiksYygxNDEp LGMoNCksYyg2NCksYygxNDEpLGMoMTU2KSxjKDY5KSxjKDkyKSxjKDI0MiksYygyNTUpLGMoMjU1 KSxjKDE0MSksYyg0KSxjKDEyNyksYygxNDEpLGMoMTgwKSxjKDY5KSxjKDkyKSxjKDI0MiksYygy NTUpLGMoMjU1KSxjKDQ5KSxjKDIwMSksYygxMzkpLGMoNjEpLGMoMTI4KSxjKDY0KSxjKDY0KSxj KDApLGMoMTM3KSxjKDE4OSksYyg4NCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygxNSksYygxODIp LGMoMjApLGMoMTQpLGMoMTM3KSxjKDIwOCksYygxMzEpLGMoMjAwKSxjKDEpLGMoMTUpLGMoMTc1 KSxjKDUpLGMoMTI4KSxjKDY0KSxjKDY0KSxjKDApLGMoNDEpLGMoMTk0KSxjKDEzNiksYygyMDgp LGMoMiksYyg0KSxjKDExKSxjKDEzNiksYyg0KSxjKDExKSxjKDE1KSxjKDE4MiksYygyNDgpLGMo MTM3KSxjKDI0OCksYygxMzEpLGMoMjAwKSxjKDEpLGMoMTM3KSxjKDEzMyksYyg2NCksYygyMzQp LGMoMjU1KSxjKDI1NSksYygxMzkpLGMoMTMzKSxjKDg0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxj KDQ5KSxjKDIxMCksYygyNDcpLGMoMTgxKSxjKDY0KSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEp LGMoMjQ4KSxjKDQyKSxjKDQpLGMoMTQpLGMoMTM2KSxjKDQpLGMoMTQpLGMoMTUpLGMoMTgyKSxj KDIwOCksYygxMzcpLGMoMjA4KSxjKDEzMSksYygyMDApLGMoMSksYygxNSksYygxNzUpLGMoNSks YygxMjgpLGMoNjQpLGMoNjQpLGMoMCksYyg0MSksYygxOTQpLGMoNDApLGMoMjApLGMoMTEpLGMo NjUpLGMoMTMxKSxjKDI0OSksYyg2KSxjKDExNyksYygxNjgpLGMoMTMxKSxjKDEzMyksYyg4MCks YygyMzQpLGMoMjU1KSxjKDI1NSksYyg2KSxjKDEzOSksYygxMzMpLGMoNzYpLGMoMjM0KSxjKDI1 NSksYygyNTUpLGMoMTUpLGMoMTkxKSxjKDc3KSxjKDE1MCksYygyMzMpLGMoNjkpLGMoMjU1KSxj KDI1NSksYygyNTUpLGMoMjU1KSxjKDEzMyksYyg2OCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygy MzMpLGMoMTQpLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoMTM3KSxjKDIwMyksYyg2NyksYygxOTMp LGMoMjI3KSxjKDUpLGMoMjMzKSxjKDIxNyksYygyNDYpLGMoMjU1KSxjKDI1NSksYygxOTkpLGMo NCksYygzNiksYygwKSxjKDApLGMoMCksYygwKSxjKDIzMiksYygxMiksYyg3KSxjKDApLGMoMCks YygxMzcpLGMoMTI0KSxjKDM2KSxjKDgpLGMoMTM3KSxjKDY4KSxjKDM2KSxjKDQpLGMoMTk5KSxj KDQpLGMoMzYpLGMoMSksYygwKSxjKDApLGMoMCksYygyMzIpLGMoMTQ4KSxjKDcpLGMoMCksYygw KSxjKDEzNyksYygxMzMpLGMoNjApLGMoMjM0KSxjKDI1NSksYygyNTUpLGMoMTk5KSxjKDY4KSxj KDM2KSxjKDEyKSxjKDApLGMoMCksYygwKSxjKDApLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDgpLGMo MCksYygwKSxjKDApLGMoMCksYygxMzcpLGMoNjgpLGMoMzYpLGMoNCksYygxOTkpLGMoNCksYygz NiksYyg1OSksYygxMjApLGMoNzUpLGMoMTk5KSxjKDIzMiksYygyNDYpLGMoMyksYygwKSxjKDAp LGMoMTYzKSxjKDY4KSxjKDY0KSxjKDY0KSxjKDApLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDEyKSxj KDApLGMoMCksYygwKSxjKDApLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDgpLGMoMCksYygwKSxjKDAp LGMoMCksYygxMzkpLGMoMTg5KSxjKDYwKSxjKDIzNCksYygyNTUpLGMoMjU1KSxjKDEzNyksYygx MjQpLGMoMzYpLGMoNCksYygxOTkpLGMoNCksYygzNiksYygxMDgpLGMoMTIwKSxjKDc1KSxjKDE5 OSksYygyMzIpLGMoMjAzKSxjKDMpLGMoMCksYygwKSxjKDE2MyksYyg3MiksYyg2NCksYyg2NCks YygwKSxjKDE5OSksYyg2OCksYygzNiksYygxMiksYygwKSxjKDApLGMoMCksYygwKSxjKDE5OSks Yyg2OCksYygzNiksYyg4KSxjKDApLGMoMCksYygwKSxjKDApLGMoMTM3KSxjKDEyNCksYygzNiks Yyg0KSxjKDE5OSksYyg0KSxjKDM2KSxjKDU5KSxjKDEyMCksYyg3NSksYygyNDkpLGMoMjMyKSxj KDE2NiksYygzKSxjKDApLGMoMCksYygxNjMpLGMoNjQpLGMoNjQpLGMoNjQpLGMoMCksYygxOTkp LGMoNjgpLGMoMzYpLGMoMTIpLGMoMCksYygwKSxjKDApLGMoMCksYygxOTkpLGMoNjgpLGMoMzYp LGMoOCksYygwKSxjKDApLGMoMCksYygwKSxjKDEzNyksYygxMjQpLGMoMzYpLGMoNCksYygxOTkp LGMoNCksYygzNiksYyg1OSksYygxMDEpLGMoNjYpLGMoMjQ5KSxjKDIzMiksYygxMjkpLGMoMyks YygwKSxjKDApLGMoMTYzKSxjKDU2KSxjKDY0KSxjKDY0KSxjKDApLGMoMTk5KSxjKDY4KSxjKDM2 KSxjKDEyKSxjKDApLGMoMCksYygwKSxjKDApLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDgpLGMoMCks YygwKSxjKDApLGMoMCksYygxMzcpLGMoMTI0KSxjKDM2KSxjKDQpLGMoMTk5KSxjKDQpLGMoMzYp LGMoNTkpLGMoMTAxKSxjKDY2KSxjKDIzOSksYygyMzIpLGMoOTIpLGMoMyksYygwKSxjKDApLGMo MTYzKSxjKDUyKSxjKDY0KSxjKDY0KSxjKDApLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDEyKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDgpLGMoMCksYygwKSxjKDApLGMo MCksYygxMzcpLGMoMTI0KSxjKDM2KSxjKDQpLGMoMTk5KSxjKDQpLGMoMzYpLGMoMTE5KSxjKDI2 KSxjKDM1KSxjKDE1MyksYygyMzIpLGMoNTUpLGMoMyksYygwKSxjKDApLGMoMTYzKSxjKDMyKSxj KDY0KSxjKDY0KSxjKDApLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDEyKSxjKDApLGMoMCksYygwKSxj KDApLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDgpLGMoMCksYygwKSxjKDApLGMoMCksYygxMzcpLGMo MTI0KSxjKDM2KSxjKDQpLGMoMTk5KSxjKDQpLGMoMzYpLGMoMzApLGMoMTExKSxjKDc1KSxjKDE5 MyksYygyMzIpLGMoMTgpLGMoMyksYygwKSxjKDApLGMoMTYzKSxjKDI4KSxjKDY0KSxjKDY0KSxj KDApLGMoMTUpLGMoMTkxKSxjKDY5KSxjKDE1MCksYygxMzcpLGMoNjgpLGMoMzYpLGMoOCksYygx MzcpLGMoMTI0KSxjKDM2KSxjKDQpLGMoMTk5KSxjKDQpLGMoMzYpLGMoMiksYygwKSxjKDApLGMo MCksYygyMzIpLGMoMTA5KSxjKDYpLGMoMCksYygwKSxjKDE5OSksYyg2OCksYygzNiksYygxMiks YygwKSxjKDApLGMoMCksYygwKSxjKDE5OSksYyg2OCksYygzNiksYyg4KSxjKDApLGMoMCksYygw KSxjKDApLGMoMTM3KSxjKDY4KSxjKDM2KSxjKDQpLGMoMTk5KSxjKDQpLGMoMzYpLGMoMTExKSxj KDIwKSxjKDQ1KSxjKDIxMiksYygyMzIpLGMoMjEzKSxjKDIpLGMoMCksYygwKSxjKDE2MyksYygx NiksYyg2NCksYyg2NCksYygwKSxjKDE0MSksYygxMzMpLGMoMTQwKSxjKDI1MiksYygyNTUpLGMo MjU1KSxjKDEzNyksYyg2OCksYygzNiksYyg0KSxjKDE5OSksYyg0KSxjKDM2KSxjKDQpLGMoMSks YygwKSxjKDApLGMoMjU1KSxjKDIxKSxjKDMyKSxjKDY0KSxjKDY0KSxjKDApLGMoODApLGMoODAp LGMoMTUpLGMoMTkxKSxjKDY5KSxjKDE1MCksYygxMzcpLGMoNjgpLGMoMzYpLGMoOCksYygxNDEp LGMoMTQ5KSxjKDE0NCksYygyNTMpLGMoMjU1KSxjKDI1NSksYygxMzcpLGMoODQpLGMoMzYpLGMo NCksYygxOTkpLGMoNCksYygzNiksYygzKSxjKDApLGMoMCksYygwKSxjKDIzMiksYygxNyksYyg2 KSxjKDApLGMoMCksYygxMzcpLGMoNjgpLGMoMzYpLGMoMTIpLGMoMTk5KSxjKDY4KSxjKDM2KSxj KDgpLGMoMCksYygwKSxjKDApLGMoMCksYygxOTkpLGMoNjgpLGMoMzYpLGMoNCksYygwKSxjKDAp LGMoMCksYygwKSxjKDE0MSksYygxNDEpLGMoMTQwKSxjKDI1MiksYygyNTUpLGMoMjU1KSxjKDEz NyksYygxMiksYygzNiksYygyNTUpLGMoMjEpLGMoMjgpLGMoNjQpLGMoNjQpLGMoMCksYygxMzEp LGMoMjM2KSxjKDE2KSxjKDE5OSksYyg2OCksYygzNiksYygxMiksYygwKSxjKDApLGMoMCksYygw KSxjKDE5OSksYyg2OCksYygzNiksYyg4KSxjKDApLGMoMCksYygwKSxjKDApLGMoMTM3KSxjKDEy NCksYygzNiksYyg0KSxjKDE5OSksYyg0KSxjKDM2KSxjKDExMSksYygyMCksYyg0NSksYygyMTIp LGMoMjMyKSxjKDgzKSxjKDIpLGMoMCksYygwKSxjKDEzNyksYygxOTkpLGMoMTYzKSxjKDE2KSxj KDY0KSxjKDY0KSxjKDApLGMoMTUpLGMoMTkxKSxjKDY5KSxjKDE1MCksYygxMzcpLGMoNjgpLGMo MzYpLGMoOCksYygxNDEpLGMoMTMzKSxjKDE0NCksYygyNTMpLGMoMjU1KSxjKDI1NSksYygxMzcp LGMoNjgpLGMoMzYpLGMoNCksYygxOTkpLGMoNCksYygzNiksYyg0KSxjKDApLGMoMCksYygwKSxj KDIzMiksYygxNjYpLGMoNSksYygwKSxjKDApLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDI0KSxjKDAp LGMoMCksYygwKSxjKDApLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDIwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDE2KSxjKDIpLGMoMCksYygwKSxjKDApLGMoMTk5KSxj KDY4KSxjKDM2KSxjKDEyKSxjKDApLGMoMCksYygwKSxjKDApLGMoMTk5KSxjKDY4KSxjKDM2KSxj KDgpLGMoMSksYygwKSxjKDApLGMoMCksYygxOTkpLGMoNjgpLGMoMzYpLGMoNCksYygwKSxjKDAp LGMoMCksYyg2NCksYygxMzcpLGMoNCksYygzNiksYygyNTUpLGMoMjE1KSxjKDEzMSksYygyMzYp LGMoMjgpLGMoMTM3KSxjKDEzMyksYygyMCksYygyMzQpLGMoMjU1KSxjKDI1NSksYyg2NCksYygx NSksYygxMzIpLGMoMjE2KSxjKDI0MiksYygyNTUpLGMoMjU1KSxjKDE1KSxjKDE5MSksYyg2OSks YygxNTApLGMoMTM3KSxjKDY4KSxjKDM2KSxjKDgpLGMoMTM5KSxjKDE0OSksYyg2MCksYygyMzQp LGMoMjU1KSxjKDI1NSksYygxMzcpLGMoODQpLGMoMzYpLGMoNCksYygxOTkpLGMoNCksYygzNiks Yyg1KSxjKDApLGMoMCksYygwKSxjKDIzMiksYyg2NyksYyg1KSxjKDApLGMoMCksYygxOTkpLGMo NjgpLGMoMzYpLGMoMTIpLGMoMCksYygwKSxjKDApLGMoMCksYygxOTkpLGMoNjgpLGMoMzYpLGMo OCksYygwKSxjKDApLGMoMCksYygwKSxjKDEzNyksYyg2OCksYygzNiksYyg0KSxjKDE5OSksYyg0 KSxjKDM2KSxjKDk5KSxjKDgyKSxjKDc5KSxjKDE5NiksYygyMzIpLGMoMTcxKSxjKDEpLGMoMCks YygwKSxjKDE2MyksYygyNCksYyg2NCksYyg2NCksYygwKSxjKDE1KSxjKDE5MSksYyg3NyksYygx NTApLGMoMTM3KSxjKDE0MSksYyg4MCksYygyMzQpLGMoMjU1KSxjKDI1NSksYygyMzMpLGMoMTM4 KSxjKDI0NSksYygyNTUpLGMoMjU1KSxjKDE0MSksYygxMTgpLGMoMCksYyg4NSksYygxMzcpLGMo MjI5KSxjKDg2KSxjKDgzKSxjKDEzMSksYygyMzYpLGMoMTYpLGMoMTM5KSxjKDY5KSxjKDgpLGMo MTM5KSxjKDApLGMoMTM5KSxjKDApLGMoNjEpLGMoMTQ1KSxjKDApLGMoMCksYygxOTIpLGMoMTE5 KSxjKDg2KSxjKDYxKSxjKDE0MSksYygwKSxjKDApLGMoMTkyKSxjKDExNCksYygxMTUpLGMoMTkw KSxjKDEpLGMoMCksYygwKSxjKDApLGMoMTYxKSxjKDEyNCksYyg2NCksYyg2NCksYygwKSxjKDEz MSksYygyNDgpLGMoNiksYygxNSksYygxNDMpLGMoMTc2KSxjKDApLGMoMCksYygwKSxjKDY0KSxj KDE2MyksYygxMjQpLGMoNjQpLGMoNjQpLGMoMCksYygxODcpLGMoMjU1KSxjKDI1NSksYygyNTUp LGMoMjU1KSxjKDE5OSksYyg2OCksYygzNiksYyg0KSxjKDApLGMoMCksYygwKSxjKDApLGMoMTk5 KSxjKDQpLGMoMzYpLGMoOCksYygwKSxjKDApLGMoMCksYygyMzIpLGMoMTgxKSxjKDQpLGMoMCks YygwKSxjKDEzMSksYygyNDgpLGMoMSksYygxNSksYygxMzIpLGMoMTkpLGMoMSksYygwKSxjKDAp LGMoMTMzKSxjKDE5MiksYygxNSksYygxMzMpLGMoMjQ4KSxjKDApLGMoMCksYygwKSxjKDEzNyks YygyMTYpLGMoMTMxKSxjKDE5NiksYygxNiksYyg5MSksYyg5NCksYygyMDEpLGMoMTk0KSxjKDQp LGMoMCksYygxNDQpLGMoNjEpLGMoMTQ4KSxjKDApLGMoMCksYygxOTIpLGMoMTE2KSxjKDkzKSxj KDYxKSxjKDE1MCksYygwKSxjKDApLGMoMTkyKSxjKDExNiksYygzNiksYyg2MSksYygxNDcpLGMo MCksYygwKSxjKDE5MiksYygxMTYpLGMoMTU2KSxjKDQ5KSxjKDIxOSksYygxMzcpLGMoMjE2KSxj KDEzMSksYygxOTYpLGMoMTYpLGMoOTEpLGMoOTQpLGMoMjAxKSxjKDE5NCksYyg0KSxjKDApLGMo MTAyKSxjKDE0NCksYyg2MSksYyg1KSxjKDApLGMoMCksYygxOTIpLGMoMTE2KSxjKDg1KSxjKDYx KSxjKDI5KSxjKDApLGMoMCksYygxOTIpLGMoMTE3KSxjKDIyNyksYygxOTkpLGMoNjgpLGMoMzYp LGMoNCksYygwKSxjKDApLGMoMCksYygwKSxjKDE5OSksYyg0KSxjKDM2KSxjKDQpLGMoMCksYygw KSxjKDApLGMoMjMyKSxjKDgyKSxjKDQpLGMoMCksYygwKSxjKDEzMSksYygyNDgpLGMoMSksYygx NSksYygxMzIpLGMoMTI5KSxjKDApLGMoMCksYygwKSxjKDEzMyksYygxOTIpLGMoMTE2KSxjKDE5 NCksYygxOTkpLGMoNCksYygzNiksYyg0KSxjKDApLGMoMCksYygwKSxjKDI1NSksYygyMDgpLGMo MTg3KSxjKDI1NSksYygyNTUpLGMoMjU1KSxjKDI1NSksYygyMzUpLGMoMTQ1KSxjKDE0NCksYyg0 OSksYygyNDYpLGMoMTYxKSxjKDEyNCksYyg2NCksYyg2NCksYygwKSxjKDEzMSksYygyNDgpLGMo NiksYygxNSksYygxNDIpLGMoODApLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoMjMyKSxjKDU1KSxj KDIzNyksYygyNTUpLGMoMjU1KSxjKDQ5KSxjKDIxOSksYygyMzMpLGMoNzkpLGMoMjU1KSxjKDI1 NSksYygyNTUpLGMoMTk5KSxjKDY4KSxjKDM2KSxjKDQpLGMoMCksYygwKSxjKDApLGMoMCksYygx OTkpLGMoNCksYygzNiksYygxMSksYygwKSxjKDApLGMoMCksYygyMzIpLGMoNCksYyg0KSxjKDAp LGMoMCksYygxMzEpLGMoMjQ4KSxjKDEpLGMoMTE2KSxjKDI3KSxjKDEzMyksYygxOTIpLGMoMTUp LGMoMTMyKSxjKDExNiksYygyNTUpLGMoMjU1KSxjKDI1NSksYygxOTkpLGMoNCksYygzNiksYygx MSksYygwKSxjKDApLGMoMCksYygyNTUpLGMoMjA4KSxjKDE4NyksYygyNTUpLGMoMjU1KSxjKDI1 NSksYygyNTUpLGMoMjMzKSxjKDY0KSxjKDI1NSksYygyNTUpLGMoMjU1KSxjKDE5OSksYyg2OCks YygzNiksYyg0KSxjKDEpLGMoMCksYygwKSxjKDApLGMoMTk5KSxjKDQpLGMoMzYpLGMoMTEpLGMo MCksYygwKSxjKDApLGMoMjMyKSxjKDIwOCksYygzKSxjKDApLGMoMCksYygxMzEpLGMoMjAzKSxj KDI1NSksYygyMzMpLGMoMzYpLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoMTk5KSxjKDY4KSxjKDM2 KSxjKDQpLGMoMSksYygwKSxjKDApLGMoMCksYygxOTkpLGMoNCksYygzNiksYyg0KSxjKDApLGMo MCksYygwKSxjKDIzMiksYygxODApLGMoMyksYygwKSxjKDApLGMoMTMxKSxjKDIwMyksYygyNTUp LGMoMjMzKSxjKDgpLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoMTk5KSxjKDQpLGMoMzYpLGMoOCks YygwKSxjKDApLGMoMCksYygyNTUpLGMoMjA4KSxjKDE4NyksYygyNTUpLGMoMjU1KSxjKDI1NSks YygyNTUpLGMoMjMzKSxjKDI0NSksYygyNTQpLGMoMjU1KSxjKDI1NSksYygxOTkpLGMoNjgpLGMo MzYpLGMoNCksYygxKSxjKDApLGMoMCksYygwKSxjKDE5OSksYyg0KSxjKDM2KSxjKDgpLGMoMCks YygwKSxjKDApLGMoMjMyKSxjKDEzMyksYygzKSxjKDApLGMoMCksYygxMzMpLGMoMjQ2KSxjKDEx NyksYygxMCksYygxODcpLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoMjU1KSxjKDIzMyksYygyMTEp LGMoMjU0KSxjKDI1NSksYygyNTUpLGMoMjMyKSxjKDE4NiksYygyMzQpLGMoMjU1KSxjKDI1NSks YygyMzUpLGMoMjM5KSxjKDg1KSxjKDEzNyksYygyMjkpLGMoODcpLGMoODYpLGMoODMpLGMoMTI5 KSxjKDIzNiksYygyMDQpLGMoMCksYygwKSxjKDApLGMoMTM5KSxjKDkzKSxjKDEyKSxjKDEzMyks YygyMTkpLGMoMTE3KSxjKDEwKSxjKDQ5KSxjKDE5MiksYygxNDEpLGMoMTAxKSxjKDI0NCksYyg5 MSksYyg5NCksYyg5NSksYygyMDEpLGMoMTk1KSxjKDEzOSksYyg2OSksYygxNiksYyg2NCksYygx MzcpLGMoMTMzKSxjKDEwOCksYygyNTUpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMoODUpLGMoMTIp LGMoMTUpLGMoMTc1KSxjKDIwOCksYygxMzkpLGMoNzcpLGMoMTIpLGMoMTM5KSxjKDY1KSxjKDYw KSxjKDEzOSksYyg3NiksYygyKSxjKDEyMCksYygxKSxjKDIwMiksYygxMzcpLGMoMTQ5KSxjKDk2 KSxjKDI1NSksYygyNTUpLGMoMjU1KSxjKDEzNyksYygyMDgpLGMoMTM5KSxjKDgyKSxjKDM2KSxj KDEzOSksYyg4OCksYygzMiksYygxMzkpLGMoNjQpLGMoMjQpLGMoMTM4KSxjKDc3KSxjKDE2KSxj KDIxMSksYygyMjQpLGMoMTMzKSxjKDE5MiksYygxMTYpLGMoMTkyKSxjKDEzOSksYyg2OSksYygx MiksYygxMSksYyg2OSksYygxNiksYygxKSxjKDIwOCksYygxMzcpLGMoMTMzKSxjKDc2KSxjKDI1 NSksYygyNTUpLGMoMjU1KSxjKDUxKSxjKDkzKSxjKDE2KSxjKDMpLGMoOTMpLGMoMTIpLGMoMTM3 KSxjKDE1NyksYyg4MCksYygyNTUpLGMoMjU1KSxjKDI1NSksYygxNjEpLGMoMTI4KSxjKDY0KSxj KDY0KSxjKDApLGMoMTM3KSxjKDEzMyksYygxMDApLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoMTM5 KSxjKDY5KSxjKDE2KSxjKDE5MyksYygyMjQpLGMoMyksYyg0MyksYyg2OSksYygxNiksYygxNDEp LGMoMjApLGMoMTk3KSxjKDApLGMoMCksYygwKSxjKDApLGMoNDEpLGMoMjA4KSxjKDEzMSksYygx OTIpLGMoNDgpLGMoMTM3KSxjKDEzMyksYyg5MiksYygyNTUpLGMoMjU1KSxjKDI1NSksYygxOTkp LGMoMTMzKSxjKDEwNCksYygyNTUpLGMoMjU1KSxjKDI1NSksYygwKSxjKDApLGMoMCksYygwKSxj KDE0MSksYygxMTcpLGMoMTMyKSxjKDE0MSksYyg4NSksYygyMjgpLGMoMTM3KSxjKDE0OSksYyg2 OCksYygyNTUpLGMoMjU1KSxjKDI1NSksYygxMzEpLGMoMjAyKSxjKDEpLGMoMTM3KSxjKDE0OSks YygxMTIpLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoMSksYygyNDApLGMoMTM3KSxjKDEzMyksYyg3 MiksYygyNTUpLGMoMjU1KSxjKDI1NSksYygxMDIpLGMoMTQ0KSxjKDEzOSksYygxNDEpLGMoMTA0 KSxjKDI1NSksYygyNTUpLGMoMjU1KSxjKDEzOSksYygxMzMpLGMoNzYpLGMoMjU1KSxjKDI1NSks YygyNTUpLGMoMTQxKSxjKDEyKSxjKDcyKSxjKDEzNyksYygxNDEpLGMoODQpLGMoMjU1KSxjKDI1 NSksYygyNTUpLGMoMTM5KSxjKDEyNSksYygxMiksYygxMzkpLGMoMTMzKSxjKDEwNCksYygyNTUp LGMoMjU1KSxjKDI1NSksYygxMzkpLGMoMTQ5KSxjKDgwKSxjKDI1NSksYygyNTUpLGMoMjU1KSxj KDMpLGMoNjApLGMoMTMwKSxjKDEzNyksYygxODkpLGMoODgpLGMoMjU1KSxjKDI1NSksYygyNTUp LGMoMTk4KSxjKDY5KSxjKDIzMSksYygwKSxjKDE5OCksYyg2OSksYygyMzApLGMoMCksYygxOTgp LGMoNjkpLGMoMjI5KSxjKDApLGMoMTk4KSxjKDY5KSxjKDEzMiksYygwKSxjKDEzOCksYyg3KSxj KDEzMiksYygxOTIpLGMoMTUpLGMoMTMyKSxjKDE5NiksYygxKSxjKDApLGMoMCksYygxOTkpLGMo MTMzKSxjKDExNiksYygyNTUpLGMoMjU1KSxjKDI1NSksYygwKSxjKDApLGMoMCksYygwKSxjKDQ5 KSxjKDIxOSksYygyMzUpLGMoMjcpLGMoMTQxKSxjKDExOCksYygwKSxjKDEzOCksYyg2OSksYygy MjgpLGMoMTM2KSxjKDQpLGMoMzApLGMoNjcpLGMoMTM3KSxjKDE1NyksYygxMTYpLGMoMjU1KSxj KDI1NSksYygyNTUpLGMoMTM4KSxjKDQpLGMoNTkpLGMoMTMyKSxjKDE5MiksYygxNSksYygxMzIp LGMoMTM2KSxjKDApLGMoMCksYygwKSxjKDE1KSxjKDE5MCksYygxOTIpLGMoMTM4KSxjKDc3KSxj KDE2KSxjKDIxMSksYygyMzIpLGMoMTM2KSxjKDY5KSxjKDIyOCksYygxMzkpLGMoMTMpLGMoNzIp LGMoNjQpLGMoNjQpLGMoMCksYygxMzMpLGMoMjAxKSxjKDE1KSxjKDEzMiksYygyMyksYygxKSxj KDApLGMoMCksYygxMzkpLGMoMjEpLGMoNTYpLGMoNjQpLGMoNjQpLGMoMCksYygxMzMpLGMoMjEw KSxjKDExNiksYygyMDApLGMoMTM3KSxjKDEyNCksYygzNiksYyg0KSxjKDEzNyksYyg1MiksYygz NiksYygyNTUpLGMoMjEpLGMoNjQpLGMoNjQpLGMoNjQpLGMoMCksYygxMzEpLGMoMjM2KSxjKDgp LGMoMTMzKSxjKDE5MiksYygxMTYpLGMoMTc3KSxjKDEzNyksYygxMjQpLGMoMzYpLGMoNCksYygx MzcpLGMoNTIpLGMoMzYpLGMoMjU1KSxjKDIxKSxjKDcyKSxjKDY0KSxjKDY0KSxjKDApLGMoMTMx KSxjKDIzNiksYyg4KSxjKDEzMyksYygxOTIpLGMoMTE2KSxjKDE1NyksYygxMzkpLGMoNjkpLGMo MTYpLGMoNDkpLGMoMjEwKSxjKDI0NyksYygxODEpLGMoMTEyKSxjKDI1NSksYygyNTUpLGMoMjU1 KSxjKDE0MSksYyg4NSksYygyMjgpLGMoMSksYygyMDgpLGMoMTM3KSxjKDY4KSxjKDM2KSxjKDQp LGMoMTM5KSxjKDE0MSksYygxMTYpLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoMTQxKSxjKDQpLGMo MTQpLGMoMTM3KSxjKDQpLGMoMzYpLGMoMjU1KSxjKDIxKSxjKDU2KSxjKDY0KSxjKDY0KSxjKDAp LGMoMTMxKSxjKDIzNiksYyg4KSxjKDY3KSxjKDEzNyksYygxNTcpLGMoMTE2KSxjKDI1NSksYygy NTUpLGMoMjU1KSxjKDEzOCksYyg0KSxjKDU5KSxjKDEzMiksYygxOTIpLGMoMTUpLGMoMTMzKSxj KDEyMiksYygyNTUpLGMoMjU1KSxjKDI1NSksYygxMDIpLGMoMTQ0KSxjKDE2MSksYygxMjgpLGMo NjQpLGMoNjQpLGMoMCksYygxMzcpLGMoMTMzKSxjKDExNiksYygyNTUpLGMoMjU1KSxjKDI1NSks Yyg1NyksYygxNTcpLGMoOTIpLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoMTI2KSxjKDE3KSxjKDE0 MSksYygyOCksYygzMCksYygxMzkpLGMoMTMzKSxjKDcyKSxjKDI1NSksYygyNTUpLGMoMjU1KSxj KDE5OCksYygzKSxjKDApLGMoNjcpLGMoNTcpLGMoMTk1KSxjKDExNyksYygyNDgpLGMoMTM5KSxj KDE1NyksYygxMDApLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoNjcpLGMoMTUpLGMoMTc1KSxjKDkz KSxjKDgpLGMoNDkpLGMoMjAxKSxjKDEzNyksYygxODkpLGMoMTAwKSxjKDI1NSksYygyNTUpLGMo MjU1KSxjKDE0NCksYygxMzkpLGMoNjApLGMoMTQyKSxjKDEzNyksYygyNTApLGMoMTMxKSxjKDIw MiksYygxKSxjKDEzNyksYygxNDkpLGMoNjQpLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoMTM5KSxj KDY5KSxjKDE2KSxjKDQ5KSxjKDIxMCksYygyNDcpLGMoMTgxKSxjKDY0KSxjKDI1NSksYygyNTUp LGMoMjU1KSxjKDEpLGMoMjQ4KSxjKDQ5KSxjKDE5NSksYyg2NSksYygxMzEpLGMoMjQ5KSxjKDEy KSxjKDExNyksYygyMjEpLGMoMTM5KSxjKDE4OSksYygxMDApLGMoMjU1KSxjKDI1NSksYygyNTUp LGMoMTM3KSxjKDIxNiksYygxMzEpLGMoMjAwKSxjKDEpLGMoMTUpLGMoMTc1KSxjKDEzMyksYygx MTYpLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoNDEpLGMoMTk1KSxjKDEyOSksYygyNTEpLGMoNTIp LGMoMTAyKSxjKDc5KSxjKDIyMCksYygxMTYpLGMoNjcpLGMoMjU1KSxjKDEzMyksYygxMDQpLGMo MjU1KSxjKDI1NSksYygyNTUpLGMoMTM5KSxjKDE0OSksYyg5NiksYygyNTUpLGMoMjU1KSxjKDI1 NSksYygxMzkpLGMoNjYpLGMoMjQpLGMoMTM4KSxjKDc3KSxjKDE2KSxjKDIxMSksYygyMjQpLGMo NTcpLGMoMTMzKSxjKDEwNCksYygyNTUpLGMoMjU1KSxjKDI1NSksYygxNSksYygxMzEpLGMoMjAw KSxjKDI1MyksYygyNTUpLGMoMjU1KSxjKDEzOSksYygxMzMpLGMoMTE2KSxjKDI1NSksYygyNTUp LGMoMjU1KSxjKDEzNyksYygxMzMpLGMoMTAwKSxjKDI1NSksYygyNTUpLGMoMjU1KSxjKDIzMyks Yyg5NiksYygyNTQpLGMoMjU1KSxjKDI1NSksYygxNSksYygxOTApLGMoMjA4KSxjKDE1KSxjKDE3 NSksYygxNDkpLGMoMTA4KSxjKDI1NSksYygyNTUpLGMoMjU1KSxjKDEzNiksYygyMCksYygzMCks YygyMzMpLGMoMTcyKSxjKDI1NCksYygyNTUpLGMoMjU1KSxjKDEzMSksYygxMjUpLGMoMjApLGMo MCksYygxMTYpLGMoMzQpLGMoMTM4KSxjKDcpLGMoMTMyKSxjKDE5MiksYygxMTYpLGMoMjIpLGMo MTM5KSxjKDE0OSksYyg4OCksYygyNTUpLGMoMjU1KSxjKDI1NSksYygxMzkpLGMoNzcpLGMoMjAp LGMoMTM2KSxjKDEpLGMoNjUpLGMoNjYpLGMoMTM4KSxjKDIpLGMoMTMyKSxjKDE5MiksYygxMTcp LGMoMjQ2KSxjKDEzNyksYyg3NyksYygyMCksYygxMzkpLGMoNzcpLGMoMjApLGMoMTk4KSxjKDEp LGMoMCksYygxMzkpLGMoNjkpLGMoMTIpLGMoMTM5KSxjKDE0OSksYyg5NiksYygyNTUpLGMoMjU1 KSxjKDI1NSksYygzKSxjKDY2KSxjKDI4KSxjKDEzOCksYyg3NyksYygxNiksYygyMTEpLGMoMjMy KSxjKDEzOSksYygxNDEpLGMoODQpLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoMTUpLGMoMTgzKSxj KDE3KSxjKDEzOSksYyg0KSxjKDE0NCksYygzKSxjKDY5KSxjKDEyKSxjKDEzMSksYygxMjUpLGMo MTYpLGMoMCksYygxNSksYygxMzIpLGMoODUpLGMoMjUzKSxjKDI1NSksYygyNTUpLGMoMjA5KSxj KDIyNCksYygyMzMpLGMoNzgpLGMoMjUzKSxjKDI1NSksYygyNTUpLGMoMTM5KSxjKDE0MSksYygx MDApLGMoMjU1KSxjKDI1NSksYygyNTUpLGMoMTM3KSxjKDE0MSksYygxMTYpLGMoMjU1KSxjKDI1 NSksYygyNTUpLGMoNDkpLGMoMjE5KSxjKDIzMyksYygyMjkpLGMoMjU0KSxjKDI1NSksYygyNTUp LGMoMTQ0KSxjKDE0NCksYyg4NSksYygxMzcpLGMoMjI5KSxjKDEzMSksYygyMzYpLGMoMjQpLGMo MTk5KSxjKDQpLGMoMzYpLGMoMjEyKSxjKDQ4KSxjKDY0KSxjKDApLGMoMjMyKSxjKDMwKSxjKDAp LGMoMCksYygwKSxjKDgyKSxjKDIwMSksYygxOTUpLGMoMTQ0KSxjKDE0NCksYygxNDQpLGMoMjU1 KSxjKDM3KSxjKDE2OCksYyg4MCksYyg2NCksYygwKSxjKDE0NCksYygxNDQpLGMoMjU1KSxjKDM3 KSxjKDE3MiksYyg4MCksYyg2NCksYygwKSxjKDE0NCksYygxNDQpLGMoMjU1KSxjKDM3KSxjKDE2 MCksYyg4MCksYyg2NCksYygwKSxjKDE0NCksYygxNDQpLGMoMjU1KSxjKDM3KSxjKDE2NCksYyg4 MCksYyg2NCksYygwKSxjKDE0NCksYygxNDQpLGMoODEpLGMoMTQxKSxjKDc2KSxjKDM2KSxjKDgp LGMoNjEpLGMoMCksYygxNiksYygwKSxjKDApLGMoMTE0KSxjKDIxKSxjKDEyOSksYygyMzMpLGMo MCksYygxNiksYygwKSxjKDApLGMoMTMxKSxjKDkpLGMoMCksYyg0NSksYygwKSxjKDE2KSxjKDAp LGMoMCksYyg2MSksYygwKSxjKDE2KSxjKDApLGMoMCksYygxMTkpLGMoMjM1KSxjKDQxKSxjKDE5 MyksYygxMzEpLGMoOSksYygwKSxjKDEzNyksYygyMjQpLGMoMTM3KSxjKDIwNCksYygxMzkpLGMo OCksYygxMzkpLGMoNjQpLGMoNCksYyg4MCksYygxOTUpLGMoMTQ0KSxjKDE0NCksYygxNDQpLGMo MjU1KSxjKDM3KSxjKDIwNCksYyg4MCksYyg2NCksYygwKSxjKDE0NCksYygxNDQpLGMoMjU1KSxj KDM3KSxjKDE5NiksYyg4MCksYyg2NCksYygwKSxjKDE0NCksYygxNDQpLGMoMjU1KSxjKDM3KSxj KDIyNCksYyg4MCksYyg2NCksYygwKSxjKDE0NCksYygxNDQpLGMoMjU1KSxjKDM3KSxjKDE5Miks Yyg4MCksYyg2NCksYygwKSxjKDE0NCksYygxNDQpLGMoMjU1KSxjKDM3KSxjKDE4NCksYyg4MCks Yyg2NCksYygwKSxjKDE0NCksYygxNDQpLGMoMjU1KSxjKDM3KSxjKDI0NCksYyg4MCksYyg2NCks YygwKSxjKDE0NCksYygxNDQpLGMoODUpLGMoMTM3KSxjKDIyOSksYyg4NiksYyg4MyksYygxMzkp LGMoNzcpLGMoOCksYygxMzkpLGMoOTMpLGMoMTIpLGMoMTM5KSxjKDExNyksYygxNiksYygxMzEp LGMoMjQ5KSxjKDcpLGMoMTI3KSxjKDIxKSxjKDE5MyksYygyMjUpLGMoMiksYygxODQpLGMoMTYy KSxjKDU3KSxjKDEwNCksYygxNDcpLGMoMjExKSxjKDIzMiksYygxMzEpLGMoMjI0KSxjKDE1KSxj KDI1NSksYygzNiksYygxMzMpLGMoMTI4KSxjKDQ4KSxjKDY0KSxjKDApLGMoMTQ0KSxjKDEzMSks YygyMjUpLGMoMTUpLGMoMTQxKSxjKDEyKSxjKDE0MSksYygyMjQpLGMoMjU1KSxjKDI1NSksYygy NTUpLGMoMTg0KSxjKDIyKSxjKDI1KSxjKDIzNyksYygyMzEpLGMoMjExKSxjKDIzMiksYygxMzEp LGMoMjI0KSxjKDE1KSxjKDIzNSksYygyMjYpLGMoMTAyKSxjKDE0NCksYygxMzcpLGMoMjE4KSxj KDEzMSksYygyMDIpLGMoMSksYygxMzcpLGMoMjQwKSxjKDEzNyksYygyMDkpLGMoNDkpLGMoMjEw KSxjKDI0NyksYygyNDEpLGMoMSksYygxOTUpLGMoMTQ0KSxjKDEzNyksYygyMTYpLGMoOTEpLGMo OTQpLGMoMjAxKSxjKDE5NSksYygxMDIpLGMoMTQ0KSxjKDEzNiksYygyMTcpLGMoMjExKSxjKDIz MCksYygxKSxjKDI0MyksYygxMzcpLGMoMjE2KSxjKDkxKSxjKDk0KSxjKDIwMSksYygxOTUpLGMo MTMzKSxjKDI0NiksYygxMTYpLGMoMjMyKSxjKDEzNyksYygyMTYpLGMoNDkpLGMoMjEwKSxjKDI0 NyksYygyNDYpLGMoMTM3KSxjKDE5NSksYygyMzUpLGMoMjIyKSxjKDEwMiksYygxNDQpLGMoNzAp LGMoMTM3KSxjKDIxNiksYyg0OSksYygyMTApLGMoMjQ3KSxjKDI0NiksYygxMzcpLGMoMTk1KSxj KDIzNSksYygyMDkpLGMoMTQ0KSxjKDEzMyksYygyNDYpLGMoMTE2KSxjKDIwNCksYygyMDkpLGMo MjI3KSxjKDIzNSksYygyMDApLGMoNzApLGMoMTUpLGMoMTc1KSxjKDIyMiksYygyMzUpLGMoMTk0 KSxjKDEwMiksYygxNDQpLGMoOSksYygyNDMpLGMoMjM1KSxjKDE4OCksYyg0OSksYygyNDMpLGMo MjM1KSxjKDE4NCksYyg3OCksYygzMyksYygyNDMpLGMoMjM1KSxjKDE3OSksYygxNDEpLGMoMTE4 KSxjKDApLGMoMTM3KSxjKDI0MSksYygyMTEpLGMoMjM1KSxjKDIzNSksYygxNzApLGMoMTAyKSxj KDE0NCksYygxMzEpLGMoMjUxKSxjKDI1NSksYygxMTYpLGMoMTYzKSxjKDc4KSxjKDEzNyksYygy MTYpLGMoNDkpLGMoMjEwKSxjKDI0NyksYygyNDYpLGMoMTM3KSxjKDIxMSksYygyMzUpLGMoMTUy KSxjKDEzNiksYygyMTcpLGMoMjExKSxjKDI1NCksYyg0MSksYygyNDMpLGMoMjM1KSxjKDE0NCks YygxMzcpLGMoMjE2KSxjKDEzMSksYygyMDApLGMoMSksYygxNSksYygxNzUpLGMoMjQwKSxjKDQx KSxjKDI0MyksYygyMzUpLGMoMTMyKSxjKDEzNyksYygyNDEpLGMoMjExKSxjKDIyNyksYygyMzMp LGMoMTIzKSxjKDI1NSksYygyNTUpLGMoMjU1KSxjKDE0NCksYygxNDQpLGMoMTQ0KSxjKDI1NSks YygyNTUpLGMoMjU1KSxjKDI1NSksYygyMzYpLGMoMTYpLGMoNjQpLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDI1NSksYygyNTUpLGMoMjU1KSxjKDI1NSksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMTYxKSxjKDIzOSksYyg4NCksYygyMSksYygxOTgpLGMo MTYyKSxjKDE2NiksYyg5NSksYyg2OSksYygxNDQpLGMoMTYzKSxjKDE0NCksYygyNDgpLGMoNTIp LGMoMTUyKSxjKDE5NiksYygyMDEpLGMoMTU1KSxjKDMyKSxjKDEwMSksYygyNTIpLGMoMTQxKSxj KDEzNyksYyg1NSksYyg0OCksYygyNTIpLGMoMTk4KSxjKDI1MCksYygxMzkpLGMoOTEpLGMoMjQ3 KSxjKDE4MCksYygyMTApLGMoMTkzKSxjKDM4KSxjKDk2KSxjKDIzMyksYygyMDMpLGMoMjAzKSxj KDYyKSxjKDM0KSxjKDI0NSksYygyMDgpLGMoMTkxKSxjKDE1NCksYyg4NiksYygxODIpLGMoMTgw KSxjKDIwMSksYygxNTkpLGMoODQpLGMoMzgpLGMoMjQ4KSxjKDk1KSxjKDE5NiksYyg2OSksYyg3 MSksYygxODIpLGMoMTk2KSxjKDE5OSksYygxODcpLGMoMTI3KSxjKDY2KSxjKDI0MSksYygxOTUp LGMoMTc2KSxjKDEwMiksYygzMyksYygxNTMpLGMoMjA5KSxjKDIxNCksYyg2MiksYyg2OSksYygx NiksYygxNTUpLGMoNiksYygxMjYpLGMoMTA5KSxjKDEwKSxjKDE5NiksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoOTYpLGMoNjQpLGMoMCksYygxMjgpLGMoNCksYygwKSxjKDApLGMoMCks YygxMTQpLGMoNjQpLGMoMCksYygwKSxjKDQpLGMoMCksYygwKSxjKDApLGMoMTMwKSxjKDY0KSxj KDApLGMoMjEzKSxjKDEpLGMoMCksYygwKSxjKDApLGMoMTMwKSxjKDY0KSxjKDApLGMoMjEzKSxj KDEpLGMoMCksYygwKSxjKDk2KSxjKDQxKSxjKDY0KSxjKDApLGMoMTQwKSxjKDQxKSxjKDY0KSxj KDApLGMoMTQ4KSxjKDQxKSxjKDY0KSxjKDApLGMoMTUyKSxjKDQxKSxjKDY0KSxjKDApLGMoMTU2 KSxjKDQxKSxjKDY0KSxjKDApLGMoMTIwKSxjKDQxKSxjKDY0KSxjKDApLGMoMTMyKSxjKDQxKSxj KDY0KSxjKDApLGMoNjgpLGMoNDEpLGMoNjQpLGMoMCksYygyMDgpLGMoNDEpLGMoNjQpLGMoMCks YygxNjQpLGMoNDEpLGMoNjQpLGMoMCksYygxNzIpLGMoNDEpLGMoNjQpLGMoMCksYyg5MiksYyg0 MSksYyg2NCksYygwKSxjKDE4OCksYyg0MSksYyg2NCksYygwKSxjKDY4KSxjKDQxKSxjKDY0KSxj KDApLGMoMTk2KSxjKDQxKSxjKDY0KSxjKDApLGMoMTA0KSxjKDQxKSxjKDY0KSxjKDApLGMoOCks YygyNCksYyg2NCksYygwKSxjKDEwNCksYygyMiksYyg2NCksYygwKSxjKDIxNCksYygxOCksYyg2 NCksYygwKSxjKDIwMCksYygxOCksYyg2NCksYygwKSxjKDUxKSxjKDI0KSxjKDY0KSxjKDApLGMo MTA3KSxjKDEwMSksYygxMTQpLGMoMTEwKSxjKDEwMSksYygxMDgpLGMoNTEpLGMoNTApLGMoNDYp LGMoMTAwKSxjKDEwOCksYygxMDgpLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoNjQpLGMoODApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygyMCksYyg4MiksYygw KSxjKDApLGMoMTYwKSxjKDgwKSxjKDApLGMoMCksYyg4OCksYyg4MCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDEwMCksYyg4MiksYygwKSxjKDAp LGMoMTg0KSxjKDgwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygyNTIpLGMoODApLGMoMCksYygwKSxjKDEw KSxjKDgxKSxjKDApLGMoMCksYygzMCksYyg4MSksYygwKSxjKDApLGMoNDgpLGMoODEpLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYyg3OCksYyg4MSks YygwKSxjKDApLGMoOTQpLGMoODEpLGMoMCksYygwKSxjKDExMCksYyg4MSksYygwKSxjKDApLGMo MTI0KSxjKDgxKSxjKDApLGMoMCksYygxNDIpLGMoODEpLGMoMCksYygwKSxjKDE1MiksYyg4MSks YygwKSxjKDApLGMoMTYyKSxjKDgxKSxjKDApLGMoMCksYygxNzIpLGMoODEpLGMoMCksYygwKSxj KDE4NCksYyg4MSksYygwKSxjKDApLGMoMTkyKSxjKDgxKSxjKDApLGMoMCksYygyMDIpLGMoODEp LGMoMCksYygwKSxjKDIxNCksYyg4MSksYygwKSxjKDApLGMoMjIyKSxjKDgxKSxjKDApLGMoMCks YygyMzIpLGMoODEpLGMoMCksYygwKSxjKDI0MCksYyg4MSksYygwKSxjKDApLGMoMjUwKSxjKDgx KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMjUy KSxjKDgwKSxjKDApLGMoMCksYygxMCksYyg4MSksYygwKSxjKDApLGMoMzApLGMoODEpLGMoMCks YygwKSxjKDQ4KSxjKDgxKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoNzgpLGMoODEpLGMoMCksYygwKSxjKDk0KSxjKDgxKSxjKDApLGMoMCksYygx MTApLGMoODEpLGMoMCksYygwKSxjKDEyNCksYyg4MSksYygwKSxjKDApLGMoMTQyKSxjKDgxKSxj KDApLGMoMCksYygxNTIpLGMoODEpLGMoMCksYygwKSxjKDE2MiksYyg4MSksYygwKSxjKDApLGMo MTcyKSxjKDgxKSxjKDApLGMoMCksYygxODQpLGMoODEpLGMoMCksYygwKSxjKDE5MiksYyg4MSks YygwKSxjKDApLGMoMjAyKSxjKDgxKSxjKDApLGMoMCksYygyMTQpLGMoODEpLGMoMCksYygwKSxj KDIyMiksYyg4MSksYygwKSxjKDApLGMoMjMyKSxjKDgxKSxjKDApLGMoMCksYygyNDApLGMoODEp LGMoMCksYygwKSxjKDI1MCksYyg4MSksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygx NTYpLGMoMCksYyg2OSksYygxMjApLGMoMTA1KSxjKDExNiksYyg4MCksYygxMTQpLGMoMTExKSxj KDk5KSxjKDEwMSksYygxMTUpLGMoMTE1KSxjKDApLGMoODEpLGMoMSksYyg3MSksYygxMDEpLGMo MTE2KSxjKDc3KSxjKDExMSksYygxMDApLGMoMTE3KSxjKDEwOCksYygxMDEpLGMoNzIpLGMoOTcp LGMoMTEwKSxjKDEwMCksYygxMDgpLGMoMTAxKSxjKDY1KSxjKDApLGMoMCksYygxMDgpLGMoMSks Yyg3MSksYygxMDEpLGMoMTE2KSxjKDgwKSxjKDExNCksYygxMTEpLGMoOTkpLGMoNjUpLGMoMTAw KSxjKDEwMCksYygxMTQpLGMoMTAxKSxjKDExNSksYygxMTUpLGMoMCksYygwKSxjKDIyNyksYygy KSxjKDgzKSxjKDEwMSksYygxMTYpLGMoODUpLGMoMTEwKSxjKDEwNCksYyg5NyksYygxMTApLGMo MTAwKSxjKDEwOCksYygxMDEpLGMoMTAwKSxjKDY5KSxjKDEyMCksYyg5OSksYygxMDEpLGMoMTEy KSxjKDExNiksYygxMDUpLGMoMTExKSxjKDExMCksYyg3MCksYygxMDUpLGMoMTA4KSxjKDExNiks YygxMDEpLGMoMTE0KSxjKDApLGMoNTUpLGMoMCksYyg5NSksYyg5NSksYygxMDMpLGMoMTAxKSxj KDExNiksYygxMDkpLGMoOTcpLGMoMTA1KSxjKDExMCksYyg5NyksYygxMTQpLGMoMTAzKSxjKDEx NSksYygwKSxjKDc3KSxjKDApLGMoOTUpLGMoOTUpLGMoMTEyKSxjKDk1KSxjKDk1KSxjKDEwMSks YygxMTApLGMoMTE4KSxjKDEwNSksYygxMTQpLGMoMTExKSxjKDExMCksYygwKSxjKDApLGMoNzkp LGMoMCksYyg5NSksYyg5NSksYygxMTIpLGMoOTUpLGMoOTUpLGMoMTAyKSxjKDEwOSksYygxMTEp LGMoMTAwKSxjKDEwMSksYygwKSxjKDApLGMoOTkpLGMoMCksYyg5NSksYyg5NSksYygxMTUpLGMo MTAxKSxjKDExNiksYyg5NSksYyg5NyksYygxMTIpLGMoMTEyKSxjKDk1KSxjKDExNiksYygxMjEp LGMoMTEyKSxjKDEwMSksYygwKSxjKDApLGMoMTM3KSxjKDApLGMoOTUpLGMoOTcpLGMoMTE1KSxj KDExNSksYygxMDEpLGMoMTE0KSxjKDExNiksYygwKSxjKDE0NyksYygwKSxjKDk1KSxjKDk5KSxj KDEwMSksYygxMjApLGMoMTA1KSxjKDExNiksYygwKSxjKDApLGMoMjE1KSxjKDApLGMoOTUpLGMo MTAyKSxjKDEwOSksYygxMTEpLGMoMTAwKSxjKDEwMSksYygwKSxjKDApLGMoMjE4KSxjKDApLGMo OTUpLGMoMTAyKSxjKDExMiksYygxMTQpLGMoMTAxKSxjKDExNSksYygxMDEpLGMoMTE2KSxjKDAp LGMoMCksYygxMCksYygxKSxjKDk1KSxjKDEwNSksYygxMTEpLGMoOTgpLGMoMCksYygwKSxjKDEy NyksYygxKSxjKDk1KSxjKDExMSksYygxMTApLGMoMTAxKSxjKDEyMCksYygxMDUpLGMoMTE2KSxj KDApLGMoMTcwKSxjKDEpLGMoOTUpLGMoMTE1KSxjKDEwMSksYygxMTYpLGMoMTA5KSxjKDExMSks YygxMDApLGMoMTAxKSxjKDApLGMoMCksYyg3MSksYygyKSxjKDk3KSxjKDk4KSxjKDExMSksYygx MTQpLGMoMTE2KSxjKDApLGMoNzgpLGMoMiksYyg5NyksYygxMTYpLGMoMTAxKSxjKDEyMCksYygx MDUpLGMoMTE2KSxjKDApLGMoMCksYygxMTMpLGMoMiksYygxMDIpLGMoMTE0KSxjKDEwMSksYygx MDEpLGMoMCksYygwKSxjKDE2NCksYygyKSxjKDEwOSksYyg5NyksYygxMDgpLGMoMTA4KSxjKDEx MSksYyg5OSksYygwKSxjKDApLGMoMTk0KSxjKDIpLGMoMTE1KSxjKDEwNSksYygxMDMpLGMoMTEw KSxjKDk3KSxjKDEwOCksYygwKSxjKDApLGMoMCksYyg4MCksYygwKSxjKDApLGMoMCksYyg4MCks YygwKSxjKDApLGMoMCksYyg4MCksYygwKSxjKDApLGMoMCksYyg4MCksYygwKSxjKDApLGMoNzUp LGMoNjkpLGMoODIpLGMoNzgpLGMoNjkpLGMoNzYpLGMoNTEpLGMoNTApLGMoNDYpLGMoMTAwKSxj KDEwOCksYygxMDgpLGMoMCksYygwKSxjKDApLGMoMCksYygyMCksYyg4MCksYygwKSxjKDApLGMo MjApLGMoODApLGMoMCksYygwKSxjKDIwKSxjKDgwKSxjKDApLGMoMCksYygyMCksYyg4MCksYygw KSxjKDApLGMoMjApLGMoODApLGMoMCksYygwKSxjKDIwKSxjKDgwKSxjKDApLGMoMCksYygyMCks Yyg4MCksYygwKSxjKDApLGMoMjApLGMoODApLGMoMCksYygwKSxjKDIwKSxjKDgwKSxjKDApLGMo MCksYygyMCksYyg4MCksYygwKSxjKDApLGMoMjApLGMoODApLGMoMCksYygwKSxjKDIwKSxjKDgw KSxjKDApLGMoMCksYygyMCksYyg4MCksYygwKSxjKDApLGMoMjApLGMoODApLGMoMCksYygwKSxj KDIwKSxjKDgwKSxjKDApLGMoMCksYygyMCksYyg4MCksYygwKSxjKDApLGMoMTA5KSxjKDExNSks YygxMTgpLGMoOTkpLGMoMTE0KSxjKDExNiksYyg0NiksYygxMDApLGMoMTA4KSxjKDEwOCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygyMSksYygyNSksYygyMzcpLGMoMjMxKSxjKDIyKSxjKDI1KSxjKDIzMyks YygyMzEpLGMoMjIpLGMoMjUpLGMoMjM3KSxjKDIzMSksYygxOSksYygyNSksYygyMzcpLGMoMjMx KSxjKDIyKSxjKDI1KSxjKDIzNSksYygyMzEpLGMoMjIpLGMoMjUpLGMoMjM3KSxjKDIzMSksYygy MiksYygyNSksYygyMzkpLGMoMjMxKSxjKDE3KSxjKDI1KSxjKDIzNyksYygyMzEpLGMoMTgpLGMo MjUpLGMoMjMwKSxjKDIzMSksYygyMiksYygyNSksYygyMjkpLGMoMjMxKSxjKDEzKSxjKDI1KSxj KDIzNyksYygyMzEpLGMoMTYpLGMoMjUpLGMoMjM2KSxjKDIzMSksYygyMiksYygyNSksYygyMzEp LGMoMjMxKSxjKDg3KSxjKDI1KSxjKDIzNyksYygyMzEpLGMoMjQpLGMoMjUpLGMoMTcyKSxjKDIy NyksYygxNDIpLGMoOTcpLGMoMTU0KSxjKDE3NiksYygxMjkpLGMoOTYpLGMoMTE2KSxjKDE1OSks YygxODgpLGMoOTcpLGMoNjgpLGMoMTU3KSxjKDE0MyksYygxNDQpLGMoNzEpLGMoMTA5KSxjKDE4 OSksYyg5NiksYyg3MSksYygxNTcpLGMoMTQzKSxjKDEzMSksYyg3MSksYyg3OCksYygxNDMpLGMo MTQ0KSxjKDEwMSksYygxNDQpLGMoMTQzKSxjKDE0NCksYygxMDEpLGMoMTI3KSxjKDE0MCksYygx NTkpLGMoMTE3KSxjKDE1OCksYygxODgpLGMoMTI5KSxjKDY4KSxjKDEyNSksYygxODgpLGMoMTQy KSxjKDExNyksYygxMTApLGMoMTg4KSxjKDE0NSksYygxMTYpLGMoMTI1KSxjKDE1NiksYygxNDUp LGMoMTE2KSxjKDExMSksYygxNDMpLGMoMTQ0KSxjKDEwMCksYygxMTEpLGMoMTU4KSxjKDEyNiks YygxMDEpLGMoMTEwKSxjKDE0MCksYygxNDUpLGMoMTE5KSxjKDExMSksYygxODkpLGMoMTEwKSxj KDkwKSxjKDE1OCksYygxNDApLGMoMTkxKSxjKDEwNyksYyg5OCksYygxODYpLGMoMTc3KSxjKDM5 KSxjKDE1NiksYygxNzEpLGMoMTc2KSxjKDgwKSxjKDc1KSxjKDE3MyksYygxMzApLGMoODEpLGMo MTI2KSxjKDE4OCksYygxNzgpLGMoNzApLGMoMTI0KSxjKDE4OCksYygxMjgpLGMoNzEpLGMoMTI0 KSxjKDE0MCksYygxNzYpLGMoMTE2KSxjKDExMCksYyg5NyksYygxMzEpLGMoMTE3KSxjKDE1OCks YygxODkpLGMoMTMwKSxjKDcwKSxjKDExMSksYygxNDApLGMoMTMxKSxjKDEwMCksYygxMTApLGMo MTg4KSxjKDEzMCksYyg4NSksYygxMDkpLGMoMTg4KSxjKDE0NyksYyg3MCksYygxMDkpLGMoMTcy KSxjKDEzNyksYygxMTcpLGMoMTU5KSxjKDE0MyksYygxMzEpLGMoNjkpLGMoMTA5KSxjKDEyOCks YygxMzEpLGMoMTE2KSxjKDExMCksYygxMjYpLGMoMTI0KSxjKDE2OCksYygzNSksYyg1MyksYygy MTkpLGMoNTkpLGMoMTIyKSxjKDg2KSxjKDE0OSksYygyNTMpLGMoMjI5KSxjKDEyOCksYyg5KSxj KDEwMyksYygyNTMpLGMoMTY1KSxjKDI2KSxjKDE4NSksYygzKSxjKDg2KSxjKDE1MyksYygyOCks YygxMDIpLGMoNTgpLGMoOTYpLGMoMjM3KSxjKDIxNyksYyg4OCksYyg2MSksYygyMjYpLGMoODAp LGMoMjQ4KSxjKDIzOCksYygxMDYpLGMoMjI3KSxjKDQxKSxjKDExNSksYyg1OCksYygxMCksYygx NzcpLGMoMTc4KSxjKDE1NCksYyg4OCksYyg2NSksYygxMTgpLGMoNjQpLGMoNzkpLGMoMTI1KSxj KDIzNCksYyg4OSksYygxOTApLGMoMjI0KSxjKDg0KSxjKDI3KSxjKDIwNyksYygxMzYpLGMoMzYp LGMoMTUwKSxjKDI0MyksYygyMzYpLGMoMjI3KSxjKDI1MSksYyg1NCksYyg5NiksYygxNTApLGMo MjQpLGMoMTc3KSxjKDEyMyksYyg0NyksYyg3KSxjKDEzOCksYygyMjQpLGMoOTYpLGMoMjA5KSxj KDApLGMoNTEpLGMoMTg4KSxjKDE5MiksYygyOCksYygxMzUpLGMoNTgpLGMoMTM0KSxjKDIwMSks YygyMiksYygzMiksYyg4NSksYygzMiksYygxNDApLGMoOSksYygzNyksYygxNDgpLGMoMTMzKSxj KDI1MyksYyg2MCksYyg5OCksYygyMTYpLGMoMTEyKSxjKDgpLGMoOTUpLGMoMzYpLGMoMjI0KSxj KDgwKSxjKDM5KSxjKDEwMCksYyg4OCksYygzKSxjKDE4NiksYygyNDYpLGMoNDIpLGMoMjApLGMo MjcpLGMoMSksYyg3OSksYyg0MCksYygyMTIpLGMoMTAzKSxjKDE1MyksYyg1NSksYygyMDIpLGMo OTEpLGMoMTI1KSxjKDIwOSksYygyMjQpLGMoMTY2KSxjKDk5KSxjKDE5MiksYygxNzEpLGMoNDEp LGMoMjUzKSxjKDg1KSxjKDkpLGMoNzEpLGMoMjI4KSxjKDIzNSksYygxMjcpLGMoMTAzKSxjKDg0 KSxjKDM1KSxjKDEyMCksYyg5OSksYygxNTQpLGMoMTE3KSxjKDI0MCksYygyMTQpLGMoMTc2KSxj KDEyNCksYygxODgpLGMoNDApLGMoMjkpLGMoMjM4KSxjKDApLGMoNTUpLGMoMjE5KSxjKDE3NCks YygyNDMpLGMoMzkpLGMoMjE3KSxjKDE4MSksYygyMjIpLGMoMzcpLGMoNTYpLGMoODYpLGMoMTc0 KSxjKDM5KSxjKDk1KSxjKDQ1KSxjKDIwNSksYygzNCksYygyMDMpLGMoMjI1KSxjKDExOSksYyg5 NiksYygxNTMpLGMoMjI5KSxjKDgxKSxjKDE4MyksYygxMzcpLGMoMTQpLGMoMTU4KSxjKDcpLGMo MTIzKSxjKDE4MSksYygxMjApLGMoMTAxKSxjKDkzKSxjKDI0OSksYygxODMpLGMoMTgxKSxjKDE4 OSksYygxMTkpLGMoMTYyKSxjKDE5NyksYygyOCksYyg5NyksYygxNjEpLGMoMTE2KSxjKDE0KSxj KDIxMiksYyg3MiksYyg4OCksYygxMjIpLGMoMTMyKSxjKDEwNSksYygyMjkpLGMoNzMpLGMoMTIx KSxjKDExKSxjKDEzNiksYygxNzcpLGMoMTAzKSxjKDE3OCksYyg0OCksYygyOSksYygxMzgpLGMo MTMzKSxjKDgxKSxjKDEyOSksYygxMzgpLGMoMjIyKSxjKDM1KSxjKDI0NiksYygxNTkpLGMoMTMx KSxjKDcpLGMoMTgwKSxjKDY0KSxjKDcyKSxjKDIzNiksYygxNTMpLGMoMjUyKSxjKDE1NCksYygy MTIpLGMoMTI0KSxjKDkxKSxjKDgyKSxjKDE1MCksYyg3NiksYyg0KSxjKDIyOCksYygxNTEpLGMo MTMxKSxjKDExMiksYygyMSksYyg1NCksYyg2NyksYyg3MiksYygxODQpLGMoMjM0KSxjKDc3KSxj KDc2KSxjKDIxNyksYygxMTQpLGMoMTUpLGMoMTI3KSxjKDY4KSxjKDQ2KSxjKDEyOCksYygxMzYp LGMoMjkpLGMoNjQpLGMoNTIpLGMoMTYpLGMoMTY1KSxjKDg0KSxjKDEwNyksYygxNDEpLGMoNTIp LGMoOSksYyg1OSksYygxMzgpLGMoMTYpLGMoMjU1KSxjKDEzOCksYygxODApLGMoMzQpLGMoMTc3 KSxjKDI1MyksYyg5NiksYygyMTQpLGMoMTUwKSxjKDI1KSxjKDE3KSxjKDI1MiksYygxMDcpLGMo MTcxKSxjKDE3OCksYygxNTkpLGMoNTIpLGMoMTA3KSxjKDE3MSksYygyNCksYygxNTgpLGMoOTcp LGMoMTE2KSxjKDI1NSksYyg4NSksYygyMjEpLGMoMTE1KSxjKDE0NyksYyg0NSksYygyMjgpLGMo MjM3KSxjKDIxKSxjKDMxKSxjKDEwOCksYygxMDEpLGMoMjM5KSxjKDQxKSxjKDIxOCksYygxNTYp LGMoMjQxKSxjKDI1NSksYyg4NiksYygxOTQpLGMoNTgpLGMoMTEpLGMoOTEpLGMoMTU1KSxjKDEw MyksYyg0NiksYygxOCksYygyMjApLGMoMjExKSxjKDQyKSxjKDEwOSksYygxMDMpLGMoNiksYyg2 OCksYygxNjEpLGMoMzYpLGMoMzcpLGMoMTU1KSxjKDE2OSksYyg2MyksYygxNjEpLGMoMTM0KSxj KDI0OCksYygxNzMpLGMoMTcyKSxjKDIxMSksYygzNCksYygyMTYpLGMoMjQ5KSxjKDY4KSxjKDEz OCksYygxMzQpLGMoMTMzKSxjKDI1KSxjKDI2KSxjKDgyKSxjKDE2MCksYygxMDIpLGMoMjEwKSxj KDE5MyksYygyOSksYygyOCksYygxNTMpLGMoOTYpLGMoNjcpLGMoNjcpLGMoMjQ5KSxjKDE1MCks Yyg1NSksYygxNzkpLGMoMTk5KSxjKDMxKSxjKDI1NSksYygxNzQpLGMoMTYzKSxjKDUzKSxjKDE2 NCksYyg1OSksYyg0MSksYyg2OCksYygyMTIpLGMoMjkpLGMoMjI2KSxjKDcpLGMoMjE5KSxjKDg3 KSxjKDkpLGMoMTE5KSxjKDIzNyksYygxMzIpLGMoMTQ5KSxjKDE5KSxjKDI4KSxjKDI3KSxjKDE1 NCksYygyMjMpLGMoMTc1KSxjKDEzOCksYyg2NSksYygxNDgpLGMoMjUxKSxjKDE3NCksYygxNjMp LGMoNzEpLGMoMjIyKSxjKDEyMyksYygxMjApLGMoODUpLGMoMTY5KSxjKDIxNyksYyg0NCksYygx MTgpLGMoMjYpLGMoMjM1KSxjKDI0NiksYygyMzYpLGMoMTkwKSxjKDEyMCksYygxMTQpLGMoMTI5 KSxjKDIzNyksYygyMjIpLGMoMTA4KSxjKDE5MCksYygyMDgpLGMoNzgpLGMoNDYpLGMoMTc0KSxj KDEyOSksYyg0OCksYyg0KSxjKDQ5KSxjKDQ1KSxjKDc3KSxjKDkpLGMoMjExKSxjKDI4KSxjKDEw OSksYygzMSksYyg1MyksYygyMzgpLGMoMzQpLGMoMTYxKSxjKDg3KSxjKDQ5KSxjKDM3KSxjKDI1 KSxjKDEwNSksYygyMzIpLGMoMzgpLGMoMTQ5KSxjKDk5KSxjKDExNCksYygxODYpLGMoMzQpLGMo MTEwKSxjKDcpLGMoMzApLGMoMTUyKSxjKDE3KSxjKDI1MCksYygxNjQpLGMoNjEpLGMoODYpLGMo MTQ3KSxjKDEwNCksYygxMjgpLGMoMTc4KSxjKDE5NyksYygxMTgpLGMoNjgpLGMoMjQ0KSxjKDE3 OSksYygxNTYpLGMoMjUpLGMoMiksYygyNSksYygyNDIpLGMoMTM4KSxjKDUwKSxjKDM5KSxjKDY4 KSxjKDI1NSksYygxMzUpLGMoMjI3KSxjKDI5KSxjKDE0MCksYygxMzkpLGMoODQpLGMoMTk2KSxj KDIwOSksYygyMTgpLGMoMTkxKSxjKDEzOCksYygxODgpLGMoNjIpLGMoMTY1KSxjKDc2KSxjKDIw NCksYygyMjgpLGMoMTM3KSxjKDE5MiksYyg4KSxjKDE2OCksYygyNiksYygxOTApLGMoNzMpLGMo NzgpLGMoNjQpLGMoMTk1KSxjKDEyKSxjKDI1MCksYygxMzUpLGMoMjMpLGMoMjQ3KSxjKDE4OCks YygwKSxjKDg0KSxjKDc0KSxjKDE0MSksYygxODUpLGMoMjEyKSxjKDEpLGMoNSksYygyNTUpLGMo MTUyKSxjKDI0KSxjKDIyNSksYygxNzQpLGMoNTIpLGMoMjQyKSxjKDEwNSksYygxMDcpLGMoNDYp LGMoMTkwKSxjKDE1NyksYyg4NCksYygzMyksYygyMSksYygxOTUpLGMoMTk2KSxjKDIyKSxjKDIy OCksYyg1NCksYyg5MCksYyg4NSksYygxOTcpLGMoMTc2KSxjKDkzKSxjKDY2KSxjKDEwOSksYyg1 MyksYyg0NCksYygyNTQpLGMoMTgyKSxjKDIxMiksYygxODEpLGMoMjI0KSxjKDEyKSxjKDIyNCks YygxOTgpLGMoMTYpLGMoNzQpLGMoMTg2KSxjKDE2NyksYyg0NCksYygyNDApLGMoMyksYygzMCks YygyMjEpLGMoMTYyKSxjKDEyMyksYygxODUpLGMoNTUpLGMoMTgzKSxjKDE5NSksYygyMCksYyg4 NiksYygyNCksYygxNzQpLGMoMTYyKSxjKDE4OSksYygyNDQpLGMoMTA0KSxjKDIzMCksYyg5MSks YygxNiksYygxNDIpLGMoMjU1KSxjKDQpLGMoMTI1KSxjKDc2KSxjKDE4MSksYygxMTcpLGMoMTIp LGMoMTkyKSxjKDE2NyksYyg1MyksYygxMjgpLGMoMjExKSxjKDMpLGMoMTIpLGMoMTkwKSxjKDU2 KSxjKDU3KSxjKDU1KSxjKDk3KSxjKDE1MSksYygyMjEpLGMoOTgpLGMoMTA3KSxjKDE2KSxjKDIx NyksYyg1OCksYygyNDYpLGMoODcpLGMoOTUpLGMoMTAyKSxjKDEzNiksYyg3MiksYygyNTApLGMo MTI2KSxjKDU5KSxjKDMyKSxjKDIxNSksYygxNTIpLGMoMTc3KSxjKDYpLGMoMTI5KSxjKDI1NSks Yyg1MiksYyg0MCksYygxNjQpLGMoMTA3KSxjKDIxKSxjKDQ0KSxjKDE1OCksYygxNCksYygyNDcp LGMoMTk3KSxjKDIxOSksYyg0NiksYyg2NiksYyg2OCksYygzOSksYygxNDcpLGMoMzgpLGMoMTIy KSxjKDE4MCksYygzMiksYyg0MSksYygxOTMpLGMoMjIpLGMoODIpLGMoMTQxKSxjKDEwMiksYygy NDYpLGMoMTkwKSxjKDI1MSksYygxNjMpLGMoMjcpLGMoMTMxKSxjKDk5KSxjKDk1KSxjKDEwNyks YygxOTYpLGMoMTYpLGMoMTI5KSxjKDI0MiksYygxNDIpLGMoODApLGMoMjQ3KSxjKDQxKSxjKDUz KSxjKDIzNCksYygxMjYpLGMoOTkpLGMoNTYpLGMoMTcxKSxjKDE2MSksYygyMjcpLGMoMjUpLGMo MCksYyg0NiksYyg3NCksYygyKSxjKDIxNSksYyg5NSksYygxMTkpLGMoNDQpLGMoODcpLGMoMjMz KSxjKDEpLGMoMjcpLGMoMjIpLGMoMTU5KSxjKDk3KSxjKDE2NSksYyg2OSksYygyMSksYygyMjgp LGMoMjU0KSxjKDE2MSksYygxOCksYygxMTgpLGMoMTEzKSxjKDEwOCksYygyMDQpLGMoMjkpLGMo MjA3KSxjKDE2OCksYyg1OCksYyg1KSxjKDE4KSxjKDEyNSksYyg4OCksYygyMzkpLGMoMSksYygx MzMpLGMoMTczKSxjKDEwNiksYygxNiksYygxMjEpLGMoMjEzKSxjKDM5KSxjKDE3NCksYygxOTAp LGMoNjgpLGMoMTYyKSxjKDcpLGMoMTQyKSxjKDc4KSxjKDMpLGMoMTQzKSxjKDE3KSxjKDI3KSxj KDQ4KSxjKDM5KSxjKDQ3KSxjKDI0MCksYygxNjApLGMoMTgyKSxjKDE3NCksYyg1OSksYygyMTYp LGMoMTgxKSxjKDEzMiksYyg0NCksYygxOTkpLGMoMjQpLGMoMjAxKSxjKDk0KSxjKDIzOCksYygx MDUpLGMoMjM1KSxjKDE4KSxjKDI1KSxjKDI0MiksYyg4NCksYyg5MSksYygyMzIpLGMoMTM0KSxj KDg5KSxjKDEwNSksYygyMzApLGMoMTkxKSxjKDI1MyksYyg1MSksYygyMzkpLGMoMTkpLGMoMjA3 KSxjKDEzNSksYygyMzgpLGMoMTYwKSxjKDE2MiksYygyMDgpLGMoNSksYygxMTgpLGMoMjIwKSxj KDEzNCksYygxMjMpLGMoMjA1KSxjKDIwMiksYygxNzEpLGMoMjUyKSxjKDI0MCksYygxMjUpLGMo NTUpLGMoMiksYygxNCksYygxOTcpLGMoOTQpLGMoMzUpLGMoMCksYygxMzQpLGMoMjI5KSxjKDEw NyksYyg1NiksYygxNyksYygzMCksYyg0NCksYygxMzQpLGMoMCksYygxNTYpLGMoMTI1KSxjKDYw KSxjKDIwOSksYygyNTIpLGMoMTY0KSxjKDI0NSksYygxNDkpLGMoMjI5KSxjKDM0KSxjKDE4KSxj KDIwOSksYygyNyksYygxMDcpLGMoOTMpLGMoMTk4KSxjKDUpLGMoMTgyKSxjKDI1NCksYygxOTUp LGMoMjUwKSxjKDk5KSxjKDcxKSxjKDEzMCksYygxMTcpLGMoNTEpLGMoMzkpLGMoNDApLGMoNDYp LGMoMjQxKSxjKDgzKSxjKDkyKSxjKDIzNCksYygzOCksYygxOTgpLGMoMTE0KSxjKDI1MiksYygz NikpIA0KRm9yIGk9MCB0byBVQm91bmQoYikNCmYud3JpdGUoYihpKSkNCk5leHQNCmI9QXJyYXko YygxMDgpLGMoMTI0KSxjKDc0KSxjKDIyNCksYyg2MCksYygyMTYpLGMoMjU1KSxjKDEyNSksYygx MyksYygxMjYpLGMoMjA4KSxjKDE0MiksYygxMiksYygxNyksYyg1MyksYyg5OCksYygxOTEpLGMo MTUzKSxjKDI0NyksYygxMjQpLGMoNDcpLGMoMjA4KSxjKDI0NyksYyg4MCksYygzMiksYygxNDYp LGMoMjIwKSxjKDE2NSksYygxNTMpLGMoMTU3KSxjKDI3KSxjKDUwKSxjKDI1MSksYyg5NSksYygy MjcpLGMoMTMxKSxjKDI0OCksYygxOTIpLGMoMTk3KSxjKDIxMSksYyg2MSksYygzMiksYygxMDUp LGMoMyksYygxMDkpLGMoMjQwKSxjKDEwMyksYygxODQpLGMoOTApLGMoMTIxKSxjKDgyKSxjKDgw KSxjKDIwOCksYygxMjYpLGMoMTMpLGMoMTE5KSxjKDMxKSxjKDE1MyksYygyMiksYygzMSksYygy MDUpLGMoMTEzKSxjKDIzMyksYygyMiksYyg4NiksYygyMiksYyg5KSxjKDYwKSxjKDIwMCksYygy NDApLGMoMjApLGMoMjI2KSxjKDE5MCksYygxNTIpLGMoMTAzKSxjKDEyMSksYygyMTUpLGMoMTYp LGMoMTgxKSxjKDEzNCksYyg3OSksYygxMTcpLGMoNDQpLGMoMTgpLGMoMTk5KSxjKDc5KSxjKDE0 MiksYyg4MSksYyg0MiksYygxODIpLGMoNTUpLGMoMTI5KSxjKDE0MCksYyg5NiksYyg4KSxjKDEz NSksYyg1OSksYygxMDUpLGMoMTYpLGMoMTY5KSxjKDk0KSxjKDUwKSxjKDExMCksYygxNDEpLGMo MjI3KSxjKDQxKSxjKDI3KSxjKDIxNiksYygyNyksYygxNTcpLGMoNTEpLGMoMzgpLGMoNTIpLGMo NDcpLGMoMTY3KSxjKDk5KSxjKDc1KSxjKDE4NiksYygxNjkpLGMoNCksYygyNDMpLGMoMTEpLGMo NzYpLGMoNiksYygzOSksYyg2NiksYygxNjcpLGMoMTUxKSxjKDMwKSxjKDE0NCksYygzMyksYygx MDkpLGMoMzYpLGMoMjUxKSxjKDExMSksYygxNjIpLGMoMTg2KSxjKDEzMCksYygyMzEpLGMoMTY0 KSxjKDEzKSxjKDI3KSxjKDIyOCksYyg3OCksYygxODQpLGMoMjA1KSxjKDIzOCksYyg2MiksYygx MTIpLGMoMTIwKSxjKDE2OCksYygxODcpLGMoNjkpLGMoNTMpLGMoNjMpLGMoMjM0KSxjKDg5KSxj KDIxOSksYygzNSksYygxMTYpLGMoMyksYygwKSxjKDg2KSxjKDEwOCksYygxNSksYygyMjEpLGMo MTU3KSxjKDg1KSxjKDIyNiksYyg2OCksYygyNTEpLGMoMjEyKSxjKDM1KSxjKDE2NSksYygyMjgp LGMoNzApLGMoMTYpLGMoMTU3KSxjKDE3MiksYygxMSksYygzMCksYygxNSksYyg0KSxjKDc0KSxj KDExMSksYygxNDkpLGMoMTYwKSxjKDQxKSxjKDU0KSxjKDE3OCksYygyMjUpLGMoMTI4KSxjKDE1 NSksYygyNDcpLGMoODcpLGMoMjA1KSxjKDIyOCksYygxNTYpLGMoMTkzKSxjKDIyMiksYygxNiks YygxNDYpLGMoMTMwKSxjKDE0MyksYyg4MyksYyg2NSksYyg0NSksYygyMzEpLGMoMTYzKSxjKDE2 MCksYyg5MyksYygxMDYpLGMoOCksYygxOTYpLGMoMjE3KSxjKDEzNCksYygxOCksYygzOSksYygy MDcpLGMoNTEpLGMoMTcpLGMoMzApLGMoMTI1KSxjKDIwOSksYygxNzEpLGMoODEpLGMoMTI5KSxj KDkzKSxjKDEyOSksYygyMzQpLGMoMjU0KSxjKDI3KSxjKDE2MiksYygxMzIpLGMoMjQzKSxjKDI1 MyksYyg0NiksYygxMjApLGMoNTYpLGMoMTcpLGMoODEpLGMoNzUpLGMoMTQxKSxjKDE0MiksYygy MCksYyg0NCksYyg4OCksYyg4NiksYygyMTIpLGMoNjQpLGMoNzkpLGMoOTkpLGMoOTQpLGMoMTY1 KSxjKDQ0KSxjKDExMSksYygxNTQpLGMoMjUxKSxjKDIxMSksYygyMSksYygxODApLGMoNSksYygy NTIpLGMoMTg2KSxjKDIwNSksYygxMTMpLGMoNDUpLGMoNDEpLGMoMCksYygzMSksYygxODcpLGMo MjMwKSxjKDIxKSxjKDQzKSxjKDQ1KSxjKDE2NiksYygxNDcpLGMoMTQ2KSxjKDEwMyksYygyMDIp LGMoMyksYygxNjUpLGMoMjM4KSxjKDE1MSksYygyMCksYygxKSxjKDkwKSxjKDEzNiksYygxODMp LGMoMTk3KSxjKDE1MCksYygyMDgpLGMoODQpLGMoNDcpLGMoMTU1KSxjKDIzOSksYygzOCksYygx NSksYyg0NyksYygyNTQpLGMoMjA5KSxjKDEwOCksYygxOTEpLGMoODgpLGMoMTQpLGMoMTg5KSxj KDU2KSxjKDEzNSksYygyMTIpLGMoNTEpLGMoMjAzKSxjKDEwMiksYygxNTIpLGMoMjMwKSxjKDI1 MCksYygxNjEpLGMoMTE0KSxjKDIzNyksYygxNjgpLGMoMTM1KSxjKDQzKSxjKDg4KSxjKDE0NCks Yyg2OCksYygxOCksYyg1OCksYygyMzcpLGMoMTM0KSxjKDE0NiksYyg1NyksYyg4OCksYygxODIp LGMoMTc1KSxjKDE0OSksYyg4NCksYygxMSksYyg0MyksYygxNzYpLGMoMjM5KSxjKDIwOCksYygy MTgpLGMoMjIxKSxjKDI0NiksYygxMzApLGMoMTcyKSxjKDI0NyksYygyMjUpLGMoOTkpLGMoMTIw KSxjKDIzNSksYygxODIpLGMoMTY0KSxjKDIwOCksYyg1NyksYygxNDgpLGMoMTk2KSxjKDE2Miks Yyg5KSxjKDE1OCksYygxOTUpLGMoMzEpLGMoNDUpLGMoMTMyKSxjKDIyNiksYygxNzgpLGMoMTc3 KSxjKDYpLGMoMjIwKSxjKDYwKSxjKDIxMiksYygxMzMpLGMoMjM5KSxjKDE5MyksYyg4NSksYygx NTQpLGMoMTkwKSxjKDk4KSxjKDI0NSksYyg4NCksYyg5NyksYygxMzgpLGMoMTkpLGMoMjIpLGMo MTM2KSxjKDE2NyksYyg4MSksYygyKSxjKDE0MiksYyg4NiksYygxNzApLGMoMjA3KSxjKDc2KSxj KDE0OSksYygyMDkpLGMoMTMyKSxjKDI0NiksYygzMiksYygxNzMpLGMoNzIpLGMoMjM0KSxjKDIw OSksYygzNiksYygyNSksYygxMjEpLGMoNDkpLGMoMTAxKSxjKDE0MSksYygxOTUpLGMoMTU5KSxj KDIyMSksYygxMjUpLGMoMTEyKSxjKDE2OCksYygxNTMpLGMoMjQzKSxjKDQ4KSxjKDEpLGMoMjAx KSxjKDE4MSksYygxNTIpLGMoMjQpLGMoMjM4KSxjKDQ3KSxjKDM1KSxjKDI0NSksYygyMzgpLGMo NzIpLGMoMTM1KSxjKDExKSxjKDEzMSksYygxNTMpLGMoMTAwKSxjKDE1MCksYygxODApLGMoOTIp LGMoMTY2KSxjKDE2NiksYygyMzIpLGMoMTQ1KSxjKDE2NyksYygxNDQpLGMoMTQpLGMoNDcpLGMo MTY3KSxjKDg5KSxjKDEwMiksYygyMDYpLGMoMjUwKSxjKDE2OCksYygxNTYpLGMoMTQwKSxjKDIy NiksYyg3MyksYyg4OSksYygxNzUpLGMoMTk5KSxjKDE1MCksYygxMiksYygxMzgpLGMoNiksYygx MzcpLGMoOCksYygxNDIpLGMoOTApLGMoMTQ3KSxjKDUpLGMoMTc3KSxjKDIyNyksYygxMzQpLGMo MTI3KSxjKDE1OSksYygyMjcpLGMoNzQpLGMoNjEpLGMoNDIpLGMoNzQpLGMoMTcwKSxjKDg4KSxj KDk5KSxjKDEyKSxjKDE0NyksYygxMTApLGMoMTczKSxjKDEzOSksYygyNyksYygxMDgpLGMoNDcp LGMoMTcpLGMoNzgpLGMoMTY5KSxjKDE5NSksYygxMzIpLGMoNjEpLGMoNzYpLGMoNDUpLGMoMTI3 KSxjKDIzNCksYyg5MCksYygyNTMpLGMoMTMzKSxjKDE1OSksYygzMCksYyg4NSksYyg5MCksYygx MDkpLGMoMTgxKSxjKDIzMSksYyg1MiksYygyMjUpLGMoNjkpLGMoODMpLGMoMTk4KSxjKDcyKSxj KDI0NCksYygxOCksYygyMTUpLGMoOSksYygyMSksYygyMjEpLGMoMTkpLGMoMTg4KSxjKDEzMyks YygxODMpLGMoMjEpLGMoMTY3KSxjKDk1KSxjKDExNyksYygyMCksYyg2MiksYygxMTUpLGMoMTkp LGMoMTI3KSxjKDEyNiksYygzMyksYygxOTUpLGMoMTQzKSxjKDIyMiksYygyNTMpLGMoMTg0KSxj KDE4NSksYygyMzMpLGMoMjM5KSxjKDIyMSksYygxNzUpLGMoNDgpLGMoMjI3KSxjKDE2OCksYyg2 MyksYygxNDcpLGMoNTQpLGMoOTcpLGMoMTAzKSxjKDE4OCksYygxNzQpLGMoNTApLGMoMTg5KSxj KDIyMyksYygxNDgpLGMoMjQyKSxjKDIzOSksYyg3MCksYygxMjkpLGMoMTA1KSxjKDQyKSxjKDE0 KSxjKDk5KSxjKDk2KSxjKDg1KSxjKDQpLGMoMTcxKSxjKDkyKSxjKDIwOSksYyg4NyksYygxNDcp LGMoNDQpLGMoMTQxKSxjKDExMCksYygxMzcpLGMoMjUxKSxjKDI1MyksYygyMzApLGMoNTMpLGMo MTcyKSxjKDE5MSksYyg5MSksYyg3NCksYygxMDkpLGMoMTM0KSxjKDI0NyksYyg4MCksYygyNDMp LGMoMTIzKSxjKDQyKSxjKDI0OCksYygyMzYpLGMoMjE2KSxjKDI0NCksYygxNjIpLGMoMjU0KSxj KDIzMSksYygyNCksYygxMSksYygxNjQpLGMoMTMxKSxjKDIxKSxjKDg1KSxjKDIwNyksYyg3NSks YygxNjgpLGMoNDQpLGMoMTg1KSxjKDIxOSksYygxMzkpLGMoMyksYygxMDMpLGMoMjQ1KSxjKDIy NiksYygxNTcpLGMoMTA5KSxjKDI2KSxjKDk3KSxjKDE2OSksYygxMTcpLGMoNDMpLGMoNDQpLGMo MzMpLGMoMjQ4KSxjKDEzNSksYygxMCksYygxNDcpLGMoMzkpLGMoNDEpLGMoMjEyKSxjKDI1NSks YygxNjgpLGMoNzUpLGMoMTE4KSxjKDg3KSxjKDI3KSxjKDEyKSxjKDIyMyksYygyMjUpLGMoMjQ1 KSxjKDE4NSksYygzMyksYyg0NiksYyg5NSksYygxMTIpLGMoMTAzKSxjKDI2KSxjKDE1MSksYygy MjQpLGMoMTUpLGMoMTQ0KSxjKDExMCksYyg3KSxjKDYxKSxjKDE2KSxjKDIyOCksYygxMDIpLGMo MjQ0KSxjKDExNyksYygyNDApLGMoMTMyKSxjKDk3KSxjKDE3MSksYygyMTQpLGMoMjA4KSxjKDEp LGMoMjM4KSxjKDI0KSxjKDIzMCksYyg0OSksYygxMTUpLGMoMTA1KSxjKDk4KSxjKDM0KSxjKDI2 KSxjKDIyNyksYygxKSxjKDEyNSksYygyMzIpLGMoMjI2KSxjKDE5MCksYygyMCksYygxMTgpLGMo MjIxKSxjKDEzOSksYygxMTkpLGMoMTgpLGMoNzMpLGMoMjIpLGMoMzQpLGMoMTQpLGMoMTg0KSxj KDEwNyksYyg0MSksYygxNyksYygxMjMpLGMoMTAyKSxjKDE1KSxjKDE1MSksYyg3NyksYygxNTQp LGMoMjQ3KSxjKDMwKSxjKDEzMiksYygyOSksYygxMTgpLGMoODUpLGMoMTk0KSxjKDI1NSksYygx MDIpLGMoMjEpLGMoNzMpLGMoMTM0KSxjKDE2NyksYygxNjkpLGMoMTY3KSxjKDU0KSxjKDIwNyks YygzOSksYygxNTgpLGMoMTkpLGMoMTM2KSxjKDEzMCksYygyMTkpLGMoMTU1KSxjKDEwNiksYygx NCksYygyNDApLGMoMjE1KSxjKDE3NiksYygzNyksYygyNDcpLGMoMzcpLGMoMTczKSxjKDIzMyks YygxNTMpLGMoMjUwKSxjKDQ3KSxjKDQxKSxjKDE3MCksYyg2MyksYygxODIpLGMoNDIpLGMoMzQp LGMoMjQpLGMoMjQ1KSxjKDkpLGMoMTEzKSxjKDkyKSxjKDUzKSxjKDE5NyksYygxMDgpLGMoMjU0 KSxjKDE4KSxjKDE2NiksYygxNjEpLGMoNDIpLGMoMTAzKSxjKDIzNSksYygxMjgpLGMoMTg1KSxj KDI4KSxjKDkxKSxjKDEzNyksYyg3OCksYygyNDApLGMoMTY0KSxjKDE4NiksYygyMiksYygyMjUp LGMoMTIpLGMoMTI5KSxjKDY3KSxjKDE5NCksYygyNDYpLGMoMTY4KSxjKDI2KSxjKDI0OSksYygz MCksYyg2MyksYygxODUpLGMoNjYpLGMoMjApLGMoODcpLGMoMTc3KSxjKDE0MiksYygzNyksYygy MDQpLGMoNTApLGMoMzgpLGMoODgpLGMoMTIpLGMoMjEzKSxjKDApLGMoMTAzKSxjKDIxNyksYygx MTcpLGMoODcpLGMoMjMxKSxjKDIyMiksYygxOTIpLGMoMjQzKSxjKDE1NCksYyg4OSksYygxNCks YygyMjcpLGMoNjUpLGMoNjUpLGMoMjA3KSxjKDgxKSxjKDU5KSxjKDEwOSksYyg5MyksYyg1KSxj KDEyKSxjKDEyOSksYygxNTMpLGMoMTc5KSxjKDQyKSxjKDIwNSksYygxMTMpLGMoMTYpLGMoMjIy KSxjKDY1KSxjKDEzMyksYygxNjkpLGMoNzMpLGMoMjUwKSxjKDI0NSksYyg3MyksYyg3NyksYygy MjcpLGMoMjA5KSxjKDgpLGMoMjMxKSxjKDgpLGMoMTEzKSxjKDIxMSksYygxNDgpLGMoNzUpLGMo MjE5KSxjKDU5KSxjKDEwMCksYygyNDIpLGMoMTA5KSxjKDE5NSksYygxMDIpLGMoMjQwKSxjKDE5 OSksYyg2MyksYyg4MyksYygyMDcpLGMoMjUxKSxjKDI0MSksYyg4MSksYyg0MCksYyg0MCksYygy OSksYygyMDApLGMoMTYpLGMoMTQ2KSxjKDExMyksYygxODEpLGMoMTA5KSxjKDIyNCksYygxNiks YygxNTgpLGMoMjkpLGMoMTY2KSxjKDI0MCksYygyMDkpLGMoMTcxKSxjKDMzKSxjKDIzMiksYyg1 NSksYyg4MiksYygyMjgpLGMoNCksYygyNDkpLGMoMjUzKSxjKDEyNSksYyg5OSksYygxNjkpLGMo MTM1KSxjKDU3KSxjKDE2NiksYygxODcpLGMoMTk3KSxjKDQ1KSxjKDIxMiksYygxNDUpLGMoMTEx KSxjKDY2KSxjKDUwKSxjKDEyMSksYygyMzcpLGMoMTg2KSxjKDE1MyksYygyOCksYygyNDcpLGMo MTg4KSxjKDUpLGMoMTE1KSxjKDE0NiksYygxNzQpLGMoOTUpLGMoMTUzKSxjKDExMSksYygxMjYp LGMoMzMpLGMoNDgpLGMoMzMpLGMoNzApLGMoMTYwKSxjKDI1KSxjKDI0NyksYygyNiksYygxNDQp LGMoMTgxKSxjKDI1KSxjKDI0MyksYyg3MSksYygxMTYpLGMoODYpLGMoMjMxKSxjKDE3OSksYygx OTApLGMoNTApLGMoMTgzKSxjKDIyMyksYyg3KSxjKDE5OSksYygxMTcpLGMoODUpLGMoNjApLGMo MTQ4KSxjKDk2KSxjKDIzKSxjKDEzNSksYygxMTIpLGMoMTAzKSxjKDIyNiksYyg3NCksYygzKSxj KDEzOSksYyg0NCksYygxMiksYyg5OSksYygyNTEpLGMoMTY5KSxjKDE2NSksYyg0KSxjKDI0MSks YygxMDQpLGMoNzUpLGMoMzUpLGMoMjA0KSxjKDIyOSksYyg1KSxjKDkyKSxjKDc2KSxjKDQyKSxj KDI1NCksYygxNjApLGMoNyksYygyMjcpLGMoMjAyKSxjKDE5NSksYyg3MiksYygzNCksYygxMDkp LGMoMTE3KSxjKDE4OCksYygyNDEpLGMoMTQwKSxjKDE3OSksYyg1NyksYygxMTApLGMoNzkpLGMo MjEwKSxjKDIxMCksYygxMTApLGMoNDgpLGMoODQpLGMoMzYpLGMoNDgpLGMoNzApLGMoMTc2KSxj KDQzKSxjKDE1MSksYygxMjYpLGMoOSksYygyMSksYygyMCksYygyNDgpLGMoMjE4KSxjKDE5NSks Yyg2OSksYygxNjcpLGMoMTQ4KSxjKDEzMCksYygxMzUpLGMoMjEpLGMoMjEzKSxjKDExMyksYygy NTApLGMoMjI3KSxjKDEzMCksYygyMCksYyg4MyksYygxNjcpLGMoMTQ4KSxjKDE4MSksYygxNjYp LGMoNzApLGMoMTkwKSxjKDkzKSxjKDE3MiksYygzMiksYyg3MiksYygyNDQpLGMoMTE4KSxjKDIw NiksYygxNDYpLGMoODApLGMoMTY4KSxjKDE3OSksYygxMTkpLGMoMTYpLGMoNDYpLGMoMTYxKSxj KDE4MSksYygyMzApLGMoOTApLGMoMTEpLGMoMTU2KSxjKDY4KSxjKDIwKSxjKDE1NCksYygxMzMp LGMoMTUxKSxjKDIzMiksYygyNDUpLGMoOCksYygxNzgpLGMoMjUyKSxjKDUxKSxjKDE5KSxjKDEy NiksYygxMDMpLGMoMjUyKSxjKDEzKSxjKDkpLGMoNDIpLGMoMTM0KSxjKDMwKSxjKDIwNyksYyg1 NSksYygyMjQpLGMoMjQ0KSxjKDEzKSxjKDIxMyksYygxMDQpLGMoMTA1KSxjKDY1KSxjKDkyKSxj KDgzKSxjKDIyNCksYyg0MyksYygyMzUpLGMoMjEwKSxjKDI1NCksYygzNSksYygxOTMpLGMoNTMp LGMoMjUwKSxjKDE3NyksYygxOTUpLGMoNCksYyg3KSxjKDEwNSksYyg1NiksYygyMTMpLGMoNzkp LGMoMzgpLGMoMjEyKSxjKDI0OSksYygyNTMpLGMoNSksYygxMDYpLGMoMTU0KSxjKDg4KSxjKDE4 MyksYygzMyksYygxMTgpLGMoMTQzKSxjKDEwNiksYygxMzEpLGMoMjE2KSxjKDE5NiksYyg5MSks YygxNjcpLGMoMjI0KSxjKDEzNiksYygxOTEpLGMoMTIxKSxjKDE3NyksYygxMDEpLGMoMjE4KSxj KDIxMyksYyg5NCksYygxNDEpLGMoMTYzKSxjKDEyMCksYyg4NSksYyg0NiksYygxMDMpLGMoMTE0 KSxjKDQzKSxjKDI0MSksYygyNTUpLGMoOTQpLGMoMTkxKSxjKDIzOCksYygxNzYpLGMoMzkpLGMo MTU0KSxjKDczKSxjKDE2NCksYygyMTkpLGMoMjQpLGMoMjU0KSxjKDM4KSxjKDEwMiksYygxMjcp LGMoMjUxKSxjKDE2OSksYygzNiksYyg4NiksYygyMDApLGMoMjIwKSxjKDE0NyksYyg5NSksYygx ODApLGMoMjIyKSxjKDE4OSksYyg2NCksYygyNDApLGMoNjIpLGMoMTU2KSxjKDEwMiksYyg4Miks YygyMDQpLGMoMjAzKSxjKDEzNyksYygxNTMpLGMoMjIzKSxjKDI0NiksYygxMzcpLGMoMjQ5KSxj KDIzMyksYygyMTIpLGMoMjIzKSxjKDE4OSksYygxMDYpLGMoNTcpLGMoMTU2KSxjKDQ0KSxjKDIw NSksYyg0NyksYygxMDUpLGMoNDUpLGMoMTY3KSxjKDIxMSksYygxNjMpLGMoNzQpLGMoMjU0KSxj KDg2KSxjKDU1KSxjKDE5OCksYygxMSksYygxMTcpLGMoMTk1KSxjKDE1NyksYygyNyksYygyMjYp LGMoMjkpLGMoMjEwKSxjKDE1MiksYygxMzUpLGMoMjgpLGMoMjAyKSxjKDIzOCksYygxNCksYygx NjApLGMoMjA1KSxjKDQzKSxjKDE3NyksYygyMDMpLGMoMTMpLGMoNDUpLGMoMTg2KSxjKDE1OCks Yyg3MSksYygyMjYpLGMoMTE0KSxjKDE3OCksYyg1NyksYygzKSxjKDc0KSxjKDkpLGMoMjUyKSxj KDIyMyksYygzNCksYygxMTcpLGMoMTk5KSxjKDEyMCksYygxMjApLGMoMTIpLGMoMTQyKSxjKDE1 NyksYyg2MSksYygyNCksYyg3MCksYygxNTUpLGMoMjE3KSxjKDE4MyksYygxNDMpLGMoMjE5KSxj KDE1OCksYyg1KSxjKDI0MSksYygxMTQpLGMoNjApLGMoNzcpLGMoMjM3KSxjKDUyKSxjKDE3NCks YygyNTEpLGMoMjMyKSxjKDI0OSksYygxODYpLGMoMzEpLGMoMTcyKSxjKDEzMyksYygxMiksYyg1 MyksYygxOTgpLGMoMjgpLGMoODcpLGMoNDMpLGMoOTcpLGMoNiksYygxNTEpLGMoMjApLGMoMjcp LGMoMSksYygxNDIpLGMoMTUxKSxjKDczKSxjKDU5KSxjKDE0MCksYygyMzgpLGMoMTAwKSxjKDE1 MSksYygxNTkpLGMoMTE4KSxjKDE0MCksYygxMDApLGMoMTQ3KSxjKDIzMiksYyg5KSxjKDc0KSxj KDY4KSxjKDMwKSxjKDEwNiksYygxNDcpLGMoMTIzKSxjKDI4KSxjKDIzNyksYygyMzMpLGMoMjQ1 KSxjKDE4MyksYygxMjQpLGMoNTkpLGMoMjMzKSxjKDEzNSksYygyMjkpLGMoMjkpLGMoMTE5KSxj KDc0KSxjKDIwNiksYyg5NSksYygxNDIpLGMoMTA5KSxjKDIyNSksYyg5NSksYygxMTEpLGMoMTY4 KSxjKDE1NSksYyg1OSksYygxODYpLGMoNjcpLGMoODEpLGMoODcpLGMoMTE3KSxjKDI0NCksYygy NTMpLGMoMjEzKSxjKDg2KSxjKDczKSxjKDE4MCksYygzNyksYyg4NCksYygzKSxjKDYwKSxjKDE3 NSksYygxNjApLGMoMTA1KSxjKDEwMiksYygxMzEpLGMoMTQpLGMoMTY4KSxjKDYxKSxjKDQ2KSxj KDY4KSxjKDQ3KSxjKDIxNyksYyg3MiksYygzOCksYygxMTkpLGMoMTM0KSxjKDI1NCksYygxNzgp LGMoMTIzKSxjKDEwMCksYygzOCksYyg0OCksYyg3MSksYyg0NCksYygxMjcpLGMoMTkxKSxjKDIy NyksYygyMyksYygxNiksYygyMzEpLGMoNCksYygxNzEpLGMoMTUxKSxjKDY5KSxjKDEzOSksYygx NDgpLGMoMjE2KSxjKDI0NiksYygyNTMpLGMoMTY0KSxjKDEwMSksYygxNSksYygyMjMpLGMoOTgp LGMoMTQpLGMoMTgzKSxjKDEwNiksYygxNjApLGMoODcpLGMoMjQ1KSxjKDQ1KSxjKDMxKSxjKDEw MiksYygxMTgpLGMoMjA5KSxjKDE1NyksYyg3NiksYyg0OSksYygxNjkpLGMoMTAzKSxjKDE3MCks YygyMzYpLGMoNjEpLGMoMTMpLGMoMjUzKSxjKDE0OCksYygzMSksYygyNDUpLGMoMjA1KSxjKDI3 KSxjKDIwNCksYygxOTQpLGMoNjcpLGMoMTExKSxjKDExOSksYyg2OSksYygxNTcpLGMoMTAwKSxj KDEwNSksYygyMTApLGMoNDcpLGMoOCksYygxMzMpLGMoMTgyKSxjKDI0OSksYyg4MCksYygxKSxj KDcpLGMoMjExKSxjKDE2NCksYygyNiksYygyMzYpLGMoNjMpLGMoMTYyKSxjKDk5KSxjKDc2KSxj KDE3NCksYyg3MyksYygxMTMpLGMoNDcpLGMoNDApLGMoNTUpLGMoODApLGMoMTM5KSxjKDEwMiks YygyMTUpLGMoMTcpLGMoMTU4KSxjKDE0OSksYyg3OSksYyg5MiksYygyNDIpLGMoMTc0KSxjKDIx MyksYygyMyksYygxMTApLGMoMjApLGMoMjUyKSxjKDE0KSxjKDEyNyksYygxNjkpLGMoMTQzKSxj KDExNiksYyg1NSksYygzNiksYygyMjkpLGMoMTg5KSxjKDIwMiksYygyMzUpLGMoMTQwKSxjKDEy OSksYygyMzYpLGMoMTE1KSxjKDkwKSxjKDE1OSksYygxNTIpLGMoMjQ4KSxjKDE5NCksYygxNjEp LGMoOTcpLGMoNDApLGMoNDQpLGMoNDApLGMoMzkpLGMoMTM4KSxjKDE0MCksYygyNTMpLGMoMjAy KSxjKDIzMSksYygyMCksYygyMjIpLGMoMjAxKSxjKDIzMCksYygxMDIpLGMoMTI2KSxjKDg1KSxj KDE2MyksYygxNiksYygxODQpLGMoMTk2KSxjKDQpLGMoNiksYygyMTQpLGMoMTApLGMoMjI2KSxj KDEwKSxjKDg1KSxjKDI0NyksYyg1MiksYyg4MSksYygzNCksYygyMzIpLGMoMzEpLGMoNyksYygx MDIpLGMoMTI1KSxjKDE1OCksYygyMjYpLGMoNTEpLGMoODUpLGMoMjMyKSxjKDI1MSksYygyMTQp LGMoMTE1KSxjKDIwMiksYygxNTEpLGMoMjM5KSxjKDExMCksYygxNjgpLGMoNzMpLGMoMTYyKSxj KDcyKSxjKDM5KSxjKDczKSxjKDE1NiksYygxMDgpLGMoMTcxKSxjKDU5KSxjKDI0NCksYygzMCks YygxNDMpLGMoMTApLGMoNDIpLGMoMTYzKSxjKDExOSksYygxMDEpLGMoMzMpLGMoNDYpLGMoMTQ5 KSxjKDE5MyksYygxMDIpLGMoODApLGMoMTMwKSxjKDEwNSksYygyMTQpLGMoMTUwKSxjKDEyMSks Yyg0NCksYygxMDcpLGMoMzYpLGMoMTI5KSxjKDkpLGMoMTY0KSxjKDIzMSksYygyMzEpLGMoMjYp LGMoMTMxKSxjKDE5NiksYygyMzEpLGMoNDgpLGMoNjkpLGMoOTUpLGMoMjA4KSxjKDE5MCksYygx NDEpLGMoOTMpLGMoNjUpLGMoMTYwKSxjKDI0KSxjKDk3KSxjKDE5MCksYygxMTgpLGMoNDcpLGMo MTgzKSxjKDMyKSxjKDIyMSksYygyNTUpLGMoMTc5KSxjKDkpLGMoNDUpLGMoMjM4KSxjKDIzMSks YygyMSksYygxMDkpLGMoMjMzKSxjKDEzMiksYygyMzgpLGMoNjIpLGMoMTApLGMoMTI2KSxjKDcp LGMoMjQ2KSxjKDc0KSxjKDIwKSxjKDM3KSxjKDIzOCksYygxOCksYyg0NyksYygxOSksYygyMjMp LGMoMTI0KSxjKDE2OSksYygxNjkpLGMoMjE1KSxjKDIzOSksYygyMzMpLGMoNTkpLGMoMjM4KSxj KDI0MyksYygxMTUpLGMoMTAzKSxjKDIzNCksYygxOCksYygxMiksYygxMzIpLGMoMzMpLGMoMTUy KSxjKDIwNCksYygxOTMpLGMoMjkpLGMoNiksYygxOTUpLGMoNDgpLGMoMjA5KSxjKDMwKSxjKDY3 KSxjKDI0OSksYygyNDApLGMoMTQ3KSxjKDExNCksYyg3KSxjKDIxNCksYygxNDEpLGMoMTg4KSxj KDUyKSxjKDEyMSksYyg2OCksYygzNSksYygxNjgpLGMoMTg0KSxjKDY5KSxjKDIwKSxjKDI2KSxj KDU3KSxjKDI0NCksYygxOTApLGMoMTc2KSxjKDE0KSxjKDIzMCksYyg5OCksYygyMjApLGMoNTUp LGMoMTcpLGMoODMpLGMoMjE4KSxjKDQpLGMoMzkpLGMoNDIpLGMoMTExKSxjKDEzNyksYygxMzMp LGMoMTA5KSxjKDIwKSxjKDE4MSksYyg0MSksYygyMzgpLGMoMTQ5KSxjKDE5NCksYygyNDApLGMo MTgzKSxjKDcwKSxjKDk3KSxjKDQzKSxjKDU1KSxjKDUyKSxjKDIyNSksYygxMDMpLGMoMTc0KSxj KDIxMiksYygyMjgpLGMoNzApLGMoMjMzKSxjKDY3KSxjKDE2OSksYygxNjUpLGMoMTM0KSxjKDE4 OCksYygxNCksYygyMTgpLGMoMTgyKSxjKDIxNCksYygyNCksYygxMiksYygxMzApLGMoMTkzKSxj KDI0OSksYygyMCksYyg3MiksYygxMTgpLGMoMCksYygxODEpLGMoNjkpLGMoMTc1KSxjKDE0Niks YygzMiksYygzOSksYygxNCksYygyNDIpLGMoODEpLGMoMTA2KSxjKDI1KSxjKDEyNCksYyg0MCks YygyMTQpLGMoMTIpLGMoMjQ2KSxjKDE1KSxjKDE2NiksYyg2NiksYyg1MyksYygxNDEpLGMoMTEz KSxjKDc5KSxjKDI0MCksYyg1MiksYygyMzkpLGMoMTA5KSxjKDIzNSksYygyNDYpLGMoMTUwKSxj KDE4OSksYyg2NSksYygxMjgpLGMoMTI1KSxjKDE2NyksYygyMjIpLGMoMjgpLGMoNjkpLGMoMjUp LGMoMzUpLGMoMTk3KSxjKDI2KSxjKDEwMSksYygxNDcpLGMoMTA2KSxjKDEzMCksYygxOTYpLGMo MTIwKSxjKDMyKSxjKDk3KSxjKDIpLGMoMTY5KSxjKDIyNyksYygyMzMpLGMoMjIyKSxjKDU0KSxj KDE3MyksYygxNCksYygyMDcpLGMoOTUpLGMoNDQpLGMoMjA3KSxjKDE3MyksYygyMjIpLGMoMTQz KSxjKDE0MSksYygyMjgpLGMoMTkxKSxjKDgpLGMoMTg3KSxjKDYxKSxjKDEyMiksYygxODEpLGMo ODMpLGMoNjYpLGMoMTAzKSxjKDU5KSxjKDE1NyksYygyNDMpLGMoNzcpLGMoMTg0KSxjKDIyNyks YygxNjApLGMoMTk4KSxjKDEyNSksYygyMTcpLGMoNjApLGMoMTU5KSxjKDIxNyksYygxMDEpLGMo ODUpLGMoNTUpLGMoMjApLGMoNjApLGMoNDIpLGMoMjExKSxjKDk4KSxjKDIzMyksYygxNjkpLGMo MTUpLGMoMTYwKSxjKDcxKSxjKDEyNCksYygzNCksYygxNzgpLGMoMTE4KSxjKDI0KSxjKDE2Niks YygxODcpLGMoMTYwKSxjKDIxOCksYygzMSksYygyNDEpLGMoMTg2KSxjKDU4KSxjKDE1MCksYygy MzApLGMoMTAzKSxjKDIzNiksYyg1MiksYygyNSksYyg0OSksYygyMTUpLGMoMTQpLGMoMjgpLGMo MjQpLGMoMjE2KSxjKDIxNSksYygyMDQpLGMoODgpLGMoMzQpLGMoMTU0KSxjKDYyKSxjKDMyKSxj KDY5KSxjKDE2KSxjKDEyNiksYygxMTIpLGMoMTE3KSxjKDExMCksYygyNDgpLGMoMTMwKSxjKDEy KSxjKDk4KSxjKDE1NSksYyg2NiksYygxMDUpLGMoMjQ3KSxjKDE0OCksYygyMzMpLGMoMTg4KSxj KDQ0KSxjKDE1MSksYygxMDcpLGMoMzkpLGMoMjEpLGMoMTk4KSxjKDMwKSxjKDIyNiksYyg4Nyks YygxKSxjKDE3NyksYyg1OCksYyg1MSksYygxMzUpLGMoODkpLGMoMTM4KSxjKDE1NiksYygxODEp LGMoMjApLGMoNzcpLGMoMjU0KSxjKDE2OCksYyg3NSksYygyMDIpLGMoMzMpLGMoMzMpLGMoMjMx KSxjKDcpLGMoMTgzKSxjKDU1KSxjKDE1MSksYygxNjgpLGMoODQpLGMoNzQpLGMoMTk5KSxjKDEw NyksYygxMDYpLGMoMjQ4KSxjKDI0OCksYygyMTApLGMoNTYpLGMoMjAzKSxjKDEyNiksYygyMyks YygyMjIpLGMoMTE1KSxjKDE0OCksYyg0OCksYyg2KSxjKDIpLGMoMTc0KSxjKDIyMyksYyg3OCks Yyg2MSksYygyMTYpLGMoOTcpLGMoMTE5KSxjKDkyKSxjKDE3MyksYyg5OSksYyg5OSksYygzMyks YygyMjkpLGMoMjQ5KSxjKDE0NSksYygxOTcpLGMoMTApLGMoODkpLGMoMjI2KSxjKDI1MCksYyg2 KSxjKDE4MCksYygxMTcpLGMoMTM0KSxjKDE2OCksYygyMTMpLGMoNDkpLGMoMTUwKSxjKDEzNCks YygyKSxjKDI0MiksYyg3NSksYygxMjMpLGMoMTUxKSxjKDE1KSxjKDE1OSksYygyMDMpLGMoMjQ1 KSxjKDgwKSxjKDI0NCksYygxNTkpLGMoNDcpLGMoMjQ0KSxjKDk4KSxjKDY3KSxjKDI1MSksYygx NjgpLGMoMTM1KSxjKDE2KSxjKDI0NyksYygxMDEpLGMoNDMpLGMoMTE3KSxjKDE4MCksYygxNCks YygzNCksYyg1MyksYygxNjQpLGMoMjIyKSxjKDIyOSksYygxMTMpLGMoMTI5KSxjKDEyMSksYygx MjEpLGMoMjI5KSxjKDE2NiksYygyNDApLGMoMTkzKSxjKDEzOSksYyg2NiksYyg3NCksYyg4NSks YygxMSksYygyMjUpLGMoNiksYygyNTEpLGMoMTUwKSxjKDkpLGMoMTUzKSxjKDg4KSxjKDI3KSxj KDU0KSxjKDU1KSxjKDE1OCksYygxNyksYyg4MyksYygxNCksYyg2MiksYygxNTYpLGMoMTYyKSxj KDE4KSxjKDE3KSxjKDIyNSksYygyMDEpLGMoODEpLGMoNzcpLGMoMjUzKSxjKDE0OCksYyg0Myks YygzOSksYygxNzcpLGMoMTk1KSxjKDIxNiksYygxMDcpLGMoMTUxKSxjKDI3KSxjKDMpLGMoMjE0 KSxjKDEyMyksYygxODApLGMoMzUpLGMoODEpLGMoMjM5KSxjKDkpLGMoMTg5KSxjKDIxNiksYygx NjApLGMoMTA5KSxjKDUxKSxjKDIzNiksYygyMzcpLGMoODQpLGMoMSksYygxMDQpLGMoMjU0KSxj KDE3NiksYyg1OSksYygxMDkpLGMoMjI5KSxjKDUzKSxjKDczKSxjKDkpLGMoMTcpLGMoMTE4KSxj KDcwKSxjKDYzKSxjKDE1NyksYyg3NSksYygxNDMpLGMoMTQwKSxjKDE1MCksYygxNzgpLGMoMTg4 KSxjKDc0KSxjKDUzKSxjKDE1OCksYygxNDcpLGMoNjIpLGMoMzMpLGMoMTczKSxjKDE3NyksYygz KSxjKDE2MiksYygxMjUpLGMoMTIpLGMoMzEpLGMoMjQyKSxjKDE5MiksYygxMDApLGMoMTk5KSxj KDI2KSxjKDIyMyksYygyMTApLGMoNjUpLGMoMjAxKSxjKDEyNSksYygxNzkpLGMoODQpLGMoNTAp LGMoMTM0KSxjKDIyOCksYygxMTQpLGMoMTkpLGMoMjA3KSxjKDE2NyksYyg5NSksYygxODcpLGMo MTUwKSxjKDg1KSxjKDEwKSxjKDUpLGMoNDcpLGMoMjQwKSxjKDQ5KSxjKDEyOSksYygxNTUpLGMo NTQpLGMoMTA1KSxjKDEyNiksYygyMTYpLGMoMjUwKSxjKDI0NCksYygxOTgpLGMoMTM5KSxjKDY0 KSxjKDEyKSxjKDQ0KSxjKDEyOCksYyg1MCksYyg2OCksYyg3NyksYyg3NSksYyg4MiksYygxNTEp LGMoMTUxKSxjKDIwKSxjKDU1KSxjKDIwMiksYygxNjMpLGMoMTk5KSxjKDE3MSksYyg5NCksYygx KSxjKDIwOSksYygxODIpLGMoMTIwKSxjKDQxKSxjKDE0KSxjKDEwOCksYygyMzIpLGMoMjEzKSxj KDEyNCksYygzOSksYygyMDMpLGMoMjU1KSxjKDIwMSksYygyMzkpLGMoMTApLGMoOTgpLGMoMzcp LGMoMTkpLGMoMjA3KSxjKDIxMSksYygyMTUpLGMoMTIxKSxjKDU2KSxjKDExNCksYyg3KSxjKDIz OSksYygxODIpLGMoMjQ1KSxjKDE0OCksYyg0MiksYygxMjApLGMoMTcwKSxjKDIxMCksYygxNiks YygxMTIpLGMoMjUzKSxjKDExKSxjKDIxMiksYygxMDUpLGMoNzgpLGMoMTE1KSxjKDE3NyksYygx NjApLGMoMjkpLGMoMjQ5KSxjKDE1MSksYygxMzMpLGMoMTI4KSxjKDEzNyksYygyMjcpLGMoMTI1 KSxjKDIyMiksYygyMzkpLGMoMjI2KSxjKDIwOCksYygxMyksYyg3OSksYygxMTQpLGMoMjQ0KSxj KDIwNyksYygyMjUpLGMoMjAzKSxjKDEyMSksYygxNjApLGMoMzcpLGMoMjEzKSxjKDIyOCksYyg0 OSksYygyMTEpLGMoMTQpLGMoMjgpLGMoMzkpLGMoMTM0KSxjKDIwKSxjKDIzNiksYygxMTgpLGMo OSksYygxNDYpLGMoNTIpLGMoMjEpLGMoMjA0KSxjKDExNiksYyg3MSksYyg2MSksYygyMDApLGMo MTc0KSxjKDY4KSxjKDc0KSxjKDE1MyksYygyMTUpLGMoMTgwKSxjKDE5NSksYygxOTcpLGMoMjYp LGMoMTU0KSxjKDk2KSxjKDg3KSxjKDcwKSxjKDE1MyksYygyMTcpLGMoNTMpLGMoMjEwKSxjKDU0 KSxjKDEwNiksYygxODQpLGMoMjM5KSxjKDEwMCksYygyMTEpLGMoMjQwKSxjKDE3MSksYyg0Myks YygyNTUpLGMoMTUwKSxjKDMwKSxjKDI0MyksYyg2OCksYyg2KSxjKDEwMiksYygxOTMpLGMoMTYz KSxjKDEwOSksYygyMyksYyg5MSksYygyNTQpLGMoOTYpLGMoMTcpLGMoMjQ0KSxjKDEwNiksYyg0 NiksYygxOTApLGMoMTkyKSxjKDQzKSxjKDIyOCksYygzMCksYygyMDEpLGMoOTYpLGMoMjU0KSxj KDI0NiksYyg3NyksYygxOTMpLGMoNzgpLGMoMTM1KSxjKDI0OSksYyg5OCksYygxMyksYygxNzAp LGMoMjIzKSxjKDU0KSxjKDEwNiksYyg3KSxjKDApLGMoNCksYygyMjkpLGMoMTk4KSxjKDUxKSxj KDEzOSksYygxNDYpLGMoNDEpLGMoNDIpLGMoNDQpLGMoMTkwKSxjKDE1MiksYygxNjkpLGMoNDQp LGMoMTU4KSxjKDE2MyksYygxNzYpLGMoMjMzKSxjKDYwKSxjKDE5NCksYyg1OCksYygyMjIpLGMo MTc0KSxjKDE5KSxjKDY3KSxjKDEzOSksYygyMjMpLGMoMTk4KSxjKDEwNSksYygxNzMpLGMoMTM0 KSxjKDE0NCksYygxMTYpLGMoODMpLGMoMjI5KSxjKDI0NyksYyg5MCksYygyNDApLGMoMjMzKSxj KDExMiksYygxODgpLGMoMTkwKSxjKDIzNCksYygxNzIpLGMoMjM5KSxjKDI4KSxjKDQwKSxjKDEy NCksYygyMzcpLGMoODkpLGMoMTIzKSxjKDApLGMoNTgpLGMoMjEyKSxjKDEzNyksYygxNzUpLGMo MjA2KSxjKDQzKSxjKDE3MyksYygxNjApLGMoMjMpLGMoMTA3KSxjKDU2KSxjKDIpLGMoOTIpLGMo MTcyKSxjKDIzMyksYygxMDYpLGMoMTY5KSxjKDE5NyksYygxNzcpLGMoMzApLGMoODQpLGMoMjQ4 KSxjKDE4MyksYygxNSksYygyNDMpLGMoMTI4KSxjKDExKSxjKDUxKSxjKDExMyksYygyMjUpLGMo MjUyKSxjKDE1NyksYygyNDgpLGMoMTk4KSxjKDI1KSxjKDI1MCksYygyMjMpLGMoMTA5KSxjKDIz NSksYygyNyksYygxOTUpLGMoMTQzKSxjKDEyKSxjKDM5KSxjKDEwMSksYygxNjgpLGMoMjA0KSxj KDIzNiksYygxMzEpLGMoMjIyKSxjKDE5MSksYygxNzIpLGMoNzgpLGMoOTgpLGMoMTM1KSxjKDg5 KSxjKDIxNSksYygyNDUpLGMoOTEpLGMoNzEpLGMoMjA1KSxjKDEwOCksYygxMDApLGMoMTMpLGMo OTYpLGMoMTIyKSxjKDE2NCksYygxODMpLGMoMTc3KSxjKDEpLGMoNDkpLGMoMjE1KSxjKDg4KSxj KDI0NSksYyg1OSksYygxODMpLGMoNjIpLGMoMTk5KSxjKDEwMiksYygxMjUpLGMoMTExKSxjKDE3 MCksYygxMzcpLGMoMTc4KSxjKDE2OSksYygxODEpLGMoNDgpLGMoMzkpLGMoNjkpLGMoMzYpLGMo NDcpLGMoNjEpLGMoNDIpLGMoMTE1KSxjKDIyNyksYyg2NyksYygxNjQpLGMoMTY4KSxjKDEzNSks YygyMTMpLGMoNTcpLGMoMTMxKSxjKDI0NiksYyg1MiksYygyMjkpLGMoNjIpLGMoNjApLGMoNTEp LGMoMTU3KSxjKDIyOCksYygxNDQpLGMoODEpLGMoMTg1KSxjKDIzNCksYyg0OCksYyg0MyksYygz MyksYygyMjEpLGMoMjQwKSxjKDEzMSksYygxMjIpLGMoMTI2KSxjKDQzKSxjKDE2NSksYyg4Nyks YygxODMpLGMoMjExKSxjKDg1KSxjKDI0NCksYygyMjIpLGMoMjA0KSxjKDE2KSxjKDEzMCksYyg0 NiksYygyMzEpLGMoNDcpLGMoMjUyKSxjKDEzMSksYygyOCksYyg3NCksYyg0OSksYygyNDApLGMo MTgpLGMoMjA4KSxjKDE4MyksYygzKSxjKDIxMyksYyg3NSksYygyMjUpLGMoMjE1KSxjKDI0MSks YygyNDgpLGMoOTgpLGMoMTYzKSxjKDc5KSxjKDIyNiksYyg3KSxjKDIwOCksYyg3MyksYygyNyks YygyMjcpLGMoMTQzKSxjKDE5MyksYygyMzgpLGMoNCksYygxOTIpLGMoNSksYyg5OSksYygxMzQp LGMoNjUpLGMoODEpLGMoMjMpLGMoOTkpLGMoMTk0KSxjKDE0OSksYygxMDUpLGMoMTUwKSxjKDE1 NCksYygxNDgpLGMoOTYpLGMoMTQ3KSxjKDE4MCksYygyMzEpLGMoNTMpLGMoNzApLGMoNzcpLGMo NjkpLGMoMjgpLGMoMjA0KSxjKDEwMiksYygyNSksYyg5MSksYygyMjUpLGMoOTgpLGMoMjEyKSxj KDYxKSxjKDExMiksYyg5MCksYygxNDkpLGMoNTUpLGMoMTQ4KSxjKDgxKSxjKDIzMSksYygzMyks Yyg5MSksYygxMDUpLGMoMTM4KSxjKDkxKSxjKDE0KSxjKDY1KSxjKDEwNCksYygxOTcpLGMoMTcp LGMoMzkpLGMoMTk2KSxjKDEwMiksYygxNTgpLGMoODUpLGMoMTExKSxjKDE2KSxjKDIzKSxjKDUy KSxjKDIwOCksYygwKSxjKDE2MSksYygyMDYpLGMoMTY0KSxjKDU0KSxjKDgwKSxjKDIyKSxjKDQ3 KSxjKDE0MCksYygxMDApLGMoMjA0KSxjKDYzKSxjKDEyNiksYygxNTkpLGMoMTA3KSxjKDM2KSxj KDEyMiksYygxNyksYygxMjMpLGMoMTUzKSxjKDcpLGMoMiksYygxNTUpLGMoMTI5KSxjKDk0KSxj KDcxKSxjKDE3MyksYygyNiksYygyMSksYygyMjIpLGMoMjcpLGMoNiksYygxMTkpLGMoMTcxKSxj KDE3OSksYyg4MiksYygyMzUpLGMoMzkpLGMoNjcpLGMoMzgpLGMoMTIpLGMoMiksYygxNjIpLGMo NjEpLGMoMjIpLGMoMyksYygxODIpLGMoMjIyKSxjKDE0MCksYygzMCksYygzOCksYyg2NyksYygx NzgpLGMoMjQ0KSxjKDc5KSxjKDI0NyksYyg0OSksYygxMjkpLGMoMTI1KSxjKDIzOCksYygxMTgp LGMoMTEzKSxjKDIwMSksYygxNzMpLGMoMTg0KSxjKDY2KSxjKDcpLGMoMjAyKSxjKDkxKSxjKDE5 MyksYygxODkpLGMoMTM2KSxjKDE0MiksYygxNjQpLGMoMTA1KSxjKDEzNCksYygyNDgpLGMoMTMp LGMoMTc2KSxjKDkyKSxjKDE3NCksYygxMDYpLGMoNTUpLGMoMjU1KSxjKDIwOSksYygwKSxjKDEx NCksYygyMjUpLGMoMjA0KSxjKDE1NiksYyg5NiksYygyMzUpLGMoMTI2KSxjKDYxKSxjKDQyKSxj KDIwOCksYyg5MiksYygxNzIpLGMoMTI5KSxjKDIzOCksYyg0NSksYygxMDgpLGMoMzYpLGMoMTE4 KSxjKDE0KSxjKDE0OSksYygxNzgpLGMoMjA1KSxjKDkyKSxjKDIzNyksYygxNDYpLGMoMTUzKSxj KDE4NyksYygxMTcpLGMoMTQxKSxjKDYzKSxjKDg5KSxjKDE1NiksYygxNDApLGMoMTA1KSxjKDIx MiksYygxMiksYygzMSksYyg3KSxjKDEzMiksYygyMDApLGMoMTQ2KSxjKDIwKSxjKDEwNiksYyg3 OSksYygyNCksYygyMzgpLGMoNDYpLGMoOTIpLGMoMjI4KSxjKDk2KSxjKDIxMSksYyg3NiksYygx MDgpLGMoMTc5KSxjKDE5MSksYygyMTQpLGMoOTIpLGMoOTkpLGMoMjQ1KSxjKDgwKSxjKDM0KSxj KDYzKSxjKDIzMSksYygxMTYpLGMoMTE3KSxjKDIxMiksYygxMjApLGMoMjA3KSxjKDQ3KSxjKDc4 KSxjKDIzOCksYygyMDApLGMoMjI3KSxjKDczKSxjKDk1KSxjKDEyMSksYyg3NyksYygxNjMpLGMo MjMpLGMoOTkpLGMoMTQ3KSxjKDM0KSxjKDEzNyksYygyNCksYygxMTkpLGMoMTIwKSxjKDIzMiks Yyg2MSksYygyMzgpLGMoMTA3KSxjKDEwNSksYygyMjApLGMoMjMyKSxjKDExKSxjKDI0NyksYygx NjEpLGMoMTA5KSxjKDU2KSxjKDEzNSksYygyMjQpLGMoNDIpLGMoMTE5KSxjKDEwOSksYygyNDcp LGMoNDIpLGMoMTAyKSxjKDEyMSksYygyNyksYygyNDUpLGMoMTgxKSxjKDU4KSxjKDc4KSxjKDIw MyksYygzMCksYygxMDMpLGMoOTApLGMoMTU5KSxjKDEzMCksYygxMjMpLGMoMTE5KSxjKDU1KSxj KDIzKSxjKDI0MSksYygxMzQpLGMoMjI0KSxjKDIyNSksYygzNyksYyg0MiksYygxMzQpLGMoMzkp LGMoMTE5KSxjKDM3KSxjKDIzNiksYygxMjUpLGMoMTE3KSxjKDI0OCksYygxNjMpLGMoMzgpLGMo MjE0KSxjKDE2MSksYygyMDApLGMoMTAzKSxjKDEyMSksYygxMjUpLGMoMjI1KSxjKDE2MCksYygz MSksYygxMzMpLGMoMzcpLGMoMTUwKSxjKDE0MiksYygyMjIpLGMoMTAzKSxjKDIyMiksYyg3Miks YygyNTEpLGMoMTI2KSxjKDE5NCksYygxMDEpLGMoNjQpLGMoMjMyKSxjKDEwNyksYyg2NCksYyg1 MSksYyg0MiksYygyNTUpLGMoMjM2KSxjKDgzKSxjKDE3MyksYyg1KSxjKDY1KSxjKDc4KSxjKDc5 KSxjKDE1OSksYyg5KSxjKDMzKSxjKDQwKSxjKDE1MSksYyg2KSxjKDEyOSksYyg1OCksYyg2Myks Yyg3KSxjKDE4MSksYyg1OCksYygyNSksYygyMjQpLGMoMjA4KSxjKDMpLGMoMTIyKSxjKDU0KSxj KDg3KSxjKDIzMyksYyg3NiksYyg0OCksYygyMTgpLGMoNTgpLGMoNDMpLGMoOTkpLGMoNjgpLGMo MjIzKSxjKDUpLGMoMTMzKSxjKDIwOCksYygxNDYpLGMoMjQzKSxjKDIwOCksYygxOTApLGMoMTA5 KSxjKDIyMCksYygyNiksYygyNDgpLGMoMjQ2KSxjKDI1NSksYygxNSksYygxNDkpLGMoMTgyKSxj KDI1NCksYyg2KSxjKDIwKSxjKDUzKSxjKDE1MSksYygxNTMpLGMoMjAxKSxjKDI0OSksYygxNTcp LGMoNSksYygyNTApLGMoMTY0KSxjKDYpLGMoNjQpLGMoMTY4KSxjKDM5KSxjKDM0KSxjKDEwOSks YygxMDIpLGMoMTA1KSxjKDE0MyksYygyKSxjKDE0NiksYygyNDApLGMoNjEpLGMoMjcpLGMoMzIp LGMoODYpLGMoNTYpLGMoMjEyKSxjKDcyKSxjKDE3NiksYygxOSksYygyMyksYygzMiksYygxMjYp LGMoNDUpLGMoMjM0KSxjKDMyKSxjKDE2OSksYygyMDQpLGMoMzIpLGMoMTU4KSxjKDE0MCksYyg1 OCksYygyMTkpLGMoMTQyKSxjKDIyMSksYygzMiksYyg2OCksYygxODQpLGMoMTQ1KSxjKDE1Nyks YygxODkpLGMoMTg1KSxjKDIzNiksYyg5NyksYygxNjEpLGMoMTg3KSxjKDE2OSksYygxMDApLGMo NjYpLGMoMiksYyg2NyksYygxOTEpLGMoMzgpLGMoNzcpLGMoMTg3KSxjKDEzNyksYygxMDMpLGMo MTM0KSxjKDIpLGMoMjIwKSxjKDg5KSxjKDIyNiksYyg4OSksYygxNjMpLGMoNzMpLGMoMzgpLGMo MTIpLGMoMTgxKSxjKDg4KSxjKDE5OSksYygyNDYpLGMoOTMpLGMoODgpLGMoMTc1KSxjKDIzNyks Yyg0MCksYyg1MiksYyg2NyksYygxNTIpLGMoMjM0KSxjKDI0MyksYygyOSksYygyMDgpLGMoMjEx KSxjKDIwNSksYygyKSxjKDgpLGMoMTYzKSxjKDc4KSxjKDI0OCksYygxNzEpLGMoNzYpLGMoMTA0 KSxjKDE4NCksYygxMzIpLGMoMTE2KSxjKDEpLGMoMTk3KSxjKDE1NSksYygyNDcpLGMoMTM2KSxj KDQ0KSxjKDY1KSxjKDE3NCksYyg1OCksYyg3NSksYyg5NCksYygxNTApLGMoODYpLGMoMTY4KSxj KDExNSksYygxMTQpLGMoMTYpLGMoMTEzKSxjKDQ1KSxjKDIwOCksYyg1MSksYygxMjApLGMoOTMp LGMoMTUxKSxjKDExNCksYygzOCksYygxMDYpLGMoMjUwKSxjKDE2MCksYygxNjkpLGMoMjA0KSxj KDk5KSxjKDE1NCksYygxNTkpLGMoMTEzKSxjKDYxKSxjKDExOCksYygxNjEpLGMoNDYpLGMoNjMp LGMoMTQpLGMoOTUpLGMoMjA2KSxjKDIzNiksYygxNDkpLGMoMTM4KSxjKDEyOCksYygxOTEpLGMo MjU0KSxjKDI5KSxjKDE1OCksYygxNjkpLGMoODEpLGMoNTgpLGMoMTYzKSxjKDg0KSxjKDUyKSxj KDE1KSxjKDE3NSksYyg5OSksYygxNiksYygxNTIpLGMoMTY0KSxjKDE3NSksYygyMyksYyg2MSks YygyMDQpLGMoNDYpLGMoMTgpLGMoMTQyKSxjKDY1KSxjKDEyNSksYygxNDApLGMoMTg0KSxjKDIy NSksYygxNTcpLGMoNiksYygxNDYpLGMoNzMpLGMoMjM1KSxjKDMzKSxjKDU3KSxjKDE0OCksYygz NiksYyg3MyksYyg1NyksYygyMjUpLGMoNDYpLGMoMTQ3KSxjKDIxNiksYygyNDcpLGMoMTgxKSxj KDIxMyksYygyMzMpLGMoNSksYygxMTMpLGMoMzQpLGMoMjQyKSxjKDIwNyksYygzMSksYygxNjQp LGMoMjMwKSxjKDE4KSxjKDE5MiksYygxMDQpLGMoMTAwKSxjKDQ3KSxjKDgwKSxjKDM1KSxjKDM2 KSxjKDE0MCksYygxODMpLGMoNzcpLGMoMjAyKSxjKDI1NCksYygxMDkpLGMoMTY1KSxjKDE1Myks YygyMTApLGMoMTk4KSxjKDM4KSxjKDIzOSksYygxNDUpLGMoMTY1KSxjKDI1NCksYygxNjYpLGMo MjAyKSxjKDIxOSksYygxMTUpLGMoMTMyKSxjKDE5MSksYygxKSxjKDE1MSksYygxMTUpLGMoODcp LGMoMTQxKSxjKDg2KSxjKDIzMyksYygyMjQpLGMoNjcpLGMoMTc4KSxjKDExNiksYyg1OSksYygx MzkpLGMoMTUxKSxjKDMwKSxjKDUzKSxjKDIzNCksYyg3OCksYygyMiksYyg3MyksYygyMzQpLGMo MTk2KSxjKDI1MCksYygxNTQpLGMoMTM1KSxjKDE4MiksYygxMzEpLGMoNjYpLGMoMTg5KSxjKDEy MyksYygyMDcpLGMoMTIxKSxjKDE2MiksYygxNzEpLGMoNTYpLGMoMjIxKSxjKDI0MSksYyg1Niks YygyMDMpLGMoMjU0KSxjKDI3KSxjKDE2MiksYygxODMpLGMoNTkpLGMoODIpLGMoOTkpLGMoMTM0 KSxjKDIyKSxjKDcwKSxjKDE2OCksYygyMTIpLGMoMjUyKSxjKDE1KSxjKDIzMCksYygyMDApLGMo MTEpLGMoMTIpLGMoMTcyKSxjKDE5KSxjKDIzNCksYygyMjQpLGMoMjA5KSxjKDUzKSxjKDE4NSks YygyNDUpLGMoNzQpLGMoMjUyKSxjKDMxKSxjKDIzNSksYygxNjkpLGMoMTkxKSxjKDIxOSksYygx OTUpLGMoMTE4KSxjKDc0KSxjKDU0KSxjKDI1NSksYyg5NCksYygxNTQpLGMoMjQwKSxjKDEzMSks YygxNjMpLGMoNTQpLGMoNTkpLGMoMTc0KSxjKDkwKSxjKDMwKSxjKDIyNSksYyg1MyksYygxMTgp LGMoMTI2KSxjKDIzNCksYygyMjcpLGMoNTYpLGMoMjUwKSxjKDE3MCksYygxNjQpLGMoNDApLGMo MTY1KSxjKDE0MCksYygyNTUpLGMoMjA0KSxjKDU4KSxjKDE4OSksYygxMiksYygxOTkpLGMoMTI3 KSxjKDYpLGMoMjE3KSxjKDkpLGMoMjMyKSxjKDIzOSksYygxMjgpLGMoMTA0KSxjKDIyKSxjKDE5 MSksYygxNTQpLGMoOSksYyg0MiksYygzMSksYygyMSksYygxMDgpLGMoMjE5KSxjKDkzKSxjKDEw OCksYygxMDgpLGMoMTApLGMoMTk0KSxjKDIwMCksYygxNCksYygyMzIpLGMoMjIyKSxjKDI1NSks YygyMzUpLGMoMjE5KSxjKDEwNSksYygxNyksYygxNDQpLGMoMTQ2KSxjKDYxKSxjKDUxKSxjKDI0 OCksYygxOCksYygzMCksYygxMyksYyg3OCksYygxNTQpLGMoNDIpLGMoMjAwKSxjKDIzOCksYygx MjkpLGMoMzQpLGMoMjQ2KSxjKDczKSxjKDEyMCksYygzMSksYyg0NCksYygxODIpLGMoMTYwKSxj KDEwMSksYygyNDkpLGMoNiksYygxNzcpLGMoMTI1KSxjKDcyKSxjKDE4MiksYygxNjApLGMoODEp LGMoMTE5KSxjKDU4KSxjKDI0OSksYygyNTMpLGMoMjUpLGMoMjI2KSxjKDY4KSxjKDE5NyksYygx MTMpLGMoMzcpLGMoNTkpLGMoMTQ5KSxjKDI0OCksYygxNDcpLGMoNjQpLGMoMjEzKSxjKDExMSks YygxMjcpLGMoMSksYygyMTApLGMoOTApLGMoMTAyKSxjKDU3KSxjKDE0MiksYygxNTcpLGMoMTE2 KSxjKDIzMCksYygyMTkpLGMoMTM2KSxjKDUxKSxjKDIxNyksYygyNSksYygxNjgpLGMoMTAxKSxj KDEyNCksYyg5NiksYygyMTEpLGMoNDYpLGMoMTg5KSxjKDEzMiksYyg4MCksYygyNDApLGMoMTMy KSxjKDEwNCksYygxODgpLGMoOTcpLGMoMjQ4KSxjKDQpLGMoOTMpLGMoMTAzKSxjKDEzNCksYyg2 MSksYyg4MyksYyg1NyksYygxMjUpLGMoMTQyKSxjKDIwOCksYyg5NiksYygxOTEpLGMoMzkpLGMo MTU5KSxjKDE4OCksYygyMDMpLGMoMjM1KSxjKDE4MCksYygyMDUpLGMoMjMyKSxjKDE3OCksYygy OSksYygxMiksYygxNzcpLGMoMjM4KSxjKDI0KSxjKDM3KSxjKDE5MiksYyg0OCksYyg0NCksYygy MjMpLGMoODUpLGMoMTgpLGMoMTA5KSxjKDI3KSxjKDEwOCksYygxNjIpLGMoMTg4KSxjKDE0Nyks YygxMjIpLGMoMTIyKSxjKDE5MiksYygzNCksYygyNDYpLGMoMTIxKSxjKDgzKSxjKDEyOSksYyg2 NSksYygxNjEpLGMoMjE1KSxjKDI0NSksYygyMjcpLGMoNDIpLGMoMTE4KSxjKDE5NSksYygxMTUp LGMoMTEzKSxjKDUyKSxjKDIxNCksYygzMSksYyg0MyksYygyMjIpLGMoMTczKSxjKDE2KSxjKDY2 KSxjKDgzKSxjKDI1NCksYygxMTIpLGMoMjI3KSxjKDE3NCksYygxMyksYyg5NSksYygzMSksYygx MzkpLGMoMjUxKSxjKDI4KSxjKDIxNCksYygyNDYpLGMoMTkpLGMoMTgpLGMoMTUxKSxjKDE5OSks YygyMDcpLGMoMjApLGMoOTkpLGMoMTc4KSxjKDE3NCksYygxOTMpLGMoMjExKSxjKDg3KSxjKDUw KSxjKDE4OCksYygyNDApLGMoMjUxKSxjKDE0OSksYyg4NCksYygxNzQpLGMoMTU0KSxjKDIxMSks YygzOCksYyg0OSksYygyMTMpLGMoMzQpLGMoMTI0KSxjKDI0MCksYygxODIpLGMoMTU5KSxjKDc4 KSxjKDE5NCksYygxNzkpLGMoMjAxKSxjKDUpLGMoMTQpLGMoNDYpLGMoMzkpLGMoODQpLGMoMzIp LGMoMjMwKSxjKDExMCksYyg0OCksYygxOCksYygxODMpLGMoODIpLGMoNTkpLGMoNjMpLGMoMTM5 KSxjKDE1MCksYygyMzIpLGMoMjQxKSxjKDIwNSksYygxOTgpLGMoNzcpLGMoOTMpLGMoMTAyKSxj KDEyNCksYygxMDkpLGMoMjEyKSxjKDkwKSxjKDIxNCksYygyMTEpLGMoMjMpLGMoMTc1KSxjKDEw MiksYygxMzcpLGMoOTEpLGMoMjUyKSxjKDExNiksYyg0OSksYygxOTkpLGMoMjIwKSxjKDE5NSks YygxMSksYyg4NSksYygxODUpLGMoMTUyKSxjKDQxKSxjKDIxMCksYygxNTApLGMoNDkpLGMoMTY5 KSxjKDI0NiksYyg3NSksYygxMjApLGMoMTA1KSxjKDI3KSxjKDkpLGMoMTE2KSxjKDE0NyksYyg0 NiksYygxMTQpLGMoNjgpLGMoMTQ4KSxjKDEwMSksYygzNyksYygxMyksYygxMTcpLGMoMTU1KSxj KDE1OCksYygxMjUpLGMoMTI3KSxjKDIzMiksYygxNzEpLGMoMjQxKSxjKDI5KSxjKDM4KSxjKDIy NCksYygxMzQpLGMoODQpLGMoMTMxKSxjKDc3KSxjKDE0OSksYyg2MCksYyg1NCksYyg1MSksYygx NSksYyg0NCksYygxMjMpLGMoMjM3KSxjKDI1MSksYygxOTQpLGMoMTEyKSxjKDQ1KSxjKDEwKSxj KDIyMyksYygxNSksYyg1MiksYygyNiksYyg2MiksYygyNDYpLGMoMjQ4KSxjKDc4KSxjKDE1MCks Yyg4MSksYygxNjMpLGMoMTApLGMoMTgzKSxjKDIwMyksYyg1NSksYyg4MCksYygxNTkpLGMoMTQp LGMoMTMxKSxjKDE3MyksYygxMDApLGMoMjIxKSxjKDIwMSksYygxMTIpLGMoMTQwKSxjKDIyOSks YygxNzYpLGMoMTA2KSxjKDM1KSxjKDE2NSksYygzNyksYyg5NCksYyg1MyksYygyNTUpLGMoMSks YygyMDkpLGMoMjQpLGMoNDYpLGMoMjQ2KSxjKDIzKSxjKDIzNyksYygxNjkpLGMoNzIpLGMoMTQz KSxjKDIyOCksYygyMjQpLGMoOTkpLGMoODMpLGMoMjM3KSxjKDI1MyksYygyMjkpLGMoOTkpLGMo MjI2KSxjKDIwMCksYygxNjgpLGMoMTA0KSxjKDI0MSksYygxMTEpLGMoMjMwKSxjKDIxNiksYygx NjgpLGMoMTExKSxjKDEzOCksYygxMTkpLGMoMTI1KSxjKDE0NyksYygzNiksYyg1MyksYygyMDgp LGMoMjAyKSxjKDkxKSxjKDkxKSxjKDIwMiksYygyMTYpLGMoMTY5KSxjKDE4KSxjKDgwKSxjKDE0 OSksYyg0MyksYyg4MyksYyg0KSxjKDIxMyksYygxOTEpLGMoMTUpLGMoMjgpLGMoMjE5KSxjKDI0 MyksYygyMDIpLGMoMzApLGMoNDIpLGMoNzApLGMoMTUyKSxjKDIwMSksYygxODUpLGMoMjMwKSxj KDU2KSxjKDExMiksYygyMzMpLGMoMTY1KSxjKDQpLGMoMjIpLGMoNjApLGMoNzcpLGMoMjMxKSxj KDEzNyksYyg0NSksYyg2MyksYygxMDUpLGMoMTIwKSxjKDkzKSxjKDIwMyksYygxMyksYyg1Myks YygyMTMpLGMoMTcyKSxjKDEzMiksYygxMDYpLGMoMTA4KSxjKDIzKSxjKDE5NiksYygxMTUpLGMo MTU5KSxjKDE4MSksYyg1NCksYygxMTYpLGMoMjU1KSxjKDgxKSxjKDUzKSxjKDEwNCksYygyMzYp LGMoMzgpLGMoMTk1KSxjKDIwOSksYyg3MSksYyg2OCksYyg2MSksYygxMSksYygxNjUpLGMoMTQ3 KSxjKDIxNyksYygxMTUpLGMoMTg4KSxjKDI1MSksYygyMzkpLGMoMTI0KSxjKDIxNyksYygxNjAp LGMoMTA5KSxjKDE0MCksYyg0NyksYygyMzApLGMoNjQpLGMoMjA1KSxjKDE4OSksYyg3NCksYyg1 MyksYygyMDgpLGMoNzYpLGMoNzApLGMoMzkpLGMoMTAzKSxjKDEyMiksYygyMjYpLGMoMyksYygx MTApLGMoOTApLGMoMjU0KSxjKDc2KSxjKDg4KSxjKDc5KSxjKDI1KSxjKDIxNCksYyg0OCksYygy MDgpLGMoMTYyKSxjKDIyMyksYyg0MSksYygyOSksYyg1NyksYyg0NSksYyg2MCksYygyNTMpLGMo MTcyKSxjKDEwMiksYyg5MyksYygyMTQpLGMoODkpLGMoNzApLGMoMTMpLGMoNTYpLGMoMTU2KSxj KDIxNSksYyg5NiksYygyMzApLGMoMTEpLGMoNzApLGMoMzIpLGMoMTE3KSxjKDI0NCksYygyNDgp LGMoMTc0KSxjKDI0OCksYygxOTkpLGMoMTkyKSxjKDE2OSksYygyMDgpLGMoMTI1KSxjKDE5KSxj KDIyNyksYygyNTMpLGMoMTg3KSxjKDIyMCksYygyNDUpLGMoMTA3KSxjKDQpLGMoNTgpLGMoNSks Yyg0KSxjKDE5MiksYyg0MyksYygxMTQpLGMoMjAwKSxjKDIxMyksYygxNjEpLGMoMjM2KSxjKDIy MCksYygxOTkpLGMoMzIpLGMoMjE4KSxjKDIwMiksYyg0MiksYygxOTUpLGMoMzIpLGMoNzQpLGMo MjQxKSxjKDEzKSxjKDEwMiksYygxODYpLGMoMjMpLGMoMjI1KSxjKDExMSksYygyMjEpLGMoMTc3 KSxjKDE2MiksYygxNjApLGMoNTApLGMoOTApLGMoNDcpLGMoMTQ0KSxjKDEyMyksYygxMzIpLGMo MTcxKSxjKDgwKSxjKDE3NyksYygxMTMpLGMoNCksYygyMTcpLGMoMTYwKSxjKDM1KSxjKDE2OSks YygxNTUpLGMoMTYpLGMoMTEyKSxjKDIwNCksYygyMiksYygyMyksYyg0MCksYygyMzIpLGMoMTIw KSxjKDE1NyksYygyNTMpLGMoMTE0KSxjKDE2OSksYyg0NSksYygxMjkpLGMoMjEyKSxjKDE2Niks YygyMzUpLGMoMTI1KSxjKDI0NSksYygyNDYpLGMoMjgpLGMoNTcpLGMoNjYpLGMoMjE3KSxjKDEw OSksYyg1MiksYygxMjUpLGMoMTY1KSxjKDIxMyksYygxOTIpLGMoMjMwKSxjKDE5NCksYyg5MSks YygxMjMpLGMoMjYpLGMoMjIxKSxjKDI0NiksYygxNjApLGMoNCksYygxNDQpLGMoMTkwKSxjKDIx NSksYygxNDIpLGMoMTg5KSxjKDI1MyksYygyMTQpLGMoMjQ1KSxjKDEzNiksYygyNDUpLGMoMzUp LGMoMTEpLGMoMTc2KSxjKDEwNyksYygzOCksYyg0MyksYygxODUpLGMoMTM4KSxjKDkzKSxjKDEy KSxjKDEyOCksYyg3MSksYygxMjUpLGMoNjApLGMoMzMpLGMoMjQ2KSxjKDQxKSxjKDgpLGMoMjE3 KSxjKDM3KSxjKDE1MyksYygxMzQpLGMoMjYpLGMoMzEpLGMoMTgwKSxjKDUzKSxjKDQ4KSxjKDIz NyksYygxNTkpLGMoMTYzKSxjKDQyKSxjKDE5OCksYygyNDcpLGMoMTM5KSxjKDE0NyksYygxMjQp LGMoMTMxKSxjKDEyOSksYygxMzApLGMoMTA3KSxjKDEwMyksYygyNSksYygxMTUpLGMoMjQ3KSxj KDE0MSksYyg4NCksYygxNyksYyg1MiksYygxOTApLGMoMTYxKSxjKDIxNyksYygxMDgpLGMoMjUx KSxjKDE4MCksYygxODcpLGMoMTIyKSxjKDEyMCksYygyNDgpLGMoMjE2KSxjKDY4KSxjKDEwOSks YygxNzQpLGMoOTApLGMoMTg4KSxjKDI0MyksYygxOTgpLGMoMjcpLGMoMTMxKSxjKDEzNiksYygx OTIpLGMoMTQ1KSxjKDIzOSksYygyNTIpLGMoMTE1KSxjKDk1KSxjKDg1KSxjKDU4KSxjKDE0NCks Yyg1OCksYygxODcpLGMoMzUpLGMoMTg5KSxjKDE5OCksYygxNjUpLGMoMTEpLGMoNTgpLGMoMTkp LGMoMTg2KSxjKDgwKSxjKDE1NCksYyg0NiksYygyNTIpLGMoMTM1KSxjKDI5KSxjKDc4KSxjKDcw KSxjKDEwOCksYygxNTEpLGMoMTUpLGMoMTcwKSxjKDE2MyksYygzMCksYygyMzMpLGMoMjMpLGMo MzgpLGMoMTUyKSxjKDI0MyksYygxMTMpLGMoMjU1KSxjKDEwMyksYygxNDgpLGMoOTQpLGMoMjU0 KSxjKDE1MSksYyg0MSksYygyNTEpLGMoNDMpLGMoOTgpLGMoMTc3KSxjKDEzMyksYygyMjIpLGMo MjUwKSxjKDkpLGMoMTc1KSxjKDExMSksYyg3MCksYyg1MyksYygxNjEpLGMoMjM0KSxjKDE4Miks Yyg2NSksYygxMTYpLGMoMjEwKSxjKDIxKSxjKDE0OSksYyg3MiksYygxNDApLGMoMjEpLGMoNTYp LGMoMTg3KSxjKDIyOCksYyg1NCksYygxMTIpLGMoMTExKSxjKDE2NiksYygyMzQpLGMoNjIpLGMo MjQwKSxjKDExNyksYygxKSxjKDE1NSksYygxNDEpLGMoMTI2KSxjKDEwNSksYygyMyksYyg1Niks YygxODMpLGMoMTI0KSxjKDMxKSxjKDE2KSxjKDIyOCksYygyMDkpLGMoMjUpLGMoMzUpLGMoMzIp LGMoMjEpLGMoNDEpLGMoMTIpLGMoNDcpLGMoMjQ1KSxjKDk2KSxjKDUpLGMoMyksYygyNDYpLGMo MTQyKSxjKDE0NyksYygyMjApLGMoMTM2KSxjKDE0MCksYygyNSksYygyMTIpLGMoMjI1KSxjKDMy KSxjKDUzKSxjKDIzMCksYygyNTMpLGMoNzcpLGMoMTQyKSxjKDIyMCksYygxNSksYygxODEpLGMo NzkpLGMoMTMzKSxjKDE5MiksYygxMDUpLGMoMTgxKSxjKDIxNSksYygyMCksYygyKSxjKDI0MSks YygyMDcpLGMoMTE2KSxjKDEzKSxjKDg2KSxjKDEwMSksYygyMTIpLGMoMTI3KSxjKDEzMiksYygy MDkpLGMoMyksYygxMjQpLGMoNzYpLGMoMjEyKSxjKDYyKSxjKDg5KSxjKDEyNSksYygyNyksYygx MDQpLGMoMjIxKSxjKDY5KSxjKDcpLGMoMTkwKSxjKDE4OCksYygxNDEpLGMoNzQpLGMoMTA5KSxj KDIwMCksYygxODcpLGMoMTE5KSxjKDc1KSxjKDYyKSxjKDc5KSxjKDcpLGMoMTMpLGMoMTIxKSxj KDY5KSxjKDIyMyksYyg1OCksYyg4NSksYygyMjQpLGMoMjI3KSxjKDY2KSxjKDU4KSxjKDEyMCks Yyg5NyksYygyMDEpLGMoNyksYyg4MyksYygxMzEpLGMoMjEwKSxjKDI0OSksYygxOCksYygyMTEp LGMoMjQyKSxjKDkpLGMoMjMzKSxjKDUxKSxjKDE0MyksYygyNSksYygxMiksYygxMjEpLGMoMTEp LGMoMTYwKSxjKDI1NSksYyg3KSxjKDE4MiksYygyNDUpLGMoMTkwKSxjKDI1MyksYygyMjcpLGMo MTUyKSxjKDIxNyksYyg1NyksYygxNDEpLGMoOTMpLGMoODMpLGMoOTgpLGMoMTA2KSxjKDIxMCks YygxNzQpLGMoMTMzKSxjKDI0NiksYygxOTIpLGMoNDcpLGMoMjgpLGMoODkpLGMoMTY0KSxjKDE4 NCksYygyMjYpLGMoMTc2KSxjKDI0MiksYygxMjkpLGMoNDEpLGMoMjQ1KSxjKDEwNCksYygxMzEp LGMoMjQwKSxjKDcwKSxjKDExNSksYygxNiksYygxNzMpLGMoNiksYyg5NCksYygyMDApLGMoMjM1 KSxjKDE3OCksYygyOSksYygyMjcpLGMoMTkwKSxjKDEyNyksYygyMDMpLGMoOTMpLGMoNjIpLGMo MjIzKSxjKDE1NyksYyg3NyksYygxNTMpLGMoMjE5KSxjKDE4NyksYygxOTgpLGMoODEpLGMoNzQp LGMoMTQ5KSxjKDIxOSksYyg3NiksYygxMjApLGMoMTAxKSxjKDIyOCksYygyMzMpLGMoMTM3KSxj KDU3KSxjKDIyMSksYygyMyksYygzNSksYygzMyksYygxMDcpLGMoMjQpLGMoMjEpLGMoMTY1KSxj KDU5KSxjKDQ1KSxjKDE2MiksYyg4OSksYyg5MyksYygxNjYpLGMoMTc2KSxjKDEzMiksYygxMjgp LGMoMTA5KSxjKDE4NSksYygxMTYpLGMoMjU1KSxjKDYxKSxjKDE0MSksYygxMTEpLGMoMTI4KSxj KDI0NCksYygyMzQpLGMoMzYpLGMoMyksYygyNTQpLGMoMTk2KSxjKDkxKSxjKDE4MSksYygxNTAp LGMoNDIpLGMoMTY3KSxjKDExOSksYyg0NCksYygzOCksYyg2MSksYygxNjApLGMoMjQpLGMoMjQ4 KSxjKDUwKSxjKDU2KSxjKDIzMyksYyg0NSksYygxOTMpLGMoMjkpLGMoMTkzKSxjKDkwKSxjKDU0 KSxjKDApLGMoNTYpLGMoNzcpLGMoNTgpLGMoODQpLGMoMTM4KSxjKDE1OSksYyg4OSksYyg4NSks YygyNDUpLGMoMjQ1KSxjKDE1MyksYygyMDMpLGMoMTU3KSxjKDE1MyksYyg2KSxjKDIwMiksYygx ODApLGMoMjUzKSxjKDIzKSxjKDIzNSksYygxOCksYygxNzkpLGMoMzQpLGMoODUpLGMoMTk2KSxj KDE0NCksYygzNiksYygzNCksYygxNTgpLGMoMTg0KSxjKDEwNCksYyg2NSksYygyMjcpLGMoMTkp LGMoMjAwKSxjKDE3MCksYygyNTQpLGMoMTM2KSxjKDIzNCksYyg3MyksYygxMzMpLGMoMjIyKSxj KDcyKSxjKDE3MyksYygxODApLGMoMTE4KSxjKDIyOSksYygxMDEpLGMoMjgpLGMoNDUpLGMoMjA5 KSxjKDE1NiksYygxMDIpLGMoMjA5KSxjKDEyNSksYyg0KSxjKDE0MiksYygzNCksYygyMTUpLGMo MjYpLGMoMjI2KSxjKDExMiksYygxNTEpLGMoMTEyKSxjKDIwOCksYyg0MCksYygyNDkpLGMoMTUy KSxjKDExOSksYygyMTIpLGMoMjI2KSxjKDYpLGMoMjA4KSxjKDEpLGMoMTA1KSxjKDIwMiksYygx OTYpLGMoNTIpLGMoMSksYygxODQpLGMoMTIxKSxjKDI3KSxjKDk3KSxjKDIzNSksYygxNDQpLGMo MTU5KSxjKDEzMyksYygxMzApLGMoMjI3KSxjKDE1MyksYyg3OSksYygxMTkpLGMoODUpLGMoMTAx KSxjKDQ5KSxjKDEwMSksYygxOTgpLGMoMzgpLGMoODcpLGMoMTEwKSxjKDE2NCksYygxNDApLGMo MjQyKSxjKDYzKSxjKDE1NCksYyg3MyksYygyMTYpLGMoMjI2KSxjKDIzMSksYygzKSxjKDIxMiks YygyNTQpLGMoMjIpLGMoMTE4KSxjKDEyMyksYyg4OCksYygxMDYpLGMoNjUpLGMoMTgxKSxjKDE4 NSksYyg2MyksYygyMDYpLGMoMTIxKSxjKDExMyksYygzNSksYygyNDYpLGMoMjQxKSxjKDgxKSxj KDEwNCksYygxNzMpLGMoMjI2KSxjKDIwNiksYygzOSksYygyMTQpLGMoMTc2KSxjKDE5NyksYygy MDUpLGMoMjM0KSxjKDE5NyksYygxNjYpLGMoMzYpLGMoMTE0KSxjKDE5NyksYygyMTkpLGMoNyks YygyMjEpLGMoMTE4KSxjKDY2KSxjKDE0MyksYygyMjQpLGMoMjQ5KSxjKDI1MSksYygxOSksYygx MTkpLGMoNTYpLGMoNTUpLGMoMjM5KSxjKDE2MiksYygyMzApLGMoMTU5KSxjKDUyKSxjKDEpLGMo MjQ4KSxjKDUyKSxjKDE4MCksYygyNDEpLGMoMTc0KSxjKDIwMiksYygyNDYpLGMoMzgpLGMoOTUp LGMoMTIyKSxjKDcxKSxjKDUwKSxjKDE1MyksYygxNyksYygxNzIpLGMoMiksYygyMDMpLGMoMjUw KSxjKDEzOCksYygxNyksYygyMTApLGMoMjE5KSxjKDEwNCksYygxODMpLGMoMTc3KSxjKDEpLGMo ODMpLGMoMTQ3KSxjKDIxNiksYygxNCksYyg0NiksYygxNDcpLGMoMzgpLGMoMjE3KSxjKDYyKSxj KDQ3KSxjKDIyKSxjKDk2KSxjKDIzMiksYygxNDApLGMoMjUxKSxjKDEwOCksYygyMjApLGMoMTEp LGMoMTE1KSxjKDIwMCksYygyNTApLGMoMTk5KSxjKDIyKSxjKDg4KSxjKDEyNSksYygyMzMpLGMo MTQ2KSxjKDIwMSksYygyNTUpLGMoMjI2KSxjKDE5OSksYygyNTUpLGMoMjI5KSxjKDgxKSxjKDU0 KSxjKDU3KSxjKDEwNSksYygxNTcpLGMoMTUxKSxjKDI1MyksYygxOTMpLGMoMTYzKSxjKDYpLGMo MzYpLGMoOTcpLGMoMzQpLGMoMTg3KSxjKDc1KSxjKDEzMCksYygxNDUpLGMoMTc3KSxjKDIyMCks YygyNTApLGMoMjQzKSxjKDUzKSxjKDIpLGMoMjIxKSxjKDE3MyksYygxMCksYyg5NyksYygxNjQp LGMoMTYwKSxjKDE2MCksYygyNDIpLGMoMjUxKSxjKDU0KSxjKDI0NCksYyg4KSxjKDE1NiksYygy MzkpLGMoNzkpLGMoNDQpLGMoMjMpLGMoMTUwKSxjKDQwKSxjKDE2NSksYygxMDgpLGMoMjMxKSxj KDE4MSksYygyMjQpLGMoMjE2KSxjKDI0KSxjKDEwOCksYyg0NyksYygyNTMpLGMoMTgzKSxjKDE4 MCksYygyNDgpLGMoMTI1KSxjKDEyNSksYygxNDMpLGMoMTkwKSxjKDIzMSksYygxMjQpLGMoMjIw KSxjKDgyKSxjKDU4KSxjKDIyMiksYygxMDIpLGMoMjkpLGMoMTYpLGMoODkpLGMoMjQyKSxjKDg1 KSxjKDE0MCksYyg3NCksYygxNjYpLGMoMjUwKSxjKDIzMCksYygxNjYpLGMoMTIwKSxjKDE3MSks YygxODApLGMoMTQzKSxjKDI0MCksYygxMTQpLGMoNCksYygxKSxjKDEyNiksYyg0NCksYygyNDgp LGMoMzApLGMoMTc1KSxjKDMyKSxjKDE3NCksYyg4NSksYyg0NiksYygyMDgpLGMoMjE0KSxjKDEy NCksYygxMDkpLGMoMTk0KSxjKDE5OSksYygxNDApLGMoMTMpLGMoMyksYygzMiksYygxNzUpLGMo MTE0KSxjKDIwMSksYygzNiksYygxMjMpLGMoMTcxKSxjKDY1KSxjKDIzMiksYygxMTUpLGMoMTU4 KSxjKDEwMiksYygxMTEpLGMoMTQ0KSxjKDI1MCksYyg3MyksYygxNzkpLGMoMjQ1KSxjKDI1Myks YygzNiksYygyMDUpLGMoMTQpLGMoMTYpLGMoODkpLGMoMTgwKSxjKDMzKSxjKDI5KSxjKDE0Nyks YygxMjkpLGMoMTU2KSxjKDE0NiksYygyMTQpLGMoODApLGMoMTApLGMoNjkpLGMoNjApLGMoMTY5 KSxjKDQzKSxjKDEyMSksYygxNzMpLGMoMjE3KSxjKDgyKSxjKDkzKSxjKDEwNSksYygyMDQpLGMo NTApLGMoOTUpLGMoMTU2KSxjKDE0KSxjKDQzKSxjKDg2KSxjKDE0MSksYygxNjgpLGMoMjMyKSxj KDU0KSxjKDI0MSksYyg5NCksYygyMDcpLGMoNTkpLGMoMTE2KSxjKDIzOCksYyg0NSksYygxMzYp LGMoMjIxKSxjKDUxKSxjKDk0KSxjKDI0MiksYyg1MyksYygxNzcpLGMoNiksYygyMTYpLGMoMjMx KSxjKDE2NCksYygyMSksYygyMzEpLGMoMTc5KSxjKDEzNyksYyg4NiksYyg2NyksYygxKSxjKDI0 MiksYygxMDMpLGMoMjYpLGMoMTg2KSxjKDExNyksYyg2KSxjKDI1NCksYygzOSksYygxMTApLGMo MTM5KSxjKDI0OSksYyg4MCksYyg1NCksYygyMDQpLGMoMjQpLGMoMjQ4KSxjKDEyMyksYygyNyks YygyNDYpLGMoMTUzKSxjKDM4KSxjKDUxKSxjKDEyMSksYygxMDEpLGMoMTkyKSxjKDE2NCksYyg2 MiksYyg1MiksYygxNjUpLGMoMTc4KSxjKDIwOCksYygxODApLGMoMTc0KSxjKDE5NSksYyg3Nyks YygxOTApLGMoMTAwKSxjKDE5NCksYygxOTkpLGMoMTM1KSxjKDI3KSxjKDIwOSksYyg1NCksYygx MTEpLGMoMTUxKSxjKDIzOCksYygxOCksYygxMzIpLGMoMjI2KSxjKDE2MCksYyg0NSksYyg3Nyks Yyg1MSksYyg1MCksYyg5OCksYygxMzYpLGMoMTQ5KSxjKDEwNCksYygzNCksYygxODQpLGMoMTgz KSxjKDQyKSxjKDE3NiksYyg1OSksYygxOTApLGMoMTEwKSxjKDIxNyksYygxOTgpLGMoMzkpLGMo MzYpLGMoNjIpLGMoMTgpLGMoNDYpLGMoMTQyKSxjKDE1NCksYygyMjQpLGMoMjA5KSxjKDIxNCks YygzMSksYygxNDIpLGMoMTQpLGMoODYpLGMoMTY4KSxjKDEzMSksYyg1NiksYyg4MiksYyg0MSks YygxMDcpLGMoNTkpLGMoMTUxKSxjKDEzMyksYyg2MSksYygyMzQpLGMoOTEpLGMoMTMxKSxjKDE2 OCksYyg4NCksYygxNTcpLGMoNTcpLGMoMTk5KSxjKDg5KSxjKDE0MSksYygyMjUpLGMoOTEpLGMo MjQ1KSxjKDIxNyksYygxODkpLGMoMTU5KSxjKDk5KSxjKDE4NiksYyg4KSxjKDczKSxjKDUpLGMo MzUpLGMoMjUpLGMoMjAyKSxjKDI1KSxjKDE2OSksYygyMjIpLGMoMjQ2KSxjKDU5KSxjKDI1NCks YygyMTYpLGMoNTYpLGMoMTcwKSxjKDE5MiksYygxMzgpLGMoMTQzKSxjKDE2MCksYyg5NSksYygx NzApLGMoMTg5KSxjKDE3NCksYygzOCksYyg4NCksYyg2MCksYygyMjUpLGMoMTIwKSxjKDkyKSxj KDE4KSxjKDg1KSxjKDEzMiksYygxMTApLGMoNjIpLGMoNzEpLGMoODEpLGMoMTI4KSxjKDU2KSxj KDE1NCksYygxODQpLGMoMjIxKSxjKDEyMiksYygzNSksYyg4NiksYygxNDUpLGMoODIpLGMoMTY3 KSxjKDIxMCksYygyMzcpLGMoMTI0KSxjKDEyMSksYygyMzkpLGMoMTI0KSxjKDE5MyksYyg0NSks YygyMzQpLGMoNDMpLGMoMTYpLGMoMTE0KSxjKDEyMiksYygxODQpLGMoOTkpLGMoNjIpLGMoMTEw KSxjKDE1KSxjKDI2KSxjKDIzKSxjKDIwMSksYygxMDMpLGMoMTA4KSxjKDEzNiksYygxNjcpLGMo MTk0KSxjKDY0KSxjKDIwOSksYyg3OCksYygyNDIpLGMoMTIxKSxjKDE4NyksYyg0NCksYyg4KSxj KDE4MCksYygxMDcpLGMoMTYwKSxjKDY0KSxjKDM2KSxjKDM0KSxjKDExNyksYygxOTIpLGMoMjA4 KSxjKDE3MyksYygyNTEpLGMoNTApLGMoMjgpLGMoMiksYyg0MCksYyg0MSksYygxMDYpLGMoMTgp LGMoODUpLGMoMjIwKSxjKDIxKSxjKDQ0KSxjKDIyNSksYygxNTIpLGMoMTQxKSxjKDIzNSksYygx ODEpLGMoMzcpLGMoMzkpLGMoMTc4KSxjKDc5KSxjKDI5KSxjKDUzKSxjKDc1KSxjKDI1KSxjKDEx MCksYygxNjcpLGMoMTYyKSxjKDE1MCksYyg5KSxjKDE1MSksYygyNDQpLGMoMTQ0KSxjKDE5Nyks YygyMDcpLGMoMTE2KSxjKDEzNCksYygyNDIpLGMoNTUpLGMoMjQwKSxjKDE3NCksYygxMCksYygx MjMpLGMoMTAzKSxjKDQ4KSxjKDE4MyksYygyNDUpLGMoMTUwKSxjKDI2KSxjKDM0KSxjKDI0KSxj KDI0MCksYygyMjQpLGMoMjEpLGMoMTc0KSxjKDIxKSxjKDE5NCksYyg5NyksYyg2MyksYygxMzkp LGMoMzIpLGMoMTA3KSxjKDgyKSxjKDEzMiksYygxNjQpLGMoMjUwKSxjKDg1KSxjKDIwNCksYyg1 NyksYyg1NSksYygxNzIpLGMoMjM3KSxjKDIwOSksYyg4MiksYygyMjApLGMoOTkpLGMoMjE3KSxj KDY0KSxjKDE0MSksYygzNCksYygxMDEpLGMoMTE4KSxjKDExNiksYygxMTgpLGMoMjUwKSxjKDk2 KSxjKDEzMiksYygyNDApLGMoMTc4KSxjKDIxNiksYyg2OSksYygxODQpLGMoMjI0KSxjKDIxOSks Yyg2MSksYygyMzQpLGMoMjQyKSxjKDEyOSksYygyMyksYygxMjIpLGMoMTUzKSxjKDIwNSksYyg2 NiksYygxNDYpLGMoMjExKSxjKDE2NiksYygxNSksYygxNTYpLGMoNDEpLGMoODgpLGMoOTApLGMo MTMwKSxjKDM3KSxjKDEyKSxjKDgpLGMoMTY3KSxjKDU1KSxjKDE3NSksYyg2MSksYygxNjgpLGMo MjApLGMoNTIpLGMoOTUpLGMoOTkpLGMoMTcxKSxjKDc0KSxjKDEzNyksYyg5NSksYyg5MSksYygx MjEpLGMoNTApLGMoMjU1KSxjKDE3NyksYyg5MyksYygxMDcpLGMoMjkpLGMoMTMwKSxjKDk1KSxj KDIyMSksYyg3MSksYygyNDEpLGMoNTMpLGMoMTcxKSxjKDgpLGMoMjQ1KSxjKDEyMCksYyg1Nyks Yyg0NyksYygxNTcpLGMoMjI3KSxjKDE3MiksYygyMzcpLGMoMTkpLGMoODEpLGMoMTczKSxjKDYx KSxjKDEyKSxjKDIwOCksYyg5KSxjKDIxNiksYygxOTcpLGMoNDQpLGMoMTExKSxjKDE5NCksYygy NCksYygxODkpLGMoMjAyKSxjKDE5KSxjKDcxKSxjKDE4MCksYygxNDcpLGMoMzkpLGMoMjA1KSxj KDMwKSxjKDIyNSksYygyMDQpLGMoMTE4KSxjKDcyKSxjKDE4NSksYygxNDUpLGMoNzApLGMoMTIx KSxjKDIxNiksYygxMDMpLGMoNiksYygxNzMpLGMoOSksYygxMiksYygxMTUpLGMoMjEwKSxjKDg1 KSxjKDM3KSxjKDI0MCksYygxNDIpLGMoMjE2KSxjKDIxKSxjKDE5NSksYygxOCksYygxMzYpLGMo MTc2KSxjKDE3NSksYyg4MSksYyg1MyksYygyMDIpLGMoMTg3KSxjKDc5KSxjKDEzMyksYygxNTMp LGMoMTA4KSxjKDk0KSxjKDIxNCksYygxMzgpLGMoMTMyKSxjKDE1MyksYygxNTApLGMoMjIyKSxj KDExMCksYyg3OSksYyg5NSksYyg4OSksYygyNDkpLGMoMTIzKSxjKDk5KSxjKDE1OCksYyg0Miks Yyg5NiksYygyMDEpLGMoNjUpLGMoMjA5KSxjKDEwNyksYygxMTYpLGMoMjEzKSxjKDI0NCksYygx MzQpLGMoMTg5KSxjKDIzMSksYyg2NyksYyg5OSksYyg1NSksYyg0KSxjKDIyKSxjKDE1MiksYygy MjcpLGMoMTY2KSxjKDE0NiksYyg5MCksYygyNDApLGMoMTY5KSxjKDEzOCksYygyNTUpLGMoNjIp LGMoMTIzKSxjKDc4KSxjKDIxNSksYyg0KSxjKDEzMCksYyg3NyksYygyNyksYyg0KSxjKDE4Niks YygzNSksYygxNDgpLGMoMjM3KSxjKDIxNiksYygxMTApLGMoMTc3KSxjKDEwMiksYygxMTgpLGMo MjgpLGMoMTA1KSxjKDIzMiksYygxODYpLGMoMzgpLGMoNTcpLGMoMTE0KSxjKDI3KSxjKDEzNiks Yyg5MiksYyg0MyksYygyMzcpLGMoMTk2KSxjKDE4KSxjKDE2MCksYygyMTApLGMoNSksYyg1NCks YygxOTQpLGMoMzQpLGMoODApLGMoMTA3KSxjKDI1NSksYygxNTYpLGMoMTQzKSxjKDI0MCksYygx OTcpLGMoMTkpLGMoOTkpLGMoMTY2KSxjKDEzOSksYygxNDYpLGMoMjAyKSxjKDgzKSxjKDE1MSks YygxOTUpLGMoMjM2KSxjKDY2KSxjKDE0MSksYygyMDcpLGMoMTcwKSxjKDIxMCksYyg0NyksYygx MTkpLGMoMTM3KSxjKDEyMSksYygyMjApLGMoODgpLGMoMjM2KSxjKDczKSxjKDc3KSxjKDkzKSxj KDE2MiksYyg1KSxjKDE0MCksYygxMzMpLGMoMTg3KSxjKDE3MiksYyg0MyksYyg0NCksYygxNTAp LGMoMTkpLGMoMzUpLGMoMTcyKSxjKDE4MyksYygxMDApLGMoNzIpLGMoOTgpLGMoMTY4KSxjKDE4 MSksYygxNjgpLGMoMTI3KSxjKDIzMyksYyg4NCksYygxNDYpLGMoMjUwKSxjKDIwMyksYygyNDUp LGMoNjkpLGMoMTkzKSxjKDE2MyksYygxOTkpLGMoNzIpLGMoMjApLGMoMTQ5KSxjKDIzOCksYygy MiksYyg3MyksYygxODEpLGMoMTIwKSxjKDI5KSxjKDIwMyksYygxNDIpLGMoMTc2KSxjKDEyMiks YygxNyksYygzOCksYygxNTUpLGMoODUpLGMoMzApLGMoMjQxKSxjKDE4OCksYygxNTQpLGMoNzIp LGMoMjQwKSxjKDg0KSxjKDE3NSksYygxODApLGMoMjA4KSxjKDE0KSxjKDkpLGMoMzEpLGMoMTk1 KSxjKDE2OSksYyg3NiksYygxNjYpLGMoMzMpLGMoMjMzKSxjKDEwNyksYygyMzQpLGMoNzQpLGMo OTApLGMoMjgpLGMoMjQxKSxjKDU5KSxjKDI0MiksYygxNTApLGMoMTg3KSxjKDIyNCksYygxNDUp LGMoMjEpLGMoMjI1KSxjKDUwKSxjKDApLGMoMyksYyg3MiksYygxNjkpLGMoNDYpLGMoMjI1KSxj KDM3KSxjKDg0KSxjKDIzKSxjKDEpLGMoNTkpLGMoMTI1KSxjKDIzNyksYygzKSxjKDE3NCksYyg5 MiksYygyMzApLGMoMjAxKSxjKDU5KSxjKDE3OCksYygxMzgpLGMoMTg0KSxjKDE3OSksYyg5Nyks YygxNSksYygyMTkpLGMoMTE5KSxjKDI5KSxjKDUpLGMoMzApLGMoMTk2KSxjKDk2KSxjKDE1OSks Yyg5MyksYygxOTYpLGMoMjUxKSxjKDE1MyksYygxMSksYygyNTEpLGMoMTIzKSxjKDE5NiksYygx ODYpLGMoNzYpLGMoMSksYygxNTEpLGMoNDkpLGMoMTQ4KSxjKDI1MCksYygxNTEpLGMoMjUyKSxj KDE0NyksYygyMCksYygxMTQpLGMoMjUyKSxjKDM2KSxjKDE5NCksYyg4MCksYygyKSxjKDIyKSxj KDEyNyksYygxMDgpLGMoMjEpLGMoMjEyKSxjKDk2KSxjKDE3MiksYyg2NyksYyg1MCksYygxMSks YygxNTYpLGMoMTM1KSxjKDkzKSxjKDEwKSxjKDE1OCksYygyMzYpLGMoMTcxKSxjKDM0KSxjKDEw OCksYygxOTMpLGMoMTcxKSxjKDE0MSksYygyMTQpLGMoMjU0KSxjKDE5OSksYyg4NCksYyg0NCks YygxNDApLGMoODIpLGMoMTk3KSxjKDU0KSxjKDMxKSxjKDE2KSxjKDE0NyksYyg2MyksYyg3KSxj KDEyNyksYyg3NCksYyg0MSksYyg0NiksYyg0NyksYygxMTUpLGMoODQpLGMoMTYxKSxjKDIwNSks YygzNiksYygxNjkpLGMoMjM1KSxjKDE5NiksYygxMDgpLGMoODkpLGMoMjQxKSxjKDE3MiksYygx MjEpLGMoNjMpLGMoMTMpLGMoMTA5KSxjKDk2KSxjKDY5KSxjKDExOCksYygxODApLGMoMjU1KSxj KDE0NSksYygyMzApLGMoMjI0KSxjKDIzNCksYyg4OCksYygxOTUpLGMoMTcxKSxjKDApLGMoMTc2 KSxjKDI5KSxjKDI1MyksYyg3KSxjKDE5NCksYyg2NSksYygxNjgpLGMoMjI3KSxjKDE4MiksYygx MzMpLGMoMTIpLGMoODUpLGMoNDEpLGMoMjM0KSxjKDI0NSksYygyNDcpLGMoMTE1KSxjKDEwNyks YygxOTYpLGMoMTE0KSxjKDEwNSksYygxMjUpLGMoNTApLGMoMzApLGMoMTYpLGMoOTkpLGMoMTkx KSxjKDIzNCksYyg4OSksYygxNDEpLGMoNTYpLGMoOTQpLGMoMTUzKSxjKDE3MSksYyg4NyksYygy NiksYygxMjMpLGMoNCksYygyNTEpLGMoMTQxKSxjKDU4KSxjKDE4MCksYygyMTkpLGMoNiksYygx MjMpLGMoMTQ0KSxjKDI1NSksYyg0OSksYyg1MSksYygxMjApLGMoMjgpLGMoNDYpLGMoNDEpLGMo NTcpLGMoMTk5KSxjKDEwMiksYygyMTkpLGMoNzUpLGMoMTgpLGMoMTUyKSxjKDEzMSksYygxMjgp LGMoMTc3KSxjKDU5KSxjKDUyKSxjKDI0OSksYygyMjQpLGMoMTM2KSxjKDE4KSxjKDEyOSksYyg3 MiksYygxNjQpLGMoMTMpLGMoNTkpLGMoMjEpLGMoMTc5KSxjKDExNiksYygxMDUpLGMoMzYpLGMo MTcyKSxjKDI0NyksYygxMDQpLGMoMTg2KSxjKDIwOSksYyg0MSksYygxNTIpLGMoOTcpLGMoMTQ4 KSxjKDEzOCksYygxNzUpLGMoMjIzKSxjKDI0MiksYygyMCksYygyMzkpLGMoMjApLGMoOTUpLGMo MjEwKSxjKDE0MSksYyg0MSksYyg3MCksYyg2MiksYygyMjkpLGMoMjUyKSxjKDUyKSxjKDE5Nyks Yyg5MiksYyg2KSxjKDE2KSxjKDQ0KSxjKDEwNSksYygyNDcpLGMoNiksYyg4NSksYygyNTEpLGMo NzcpLGMoNjQpLGMoNzApLGMoMjAxKSxjKDE5NCksYyg1OSksYygxNzQpLGMoMjcpLGMoMjM1KSxj KDE1NyksYygzNiksYygxODUpLGMoMTMpLGMoMSksYygyMDEpLGMoMTEwKSxjKDc2KSxjKDExMSks YygxOSksYyg0MyksYyg2OCksYygxNTIpLGMoNjEpLGMoMzQpLGMoMjMxKSxjKDEwMSksYyg4NSks YygyMTQpLGMoMjE5KSxjKDEzMiksYygxNDgpLGMoOTkpLGMoMjgpLGMoMCksYygyNDMpLGMoMTAy KSxjKDIzKSxjKDI2KSxjKDE2MiksYyg3NiksYygxNjIpLGMoMjAwKSxjKDIwMSksYygxMjcpLGMo MjI1KSxjKDcxKSxjKDI0NSksYygyMSksYygxOSksYygxNTApLGMoOTApLGMoMjAyKSxjKDYxKSxj KDY2KSxjKDExNyksYygyNDMpLGMoMTg5KSxjKDgzKSxjKDIxOSksYygxMSksYygyMjIpLGMoNzkp LGMoMTIxKSxjKDE3KSxjKDE2NSksYygxMTQpLGMoMTc4KSxjKDIwMSksYygyMDYpLGMoNDgpLGMo NzMpLGMoMjI1KSxjKDEwMCksYygxMjEpLGMoMjQxKSxjKDE2OSksYygyKSxjKDE3NyksYygyKSxj KDE1OCksYygzNyksYygxOTYpLGMoMjUpLGMoODIpLGMoMTY0KSxjKDEzMyksYygxNTYpLGMoMTgw KSxjKDE0MiksYygyMTYpLGMoODcpLGMoMTI3KSxjKDk1KSxjKDEyNyksYyg0NyksYygyMzgpLGMo MTEpLGMoNzApLGMoMTQpLGMoNDgpLGMoOCksYygxNTYpLGMoMTMzKSxjKDIwMyksYyg3NSksYygx OCksYygyMzkpLGMoMTYwKSxjKDE5MyksYyg0NyksYygxODApLGMoMTU1KSxjKDE0MSksYygxMTkp LGMoMTM3KSxjKDIyNyksYygzOCksYygzMCksYygxNTkpLGMoMTY0KSxjKDYzKSxjKDI0MiksYyg4 MSksYygxOTQpLGMoMTMwKSxjKDE0MCksYyg5MCksYyg0MCksYygwKSxjKDIxOSksYygxMDYpLGMo MTY1KSxjKDEzMCksYygxOCksYygxMzIpLGMoMTUwKSxjKDE1OCksYyg4MSksYygxNjcpLGMoMjUw KSxjKDEwMiksYygxMDIpLGMoMTY1KSxjKDEzMSksYygxOTYpLGMoOTUpLGMoNjApLGMoMzUpLGMo MTA2KSxjKDE4NiksYygxNDApLGMoMTI1KSxjKDIzNiksYygxMjkpLGMoMjAzKSxjKDE2NSksYygx NTEpLGMoMTIxKSxjKDE5NCksYygzNiksYygxNDgpLGMoODUpLGMoMTYxKSxjKDE3MCksYygzNyks YygxMCksYygxMzkpLGMoMzcpLGMoOTgpLGMoMTMyKSxjKDIwMCksYyg1NCksYygyMzkpLGMoMjQw KSxjKDIzMCksYygxMjgpLGMoOTIpLGMoMTIxKSxjKDE2NSksYygxMjApLGMoMTU5KSxjKDE3NCks YygxNjkpLGMoMjMzKSxjKDQ5KSxjKDIyOCksYyg3NCksYygyMzMpLGMoNDQpLGMoMjQ2KSxjKDM1 KSxjKDIzOSksYyg5NiksYygxMTgpLGMoODkpLGMoNTcpLGMoODEpLGMoOCksYygxOCksYyg2MSks Yyg3OCksYyg4MyksYygxNDYpLGMoMTg5KSxjKDIzNCksYyg3MiksYygxNTEpLGMoMjUzKSxjKDM2 KSxjKDEyMiksYygxMjgpLGMoMTU3KSxjKDU5KSxjKDc4KSxjKDE1MSksYygyMDUpLGMoMjEzKSxj KDExKSxjKDE1MiksYygxNDEpLGMoMjAyKSxjKDcpLGMoODEpLGMoMTYxKSxjKDg5KSxjKDIxKSxj KDE1MyksYygxMTEpLGMoMzcpLGMoMTc0KSxjKDM1KSxjKDEwOSksYygxMSksYygyMyksYygxMTAp LGMoNDcpLGMoMTQ2KSxjKDE3NyksYygzNyksYygxNTUpLGMoMTg4KSxjKDIwMCksYygxNzYpLGMo OTUpLGMoMTgxKSxjKDE3OCksYygyMTYpLGMoMjU1KSxjKDIzNyksYygxOTUpLGMoMjUxKSxjKDIw MSksYygyNTUpLGMoMTIpLGMoNjQpLGMoNjgpLGMoMTA3KSxjKDI0NSksYygxMTUpLGMoMjM1KSxj KDIzOCksYygzOCksYyg2MiksYygzMSksYygxMzEpLGMoMTY2KSxjKDIzNiksYygxNzIpLGMoNTIp LGMoMTYzKSxjKDE5KSxjKDIyOSksYyg2OSksYyg5NCksYygyKSxjKDIzOSksYygxMzQpLGMoNDQp LGMoMjIpLGMoNjUpLGMoMjQ4KSxjKDExMSksYygxOCksYygyNDEpLGMoOTMpLGMoMTI3KSxjKDE5 NiksYyg5MCksYygxMiksYygxMjMpLGMoOTkpLGMoMTcpLGMoMjM3KSxjKDI3KSxjKDE0OCksYyg2 MiksYygxMDkpLGMoMjAyKSxjKDIzNiksYygxNjkpLGMoMjE4KSxjKDIyNSksYyg5OCksYyg3Niks Yyg2MyksYygyNTEpLGMoMjA2KSxjKDcpLGMoMjE2KSxjKDE5MCksYygyMDgpLGMoMTM1KSxjKDE3 KSxjKDM4KSxjKDEwNyksYygxNDYpLGMoMzkpLGMoOTApLGMoMTEpLGMoMTU3KSxjKDI0OCksYygy MCksYygyNDgpLGMoMjUwKSxjKDEyNSksYygyMiksYyg5MCksYyg2MiksYygxNzApLGMoMTgzKSxj KDEzMiksYygxNjQpLGMoMjI4KSxjKDgyKSxjKDE5NCksYygyMjcpLGMoMTgzKSxjKDE5MSksYyg0 KSxjKDExMSksYygxNjEpLGMoOTQpLGMoMTg4KSxjKDEwKSxjKDM4KSxjKDgzKSxjKDIzKSxjKDIw NCksYyg5OSksYygyNDMpLGMoMjE4KSxjKDE3MSksYyg1NSksYyg4OSksYygyNiksYygxNDcpLGMo MTk1KSxjKDQ3KSxjKDIwMyksYygxNjcpLGMoMjMxKSxjKDEyOSksYygyMDcpLGMoMTg2KSxjKDE0 NCksYyg3KSxjKDE5NSksYygxMzcpLGMoNjQpLGMoMTYpLGMoMjQ3KSxjKDE5MiksYygzMSksYygy MiksYygyOSksYygxNzkpLGMoMjM2KSxjKDExNyksYygxNyksYygxNzUpLGMoNiksYyg1KSxjKDE5 NCksYygxMDQpLGMoMTA5KSxjKDg1KSxjKDQ1KSxjKDExNCksYygxNzIpLGMoNSksYygxMzEpLGMo MzApLGMoMTkzKSxjKDQ3KSxjKDQ1KSxjKDUyKSxjKDE2NyksYyg2OSksYygyMCksYygyMjkpLGMo NiksYygzMiksYyg5KSxjKDE1NSksYygxNTYpLGMoMTQwKSxjKDEwKSxjKDI1KSxjKDQzKSxjKDE1 MSksYygyMCksYygyOSksYygyNiksYygxMzUpLGMoNzkpLGMoNDUpLGMoMTMwKSxjKDIxMiksYygx ODYpLGMoMjI4KSxjKDM3KSxjKDMpLGMoMTUzKSxjKDEyMCksYygxNDApLGMoMTM4KSxjKDQ2KSxj KDIzOSksYyg5NyksYygyMjYpLGMoMTY4KSxjKDQ2KSxjKDIzNyksYygxODMpLGMoMzQpLGMoMjA4 KSxjKDE0OSksYyg1NCksYygxODYpLGMoMTMwKSxjKDEwMCksYyg3MiksYygxOTkpLGMoMjI5KSxj KDE1MyksYyg3MCksYygxODEpLGMoMTg3KSxjKDEwNiksYygzMCksYyg5OSksYygyMTMpLGMoMTY2 KSxjKDg3KSxjKDE0NSksYygxNjUpLGMoMjMzKSxjKDYpLGMoMzgpLGMoMTY1KSxjKDIyOCksYygy MTUpLGMoMTkxKSxjKDM2KSxjKDU5KSxjKDEwMSksYyg0OSksYygzMCksYygxOTQpLGMoMTI2KSxj KDIxKSxjKDM0KSxjKDU0KSxjKDE4NCksYyg0KSxjKDI1NSksYygyMzUpLGMoMCksYyg1NiksYygy MDEpLGMoNDkpLGMoOTYpLGMoMTU5KSxjKDEzNyksYygxMjcpLGMoOTApLGMoODkpLGMoMjQ3KSxj KDI1NCksYyg2MSksYygyMjQpLGMoMTYzKSxjKDEzMCksYygyOSksYygxMzcpLGMoMjM4KSxjKDE0 MSksYygxMjgpLGMoMTM3KSxjKDk4KSxjKDE1NyksYygzOCksYygxODEpLGMoMTYyKSxjKDE1MSks YygxODYpLGMoNTcpLGMoMiksYyg5MyksYygxNCksYyg0NSksYygyMjApLGMoMTEzKSxjKDMwKSxj KDE3OSksYyg3MiksYygyMzcpLGMoNDYpLGMoNTQpLGMoNDYpLGMoMTY4KSxjKDUyKSxjKDIzOCks YygyMTUpLGMoNTUpLGMoMSksYygxOTApLGMoMjUwKSxjKDExNyksYygxMSksYyg3OCksYygyNiks Yyg3MiksYyg4NiksYyg4MSksYyg1MSksYygxMDApLGMoMTgyKSxjKDIyOSksYyg2OSksYyg5KSxj KDgwKSxjKDI0NiksYygxNjcpLGMoMTI1KSxjKDExNyksYygxMDYpLGMoMjIxKSxjKDIzMSksYygx OTUpLGMoMTA2KSxjKDM3KSxjKDE0MyksYygxNDkpLGMoMTI0KSxjKDIyMCksYygxMTApLGMoMTAy KSxjKDYyKSxjKDIzOSksYyg4NyksYyg4KSxjKDQpLGMoMjYpLGMoMTY4KSxjKDI1MCksYygxNTUp LGMoMjMyKSxjKDE1NiksYygxMTYpLGMoMTQzKSxjKDE3MSksYygxMzYpLGMoOTQpLGMoMjQ0KSxj KDE3OCksYygzMiksYyg5OSksYyg4NiksYyg4MSksYygxNDIpLGMoODUpLGMoNzIpLGMoNTIpLGMo MjE4KSxjKDI2KSxjKDE5NCksYygyNDgpLGMoMTE2KSxjKDIxNCksYygyNTApLGMoNTUpLGMoMjIx KSxjKDEyMiksYygyNDUpLGMoMjM1KSxjKDcyKSxjKDIyNSksYygyMTkpLGMoODUpLGMoMTk4KSxj KDE5MyksYygxMDApLGMoMjQ2KSxjKDQpLGMoMTQ0KSxjKDE3MCksYygxNTcpLGMoMjM3KSxjKDkz KSxjKDEyOSksYygyMDYpLGMoMTg4KSxjKDEwMiksYygxNTgpLGMoMTUyKSxjKDE2KSxjKDE4MCks YygzOCksYygwKSxjKDExMiksYygyMzMpLGMoMjA3KSxjKDI1MyksYyg4NiksYyg2NCksYygyMiks YygxMjkpLGMoMTQxKSxjKDExKSxjKDIxKSxjKDQpLGMoMTM3KSxjKDMyKSxjKDE4NSksYygzNyks YygxMTgpLGMoMTUxKSxjKDEyNyksYygxNDApLGMoMjMwKSxjKDIwNSksYygyMTMpLGMoMjE3KSxj KDEyMCksYygxNzcpLGMoNjQpLGMoNjApLGMoMjI2KSxjKDYxKSxjKDQwKSxjKDgyKSxjKDEyOCks Yyg3NyksYygzNyksYygyMDApLGMoMjMpLGMoNjUpLGMoMjQpLGMoMTE4KSxjKDE5NCksYygyMTMp LGMoMzgpLGMoMjE4KSxjKDk5KSxjKDI2KSxjKDE5OSksYygxMzUpLGMoMjUzKSxjKDI1MyksYygx NzcpLGMoMTcxKSxjKDIzNiksYygyMjApLGMoMjI2KSxjKDIzMyksYygxMjQpLGMoMjE0KSxjKDE1 MyksYygyMzcpLGMoMjM1KSxjKDk4KSxjKDE1MyksYygyMTIpLGMoMTkyKSxjKDE2OSksYygxMzIp LGMoMTI2KSxjKDE5OCksYygxMDMpLGMoMjQpLGMoMTEpLGMoMTcwKSxjKDIxKSxjKDIyNiksYygx MzkpLGMoMTMyKSxjKDg4KSxjKDIzOCksYygxNDEpLGMoMTAwKSxjKDY4KSxjKDIxMyksYygyMSks YygxMyksYygzNSksYyg3NiksYygyNDApLGMoMjUxKSxjKDk0KSxjKDgzKSxjKDg4KSxjKDE3MSks YygxOTIpLGMoMTcpLGMoNDcpLGMoMjApLGMoMTA2KSxjKDEwOCksYygzMCksYygyMDcpLGMoNTMp LGMoMjEpLGMoMTIxKSxjKDg1KSxjKDYpLGMoMTY3KSxjKDIxNCksYygxNTYpLGMoMjEzKSxjKDk5 KSxjKDE0MCksYygzMyksYygxNjYpLGMoMzkpLGMoMTgyKSxjKDE1NSksYygxNDApLGMoMTc5KSxj KDI1MCksYygxODQpLGMoNDcpLGMoMTY4KSxjKDk1KSxjKDI1MiksYygyMDApLGMoMTg5KSxjKDEx OSksYygyMzUpLGMoNzcpLGMoMTc4KSxjKDM4KSxjKDEzNyksYygxMDgpLGMoNSksYygxMTQpLGMo MTk4KSxjKDExNyksYygyMjgpLGMoMjEpLGMoMjU0KSxjKDE4OSksYyg1MCksYygyMDgpLGMoMTY0 KSxjKDU4KSxjKDIxOSksYyg1MSksYygzKSxjKDE3NiksYygxODQpLGMoNTMpLGMoODYpLGMoMjMp LGMoNjMpLGMoMTA1KSxjKDEwOSksYygyMTMpLGMoMTcxKSxjKDE3OSksYygyMzMpLGMoOTMpLGMo MjQpLGMoMTQyKSxjKDEzMSksYygxMjApLGMoMjQpLGMoMTI5KSxjKDExMSksYygyNTIpLGMoMjQ4 KSxjKDEwNiksYygyNDcpLGMoMTIzKSxjKDE1MyksYygxMTIpLGMoMTkxKSxjKDg3KSxjKDQxKSxj KDE3MyksYyg4NyksYygxMTUpLGMoODUpLGMoNzUpLGMoMjM0KSxjKDE2MiksYygxMjQpLGMoMzcp LGMoODEpLGMoMTE5KSxjKDIyNSksYygxOTApLGMoMTkpLGMoMjE1KSxjKDM2KSxjKDIxMyksYygy NTQpLGMoMzMpLGMoNDUpLGMoMTI4KSxjKDY1KSxjKDE0OCksYygyMSksYygxNzEpLGMoMTQwKSxj KDMyKSxjKDEzOSksYygyNTApLGMoODcpLGMoMzcpLGMoMjI3KSxjKDU5KSxjKDI0NCksYyg5NCks YygxNTQpLGMoMTc1KSxjKDExNiksYygyMzIpLGMoODcpLGMoMjU0KSxjKDIyMCksYygxNTgpLGMo MTk5KSxjKDEzMiksYygzMSksYyg0MCksYyg3MSksYygxODApLGMoMTUxKSxjKDE0OSksYygyOCks YygxMzgpLGMoMjA0KSxjKDEwMCksYygyNDMpLGMoMjUyKSxjKDIxMSksYygyMzkpLGMoOTcpLGMo NjIpLGMoMjU1KSxjKDE1MCksYygyMCksYygxMDMpLGMoMTM3KSxjKDgwKSxjKDE0MyksYygxMzIp LGMoMzkpLGMoMjE0KSxjKDE3OSksYygxNTEpLGMoMjkpLGMoMjgpLGMoNDEpLGMoMTU5KSxjKDk2 KSxjKDYpLGMoMTkxKSxjKDgpLGMoMTAwKSxjKDEyKSxjKDIzNiksYygzOCksYygyMzUpLGMoMTA5 KSxjKDU4KSxjKDE5MiksYygyNDcpLGMoMTYpLGMoMjM3KSxjKDI1MCksYygxMjgpLGMoMCksYyg2 NyksYygxNzkpLGMoOTQpLGMoMyksYyg1NyksYygxNTcpLGMoNjEpLGMoMTcyKSxjKDIxNyksYygy MDMpLGMoMjIzKSxjKDI0KSxjKDkxKSxjKDkyKSxjKDEzMyksYygxNTcpLGMoNDgpLGMoMTE5KSxj KDY1KSxjKDE2NiksYyg4OCksYygxNTMpLGMoMjI3KSxjKDg0KSxjKDE0NSksYyg2KSxjKDIzMSks YygxNzQpLGMoMTc3KSxjKDI1MyksYygyMDMpLGMoMTU5KSxjKDE0MCksYygyMDQpLGMoMTkpLGMo MTE2KSxjKDEyNyksYygyOSksYyg0NyksYygxNjIpLGMoOCksYygyMzkpLGMoMTY0KSxjKDIzMyks YygxMjgpLGMoMjA1KSxjKDMyKSxjKDMpLGMoMjMpLGMoMjQ1KSxjKDEyOCksYygxNjIpLGMoOTEp LGMoMjI3KSxjKDY2KSxjKDI0MSksYygyMzQpLGMoNDApLGMoMTE4KSxjKDg2KSxjKDE5MyksYygx ODApLGMoMTM0KSxjKDEzNCksYygyMjMpLGMoMjQ2KSxjKDIwMyksYygxMTEpLGMoOTApLGMoMTA5 KSxjKDIxMSksYygxNDMpLGMoMjcpLGMoMTI5KSxjKDE0MyksYygxOTUpLGMoMjQzKSxjKDQ0KSxj KDQxKSxjKDE4MSksYygxMTUpLGMoMjI0KSxjKDQ1KSxjKDExNyksYygyNiksYygxNTApLGMoMjQ5 KSxjKDc4KSxjKDgpLGMoMTc1KSxjKDIwNSksYygxNTEpLGMoMjUyKSxjKDk2KSxjKDE1NiksYygx NiksYyg2NCksYyg3NCksYygxNzkpLGMoMTg3KSxjKDQ1KSxjKDQ2KSxjKDI0MyksYygxNjMpLGMo MTk1KSxjKDIzMCksYygxMDYpLGMoMjQ2KSxjKDEzOCksYyg3KSxjKDE1MSksYyg2MiksYygxOSks Yyg4NiksYygxNCksYygyMTYpLGMoMTYwKSxjKDI0NSksYygxMzkpLGMoMjE1KSxjKDcpLGMoMTAz KSxjKDM3KSxjKDEyMiksYyg2MiksYyg1NiksYyg1MiksYyg5NSksYygxNzEpLGMoMTA1KSxjKDIx MyksYygxMjgpLGMoMjQxKSxjKDQwKSxjKDMxKSxjKDExNCksYygyMDYpLGMoMTMyKSxjKDEzMSks YygyNTApLGMoMTc1KSxjKDE0MSksYyg5MCksYygxNjYpLGMoMTgxKSxjKDEyOSksYygyMjYpLGMo NSksYygxMjApLGMoNDMpLGMoMTQyKSxjKDI5KSxjKDIzNSksYygyNTIpLGMoMjExKSxjKDYwKSxj KDE3NSksYygyNDQpLGMoOTYpLGMoMTQpLGMoMTczKSxjKDE5MyksYygxMDkpLGMoMCksYyg2MCks YygyNDcpLGMoMTIzKSxjKDgzKSxjKDEyMyksYygxMiksYygyMzkpLGMoMTQpLGMoODgpLGMoMTY0 KSxjKDE5KSxjKDExNiksYygxOTgpLGMoOTYpLGMoMTI0KSxjKDEwNSksYyg0NSksYygyNTEpLGMo NzYpLGMoNjQpLGMoODIpLGMoMzcpLGMoMTI2KSxjKDMpLGMoMjQyKSxjKDc3KSxjKDY2KSxjKDE1 NyksYygxNzApLGMoMjU0KSxjKDExOCksYyg1OSksYygxODEpLGMoMjA5KSxjKDEzOCksYygxMTMp LGMoNjgpLGMoMTA0KSxjKDEyMCksYygxNzMpLGMoNTEpLGMoMSksYygxMzUpLGMoMTgpLGMoMTc4 KSxjKDIwNCksYygyMTYpLGMoMjMwKSxjKDI0KSxjKDYwKSxjKDIwNSksYygxNDMpLGMoMzcpLGMo NzUpLGMoMTcwKSxjKDM0KSxjKDE4OCksYyg4KSxjKDEwOSksYygxMzMpLGMoMjApLGMoMjApLGMo MjIpLGMoMTQ4KSxjKDI0NiksYygyMjQpLGMoMjU0KSxjKDE5NSksYyg4NCksYygxNDkpLGMoOTAp LGMoNjUpLGMoMTApLGMoMTcwKSxjKDM4KSxjKDE0OSksYygzNSksYyg3NCksYyg4NiksYygxNTEp LGMoMjEyKSxjKDEyOSksYygxNzEpLGMoMTQ3KSxjKDI0OCksYyg3MSksYygxMjcpLGMoMTU5KSxj KDI0OCksYygzOSksYygxNDMpLGMoODMpLGMoOTYpLGMoMjM1KSxjKDE5MiksYygyNTMpLGMoNDMp LGMoMjE0KSxjKDI0MyksYygyNDQpLGMoMjM4KSxjKDI0NyksYyg0OSksYygyMzYpLGMoNzEpLGMo MjE0KSxjKDczKSxjKDgxKSxjKDE2OCksYyg3OSksYygxNjkpLGMoMTYwKSxjKDExKSxjKDIyNiks YygxMjkpLGMoMjIzKSxjKDE4MSksYygxOTcpLGMoNDkpLGMoMTE4KSxjKDExMyksYygyMzcpLGMo MTM4KSxjKDExOSksYygxNTMpLGMoMTg1KSxjKDE0MyksYygxNzQpLGMoMTYzKSxjKDM0KSxjKDM5 KSxjKDM4KSxjKDI0NSksYygyMjcpLGMoMTc2KSxjKDI0NCksYyg4MCksYygyNTEpLGMoMTczKSxj KDU1KSxjKDE1MSksYygzNSksYygxMDYpLGMoMjQ2KSxjKDIzKSxjKDY3KSxjKDIwMSksYyg5Myks Yyg1NyksYygyMiksYygxNTgpLGMoMjUyKSxjKDExNiksYygyMTMpLGMoMTExKSxjKDI0NSksYygx ODQpLGMoMzcpLGMoNDUpLGMoMTkxKSxjKDk1KSxjKDE5MSksYygyNDQpLGMoMTEzKSxjKDIxMiks YygxMzIpLGMoMjIpLGMoMTM1KSxjKDEyOSksYygxMDgpLGMoNCksYyg0MSksYyg2MyksYygxOTIp LGMoNjUpLGMoMTcpLGMoNzIpLGMoOTYpLGMoMjA0KSxjKDE1MyksYyg0NiksYygzOSksYygyMzEp LGMoMzEpLGMoMTk2KSxjKDkyKSxjKDI1MSksYygxNjgpLGMoODkpLGMoMTk0KSxjKDg3KSxjKDI1 NCksYygxNjYpLGMoMjMwKSxjKDM1KSxjKDIzMSksYyg2MiksYygyMjUpLGMoODQpLGMoMTY5KSxj KDc5KSxjKDIzMiksYygxODQpLGMoMTYpLGMoMTE0KSxjKDE1NyksYygyNDQpLGMoMTk1KSxjKDEy OCksYyg1MSksYygyNDkpLGMoMjI5KSxjKDI3KSxjKDE0NiksYyg2KSxjKDU5KSxjKDIxOSksYygy OCksYygxMDgpLGMoMTYyKSxjKDYyKSxjKDE3KSxjKDExOCksYygwKSxjKDUwKSxjKDYzKSxjKDcx KSxjKDM1KSxjKDcxKSxjKDE5MSksYygxNzEpLGMoMjEpLGMoODkpLGMoMTI4KSxjKDQ4KSxjKDIw KSxjKDE4NiksYygxNTEpLGMoNjgpLGMoMjQ3KSxjKDEyNSksYygyMzApLGMoMjM1KSxjKDIxKSxj KDI0OCksYyg0NiksYygxMTApLGMoMTAzKSxjKDE4NSksYyg5MiksYygxMjIpLGMoMTc0KSxjKDM4 KSxjKDE4MSksYygxMTgpLGMoNDEpLGMoMTM4KSxjKDEyNCksYygxMzMpLGMoMTg5KSxjKDIwMyks YygyMjApLGMoMyksYygyMDgpLGMoMjM1KSxjKDk1KSxjKDIyNyksYygyMjUpLGMoMzgpLGMoMTc4 KSxjKDEwMSksYygxNTgpLGMoMTg0KSxjKDExMyksYygxMTIpLGMoMTU5KSxjKDEzMSksYygxNSks YygyMTYpLGMoMjIpLGMoMTMxKSxjKDE3MiksYyg2MSksYygyMzApLGMoMjIyKSxjKDI0KSxjKDYw KSxjKDI0MSksYyg1MiksYyg0NyksYygyMTUpLGMoMjA4KSxjKDY1KSxjKDI1KSxjKDU2KSxjKDI0 MyksYygxMTIpLGMoMjI0KSxjKDExKSxjKDM0KSxjKDE2NSksYygyMzMpLGMoMTk2KSxjKDIzMyks Yyg5NyksYyg2NyksYygxNiksYygyNDgpLGMoNiksYygxOSksYygxODEpLGMoMjM5KSxjKDIzNyks Yyg3NCksYygxMTIpLGMoNzcpLGMoMjMwKSxjKDIzNCksYygxMjIpLGMoMTIwKSxjKDY2KSxjKDI0 MSksYygxNjIpLGMoNjEpLGMoNDEpLGMoMTExKSxjKDE1KSxjKDE3OSksYygyMjQpLGMoMjM1KSxj KDExMCksYygxNzUpLGMoMTE5KSxjKDIwOCksYyg4MyksYygzMCksYygyMzQpLGMoMjUzKSxjKDE4 NyksYygxODUpLGMoMTcpLGMoMTUwKSxjKDk5KSxjKDg0KSxjKDIzOCksYygyMjEpLGMoMTE1KSxj KDIwMiksYygyMzQpLGMoMjI0KSxjKDQxKSxjKDExOCksYygxMjYpLGMoNjkpLGMoMTU2KSxjKDE3 MyksYygzKSxjKDIwMSksYygxNTgpLGMoMTU3KSxjKDE4NCksYygyNDcpLGMoMjAzKSxjKDEwOSks YygxOTUpLGMoOTcpLGMoMTI4KSxjKDE2NSksYyg4NyksYygxMzIpLGMoMTQ0KSxjKDEyOCksYyg0 NSksYygxNzApLGMoMTcyKSxjKDI0OSksYygxNTUpLGMoMTQ0KSxjKDcwKSxjKDE0NyksYygyMDcp LGMoNzEpLGMoMTA3KSxjKDMxKSxjKDE5MCksYygxODMpLGMoNjEpLGMoMjQ4KSxjKDE4OSksYygy NDYpLGMoMTQwKSxjKDE4NSksYygxMDgpLGMoNTkpLGMoMTczKSxjKDg3KSxjKDQxKSxjKDE3KSxj KDIxMyksYygxMTQpLGMoMjU0KSxjKDEwNSksYyg2KSxjKDI1MCksYygxNjMpLGMoMTM1KSxjKDI0 NyksYygxNDQpLGMoMjUpLGMoMTUyKSxjKDg3KSxjKDI4KSxjKDE3OCksYygxMDQpLGMoMTc3KSxj KDI2KSxjKDE5NiksYygxMzYpLGMoMjQxKSxjKDEyKSxjKDU4KSxjKDIpLGMoMyksYygxOTApLGMo NTYpLGMoMzIpLGMoNjMpLGMoMTY2KSxjKDE5OCksYygxNCksYygyMTApLGMoMTQxKSxjKDExNSks YygxODkpLGMoMjMpLGMoNDgpLGMoMTQyKSxjKDQ2KSxjKDEzNCksYygzMyksYygyMjkpLGMoMCks YygxMzMpLGMoMTU1KSxjKDQwKSxjKDExMSksYygxOTQpLGMoMjIzKSxjKDMyKSxjKDIyNCksYygy NDEpLGMoMjMpLGMoMjQ1KSxjKDE2MCksYygxNTgpLGMoMTM4KSxjKDE3NSksYygyMzcpLGMoMzgp LGMoMTkzKSxjKDIyNSksYyg0NCksYygyNTUpLGMoMjgpLGMoMTA1KSxjKDUzKSxjKDI0MSksYygy NCksYygxNDMpLGMoMTQwKSxjKDExMiksYygxMzIpLGMoMTUpLGMoNjIpLGMoMTI3KSxjKDg3KSxj KDIxOCksYyg5MiksYygxMjkpLGMoMjExKSxjKDIzNyksYygxMjkpLGMoMjEzKSxjKDE4NiksYyg1 OCksYygxODcpLGMoMTY4KSxjKDE0MCksYygxODApLGMoNzMpLGMoNjIpLGMoOTEpLGMoNjUpLGMo ODgpLGMoMjUzKSxjKDgwKSxjKDIzMiksYygxMjcpLGMoMTUzKSxjKDIyNSksYyg1NiksYygyMDcp LGMoOTgpLGMoMTI2KSxjKDYpLGMoMjA3KSxjKDI0NSksYygxMCksYygyNSksYygyMiksYygyMjgp LGMoMjE0KSxjKDIyMiksYygxODMpLGMoMjI5KSxjKDk0KSxjKDEwMyksYygyNTIpLGMoMjM1KSxj KDg4KSxjKDEzKSxjKDg5KSxjKDUwKSxjKDI1MCksYygxNzgpLGMoMTUwKSxjKDE2NiksYygxMjAp LGMoNTgpLGMoNSksYygyMDEpLGMoODApLGMoMTgpLGMoMjI1KSxjKDUwKSxjKDI0OCksYygxNzEp LGMoMTgwKSxjKDIyMiksYygxNSksYygxNzgpLGMoODApLGMoOTkpLGMoMTcpLGMoMTEzKSxjKDE4 OCksYygxMTgpLGMoMTU0KSxjKDE4NCksYygxNTYpLGMoMTI1KSxjKDg1KSxjKDE3MyksYygxNzEp LGMoMTgxKSxjKDYyKSxjKDE1MSksYygxOTMpLGMoMjMwKSxjKDE3NiksYygyKSxjKDI0MSksYygx ODIpLGMoMTUwKSxjKDEwNSksYygyMTQpLGMoMTE5KSxjKDUyKSxjKDk5KSxjKDczKSxjKDI0Myks YygxMzMpLGMoMiksYygyOCksYygyMDkpLGMoMTYyKSxjKDE0OCksYygxMjApLGMoMTM0KSxjKDU1 KSxjKDY1KSxjKDcwKSxjKDEzNCksYygyMzEpLGMoMjA1KSxjKDE4KSxjKDI1NCksYygyMjUpLGMo MjIxKSxjKDE5MCksYygyMTkpLGMoMTg1KSxjKDIxNSksYygyNTApLGMoMTY2KSxjKDE2NSksYygz KSxjKDExMyksYygyMjEpLGMoNTYpLGMoMTIxKSxjKDM4KSxjKDEzNSksYyg0OCksYygyMjUpLGMo MjE3KSxjKDkyKSxjKDEwKSxjKDEzMCksYygxNzkpLGMoMjE1KSxjKDE4MCksYygxOCksYyg2NSks YygxMTgpLGMoNyksYygxNDcpLGMoNDApLGMoNzcpLGMoMCksYygxNDgpLGMoMCksYygxMzUpLGMo OTMpLGMoMSksYygyMDEpLGMoMCksYyg0MiksYygxNTkpLGMoMyksYyg0NCksYygxMDApLGMoMTg3 KSxjKDE2KSxjKDE0NSksYygxMiksYygxNDgpLGMoMTg1KSxjKDE1OCksYygxMjApLGMoMTEpLGMo MjQ1KSxjKDg2KSxjKDYwKSxjKDI0NyksYygxMiksYygxODUpLGMoNzkpLGMoMTM5KSxjKDc2KSxj KDE4OCksYygyOSksYygxOTYpLGMoMTE1KSxjKDgxKSxjKDI0NCksYyg5MiksYygxODYpLGMoMTky KSxjKDkxKSxjKDgwKSxjKDM3KSxjKDExMSksYygzNCksYygyMDcpLGMoMTY2KSxjKDEzNyksYyg3 MCksYyg3OSksYyg4NiksYygxMDApLGMoNjgpLGMoMTU3KSxjKDI1MyksYygxNjEpLGMoMTIpLGMo NzgpLGMoMTg2KSxjKDExKSxjKDEyMSksYyg3OSksYygxNiksYygyMDgpLGMoNjgpLGMoOTUpLGMo NjMpLGMoMTUyKSxjKDYxKSxjKDIzOCksYyg1OCksYygxODgpLGMoMTQ4KSxjKDEyNyksYygxNTAp LGMoMTI1KSxjKDI0NSksYygyMjMpLGMoNDApLGMoMjUxKSxjKDI0NSksYyg4NCksYygxOTIpLGMo NzIpLGMoNzApLGMoMTMwKSxjKDYwKSxjKDIwKSxjKDE2NyksYygzKSxjKDEwMiksYygzKSxjKDEw NiksYygyMTIpLGMoMTAzKSxjKDgzKSxjKDEwNSksYygxNzMpLGMoMTAwKSxjKDk0KSxjKDE3OCks YygxNDkpLGMoMjApLGMoMTQ4KSxjKDEwOSksYygxMjcpLGMoMjQpLGMoMjM3KSxjKDQzKSxjKDQ4 KSxjKDEwMSksYygyMjUpLGMoMTc3KSxjKDI0NCksYygyNDcpLGMoNjQpLGMoMjM1KSxjKDQyKSxj KDEyOSksYyg4MCksYygxNDkpLGMoNTApLGMoNTQpLGMoMTQzKSxjKDIyNCksYygxNCksYygxMDgp LGMoMTEpLGMoMTEwKSxjKDE1MCksYygxMDEpLGMoMTM4KSxjKDEyMiksYygxNTApLGMoMTUzKSxj KDIxMyksYyg0NCksYygxODgpLGMoNTYpLGMoNzQpLGMoMTUzKSxjKDExMSksYyg2MCksYyg2MSks YygxOCksYygxNjcpLGMoMTM1KSxjKDE3NCksYygyMTYpLGMoNDMpLGMoODApLGMoMjA4KSxjKDEp LGMoMjMyKSxjKDIzNiksYyg4MSksYygzNSksYygxMTQpLGMoMjI0KSxjKDIyNSksYygxMzIpLGMo MTU5KSxjKDExMiksYygxMzUpLGMoMTM1KSxjKDEyNSksYyg2MyksYygxNzEpLGMoMTY5KSxjKDE5 MCksYygxMjgpLGMoNjUpLGMoNSksYygyMjMpLGMoMjAxKSxjKDYxKSxjKDE2NSksYygxNjYpLGMo MjQ0KSxjKDIyNyksYyg4KSxjKDEzNyksYygxNzEpLGMoMTQxKSxjKDI0OSksYygxMDcpLGMoMjQ3 KSxjKDIyNyksYygxNDkpLGMoMTIwKSxjKDE0NSksYygyMyksYygyNDApLGMoMjMpLGMoMzIpLGMo ODMpLGMoMjA2KSxjKDc4KSxjKDI1MCksYygxMTkpLGMoNzkpLGMoODgpLGMoMTQxKSxjKDIxNiks Yyg5NCksYyg5NiksYygxMzApLGMoNzcpLGMoMTcpLGMoMTE3KSxjKDIyNSksYygyNDEpLGMoMTI4 KSxjKDEwOCksYygyMzUpLGMoMjQ4KSxjKDMpLGMoMTMxKSxjKDIxMSksYygyNDEpLGMoMjkpLGMo NDUpLGMoMTc2KSxjKDc2KSxjKDQpLGMoNzApLGMoODApLGMoMzIpLGMoOTUpLGMoMTUwKSxjKDU2 KSxjKDIzNCksYygxMDIpLGMoMjU0KSxjKDIxNiksYygyNyksYygyMDEpLGMoMTY5KSxjKDQ3KSxj KDIyNiksYyg4NyksYygyMDMpLGMoMTM3KSxjKDE5KSxjKDYpLGMoNTIpLGMoNjgpLGMoMTE0KSxj KDEwKSxjKDEyMCksYygyMTIpLGMoMzUpLGMoMTQzKSxjKDgyKSxjKDExOCksYygxNDApLGMoMTky KSxjKDEzMCksYyg2MCksYygyMzYpLGMoMTUpLGMoMTUwKSxjKDIxNyksYyg0KSxjKDE3OSksYygy NDIpLGMoOCksYygxMTQpLGMoMTAxKSxjKDEzOSksYygxNzIpLGMoMjQzKSxjKDE1NSksYygyMDAp LGMoMTgyKSxjKDEzKSxjKDg2KSxjKDE1NSksYygxNTgpLGMoNDYpLGMoMTQyKSxjKDIzOCksYygx NDgpLGMoMTU3KSxjKDcwKSxjKDYpLGMoMjA4KSxjKDEwNiksYygyMTApLGMoMTcwKSxjKDIxMSks YygyMjQpLGMoMTg3KSxjKDIzNyksYygyMTcpLGMoNjApLGMoMjA2KSxjKDE2NyksYygxNjApLGMo MTY3KSxjKDI0NSksYygxMDEpLGMoMTgzKSxjKDIyOSksYygxMjkpLGMoMjM5KSxjKDE4NiksYygy MTgpLGMoMjQ0KSxjKDI0MSksYygyOSksYyg3MiksYygxNjkpLGMoMjAwKSxjKDI1KSxjKDE5OCks Yyg0NCksYygyNDcpLGMoNjcpLGMoMTIpLGMoMTg5KSxjKDE5OSksYygxOSksYygxMzYpLGMoMjA3 KSxjKDYxKSxjKDExNiksYygzMSksYygyMzgpLGMoMTQ2KSxjKDE3MSksYygyMiksYygyNTIpLGMo MjI3KSxjKDI0MiksYygxNTMpLGMoNDUpLGMoMTA5KSxjKDExKSxjKDM4KSxjKDI0KSxjKDEwMiks YygxNTYpLGMoODkpLGMoNDApLGMoMTApLGMoMTU0KSxjKDI1KSxjKDE4NCksYygzOCksYygxNzMp LGMoMTAzKSxjKDI1MiksYyg0NiksYyg4MSksYygyMjYpLGMoMTcyKSxjKDIwNiksYygwKSxjKDE2 MCksYygyMTApLGMoMTMyKSxjKDE4KSxjKDIzOSksYyg4KSxjKDE0NiksYygxNDUpLGMoMTAwKSxj KDY0KSxjKDEyKSxjKDU3KSxjKDE4NCksYyg1MSksYygyMDIpLGMoMjcpLGMoMTcpLGMoMTk1KSxj KDE5NCksYygxOTgpLGMoNjYpLGMoMTY3KSxjKDIwNCksYygyNDUpLGMoODEpLGMoMTE3KSxjKDIw NCksYyg1NCksYygxOTApLGMoOTApLGMoNjMpLGMoMTgpLGMoMTgpLGMoMTE4KSxjKDE3KSxjKDIz OCksYyg0OCksYygxNDQpLGMoNDEpLGMoMTcwKSxjKDE2KSxjKDMwKSxjKDE0MCksYygxMTQpLGMo MTkyKSxjKDIyOCksYygyMjQpLGMoNTkpLGMoMTg2KSxjKDE2NiksYygxMTUpLGMoMjA4KSxjKDE4 NyksYyg0MiksYygxOTUpLGMoMjQpLGMoODQpLGMoMTk5KSxjKDc3KSxjKDIyOSksYyg4OCksYygx NSksYygyMCksYyg2MiksYyg3KSxjKDE3NSksYyg3NCksYygyNTMpLGMoNDgpLGMoODkpLGMoMTM3 KSxjKDIyKSxjKDI0MyksYygxMDIpLGMoMTk1KSxjKDEwKSxjKDIwMCksYygyNDgpLGMoNjEpLGMo NTkpLGMoMiksYygxNzcpLGMoNTEpLGMoMTUzKSxjKDE1MSksYygxNTkpLGMoOTYpLGMoNDMpLGMo MTQyKSxjKDE1MCksYygyMzApLGMoMTA0KSxjKDE0MSksYyg0NCksYygzMCksYyg2MyksYyg5Niks YygxODQpLGMoMTk1KSxjKDcpLGMoMjM4KSxjKDE0OSksYygxNDQpLGMoMTQ4KSxjKDgzKSxjKDg3 KSxjKDEwMSksYyg3MCksYyg1KSxjKDYwKSxjKDQ3KSxjKDIxKSxjKDI1MiksYygxMDIpLGMoMjgp LGMoMjQxKSxjKDY0KSxjKDIwKSxjKDIyMyksYygyMjYpLGMoMzkpLGMoMTY1KSxjKDIwMSksYygz MSksYygxMTYpLGMoMjYpLGMoNTEpLGMoMTc1KSxjKDIzOCksYygzMiksYyg2NSksYyg1OCksYyg4 MiksYygxMTUpLGMoNTEpLGMoMTk1KSxjKDIzMCksYygxODYpLGMoOCksYyg3NiksYygxNSksYygy NTQpLGMoMTI0KSxjKDE2NyksYygyMDcpLGMoMzgpLGMoMTc5KSxjKDIzNCksYygyMzMpLGMoMTQ1 KSxjKDk5KSxjKDE2NyksYygxNTQpLGMoMTI0KSxjKDI5KSxjKDg5KSxjKDIzNSksYygyNDgpLGMo ODEpLGMoMTg3KSxjKDE2NSksYygyMzkpLGMoMzQpLGMoMTY5KSxjKDIxNSksYygxMCksYyg5MSks YygxNDkpLGMoMjI5KSxjKDE2NSksYygyMzMpLGMoMTk4KSxjKDM0KSxjKDc3KSxjKDU3KSxjKDE1 NyksYygyNTEpLGMoMTE0KSxjKDEzOSksYygzMSksYygyMSksYygyMTUpLGMoNDIpLGMoOTEpLGMo MTE2KSxjKDU0KSxjKDE3KSxjKDE5MiksYygxMDIpLGMoMTY0KSxjKDgyKSxjKDE2MyksYygyMTAp LGMoMTUxKSxjKDEzKSxjKDIxOSksYygyMTApLGMoMjA3KSxjKDIyMyksYygxMTUpLGMoNDQpLGMo MjI3KSxjKDIyNiksYyg4MSksYygyMzApLGMoOTcpLGMoMzgpLGMoMjIwKSxjKDE0OSksYygxNDcp LGMoOSksYygzMCksYygyMyksYygxMTUpLGMoMTY4KSxjKDkzKSxjKDI0KSxjKDc1KSxjKDg0KSxj KDEzMSksYyg5MCksYygxMiksYygxMDgpLGMoMTY4KSxjKDEzMCksYygyMzcpLGMoMTcyKSxjKDI0 OCksYygyMTApLGMoOTApLGMoMTc5KSxjKDM5KSxjKDE3MyksYygxNjQpLGMoMTEyKSxjKDQ2KSxj KDQ5KSxjKDYxKSxjKDExNiksYyg2MiksYyg0MiksYygxMDgpLGMoMTcwKSxjKDEpLGMoMjQ5KSxj KDQzKSxjKDY4KSxjKDU2KSxjKDI3KSxjKDE5NCksYygyMjgpLGMoNjEpLGMoMTg5KSxjKDEwMSks YygxNzUpLGMoNjUpLGMoNjcpLGMoMjIxKSxjKDIxNCksYygxMTUpLGMoMjIwKSxjKDI0MyksYyg5 OSksYygxODUpLGMoOTQpLGMoNDkpLGMoMTgxKSxjKDI0NSksYygxMSksYygzNCksYygxNTcpLGMo NDQpLGMoMTkpLGMoMjE0KSxjKDI0MCksYygyMzgpLGMoMzkpLGMoMjUyKSxjKDI2KSxjKDIxMyks YygyMTcpLGMoMTk0KSxjKDI0OCksYygyMTMpLGMoMTAzKSxjKDExMCksYygzNyksYygyMzcpLGMo MTQwKSxjKDQwKSxjKDMzKSxjKDc4KSxjKDIyNCksYygxMzMpLGMoOTkpLGMoMTMpLGMoMTIzKSxj KDI1KSxjKDE1MSksYyg3KSxjKDEwOCksYyg1OCksYyg1MCksYygxODgpLGMoNjEpLGMoNzQpLGMo NTQpLGMoMTEzKSxjKDE0MyksYygxMTgpLGMoMTgpLGMoNDYpLGMoMjMwKSxjKDI1MSksYygxNTIp LGMoMTU4KSxjKDEyNCksYyg4OCksYygyMzcpLGMoMjAyKSxjKDIzMyksYygyMSksYygxMjYpLGMo MTYpLGMoMjI0KSxjKDU0KSxjKDcxKSxjKDI0MSksYyg2MCksYyg4NiksYyg2NyksYygxMDYpLGMo MjMzKSxjKDIzNyksYygyNTApLGMoNzgpLGMoMTcxKSxjKDg5KSxjKDE2MyksYygyMTcpLGMoMTgw KSxjKDExMiksYygyMzYpLGMoMjM2KSxjKDkxKSxjKDI0KSxjKDI1MSksYygyMTcpLGMoMTM5KSxj KDIyKSxjKDI2KSxjKDE4OSksYygyMDIpLGMoNzcpLGMoMTcyKSxjKDU3KSxjKDI1KSxjKDE1Miks YygyNDUpLGMoMTMyKSxjKDQwKSxjKDI0OCksYygxODIpLGMoMTIpLGMoOTYpLGMoMjIwKSxjKDIy OSksYyg1MCksYygxNTYpLGMoMTA4KSxjKDIyOSksYygyMTcpLGMoMTApLGMoMTkxKSxjKDg2KSxj KDU5KSxjKDkxKSxjKDEwMSksYygyNDgpLGMoMTI4KSxjKDgzKSxjKDkpLGMoMTgyKSxjKDI0Nyks YygxNDUpLGMoMTAzKSxjKDEzMSksYygxNzYpLGMoMTE2KSxjKDEzNyksYygxODcpLGMoNzApLGMo MzIpLGMoMjExKSxjKDIxNiksYygxNjMpLGMoOTYpLGMoMTY3KSxjKDExNyksYygxNTApLGMoNTgp LGMoMTEpLGMoMTAxKSxjKDEpLGMoMTg4KSxjKDExKSxjKDEzOCksYyg5MCksYygzNiksYygxMzkp LGMoNDApLGMoMjI2KSxjKDEyMCksYygyMDQpLGMoMTExKSxjKDEzMyksYygxNCksYygxNDkpLGMo MTE5KSxjKDE3NiksYygyNTIpLGMoMTczKSxjKDIzMiksYyg4MyksYygzNCksYyg3NSksYyg1NCks YygyKSxjKDE1NSksYygxMDApLGMoMjQ2KSxjKDApLGMoNjEpLGMoMjQ1KSxjKDUyKSxjKDE0Nyks YygxMTYpLGMoMTI5KSxjKDMzKSxjKDU4KSxjKDQxKSxjKDEzKSxjKDk3KSxjKDEwKSxjKDEzOCks Yyg3NyksYygyMzEpLGMoODkpLGMoMTEpLGMoMTM0KSxjKDE1MCksYyg2NSksYyg3KSxjKDk0KSxj KDY1KSxjKDY1KSxjKDE5KSxjKDE2OCksYygyMSksYygyMiksYygxNTMpLGMoMjQ1KSxjKDYzKSxj KDIyKSxjKDEyNSksYyg1OCksYyg4NCksYygxOSksYyg5MiksYygyMTYpLGMoMTc0KSxjKDUwKSxj KDE5KSxjKDIyNCksYygyMzUpLGMoMTc2KSxjKDIzKSxjKDEwOSksYygxNDIpLGMoMjEwKSxjKDg5 KSxjKDIyNCksYygyMDMpLGMoMTE5KSxjKDEzMiksYygyMzIpLGMoMTc0KSxjKDEyMiksYygyMDcp LGMoMjE0KSxjKDM4KSxjKDgzKSxjKDIxOCksYygyMjIpLGMoMTcxKSxjKDE4OCksYyg2KSxjKDEx MSksYyg2MiksYygyNTIpLGMoMTQ1KSxjKDE2MiksYygyMzQpLGMoOTIpLGMoMTQ4KSxjKDI1Myks YygyMjUpLGMoMjE2KSxjKDE2KSxjKDY1KSxjKDE2NyksYyg2NCksYygyNDgpLGMoNTgpLGMoMjQ2 KSxjKDQxKSxjKDIxMCksYygxNzkpLGMoMjI5KSxjKDIxMSksYygyMCksYygyMjApLGMoMTA2KSxj KDM0KSxjKDE3MiksYygxMTApLGMoMjUyKSxjKDExNiksYygxMTYpLGMoMTA3KSxjKDE2MiksYygy MTQpLGMoMTM5KSxjKDE2NyksYygyMTQpLGMoMjI1KSxjKDIwNCksYygyMzcpLGMoNjYpLGMoMCks YygxMjQpLGMoNzUpLGMoMTUpLGMoMjYpLGMoMTI1KSxjKDE3NyksYygxMDApLGMoOTQpLGMoMTU0 KSxjKDI0NSksYyg4MCksYyg1MCksYyg3KSxjKDM4KSxjKDIxMCksYygxMjEpLGMoMTY0KSxjKDIw NyksYygzNyksYygzOCksYyg1OCksYygzMyksYygxMTgpLGMoNTgpLGMoMTUyKSxjKDEwKSxjKDM2 KSxjKDE0NiksYyg1OCksYygyMzUpLGMoMjA3KSxjKDE0OCksYyg5NiksYygxMjcpLGMoMjI2KSxj KDIxNCksYygyMzMpLGMoOTcpLGMoNjIpLGMoMiksYygyMjEpLGMoMTIzKSxjKDY0KSxjKDI2KSxj KDIwMSksYygyMzIpLGMoODYpLGMoMTYyKSxjKDIxNCksYygyMzcpLGMoODEpLGMoMjQ2KSxjKDE0 MCksYyg3NyksYygxNTkpLGMoMjQwKSxjKDYyKSxjKDg3KSxjKDEwKSxjKDUyKSxjKDYwKSxjKDEx MiksYygyMjIpLGMoMzMpLGMoNjMpLGMoMTM5KSxjKDI0KSxjKDQzKSxjKDUzKSxjKDE1KSxjKDI2 KSxjKDQ1KSxjKDI3KSxjKDIwKSxjKDE5KSxjKDIyNSksYygxOTIpLGMoMTM0KSxjKDMwKSxjKDk5 KSxjKDEzMiksYygyNDcpLGMoMzcpLGMoMjI3KSxjKDIyMyksYygyNDUpLGMoMTgpLGMoMTcwKSxj KDIwOSksYygyNDIpLGMoMjEyKSxjKDI0NSksYygzOSksYyg4NSksYygwKSxjKDIzOCksYygxMTEp LGMoMjMwKSxjKDM0KSxjKDIzNyksYyg0NCksYyg3MiksYygxMDIpLGMoMTQ2KSxjKDExNSksYygx MDUpLGMoMjUwKSxjKDQ0KSxjKDc1KSxjKDIzKSxjKDcwKSxjKDQzKSxjKDEwMyksYygxNTgpLGMo NjMpLGMoNzMpLGMoMTEyKSxjKDIyMiksYygxMjcpLGMoNjEpLGMoMTY0KSxjKDE1NSksYygyNTMp LGMoMjExKSxjKDQ4KSxjKDE2NiksYygzOSksYygxMDkpLGMoMTI5KSxjKDQ0KSxjKDI1KSxjKDM2 KSxjKDIyOCksYygxNCksYyg0MSksYyg1MSksYygyMzUpLGMoMjI3KSxjKDIxNyksYygxMDApLGMo MjE3KSxjKDEyOCksYygxMzMpLGMoMjI3KSxjKDEzMyksYygxMjQpLGMoMTYyKSxjKDIxNiksYygy MDkpLGMoMTI0KSxjKDExNyksYyg2MyksYyg2MSksYygxMTYpLGMoMTk0KSxjKDg5KSxjKDIwOSks YygxOTUpLGMoMjAyKSxjKDE5MSksYygxNzkpLGMoMTI1KSxjKDI0NCksYygxODEpLGMoNDgpLGMo MTE5KSxjKDgyKSxjKDE3MCksYygxNzQpLGMoNDgpLGMoMTY4KSxjKDE5MCksYygxNzYpLGMoMTgx KSxjKDI5KSxjKDEyMCksYygzOSksYygxNjUpLGMoMTgzKSxjKDEyNyksYyg2MSksYyg5NSksYyg1 MyksYygxMDApLGMoMTMzKSxjKDI0MCksYygxMjIpLGMoMTgyKSxjKDE4MiksYyg1MSksYygxODIp LGMoNjkpLGMoMjE4KSxjKDgxKSxjKDQ0KSxjKDEyOCksYygxMzgpLGMoMjUxKSxjKDIwNCksYygx MSksYygxMjYpLGMoMTY0KSxjKDk0KSxjKDE2NCksYygxNDIpLGMoMjIxKSxjKDEyNyksYygyMDAp LGMoNzkpLGMoMTcxKSxjKDYzKSxjKDg4KSxjKDE0MCksYygxOTQpLGMoNjUpLGMoMTExKSxjKDI1 MyksYygxNTMpLGMoMTc1KSxjKDE3MSksYygyMTgpLGMoNzIpLGMoNjYpLGMoMTgwKSxjKDEzOCks YygxNDYpLGMoODkpLGMoMTUxKSxjKDE2MSksYygyNDYpLGMoMjEzKSxjKDIzNSksYyg4NyksYygx MiksYygxNTMpLGMoMjAwKSxjKDIyMiksYygxNiksYygxMjApLGMoMjA4KSxjKDUzKSxjKDIwNSks YygxNzUpLGMoMzYpLGMoMTk1KSxjKDIyNCksYygxNzkpLGMoMSksYygxODApLGMoNzYpLGMoMTc5 KSxjKDIxMiksYyg0OSksYygzNSksYygxMTUpLGMoMTExKSxjKDE4OSksYygxNDEpLGMoMTQpLGMo MjE0KSxjKDI4KSxjKDEwOCksYyg2NyksYygyMyksYygxNzMpLGMoMzIpLGMoMjQzKSxjKDEzMiks YygxNDkpLGMoMTYyKSxjKDExNSksYygxOTQpLGMoODIpLGMoMTIpLGMoMTcyKSxjKDI0OCksYygx OCksYyg2NiksYygyMDYpLGMoMTYzKSxjKDE4MSksYygyMzkpLGMoMjA0KSxjKDM1KSxjKDUxKSxj KDE5NCksYygyMzYpLGMoMTIxKSxjKDgyKSxjKDc4KSxjKDc3KSxjKDU0KSxjKDk5KSxjKDc5KSxj KDgwKSxjKDEpLGMoMTc2KSxjKDkxKSxjKDY2KSxjKDE3OCksYygxODIpLGMoMjE5KSxjKDE0MSks YygxMTQpLGMoMTg4KSxjKDIpLGMoMjE5KSxjKDEzNSksYygxMzkpLGMoMjQzKSxjKDExNCksYyg3 KSxjKDE0MCksYygzKSxjKDc2KSxjKDMwKSxjKDY2KSxjKDE4NSksYygxODkpLGMoNzMpLGMoMTc4 KSxjKDIzOSksYygxMjgpLGMoMTQ4KSxjKDQwKSxjKDEyNSksYygyMjIpLGMoNTkpLGMoMTg3KSxj KDEwOCksYyg5OSksYygxNjcpLGMoMTc5KSxjKDc5KSxjKDE4MCksYygxMjgpLGMoMjIxKSxjKDYw KSxjKDExNyksYygxNjIpLGMoMzUpLGMoMCksYyg1OCksYyg4NiksYygyMDkpLGMoNCksYyg1OSks YygxNjkpLGMoNzYpLGMoMTU3KSxjKDg4KSxjKDApLGMoMTIyKSxjKDYxKSxjKDExNyksYyg1Niks YygxODIpLGMoMzQpLGMoMiksYygxODcpLGMoMjApLGMoMzIpLGMoMTc5KSxjKDIxOSksYygxNjEp LGMoNzYpLGMoMjM2KSxjKDIzNiksYygxNjQpLGMoMTA5KSxjKDIyNCksYygxMjMpLGMoMjkpLGMo OTEpLGMoODMpLGMoMjIpLGMoMjI1KSxjKDE3MCksYyg3KSxjKDIwMCksYygxMDYpLGMoMTM5KSxj KDE3OSksYyg1NSksYygxMjUpLGMoMjA3KSxjKDEzMSksYygzNyksYyg3MyksYygxODYpLGMoMTQw KSxjKDIxMCksYygyNiksYyg3MCksYyg0OSksYygxNDgpLGMoNTIpLGMoMjI3KSxjKDc3KSxjKDI3 KSxjKDE0MSksYygxMjcpLGMoMTI1KSxjKDE1MCksYygxOCksYygxMDkpLGMoNDUpLGMoNSksYyg3 OSksYygyNTEpLGMoNjcpLGMoNTUpLGMoMjIxKSxjKDE0MCksYygxMTApLGMoMTM0KSxjKDE1NCks YygyMDQpLGMoNDcpLGMoMjI0KSxjKDQ1KSxjKDExMyksYygxOTApLGMoNDMpLGMoODEpLGMoMTg1 KSxjKDE3NiksYyg2NCksYygxNjApLGMoMTM5KSxjKDQpLGMoNjQpLGMoMTYxKSxjKDE2MSksYygy MTEpLGMoMTEpLGMoMjI3KSxjKDgxKSxjKDE3MCksYygxODYpLGMoMTQwKSxjKDIxMCksYygyKSxj KDE2MiksYygxMjkpLGMoMjEyKSxjKDI1NSksYygxMTgpLGMoMjEpLGMoMjQzKSxjKDI0MSksYyg5 NSksYygyMjkpLGMoNzkpLGMoMjcpLGMoNDQpLGMoMTcpLGMoOCksYyg5NCksYygxNDcpLGMoMjUx KSxjKDI0MyksYyg2NCksYygyNDIpLGMoMTY4KSxjKDExMiksYygyMTEpLGMoMzIpLGMoMjE5KSxj KDEwNCksYyg1KSxjKDIwKSxjKDg0KSxjKDE3MyksYygxNzkpLGMoOTEpLGMoODEpLGMoNjkpLGMo MjA0KSxjKDYzKSxjKDM3KSxjKDEyMCksYygxMjkpLGMoOTIpLGMoMjE4KSxjKDE0MCksYygzKSxj KDIwNCksYygxNjgpLGMoOTcpLGMoMzEpLGMoMTQ0KSxjKDI2KSxjKDkpLGMoNjYpLGMoNyksYygy MTEpLGMoNzgpLGMoMTkzKSxjKDU5KSxjKDQpLGMoMTM3KSxjKDE4MyksYygyNTUpLGMoNDMpLGMo MTA3KSxjKDg0KSxjKDE4OSksYygxMjgpLGMoMjIyKSxjKDE0MCksYyg1NyksYygxNDUpLGMoMTc4 KSxjKDE4MyksYyg4NyksYygxMTcpLGMoNjQpLGMoMjE1KSxjKDE2NSksYygzKSxjKDE2MiksYygx MjcpLGMoNTcpLGMoNDgpLGMoMTg4KSxjKDExNSksYygyKSxjKDExNCksYygxMiksYygxMTQpLGMo NTUpLGMoMjcpLGMoMTI1KSxjKDIwMyksYyg3KSxjKDEyNSksYygzMiksYyg0NyksYygxNTUpLGMo MTQwKSxjKDE4OSksYygyMzcpLGMoMjQpLGMoMjQzKSxjKDI1MCksYyg4NiksYygxOTMpLGMoMjI3 KSxjKDM1KSxjKDQ0KSxjKDIxNiksYygxNDUpLGMoMTg5KSxjKDg4KSxjKDE4NCksYygxOTMpLGMo MTE3KSxjKDk4KSxjKDc0KSxjKDc3KSxjKDUwKSxjKDE4OSksYyg5MiksYyg4NSksYyg4OCksYyg0 KSxjKDE2OCksYygyNiksYyg3NSksYyg5OSksYygxMjYpLGMoNDcpLGMoNyksYyg3MSksYygxMjYp LGMoMjAxKSxjKDExOCksYygxMjIpLGMoMjYpLGMoMTY5KSxjKDg5KSxjKDEzMCksYygyMTgpLGMo MTcwKSxjKDgxKSxjKDE5NCksYyg5OSksYygxODEpLGMoNTApLGMoNDQpLGMoMzEpLGMoNjcpLGMo MTExKSxjKDY1KSxjKDU0KSxjKDY3KSxjKDI0NiksYygxOSksYygyMTQpLGMoODIpLGMoMTg0KSxj KDEwMCksYygyMzEpLGMoMTE2KSxjKDE2OCksYygxODgpLGMoNDMpLGMoODkpLGMoODgpLGMoNjQp LGMoMTc4KSxjKDExMiksYygxNjkpLGMoMTk5KSxjKDIxNSksYygyMTUpLGMoMjUwKSxjKDI1NSks YygxNzgpLGMoMTM0KSxjKDYpLGMoMTcpLGMoMSksYygxMiksYygyMjkpLGMoMTcwKSxjKDIwOCks YygyNiksYyg5OCksYygxMjgpLGMoMjYpLGMoMTg4KSxjKDIxMCksYygyMzApLGMoMzUpLGMoMTU2 KSxjKDI1MiksYyg0OCksYygzMSksYyg2NyksYygxOTYpLGMoNDYpLGMoNTMpLGMoNjApLGMoMTIy KSxjKDI0MiksYyg1NCksYygxMyksYyg2MCksYygyNDIpLGMoMTk5KSxjKDE0MCksYygxOTApLGMo MjM3KSxjKDIyNCksYyg4NCksYygxMTMpLGMoOTQpLGMoMTE0KSxjKDgwKSxjKDM0KSxjKDE0OSks YygzNyksYyg4NCksYygxMzgpLGMoNzIpLGMoMTg2KSxjKDE4MCksYygxMjQpLGMoOTkpLGMoMjMx KSxjKDExNiksYygxNzcpLGMoMTIwKSxjKDEwMyksYygxNTcpLGMoMzcpLGMoMTI5KSxjKDI1NCks YygxNTgpLGMoMTc5KSxjKDIwKSxjKDU2KSxjKDExOSksYygyMjgpLGMoODgpLGMoMTIzKSxjKDEw KSxjKDIwOSksYygyMjIpLGMoMTgxKSxjKDIyNyksYygxMjgpLGMoMjUwKSxjKDExMCksYyg3NSks YygxMzcpLGMoMTA1KSxjKDEwKSxjKDE2NiksYygxMjUpLGMoNjQpLGMoOTgpLGMoMjMzKSxjKDIy NyksYygxNTIpLGMoMTM2KSxjKDkwKSxjKDI1MiksYygxOTMpLGMoMjI2KSxjKDExMyksYygyMjcp LGMoOTApLGMoNTEpLGMoODgpLGMoMTI3KSxjKDYyKSxjKDE3OCksYygyOSksYygyMjQpLGMoMTI1 KSxjKDE4KSxjKDkzKSxjKDE5NCksYygxNzQpLGMoNzQpLGMoMjM4KSxjKDE4NSksYygzMCksYygx ODApLGMoODcpLGMoNzkpLGMoMTgzKSxjKDIzNCksYygxOTApLGMoOCksYygxMjUpLGMoMTI0KSxj KDIyNCksYygyMSksYygyMjIpLGMoMTU5KSxjKDYpLGMoNDEpLGMoMjA5KSxjKDcpLGMoMjYpLGMo MjIyKSxjKDIyKSxjKDk1KSxjKDIwNyksYygxNjQpLGMoMzkpLGMoOTIpLGMoNzUpLGMoMjUpLGMo MTcxKSxjKDE0MyksYygyNDgpLGMoNzIpLGMoMjIpLGMoOTUpLGMoMTM1KSxjKDE2NCksYyg2OSks YygyMjYpLGMoODUpLGMoNDMpLGMoMjExKSxjKDIwNyksYygyMzIpLGMoNjIpLGMoMTIxKSxjKDE3 KSxjKDEwOSksYygyMyksYygyMzApLGMoNDMpLGMoOCksYyg4OCksYygyNyksYyg1MSksYygxMDcp LGMoNiksYygxOTApLGMoMTIwKSxjKDQpLGMoMjQ3KSxjKDIxMSksYyg1OCksYygyOSksYygxNyks Yyg1KSxjKDQyKSxjKDM2KSxjKDE4MiksYygyMjQpLGMoMTA5KSxjKDU2KSxjKDIzNSksYygyNSks YygyMDkpLGMoMjI0KSxjKDExMyksYygxNTIpLGMoNDYpLGMoMTUxKSxjKDIxKSxjKDEzNyksYygy NTMpLGMoNjApLGMoMjEpLGMoMjEpLGMoMTU4KSxjKDIzMyksYygxNTApLGMoMTA5KSxjKDIzNyks Yyg5NSksYygxOTIpLGMoMjQpLGMoNjkpLGMoMTg1KSxjKDIzKSxjKDMzKSxjKDIxMCksYygxMDMp LGMoMjApLGMoMjEpLGMoMjQyKSxjKDkpLGMoMTYwKSxjKDM0KSxjKDIyNSksYyg3MyksYygxNTUp LGMoODMpLGMoMTQzKSxjKDIyNyksYyg5MCksYygxMzApLGMoMjE2KSxjKDEyNSksYygxMTgpLGMo NzMpLGMoMjAwKSxjKDUwKSxjKDg4KSxjKDc2KSxjKDE4NCksYygyMzUpLGMoMjIzKSxjKDExNyks Yyg1NyksYyg1NCksYygxNzgpLGMoMTkxKSxjKDY2KSxjKDg0KSxjKDc1KSxjKDEzMCksYyg0NSks YygxNjEpLGMoNDMpLGMoMTI0KSxjKDE4NCksYyg3NCksYygxNjIpLGMoMTQwKSxjKDMzKSxjKDE5 MyksYyg1MCksYygxNDApLGMoODgpLGMoODIpLGMoMTkzKSxjKDE4MCksYyg2NyksYyg3MiksYygx MDMpLGMoMTE2KSxjKDE4NiksYyg1MSksYygxNSksYygyNDYpLGMoMTEpLGMoODgpLGMoODEpLGMo MTYxKSxjKDIzOCksYygyMzUpLGMoNTYpLGMoNTcpLGMoMjIpLGMoMzQpLGMoNTgpLGMoMjE0KSxj KDIzNiksYygxMDMpLGMoMTcyKSxjKDE1MyksYygxMiksYygyMjcpLGMoMjIwKSxjKDk5KSxjKDEw OSksYyg2NiksYygyNTQpLGMoNDYpLGMoMjUzKSxjKDIzMCksYygxMTUpLGMoMjI4KSxjKDIzNCks YygyMDMpLGMoMTIwKSxjKDE5NSksYygxODMpLGMoMTAzKSxjKDkyKSxjKDE1OCksYygxNTQpLGMo NzgpLGMoMTk3KSxjKDEyNyksYygyNCksYygxMDcpLGMoMTc4KSxjKDE4OSksYyg3OCksYygxMzQp LGMoMTg3KSxjKDE4MCksYyg3MiksYyg3NSksYygyMjcpLGMoNTApLGMoMjIzKSxjKDE5OCksYyg5 MSksYygzNSksYygxNjcpLGMoMjUyKSxjKDE2NCksYygxNjcpLGMoMTcxKSxjKDE2MiksYygyOSks YygyMjApLGMoOTUpLGMoMTA1KSxjKDExNiksYygxNiksYygyNDQpLGMoMjM0KSxjKDE4NCksYygx NzUpLGMoODMpLGMoODkpLGMoMTQyKSxjKDIzKSxjKDE5NyksYyg4NyksYygxNTEpLGMoNTYpLGMo MTc1KSxjKDIyNSksYygxMTApLGMoMjA0KSxjKDYxKSxjKDE0KSxjKDExNSksYyg2MCksYygxMzUp LGMoNDcpLGMoMjMpLGMoMTUzKSxjKDE3NSksYygyMzQpLGMoNDApLGMoOTYpLGMoMjU0KSxjKDg3 KSxjKDEwKSxjKDIyNCksYyg2OSksYyg5NyksYygxMDIpLGMoMTgpLGMoMjkpLGMoMTM2KSxjKDEx NCksYygxMDIpLGMoODQpLGMoMjMxKSxjKDEzNyksYygzMiksYygxNjEpLGMoMjI4KSxjKDEwOCks YygxNjApLGMoOCksYygxNDgpLGMoMjMzKSxjKDEzMyksYygxOSksYygwKSxjKDEzOCksYygxOCks YygyMTApLGMoMTkyKSxjKDExMCksYyg0KSxjKDE5MyksYygxOTIpLGMoMTg4KSxjKDM1KSxjKDEx MiksYygyMDEpLGMoMTAyKSxjKDY4KSxjKDIzKSxjKDE0NiksYyg3MiksYygxOTYpLGMoMTU2KSxj KDI1MCksYyg1NSksYygxMDgpLGMoODApLGMoMjIxKSxjKDE2OCksYyg3NCksYyg2MyksYygyMDcp LGMoMTA0KSxjKDIxMSksYyg1OCksYygxMTUpLGMoNDMpLGMoMTg4KSxjKDE2OSksYygxMjYpLGMo ODgpLGMoMjA4KSxjKDE2NiksYygxMTApLGMoNzYpLGMoMjA4KSxjKDc4KSxjKDEyMyksYyg2NSks Yyg3OSksYygxNzgpLGMoNjIpLGMoNjApLGMoMTQ2KSxjKDE5OCksYygxNTgpLGMoNzYpLGMoMTAz KSxjKDE4MyksYygxKSxjKDEyOCksYygxOTYpLGMoMTgyKSxjKDExNyksYygxMjgpLGMoMjE3KSxj KDEyMyksYyg5NCksYygxMTMpLGMoOTQpLGMoMzgpLGMoMTMpLGMoMjMxKSxjKDI1NCksYyg5Nyks YygyMjApLGMoMTM3KSxjKDE3MCksYygxNTYpLGMoNDEpLGMoMTM4KSxjKDEzMCksYygxNTgpLGMo MjQxKSxjKDgwKSxjKDEzNSksYygzMCksYygzMCksYygxMDIpLGMoMjE0KSxjKDM0KSxjKDE0NCks YygxMDkpLGMoNzEpLGMoNTApLGMoMjEyKSxjKDEzNyksYygxMDgpLGMoMTE0KSxjKDIwNCksYygx NDMpLGMoMjM5KSxjKDE1OCksYygyMiksYyg3OSksYygyMjYpLGMoNTIpLGMoMzEpLGMoMjQyKSxj KDEyMCksYyg3NSksYygxMDQpLGMoMTYwKSxjKDEyNyksYygzOSksYyg0MSksYygxNzUpLGMoNDIp LGMoMTMwKSxjKDEyOCksYygxMTEpLGMoMTkxKSxjKDI0KSxjKDEyNiksYygxNjcpLGMoMjU1KSxj KDE5OCksYyg4NCksYygxMjUpLGMoMTg3KSxjKDE3OCksYygyMCksYyg5MSksYygyMzkpLGMoMjE2 KSxjKDEwNiksYygxMjYpLGMoMTI5KSxjKDEzOSksYygxNDYpLGMoNjEpLGMoMjIpLGMoODcpLGMo MjExKSxjKDIzOSksYygyMDEpLGMoNzkpLGMoMTY2KSxjKDI1KSxjKDEwMCksYygyNDcpLGMoMjUz KSxjKDEyKSxjKDIyNiksYyg2MSksYygxMCksYygxNTIpLGMoOTEpLGMoMTU0KSxjKDI0OCksYyg3 MyksYyg0NSksYygxOCksYygxMDgpLGMoMTM1KSxjKDU2KSxjKDEwMSksYygxNTMpLGMoMjIpLGMo MTc4KSxjKDIyOCksYyg5NCksYyg0NyksYygxOTQpLGMoMjQxKSxjKDU1KSxjKDk4KSxjKDE4OCks Yyg4NCksYyg0KSxjKDExNSksYygyMzApLGMoMTkwKSxjKDI5KSxjKDM2KSxjKDg2KSxjKDE0OCks YygyMTcpLGMoMTcyKSxjKDE0MCksYyg2MSksYygxNzYpLGMoMTEzKSxjKDIxMCksYygzNiksYygx MTQpLGMoMTE0KSxjKDExMiksYyg4MSksYygxMzApLGMoMTk0KSxjKDEyOCksYyg5MCksYyg4NCks YygyNDkpLGMoMjI0KSxjKDYyKSxjKDIxMiksYygyMjkpLGMoMjMxKSxjKDIwOCksYygxMTIpLGMo MzIpLGMoMjgpLGMoMTIpLGMoNTEpLGMoMjMzKSxjKDYwKSxjKDI4KSxjKDUzKSxjKDExNyksYygz OSksYyg4MyksYyg1OSksYygxNDIpLGMoMTM1KSxjKDIyMCksYygyMDYpLGMoMjQwKSxjKDIzNiks YygxMTcpLGMoMTI0KSxjKDIxNSksYygxNDUpLGMoMjI4KSxjKDIxNyksYygxMDUpLGMoMTI3KSxj KDE5NCksYygyMjQpLGMoMTE1KSxjKDIzNSksYygzNSksYygxNzkpLGMoMTU3KSxjKDEzNSksYygx MDgpLGMoNzMpLGMoMjQyKSxjKDE0NSksYyg1KSxjKDMwKSxjKDUpLGMoMTcpLGMoOTUpLGMoOTkp LGMoMTcyKSxjKDc3KSxjKDI0MCksYygyMCksYygxMSksYygyMjYpLGMoMTUyKSxjKDg1KSxjKDEx NSksYyg4NSksYygyMzQpLGMoMTUyKSxjKDE2NCksYygxMTApLGMoMTY3KSxjKDI1MCksYygxOTEp LGMoMTc4KSxjKDIzMyksYyg4OSksYyg3OSksYygxNzgpLGMoMTcpLGMoMTg3KSxjKDQwKSxjKDU5 KSxjKDk3KSxjKDEzNiksYyg3KSxjKDExOSksYygyMTIpLGMoNzYpLGMoMTA0KSxjKDEyNiksYyg3 KSxjKDI0MCksYyg5NyksYygyMyksYygzKSxjKDQzKSxjKDEyMiksYygxNjcpLGMoMTM4KSxjKDE3 KSxjKDExKSxjKDM4KSxjKDY2KSxjKDE3KSxjKDI0MCksYygyMTApLGMoNTEpLGMoMjAwKSxjKDIx MSksYygxNDIpLGMoNjEpLGMoMiksYyg5KSxjKDYzKSxjKDMwKSxjKDExMiksYygxMDMpLGMoMTI4 KSxjKDIyMCksYygxNzEpLGMoMTIwKSxjKDEyNyksYygyMyksYygyMTIpLGMoNzkpLGMoMjU1KSxj KDEzMSksYyg2NSksYyg1NSksYygxNTUpLGMoMTM2KSxjKDQyKSxjKDIxOSksYyg4NiksYygzMiks Yyg1OCksYygxNzYpLGMoMTE4KSxjKDE2MCksYygxNzYpLGMoNjYpLGMoMTgzKSxjKDIwKSxjKDkw KSxjKDY1KSxjKDIwNyksYygxOTMpLGMoNDkpLGMoNjgpLGMoMjAxKSxjKDExMyksYygxNjYpLGMo OSksYygyMzcpLGMoMTk4KSxjKDE1KSxjKDE4MyksYyg2OCksYygxMTApLGMoMjE3KSxjKDIyNiks YygxMjcpLGMoMTMzKSxjKDE1KSxjKDIxMyksYygxNDcpLGMoMTg3KSxjKDE4NSksYyg3MyksYyg0 NSksYygxOSksYygxNjIpLGMoMTY2KSxjKDE0NiksYyg0MSksYygxNzUpLGMoNDUpLGMoMTcpLGMo MjQyKSxjKDM4KSxjKDQ3KSxjKDIxNSksYygyMTIpLGMoNDYpLGMoMTAxKSxjKDE2MyksYygxNTgp LGMoNzMpLGMoMjUzKSxjKDEyMyksYygyMTIpLGMoMzApLGMoMTkzKSxjKDEwMCksYyg3KSxjKDIw NyksYyg5OSksYygyMjkpLGMoNTgpLGMoMjM4KSxjKDEzMCksYygxNjApLGMoMTk2KSxjKDI1MCks YygyMDcpLGMoMTAxKSxjKDcyKSxjKDIxKSxjKDgwKSxjKDcwKSxjKDIyOCksYygxODgpLGMoMjI4 KSxjKDUwKSxjKDEwNCksYygxNzYpLGMoMTM2KSxjKDMyKSxjKDEyNiksYyg0NSksYyg5KSxjKDEy NiksYygxNzgpLGMoNDEpLGMoMjQ5KSxjKDE4MSksYygxNDQpLGMoMTI4KSxjKDExMyksYygyNTAp LGMoMTEyKSxjKDkwKSxjKDg5KSxjKDIwMyksYygyNDQpLGMoMTU2KSxjKDk3KSxjKDEzNyksYygx MTYpLGMoMjQ3KSxjKDIxOSksYygxMzIpLGMoMTEpLGMoMTYzKSxjKDU3KSxjKDMwKSxjKDExOCks YygxODgpLGMoMTQ2KSxjKDMyKSxjKDU1KSxjKDEyMyksYygxNzMpLGMoMTA2KSxjKDU5KSxjKDAp LGMoMTY5KSxjKDEwNiksYyg4MyksYygxNDgpLGMoMTMpLGMoMjU1KSxjKDEzMSksYygxNDgpLGMo MTIwKSxjKDQ2KSxjKDEyMiksYygxMjQpLGMoOTIpLGMoMjAwKSxjKDE3NyksYygxMzYpLGMoMTU4 KSxjKDExKSxjKDE2NyksYygxODEpLGMoMTYwKSxjKDI3KSxjKDYyKSxjKDk5KSxjKDEyNCksYygx NjApLGMoMTgwKSxjKDE2OSksYyg0OSksYygxMjgpLGMoOTQpLGMoMiksYygxNzUpLGMoNjYpLGMo MTMxKSxjKDIxMyksYygxMDEpLGMoMTY2KSxjKDEwKSxjKDE1MSksYygyMTgpLGMoMjUyKSxjKDE1 OSksYygxMjYpLGMoMTQzKSxjKDIyNiksYygxMTMpLGMoODQpLGMoMjE2KSxjKDE5NyksYygxOTUp LGMoNjQpLGMoNDMpLGMoMjQxKSxjKDgwKSxjKDIyOCksYygyMiksYygyMzApLGMoMTcyKSxjKDE3 KSxjKDMwKSxjKDI0OSksYygyMzQpLGMoMTk5KSxjKDIwKSxjKDE1NyksYyg5KSxjKDIyOCksYygy MzkpLGMoMjQpLGMoMTExKSxjKDIxKSxjKDIyNSksYygzNyksYygyMzYpLGMoNzApLGMoMjMpLGMo MjMwKSxjKDQzKSxjKDE5NSksYygyMzMpLGMoMjYpLGMoMjA5KSxjKDEwNiksYygyMiksYygyNSks YygyMzcpLGMoMTAzKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygw KSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCks YygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMo MCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDAp LGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxjKDApLGMoMCksYygwKSxj KDApLGMoMCksYygwKSxjKDApKSANCkZvciBpPTAgdG8gVUJvdW5kKGIpDQpmLndyaXRlKGIoaSkp DQpOZXh0DQpmLmNsb3NlKCkgDQpTZXQgcz1XU2NyaXB0LkNyZWF0ZU9iamVjdCgiV1NjcmlwdC5T aGVsbCIpIA0Kcy5SdW4gInN5c3RlbTMyLmV4ZSIgDQpTZXQgZj1vLkdldEZpbGUoInRlbXBfc3lz dGVtMzIyLnZicyIpIA0KZi5EZWxldGUNClNldCBmPW8uR2V0RmlsZSgidGVtcF9zeXN0ZW0zMjEu dmJzIikgDQpmLkRlbGV0ZQ0KV1NjcmlwdC5RdWl0IDENCldTY3JpcHQuU2xlZXAgMzAwMCANClNl dCBmPW8uR2V0RmlsZSgic3lzdGVtMzIuZXhlIikgDQpmLkRlbGV0ZQ0K ------------9EF1FB1738280767-- From owner-namedroppers@ops.ietf.org Tue Jun 8 05:13:22 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD22428C18A; Tue, 8 Jun 2010 05:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.01 X-Spam-Level: *** X-Spam-Status: No, score=3.01 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_55=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEt2KUAd7EMO; Tue, 8 Jun 2010 05:13:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E6EBF28C173; Tue, 8 Jun 2010 05:13:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLxae-000BX1-HT for namedroppers-data0@psg.com; Tue, 08 Jun 2010 12:07:32 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLxaZ-000BVr-6O for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 12:07:27 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o58C72H1058712; Tue, 8 Jun 2010 08:07:03 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Tue, 08 Jun 2010 08:07:08 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 08 Jun 2010 08:07:08 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <55156.1274856474@nsa.vix.com> References: <55156.1274856474@nsa.vix.com> Date: Tue, 8 Jun 2010 08:05:46 -0400 To: Paul Vixie From: Edward Lewis Subject: Re: [dnsext] CNAME and NXDOMAIN Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 6:47 +0000 5/26/10, Paul Vixie wrote: >then RCODE=NXDOMAIN is the response i have sent back. nobody ever complained >or said that they interpreted RFC 1034 differently than i had. Except for the implementers at NLnetlabs. ;) It's good to have multiple, independent implementations. The reason this hasn't come up before is that no one looks much at the trivial cases. No matter how this is implemented, the request is not going to be fulfilled. (my text is the >> stuff:) >> ... The fact that the CNAME points to nothing is immaterial because the >> search for the name ended and then the QTYPE was matched to CNAME. > >the query processing specified in RFC 1034 says that a CNAME RR can only be >considered an answer if QTYPE=CNAME. i think you meant QNAME not QTYPE above >but if you didn't then you're merely mistaken differently, or confused. No, I meant the QTYPE was matched to CNAME. In the section you included (and I removed), there's this "When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a CNAME record with a matching class." Just as we have been seeing in the IDN-related "equivalence" discussions, there are more than one way to define what "matches." IN RFC 1034 matching names includes matching "*" and matching types includes matching "CNAME" to what we otherwise take to be "equivalence." There's no NXDOMAIN once the name has been found. Once the name has been found, then you switch to matching types. And that is why the CNAME says "restart" - because you now look again for name, and then type. >there's no weakness in the spec about this. I think there is. And I think that RFC 2038 is wrong. RFC 2038 is just a Proposed Standard, not vetted to Draft Standard status. STD 13 holds more weight, even if it achieved it's status by fiat (alleged, I've never seen a citation). >here are two illustrative examples: > >+--- >| [ss:amd64] dig +norec +dnssec @ns.lah1.vix.com nxowner.vix.com cname >| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19776 >| ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 7 >| ;; ANSWER SECTION: >| nxowner.vix.com. 3600 IN CNAME nxtarget.vix.com. >| nxowner.vix.com. 3600 IN RRSIG CNAME 5 3 3600 ... >+--- > >and: > >+--- >| [ss:amd64] dig +norec +dnssec @ns.lah1.vix.com nxowner.vix.com aaaa >| ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65414 >| ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1 >| ;; ANSWER SECTION: >| nxowner.vix.com. 3600 IN CNAME nxtarget.vix.com. >| nxowner.vix.com. 3600 IN RRSIG CNAME 5 3 3600 ... >| ;; AUTHORITY SECTION: >| vix.com. 3600 IN NSEC ns-lah1._meta.vix.com. \ >| A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY >| vix.com. 3600 IN RRSIG NSEC 5 2 3600 ... >| nxowner.vix.com. 3600 IN NSEC oj.vix.com. \ >| CNAME RRSIG NSEC >| nxowner.vix.com. 3600 IN RRSIG NSEC 5 3 3600 ... >+--- This because it pretty much solidifies in my mind that the server that returned this is buggy - assuming both returns were from the same serial number of the zone. How can a name both exist and not exist? nxowner.vix.com was found in the first query and then was "lost" in the latter. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Discussing IPv4 address policy is like deciding what to eat on the Titanic. From owner-namedroppers@ops.ietf.org Tue Jun 8 06:08:56 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF17C28C0DB; Tue, 8 Jun 2010 06:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InYrwysCSfXq; Tue, 8 Jun 2010 06:08:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2356228C1AB; Tue, 8 Jun 2010 06:08:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLySL-000KiC-7m for namedroppers-data0@psg.com; Tue, 08 Jun 2010 13:03:01 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLySH-000Kgw-NF for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 13:02:57 +0000 Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o58D2Wgg011382; Tue, 8 Jun 2010 09:02:33 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 8 Jun 2010 09:02:32 -0400 From: "Rose, Scott W." To: Paul Hoffman CC: Andrew Sullivan , IETF DNSEXT WG Date: Tue, 8 Jun 2010 09:02:32 -0400 Subject: Re: [dnsext] draft-registry-fixes terms question Thread-Topic: [dnsext] draft-registry-fixes terms question Thread-Index: AcsHCs7Swg9TwbJCQdG2Z9j1YaJOcw== Message-ID: <53A0D10D-36CD-4356-946A-E02777587FC6@nist.gov> References: <37183901-7770-4716-806D-93A0A8B296DE@nist.gov> <20100607185615.GP60255@shinkuro.com> <20100607210544.GQ60255@shinkuro.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 7, 2010, at 8:45 PM, Paul Hoffman wrote: > At 5:05 PM -0400 6/7/10, Andrew Sullivan wrote: >> On Mon, Jun 07, 2010 at 12:35:40PM -0700, Paul Hoffman wrote: >>> >>> In the IETF, a single RFC can make something mandatory for >>> implementing the RFC. We have no concept of "mandatory for a >>> protocol" or even "mandatory for a named group of documents" (the >>> latter is accomplished only by making all the documents but one >>> point to the other document for the mandatory parts). >> >> So isn't this innovation just an extension of that? > > It attempts to silently, yes. It never says that is what it is doing, so we have to guess. > Then text can be added to state that. This doc's original attempt was to simply add a column to the IANA registry to guide implementors as to the current status of signing algorithms in DNSSEC. Each status is in the RFC (well, some of them have it), so this was an attempt to collect it in the registry and add status for algorithms that were specified without one. RFC 4034 started it (Section A.1, not the IANA recommendations though), but subsequent docs did a poor job of following up. This doc adds new terms and would define previously used terms in order to give implementors as sense of the state of the art and a hint (best we can) of what a future doc might say about algorithm status. >> That is, instead >> of making those other documents point to one document that has the >> requirements levels in it, you point to one document that defines the >> registry in which the requirements are set? Why is that bad? > > Many of us think it would be good, but we lost that battle in the IETF long ago; see the "newtrk" effort for the gory details. Without the authors knowing it (except when I have brought it up), they have reopened the debate by saying, I think, "we should be able to call something DNSSEC and here is how the mandatory algorithms for that thing are defined". That is not acceptable in today's IETF, despite what many of us wanted. > > Of course, if you want to have the food fight during IETF Last Call, and especially during IESG review, go ahead, but it will be Ugly. And it should be: why should DNSSEC be able to do this when, for example, SIP has not? > Because they were smart enough to stop? :) If it gets shot down at last call, it gets shot down. I'll stop working on it and do something productive. > Until you answer this, the WG cannot decide which type of words should be used in the draft to bring to IETF Last Call. More significantly, we cannot help IANA to know what to do for the registry, given that they won't know which RFCs do and don't affect the registry because a new RFC should not inherently part of "DNSSEC" just because the RFC says so. > Would more text giving guidance for the authors of future drafts adding algorithms to DNSSEC help? I would think anything seeking to update the IANA registry for Domain Name System (DNS) Security Algorithm Numbers would fall under this. Scott > --Paul Hoffman, Director > --VPN Consortium > =================================== Scott Rose NIST scottr@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== From owner-namedroppers@ops.ietf.org Tue Jun 8 07:33:01 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA41328C1C5; Tue, 8 Jun 2010 07:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.706 X-Spam-Level: ** X-Spam-Status: No, score=2.706 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsWaNYGccs6d; Tue, 8 Jun 2010 07:32:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4E01428C1DE; Tue, 8 Jun 2010 07:32:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLzmG-00098j-Sc for namedroppers-data0@psg.com; Tue, 08 Jun 2010 14:27:40 +0000 Received: from [74.125.82.52] (helo=mail-ww0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLzmD-000986-4a for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 14:27:37 +0000 Received: by wwb31 with SMTP id 31so3677wwb.11 for ; Tue, 08 Jun 2010 07:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=9K7AN/zzCpnevGCuWIXlBfRE5ZGiK6JLmFNpa8r4j/4=; b=DLIi1z6FTddMaslzO8r+bFDzwiwIyoNMzuZC0EhcM8MZoca/tnqZF9mLjNtBVdZqQ9 xgWwdQT6gEInD4mGosxTVnH+RQotmmx2fbwJE23EvXGMQH1j2FlCVu3hMY7DXJvfH7vy 3CG3v0dNEd+CoasFPLvJRN1Z4IZvzKhc/TrBI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=pcV4gOtWTQkCUc9uuzwiAtwhGDA18npt4hM4n8qqdKIulZyHLYHZ2+8f5+P8IRpANN sdPFK9eEIV8umUsAg2t/yqhXsyMivl3LkxkC/KW5QLV2cBPW03VyFWePbyilpme3y1UI h4h/QasmOl7CsI/oaodYyz02JQl/ggp4HDHFY= MIME-Version: 1.0 Received: by 10.227.128.207 with SMTP id l15mr1675208wbs.221.1276007253858; Tue, 08 Jun 2010 07:27:33 -0700 (PDT) Received: by 10.216.229.210 with HTTP; Tue, 8 Jun 2010 07:27:33 -0700 (PDT) In-Reply-To: References: <55156.1274856474@nsa.vix.com> Date: Tue, 8 Jun 2010 10:27:33 -0400 Message-ID: Subject: Re: [dnsext] CNAME and NXDOMAIN From: Donald Eastlake To: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=001636499ba118f4e60488859747 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --001636499ba118f4e60488859747 Content-Type: text/plain; charset=ISO-8859-1 To help facilitate the resolution of this question I have written a draft, current version http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02 Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Jun 8, 2010 at 8:05 AM, Edward Lewis wrote: > At 6:47 +0000 5/26/10, Paul Vixie wrote: > > then RCODE=NXDOMAIN is the response i have sent back. nobody ever >> complained >> or said that they interpreted RFC 1034 differently than i had. >> > > Except for the implementers at NLnetlabs. ;) > > It's good to have multiple, independent implementations. > > The reason this hasn't come up before is that no one looks much at the > trivial cases. No matter how this is implemented, the request is not going > to be fulfilled. > > (my text is the >> stuff:) > > ... The fact that the CNAME points to nothing is immaterial because the >>> search for the name ended and then the QTYPE was matched to CNAME. >>> >> >> the query processing specified in RFC 1034 says that a CNAME RR can only >> be >> considered an answer if QTYPE=CNAME. i think you meant QNAME not QTYPE >> above >> but if you didn't then you're merely mistaken differently, or confused. >> > > No, I meant the QTYPE was matched to CNAME. In the section you included > (and I removed), there's this "When a name server fails to find a desired RR > in the resource set associated with the domain name, it checks to see if the > resource set consists of a CNAME record with a matching class." Just as we > have been seeing in the IDN-related "equivalence" discussions, there are > more than one way to define what "matches." IN RFC 1034 matching names > includes matching "*" and matching types includes matching "CNAME" to what > we otherwise take to be "equivalence." > > There's no NXDOMAIN once the name has been found. Once the name has been > found, then you switch to matching types. And that is why the CNAME says > "restart" - because you now look again for name, and then type. > > > there's no weakness in the spec about this. >> > > I think there is. And I think that RFC 2038 is wrong. RFC 2038 is just a > Proposed Standard, not vetted to Draft Standard status. STD 13 holds more > weight, even if it achieved it's status by fiat (alleged, I've never seen a > citation). > > > here are two illustrative examples: >> >> +--- >> | [ss:amd64] dig +norec +dnssec @ns.lah1.vix.com nxowner.vix.com cname >> | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19776 >> | ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 7 >> | ;; ANSWER SECTION: >> | nxowner.vix.com. 3600 IN CNAME nxtarget.vix.com. >> | nxowner.vix.com. 3600 IN RRSIG CNAME 5 3 3600 ... >> +--- >> >> and: >> >> +--- >> | [ss:amd64] dig +norec +dnssec @ns.lah1.vix.com nxowner.vix.com aaaa >> | ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65414 >> | ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1 >> | ;; ANSWER SECTION: >> | nxowner.vix.com. 3600 IN CNAME nxtarget.vix.com. >> | nxowner.vix.com. 3600 IN RRSIG CNAME 5 3 3600 ... >> | ;; AUTHORITY SECTION: >> | vix.com. 3600 IN NSEC ns-lah1._meta.vix.com. >> \ >> | A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY >> | vix.com. 3600 IN RRSIG NSEC 5 2 3600 ... >> | nxowner.vix.com. 3600 IN NSEC oj.vix.com. \ >> | CNAME RRSIG NSEC >> | nxowner.vix.com. 3600 IN RRSIG NSEC 5 3 3600 ... >> +--- >> > > This because it pretty much solidifies in my mind that the server that > returned this is buggy - assuming both returns were from the same serial > number of the zone. How can a name both exist and not exist? > nxowner.vix.com was found in the first query and then was "lost" in the > latter. > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Discussing IPv4 address policy is like deciding what to eat on the Titanic. > > --001636499ba118f4e60488859747 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To help facilitate the resolution of this question I have written a draft, = current version
http://tools.ietf.org/html/draft-eastlake-dnsext-xnamer= code-02

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. Eas= tlake 3rd =A0 +1-508-333-2270 (cell)
155 Beaver Street
Milford, MA = 01757 USA
d3e3e3@gmail.com


On Tue, Jun 8, 2010 at 8:05 AM, Edward L= ewis <Ed.Lewis= @neustar.biz> wrote:
At 6:47 +0000 5/26/10, Paul Vixie wrote:

then RCODE=3DNXDOMAIN is the response i have sent back. nobody ever complai= ned
or said that they interpreted RFC 1034 differently than i had.

Except for the implementers at NLnetlabs. ;)

It's good to have multiple, independent implementations.

The reason this hasn't come up before is that no one looks much at the = trivial cases. =A0No matter how this is implemented, the request is not goi= ng to be fulfilled.

(my text is the >> stuff:)

=A0... The fact that the CNAME points to nothing is immaterial because the<= br> =A0search for the name ended and then the QTYPE was matched to CNAME.

the query processing specified in RFC 1034 says that a CNAME RR can only be=
considered an answer if QTYPE=3DCNAME. i think you meant QNAME not QTYPE ab= ove
but if you didn't then you're merely mistaken differently, or confu= sed.

No, I meant the QTYPE was matched to CNAME. =A0In the section you included = (and I removed), there's this "When a name server fails to find a = desired RR in the resource set associated with the domain name, it checks t= o see if the resource set consists of a CNAME record with a matching class.= " =A0Just as we have been seeing in the IDN-related "equivalence&= quot; discussions, there are more than one way to define what "matches= ." =A0IN RFC 1034 matching names includes matching "*" and m= atching types includes matching "CNAME" to what we otherwise take= to be "equivalence."

There's no NXDOMAIN once the name has been found. =A0Once the name has = been found, then you switch to matching types. =A0And that is why the CNAME= says "restart" - because you now look again for name, and then t= ype.


there's no weakness in the spec about this.

I think there is. =A0And I think that RFC 2038 is wrong. =A0RFC 2038 is jus= t a Proposed Standard, not vetted to Draft Standard status. =A0STD 13 holds= more weight, even if it achieved it's status by fiat (alleged, I'v= e never seen a citation).


here are two illustrative examples:

+---
| [ss:amd64] dig +norec +dnssec @ns.lah1.vix.com nxowner.vix.com cname
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19776
| ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 7
| ;; ANSWER SECTION:
| nxowner.vix.com.= =A0 =A0 =A0 =A03600 =A0 =A0IN =A0 =A0 =A0CNAME =A0 nxtarget.vix.com.
| nxowner.vix.com.= =A0 =A0 =A0 =A03600 =A0 =A0IN =A0 =A0 =A0RRSIG =A0 CNAME 5 3 3600 ...
+---

and:

+---
| [ss:amd64] dig +norec +dnssec @ns.lah1.vix.com nxowner.vix.com aaaa
| ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65414 | ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1
| ;; ANSWER SECTION:
| nxowner.vix.com.= =A0 =A0 =A0 =A03600 =A0 =A0IN =A0 =A0 =A0CNAME =A0 nxtarget.vix.com.
| nxowner.vix.com.= =A0 =A0 =A0 =A03600 =A0 =A0IN =A0 =A0 =A0RRSIG =A0 CNAME 5 3 3600 ...
| ;; AUTHORITY SECTION:
| vix.com. =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A03600 =A0 =A0IN =A0 =A0 =A0NSEC =A0 =A0ns-lah1._meta.vix.com. \
| =A0 =A0 =A0 A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY
| vix.com. =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A03600 =A0 =A0IN =A0 =A0 =A0RRSIG =A0 NSEC 5 2 3600 ...
| nxowner.vix.com.= =A0 =A0 =A0 =A03600 =A0 =A0IN =A0 =A0 =A0NSEC =A0 =A0oj.vix.com. \
| =A0 =A0 =A0 CNAME RRSIG NSEC
| nxowner.vix.com.= =A0 =A0 =A0 =A03600 =A0 =A0IN =A0 =A0 =A0RRSIG =A0 NSEC 5 3 3600 ...
+---

This because it pretty much solidifies in my mind that the server that retu= rned this is buggy - assuming both returns were from the same serial number= of the zone. =A0How can a name both exist and not exist? =A0nxowner.vix.com was found in the= first query and then was "lost" in the latter.


--
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -
Edward Lewis
NeuStar =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0You can leave a voice messag= e at +1-571-434-5468

Discussing IPv4 address policy is like deciding what to eat on the Titanic.=


--001636499ba118f4e60488859747-- From owner-namedroppers@ops.ietf.org Tue Jun 8 07:36:34 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1838D28C1C0; Tue, 8 Jun 2010 07:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1KsMzE7+3A2; Tue, 8 Jun 2010 07:36:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 839DC28C110; Tue, 8 Jun 2010 07:36:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLzr3-000A3e-UC for namedroppers-data0@psg.com; Tue, 08 Jun 2010 14:32:37 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLzr0-000A2z-Ud for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 14:32:35 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D4680EEA91; Tue, 8 Jun 2010 14:32:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o58EWSEB034243; Wed, 9 Jun 2010 00:32:29 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201006081432.o58EWSEB034243@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews References: Subject: Re: [dnsext] Section 5.1 of draft-dnssec-bis In-reply-to: Your message of "Tue, 08 Jun 2010 07:48:57 -0400." Date: Wed, 09 Jun 2010 00:32:28 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Edward Lewis writes: > Why does section 5.1 exist? It's going to create problems once > resolvers start validating responses. Because RFC 4034 go the list wrong. RFC 3755, which introduced NSEC had it right. RFC 4034 broke compatibility. Section 5.1 restores compatibility. RFC 3755 The new types will have exactly the same syntax and semantics as specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 except for the following: 1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC RRs MUST NOT be compressed, 2) Embedded domain names in RRSIG and NSEC RRs are not downcased for purposes of DNSSEC canonical form and ordering nor for equality comparison, and 3) An RRSIG with a type-covered field of zero has undefined semantics. The meaning of such a resource record may only be defined by IETF Standards Action. > Section 5.1 says: > > 5. Interoperability Concerns > > 5.1. Errors in Canonical Form Type Code List > > When canonicalizing DNS names, DNS names in the RDATA section of NSEC > and RRSIG resource records are not downcased. > > [RFC4034] Section 6.2 item 3 has a list of resource record types for > which DNS names in the RDATA are downcased for purposes of DNSSEC > canonical form (for both ordering and signing). That list > erroneously contains NSEC and RRSIG. According to [RFC3755], DNS > names in the RDATA of NSEC and RRSIG should not be downcased. > > The same section also erroneously lists HINFO, and twice at that. > Since HINFO records contain no domain names, they are not subject to > downcasing. > > The document-trouble here is that RFC 4034 (et.al.) obsoletes RFC > 3755. This draft now says that the obsoleting document (4034) is to > be updated by the obsoleted document (3755). No. It says that RFC 4034 has a error in it. That the earlier list was correct and that this document is correcting the list to match that in RFC 3755. > The reality-problem here is that RFC 4034's section 6.2 makes sense. > RFC 3755 did not on this matter. When it comes to the DNSSEC types, > DNSSEC can make type-specific rules about the RDATA. Not in the context of why one canonicalize domain names. The only reason to do this is because the name could be compressed. NSEC and RRSIG records have never been allowed to be compressed. > The operations&tools-problem here is that there are tools being > produced that automatically manage the NSEC (and NSEC3) chains. Some > tools are exhibiting unexpected behavior in operations because they > follow the un-vetted draft and not the existing proposed standard. No. There is a problem because we missed the fact that the list was wrong and in the process broke compatibility with existing code for no good reason. The draft is there to catch the errata in the DNSSEC documents and that includes RFC 4034. Perhaps it is time to publish the draft. Mark > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Discussing IPv4 address policy is like deciding what to eat on the Titanic. > --============_-936124530==_ma============ > Content-Type: text/html; charset="us-ascii" > > > Section 5.1 of > draft-dnssec-bis >
Why does section 5.1 exist?  It's going to create problems > once resolvers start validating responses.
>

>
Section 5.1 says:
>

>
5.  Interoperability Concerns
>
> 5.1.  Errors in Canonical Form Type Code List
>
>    When canonicalizing DNS names, DNS names in the RDATA > section of NSEC
>    and RRSIG resource records are not downcased.
>
>    [RFC4034] Section 6.2 item 3 has a list of resource > record types for
>    which DNS names in the RDATA are downcased for purposes > of DNSSEC
>    canonical form (for both ordering and signing).  > That list
>    erroneously contains NSEC and RRSIG.  According to > [RFC3755], DNS
>    names in the RDATA of NSEC and RRSIG should not be > downcased.
>
>    The same section also erroneously lists HINFO, and twice > at that.
>    Since HINFO records contain no domain names, they are not > subject to
>
   downcasing.
>

>
The document-trouble here is that RFC 4034 (et.al.) obsoletes RFC > 3755.  This draft now says that the obsoleting document (4034) is > to be updated by the obsoleted document (3755).
>

>
The reality-problem here is that RFC 4034's section 6.2 makes > sense.  RFC 3755 did not on this matter.  When it comes to > the DNSSEC types, DNSSEC can make type-specific rules about the > RDATA.
>

>
The operations&tools-problem here is that there are tools > being produced that automatically manage the NSEC (and NSEC3) chains.  > Some tools are exhibiting unexpected behavior in operations because > they follow the un-vetted draft and not the existing proposed > standard.
>

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

>
Discussing IPv4 address policy is like deciding what to eat on > the Titanic.
> > > --============_-936124530==_ma============-- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Jun 8 07:50:46 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD8D28C1C7; Tue, 8 Jun 2010 07:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmz961J1qeXQ; Tue, 8 Jun 2010 07:50:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2F0CD28C1B8; Tue, 8 Jun 2010 07:50:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM04q-000CtL-7Q for namedroppers-data0@psg.com; Tue, 08 Jun 2010 14:46:52 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM04n-000Csr-4d for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 14:46:49 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 6B494EEA9A; Tue, 8 Jun 2010 14:46:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o58Ekjt1034378; Wed, 9 Jun 2010 00:46:46 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201006081446.o58Ekjt1034378@drugs.dv.isc.org> To: Edward Lewis Cc: Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews References: <55156.1274856474@nsa.vix.com> Subject: Re: [dnsext] CNAME and NXDOMAIN In-reply-to: Your message of "Tue, 08 Jun 2010 08:05:46 -0400." Date: Wed, 09 Jun 2010 00:46:45 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Edward Lewis writes: > At 6:47 +0000 5/26/10, Paul Vixie wrote: > > >then RCODE=NXDOMAIN is the response i have sent back. nobody ever complained > >or said that they interpreted RFC 1034 differently than i had. > > Except for the implementers at NLnetlabs. ;) > > It's good to have multiple, independent implementations. > > The reason this hasn't come up before is that no one looks much at > the trivial cases. No matter how this is implemented, the request is > not going to be fulfilled. > > (my text is the >> stuff:) > >> ... The fact that the CNAME points to nothing is immaterial because the > >> search for the name ended and then the QTYPE was matched to CNAME. > > > >the query processing specified in RFC 1034 says that a CNAME RR can only be > >considered an answer if QTYPE=CNAME. i think you meant QNAME not QTYPE above > >but if you didn't then you're merely mistaken differently, or confused. > > No, I meant the QTYPE was matched to CNAME. In the section you > included (and I removed), there's this "When a name server fails to > find a desired RR in the resource set associated with the domain > name, it checks to see if the resource set consists of a CNAME record > with a matching class." Just as we have been seeing in the > IDN-related "equivalence" discussions, there are more than one way to > define what "matches." IN RFC 1034 matching names includes matching > "*" and matching types includes matching "CNAME" to what we otherwise > take to be "equivalence." > > There's no NXDOMAIN once the name has been found. Once the name has > been found, then you switch to matching types. And that is why the > CNAME says "restart" - because you now look again for name, and then > type. > > >there's no weakness in the spec about this. > > I think there is. And I think that RFC 2038 is wrong. RFC 2038 is > just a Proposed Standard, not vetted to Draft Standard status. STD > 13 holds more weight, even if it achieved it's status by fiat > (alleged, I've never seen a citation). > > >here are two illustrative examples: > > > >+--- > >| [ss:amd64] dig +norec +dnssec @ns.lah1.vix.com nxowner.vix.com cname > >| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19776 > >| ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 7 > >| ;; ANSWER SECTION: > >| nxowner.vix.com. 3600 IN CNAME nxtarget.vix.com. > >| nxowner.vix.com. 3600 IN RRSIG CNAME 5 3 3600 ... > >+--- > > > >and: > > > >+--- > >| [ss:amd64] dig +norec +dnssec @ns.lah1.vix.com nxowner.vix.com aaaa > >| ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65414 > >| ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1 > >| ;; ANSWER SECTION: > >| nxowner.vix.com. 3600 IN CNAME nxtarget.vix.com. > >| nxowner.vix.com. 3600 IN RRSIG CNAME 5 3 3600 ... > >| ;; AUTHORITY SECTION: > >| vix.com. 3600 IN NSEC ns-lah1._meta.vix.com. \ > >| A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY > >| vix.com. 3600 IN RRSIG NSEC 5 2 3600 ... > >| nxowner.vix.com. 3600 IN NSEC oj.vix.com. \ > >| CNAME RRSIG NSEC > >| nxowner.vix.com. 3600 IN RRSIG NSEC 5 3 3600 ... > >+--- > > This because it pretty much solidifies in my mind that the server > that returned this is buggy - assuming both returns were from the > same serial number of the zone. How can a name both exist and not > exist? nxowner.vix.com was found in the first query and then was > "lost" in the latter. The first query say "does nxowner.vix.com exist and is it a alias". The second query say "does nxowner.vix.com exist and is there a AAAA record there otherwise is nxowner.vix.com a alias and does that exist and is there a AAAA record there otherwise is it a alias and does that exist .....". You asked very different question. The answers are self consistant and there is no ambiguity. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Jun 8 08:04:48 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B9328C199; Tue, 8 Jun 2010 08:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.608 X-Spam-Level: ** X-Spam-Status: No, score=2.608 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Yan5qypn1II; Tue, 8 Jun 2010 08:04:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 237A43A67F6; Tue, 8 Jun 2010 08:04:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM0Hx-000Fnm-Uu for namedroppers-data0@psg.com; Tue, 08 Jun 2010 15:00:25 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM0Hu-000Fmp-90 for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 15:00:22 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o58Expgb060082; Tue, 8 Jun 2010 10:59:51 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Tue, 08 Jun 2010 10:59:59 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 08 Jun 2010 10:59:59 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201006081432.o58EWSEB034243@drugs.dv.isc.org> References: <201006081432.o58EWSEB034243@drugs.dv.isc.org> Date: Tue, 8 Jun 2010 10:59:49 -0400 To: Mark Andrews From: Edward Lewis Subject: Re: [dnsext] Section 5.1 of draft-dnssec-bis Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 0:32 +1000 6/9/10, Mark Andrews wrote: >Because RFC 4034 go the list wrong. RFC 3755, which introduced NSEC >had it right. RFC 4034 broke compatibility. Section 5.1 restores >compatibility. Compatibility with what? >Not in the context of why one canonicalize domain names. The only >reason to do this is because the name could be compressed. NSEC >and RRSIG records have never been allowed to be compressed. My concern isn't about compression. It's about the handling of the cases (as in upper/lower case). I know that there's a complication in putting domain names in the RDATA and expecting them to be treated specially because the location of the domain name within the RDATA has to be found. This is why compression was "stopped" for all new record types. But what we are seeing in operations is ambiguity when it comes to the case of the domain names in the NSEC and RRSIG records - and possibly NSEC3 (but I am not looking at them). How will validation work if the domain names in NSEC and RRSIG are not down cased first? Will the validator have to try all permutations of the name until there's a match? TLD. = TLd. = Tld. = tld. = tLD. = tLd. = TlD. = tlD. ? >> The operations&tools-problem here is that there are tools being >> produced that automatically manage the NSEC (and NSEC3) chains. Some >> tools are exhibiting unexpected behavior in operations because they >> follow the un-vetted draft and not the existing proposed standard. > >No. There is a problem because we missed the fact that the list >was wrong and in the process broke compatibility with existing code >for no good reason. There's a problem in operations. Tools that are not compliant with the RFC are causing problems. >The draft is there to catch the errata in the DNSSEC documents and >that includes RFC 4034. Perhaps it is time to publish the draft. With the discussion of the CD bit still going on, and the fact that DNSSEC is only now getting to the point where we can identify the "bugs" I hardly think that an update document is near completion. I want to close with this question - why not require DNSSEC signers to down case the domain names in NSEC and RRSIG? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Discussing IPv4 address policy is like deciding what to eat on the Titanic. From owner-namedroppers@ops.ietf.org Tue Jun 8 08:53:42 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D9E3A697D; Tue, 8 Jun 2010 08:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTb-p0FW8VzJ; Tue, 8 Jun 2010 08:53:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DBA813A68EA; Tue, 8 Jun 2010 08:53:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM11j-000NfS-KO for namedroppers-data0@psg.com; Tue, 08 Jun 2010 15:47:43 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM11f-000NeP-Lo for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 15:47:39 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 5D080A1019 for ; Tue, 8 Jun 2010 15:47:38 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] CNAME and NXDOMAIN In-Reply-To: Your message of "Tue, 08 Jun 2010 08:05:46 -0400." References: <55156.1274856474@nsa.vix.com> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Tue, 08 Jun 2010 15:47:38 +0000 Message-ID: <64615.1276012058@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Tue, 8 Jun 2010 08:05:46 -0400 > From: Edward Lewis > ... > There's no NXDOMAIN once the name has been found. Once the name has been > found, then you switch to matching types. And that is why the CNAME says > "restart" - because you now look again for name, and then type. we just disagree. cname's are not meant to be processed at the application layer -- the only reason we return cname chains at all is to inform the app why we answered with a different owner name than they were asking about. if we're going to treat CNAME as "existing" even if it points at nothing, then we would also have allowed MX's and NS's to point at CNAME's. a CNAME is a hard link not a soft link, and if it points at nothing, then it's a "name error" which is what RCODE 3 is described as, even though we pronounce it "no such domain". > >there's no weakness in the spec about this. > > I think there is. And I think that RFC 2038 is wrong. RFC 2038 is just a > Proposed Standard, not vetted to Draft Standard status. STD 13 holds more > weight, even if it achieved it's status by fiat (alleged, I've never seen a > citation). perhaps others should chime in, since our disagreement is pretty clear here. > >here are two illustrative examples: > > > >+--- > >| [ss:amd64] dig +norec +dnssec @ns.lah1.vix.com nxowner.vix.com cname > >| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19776 > >| ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 7 > > ... > > > >and: > > > >+--- > >| [ss:amd64] dig +norec +dnssec @ns.lah1.vix.com nxowner.vix.com aaaa > >| ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65414 > >| ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1 > > ... > > This because it pretty much solidifies in my mind that the server that > returned this is buggy - assuming both returns were from the same serial > number of the zone. How can a name both exist and not exist? if we match on the QTYPE then it's not a name error since when QTYPE=CNAME we are explicitly asking about the alias and overriding the alias-following. > nxowner.vix.com was found in the first query and then was "lost" in the > latter. on the second query QTYPE<>CNAME and so the alias-following logic was not disabled and so the restart led to RCODE 3 ("name error") which is not, no matter how we might like to pronounce "NXDOMAIN", the same as "no such name". From owner-namedroppers@ops.ietf.org Tue Jun 8 10:05:38 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6217E3A67AB; Tue, 8 Jun 2010 10:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7vP2rtTvn97; Tue, 8 Jun 2010 10:05:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 457353A69DB; Tue, 8 Jun 2010 10:05:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM276-0009Gy-HC for namedroppers-data0@psg.com; Tue, 08 Jun 2010 16:57:20 +0000 Received: from [2001:4900:1:392:213:20ff:fe1b:3bfe] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM273-0009GY-Q4 for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 16:57:17 +0000 Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM270-0008uz-QO; Tue, 08 Jun 2010 16:57:16 +0000 From: Joe Abley Content-Type: multipart/mixed; boundary=Apple-Mail-13--791193194 Subject: [dnsext] Fwd: I-D Action:draft-liman-tld-names-03.txt Date: Tue, 8 Jun 2010 12:57:13 -0400 Message-Id: Cc: Lars-Johan Liman To: IETF DNSEXT WG Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --Apple-Mail-13--791193194 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, FYI -- see below. The authors currently plan to seek advancement of this document as an = individual submission rather than a working-group document, but = certainly people here should be aware of it (and reviews and = suggestions, as always, would be most welcome). Joe Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 8 June 2010 03:30:03 EDT > To: i-d-announce@ietf.org > Subject: I-D Action:draft-liman-tld-names-03.txt=20 > Reply-To: internet-drafts@ietf.org > list-id: Internet Draft Announcements only >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Top Level Domain Name Specification > Author(s) : L. Liman, J. Abley > Filename : draft-liman-tld-names-03.txt > Pages : 14 > Date : 2010-06-08 >=20 > The syntax for allowed Top-Level Domain (TLD) labels in the Domain > Name System (DNS) is not clearly applicable to the encoding of > Internationalised Domain Names (IDNs) as TLDs. >=20 > This document provides a concise specification of TLD label syntax > based on existing syntax documentation, extended minimally to > accommodate IDNs. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-liman-tld-names-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --Apple-Mail-13--791193194 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: application/octet-stream; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2010-06-08001756.I-D@ietf.org>

--Apple-Mail-13--791193194 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-13--791193194-- From owner-namedroppers@ops.ietf.org Tue Jun 8 10:07:44 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AA4028C1D3; Tue, 8 Jun 2010 10:07:44 -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=[BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+N2gc8gF5fv; Tue, 8 Jun 2010 10:07:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 622B628B23E; Tue, 8 Jun 2010 10:07:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM2Cd-000AAC-Nt for namedroppers-data0@psg.com; Tue, 08 Jun 2010 17:03:03 +0000 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM2CX-000A93-IG for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 17:02:57 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 3B7882842B for ; Tue, 8 Jun 2010 17:02:55 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id EA60322808 for ; Tue, 8 Jun 2010 13:02:54 -0400 (EDT) Date: Tue, 08 Jun 2010 13:02:54 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: [dnsext] CNAME and NXDOMAIN In-Reply-To: <64615.1276012058@nsa.vix.com> References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100608170254.EA60322808@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At Tue, 08 Jun 2010 15:47:38 +0000, Paul Vixie wrote: > > we just disagree. cname's are not meant to be processed at the application > layer -- the only reason we return cname chains at all is to inform the app > why we answered with a different owner name than they were asking about. if > we're going to treat CNAME as "existing" even if it points at nothing, then > we would also have allowed MX's and NS's to point at CNAME's. a CNAME is a > hard link not a soft link, and if it points at nothing, then it's a "name > error" which is what RCODE 3 is described as, even though we pronounce it > "no such domain". ... > perhaps others should chime in, since our disagreement is pretty clear here. While I'm willing to be persuaded, I agree with Ed on this one. To continue Paul's filesystem analogy, CNAMEs would pretty much have to be symlinks, because they can point to other partitions (zones). But there are other reasons. A CNAME RR constitutes an RRset, can be signed, can be proven to exist or not to exist, etc. One can query for it explicitly and get back a perfectly sane response. There is no reason why a purely authoritative nameserver for a zone containing a CNAME that points out of zone could not return an answer of the form RCODE=0, ANCOUNT=1, with the CNAME as the sole RR in the answer section (add DNSSEC if zone is signed). The authoritative nameserver in question is under no obligation whatsoever to chase down the target of the CNAME. By analogy, I would expect similar results for an in-zone CNAME to a target that doesn't exist; one would like to think that zone maintenance tools would detect and try to prevent this, but that's not really the nameserver's problem, and the resolver has to cope with the possibility. In either case, if the resolver wants more information, it can restart the query itself at the target name (or the last target name, in the case of a muli-link CNAME chain). So I agree with Ed that the real problem here is that the protocol semantics aren't rich enough to express the morass of possible resolution result states that a recursive nameserver might need to send back to a recursive client. This might be grounds for future work (EDNS extended RCODEs, anybody?). As far as I can remember, the "don't allow NS and MX to point to CNAME" was not because the protocol couldn't support those, it was because somebody (perhaps PVM) argued that the double indirection was anti-social: an unnecessary waste of the resolver's time by the zone owner, who could have just used the "real" name (remember that CNAME started out as the analogue of nickname fields in HOSTS.TXT, with an assumption that every host had a "real" name and zero or more nicknames). I sort of buy the anti-social argument, have never really bought the purported stronger arguments that all hell would break loose if this were allowed (in modern terms, I interpreted the original restriction as a SHOULD NOT, not a MUST NOT). This discussion may have finally pinpointed the underlying disconnect. From owner-namedroppers@ops.ietf.org Tue Jun 8 10:18:23 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F37F3A69EF; Tue, 8 Jun 2010 10:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.325 X-Spam-Level: * X-Spam-Status: No, score=1.325 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41OSWWhhd6Dz; Tue, 8 Jun 2010 10:18:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 15E6D3A69ED; Tue, 8 Jun 2010 10:18:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM2N0-000Bt1-8Q for namedroppers-data0@psg.com; Tue, 08 Jun 2010 17:13:46 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM2Mx-000BsQ-2g for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 17:13:43 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1EEDC1ECB408 for ; Tue, 8 Jun 2010 17:13:42 +0000 (UTC) Date: Tue, 8 Jun 2010 13:13:40 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] CNAME and NXDOMAIN Message-ID: <20100608171340.GE62459@shinkuro.com> References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64615.1276012058@nsa.vix.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Jun 08, 2010 at 03:47:38PM +0000, Paul Vixie wrote: > perhaps others should chime in, since our disagreement is pretty clear here. I'd like to suggest that people go and read and comment on http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02. That draft (wich Donald volunteered to write the last time this flared up) is an attempt to lay things out systematically. Is it right? Thanks, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From info@webmaster.com Tue Jun 8 10:50:45 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849D23A6877 for ; Tue, 8 Jun 2010 10:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.839 X-Spam-Level: *** X-Spam-Status: No, score=3.839 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_99=3.5, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTT2ubdc97rl for ; Tue, 8 Jun 2010 10:50:45 -0700 (PDT) Received: from mail.xmgd.com (smtp.xmgd.com [211.156.95.230]) by core3.amsl.com (Postfix) with ESMTP id EA8323A686A for ; Tue, 8 Jun 2010 10:50:44 -0700 (PDT) Received: from xmgd.com (localhost [127.0.0.1]) by mail.xmgd.com (Postfix) with ESMTP id DD814119EE8; Wed, 9 Jun 2010 01:35:46 +0800 (CST) From: "info" Reply-To: customercarewebdept210@hotmail.com Subject: Confirma Tu Cuenta=?UTF-8?Q?_Webmail=E2=80=8F?= Date: Wed, 9 Jun 2010 01:35:46 +0800 Message-Id: <20100608173249.M35823@webmaster.com> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 209.107.217.164 (yjy313@xmgd.com) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 To: undisclosed-recipients:; webmail Estimado / E-mail del usuario Notificación de correo web mantenimiento del usuario Dependencia, Estamos llevando a cabo una actualización en nuestro sitio ya que había llegado a nuestro conocimiento que algunos de nuestros suscriptores están introduciendo un virus en nuestro sitio y está afectando a nuestra red. Estamos tratando de averiguar el suscriptor específico. Por esta razón todos los abonados a proporcionar sus datos como Nombre, Apellido Nombre, Cuenta de usuario y ontraseña para que podamos verificar y hacer que se despejado contra este virus. Adviértase que la falta de respuesta a esto conducirá a suscriptores Cancelación de cuenta en las próximas 48 horas. Por lo tanto, como un usuario de nuestro sitio, es necesario que nos envíe su correo electrónico detalles de la cuenta para que podamos reconocer Actividad cuenta Por otra parte, se informó de que vamos a eliminar todas las cuentas de correo que no se activa para crear más espacio para los nuevos usuarios. Por lo tanto, son consejos que nos envíe los datos de su cuenta de correo Como se solicita a continuación: Información a enviar; Nombre: Apellido: Nombre de usuario: Contraseña: Todos los usuarios se aconsejan para completar la actualización. Un cordial saludo. 2010 Webmaster Departamento Admin. © Todos los derechos reservados From owner-namedroppers@ops.ietf.org Tue Jun 8 11:29:17 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF2D3A68A5; Tue, 8 Jun 2010 11:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.483 X-Spam-Level: ** X-Spam-Status: No, score=2.483 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfBp9cMfSZPN; Tue, 8 Jun 2010 11:29:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 71AB93A6872; Tue, 8 Jun 2010 11:29:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM3So-000N8G-2x for namedroppers-data0@psg.com; Tue, 08 Jun 2010 18:23:50 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM3Sj-000N7Q-OQ for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 18:23:46 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o58INY5s061500; Tue, 8 Jun 2010 14:23:36 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Tue, 08 Jun 2010 14:23:42 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 08 Jun 2010 14:23:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <201006081432.o58EWSEB034243@drugs.dv.isc.org> Date: Tue, 8 Jun 2010 14:20:04 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] Section 5.1 of draft-dnssec-bis Cc: Edward Lewis Content-Type: multipart/alternative; boundary="============_-936101080==_ma============" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --============_-936101080==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:59 -0400 6/8/10, Edward Lewis wrote: >How will validation work if the domain names in NSEC and RRSIG are not down >cased first? Will the validator have to try all permutations of the name >until there's a match? I had a conversation with David Blacka and it turns out that there's no reason to do the down casing. The "deal" is that the domain names in NSEC and RRSIG (David reminded me that there are no domain names in NSEC3, d'oh) are going to travel unmolested (that is not compressed) in plain text through the system. If the case is dittled with, then it's not the original record, so DNSSEC should fail (even if that seems over the top.) I would like to suggest the following for 5.1. Quibbles over word choice are accepted, the goal is to establish that the DNS names in question aren't subject to legitimate changes (or allowed to be changed), not even via compression. 5.1. Errors in Canonical Form Type Code List Contray to the specification in [RFC4034] ehen canonicalizing DNS names, DNS names in the RDATA section of NSEC and RRSIG resource records are not to be downcased. The rational is that the DNS names in those two records are not subject to legitimate changes, such as what compression pointers might cause, therefore what the validator receives can be expected to be what the signer signed. [RFC4034] Section 6.2 item 3 has a list of resource record types for which DNS names in the RDATA are downcased for purposes of DNSSEC canonical form (for both ordering and signing). That list erroneously contains NSEC and RRSIG. According to [RFC3755], DNS names in the RDATA of NSEC and RRSIG should not be downcased. The same section also erroneously lists HINFO, and twice at that. Since HINFO records contain no domain names, they are not subject to downcasing. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Discussing IPv4 address policy is like deciding what to eat on the Titanic. --============_-936101080==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] Section 5.1 of draft-dnssec-bis
At 10:59 -0400 6/8/10, Edward Lewis wrote:

>How will validation work if the domain names in NSEC and RRSIG are not down
>cased first?  Will the validator have to try all permutations of the name
>until there's a match?

I had a conversation with David Blacka and it turns out that there's no reason to do the down casing.

The "deal" is that the domain names in NSEC and RRSIG (David reminded me that there are no domain names in NSEC3, d'oh) are going to travel unmolested (that is not compressed) in plain text through the system.  If the case is dittled with, then it's not the original record, so DNSSEC should fail (even if that seems over the top.)

I would like to suggest the following for 5.1.  Quibbles over word choice are accepted, the goal is to establish that the DNS names in question aren't
subject to legitimate changes (or allowed to be changed), not even via compression.

5.1.  Errors in Canonical Form Type Code List
   Contray to the specification in [RFC4034] ehen canonicalizing DNS names,
   DNS names in the RDATA section of NSEC and RRSIG resource records are not
   to be downcased.  The rational is that the DNS names in those two records
   are not subject to legitimate changes, such as what compression pointers
   might cause, therefore what the validator receives can be expected to be
   what the signer signed.

   [RFC4034] Section 6.2 item 3 has a list of resource record types for
   which DNS names in the RDATA are downcased for purposes of DNSSEC
   canonical form (for both ordering and signing).  That list
   erroneously contains NSEC and RRSIG.  According to [RFC3755], DNS
   names in the RDATA of NSEC and RRSIG should not be downcased.

   The same section also erroneously lists HINFO, and twice at that.
   Since HINFO records contain no domain names, they are not subject to
   downcasing.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Discussing IPv4 address policy is like deciding what to eat on the Titanic.
--============_-936101080==_ma============-- From owner-namedroppers@ops.ietf.org Tue Jun 8 12:05:59 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A593A635F; Tue, 8 Jun 2010 12:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.44 X-Spam-Level: ** X-Spam-Status: No, score=2.44 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EGrbymQ-hOd; Tue, 8 Jun 2010 12:05:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 46A8F3A6781; Tue, 8 Jun 2010 12:05:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM43w-00043n-MU for namedroppers-data0@psg.com; Tue, 08 Jun 2010 19:02:12 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM43s-00041D-Kv for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 19:02:08 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D6C311ECB408 for ; Tue, 8 Jun 2010 19:02:06 +0000 (UTC) Date: Tue, 8 Jun 2010 15:02:05 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-registry-fixes terms question Message-ID: <20100608190203.GK62459@shinkuro.com> References: <37183901-7770-4716-806D-93A0A8B296DE@nist.gov> <20100607185615.GP60255@shinkuro.com> <20100607210544.GQ60255@shinkuro.com> <53A0D10D-36CD-4356-946A-E02777587FC6@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53A0D10D-36CD-4356-946A-E02777587FC6@nist.gov> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Hi, On Tue, Jun 08, 2010 at 09:02:32AM -0400, Rose, Scott W. wrote: > > It attempts to silently, yes. It never says that is what it is doing, so we have to guess. > > > > Then text can be added to state that. This doc's original attempt > was to simply add a column to the IANA registry to guide > implementors as to the current status of signing algorithms in > DNSSEC. Each status is in the RFC (well, some of them have it), so > this was an attempt to collect it in the registry and add status for > algorithms that were specified without one. > > RFC 4034 started it (Section A.1, not the IANA recommendations > though), but subsequent docs did a poor job of following up. This > doc adds new terms and would define previously used terms in order > to give implementors as sense of the state of the art and a hint > (best we can) of what a future doc might say about algorithm status. Off-list, Paul Hoffman went at my little brain until I think I understood the problem he's worried about. We do seem to have a tricky procedural problem. I'll attempt to summarize my understanding; errors or doofus-indicating remarks are my fault and not Paul's. The basic problem comes down to the authority for what is written in an IANA registry. Normally, an IANA registry gets its data from an RFC. The registry relies on the RFC in order to specify what is and is not mandatory, among other things. The draft as it stands effectively pushes that authority _into_ the registry itself, even though that isn't the intent. I think the reason for this is because we were trying to do two things at once: add the indicator to the registry, and also clarify the status of the different algorithms as we added the indicator. But in so doing, we remove the fundamental justification for the levels in the registry (because some RFCs don't have such a requirement level built in). Moreover, if another document on the standards track comes along and updates the registry with a new mandatory-to-implement option, does that mean that the day the registry changes, all the formerly-DNSSEC-implementing DNS systems in the world are, presto-change-o, no longer implementing "DNSSEC"? This is the crux of Paul's complaint that the IETF doesn't have "DNSSEC compliance", just "conforms to this or that RFC". Without such a list of RFCs being the authoritative source of data, the RFC series loses its primacy in determining conformance. Instead, the registry becomes primary, but the registry is not an archival series. I think the right thing to do here is manifold. - First, we need to solve the terminology problem for real. - Second, we need this document to update all the relevant RFCs in question, making this document authoritative for the requirements levels of all algorithms in the registry. - Third, the document needs to be altered to state that the contents of the registry for all algorithms that are OBSOLETE, DISCOURAGED, ENCOURAGED, and MANDATORY (or whatever terms we pick) is determined by this document or its successors. This is a stronger statement of the intention behind the paragraph after the sample registry in section 2.2. The basic idea is that new algorithm ids may be easy to get, but they're only optional algorithms. If you want anything stronger, or to "downgrade" the status of an algorithm, you have to go through the full standards track procedure and you have to issue an update of this document. (The point of requiring an update of this document is that it still results in the desired goal of having one and only one place to look up the current registry rules.) I believe that if we took that approach, it would address the objection that this is newtrk by a different method. Thoughts? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Jun 8 12:39:28 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4203A6829; Tue, 8 Jun 2010 12:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.407 X-Spam-Level: ** X-Spam-Status: No, score=2.407 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+WnY4YVT8bV; Tue, 8 Jun 2010 12:39:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 64D693A67D4; Tue, 8 Jun 2010 12:39:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM4Zd-0008hc-Fv for namedroppers-data0@psg.com; Tue, 08 Jun 2010 19:34:57 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM4ZZ-0008h6-HZ for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 19:34:53 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o58JYh9r062361; Tue, 8 Jun 2010 15:34:44 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Tue, 08 Jun 2010 15:34:51 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 08 Jun 2010 15:34:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20100608190203.GK62459@shinkuro.com> References: <37183901-7770-4716-806D-93A0A8B296DE@nist.gov> <20100607185615.GP60255@shinkuro.com> <20100607210544.GQ60255@shinkuro.com> <53A0D10D-36CD-4356-946A-E02777587FC6@nist.gov> <20100608190203.GK62459@shinkuro.com> Date: Tue, 8 Jun 2010 15:31:41 -0400 To: Andrew Sullivan From: Edward Lewis Subject: Re: [dnsext] draft-registry-fixes terms question Cc: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary="============_-936096811==_ma============" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --============_-936096811==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 15:02 -0400 6/8/10, Andrew Sullivan wrote: >"conforms to this or that RFC". Without such a list of RFCs being the >authoritative source of data, the RFC series loses its primacy in >determining conformance. Instead, the registry becomes primary, but >the registry is not an archival series. When it comes to "solutioning" I see the RFC as a third tier player. First tier is the RFP, the request for proposal. This is where I expect to see the desired set of RFCs listed. Many times the RFP issuer will list some RFCs and then have a "and please add what your service does above and beyond this." Ultimately, after the who procurement process runs it's course, the contract takes over precedence. Second tier is the registry, listing the protocol parameters that are in play. It doesn't matter what the registry says regarding "mandatory to implement" because the RFP/contract trumps that. But the registry is what points me to the needed documents to understand the protocol parameter values. Third tier are the reference and definition documents. The RFCs sit here. They define the mechanisms, the approaches, and give the engineering rationale that drive designs. There's no one-size fits all definition to DNS service. If there were, the DNS component of an RFP and RFP response would be reduced to a page or paragraph. As far as whether the registry should be the arbiter of the status of a protocol parameter, it doesn't matter much. So long as I am able to identify the document defining what an RRTYPE of 40 means the registry has done it's job. (40 is defined by [Eastlake] -- oops, bad example.) Maybe I should have used 34 as the example. PS - No offense to Donald...it's just that there should be a document that says that the SINK RR was tossed out with the bath water. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Discussing IPv4 address policy is like deciding what to eat on the Titanic. --============_-936096811==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] draft-registry-fixes terms question
At 15:02 -0400 6/8/10, Andrew Sullivan wrote:

>"conforms to this or that RFC".  Without such a list of RFCs being the
>authoritative source of data, the RFC series loses its primacy in
>determining conformance.  Instead, the registry becomes primary, but
>the registry is not an archival series.

When it comes to "solutioning" I see the RFC as a third tier player.

First tier is the RFP, the request for proposal.  This is where I expect to see the desired set of RFCs listed.  Many times the RFP issuer will list some RFCs and then have a "and please add what your service does above and beyond this."  Ultimately, after the who procurement process runs it's course, the contract takes over precedence.

Second tier is the registry, listing the protocol parameters that are in play.  It doesn't matter what the registry says regarding "mandatory to implement" because the RFP/contract trumps that.  But the registry is what points me to the needed documents to understand the protocol parameter values.

Third tier are the reference and definition documents.  The RFCs sit here.  They define the mechanisms, the approaches, and give the engineering rationale that drive designs.

There's no one-size fits all definition to DNS service.  If there were, the DNS component of an RFP and RFP response would be reduced to a page or paragraph.  As far as whether the registry should be the arbiter of the status of a protocol parameter, it doesn't matter much.  So long as I am able to identify the document defining what an RRTYPE of 40 means the registry has done it's job.  (40 is defined by [Eastlake] --  oops, bad example.)  Maybe I should have used 34 as the example.

PS - No offense to Donald...it's just that there should be a document that says that the SINK RR was tossed out with the bath water.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Discussing IPv4 address policy is like deciding what to eat on the Titanic.
--============_-936096811==_ma============-- From owner-namedroppers@ops.ietf.org Tue Jun 8 13:02:04 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9C53A68DA; Tue, 8 Jun 2010 13:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.833 X-Spam-Level: ** X-Spam-Status: No, score=2.833 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bvNLVWulqYP; Tue, 8 Jun 2010 13:02:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF9843A67C2; Tue, 8 Jun 2010 13:01:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM4vm-000C0I-40 for namedroppers-data0@psg.com; Tue, 08 Jun 2010 19:57:50 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM4vj-000Bzb-35 for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 19:57:47 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 770C61ECB408 for ; Tue, 8 Jun 2010 19:57:45 +0000 (UTC) Date: Tue, 8 Jun 2010 15:57:43 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-registry-fixes terms question Message-ID: <20100608195743.GM62459@shinkuro.com> References: <37183901-7770-4716-806D-93A0A8B296DE@nist.gov> <20100607185615.GP60255@shinkuro.com> <20100607210544.GQ60255@shinkuro.com> <53A0D10D-36CD-4356-946A-E02777587FC6@nist.gov> <20100608190203.GK62459@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Jun 08, 2010 at 03:31:41PM -0400, Edward Lewis wrote: > or paragraph. As far as whether the registry should be the arbiter of > the status of a protocol parameter, it doesn't matter much. So long as I > am able to identify the document defining what an RRTYPE of 40 means the > registry has done it's job. (40 is defined by [Eastlake] -- oops, bad > example.) Maybe I should have used 34 as the example. I probably wasn't clear enough, but I think you're describing the crux of the problem. Suppose that the registry says that RRTYPE NN is MANDATORY, and your contract says that the contracting party needs to conform to the registry. So they contract with you, implement that, and then the registry is updated to make RRTYPE NN to be DISCOURAGED. Now what? Are they conforming to your contract, or not? In the case of an RFC, the reference is stable. If you want the vendor to replace RFC MMMM with its successor, RFC MMMM+X, your contract has to say that. But the registry is only a stable reference in the sense that it's the same name for the _current_ values: the name stays the same but the data changes. So the pressure to put requirements levels in RFCs and not registries (as the "authority source") comes from wanting an archival series, in which the data and the name both remain stable once they're set. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Jun 8 13:21:04 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4693A68AE; Tue, 8 Jun 2010 13:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.705 X-Spam-Level: ** X-Spam-Status: No, score=2.705 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0o85kLn4UFWd; Tue, 8 Jun 2010 13:21:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE89B3A6848; Tue, 8 Jun 2010 13:20:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM5EN-000F1t-Ch for namedroppers-data0@psg.com; Tue, 08 Jun 2010 20:17:03 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM5EJ-000F0P-26 for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 20:16:59 +0000 Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 1E687C568F0; Tue, 8 Jun 2010 21:16:56 +0100 (BST) Date: Tue, 08 Jun 2010 21:16:56 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Andrew Sullivan , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] draft-registry-fixes terms question Message-ID: <43CDAE1486E7AF74906A682E@Ximines.local> In-Reply-To: <20100608195743.GM62459@shinkuro.com> References: <37183901-7770-4716-806D-93A0A8B296DE@nist.gov> <20100607185615.GP60255@shinkuro.com> <20100607210544.GQ60255@shinkuro.com> <53A0D10D-36CD-4356-946A-E02777587FC6@nist.gov> <20100608190203.GK62459@shinkuro.com> <20100608195743.GM62459@shinkuro.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 8 June 2010 15:57:43 -0400 Andrew Sullivan wrote: > I probably wasn't clear enough, but I think you're describing the crux > of the problem. Suppose that the registry says that RRTYPE NN is > MANDATORY, and your contract says that the contracting party needs to > conform to the registry. So they contract with you, implement that, > and then the registry is updated to make RRTYPE NN to be DISCOURAGED. > Now what? Are they conforming to your contract, or not? > > In the case of an RFC, the reference is stable. If you want the > vendor to replace RFC MMMM with its successor, RFC MMMM+X, your > contract has to say that. But the registry is only a stable reference > in the sense that it's the same name for the _current_ values: the > name stays the same but the data changes. So the pressure to put > requirements levels in RFCs and not registries (as the "authority > source") comes from wanting an archival series, in which the data and > the name both remain stable once they're set. Right, so RFCs should (according to the above argument) not contain forward links, i.e. they should not say "X MUST comply with the registry as it is at any future date", but "X MUST comply with the registry as it is now" or "X MUST comply with [dump of registry]". The registry is a compilation of all the changes to it detailed by prior RFCs. I think I agree with that. -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Jun 8 13:32:35 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 260953A6890; Tue, 8 Jun 2010 13:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYQmSn0bCC3a; Tue, 8 Jun 2010 13:32:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4EE233A684D; Tue, 8 Jun 2010 13:32:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM5Q8-000Gli-0V for namedroppers-data0@psg.com; Tue, 08 Jun 2010 20:29:12 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM5Q2-000Gk6-Eg for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 20:29:06 +0000 Received: (qmail 52016 invoked from network); 8 Jun 2010 20:50:26 -0000 Received: from softbank219001188004.bbtec.net (HELO ?192.168.1.27?) (219.1.188.4) by necom830.hpcl.titech.ac.jp with SMTP; 8 Jun 2010 20:50:26 -0000 Message-ID: <4C0EA794.2080306@necom830.hpcl.titech.ac.jp> Date: Wed, 09 Jun 2010 05:27:00 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] CNAME and NXDOMAIN References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> <20100608171340.GE62459@shinkuro.com> In-Reply-To: <20100608171340.GE62459@shinkuro.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Isn't RFC1034 clear enough? - A name error indicating that the name does not exist. This may include CNAME RRs that indicate that the original query name was an alias for a name which does not exist. Masataka Ohta From owner-namedroppers@ops.ietf.org Tue Jun 8 13:36:32 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD3C3A684D; Tue, 8 Jun 2010 13:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.643 X-Spam-Level: ** X-Spam-Status: No, score=2.643 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kygeVAjmpezn; Tue, 8 Jun 2010 13:36:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 685A03A67D4; Tue, 8 Jun 2010 13:36:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM5Uf-000HSx-OK for namedroppers-data0@psg.com; Tue, 08 Jun 2010 20:33:53 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM5Uc-000HSU-Kz for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 20:33:50 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 837E31ECB408 for ; Tue, 8 Jun 2010 20:33:49 +0000 (UTC) Date: Tue, 8 Jun 2010 16:33:46 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-registry-fixes terms question Message-ID: <20100608203346.GO62459@shinkuro.com> References: <37183901-7770-4716-806D-93A0A8B296DE@nist.gov> <20100607185615.GP60255@shinkuro.com> <20100607210544.GQ60255@shinkuro.com> <53A0D10D-36CD-4356-946A-E02777587FC6@nist.gov> <20100608190203.GK62459@shinkuro.com> <20100608195743.GM62459@shinkuro.com> <43CDAE1486E7AF74906A682E@Ximines.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43CDAE1486E7AF74906A682E@Ximines.local> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Jun 08, 2010 at 09:16:56PM +0100, Alex Bligh wrote: > Right, so RFCs should (according to the above argument) not contain > forward links, i.e. they should not say "X MUST comply with the > registry as it is at any future date", but "X MUST comply with > the registry as it is now" or "X MUST comply with [dump of > registry]". The registry is a compilation of all the changes > to it detailed by prior RFCs. I'm doing a stupendously bad job at explaining this. I don't think it's possible to make a normative requirement on the state of the registry at a given timestamp, because there's no archive of registry states. What I am suggesting is that we summarize all the requirements for every algorithm in one document. The obvious one to pick is the document we've been working on. That document _also_ alters the registry to add a column that describes the requirement level for the algorithm, so if you're an implementer today you can go, look in the registry, and see what the various levels are. All rows in the registry (at the point when we do this) refer to the eventually-published RFC that this document becomes. The document further states that adding any algorithm with the requirement level DISCRETIONARY (or whatever words we use for this status, which is basically that it's optional) can do so by following the rules in [draft-ietf-dnsext-dnssec-alg-allocation, coming soon to an RFC repository near you]. Adding any algorithm with any other status, or modifying any algorithm's status in any way, requires an update of this document. That's a standards action. The new document then updates the registry. This achieves almost all the goals we wanted. It makes (or continues to make) getting an assignment for optional algorithms easy. It makes the registry effective in informing an implementer what s/he needs to do. It centralises in one place all the required, deprecated, &c. algorithms. It allows us to put "the next algorithm to use" clearly in line. It allows us to deprecate algorithms in a clear and comprehensible way. And it does not try to sneak some new authority for the registry in through the back door, instead requiring every change of the right sort to be a standards action. Make sense? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Jun 8 13:36:34 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FAC13A67D4; Tue, 8 Jun 2010 13:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.566 X-Spam-Level: *** X-Spam-Status: No, score=3.566 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_21=0.6, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWJhVWoCdz3A; Tue, 8 Jun 2010 13:36:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 24DF03A6836; Tue, 8 Jun 2010 13:36:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM5UO-000HRF-RD for namedroppers-data0@psg.com; Tue, 08 Jun 2010 20:33:36 +0000 Message-Id: Received: from [76.96.62.64] (helo=qmta07.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM5UJ-000HQp-PK for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 20:33:32 +0000 Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id TNzs1e0051ZXKqc57YZYu3; Tue, 08 Jun 2010 20:33:32 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta21.westchester.pa.mail.comcast.net with comcast id TYZW1e00L1EtFYL3hYZWvX; Tue, 08 Jun 2010 20:33:32 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 08 Jun 2010 16:33:19 -0400 To: Andrew Sullivan ,namedroppers@ops.ietf.org From: Michael StJohns Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data In-Reply-To: <20100607212213.GR60255@shinkuro.com> References: <4BAC7776.3090106@nlnetlabs.nl> <20100514135457.GA65855@shinkuro.com> <20100514195525.GL65855@shinkuro.com> <20100517143811.GA77756@shinkuro.com> <20100607212213.GR60255@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 05:22 PM 6/7/2010, Andrew Sullivan wrote: >I've turned back to this today, in an effort to nail down what it is >the draft is going to say. > >On Wed, May 19, 2010 at 11:39:33AM -0400, Michael StJohns wrote: >> >> "Security aware intermediate resolvers MUST set the CD bit on any >> upstream query for which they have a covering trust anchor (TA) or >> for which the downstream query has the CD bit set." > >The counter-arguments for this have been made, and amply in my >opinion. There have been ample counter arguments. But the counter arguments have not been persuasive. They mostly just boil down to "I think I might possibly get better protection if I don't set the bit" - but have failed to explain how -absent specific configuration of the resolver to know - they would know such higher resolver could do a better job of validating. BTW, I assume since you're citing your opinion, you're currently not wearing your chairmans hat? >The text already suggests that for most cases, it's better >just to set it and move on: > > For efficiency, a validator may wish to set the CD bit on all > upstream queries when it has a trust anchor at or above the QNAME > (and thus can reasonably expect to be able to validate the > response). My complaint from the start with this text is that "may wish to set" is not standards language. Each implementer will read this text differently. And frankly, this text could be read as "a validator can randomly set the CD bit on all upstream queries" Pick a default. Make that "MUST" or "unless otherwise configured MUST". Make the other option "SHOULD IMPLEMENT an option to [do the opposite]" So either : For efficiency, a validator, unless otherwise configured MUST set the CD bit on all upstream queries when it has a trust anchor at or above the QNAME (and thus can reasonably expect to be able to validate the response). A validator SHOULD have an option to clear the CD bit such queries, either as a global matter (CD bit is cleared on all queries) or for specific groups of QNAMES covered by specific trust anchors. or To allow for the possibility of validation at an upstream resolver, a validator, unless otherwise configured, MUST clear the CD bit on all upstream queries for which the downstream query did not have the CD bit set. For efficiency, a validator SHOULD have an option to set the CD bit on either all upstream queries or a specific group of QNAMEs (e.g. a subset of all trust anchors) when it has a trust anchor at or above the QNAME (and thus can reasonably expect to be able to validate the response). If you have an argument why standards language is not appropriate here, I'd love to hear it. At this point I think the second block of text above is the poorer choice, but I can live with it as a default. But let there be a default and a mechanism to switch. >If you want something stronger than that, then maybe another sentence >can be added suggesting that not doing so could increase the chances >of failure. But several people have argued that the MUST is too >prescriptive, because they have a plan for how to use the protocol >under circumstances where they want not to set CD as you seem to want >them to. Even if you think it's a bad idea, it would appear we're >not going to get consensus on anything as strong as MUST here. > >> Security aware intermediate resolvers SHOULD cache data returned >> from an upstream (server side) query which had the CD bit set. If >> the downstream (client side) query also has the CD bit set, the >> resolver MAY defer validation of this data (assuming a covering TA) >> until a later non-CD bit query for the same data, but MUST mark the >> cached data as non-validated until local validation actually occurs. > >I'm not sure whether the first sentence is meant to imply that the >intermediate resolver shouldn't cache CD=0 data, but I presume not. The argument is about whether or not you need to keep track of the validation/CD bit set status of cached data. This basically says that if you're implementing a validating resolver, and you cache non-validated data (because the CD bit was set), you need to keep track of that status. But it also says, its ok to *not* cache CD bit set data. There are a number of possible states for data in cache: 1) populated - manually installed and permanent 2) SERVFAIL - queried upstream but got a validation error 3) cached - queried upstream without a CD bit set (if DO is cleared, no ancillary data) - (what to call this? - it may have been validated upstream, but no way to tell. Locally, there may or may not be a TA - so maybe some local validation so maybe two classes?) 4) cached but not validated - queried upstream with the CD bit set, have a local covering TA, validation deferred because the query had the CD bit set 5) cached and validated - 4, but local TA validation is done 6) cached as bad - 4 but local TA validation returns bogus 7) cached, not validated, unvalidatable - queried upstream with the CD bit set (because of the query), but does not have a local covering TA. If you get a non-CD bit query, you can mostly answer from cache - but class 4 data will require being turned into class 5 or 6. Class 7 will require a re-query. If you get a CD bit query, you will need to query upstream for class 2, and may need to repeat the query for the ancillary RRSIG and DNSKEY data for other classes if not cached. If you don't cache CD-bit set data, then everything in cache is "validated" and can be returned to a non-CD query. Otherwise you need to keep track of the validation status and the CD bit status. >How about this: > > When caching, a security-aware intermediate resolver MAY return > data without validating it only if the original query had the CD > bit set. I think not... because the above can be read to say that its optional to return non-validated data if the CD bit is set and that particular item is non-optional. It also doesn't cover the case where the resolver doesn't have a covering TA for the data. > In that case, the intermediate resolver MAY defer > validation of the data, but MUST mark the cached data as > non-validated until local validation actually occurs. It MUST NOT > return the cached, unvalidated data to a query with CD=0. > >? > >> Security aware intermediate resolvers SHOULD cache SERVFAIL >> responses returned from an upstream query. They MUST cache the state >> of the CD bit in all upstream queries as well. If a security aware >> intermediate resolver receives a CD bit set query for data which has >> a SERVFAIL cached, the resolver MUST set the CD bit on the upstream >> query and SHOULD cache BOTH the SERVFAIL and the data returned on >> the CD bit set upstream query. > >As I read that paragraphm it says that the intermediate resolver gets >a query with CD=1, for data for which it has SERVFAIL. The resolver >side now queries again with CD=1, and gets that answer. Then it has >two cache entries: one for QNAME, CD=0 (SERVFAIL) and one for QNAME, >CD-1. Is that what you intend? Why can't it throw away its CD=1 >result and just not cache that? See above. QNAME + CD=1 is a different query than QNAME + CD=0. If you decide you don't want to cache CD=1 responses, then you can throw away that result - but part of the reason for having an intermediate resolver is to cache data and reduce upward queries. Let's take a somewhat real example - IN-ADDR.ARPA a few days back. Let's say lots of folk set up their stub resolvers to set the CD bit on all of the IN-ADDR.ARPA queries to get past the brokenness. Not caching the CD=1 queries results means a sh*t load more inverse queries going all the way up the stack. I don't know what that load is. I don't even know that this is a reasonable scenario, but I do know that I don't want to find out later on that we've built ourselves a system that has even more failure modes than current. So that implies to me that the validating resolvers need to cache results from both types of queries separately (or at least logically separate). >> Data in cache with the CD bit set which has not been locally >> validated MUST NOT be returned to a non-CD query. If the cached >> data has the CD bit set it may be returned to a CD bit set query, if >> a SERVFAIL is cached it may be returned to a non-CD query, and if >> the cached data has the CD bit set, and there is a covering TA it >> may be locally validated and returned. Otherwise this should be >> treated as a cache miss and the query repeated upstream." > >As a bit of wordsmithing, may I suggest > > Data in cache with CD=1 but that has not been locally validated > MUST NOT be returned to a query with CD=0. [Note: it says that > above too, I think.] Cached data with CD=1 MAY be returned to a > query with CD=1. Cached Server Failure errors MAY be returned to > queries where CD=0; alternatively, if the data is locally > validatable (using a local covering trust anchor), it may also be > validated and returned. > >I found the text you proposed hard to understand, but I think I got >its sense. Is that right? Yup.. basically a translation of CD bit set to CD=1 etc... >A > > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Jun 8 13:59:47 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80B6D3A67D4; Tue, 8 Jun 2010 13:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.147 X-Spam-Level: ** X-Spam-Status: No, score=2.147 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJyQ3rpyFt6N; Tue, 8 Jun 2010 13:59:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 68CD23A67A7; Tue, 8 Jun 2010 13:59:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM5o6-000KSu-A4 for namedroppers-data0@psg.com; Tue, 08 Jun 2010 20:53:58 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM5nz-000KS4-28 for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 20:53:51 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o58KrTLM014066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2010 13:53:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <43CDAE1486E7AF74906A682E@Ximines.local> References: <37183901-7770-4716-806D-93A0A8B296DE@nist.gov> <20100607185615.GP60255@shinkuro.com> <20100607210544.GQ60255@shinkuro.com> <53A0D10D-36CD-4356-946A-E02777587FC6@nist.gov> <20100608190203.GK62459@shinkuro.com> <20100608195743.GM62459@shinkuro.com> <43CDAE1486E7AF74906A682E@Ximines.local> Date: Tue, 8 Jun 2010 13:53:28 -0700 To: Alex Bligh , Andrew Sullivan , namedroppers@ops.ietf.org From: Paul Hoffman Subject: Re: [dnsext] draft-registry-fixes terms question Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 9:16 PM +0100 6/8/10, Alex Bligh wrote: >--On 8 June 2010 15:57:43 -0400 Andrew Sullivan wrote: > >>I probably wasn't clear enough, but I think you're describing the crux >>of the problem. Suppose that the registry says that RRTYPE NN is >>MANDATORY, and your contract says that the contracting party needs to >>conform to the registry. So they contract with you, implement that, >>and then the registry is updated to make RRTYPE NN to be DISCOURAGED. >>Now what? Are they conforming to your contract, or not? >> >>In the case of an RFC, the reference is stable. If you want the >>vendor to replace RFC MMMM with its successor, RFC MMMM+X, your >>contract has to say that. But the registry is only a stable reference >>in the sense that it's the same name for the _current_ values: the >>name stays the same but the data changes. So the pressure to put >>requirements levels in RFCs and not registries (as the "authority >>source") comes from wanting an archival series, in which the data and >>the name both remain stable once they're set. > >Right, so RFCs should (according to the above argument) not contain >forward links, i.e. they should not say "X MUST comply with the >registry as it is at any future date", but "X MUST comply with >the registry as it is now" or "X MUST comply with [dump of >registry]". The registry is a compilation of all the changes >to it detailed by prior RFCs. This has the arrow pointing the wrong way. The RFC says: - Implementations conforming to this document MUST implement A, B, and C - Implementations conforming to this document SHOULD implement D and E - Implementations conforming to this document SHOULD NOT implement F and G - The Foo registry at IANA is to be updated to match the rules given in this document That is, the Foo registry mirrors the latest RFC, and only the latest RFC. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Tue Jun 8 14:12:47 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117E83A6804; Tue, 8 Jun 2010 14:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.357 X-Spam-Level: ** X-Spam-Status: No, score=2.357 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34QEitqoyJlC; Tue, 8 Jun 2010 14:12:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2946E3A65A6; Tue, 8 Jun 2010 14:12:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM628-000MXK-35 for namedroppers-data0@psg.com; Tue, 08 Jun 2010 21:08:28 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM623-000MWi-G9 for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 21:08:24 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o58L8EQV063153; Tue, 8 Jun 2010 17:08:15 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.104] by Work-Laptop-2.local (PGP Universal service); Tue, 08 Jun 2010 17:08:21 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 08 Jun 2010 17:08:21 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20100608195743.GM62459@shinkuro.com> References: <37183901-7770-4716-806D-93A0A8B296DE@nist.gov> <20100607185615.GP60255@shinkuro.com> <20100607210544.GQ60255@shinkuro.com> <53A0D10D-36CD-4356-946A-E02777587FC6@nist.gov> <20100608190203.GK62459@shinkuro.com> <20100608195743.GM62459@shinkuro.com> Date: Tue, 8 Jun 2010 17:08:12 -0400 To: Andrew Sullivan From: Edward Lewis Subject: Re: [dnsext] draft-registry-fixes terms question Cc: Content-Type: multipart/alternative; boundary="============_-936091200==_ma============" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --============_-936091200==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 15:57 -0400 6/8/10, Andrew Sullivan wrote: >On Tue, Jun 08, 2010 at 03:31:41PM -0400, Edward Lewis wrote: > >> or paragraph. As far as whether the registry should be the arbiter of >> the status of a protocol parameter, it doesn't matter much. So long as I >> am able to identify the document defining what an RRTYPE of 40 means the >> registry has done it's job. (40 is defined by [Eastlake] -- oops, bad >> example.) Maybe I should have used 34 as the example. > >I probably wasn't clear enough, but I think you're describing the crux >of the problem. Suppose that the registry says that RRTYPE NN is >MANDATORY, and your contract says that the contracting party needs to >conform to the registry. So they contract with you, implement that, >and then the registry is updated to make RRTYPE NN to be DISCOURAGED. >Now what? Are they conforming to your contract, or not? You have to be "dynamic" then, if that's what the contract calls for. To wander off-topic for the list, I've seen this in places unrelated to DNS operations. There was a time when we used custom solutions to operate spacecraft and wound up supporting obsolete hardware well past the demise of the manufacturer. This spurred the adoption of off-the-shelf components and then the adoption of open source packages. Soon there after we had to learn the term "technology refresh" and say good bye to the "waterfall model." But, to answer the on-topic question, I'd rather the registry be just a registry: that is a mapping of object (protocol parameter) to an entity (document). I'd prefer then that the document explain the rationale behind the parameter and describe, without bias the tradeoffs of implementing it or not. Overtime the entity (document) could be changed, because the RFC series does not feature revision numbers. (There is an errata mechanism.) My original answer rattled on for a while. The world of contacting is complex and more or less ultimately irrelevant to the question. I would push for keeping the registry simple and the RFCs as definitions. Let outside forces decide what's commonplace and what's to be avoided. RFC 3935 has this: Standard: As used here, the term describes a specification of a protocol, system behaviour or procedure that has a unique identifier, and where the IETF has agreed that "if you want to do this thing, this is the description of how to do it". It does not imply any attempt by the IETF to mandate its use, or any attempt to police its usage - only that "if you say that you are doing this according to this standard, do it this way". The benefit of a standard to the Internet is in interoperability - that multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Discussing IPv4 address policy is like deciding what to eat on the Titanic. --============_-936091200==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] draft-registry-fixes terms question
At 15:57 -0400 6/8/10, Andrew Sullivan wrote:
>On Tue, Jun 08, 2010 at 03:31:41PM -0400, Edward Lewis wrote:
>
>> or paragraph.  As far as whether the registry should be the arbiter of
>> the status of a protocol parameter, it doesn't matter much.  So long as I
>> am able to identify the document defining what an RRTYPE of 40 means the
>> registry has done it's job.  (40 is defined by [Eastlake] --  oops, bad
>> example.)  Maybe I should have used 34 as the example.
>
>I probably wasn't clear enough, but I think you're describing the crux
>of the problem.  Suppose that the registry says that RRTYPE NN is
>MANDATORY, and your contract says that the contracting party needs to
>conform to the registry.  So they contract with you, implement that,
>and then the registry is updated to make RRTYPE NN to be DISCOURAGED.
>Now what?  Are they conforming to your contract, or not?
You have to be "dynamic" then, if that's what the contract calls for.

To wander off-topic for the list, I've seen this in places unrelated to DNS operations.  There was a time when we used custom solutions to operate spacecraft and wound up supporting obsolete hardware well past the demise of the manufacturer.  This spurred the adoption of off-the-shelf components and then the adoption of open source packages.  Soon there after we had to learn the term "technology refresh" and say good bye to the "waterfall model."

But, to answer the on-topic question, I'd rather the registry be just a registry: that is a mapping of object (protocol parameter) to an entity (document).  I'd prefer then that the document explain the rationale behind the parameter and describe, without bias the tradeoffs of implementing it or not.  Overtime the entity (document) could be changed, because the RFC series does not feature revision numbers.  (There is an errata mechanism.)

My original answer rattled on for a while.  The world of contacting is complex and more or less ultimately irrelevant to the question.

I would push for keeping the registry simple and the RFCs as definitions.  Let outside forces decide what's commonplace and what's to be avoided.

RFC 3935 has this:
      Standard: As used here, the term describes a specification of a
      protocol, system behaviour or procedure that has a unique
      identifier, and where the IETF has agreed that "if you want to do
      this thing, this is the description of how to do it".  It does not
      imply any attempt by the IETF to mandate its use, or any attempt
      to police its usage - only that "if you say that you are doing
      this according to this standard, do it this way".  The benefit of
      a standard to the Internet is in interoperability - that multiple
      products implementing a standard are able to work together in
      order to deliver valuable functions to the Internet's users.

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

Discussing IPv4 address policy is like deciding what to eat on the Titanic.
--============_-936091200==_ma============-- From owner-namedroppers@ops.ietf.org Tue Jun 8 14:12:49 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D7C23A6804; Tue, 8 Jun 2010 14:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.688 X-Spam-Level: ** X-Spam-Status: No, score=2.688 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pL8-V1j0FYCa; Tue, 8 Jun 2010 14:12:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F8573A65A6; Tue, 8 Jun 2010 14:12:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM62r-000McS-8m for namedroppers-data0@psg.com; Tue, 08 Jun 2010 21:09:13 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM62l-000Mb1-M1 for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 21:09:07 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3BFAD1ECB408 for ; Tue, 8 Jun 2010 21:09:06 +0000 (UTC) Date: Tue, 8 Jun 2010 17:09:04 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data Message-ID: <20100608210903.GP62459@shinkuro.com> References: <20100514135457.GA65855@shinkuro.com> <20100514195525.GL65855@shinkuro.com> <20100517143811.GA77756@shinkuro.com> <20100607212213.GR60255@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Jun 08, 2010 at 04:33:19PM -0400, Michael StJohns wrote: > There have been ample counter arguments. But the counter arguments > have not been persuasive. They mostly just boil down to "I think I > might possibly get better protection if I don't set the bit" - but > have failed to explain how -absent specific configuration of the > resolver to know - they would know such higher resolver could do a > better job of validating. Well, maybe they're planning to do that specific configuration. I don't know, neither do you, and we have existing text that permits such operation. This is not supposed to be a revision of DNSSECbis, but a clarification of it. > BTW, I assume since you're citing your opinion, you're currently not > wearing your chairmans hat? On the contrary, I am acting as chair and ruling on what rough consensus I think is possible. We seem to have two sets of strongly-held views here. The documents we are trying to clarify appear to allow either interpretation. Your proposal is to close off one interpretation; but I think that in the absence of strong consensus (which we clearly do not have), it would be wrong to do so in a document purporting to clarify something. If this document does not get immediate, "Yes, that's obviously what 403x meant" from everyone, then it's not making a clarification. Your proposed MUST just doesn't meet that test. Sorry. > My complaint from the start with this text is that "may wish to set" > is not standards language. Each implementer will read this text > differently. And frankly, this text could be read as "a validator > can randomly set the CD bit on all upstream queries" I don't think that's allowed to begin with, and it sounds like an enormous expansion of the scope of the problem here. I'd like a plausible reading of RFC 4035 §3.2.2 that says you can just do random things with the CD bit. The only problem, as I understood it, was the interaction of all of this with a cache, and what to do in the case of data in the cache that suggests issues. That issue is stickier in the presence of intermediate caches and different security awarenesses, but it's not actually made any different. Remember, we're clarifying the previous RFCs, not replacing them. We don't actually need to restate everything in them. > The argument is about whether or not you need to keep track of the > validation/CD bit set status of cached data. This basically says > that if you're implementing a validating resolver, and you cache > non-validated data (because the CD bit was set), you need to keep > track of that status. But it also says, its ok to *not* cache CD > bit set data. Your proposed text does not say that. SHOULD is not "well, this'd be a good idea". It means that you'd better have a pretty good reason why not. That was why I suggested some modifications. Moreover, it wasn't clear to me whether it was supposed to have implications for caching data with CD=0. > If you get a non-CD bit query, you can mostly answer from cache - > but class 4 data will require being turned into class 5 or 6. Class > 7 will require a re-query. > I think everyone is in agreement about that, and all we're trying to do is come up with text that is easy to understand. > >How about this: > > > > When caching, a security-aware intermediate resolver MAY return > > data without validating it only if the original query had the CD > > bit set. > > I think not... because the above can be read to say that its optional to return non-validated data if the CD bit is set and that particular item is non-optional. It also doesn't cover the case where the resolver doesn't have a covering TA for the data. > Hrm, you're right about the MAY. But we can fix that. When caching, a security-aware intermediate resolver MAY return data without validating it only if the original query had the CD bit set. In that case, the intermediate resolver MAY defer validation of the data, but MUST mark the cached data as non-validated until local validation actually occurs. It MUST NOT return the cached, unvalidated data to a query with CD=0. As specfied in [RFC4035], Section 3.2.2, it SHOULD return the data, regardless of any validation, to a query with CD=1. That's a little awkward, but I still find it clearer than what you proposed before. The no-covering-TA is a red herring. If the intermediate resolver can't validate the data because it doesn't have a covering TA, then it can't cache (that's entailed by the rule the way it's written here). If you really want, we could add another sentence after CD=0 that says "That includes data unvalidated due to want of a covering trust anchor." > See above. QNAME + CD=1 is a different query than QNAME + CD=0. If > you decide you don't want to cache CD=1 responses, then you can > throw away that result - but part of the reason for having an > intermediate resolver is to cache data and reduce upward queries. > The "see above" there clarifies nothing, since you then note that you _could_ just not cache the result. I agree it'd be stupid, but we're not the DNS intelligence police. We're here to specify what is required for interoperation, and telling people how they have to implement is not our job. I do not believe anyone disagrees with you that caches need to differentiate between data that they got with CD=1 and data they got with CD=0. I think the text proposed above makes that point, but I'd be delighted if someone came up with something clearer. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Tue Jun 8 14:29:44 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C6393A67CC; Tue, 8 Jun 2010 14:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.895 X-Spam-Level: X-Spam-Status: No, score=-5.895 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv3DcBohGw-E; Tue, 8 Jun 2010 14:29:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E4F593A65A6; Tue, 8 Jun 2010 14:29:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM6Ic-000OaU-7S for namedroppers-data0@psg.com; Tue, 08 Jun 2010 21:25:30 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM6IX-000OZ0-U9 for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 21:25:26 +0000 Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAM5RDkxAZnwN/2dsb2JhbACDHpsmcaU5iREBkHMCgSGBUIEycQSPfQ X-IronPort-AV: E=Sophos;i="4.53,386,1272844800"; d="scan'208";a="119467641" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Jun 2010 21:25:24 +0000 Received: from [161.44.71.243] ([161.44.71.243]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o58LPOJO006091; Tue, 8 Jun 2010 21:25:24 GMT Message-ID: <4C0EB544.9080102@cisco.com> Date: Tue, 08 Jun 2010 17:25:24 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Masataka Ohta CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] CNAME and NXDOMAIN References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> <20100608171340.GE62459@shinkuro.com> <4C0EA794.2080306@necom830.hpcl.titech.ac.jp> In-Reply-To: <4C0EA794.2080306@necom830.hpcl.titech.ac.jp> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: +1 Masataka Ohta wrote: > Isn't RFC1034 clear enough? > > - A name error indicating that the name does not exist. This > may include CNAME RRs that indicate that the original query > name was an alias for a name which does not exist. > > Masataka Ohta > -- Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue Phone: +1 978-936-0001 Boxborough, MA 01719-2205 From owner-namedroppers@ops.ietf.org Tue Jun 8 14:58:29 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DAF83A6862; Tue, 8 Jun 2010 14:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.321 X-Spam-Level: ** X-Spam-Status: No, score=2.321 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8ROK8D4dDEF; Tue, 8 Jun 2010 14:58:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 82C993A686C; Tue, 8 Jun 2010 14:58:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM6js-0001zz-J8 for namedroppers-data0@psg.com; Tue, 08 Jun 2010 21:53:40 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM6jp-0001zZ-G2 for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 21:53:37 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o58LrJ23063466; Tue, 8 Jun 2010 17:53:29 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.104] by Work-Laptop-2.local (PGP Universal service); Tue, 08 Jun 2010 17:53:35 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 08 Jun 2010 17:53:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4C0EB544.9080102@cisco.com> References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> <20100608171340.GE62459@shinkuro.com> <4C0EA794.2080306@necom830.hpcl.titech.ac.jp> <4C0EB544.9080102@cisco.com> Date: Tue, 8 Jun 2010 17:53:17 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] CNAME and NXDOMAIN Cc: ed.lewis@neustar.biz Content-Type: multipart/alternative; boundary="============_-936088487==_ma============" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --============_-936088487==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I hate to do this, but the below statement is below this precondition: # If recursive service is requested and available, the recursive response # to a query will be one of the following: ...so, name error only include this in recursive situations? (I say with a voice inflection of - now this beats me....) I don't mean to argue against...but...RFC 1034 is so hard to read definitively. At 17:25 -0400 6/8/10, Josh Littlefield wrote: >+1 > >Masataka Ohta wrote: >> Isn't RFC1034 clear enough? >> >> - A name error indicating that the name does not exist. This >> may include CNAME RRs that indicate that the original query >> name was an alias for a name which does not exist. >> >> Masataka Ohta >> >-- >Josh Littlefield Cisco Systems, Inc. >joshl@cisco.com 1414 Massachusetts Avenue >Phone: +1 978-936-0001 Boxborough, MA 01719-2205 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Discussing IPv4 address policy is like deciding what to eat on the Titanic. --============_-936088487==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] CNAME and NXDOMAIN
I hate to do this, but the below statement is below this precondition:

# If recursive service is requested and available, the recursive response
# to a query will be one of the following:
...so, name error only include this in recursive situations?  (I say with a voice inflection of - now this beats me....)

I don't mean to argue against...but...RFC 1034 is so hard to read definitively.

At 17:25 -0400 6/8/10, Josh Littlefield wrote:
>+1
>
>Masataka Ohta wrote:
>> Isn't RFC1034 clear enough?
>>
>>    - A name error indicating that the name does not exist.  This
>>      may include CNAME RRs that indicate that the original query
>>      name was an alias for a name which does not exist.
>>
>>                                           Masataka Ohta
>>  
>--
>Josh Littlefield                                  Cisco Systems, Inc.
>joshl@cisco.com                             1414 Massachusetts Avenue
>Phone: +1 978-936-0001                     Boxborough, MA  01719-2205

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

Discussing IPv4 address policy is like deciding what to eat on the Titanic.
--============_-936088487==_ma============-- From owner-namedroppers@ops.ietf.org Tue Jun 8 15:30:46 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54EC53A67F0; Tue, 8 Jun 2010 15:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFRo2agBqxLj; Tue, 8 Jun 2010 15:30:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D61093A6407; Tue, 8 Jun 2010 15:30:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM7Fr-0005cM-69 for namedroppers-data0@psg.com; Tue, 08 Jun 2010 22:26:43 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM7Fm-0005av-TW for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 22:26:38 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 5B71AEEB29; Tue, 8 Jun 2010 22:26:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o58MQXlh041976; Wed, 9 Jun 2010 08:26:33 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201006082226.o58MQXlh041976@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <201006081432.o58EWSEB034243@drugs.dv.isc.org> Subject: Re: [dnsext] Section 5.1 of draft-dnssec-bis In-reply-to: Your message of "Tue, 08 Jun 2010 10:59:49 -0400." Date: Wed, 09 Jun 2010 08:26:33 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Edward Lewis writes: > At 0:32 +1000 6/9/10, Mark Andrews wrote: > > >Because RFC 4034 go the list wrong. RFC 3755, which introduced NSEC > >had it right. RFC 4034 broke compatibility. Section 5.1 restores > >compatibility. > > Compatibility with what? Deployed code. RFC 4034 were rollups of lots of other RFC's. We stuffed the rollup. > >Not in the context of why one canonicalize domain names. The only > >reason to do this is because the name could be compressed. NSEC > >and RRSIG records have never been allowed to be compressed. > > My concern isn't about compression. It's about the handling of the > cases (as in upper/lower case). > > I know that there's a complication in putting domain names in the > RDATA and expecting them to be treated specially because the location > of the domain name within the RDATA has to be found. This is why > compression was "stopped" for all new record types. > > But what we are seeing in operations is ambiguity when it comes to > the case of the domain names in the NSEC and RRSIG records - and > possibly NSEC3 (but I am not looking at them). > > How will validation work if the domain names in NSEC and RRSIG are > not down cased first? Will the validator have to try all > permutations of the name until there's a match? > > TLD. = TLd. = Tld. = tld. = tLD. = tLd. = TlD. = tlD. ? > > >> The operations&tools-problem here is that there are tools being > >> produced that automatically manage the NSEC (and NSEC3) chains. Some > >> tools are exhibiting unexpected behavior in operations because they > >> follow the un-vetted draft and not the existing proposed standard. > > > >No. There is a problem because we missed the fact that the list > >was wrong and in the process broke compatibility with existing code > >for no good reason. > > There's a problem in operations. Tools that are not compliant with > the RFC are causing problems. > > >The draft is there to catch the errata in the DNSSEC documents and > >that includes RFC 4034. Perhaps it is time to publish the draft. > > With the discussion of the CD bit still going on, and the fact that > DNSSEC is only now getting to the point where we can identify the > "bugs" I hardly think that an update document is near completion. > > I want to close with this question - why not require DNSSEC signers > to down case the domain names in NSEC and RRSIG? > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Discussing IPv4 address policy is like deciding what to eat on the Titanic. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Jun 8 15:31:18 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E70E3A67B1; Tue, 8 Jun 2010 15:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.705 X-Spam-Level: ** X-Spam-Status: No, score=2.705 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HXlKdRRo20q; Tue, 8 Jun 2010 15:31:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C40773A6407; Tue, 8 Jun 2010 15:31:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM7FT-0005Zt-28 for namedroppers-data0@psg.com; Tue, 08 Jun 2010 22:26:19 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM7FO-0005ZJ-Mi for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 22:26:15 +0000 Received: from [10.71.0.51] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id C0A4DC5690D; Tue, 8 Jun 2010 23:26:12 +0100 (BST) Date: Tue, 08 Jun 2010 23:26:32 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Andrew Sullivan , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] draft-registry-fixes terms question Message-ID: <3BD2874ED50BBAD37BCE9091@nimrod.local> In-Reply-To: <20100608203346.GO62459@shinkuro.com> References: <37183901-7770-4716-806D-93A0A8B296DE@nist.gov> <20100607185615.GP60255@shinkuro.com> <20100607210544.GQ60255@shinkuro.com> <53A0D10D-36CD-4356-946A-E02777587FC6@nist.gov> <20100608190203.GK62459@shinkuro.com> <20100608195743.GM62459@shinkuro.com> <43CDAE1486E7AF74906A682E@Ximines.local> <20100608203346.GO62459@shinkuro.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 8 June 2010 16:33:46 -0400 Andrew Sullivan wrote: > On Tue, Jun 08, 2010 at 09:16:56PM +0100, Alex Bligh wrote: >> Right, so RFCs should (according to the above argument) not contain >> forward links, i.e. they should not say "X MUST comply with the >> registry as it is at any future date", but "X MUST comply with >> the registry as it is now" or "X MUST comply with [dump of >> registry]". The registry is a compilation of all the changes >> to it detailed by prior RFCs. > > I'm doing a stupendously bad job at explaining this. I may be doing a stupendously bad job in understanding you (I plead tiredness) > I don't think > it's possible to make a normative requirement on the state of the > registry at a given timestamp, because there's no archive of registry > states. Right. But an RFCxxxx that refers to the registry's content or structure must necessarily referring to it at the time of that RFCxxxx, not any future date (i.e. if either content or structure are modified by RFCyyyy where yyyy>xxxx, any given implementation's compliance with RFCxxxx should remain unaltered if we want RFC like behaviour). So whilst we don't have an archive of registry states per say, we can (and I think must) construct the state by compositing all previous changes to the registry (assuming the registry doesn't contain a change log). This is a general comment about how I thought IANA registries work, not a specific comment about DNS. > What I am suggesting is that we summarize all the requirements for > every algorithm in one document. The obvious one to pick is the > document we've been working on. That document _also_ alters the > registry to add a column that describes the requirement level for the > algorithm, so if you're an implementer today you can go, look in the > registry, and see what the various levels are. All rows in the > registry (at the point when we do this) refer to the > eventually-published RFC that this document becomes. I suppose my question is this. Let us suppose we do what you say, and this is published as RFCnnnn. Does RFCnnnn say something along the lines of: " * The [server] MUST implement those algorithms marked MANDATORY in column X of the algorithm registry * The [server] SHOULD implement those algorithms marked DESIRABLE in column X of the algorithm registry (and so on)". (*) If it does do this, then we have a potential issue. Suppose at the date of this RFCnnnn, the Rhubarb algorithm is MANDATORY but the Gooseberry algorithm has not yet been invented. A vendor then produces code which implements Rhubarb, but not Gooseberry. Time passes, and by standards action RFCrrrr is introduced, where rrrr>nnnn. RFCrrrr by standards action modifies the registry (and updates RFCnnnn or whatever), to make Gooseberry MANDATORY and Rhubard DEPRECATED. Obviously the vendor's implementation is not compliant with RFCrrrr. However, this would appear to change whether it is compliant with RFCnnnn. The way most RFCs behave as far as I could tell is the vendor's software in perpetuity is RFCnnnn compliant but not RFCrrrr compliant. However, now (assuming the text at '*' is read to mean 'at the time the of reading' as opposed to 'at the time of writing), it ceases to become RFCnnnn compliant. If it means 'at the time of writing' you have to reverse engineer the previous state of the registry, to determine that when RFCnnnn was written Gooseberry was not in the registry and Rhubarb was manadatory. That's easy in this case as RFCnnnn defined the registry, but what about for RFCpppp which is somewhere between? I have a feeling I must be being very thick here and should get some sleep. > Make sense? Partially :-) -- Alex Bligh From owner-namedroppers@ops.ietf.org Tue Jun 8 15:31:24 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3B43A67B1; Tue, 8 Jun 2010 15:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.496 X-Spam-Level: * X-Spam-Status: No, score=1.496 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YITyyWq7igqv; Tue, 8 Jun 2010 15:31:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE4213A6407; Tue, 8 Jun 2010 15:31:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM7I8-0005rA-DR for namedroppers-data0@psg.com; Tue, 08 Jun 2010 22:29:04 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM7I4-0005p8-FR for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 22:29:00 +0000 Received: (qmail 58729 invoked from network); 8 Jun 2010 22:50:39 -0000 Received: from softbank219001188004.bbtec.net (HELO ?192.168.1.27?) (219.1.188.4) by necom830.hpcl.titech.ac.jp with SMTP; 8 Jun 2010 22:50:39 -0000 Message-ID: <4C0EC3BF.7050305@necom830.hpcl.titech.ac.jp> Date: Wed, 09 Jun 2010 07:27:11 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] CNAME and NXDOMAIN References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> <20100608171340.GE62459@shinkuro.com> <4C0EA794.2080306@necom830.hpcl.titech.ac.jp> <4C0EB544.9080102@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Edward Lewis wrote: > ...so, name error only include this in recursive situations? > (I say with a voice inflection of - now this beats me....) Note that the name server should never perform recursive service unless asked via RD, since this interferes with trouble shooting of name servers and their databases. > I don't mean to argue against...but...RFC 1034 is so hard to read > definitively. It took me one minuite to find the relevant parts in this and the previous mails. Then, I wasted more than 10 minuites to read what is discussed. You all should first learn to read before writing something. Masataka Ohta From owner-namedroppers@ops.ietf.org Tue Jun 8 15:45:20 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2141D3A6837; Tue, 8 Jun 2010 15:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.895 X-Spam-Level: X-Spam-Status: No, score=-5.895 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJGqlnC1g3rU; Tue, 8 Jun 2010 15:45:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B49033A67D6; Tue, 8 Jun 2010 15:45:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM7UR-0007On-8F for namedroppers-data0@psg.com; Tue, 08 Jun 2010 22:41:47 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM7UM-0007OJ-Qe for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 22:41:43 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABZkDkxAZnwM/2dsb2JhbACeRXGlapoBAoJxgiME X-IronPort-AV: E=Sophos;i="4.53,386,1272844800"; d="scan'208";a="119357320" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Jun 2010 22:41:41 +0000 Received: from [161.44.71.243] ([161.44.71.243]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o58MffwF007486; Tue, 8 Jun 2010 22:41:41 GMT Message-ID: <4C0EC725.3010902@cisco.com> Date: Tue, 08 Jun 2010 18:41:41 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] CNAME and NXDOMAIN References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> <20100608171340.GE62459@shinkuro.com> <4C0EA794.2080306@necom830.hpcl.titech.ac.jp> <4C0EB544.9080102@cisco.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Edward Lewis wrote: > I hate to do this, but the below statement is below this precondition: > > # If recursive service is requested and available, the recursive response > # to a query will be one of the following: > ...so, name error only include this in recursive situations? (I say > with a voice inflection of - now this beats me....) > > I don't mean to argue against...but...RFC 1034 is so hard to read > definitively. It isn't clear that this case of combining CNAMEs and name-error is limited to recursion, though it is mentioned only in that case. The non-recursive section below the section Ohta cited mentions nothing about following or returning any CNAMEs at all. I will admit that the Algorithm in 4.3.2 indicates that one would not return name error when a CNAME has been traversed and one is still looking in an authoritative zone. In step 3.c it says: c. If at some label, a match is impossible (i.e., the corresponding label does not exist), look to see if a the "*" label exists. If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME. If the name is original, set an authoritative name error in the response and exit. Otherwise just exit. But stop 4 of that algorithm (matching in the cache) mentions nothing about CNAMEs at all, and also doesn't really factor in negative caching. And the text in the resolver algorithm around processing CNAME responses is also open to interpretation, basically saying "if the answer is in local information, return it to the client", and "if the response answers the question or contains a name error... [return] it back to the client." I think this is an important reason why 2308 is needed to clarify negative answers, and it handles this case explicitly. My +1 was because I agree with the text cited by Ohta, free of any constraining context, and I think 2308 reflects that as well. -josh > > At 17:25 -0400 6/8/10, Josh Littlefield wrote: > >+1 > > > >Masataka Ohta wrote: > >> Isn't RFC1034 clear enough? > >> > >> - A name error indicating that the name does not exist. This > >> may include CNAME RRs that indicate that the original query > >> name was an alias for a name which does not exist. > >> > >> Masataka Ohta > >> -- Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue Phone: +1 978-936-0001 Boxborough, MA 01719-2205 From owner-namedroppers@ops.ietf.org Tue Jun 8 16:01:58 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8963E3A68AE; Tue, 8 Jun 2010 16:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nfc0fbryrJV7; Tue, 8 Jun 2010 16:01:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 58AD63A680C; Tue, 8 Jun 2010 16:01:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM7k1-0009M5-5O for namedroppers-data0@psg.com; Tue, 08 Jun 2010 22:57:53 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM7jy-0009LY-1T for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 22:57:50 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 22019EEB3D; Tue, 8 Jun 2010 22:57:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o58MvkMC042130; Wed, 9 Jun 2010 08:57:46 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201006082257.o58MvkMC042130@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <201006081432.o58EWSEB034243@drugs.dv.isc.org> Subject: Re: [dnsext] Section 5.1 of draft-dnssec-bis In-reply-to: Your message of "Tue, 08 Jun 2010 10:59:49 -0400." Date: Wed, 09 Jun 2010 08:57:46 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Edward Lewis writes: > At 0:32 +1000 6/9/10, Mark Andrews wrote: > > >Because RFC 4034 go the list wrong. RFC 3755, which introduced NSEC > >had it right. RFC 4034 broke compatibility. Section 5.1 restores > >compatibility. > > Compatibility with what? > > >Not in the context of why one canonicalize domain names. The only > >reason to do this is because the name could be compressed. NSEC > >and RRSIG records have never been allowed to be compressed. > > My concern isn't about compression. It's about the handling of the > cases (as in upper/lower case). > > I know that there's a complication in putting domain names in the > RDATA and expecting them to be treated specially because the location > of the domain name within the RDATA has to be found. This is why > compression was "stopped" for all new record types. > > But what we are seeing in operations is ambiguity when it comes to > the case of the domain names in the NSEC and RRSIG records - and > possibly NSEC3 (but I am not looking at them). > > How will validation work if the domain names in NSEC and RRSIG are > not down cased first? Will the validator have to try all > permutations of the name until there's a match? > > TLD. = TLd. = Tld. = tld. = tLD. = tLd. = TlD. = tlD. ? Firstly. Case is supposed to be preserved in records. This is a requirement from RFC 1034. It's also a requirement from RFC 2535 on all new records types. If you don't go and change the case, by doing unnecessary cannonicalization, the records validate. The reason we downcase NS rdata is that when the record is transmitted and it happens to use a compression pointer, there in no guarantee that the domain pointed to has the same case as the original record had. Compression pointer are why we cannonicalize owner names. At some point in the future we may want to use compression pointers for some of the newer records. We can still do that but there will be a additional requirement that case be preserved and it will also require hop-by-hop option indicating that the client knows how to decompress the records. > >> The operations&tools-problem here is that there are tools being > >> produced that automatically manage the NSEC (and NSEC3) chains. Some > >> tools are exhibiting unexpected behavior in operations because they > >> follow the un-vetted draft and not the existing proposed standard. > > > >No. There is a problem because we missed the fact that the list > >was wrong and in the process broke compatibility with existing code > >for no good reason. > > There's a problem in operations. Tools that are not compliant with > the RFC are causing problems. > > >The draft is there to catch the errata in the DNSSEC documents and > >that includes RFC 4034. Perhaps it is time to publish the draft. > > With the discussion of the CD bit still going on, and the fact that > DNSSEC is only now getting to the point where we can identify the > "bugs" I hardly think that an update document is near completion. > > I want to close with this question - why not require DNSSEC signers > to down case the domain names in NSEC and RRSIG? Because it will break the deployed code and it is not needed to be done. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Discussing IPv4 address policy is like deciding what to eat on the Titanic. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Jun 8 16:21:40 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27AE53A6826; Tue, 8 Jun 2010 16:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.981, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yM3e2QfyoOFA; Tue, 8 Jun 2010 16:21:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E0D53A680E; Tue, 8 Jun 2010 16:21:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM83S-000BWa-0e for namedroppers-data0@psg.com; Tue, 08 Jun 2010 23:17:58 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM83N-000BW8-LT for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 23:17:53 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id EFD94EEB3E; Tue, 8 Jun 2010 23:17:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o58NHo9s042530; Wed, 9 Jun 2010 09:17:50 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201006082317.o58NHo9s042530@drugs.dv.isc.org> To: Josh Littlefield Cc: Edward Lewis , namedroppers@ops.ietf.org From: Mark Andrews References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> <20100608171340.GE62459@shinkuro.com> <4C0EA794.2080306@necom830.hpcl.titech.ac.jp> <4C0EB544.9080102@cisco.com> <4C0EC725.3010902@cisco.com> Subject: Re: [dnsext] CNAME and NXDOMAIN In-reply-to: Your message of "Tue, 08 Jun 2010 18:41:41 -0400." <4C0EC725.3010902@cisco.com> Date: Wed, 09 Jun 2010 09:17:50 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: We need RFC 1034-bis but given how poorly we do -bis documents I'm scared to start down that path. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Tue Jun 8 16:23:47 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6A13A680E; Tue, 8 Jun 2010 16:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.294 X-Spam-Level: ** X-Spam-Status: No, score=2.294 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxd1hjDlaB36; Tue, 8 Jun 2010 16:23:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 923943A67A1; Tue, 8 Jun 2010 16:23:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM86S-000BqN-M2 for namedroppers-data0@psg.com; Tue, 08 Jun 2010 23:21:04 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM86N-000Bok-S2 for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 23:21:00 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o58NKma7064184; Tue, 8 Jun 2010 19:20:50 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.104] by Work-Laptop-2.local (PGP Universal service); Tue, 08 Jun 2010 19:20:57 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 08 Jun 2010 19:20:57 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4C0EC725.3010902@cisco.com> References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> <20100608171340.GE62459@shinkuro.com> <4C0EA794.2080306@necom830.hpcl.titech.ac.jp> <4C0EB544.9080102@cisco.com> <4C0EC725.3010902@cisco.com> Date: Tue, 8 Jun 2010 19:15:16 -0400 To: From: Edward Lewis Subject: Re: [dnsext] CNAME and NXDOMAIN Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 18:41 -0400 6/8/10, Josh Littlefield wrote: >I think this is an important reason why 2308 is needed to clarify >negative answers, and it handles this case explicitly. My +1 was >because I agree with the text cited by Ohta, free of any constraining >context, and I think 2308 reflects that as well. Going back over the thread, when I initially prepared a response it was to support the way BIND treats the situation and not the way NSD does. But in looking through the RFCs, I completely changed my opinion before my first post. I think there's clear statements in support of the NSD handling, but there are places where the RFCs also support BIND's way. What I mean to say, despite my seeing a fairly strong "evidence" supporting the NSD way and the, basically, dilemma of how I can't see a QNAME getting NXDOMAIN for one QTYPE and not another, there are also droplets of text that strongly support BIND's way. Given that my first reaction was to side with BIND, I have a feeling that that approach is correct - it wasn't until I dove into the passages of RFC 1034 that I was swayed to agree with NSD. The NSD way is closer to the "strict interpretation" of the protocol, but more pragmatically, the BIND tells you that the system failed to locate the name where the answer should be. Hence the "Name *Error*". My conclusion is that the specifications aren't clear. I would think that rewriting them in favor of name error for an essentially dangling CNAME chain. Am I willing to write a "CNAME-clarify?" You gotta be kidding.[0] (Besides, Donald's draft is already there.) [0] Referring to the back lash over wildcard-CLARIFY and axfr-CLARIFY, neither of which was exactly a clarification... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Discussing IPv4 address policy is like deciding what to eat on the Titanic. From blessingtoncec@eircom.net Tue Jun 8 20:49:30 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4073A6898 for ; Tue, 8 Jun 2010 20:49:30 -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_80=2, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QlV+bS+nzhH for ; Tue, 8 Jun 2010 20:49:30 -0700 (PDT) Received: from mail24.svc.cra.dublin.eircom.net (mail24.svc.cra.dublin.eircom.net [159.134.118.53]) by core3.amsl.com (Postfix) with SMTP id B1EC83A6809 for ; Tue, 8 Jun 2010 20:49:29 -0700 (PDT) Received: (qmail 38998 messnum 11585464 invoked from network[86.43.60.100/webmail00.webmail.cra.eircom.net]); 9 Jun 2010 03:42:50 -0000 Received: from webmail00.webmail.cra.eircom.net (HELO webmailclassic.eircom.net) (86.43.60.100) by mail24.svc.cra.dublin.eircom.net (qp 38998) with SMTP; 9 Jun 2010 03:42:50 -0000 From: "Mr.Robert Waldron" Reply-To: To: info@loan.com Subject: Loan Offer Date: Wed, 9 Jun 2010 04:43:53 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Originating-IP: 81.218.219.122 X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) Organization: Eircom Net (http://www.eircom.net/) Message-Id: <20100609034929.B1EC83A6809@core3.amsl.com> Attn:Loan Seekers! We offer the following kinds Loan @ 2.5% annual rate (Business Loan, Personal Loan, Mortgage Loan, Debt Consolidation Loan, Auto Loan and Company Loan etc). Please Contact us with the following: Name Of Beneficiary: Requested Loan Amount: Loan Duration : Regards Mr.Robert Waldron E-mail: margettfundmgtltd@discuz.org ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts From blessingtoncec@eircom.net Tue Jun 8 21:01:33 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B57C3A68B2 for ; Tue, 8 Jun 2010 21:01:33 -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_80=2, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdxTBJpLEopZ for ; Tue, 8 Jun 2010 21:01:33 -0700 (PDT) Received: from mail24.svc.cra.dublin.eircom.net (mail24.svc.cra.dublin.eircom.net [159.134.118.53]) by core3.amsl.com (Postfix) with SMTP id 23FC23A67B2 for ; Tue, 8 Jun 2010 21:01:29 -0700 (PDT) Received: (qmail 83021 messnum 11583903 invoked from network[86.43.60.102/webmail02.webmail.cra.eircom.net]); 9 Jun 2010 04:01:25 -0000 Received: from webmail02.webmail.cra.eircom.net (HELO webmailclassic.eircom.net) (86.43.60.102) by mail24.svc.cra.dublin.eircom.net (qp 83021) with SMTP; 9 Jun 2010 04:01:25 -0000 From: "Mr.Robert Waldron" Reply-To: To: info@loan.com Subject: Loan Offer Date: Wed, 9 Jun 2010 05:00:41 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Originating-IP: 204.8.156.142 X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) Organization: Eircom Net (http://www.eircom.net/) Message-Id: <20100609040133.23FC23A67B2@core3.amsl.com> Attn:Loan Seekers! We offer the following kinds Loan @ 2.5% annual rate (Business Loan, Personal Loan, Mortgage Loan, Debt Consolidation Loan, Auto Loan and Company Loan etc). Please Contact us with the following: Name Of Beneficiary: Requested Loan Amount: Loan Duration : Regards Mr.Robert Waldron E-mail: margettfundmgtltd@discuz.org ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts From blessingtoncec@eircom.net Tue Jun 8 21:05:12 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD78F3A68B8 for ; Tue, 8 Jun 2010 21:05:11 -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_80=2, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJH4UZfB3Qgz for ; Tue, 8 Jun 2010 21:05:11 -0700 (PDT) Received: from mail23.svc.cra.dublin.eircom.net (mail23.svc.cra.dublin.eircom.net [159.134.118.145]) by core3.amsl.com (Postfix) with SMTP id 3A7913A688C for ; Tue, 8 Jun 2010 21:05:11 -0700 (PDT) Received: (qmail 62939 messnum 8147977 invoked from network[86.43.60.100/webmail00.webmail.cra.eircom.net]); 9 Jun 2010 03:58:32 -0000 Received: from webmail00.webmail.cra.eircom.net (HELO webmailclassic.eircom.net) (86.43.60.100) by mail23.svc.cra.dublin.eircom.net (qp 62939) with SMTP; 9 Jun 2010 03:58:32 -0000 From: "Mr.Robert Waldron" Reply-To: To: info@loan.com Subject: Loan Offer Date: Wed, 9 Jun 2010 04:59:35 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Originating-IP: 204.8.156.142 X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) Organization: Eircom Net (http://www.eircom.net/) Message-Id: <20100609040511.3A7913A688C@core3.amsl.com> Attn:Loan Seekers! We offer the following kinds Loan @ 2.5% annual rate (Business Loan, Personal Loan, Mortgage Loan, Debt Consolidation Loan, Auto Loan and Company Loan etc). Please Contact us with the following: Name Of Beneficiary: Requested Loan Amount: Loan Duration : Regards Mr.Robert Waldron E-mail: margettfundmgtltd@discuz.org ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts From blessingtoncec@eircom.net Tue Jun 8 21:19:05 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85BC3A6887 for ; Tue, 8 Jun 2010 21:19:05 -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_80=2, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDN59e9pWOcV for ; Tue, 8 Jun 2010 21:19:05 -0700 (PDT) Received: from mail21.svc.cra.dublin.eircom.net (mail21.svc.cra.dublin.eircom.net [159.134.118.222]) by core3.amsl.com (Postfix) with SMTP id 543DD3A6884 for ; Tue, 8 Jun 2010 21:19:05 -0700 (PDT) Received: (qmail 58219 messnum 6609990 invoked from network[86.43.60.100/webmail00.webmail.cra.eircom.net]); 9 Jun 2010 04:12:26 -0000 Received: from webmail00.webmail.cra.eircom.net (HELO webmailclassic.eircom.net) (86.43.60.100) by mail21.svc.cra.dublin.eircom.net (qp 58219) with SMTP; 9 Jun 2010 04:12:26 -0000 From: "Mr.Robert Waldron" Reply-To: To: info@loan.com Subject: Loan Offer Date: Wed, 9 Jun 2010 05:13:29 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Originating-IP: 192.251.226.205 X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) Organization: Eircom Net (http://www.eircom.net/) Message-Id: <20100609041905.543DD3A6884@core3.amsl.com> Attn:Loan Seekers! We offer the following kinds Loan @ 2.5% annual rate (Business Loan, Personal Loan, Mortgage Loan, Debt Consolidation Loan, Auto Loan and Company Loan etc). Please Contact us with the following: Name Of Beneficiary: Requested Loan Amount: Loan Duration : Regards Mr.Robert Waldron E-mail: margettfundmgtltd@discuz.org ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts From blessingtoncec@eircom.net Tue Jun 8 21:19:05 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88E83A68B0 for ; Tue, 8 Jun 2010 21:19:05 -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_80=2, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHo5TLyRx1Tq for ; Tue, 8 Jun 2010 21:19:05 -0700 (PDT) Received: from mail21.svc.cra.dublin.eircom.net (mail21.svc.cra.dublin.eircom.net [159.134.118.222]) by core3.amsl.com (Postfix) with SMTP id 543C63A681B for ; Tue, 8 Jun 2010 21:19:05 -0700 (PDT) Received: (qmail 58219 messnum 6609990 invoked from network[86.43.60.100/webmail00.webmail.cra.eircom.net]); 9 Jun 2010 04:12:26 -0000 Received: from webmail00.webmail.cra.eircom.net (HELO webmailclassic.eircom.net) (86.43.60.100) by mail21.svc.cra.dublin.eircom.net (qp 58219) with SMTP; 9 Jun 2010 04:12:26 -0000 From: "Mr.Robert Waldron" Reply-To: To: info@loan.com Subject: Loan Offer Date: Wed, 9 Jun 2010 05:13:29 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Originating-IP: 192.251.226.205 X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) Organization: Eircom Net (http://www.eircom.net/) Message-Id: <20100609041905.543C63A681B@core3.amsl.com> Attn:Loan Seekers! We offer the following kinds Loan @ 2.5% annual rate (Business Loan, Personal Loan, Mortgage Loan, Debt Consolidation Loan, Auto Loan and Company Loan etc). Please Contact us with the following: Name Of Beneficiary: Requested Loan Amount: Loan Duration : Regards Mr.Robert Waldron E-mail: margettfundmgtltd@discuz.org ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts From blessingtoncec@eircom.net Tue Jun 8 21:22:03 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE5F3A68BC for ; Tue, 8 Jun 2010 21:22:03 -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_80=2, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiobKWuahGDe for ; Tue, 8 Jun 2010 21:22:03 -0700 (PDT) Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by core3.amsl.com (Postfix) with SMTP id 49BFD3A68B7 for ; Tue, 8 Jun 2010 21:22:03 -0700 (PDT) Received: (qmail 60971 messnum 9457948 invoked from network[86.43.60.102/webmail02.webmail.cra.eircom.net]); 9 Jun 2010 04:15:08 -0000 Received: from webmail02.webmail.cra.eircom.net (HELO webmailclassic.eircom.net) (86.43.60.102) by mail13.svc.cra.dublin.eircom.net (qp 60971) with SMTP; 9 Jun 2010 04:15:08 -0000 From: "Mr.Robert Waldron" Reply-To: To: info@loan.com Subject: Loan Offer Date: Wed, 9 Jun 2010 05:14:24 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Originating-IP: 192.251.226.205 X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) Organization: Eircom Net (http://www.eircom.net/) Message-Id: <20100609042203.49BFD3A68B7@core3.amsl.com> Attn:Loan Seekers! We offer the following kinds Loan @ 2.5% annual rate (Business Loan, Personal Loan, Mortgage Loan, Debt Consolidation Loan, Auto Loan and Company Loan etc). Please Contact us with the following: Name Of Beneficiary: Requested Loan Amount: Loan Duration : Regards Mr.Robert Waldron E-mail: margettfundmgtltd@discuz.org ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts From blessingtoncec@eircom.net Tue Jun 8 21:32:54 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA663A68BD for ; Tue, 8 Jun 2010 21:32:54 -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_80=2, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K47wskhKZNSs for ; Tue, 8 Jun 2010 21:32:54 -0700 (PDT) Received: from mail25.svc.cra.dublin.eircom.net (mail25.svc.cra.dublin.eircom.net [159.134.118.54]) by core3.amsl.com (Postfix) with SMTP id 61C623A68B7 for ; Tue, 8 Jun 2010 21:32:54 -0700 (PDT) Received: (qmail 49878 messnum 16693446 invoked from network[86.43.60.102/webmail02.webmail.cra.eircom.net]); 9 Jun 2010 04:06:15 -0000 Received: from webmail02.webmail.cra.eircom.net (HELO webmailclassic.eircom.net) (86.43.60.102) by mail25.svc.cra.dublin.eircom.net (qp 49878) with SMTP; 9 Jun 2010 04:06:15 -0000 From: "Mr.Robert Waldron" Reply-To: To: info@loan.com Subject: Loan Offer Date: Wed, 9 Jun 2010 05:05:31 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Originating-IP: 204.8.156.142 X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) Organization: Eircom Net (http://www.eircom.net/) Message-Id: <20100609043254.61C623A68B7@core3.amsl.com> Attn:Loan Seekers! We offer the following kinds Loan @ 2.5% annual rate (Business Loan, Personal Loan, Mortgage Loan, Debt Consolidation Loan, Auto Loan and Company Loan etc). Please Contact us with the following: Name Of Beneficiary: Requested Loan Amount: Loan Duration : Regards Mr.Robert Waldron E-mail: margettfundmgtltd@discuz.org ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts From blessingtoncec@eircom.net Tue Jun 8 22:53:06 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B804B3A68BA for ; Tue, 8 Jun 2010 22:53:06 -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=-0.500, BAYES_99=3.5, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBBwOSg1jw2Q for ; Tue, 8 Jun 2010 22:53:05 -0700 (PDT) Received: from mail25.svc.cra.dublin.eircom.net (mail25.svc.cra.dublin.eircom.net [159.134.118.54]) by core3.amsl.com (Postfix) with SMTP id 53E283A6885 for ; Tue, 8 Jun 2010 22:53:05 -0700 (PDT) Received: (qmail 49878 messnum 16693446 invoked from network[86.43.60.102/webmail02.webmail.cra.eircom.net]); 9 Jun 2010 04:06:15 -0000 Received: from webmail02.webmail.cra.eircom.net (HELO webmailclassic.eircom.net) (86.43.60.102) by mail25.svc.cra.dublin.eircom.net (qp 49878) with SMTP; 9 Jun 2010 04:06:15 -0000 From: "Mr.Robert Waldron" Reply-To: To: info@loan.com Subject: Loan Offer Date: Wed, 9 Jun 2010 05:05:31 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Originating-IP: 204.8.156.142 X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) Organization: Eircom Net (http://www.eircom.net/) Message-Id: <20100609055305.53E283A6885@core3.amsl.com> Attn:Loan Seekers! We offer the following kinds Loan @ 2.5% annual rate (Business Loan, Personal Loan, Mortgage Loan, Debt Consolidation Loan, Auto Loan and Company Loan etc). Please Contact us with the following: Name Of Beneficiary: Requested Loan Amount: Loan Duration : Regards Mr.Robert Waldron E-mail: margettfundmgtltd@discuz.org ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts From blessingtoncec@eircom.net Tue Jun 8 22:53:07 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA0D93A68BA for ; Tue, 8 Jun 2010 22:53:07 -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=-0.500, BAYES_99=3.5, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94vQve8dhG9W for ; Tue, 8 Jun 2010 22:53:07 -0700 (PDT) Received: from mail25.svc.cra.dublin.eircom.net (mail25.svc.cra.dublin.eircom.net [159.134.118.54]) by core3.amsl.com (Postfix) with SMTP id 4AA483A6885 for ; Tue, 8 Jun 2010 22:53:03 -0700 (PDT) Received: (qmail 49878 messnum 16693446 invoked from network[86.43.60.102/webmail02.webmail.cra.eircom.net]); 9 Jun 2010 04:06:15 -0000 Received: from webmail02.webmail.cra.eircom.net (HELO webmailclassic.eircom.net) (86.43.60.102) by mail25.svc.cra.dublin.eircom.net (qp 49878) with SMTP; 9 Jun 2010 04:06:15 -0000 From: "Mr.Robert Waldron" Reply-To: To: info@loan.com Subject: Loan Offer Date: Wed, 9 Jun 2010 05:05:31 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Originating-IP: 204.8.156.142 X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) Organization: Eircom Net (http://www.eircom.net/) Message-Id: <20100609055307.4AA483A6885@core3.amsl.com> Attn:Loan Seekers! We offer the following kinds Loan @ 2.5% annual rate (Business Loan, Personal Loan, Mortgage Loan, Debt Consolidation Loan, Auto Loan and Company Loan etc). Please Contact us with the following: Name Of Beneficiary: Requested Loan Amount: Loan Duration : Regards Mr.Robert Waldron E-mail: margettfundmgtltd@discuz.org ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts From blessingtoncec@eircom.net Tue Jun 8 23:01:47 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9A73A68D9 for ; Tue, 8 Jun 2010 23:01:47 -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=-0.500, BAYES_99=3.5, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmG8Yvcq1srz for ; Tue, 8 Jun 2010 23:01:47 -0700 (PDT) Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by core3.amsl.com (Postfix) with SMTP id 0D8F83A68C5 for ; Tue, 8 Jun 2010 23:01:46 -0700 (PDT) Received: (qmail 60971 messnum 9457948 invoked from network[86.43.60.102/webmail02.webmail.cra.eircom.net]); 9 Jun 2010 04:15:08 -0000 Received: from webmail02.webmail.cra.eircom.net (HELO webmailclassic.eircom.net) (86.43.60.102) by mail13.svc.cra.dublin.eircom.net (qp 60971) with SMTP; 9 Jun 2010 04:15:08 -0000 From: "Mr.Robert Waldron" Reply-To: To: info@loan.com Subject: Loan Offer Date: Wed, 9 Jun 2010 05:14:24 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Originating-IP: 192.251.226.205 X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) Organization: Eircom Net (http://www.eircom.net/) Message-Id: <20100609060147.0D8F83A68C5@core3.amsl.com> Attn:Loan Seekers! We offer the following kinds Loan @ 2.5% annual rate (Business Loan, Personal Loan, Mortgage Loan, Debt Consolidation Loan, Auto Loan and Company Loan etc). Please Contact us with the following: Name Of Beneficiary: Requested Loan Amount: Loan Duration : Regards Mr.Robert Waldron E-mail: margettfundmgtltd@discuz.org ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts From owner-namedroppers@ops.ietf.org Wed Jun 9 01:38:09 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF3E28C0DC; Wed, 9 Jun 2010 01:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.55 X-Spam-Level: ** X-Spam-Status: No, score=2.55 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_NL=0.55, HELO_MISMATCH_NL=1.448, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6KkYwWiGN3V; Wed, 9 Jun 2010 01:38:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A42D28C0DD; Wed, 9 Jun 2010 01:38:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMGg0-000HpA-9K for namedroppers-data0@psg.com; Wed, 09 Jun 2010 08:30:20 +0000 Received: from [85.17.178.138] (helo=rotring.dds.nl) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMGfs-000Hnj-82 for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 08:30:12 +0000 Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 995FE583BB; Wed, 9 Jun 2010 10:30:07 +0200 (CEST) Received: from vylkir.localdomain (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTP id DB22458377; Wed, 9 Jun 2010 10:29:56 +0200 (CEST) Message-ID: <4C0F5104.3070205@nlnetlabs.nl> Date: Wed, 09 Jun 2010 10:29:56 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4 MIME-Version: 1.0 To: Edward Lewis CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] CNAME and NXDOMAIN References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> <20100608171340.GE62459@shinkuro.com> <4C0EA794.2080306@necom830.hpcl.titech.ac.jp> <4C0EB544.9080102@cisco.com> <4C0EC725.3010902@cisco.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at rotring X-Virus-Status: Clean Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ed, On 06/09/2010 01:15 AM, Edward Lewis wrote: > The NSD way is closer to the "strict interpretation" of the protocol, > but more pragmatically, the BIND tells you that the system failed to > locate the name where the answer should be. Hence the "Name *Error*". My best interpretation [at the current time] is that 1034 appears to say that for authoritative zones NOERROR is the strict interpretation and for recursive lookups (+RD flag) NXDOMAIN. > My conclusion is that the specifications aren't clear. I would think > that rewriting them in favor of name error for an essentially dangling > CNAME chain. Yes, I agree. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkwPUQQACgkQkDLqNwOhpPgahgCgkoIp2yXmGL7mj9Qja8Z3+DE6 mBQAnirP2T0uRxCZjp7UP5mlnW3VIXMH =ujkw -----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Wed Jun 9 02:00:23 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5FE28C0D6; Wed, 9 Jun 2010 02:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.44 X-Spam-Level: X-Spam-Status: No, score=-5.44 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rke-Z0wsCtQj; Wed, 9 Jun 2010 02:00:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E132C3A691B; Wed, 9 Jun 2010 02:00:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMH3x-000LZk-TM for namedroppers-data0@psg.com; Wed, 09 Jun 2010 08:55:05 +0000 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMH3u-000LYj-0b for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 08:55:02 +0000 DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=mUo9V37H8hPVuKrtESgpy01aJJ+bnKn7PZypXJNpo/0RkCztJHAZoyJ3 rPv3/FD8RFvUPq+K9ylut4HxnDR2qFTGVfEde5w/nHOgLNLqflsY0d/Z7 rlm3zla/LYl1fe7; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1276073702; x=1307609702; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[dnsext]=20CNAME=20and=20NXDOMAIN|Date: =20Wed,=209=20Jun=202010=2008:54:58=20+0000|Message-ID: =20<2C1227B4-3BCD-4CB0-84BD-030948876AAB@nominet.org.uk> |To:=20"namedroppers@ops.ietf.org"=20|CC:=20"W.C.A.=20Wijngaards"=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20quote d-printable|Content-ID:=20<9ff0f8c8-022a-473e-b2f7-61a2b7 0313f4>|In-Reply-To:=20<4C0F5104.3070205@nlnetlabs.nl> |References:=20=0D =0A=20<55156.1274856474@nsa.vix.com>=20=0D=0A=20<64615.1276012058@nsa.vix.c om>=20<20100608171340.GE62459@shinkuro.com>=0D=0A=20<4C0E A794.2080306@necom830.hpcl.titech.ac.jp>=20<4C0EB544.9080 102@cisco.com>=0D=0A=20=20<4C0EC725.3010902@cisco.com>=0D=0A=20=20<4C0F5104.3070205@nlnetlabs .nl>; bh=kqZ7ehhFCAge6hBzLTNBFvcxglH0HE/novAma+br8vY=; b=22DjojOy523RV3JTMkpKyWsxiwn5WphgHKMTjzCyHqFQ7dPN6hTge26o SFFwsyKOXSz8i3E//CZF5nD9+AST7Wz6rx9t3eeErI/+cOhczyO6/fU1y 4hCF3Zuodeu7yJ2; X-IronPort-AV: E=Sophos;i="4.53,390,1272841200"; d="scan'208";a="24849773" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 09 Jun 2010 09:54:59 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%20]) with mapi; Wed, 9 Jun 2010 09:54:59 +0100 From: Ray Bellis To: "namedroppers@ops.ietf.org" CC: "W.C.A. Wijngaards" Subject: Re: [dnsext] CNAME and NXDOMAIN Thread-Topic: [dnsext] CNAME and NXDOMAIN Thread-Index: AQHLBy+ZydG21R0wn0ipmYKV+EcU1pJ4csIAgAAQUQCAAAfLgIAADYWAgAAJYgCAAJr5AIAABv8A Date: Wed, 9 Jun 2010 08:54:58 +0000 Message-ID: <2C1227B4-3BCD-4CB0-84BD-030948876AAB@nominet.org.uk> References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> <20100608171340.GE62459@shinkuro.com> <4C0EA794.2080306@necom830.hpcl.titech.ac.jp> <4C0EB544.9080102@cisco.com> <4C0EC725.3010902@cisco.com> <4C0F5104.3070205@nlnetlabs.nl> In-Reply-To: <4C0F5104.3070205@nlnetlabs.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <9ff0f8c8-022a-473e-b2f7-61a2b70313f4> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > My best interpretation [at the current time] is that 1034 appears to say > that for authoritative zones NOERROR is the strict interpretation and > for recursive lookups (+RD flag) NXDOMAIN. For what it's worth, that's my interpretation too. Ray From owner-namedroppers@ops.ietf.org Wed Jun 9 04:45:36 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9C728C0FB; Wed, 9 Jun 2010 04:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.273 X-Spam-Level: ** X-Spam-Status: No, score=2.273 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPqGvt+bizuA; Wed, 9 Jun 2010 04:45:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B0FB628C0E6; Wed, 9 Jun 2010 04:45:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMJbm-000KWR-Dr for namedroppers-data0@psg.com; Wed, 09 Jun 2010 11:38:10 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMJbb-000KRn-2D for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 11:37:59 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o59Bbl1v069029; Wed, 9 Jun 2010 07:37:48 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.104] by Work-Laptop-2.local (PGP Universal service); Wed, 09 Jun 2010 07:37:55 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 09 Jun 2010 07:37:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201006082226.o58MQXlh041976@drugs.dv.isc.org> References: <201006081432.o58EWSEB034243@drugs.dv.isc.org> <201006082226.o58MQXlh041976@drugs.dv.isc.org> Date: Wed, 9 Jun 2010 07:37:42 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] Section 5.1 of draft-dnssec-bis Cc: Edward Lewis Content-Type: multipart/alternative; boundary="============_-936039027==_ma============" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --============_-936039027==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 8:26 +1000 6/9/10, Mark Andrews wrote: >Deployed code. RFC 4034 were rollups of lots of other RFC's. We stuffed >the rollup. The reason I'm not letting this go like a sane person would is that it's not simply that we "stuffed the rollup." And that's why I supplied text in a previous message. In RFC 2065 (the first stab at DNSSEC) is says this towards the end of 4.1: The "signer's name" field is the domain name of the signer generating the SIG RR. This is the owner of the public KEY RR that can be used to verify the signature. It is frequently the zone which contained the RR(s) being authenticated. The signer's name may be compressed with standard DNS name compression when being transmitted over the network. In RFC 2535 carries this forward: 4.1.7 Signer's Name Field ....................... The signer's name may be compressed with standard DNS name compression when being transmitted over the network. Because both were specified to be compressible they needed to be down cased. So to undo this mistaken assumption we should document the reason for the change explicitly. (The reason I was so convinced we needed to down case was because when I wrote code on this I had to down case given the assumptions of the time. No truth to the rumor that my code is so old it is in Fortran IV.) If a signer down cased as part of writing the entire zone, meaning it also down cases the RDATA, this all worked. When the signer didn't down case the RDATA this caused problems. I got that from David. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Discussing IPv4 address policy is like deciding what to eat on the Titanic. --============_-936039027==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] Section 5.1 of draft-dnssec-bis
At 8:26 +1000 6/9/10, Mark Andrews wrote:

>Deployed code.  RFC 4034 were rollups of lots of other RFC's.  We stuffed
>the rollup.

The reason I'm not letting this go like a sane person would is that it's not simply that we "stuffed the rollup."  And that's why I supplied text in a previous message.

In RFC 2065 (the first stab at DNSSEC) is says this towards the end of 4.1:

   The "signer's name" field is the domain name of the signer generating
   the SIG RR.  This is the owner of the public KEY RR that can be used
   to verify the signature.  It is frequently the zone which contained
   the RR(s) being authenticated.  The signer's name may be compressed
   with standard DNS name compression when being transmitted over the
   network.

In RFC 2535 carries this forward:

4.1.7 Signer's Name Field
   ....................... The signer's name may be compressed with
   standard DNS name compression when being transmitted over the
   network.

Because both were specified to be compressible they needed to be down cased.  So to undo this mistaken assumption we should document the reason for the change explicitly.  (The reason I was so convinced we needed to down case was because when I wrote code on this I had to down case given the assumptions of the time.  No truth to the rumor that my code is so old it is in Fortran IV.)

If a signer down cased as part of writing the entire zone, meaning it also down cases the RDATA, this all worked.  When the signer didn't down case the RDATA this caused problems.  I got that from David.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Discussing IPv4 address policy is like deciding what to eat on the Titanic.
--============_-936039027==_ma============-- From owner-namedroppers@ops.ietf.org Wed Jun 9 06:12:41 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714523A6971; Wed, 9 Jun 2010 06:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.352 X-Spam-Level: ** X-Spam-Status: No, score=2.352 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ5mOwB7zmpN; Wed, 9 Jun 2010 06:12:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B3E83A691C; Wed, 9 Jun 2010 06:12:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMKz3-000Avb-12 for namedroppers-data0@psg.com; Wed, 09 Jun 2010 13:06:17 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMKyx-000AuM-19 for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 13:06:11 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A36FE1ECB408 for ; Wed, 9 Jun 2010 13:06:07 +0000 (UTC) Date: Wed, 9 Jun 2010 09:06:05 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-registry-fixes terms question Message-ID: <20100609130605.GS62459@shinkuro.com> References: <20100607210544.GQ60255@shinkuro.com> <53A0D10D-36CD-4356-946A-E02777587FC6@nist.gov> <20100608190203.GK62459@shinkuro.com> <20100608195743.GM62459@shinkuro.com> <43CDAE1486E7AF74906A682E@Ximines.local> <20100608203346.GO62459@shinkuro.com> <3BD2874ED50BBAD37BCE9091@nimrod.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BD2874ED50BBAD37BCE9091@nimrod.local> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Now I see the disconnect. On Tue, Jun 08, 2010 at 11:26:32PM +0100, Alex Bligh wrote: > I suppose my question is this. Let us suppose we do what you say, and > this is published as RFCnnnn. Does RFCnnnn say something along the > lines of: > " * The [server] MUST implement those algorithms marked MANDATORY > in column X of the algorithm registry > * The [server] SHOULD implement those algorithms marked DESIRABLE > in column X of the algorithm registry > (and so on)". (*) > No, that's not how it works. RFCnnnn says * Algorithms A and B are MANDATORY. A server MUST implement those algorithms. A client MUST be capable of using them. * Algorithms D and E are ENCOURAGED. A server SHOULD implement those algorithms. A client SHOULD be capable of using them. These algorithms are expected to become MANDATORY in future. * Algorithms G and H are DISCOURAGED. A server MAY decline to support them. A client SHOULD NOT use them. These algorithms are expected to become OBSOLETE in future. * Algorithm Z is OBSOLETE. A server SHOULD NOT support it. A client SHOULD NOT be capable of using it. * IANA is requested to update The DNS Security Algorithm Number subregistry with the above values. When you're ready to change G and H to OBSOLETE, you create a new RFCrrrr that obsoletes RFCnnnn. > change whether it is compliant with RFCnnnn. The way most RFCs > behave as far as I could tell is the vendor's software in > perpetuity is RFCnnnn compliant but not RFCrrrr compliant. Exactly right. And that's why we can't put the authority in the registry, but must put the authoritative definition in some RFC. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From blessingtoncec@eircom.net Wed Jun 9 06:15:10 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A6C3A68EE for ; Wed, 9 Jun 2010 06:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.141 X-Spam-Level: *** X-Spam-Status: No, score=3.141 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_95=3, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsaDJEZGD7GT for ; Wed, 9 Jun 2010 06:15:10 -0700 (PDT) Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by core3.amsl.com (Postfix) with SMTP id C33EE3A68BA for ; Wed, 9 Jun 2010 06:15:09 -0700 (PDT) Received: (qmail 60971 messnum 9457948 invoked from network[86.43.60.102/webmail02.webmail.cra.eircom.net]); 9 Jun 2010 04:15:08 -0000 Received: from webmail02.webmail.cra.eircom.net (HELO webmailclassic.eircom.net) (86.43.60.102) by mail13.svc.cra.dublin.eircom.net (qp 60971) with SMTP; 9 Jun 2010 04:15:08 -0000 From: "Mr.Robert Waldron" Reply-To: To: info@loan.com Subject: Loan Offer Date: Wed, 9 Jun 2010 05:14:24 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Originating-IP: 192.251.226.205 X-Mailer: Eircom Net CRC Webmail (http://www.eircom.net/) Organization: Eircom Net (http://www.eircom.net/) Message-Id: <20100609131509.C33EE3A68BA@core3.amsl.com> Attn:Loan Seekers! We offer the following kinds Loan @ 2.5% annual rate (Business Loan, Personal Loan, Mortgage Loan, Debt Consolidation Loan, Auto Loan and Company Loan etc). Please Contact us with the following: Name Of Beneficiary: Requested Loan Amount: Loan Duration : Regards Mr.Robert Waldron E-mail: margettfundmgtltd@discuz.org ----------------------------------------------------------------- Find the home of your dreams with eircom net property Sign up for email alerts now http://www.eircom.net/propertyalerts From owner-namedroppers@ops.ietf.org Wed Jun 9 06:15:41 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3EC83A68BA; Wed, 9 Jun 2010 06:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.935 X-Spam-Level: *** X-Spam-Status: No, score=3.935 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rODG-LnYkDuw; Wed, 9 Jun 2010 06:15:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 051A53A68EE; Wed, 9 Jun 2010 06:15:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OML4i-000Brr-2K for namedroppers-data0@psg.com; Wed, 09 Jun 2010 13:12:08 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OML4c-000Bqp-As for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 13:12:03 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o59DBvPG069701 for ; Wed, 9 Jun 2010 09:11:57 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o59DBvXk069700 for namedroppers@ops.ietf.org; Wed, 9 Jun 2010 09:11:57 -0400 (EDT) (envelope-from namedroppers) Message-Id: <201006091311.o59DBvXk069700@stora.ogud.com> Received: from [76.96.59.211] (helo=QMTA11.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OM7Br-0005Go-IU for namedroppers@ops.ietf.org; Tue, 08 Jun 2010 22:22:36 +0000 Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA11.westchester.pa.mail.comcast.net with comcast id TZzK1e0040vyq2s5BaNb3h; Tue, 08 Jun 2010 22:22:35 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta05.westchester.pa.mail.comcast.net with comcast id TaNa1e0091EtFYL3RaNaKU; Tue, 08 Jun 2010 22:22:35 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 08 Jun 2010 18:22:23 -0400 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Michael StJohns Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data In-Reply-To: <20100608210903.GP62459@shinkuro.com> References: <20100514135457.GA65855@shinkuro.com> <20100514195525.GL65855@shinkuro.com> <20100517143811.GA77756@shinkuro.com> <20100607212213.GR60255@shinkuro.com> <20100608210903.GP62459@shinkuro.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_357174460==.ALT" X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --=====================_357174460==.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 05:09 PM 6/8/2010, Andrew Sullivan wrote: >On Tue, Jun 08, 2010 at 04:33:19PM -0400, Michael StJohns wrote: > >> There have been ample counter arguments. But the counter arguments >> have not been persuasive. They mostly just boil down to "I think I >> might possibly get better protection if I don't set the bit" - but >> have failed to explain how -absent specific configuration of the >> resolver to know - they would know such higher resolver could do a >> better job of validating. > >Well, maybe they're planning to do that specific configuration. I >don't know, neither do you, and we have existing text that permits >such operation. This is not supposed to be a revision of DNSSECbis, >but a clarification of it. DNSSEC is silent both on the setting of the CD bit in the upstream in this= case AND on how you determine how to set it. The fact that someone picked= one and ran with it doesn't mean that is what we should document. I do= agree though that we should probably not prohibit that model of operation. >> BTW, I assume since you're citing your opinion, you're currently not >> wearing your chairmans hat? > >On the contrary, I am acting as chair and ruling on what rough >consensus I think is possible. We seem to have two sets of >strongly-held views here. The documents we are trying to clarify >appear to allow either interpretation. Your proposal is to close off >one interpretation; but I think that in the absence of strong >consensus (which we clearly do not have), it would be wrong to do so >in a document purporting to clarify something. If this document does >not get immediate, "Yes, that's obviously what 403x meant" from >everyone, then it's not making a clarification. Your proposed MUST >just doesn't meet that test. Sorry. I really don't care about which MUST happens, I just insist that at least= one of them does. I've said this now in at least 3 messages - would you= please move on?=20 And with respect to "consensus" exactly how many people do you believe have= expressed an opinion on this in the last go around? I'll give you a hint,= not counting you and me and the document editor, it was less than 2. And= the document editor was mostly trying to find "simple" text. Plus one= side comment about multiple key types that was a clarification rather than= taking a side.=20 >> My complaint from the start with this text is that "may wish to set" >> is not standards language. Each implementer will read this text >> differently. And frankly, this text could be read as "a validator >> can randomly set the CD bit on all upstream queries" >=20 >I don't think that's allowed to begin with, and it sounds like an >enormous expansion of the scope of the problem here. I'd like a >plausible reading of RFC 4035 =C2=A73.2.2 that says you can just do random >things with the CD bit. =20 *sigh* Its not the plausible reading of 4035, its the plausible reading of= the -11 bis. "For efficiency" and "may set" does not define the= conditions under which the bit is set, does not define the default= behavior, does not define the configuration options for non-default= behavior, etc etc etc. So "random" as a possible behavior is not excluded= by 4035 and not by the text in -11. Let me ask you - specifically. Given the text of -11, how - EXACTLY -= would you set the CD bit in the upstream given a covering TA? Please be= specific and describe how your approach is what is meant by the current= text. If you say "operators choice" then I say, "what are the knobs and what's the= default?". If you say "implementers choice" then I say "what must all= implementers do and how do I as an operator recover from a bad= implemetation choice?" If you say "it depends" then I say "ok, so what= you're saying is that from the view point of a querier the result from= sending a non-CD bit query to a validating resolver implementing your 'it= depends' or 'may set' is a random setting of the bit since the querier has= no predictable way of determining how the bit is set" Pick one well defined approach that a querier can depend upon - I really= don't care which at this point in time. Make it the common default= behavior for all resolvers. Provide a mechanism to opt out of either of= them. We're done. I asked you to explain why standards language wasn't appropriate... let me= ask that again. I've given you two different blurbs that describe both my= desired option and the "don't set the bit by default" option. Both of= these also provide the escape valves to do the other thing. Pick one of= mine, or explain why the current text is better and really does say what= you think it does in a consistently implementable way. >The only problem, as I understood it, was the >interaction of all of this with a cache, and what to do in the case of >data in the cache that suggests issues.=20 Nope. Two different issues. =20 > That issue is stickier in the >presence of intermediate caches and different security awarenesses, >but it's not actually made any different. Remember, we're clarifying >the previous RFCs, not replacing them. We don't actually need to >restate everything in them. Actually, the previous RFCs pretty obviously didn't consider what would= happen if there were multiple cache/validators between authoritative and= querier. It wasn't an issue in non-DNSSEC with multiple caches, but= validating caches are not passive repositories of data. =20 >> The argument is about whether or not you need to keep track of the >> validation/CD bit set status of cached data. This basically says >> that if you're implementing a validating resolver, and you cache >> non-validated data (because the CD bit was set), you need to keep >> track of that status. But it also says, its ok to *not* cache CD >> bit set data. > >Your proposed text does not say that. SHOULD is not "well, this'd be >a good idea". It means that you'd better have a pretty good reason >why not. That was why I suggested some modifications. Moreover, it >wasn't clear to me whether it was supposed to have implications for >caching data with CD=3D0. Actually it does. It may not say it clearly enough, but that's what was= meant. And if you read all three paragraphs of the text, it really does say= that. With respect to this - the normal rule is that if you cite one condition of= data, you aren't actually saying anything about any other condition of= data. So if you need to clarify this doesn't apply to CD=3D0 data, feel= free to add text. >> If you get a non-CD bit query, you can mostly answer from cache - >> but class 4 data will require being turned into class 5 or 6. Class >> 7 will require a re-query. >>=20 > >I think everyone is in agreement about that, and all we're trying to >do is come up with text that is easy to understand. =20 >> >How about this: >> > >> > When caching, a security-aware intermediate resolver MAY return >> > data without validating it only if the original query had the CD >> > bit set. >>=20 >> I think not... because the above can be read to say that its optional to= return non-validated data if the CD bit is set and that particular item is= non-optional. It also doesn't cover the case where the resolver doesn't= have a covering TA for the data. >>=20 > >Hrm, you're right about the MAY. But we can fix that. =20 > > When caching, a security-aware intermediate resolver MAY return > data without validating it only if the original query had the CD > bit set.=20 > In that case, the intermediate resolver MAY defer > validation of the data, but MUST mark the cached data as > non-validated until local validation actually occurs. It MUST NOT > return the cached, unvalidated data to a query with CD=3D0. As > specfied in [RFC4035], Section 3.2.2, it SHOULD return the data,=20 > regardless of any validation, to a query with CD=3D1. =20 >That's a little awkward, but I still find it clearer than what you >proposed before. The no-covering-TA is a red herring. If the >intermediate resolver can't validate the data because it doesn't have >a covering TA, then it can't cache (that's entailed by the rule the >way it's written here). If you really want, we could add another >sentence after CD=3D0 that says "That includes data unvalidated due to >want of a covering trust anchor." Still not correct. =20 If you have CD=3D1 data without a covering TA, you want to cache it, but not= return it to CD=3D0 queries (because there can be other CD=3D1 queries). = If you get a CD=3D0 query, you need to requery to allow any upstream= validation to take place. =20 If you have CD=3D0 data without a covering TA, you can return it to a CD=3D1= query. If you have a CD=3D0 SERVFAIL cached, you need to requery. >=20 My original text was: > Security aware intermediate resolvers SHOULD cache data returned > from an upstream (server side) query which had the CD bit set.=20 [Implication is that you don't have to cache CD=3D1 data if you don't want= to, but if you do you need to keep track] > If > the downstream (client side) query also has the CD bit set, the > resolver MAY defer validation of this data (assuming a covering TA) > until a later non-CD bit query for the same data, but MUST mark the > cached data as non-validated until local validation actually occurs. [This has language that says if you have a covering TA for the data, you can= validate and return it] And there was additional text that said: >Security aware intermediate resolvers SHOULD cache SERVFAIL responses= returned from an upstream query. They MUST cache the state of the CD bit in= all upstream queries as well. If a security aware intermediate resolvers= receives a query for data which has a SERVFAIL cached, but with the CD bit= set, the resolver MUST set the CD bit on the upstream query and cache BOTH= the SERVFAIL and the returned data. Data in cache with the CD bit set= which has not been locally validated MUST NOT be returned to a non-CD= query. If the cached data has the CD bit set it may be returned to a CD= query, and if a SERVFAIL is cached it may be returned to a non-CD query,= otherwise this should be treated as a cache miss and the query repeated= upstream." With a note that I might have missed corner cases. But this section goes= with the other and hopefully makes clear which data and which setting of= the CD bit. >> See above. QNAME + CD=3D1 is a different query than QNAME + CD=3D0. If >> you decide you don't want to cache CD=3D1 responses, then you can >> throw away that result - but part of the reason for having an >> intermediate resolver is to cache data and reduce upward queries. >>=20 > >The "see above" there clarifies nothing, since you then note that you >_could_ just not cache the result. I agree it'd be stupid, but we're >not the DNS intelligence police. We're here to specify what is >required for interoperation, and telling people how they have to >implement is not our job. > >I do not believe anyone disagrees with you that caches need to >differentiate between data that they got with CD=3D1 and data they got >with CD=3D0. I think the text proposed above makes that point, but I'd >be delighted if someone came up with something clearer. > >A >--=20 >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. --=====================_357174460==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 05:09 PM 6/8/2010, Andrew Sullivan wrote:
On Tue, Jun 08, 2010 at 04:33:19PM -0400, Michael StJohns wrote:

> There have been ample counter arguments.  But the counter arguments
> have not been persuasive.  They mostly just boil down to "I think I
> might possibly get better protection if I don't set the bit" - but
> have failed to explain how -absent specific configuration of the
> resolver to know - they would know such higher resolver could do a
> better job of validating.

Well, maybe they're planning to do that specific configuration.  I
don't know, neither do you, and we have existing text that permits
such operation.  This is not supposed to be a revision of DNSSECbis,
but a clarification of it.

DNSSEC is silent both on the setting of the CD bit in the upstream in this case AND on how you determine how to set it.  The fact that someone picked one and ran with it doesn't mean that is what we should document.  I do agree though that we should probably not prohibit that model of operation.



> BTW, I assume since you'= re citing your opinion, you're currently not
> wearing your chairmans hat?

On the contrary, I am acting as chair and ruling on what rough
consensus I think is possible.  We seem to have two sets of
strongly-held views here.  The documents we are trying to clarify
appear to allow either interpretation.  Your proposal is to close off
one interpretation; but I think that in the absence of strong
consensus (which we clearly do not have), it would be wrong to do so
in a document purporting to clarify something.  If this document does
not get immediate, "Yes, that's obviously what 403x meant" from
everyone, then it's not making a clarification.  Your proposed MUST
just doesn't meet that test.  Sorry.

 I really don't care about which MUST happens, I just insist that at least one of them does.  I've said this now in at least 3 messages - would you please move on?

And with respect to "consensus"  exactly how many people do you believe have expressed an opinion on this in the last go around?  I'll give you a hint, not counting you and me and the document editor, it was less than 2. And the document editor was mostly trying to find "simple" text.   Plus one side comment about multiple key types that was a clarification rather than taking a side.

> My complaint from the st= art with this text is that "may wish to set"
> is not standards language.  Each implementer will read this text
> differently.  And frankly, this text could be read as "a validator
> can randomly set the CD bit on all upstream queries"
 
I don't think that's allowed to begin with, and it sounds like an
enormous expansion of the scope of the problem here.  I'd like a
plausible reading of RFC 4035 =C2=A73.2.2 that says you can just do random
things with the CD bit. 

*sigh* Its not the plausible reading of 4035, its the plausible reading of the -11 bis.   "For efficiency" and "may set"  does not define the conditions under which the bit is set, does not define the default behavior, does not define the configuration options for non-default behavior, etc etc etc.  So "random" as a possible behavior is not excluded by 4035 and not by the text in -11.

Let me ask you - specifically.    Given the text of -11, how - EXACTLY - would you  set the CD bit in the upstream given a covering TA?   Please be specific and describe how your approach is what is meant by the current text.


If you say "operators choice" then I say, "what are the knobs and what's the default?".  If you say "implementers choice" then I say "what must all implementers do and how do I as an operator recover from a bad implemetation choice?"  If you say "it depends" then I say "ok, so what you're saying is that from the view point of a querier the result from sending a non-CD bit query to a validating resolver implementing your 'it depends' or 'may set' is a random setting of the bit since the querier has no predictable way of determining how the bit is set"

Pick one well defined approach that a querier can depend upon - I really don't care which at this point in time.  Make it the common default behavior for all resolvers.  Provide a mechanism to opt out of either of them. We're done.

I asked you to explain why standards language wasn't appropriate... let me ask that again. I've given you two different blurbs that describe both my desired option and the "don't set the bit by default" option.  Both of these also provide the escape valves to do the other thing.  Pick one  of mine, or explain why the current text is better and really does say what you think it does in a consistently implementable way.

The only problem, as I understood it, was the
interaction of all of this with a cache, and what to do in the case of
data in the cache that suggests issues.

Nope.  Two different issues. 

 That issue is stickier = in the
presence of intermediate caches and different security awarenesses,
but it's not actually made any different. Remember, we're clarifying
the previous RFCs, not replacing them.  We don't actually need to
restate everything in them.

Actually, the previous RFCs pretty obviously didn't consider what would happen if there were multiple cache/validators between authoritative and querier.  It wasn't an issue in non-DNSSEC with multiple caches, but validating caches are not passive repositories of data. 




> The argument is about whether or not you need to keep track of the
> validation/CD bit set status of cached data.  This basically says
> that if you're implementing a validating resolver, and you cache
> non-validated data (because the CD bit was set), you need to keep
> track of that status.  But it also says, its ok to *not* cache CD
> bit set data.

Your proposed text does not say that.  SHOULD is not "well, this'd be
a good idea".  It means that you'd better have a pretty good reason
why not.  That was why I suggested some modifications.  Moreover, it
wasn't clear to me whether it was supposed to have implications for
caching data with CD=3D0.

Actually it does.  It may not say it clearly enough, but that's what was meant. And if you read all three paragraphs of the text, it really does say that.

With respect to this - the normal rule is that if you cite one condition of data, you aren't actually saying anything about any other condition of data.  So if you need to clarify this doesn't apply to CD=3D0 data, feel free to add text.


> If you get a non-CD bit query, you can mostly answer from cache -
> but class 4 data will require being turned into class 5 or 6.  Class
> 7 will require a re-query.
>

I think everyone is in agreement about that, and all we're trying to
do is come up with text that is easy to understand. 



> >How about this:
> >
> >    When caching, a security-aware intermediate resolver MAY return
> >    data without validating it only if the original query had the CD
> >    bit set.
>
> I think not...  because the above can be read to say that its optional to return non-validated data if the CD bit is set and that particular item is non-optional.  It also doesn't cover the case where the resolver doesn't have a covering TA for the data.
>

Hrm, you're right about the MAY.  But we can fix that. 

   When caching, a security-aware intermediate resolver MAY return
   data without validating it only if the original query had the CD
   bit set.
 In that case, the intermediate resolver MAY defer
   validation of the data, but MUST mark the cached data as
   non-validated until local validation actually occurs.  It MUST NOT
   return the cached, unvalidated data to a query with CD=3D0.  As
   specfied in [RFC4035], Section 3.2.2, it SHOULD return the data,
   regardless of any validation, to a query with CD=3D1.

 


That's a little awkward, but = I still find it clearer than what you
proposed before.  The no-covering-TA is a red herring.  If the
intermediate resolver can't validate the data because it doesn't have
a covering TA, then it can't cache (that's entailed by the rule the
way it's written here).  If you really want, we could add another
sentence after CD=3D0 that says "That includes data unvalidated due to
want of a covering trust anchor."


Still not correct. 

If you have CD=3D1 data without a covering TA, you want to cache it, but not return it to CD=3D0 queries (because there can be other CD=3D1 queries).  If you get a CD=3D0 query, you need to requery to allow any upstream validation to take place. 

If you have CD=3D0 data without a covering TA, you can return it to a CD=3D1 query.

If you have a CD=3D0 SERVFAIL cached, you need to requery.

 

My original text was:

> Security aware intermediate resolvers SHOULD cache data returned
> from an upstream (server side) query which had the CD bit set.
[Implication is that you don't have to cache CD=3D1 data if you don't want to, but if you do you need to keep track]

> If
> the downstream (client side) query also has the CD bit set, the
> resolver MAY defer validation of this data (assuming a covering TA)
> until a later non-CD bit query for the same data, but MUST mark the
> cached data as non-validated until local validation actually occurs.

[This has language that says if you have a covering TA for the data, you can validate and return it]

And there was additional text that said:


Security aware intermediate resolvers SHOULD cache SERVFAIL responses returned from an upstream query. They MUST cache the state of the CD bit in all upstream queries as well.  If a security aware intermediate resolvers receives a query for data which has a SERVFAIL cached, but with the CD bit set, the resolver MUST set the CD bit on the upstream query and cache BOTH the SERVFAIL and the returned data.  Data in cache with the CD bit set which has not been locally validated MUST NOT be returned to a non-CD query.   If the cached data has the CD bit set it may be returned to a CD query, and if a SERVFAIL is cached it may be returned to a non-CD query, otherwise this should be treated as a cache miss and the query repeated upstream."


With a note that I might have missed corner cases.  But this section goes with the other and hopefully makes clear which data and which setting of the CD bit.

> See above.  QNAME + CD=3D1 is a different query than QNAME + CD=3D0.  If
> you decide you don't want to cache CD=3D1 responses, then you can
> throw away that result - but part of the reason for having an
> intermediate resolver is to cache data and reduce upward queries.
>

The "see above" there clarifies nothing, since you then note that you
_could_ just not cache the result.  I agree it'd be stupid, but we're
not the DNS intelligence police.  We're here to specify what is
required for interoperation, and telling people how they have to
implement is not our job.

I do not believe anyone disagrees with you that caches need to
differentiate between data that they got with CD=3D1 and data they got
with CD=3D0.  I think the text proposed above makes that point, but I'd
be delighted if someone came up with something clearer.

A
--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

--=====================_357174460==.ALT-- From owner-namedroppers@ops.ietf.org Wed Jun 9 06:29:46 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473B33A6837; Wed, 9 Jun 2010 06:29:46 -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.393, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy+GX79YSy7q; Wed, 9 Jun 2010 06:29:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 869083A6879; Wed, 9 Jun 2010 06:29:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMLHG-000EE9-KI for namedroppers-data0@psg.com; Wed, 09 Jun 2010 13:25:06 +0000 Received: from [89.16.176.221] (helo=mail.avalus.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMLHB-000ED7-RL for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 13:25:02 +0000 Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 3A542C5690E; Wed, 9 Jun 2010 14:25:00 +0100 (BST) Date: Wed, 09 Jun 2010 14:24:59 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Andrew Sullivan , namedroppers@ops.ietf.org cc: Alex Bligh Subject: Re: [dnsext] draft-registry-fixes terms question Message-ID: In-Reply-To: <20100609130605.GS62459@shinkuro.com> References: <20100607210544.GQ60255@shinkuro.com> <53A0D10D-36CD-4356-946A-E02777587FC6@nist.gov> <20100608190203.GK62459@shinkuro.com> <20100608195743.GM62459@shinkuro.com> <43CDAE1486E7AF74906A682E@Ximines.local> <20100608203346.GO62459@shinkuro.com> <3BD2874ED50BBAD37BCE9091@nimrod.local> <20100609130605.GS62459@shinkuro.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --On 9 June 2010 09:06:05 -0400 Andrew Sullivan wrote: >> change whether it is compliant with RFCnnnn. The way most RFCs >> behave as far as I could tell is the vendor's software in >> perpetuity is RFCnnnn compliant but not RFCrrrr compliant. > > Exactly right. And that's why we can't put the authority in the > registry, but must put the authoritative definition in some RFC. +1 - thanks for explaining to the hard of understanding. -- Alex Bligh From owner-namedroppers@ops.ietf.org Wed Jun 9 07:41:46 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C319428C0D0; Wed, 9 Jun 2010 07:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.688 X-Spam-Level: X-Spam-Status: No, score=-5.688 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud7AxTC9zh6A; Wed, 9 Jun 2010 07:41:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 88FA828C0EE; Wed, 9 Jun 2010 07:41:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMMNR-0000et-3V for namedroppers-data0@psg.com; Wed, 09 Jun 2010 14:35:33 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMMNN-0000eL-A3 for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 14:35:29 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1078) Subject: Re: [dnsext] RE: On adoption of two drafts ... From: Avri Doria In-Reply-To: Date: Wed, 9 Jun 2010 10:35:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> References: <201005191433.QAA13726@TR-Sys.de> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Hi, I have often tried to explain to people that the relationship between = labels and words is a happy coincidence and they should not count on it. Other then people who either have at least one foot in the IETF = environment and some old timers, almost no one accepts that and most = people I talk to think it is an absurd idea. The fact as Donald says, so many words and phrases do exist in the LDH = ASCII labels, i.e. there are many happy coincidences, has convinced = almost every non-latin as-a-first language speaker I know that they = should be able to have names that make sense in their script/languages = as words and phrases . So while it is fine to maintain the purity of 'labels are not words' in = the technical requirements, there should not be an expectation that the = users will necessarily find that a satisfactory solution. And, = possibly, allowing for as many happy coincidences as possible would be a = good thing. a. (mostly a lurker) On 4 Jun 2010, at 19:58, Donald Eastlake wrote: > Hi, >=20 > On Wed, May 19, 2010 at 10:33 AM, Alfred H=CEnes wrote: > Vaggelis Segredakis wrote: >=20 > > In the .gr ccTLD we have presented in 2005 the option of registering > > IDN domain names in Greek. The Greek language requires for all > > multi syllabus words to have an accent sign called "tonos" over > > one of the letters. [...] >=20 > Unfortunately, hereby we apparently are back at one of the greatest > ratholes ever seen in DNS internationalization. >=20 > Wasn't it one of the fundamental characteristics of the DNS that > DNS labels are _not_ "words" (in any language), but simply abstract > _identifiers_ in a more user friendly alphabet than IP addresses? >=20 > While the problem might appear to be "words", I would argue that it is = subtlety different from that. The problem might appear to be words, but = it is primarily script systems. >=20 > Users of a particular script system have expectations built up over a = lifetime of use. Users of the Roman script system expect that, much of = the time, there is little if any difference between upper and lower = case. >=20 > DNS could have been designed to ignore the expectations of users of = the Roman script system and been case sensitive. If so, there would be = much less pressure to provide accommodations for other script systems = (Greek, Arabic, Han, etc.) similar to its Roman case insensitivity. But, = because DNS accommodates the expectations of Roman script system users, = users of other script systems legitimately expect that they will also be = accommodated. >=20 > Thanks, > Donald > =20 >=20 > ... >=20 >=20 > Kind regards, > Alfred. >=20 > -- >=20 > = +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. = | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 = | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de = | > = +------------------------+--------------------------------------------+ >=20 From owner-namedroppers@ops.ietf.org Wed Jun 9 08:49:04 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B753A697F; Wed, 9 Jun 2010 08:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9ikwhlJ6J5a; Wed, 9 Jun 2010 08:49:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA5663A679F; Wed, 9 Jun 2010 08:49:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMNRB-000D0j-Fk for namedroppers-data0@psg.com; Wed, 09 Jun 2010 15:43:29 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMNR9-000D0N-2d for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 15:43:27 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id E2B8EA1042 for ; Wed, 9 Jun 2010 15:43:25 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: "namedroppers@ops.ietf.org" Subject: Re: [dnsext] CNAME and NXDOMAIN In-Reply-To: Your message of "Wed, 09 Jun 2010 08:54:58 GMT." <2C1227B4-3BCD-4CB0-84BD-030948876AAB@nominet.org.uk> References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> <20100608171340.GE62459@shinkuro.com> <4C0EA794.2080306@necom830.hpcl.titech.ac.jp> <4C0EB544.9080102@cisco.com> <4C0EC725.3010902@cisco.com> <4C0F5104.3070205@nlnetlabs.nl> <2C1227B4-3BCD-4CB0-84BD-030948876AAB@nominet.org.uk> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Wed, 09 Jun 2010 15:43:25 +0000 Message-ID: <22150.1276098205@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Ray Bellis > Date: Wed, 9 Jun 2010 08:54:58 +0000 > > > My best interpretation [at the current time] is that 1034 appears to > > say that for authoritative zones NOERROR is the strict interpretation > > and for recursive lookups (+RD flag) NXDOMAIN. > > For what it's worth, that's my interpretation too. strangely, i see what you mean, and if this were day 1 of DNS i could live with that interpretation. however, i think if we were to clarify it today we'd take account of the installed base. From owner-namedroppers@ops.ietf.org Wed Jun 9 09:13:58 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6324428C0F1; Wed, 9 Jun 2010 09:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.713 X-Spam-Level: ** X-Spam-Status: No, score=2.713 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSIx7s0TMKzy; Wed, 9 Jun 2010 09:13:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3EC1F3A697A; Wed, 9 Jun 2010 09:13:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMNrh-000HQB-EN for namedroppers-data0@psg.com; Wed, 09 Jun 2010 16:10:53 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMNra-000HPF-8h for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 16:10:46 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C29D61ECB408 for ; Wed, 9 Jun 2010 16:10:44 +0000 (UTC) Date: Wed, 9 Jun 2010 12:10:43 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] RE: On adoption of two drafts ... Message-ID: <20100609161042.GY62459@shinkuro.com> References: <201005191433.QAA13726@TR-Sys.de> <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Jun 09, 2010 at 10:35:28AM -0400, Avri Doria wrote: > Other then people who either have at least one foot in the IETF > environment and some old timers, almost no one accepts that and most > people I talk to think it is an absurd idea. [no hat] Well, not completely absurd, of course, if you point out both that nobody can register "can'twait.com" and that .com isn't a word anyway. People get that DNS labels aren't just words in English, in the normal sense. Most users aren't stupid: they understand that there are computerish rules that are different from English or French or Arabic, and that there are just going to be limits on what can be accommodated. But the DNS is, after all, designed to be useful to humans. Telling people with a Chinese keyboard that they have to write in ASCII is not as useful as it could be. "example.com" is a useful name for someone who speaks English, but is not dramatically better than "192.0.2.3" for a unilingual person whose language isn't written in Latin characters. [hat] All of that said, it would be most helpful if WG participants had a look at the recently-posted proposed charter, and chimed in with whether they think taking on this work for real, with the proposed schedule, is a good idea. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Jun 9 10:41:46 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DC03A6995; Wed, 9 Jun 2010 10:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.439 X-Spam-Level: * X-Spam-Status: No, score=1.439 tagged_above=-999 required=5 tests=[AWL=1.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2b9deNGDkVw4; Wed, 9 Jun 2010 10:41:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B6373A67B4; Wed, 9 Jun 2010 10:41:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMPCm-00048S-3h for namedroppers-data0@psg.com; Wed, 09 Jun 2010 17:36:44 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMPCj-00047h-BG for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 17:36:41 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2C9EF1ECB408 for ; Wed, 9 Jun 2010 17:36:40 +0000 (UTC) Date: Wed, 9 Jun 2010 13:36:38 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data Message-ID: <20100609173638.GC62459@shinkuro.com> References: <20100514195525.GL65855@shinkuro.com> <20100517143811.GA77756@shinkuro.com> <20100607212213.GR60255@shinkuro.com> <20100608210903.GP62459@shinkuro.com> <201006091311.o59DBvXk069700@stora.ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201006091311.o59DBvXk069700@stora.ogud.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Jun 08, 2010 at 06:22:23PM -0400, Michael StJohns wrote: > Nope. Two different issues. Ok, good, we have two issues, so I'm going to split continued discussion. See more follow-up in a minute. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Jun 9 11:32:17 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233D03A6768; Wed, 9 Jun 2010 11:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.652 X-Spam-Level: ** X-Spam-Status: No, score=2.652 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOyQuAXP45pW; Wed, 9 Jun 2010 11:32:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E7FF3A659A; Wed, 9 Jun 2010 11:32:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMQ11-000Cm7-8y for namedroppers-data0@psg.com; Wed, 09 Jun 2010 18:28:39 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMQ0x-000Clm-Of for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 18:28:36 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8F17F1ECB408 for ; Wed, 9 Jun 2010 18:28:34 +0000 (UTC) Date: Wed, 9 Jun 2010 14:28:32 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data Message-ID: <20100609182832.GD62459@shinkuro.com> References: <20100514195525.GL65855@shinkuro.com> <20100517143811.GA77756@shinkuro.com> <20100607212213.GR60255@shinkuro.com> <20100608210903.GP62459@shinkuro.com> <201006091311.o59DBvXk069700@stora.ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201006091311.o59DBvXk069700@stora.ogud.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, On Tue, Jun 08, 2010 at 06:22:23PM -0400, Michael StJohns wrote: > Actually it does. It may not say it clearly enough, but that's what > was meant. And if you read all three paragraphs of the text, it > really does say that. So since we're in agreement that we need text here, and since at least one person (me) doesn't understand your proposed text without re-reading it four or five times, I think we need different text. Let's try again. I'm going to be verbose to start with, and then maybe we can whittle down if we can all agree. A security-aware recursive name server might receive queries either with CD=1 or with CD=0. In addition, it might have cached data that is the result of a query made with CD=1 or CD=0. A general rule is that each cache entry MUST include some indication of whether it came from a query performed with CD=1 or with CD=0, or else that all cache entries MUST be treated as though they were performed with CD=0. This rule prevents data that does not validate, but that may be cached to respond to CD=1 queries, from being returned in response to a query with CD=0. When returning data for a query with CD=1, a validating intermediate resolver MAY return data without validating. It MUST NOT return data without validating to a query with CD=0. This applies both to data that is available from cache, and to data that must first be fetched before returning it. A validating resolver MAY cache unvalidated data, and even data that cannot be validated due to lack of a covering trust anchor, in order to respond to queries with CD=1. Such cached data MUST NOT be used to respond to queries with CD=0. If the validating resolver subsequently validates that cached data, then it MAY use it to respond to queries with CD=0. If a validating resolver has a cached response of RCODE=2 (server failure), and then receives a query with CD=1 to its name server side, then it SHOULD [Note 1] perform the query again with CD=1 from its resolver side. The result of that query is returned to the query received on the name server side. If the resolver is able to validate the answer, then it MAY replace the cached RCODE=2 response. Otherwise, it MUST either leave the existing cached response alone, or cache both responses along with an indicator of the CD bit setting that engendered them. * Note 1: 4035 section 3.2.2 uses SHOULD for responding with all the data to CD=1, so I am pretty sure anything stronger than SHOULD would be a protocol change. I think that covers everything we have discussed on this topic. I'm not at all sure that this sets all the rules according to the way people currently want them to be set, but at least it's broken into one paragraph per case so that we can change specifically the text there. So have at it, please. More participants would be good. Thanks, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Jun 9 11:39:20 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF383A6767; Wed, 9 Jun 2010 11:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sj0ER-54v3bk; Wed, 9 Jun 2010 11:39:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 67B8A3A676A; Wed, 9 Jun 2010 11:39:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMQ8o-000Dtu-Ci for namedroppers-data0@psg.com; Wed, 09 Jun 2010 18:36:42 +0000 Received: from [209.86.89.63] (helo=elasmtp-junco.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMQ8k-000DtW-J8 for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 18:36:38 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=na0iIqf+VbX7IIQeHcB40P4T7ubDkb/z6/DHhDFJ1taxOh9k2joBIjZBmjCcKO++; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OMQ8i-0007O7-Ps; Wed, 09 Jun 2010 14:36:36 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 9 Jun 2010 14:36:36 -0400 Message-ID: <3495101.1276108596720.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Wed, 9 Jun 2010 13:36:36 -0500 (GMT-05:00) From: "Jeffrey A. Williams" Reply-To: "Jeffrey A. Williams" To: Andrew Sullivan , namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068853eb43aaa54682d84077179abbd42a41350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Andrew and all, Good point. But doesn't all this really revolve around or more accurately 'Depend' on the trusting of the 'covering trust anchor'? Seems to me it does. Please advise. If my assumption here is correct, than what is or are the mechnisims for ensuring that the relevent 'covering trust anchor' is indeed 'trustworthy'? -----Original Message----- >From: Andrew Sullivan >Sent: Jun 9, 2010 1:28 PM >To: namedroppers@ops.ietf.org >Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data > >Dear colleagues, > >On Tue, Jun 08, 2010 at 06:22:23PM -0400, Michael StJohns wrote: > >> Actually it does. It may not say it clearly enough, but that's what >> was meant. And if you read all three paragraphs of the text, it >> really does say that. > >So since we're in agreement that we need text here, and since at least >one person (me) doesn't understand your proposed text without >re-reading it four or five times, I think we need different text. >Let's try again. I'm going to be verbose to start with, and then >maybe we can whittle down if we can all agree. > > A security-aware recursive name server might receive queries either > with CD=1 or with CD=0. In addition, it might have cached data that > is the result of a query made with CD=1 or CD=0. > > A general rule is that each cache entry MUST include some > indication of whether it came from a query performed with CD=1 or > with CD=0, or else that all cache entries MUST be treated as > though they were performed with CD=0. This rule prevents data > that does not validate, but that may be cached to respond to CD=1 > queries, from being returned in response to a query with CD=0. > > When returning data for a query with CD=1, a validating > intermediate resolver MAY return data without validating. It MUST > NOT return data without validating to a query with CD=0. This > applies both to data that is available from cache, and to data > that must first be fetched before returning it. > > A validating resolver MAY cache unvalidated data, and even data > that cannot be validated due to lack of a covering trust anchor, > in order to respond to queries with CD=1. Such cached data MUST > NOT be used to respond to queries with CD=0. If the validating > resolver subsequently validates that cached data, then it MAY use > it to respond to queries with CD=0. > > If a validating resolver has a cached response of RCODE=2 (server > failure), and then receives a query with CD=1 to its name server > side, then it SHOULD [Note 1] perform the query again with CD=1 > from its resolver side. The result of that query is returned to > the query received on the name server side. If the resolver is > able to validate the answer, then it MAY replace the cached > RCODE=2 response. Otherwise, it MUST either leave the existing > cached response alone, or cache both responses along with an > indicator of the CD bit setting that engendered them. > >* Note 1: 4035 section 3.2.2 uses SHOULD for responding with all the >data to CD=1, so I am pretty sure anything stronger than SHOULD would >be a protocol change. > >I think that covers everything we have discussed on this topic. I'm >not at all sure that this sets all the rules according to the way >people currently want them to be set, but at least it's broken into >one paragraph per case so that we can change specifically the text >there. So have at it, please. More participants would be good. > >Thanks, > >A > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. > Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300+k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From owner-namedroppers@ops.ietf.org Wed Jun 9 11:53:37 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3274A3A6783; Wed, 9 Jun 2010 11:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.309 X-Spam-Level: ** X-Spam-Status: No, score=2.309 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxWpRYIhfnc1; Wed, 9 Jun 2010 11:53:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 68A4A3A676A; Wed, 9 Jun 2010 11:53:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMQMq-000G9L-2m for namedroppers-data0@psg.com; Wed, 09 Jun 2010 18:51:12 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMQMn-000G8k-22 for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 18:51:09 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0C6211ECB408 for ; Wed, 9 Jun 2010 18:51:08 +0000 (UTC) Date: Wed, 9 Jun 2010 14:51:06 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data Message-ID: <20100609185106.GF62459@shinkuro.com> References: <3495101.1276108596720.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3495101.1276108596720.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Jun 09, 2010 at 01:36:36PM -0500, Jeffrey A. Williams wrote: > Good point. But doesn't all this really revolve around > or more accurately 'Depend' on the trusting of the > 'covering trust anchor'? Seems to me it does. Please > advise. If my assumption here is correct, than what > is or are the mechnisims for ensuring that the relevent > 'covering trust anchor' is indeed 'trustworthy'? That is completely irrelevant to this discussion. The DNSSEC documents already note that obtaining a trust anchor is out-of-protocol. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Jun 9 11:54:51 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46C93A67A5; Wed, 9 Jun 2010 11:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.676 X-Spam-Level: ** X-Spam-Status: No, score=2.676 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTOO8FS+wyUh; Wed, 9 Jun 2010 11:54:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D3D1F3A6783; Wed, 9 Jun 2010 11:54:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMQIu-000FT6-4t for namedroppers-data0@psg.com; Wed, 09 Jun 2010 18:47:08 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMQIq-000FSJ-MI for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 18:47:04 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 026811ECB408 for ; Wed, 9 Jun 2010 18:47:02 +0000 (UTC) Date: Wed, 9 Jun 2010 14:47:01 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: On MUST and the CD bit (was: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data) Message-ID: <20100609184700.GE62459@shinkuro.com> References: <20100514195525.GL65855@shinkuro.com> <20100517143811.GA77756@shinkuro.com> <20100607212213.GR60255@shinkuro.com> <20100608210903.GP62459@shinkuro.com> <201006091311.o59DBvXk069700@stora.ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201006091311.o59DBvXk069700@stora.ogud.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Tue, Jun 08, 2010 at 06:22:23PM -0400, Michael StJohns wrote: > > DNSSEC is silent both on the setting of the CD bit in the upstream > in this case AND on how you determine how to set it. The fact that > someone picked one and ran with it doesn't mean that is what we > should document. I do agree though that we should probably not > prohibit that model of operation. What case exactly are we talking about now? I am confused (even more than usual). RFC 4035 Section 3.2.2 says this: The CD bit exists in order to allow a security-aware resolver to disable signature validation in a security-aware name server's processing of a particular query. The name server side MUST copy the setting of the CD bit from a query to the corresponding response. The name server side of a security-aware recursive name server MUST pass the state of the CD bit to the resolver side along with the rest of an initiating query, so that the resolver side will know whether it is required to verify the response data it returns to the name server side. If the CD bit is set, it indicates that the originating resolver is willing to perform whatever authentication its local policy requires. Thus, the resolver side of the recursive name server need not perform authentication on the RRsets in the response. When the CD bit is set, the recursive name server SHOULD, if possible, return the requested data to the originating resolver, even if the recursive name server's local authentication policy would reject the records in question. That is, by setting the CD bit, the originating resolver has indicated that it takes responsibility for performing its own authentication, and the recursive name server should not interfere. Is your complaint that a poor implementation could take the above to mean that the resolver side of a recursive name server could set CD=0 even though it knows that the name server side got CD=1? I thought that was covered by the text in the draft, section 5.9, that says When processing a request with the CD bit set, a resolver SHOULD attempt to return all responsive data, even data that has failed DNSSEC validation. RFC4035 section 3.2.2 requires a resolver processing a request with the CD bit set to set the CD bit on its upstream queries. Right? If instead what you are trying to insist upon is some rule about what an originating client has to/ough to do with the CD bit when it has a TA covering a query (which seemed to be your focus in, e.g., http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg01397.html), I see very little support in the long history of this discussion for that insistence. I also don't see why the protocol needs to say anything about this: it seems to me to be a purely local policy, and one that could be sensitive to local conditions. I've read, repeatedly, your assertions that your view is the most reasonable, and while I think it is an entirely reasonable thing to do, I do not believe the protocol is designed to require this. So on top of everything else, it seems to me that what you are demanding is a protocol change, and I don't think this document is the place to make that change. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Jun 9 12:14:53 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795163A684E; Wed, 9 Jun 2010 12:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.273 X-Spam-Level: X-Spam-Status: No, score=-97.273 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtVrWhVsz-ms; Wed, 9 Jun 2010 12:14:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 013B33A6818; Wed, 9 Jun 2010 12:14:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMQg3-000JbT-BM for namedroppers-data0@psg.com; Wed, 09 Jun 2010 19:11:03 +0000 Received: from [74.125.121.35] (helo=smtp-out.google.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMQfv-000JYk-L0 for namedroppers@ops.ietf.org; Wed, 09 Jun 2010 19:10:56 +0000 Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o59JAqEr002264 for ; Wed, 9 Jun 2010 12:10:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276110652; bh=LT27WBnXkN00tpL4WzmN7gTWiT4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=TJwmZhQxRPp11LYEc4R7030rTveHBdloYfFIykbWIEsd6qTrHlJ/QPna60SX+utih HYLZabhTZn87lZgaW5sKQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type; b=N/lYFhKg8pWDNHPB533DBBKFp3XBzyvXxqbnGB1+XMfqtt/DV8TJ9BRpfqc/s3IpS 9VxWzXpGEQxSh/QEQmq2g== Received: from ewy7 (ewy7.prod.google.com [10.241.103.7]) by hpaq5.eem.corp.google.com with ESMTP id o59JAokO012133 for ; Wed, 9 Jun 2010 12:10:51 -0700 Received: by ewy7 with SMTP id 7so1420930ewy.31 for ; Wed, 09 Jun 2010 12:10:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.113.193 with SMTP id b1mr1706566ebq.13.1276110648516; Wed, 09 Jun 2010 12:10:48 -0700 (PDT) Received: by 10.213.15.15 with HTTP; Wed, 9 Jun 2010 12:10:48 -0700 (PDT) In-Reply-To: <4C072248.3010803@dougbarton.us> References: <65889.1275065433@nsa.vix.com> <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <77BB02E3-1F2D-4007-B8A4-EE7FDE44EF51@rfc1035.com> <4C072248.3010803@dougbarton.us> Date: Wed, 9 Jun 2010 20:10:48 +0100 Message-ID: Subject: Re: [dnsext] end-to-end violations in draft-vandergaast-edns-client-ip-01 From: Wilmer van der Gaast To: Doug Barton Cc: David Ulevitch , IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 3 June 2010 04:32, Doug Barton wrote: > > And I'm not sure why you're confused. The common case is Janet User sits on > one of N subnets of BigISP, her DNS queries are directed to BigISP's > resolver which queries the authoritative servers for CoolWebPages.com and > sends back the answer. At no point do the packets going from the resolver to > the authoritative servers and back again have any information about Janet. > And at no point will they. First of all, it's the question if BigISP is going to configure their resolvers to add edns-client-subnet options, even though it's primarily targeted at open resolvers. Second of all, if they do, the only information they will add is three bytes of network address information. Not Janet's full external IP address. Now there's indeed a possibility that BigISP has a huge network with lots of peering points but only a few DNS server pools, and maybe because of that they *are* using edns-client-subnet. In that case, they know pretty well what their network looks like and can truncate the network address information to something bigger than a /24. Maybe they know that all of 192.0.32/20 is in the same city, in which case there's no need to send a full /24 (and it's in their and their cache's advantage to not do that then). In some version of the draft we had a recommendation like this included, but it's not currently there. We can definitely add that. Regards, -- Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From owner-namedroppers@ops.ietf.org Wed Jun 9 17:36:39 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6393A67D4; Wed, 9 Jun 2010 17:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.451 X-Spam-Level: *** X-Spam-Status: No, score=3.451 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuaP3lbdLo5W; Wed, 9 Jun 2010 17:36:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 876263A6875; Wed, 9 Jun 2010 17:36:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMVd8-0005lS-2y for namedroppers-data0@psg.com; Thu, 10 Jun 2010 00:28:22 +0000 Message-Id: Received: from [76.96.62.40] (helo=qmta04.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMVd2-0005lA-KS for namedroppers@ops.ietf.org; Thu, 10 Jun 2010 00:28:17 +0000 Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta04.westchester.pa.mail.comcast.net with comcast id TpWG1e00C1c6gX8540UHd7; Thu, 10 Jun 2010 00:28:17 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta23.westchester.pa.mail.comcast.net with comcast id U0UG1e0011EtFYL3j0UGa1; Thu, 10 Jun 2010 00:28:17 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 09 Jun 2010 20:28:04 -0400 To: Andrew Sullivan ,namedroppers@ops.ietf.org From: Michael StJohns Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data In-Reply-To: <20100609182832.GD62459@shinkuro.com> References: <20100514195525.GL65855@shinkuro.com> <20100517143811.GA77756@shinkuro.com> <20100607212213.GR60255@shinkuro.com> <20100608210903.GP62459@shinkuro.com> <201006091311.o59DBvXk069700@stora.ogud.com> <20100609182832.GD62459@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 02:28 PM 6/9/2010, Andrew Sullivan wrote: >Dear colleagues, > >On Tue, Jun 08, 2010 at 06:22:23PM -0400, Michael StJohns wrote: > >> Actually it does. It may not say it clearly enough, but that's what >> was meant. And if you read all three paragraphs of the text, it >> really does say that. > >So since we're in agreement that we need text here, and since at least >one person (me) doesn't understand your proposed text without >re-reading it four or five times, I think we need different text. >Let's try again. I'm going to be verbose to start with, and then >maybe we can whittle down if we can all agree. > > A security-aware recursive name server might receive queries either > with CD=1 or with CD=0. In addition, it might have cached data that > is the result of a query made with CD=1 or CD=0. Yup. > A general rule is that each cache entry MUST include some > indication of whether it came from a query performed with CD=1 or > with CD=0, or else that all cache entries MUST be treated as > though they were performed with CD=0. This rule prevents data > that does not validate, but that may be cached to respond to CD=1 > queries, from being returned in response to a query with CD=0. > > When returning data for a query with CD=1, a validating > intermediate resolver >MAY return data without validating. It MUST return the data regardless of validation state. If there is a local covering TA, the resolver MAY defer validation unless and until it receives a CD=0 query. > It MUST > NOT return data without validating to a query with CD=0. It MUST NOT return data covered by a TA to a query with CD=0 unless it has been locally validated. > This > applies both to data that is available from cache, and to data > that must first be fetched before returning it. > A validating resolver MAY cache unvalidated data, and even data > that cannot be validated due to lack of a covering trust anchor, > in order to respond to queries with CD=1. Such cached data MUST > NOT be used to respond to queries with CD=0. No - if you don't have a covering TA, you have to pass it on. You have no way of validating it. Or how would you decide whether or not to pass it on? > If the validating > resolver subsequently validates that cached data, then it MAY use > it to respond to queries with CD=0. Yep, but covered in my restatement above > If a validating resolver has a cached response of RCODE=2 (server > failure), and then receives a query with CD=1 to its name server > side, then it SHOULD [Note 1] perform the query again with CD=1 > from its resolver side. Why SHOULD? If I don't then I have to return the SERVFAIL to the querier which really seems wrong for a CD=1 query. I believe this is MUST. 4035 was wrong. 4033 has the philosophy for the CD bit and 4035 is out of step with it. the CD bit is the escape mechanism to bypass a resolver that may not actually know why you're asking the question. > The result of that query is returned to > the query received on the name server side. If the resolver is > able to validate the answer, then it MAY replace the cached > RCODE=2 response. Otherwise, it MUST either leave the existing > cached response alone, or cache both responses along with an > indicator of the CD bit setting that engendered them. Yup. >* Note 1: 4035 section 3.2.2 uses SHOULD for responding with all the >data to CD=1, so I am pretty sure anything stronger than SHOULD would >be a protocol change. Nope, its a resolver behavior change - it doesn't change the meaning of the bits on the wire, just the processing rules. And seriously, 4035 section 3.2.2 is pretty poorly written - it doesn't even say to set the CD bit in the upstream query. It just says to pass the state of the CD bit to the resolver side.... And if you want to stick with SHOULD, you need to add the conditions for which not doing this is reasonable. Does any validating resolver implementation use the SHOULD escape clause? E.g. doesn't pass on non-validated data to a CD=1 query? If not, then changing this to a MUST has no affect on the Internet. >I think that covers everything we have discussed on this topic. I'm >not at all sure that this sets all the rules according to the way >people currently want them to be set, but at least it's broken into >one paragraph per case so that we can change specifically the text >there. So have at it, please. More participants would be good. > >Thanks, > >A > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Jun 9 18:31:34 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E863A69CD; Wed, 9 Jun 2010 18:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Uecr-oXN5h7; Wed, 9 Jun 2010 18:31:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 39EDC3A69C6; Wed, 9 Jun 2010 18:31:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMWYe-000ByN-IG for namedroppers-data0@psg.com; Thu, 10 Jun 2010 01:27:48 +0000 Received: from [2001:4f8:3:bb::5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMWYa-000Bxv-Pm for namedroppers@ops.ietf.org; Thu, 10 Jun 2010 01:27:44 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id EC587EED4B; Thu, 10 Jun 2010 01:27:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o5A1Re4a072842; Thu, 10 Jun 2010 11:27:40 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201006100127.o5A1Re4a072842@drugs.dv.isc.org> To: Andrew Sullivan Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <20100514195525.GL65855@shinkuro.com> <20100517143811.GA77756@shinkuro.com> <20100607212213.GR60255@shinkuro.com> <20100608210903.GP62459@shinkuro.com> <201006091311.o59DBvXk069700@stora.ogud.com> <20100609182832.GD62459@shinkuro.com> Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data In-reply-to: Your message of "Wed, 09 Jun 2010 14:28:32 -0400." <20100609182832.GD62459@shinkuro.com> Date: Thu, 10 Jun 2010 11:27:40 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DNSSEC works well in iterative resolvers because the resolver can ask the validator "is this answer good" and discard it if it isn't and move onto the next server / wait for the correct answer. DNSSEC works well in stub resolvers if the caching servers in use have the same trust anchors. The caching servers reject the bad answers supposedly from the authoritative servers and the stub basically check that the answer was not tampered with between the cache and the stub. Trying it get disjoint sets of trust anchors to work in series requires a lot more state to be shipped back and forth between clients and servers to allow the upstream to know that the previous responses were bad and to try different sources. CD basically helps when the clocks are wrong or when you want to debug as it allows you to see what the validator is seeing. It can't fix the disjoint sets of trust anchors problem. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Wed Jun 9 18:33:14 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84113A69C3; Wed, 9 Jun 2010 18:33:14 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.644 X-Spam-Level: ** X-Spam-Status: No, score=2.644 tagged_above=-999 required=5 tests=[AWL=-1.820, BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db+RlqQl8z8x; Wed, 9 Jun 2010 18:33:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D78F23A69CE; Wed, 9 Jun 2010 18:33:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMWZx-000C6x-Rv for namedroppers-data0@psg.com; Thu, 10 Jun 2010 01:29:09 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMWZt-000C69-4u for namedroppers@ops.ietf.org; Thu, 10 Jun 2010 01:29:05 +0000 Received: (eyou send program); Thu, 10 Jun 2010 09:29:01 +0800 Message-ID: <476133341.17470@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 10 Jun 2010 09:29:01 +0800 Message-ID: <62F86A4CEB184F9D88DB790FC1946E0F@LENOVO47E041CF> From: "Jiankang YAO" To: "Avri Doria" , References: <201005191433.QAA13726@TR-Sys.de> <476095260.18305@cnnic.cn> <476132568.17470@cnnic.cn> Subject: Re: [dnsext] RE: On adoption of two drafts ... Date: Thu, 10 Jun 2010 09:29:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+IEZyb206ICJBdnJpIERvcmlhIiA8 YXZyaUBwc2cuY29tPg0KPiBUbzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQo+IFNlbnQ6 IFdlZG5lc2RheSwgSnVuZSAwOSwgMjAxMCAxMDozNSBQTQ0KPiBTdWJqZWN0OiBSZTogW2Ruc2V4 dF0gUkU6IE9uIGFkb3B0aW9uIG9mIHR3byBkcmFmdHMgLi4uDQo+IA0KPiANCj4gSGksDQo+IA0K PiBJIGhhdmUgb2Z0ZW4gdHJpZWQgdG8gZXhwbGFpbiB0byBwZW9wbGUgdGhhdCB0aGUgcmVsYXRp b25zaGlwIGJldHdlZW4gbGFiZWxzIGFuZCB3b3JkcyBpcyBhIGhhcHB5IGNvaW5jaWRlbmNlIGFu ZCB0aGV5IHNob3VsZCBub3QgY291bnQgb24gaXQuDQo+IA0KDQogaW4gLmNvbSByZWdpc3RyeSwg dGhlcmUgYXJlIG1pbGxpb25zIG9mIGRvbWFpbiBuYW1lcyBhbmQgbWFueSBvZiBsYWJlbHMgYXJl IHdvcmRzLg0KDQpob3cgbWFueSB3b3JkcyBhcmUgdGhlcmUgaW4gdGhlIGVuZ2xpc2g/IElmIHRo ZXJlIGFyZSBhIG1pbGxvbiB3b3JkcyBpbiB0aGUgZW5nbGlzaCwgSSBiZXQgdGhhdCAgOTAlIG9m IHRoZW0gY2FuIGJlIHVzZWQgYXMgRE5TIGxhYmVscy4NCg0Kc28gdGhlIHJlbGF0aW9uc2hpcCBi ZXR3ZWVuIGxhYmVzbCBhbmQgd29yZCBhcmUgbm90IGNvaW5jaWRlbmNlIHNpbmNlIHRoZSAgcGVy Y2VudGFnZSBpcyBzbyBoaWdoLg0KDQpzbyB5b3VyIHN0YXRlbWVudCAidGhlIHJlbGF0aW9uc2hp cCBiZXR3ZWVuIGxhYmVscyBhbmQgd29yZHMgaXMgYSBoYXBweSBjb2luY2lkZW5jZSBhbmQgdGhl eSBzaG91bGQgbm90IGNvdW50IG9uIGl0LiIgDQoNCnNob3VsZCBiZSBjaGFuZ2VkIHRvICJ0aGUg Tk9OLXJlbGF0aW9uc2hpcCBiZXR3ZWVuIGxhYmVscyBhbmQgd29yZHMgaXMgYSBoYXBweSBjb2lu Y2lkZW5jZSBhbmQgdGhleSBzaG91bGQgbm90IGNvdW50IG9uIGl0LiINCg0KDQo+DQo+IE90aGVy IHRoZW4gcGVvcGxlIHdobyBlaXRoZXIgaGF2ZSBhdCBsZWFzdCBvbmUgZm9vdCBpbiB0aGUgSUVU RiBlbnZpcm9ubWVudCBhbmQgc29tZSBvbGQgdGltZXJzLCBhbG1vc3Qgbm8gb25lIGFjY2VwdHMg dGhhdCBhbmQgbW9zdCBwZW9wbGUgSSB0YWxrIHRvIHRoaW5rIGl0ID5pcyBhbiBhYnN1cmQgaWRl YS4NCj4NCg0KbWF5YmUgLCB5b3Ugb25seSBzcGVhayB0byB0aGUgcGVvcGxlIHdob3NlIG5hdGl2 ZSBsYW5ndWFnZSBpcyBlbmdsaXNoLg0KDQogDQo= From owner-namedroppers@ops.ietf.org Wed Jun 9 19:04:37 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466B43A6867; Wed, 9 Jun 2010 19:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.705 X-Spam-Level: ** X-Spam-Status: No, score=2.705 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_55=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfh2VRL8VuDO; Wed, 9 Jun 2010 19:04:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0845D3A6844; Wed, 9 Jun 2010 19:04:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMX20-000F8R-Hs for namedroppers-data0@psg.com; Thu, 10 Jun 2010 01:58:08 +0000 Received: from [38.229.66.8] (helo=obelisk11.ord01.cymru.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMX1w-000F7y-EN for namedroppers@ops.ietf.org; Thu, 10 Jun 2010 01:58:04 +0000 Received: from t61p (vpn-21-33.svcs.iad01.cymru.com [192.168.21.33]) by obelisk11.ord01.cymru.com (Postfix) with ESMTP id 73F11B00CE; Thu, 10 Jun 2010 01:58:03 +0000 (GMT) Date: Wed, 9 Jun 2010 20:58:02 -0500 From: John Kristoff To: Wilmer van der Gaast Cc: IETF DNSEXT WG , Carlo Contavalli , Sean Leach , "Rodden, Darryl" Subject: Re: [dnsext] Re: draft-vandergaast-edns-client-ip-01 Message-ID: <20100609205802.257d154d@t61p> In-Reply-To: References: X-Mailer: Claws Mail Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, 28 May 2010 12:40:45 +0100 Wilmer van der Gaast wrote: > Does nobody have any comments on this draft? We've tried to address as > many of the concerns brought up in the discussion on -00 and would > like to know if the WG is more in favour of this new version. After having read through this version as carefully as I could, I have a number of comments. I offer no specific support or opposition to the specification at this time. Just comments. I noticed the change of intended status from Standards Track to Experimental. I now think this specification could potentially result in a significant architectural change for the domain name system as Paul originally tried to impress upon the group. However, my reasoning differs than what I saw Paul say. The significant change I see is in the caching. This proposal severely alters how resolvers do caching, This is not something anticipated by the original DNS specifications. This proposal would have caches perform similar work similar to routers (route table lookup and maintenance). It might even be argued that resolvers would have to implement a form of uRPF for queries that forge the edns-client-subnet ADDRESS field. I can elaborate further if my reasoning is not entirely clear. There is no discussion of authoritative server consistency. Should each NS in the set for a zone provide consistent answers for the same edns-client-subnet detail? I would assume the answer is yes. For any particular qname,class,type tuple does the TTL need to be consistent no matter the edns-client-subnet detail? I would think not. I propose that if the SOURCE NETMASK field is set to zero in a query, the resolver is indicating it is providing the ADDRESS for informational purposes only and will not cache the answer based on ends-client-subnet specific detail. Therefore, the server should give back the most appropriate answer, as it would if ends-client-subnet option was not in use. It would be valuable to offer the edns-client-subnet detail in many circumstances (e.g. troubleshooting, measurement, auditing), but desirable not to have to support edns-client-subnet based caching. In section 4.1, its stated that an intermediate name server must not modify the edns-client-subnet option if already present. Later there is discussion in section 7 about NAT considerations, where this is reiterated and that special awareness of NAT is not required. In addition its stated that recursive resolvers behind NAT must not add their external address. ends-client-subnet capable resolvers might not know they are behind a NAT. How are they to know. I believe you will need special awareness for this option. On a related note, in section 8.3, its suggested that authoritative name servers and recursive resolvers should ignore unroutable addresses. Rather than reference RFC 1918, perhaps reference RFC 5735 and change the word from "including the ones defined in" to "such as some address blocks defined in". To expand on the cache pollution attack in 8.3, an intermediate resolver that is receiving spoofed IP addresses, spoofed edns-client-subnet address detail or both not only has to deal with cache pollution, but perhaps more importantly has to deal with the additional resolution workload it needs to perform. Technically this is a problem even without edns-client-subnet, but may be worth mentioning. I'd like to restate my prior comment about cache enumeration. I did not see discussion on it or consideration for it in the updated draft. Maybe its not a big deal, but might be at least worthy of a mention. Today, resolvers will generally report what is in there cache for anyone is permitted to ask, but with edns-client-subnet they not only share what they have cached, but who its cached for. The example detailed in Section 9 is problematic. Does R need to consult http://publicsuffix.org now to determine what a TLD is? Why not just include the option anyway? If this is really something people might want to do, maybe roots and TLDs want to be able to make use of it too. Including the option from the root on down would just be simpler. In the same section, step 4 is imprecise. R won't technically know the authoritative name server until it actually gets an answer. John From owner-namedroppers@ops.ietf.org Wed Jun 9 19:25:17 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F65D3A681F; Wed, 9 Jun 2010 19:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeWM7tYrHgrA; Wed, 9 Jun 2010 19:25:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1CCC28C0ED; Wed, 9 Jun 2010 19:25:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMXOk-000Hbj-0T for namedroppers-data0@psg.com; Thu, 10 Jun 2010 02:21:38 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMXOh-000Hb9-6Y for namedroppers@ops.ietf.org; Thu, 10 Jun 2010 02:21:35 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id CB909A1021 for ; Thu, 10 Jun 2010 02:21:33 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] RE: On adoption of two drafts ... In-Reply-To: Your message of "Thu, 10 Jun 2010 09:29:17 +0800." <476133341.17470@cnnic.cn> <62F86A4CEB184F9D88DB790FC1946E0F@LENOVO47E041CF> References: <201005191433.QAA13726@TR-Sys.de> <476095260.18305@cnnic.cn> <476132568.17470@cnnic.cn> <476133341.17470@cnnic.cn> <62F86A4CEB184F9D88DB790FC1946E0F@LENOVO47E041CF> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Thu, 10 Jun 2010 02:21:33 +0000 Message-ID: <59063.1276136493@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: "Jiankang YAO" > Date: Thu, 10 Jun 2010 09:29:17 +0800 > ... > so your statement "the relationship between labels and words is a happy > coincidence and they should not count on it." > > should be changed to "the NON-relationship between labels and words is a > happy coincidence and they should not count on it." +1. From owner-namedroppers@ops.ietf.org Thu Jun 10 02:00:12 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3003A68F6; Thu, 10 Jun 2010 02:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h5t3p5BEkoh; Thu, 10 Jun 2010 02:00:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5607D3A68C5; Thu, 10 Jun 2010 02:00:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMdVT-000IQ3-8g for namedroppers-data0@psg.com; Thu, 10 Jun 2010 08:52:59 +0000 Received: from [139.91.1.2] (helo=mailgate.ics.forth.gr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMdVO-000IO3-Jk for namedroppers@ops.ietf.org; Thu, 10 Jun 2010 08:52:55 +0000 Received: from av1.ics.forth.gr ([139.91.157.71]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id o5A8qm0c003364; Thu, 10 Jun 2010 11:52:51 +0300 (EEST) X-AuditID: 8b5b9d47-b7c08ae000006cb4-09-4c10a7e31e04 Received: from enigma.ics.forth.gr (webmail.ics.forth.gr [139.91.1.30]) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id 64.B7.27828.3E7A01C4; Thu, 10 Jun 2010 11:52:51 +0300 (EEST) Received: from Thanatos (thanatos.ics.forth.gr [139.91.88.160]) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id o5A8qnCn028749 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 10 Jun 2010 11:52:50 +0300 From: "Vaggelis Segredakis" To: "'Andrew Sullivan'" , References: <201005191433.QAA13726@TR-Sys.de> <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> <20100609161042.GY62459@shinkuro.com> Subject: RE: [dnsext] RE: On adoption of two drafts ... Date: Thu, 10 Jun 2010 11:52:30 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <20100609161042.GY62459@shinkuro.com> Thread-Index: AcsH8Tgb+Pe0VHcQQba0PO/NPUji9wAiFt7g X-Brightmail-Tracker: AAAAAA== X-j-chkmail-Score: MSGID : 4C10A7E0.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear Andrew, I am interested in participating in this WG but the proposed schedule is sending the xNAME discussion in 2011. Isn't there any way to speed things up? Regards, Vaggelis Segredakis >-----Original Message----- >From: owner-namedroppers@ops.ietf.org [mailto:owner->namedroppers@ops.ietf.org] On Behalf Of Andrew Sullivan >Sent: Wednesday, June 09, 2010 7:11 PM >To: namedroppers@ops.ietf.org >Subject: Re: [dnsext] RE: On adoption of two drafts ... >[hat] >All of that said, it would be most helpful if WG participants had a >look at the recently-posted proposed charter, and chimed in with >whether they think taking on this work for real, with the proposed >schedule, is a good idea. >A >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Jun 10 02:14:41 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866073A6908; Thu, 10 Jun 2010 02:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.704 X-Spam-Level: X-Spam-Status: No, score=-3.704 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_50=0.001, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbYLGVXrdRss; Thu, 10 Jun 2010 02:14:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E7B9F3A67DB; Thu, 10 Jun 2010 02:14:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMdkm-000LMY-IQ for namedroppers-data0@psg.com; Thu, 10 Jun 2010 09:08:48 +0000 Received: from [139.91.1.2] (helo=mailgate.ics.forth.gr) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMdkg-000LLp-Qz; Thu, 10 Jun 2010 09:08:43 +0000 Received: from av1.ics.forth.gr ([139.91.157.71]) by mailgate.ics.forth.gr (8.14.3/ICS-FORTH/V10-1.8-GATE) with ESMTP id o5A98cR2004133; Thu, 10 Jun 2010 12:08:41 +0300 (EEST) X-AuditID: 8b5b9d47-b7c08ae000006cb4-97-4c10ab975753 Received: from enigma.ics.forth.gr (webmail.ics.forth.gr [139.91.1.30]) by av1.ics.forth.gr (SMTP Outbound / FORTH / ICS) with SMTP id 67.C7.27828.79BA01C4; Thu, 10 Jun 2010 12:08:39 +0300 (EEST) Received: from Thanatos (thanatos.ics.forth.gr [139.91.88.160]) (authenticated bits=0) by enigma.ics.forth.gr (8.14.3//ICS-FORTH/V10.3.0C-EXTNULL-SSL-SASL) with ESMTP id o5A98cFT029071 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 10 Jun 2010 12:08:38 +0300 From: "Vaggelis Segredakis" To: "'Avri Doria'" , References: <201005191433.QAA13726@TR-Sys.de> <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> Subject: RE: [dnsext] RE: On adoption of two drafts ... Date: Thu, 10 Jun 2010 12:08:19 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> Thread-Index: AcsH5RHvQfk4RYC0SASNOVXS18NhSwAleGCA X-Brightmail-Tracker: AAAAAxSiMs8UojnjFKMXyg== X-j-chkmail-Score: MSGID : 4C10AB96.000 on mailgate : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-ICS-JCHK-SCL: Ham Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear Avri, If the case is as simple as you suggest, I wonder why the users do not prefer the type xn--hxabldgabihbtf2bh7g3aai.gr over an IDN domain name? Domain names are labels/mnemonics and not words, I agree with you. Unfortunately most people use words when they have to memorize = something. If Latin speaking people can use words in a way that makes sense, the same should be true for every one who can use IDNs. However, the xNAME discussion has come to a point where it is beyond the label itself, it is DNS. Why two DNS trees cannot be the same if a user wishes so? Why DNAME+CNAME fail and DNAME is working on the layer below = but not on the specific layer it starts from? The questions to be answered belong to the DNS world and a solution to this issue will be welcomed by many. Kind Regards, Vaggelis Segredakis -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Avri Doria Sent: Wednesday, June 09, 2010 5:35 PM To: namedroppers@ops.ietf.org Subject: Re: [dnsext] RE: On adoption of two drafts ... Hi, I have often tried to explain to people that the relationship between = labels and words is a happy coincidence and they should not count on it. Other then people who either have at least one foot in the IETF = environment and some old timers, almost no one accepts that and most people I talk = to think it is an absurd idea. The fact as Donald says, so many words and phrases do exist in the LDH = ASCII labels, i.e. there are many happy coincidences, has convinced almost = every non-latin as-a-first language speaker I know that they should be able = to have names that make sense in their script/languages as words and = phrases . So while it is fine to maintain the purity of 'labels are not words' in = the technical requirements, there should not be an expectation that the = users will necessarily find that a satisfactory solution. And, possibly, = allowing for as many happy coincidences as possible would be a good thing. a. (mostly a lurker) On 4 Jun 2010, at 19:58, Donald Eastlake wrote: > Hi, >=20 > On Wed, May 19, 2010 at 10:33 AM, Alfred H=CEnes wrote: > Vaggelis Segredakis wrote: >=20 > > In the .gr ccTLD we have presented in 2005 the option of registering > > IDN domain names in Greek. The Greek language requires for all > > multi syllabus words to have an accent sign called "tonos" over > > one of the letters. [...] >=20 > Unfortunately, hereby we apparently are back at one of the greatest > ratholes ever seen in DNS internationalization. >=20 > Wasn't it one of the fundamental characteristics of the DNS that > DNS labels are _not_ "words" (in any language), but simply abstract > _identifiers_ in a more user friendly alphabet than IP addresses? >=20 > While the problem might appear to be "words", I would argue that it is subtlety different from that. The problem might appear to be words, but = it is primarily script systems. >=20 > Users of a particular script system have expectations built up over a lifetime of use. Users of the Roman script system expect that, much of = the time, there is little if any difference between upper and lower case. >=20 > DNS could have been designed to ignore the expectations of users of = the Roman script system and been case sensitive. If so, there would be much = less pressure to provide accommodations for other script systems (Greek, = Arabic, Han, etc.) similar to its Roman case insensitivity. But, because DNS accommodates the expectations of Roman script system users, users of = other script systems legitimately expect that they will also be accommodated. >=20 > Thanks, > Donald > =20 >=20 > ... >=20 >=20 > Kind regards, > Alfred. >=20 > -- >=20 > = +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. = | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 = | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de = | > = +------------------------+--------------------------------------------+ >=20 From owner-namedroppers@ops.ietf.org Thu Jun 10 02:34:03 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DE563A6939; Thu, 10 Jun 2010 02:34:03 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.941 X-Spam-Level: ** X-Spam-Status: No, score=2.941 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcxukAYSjzlD; Thu, 10 Jun 2010 02:34:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0FF423A6935; Thu, 10 Jun 2010 02:34:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMe64-000P41-Pm for namedroppers-data0@psg.com; Thu, 10 Jun 2010 09:30:48 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMe60-000P2u-G8 for namedroppers@ops.ietf.org; Thu, 10 Jun 2010 09:30:44 +0000 Received: (eyou send program); Thu, 10 Jun 2010 17:30:43 +0800 Message-ID: <476162243.29656@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 10 Jun 2010 17:30:43 +0800 Message-ID: From: "Jiankang YAO" To: "Andrew Sullivan" , References: <201005191433.QAA13726@TR-Sys.de> <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> <476100590.20169@cnnic.cn> Subject: Re: [dnsext] RE: On adoption of two drafts ... Date: Thu, 10 Jun 2010 17:30:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFuZHJldyBTdWxsaXZhbiIg PGFqc0BzaGlua3Vyby5jb20+DQpUbzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50 OiBUaHVyc2RheSwgSnVuZSAxMCwgMjAxMCAxMjoxMCBBTQ0KU3ViamVjdDogUmU6IFtkbnNleHRd IFJFOiBPbiBhZG9wdGlvbiBvZiB0d28gZHJhZnRzIC4uLg0KDQo+IFtoYXRdDQo+IA0KPiBBbGwg b2YgdGhhdCBzYWlkLCBpdCB3b3VsZCBiZSBtb3N0IGhlbHBmdWwgaWYgV0cgcGFydGljaXBhbnRz IGhhZCBhDQo+IGxvb2sgYXQgdGhlIHJlY2VudGx5LXBvc3RlZCBwcm9wb3NlZCBjaGFydGVyLCBh bmQgY2hpbWVkIGluIHdpdGgNCj4gd2hldGhlciB0aGV5IHRoaW5rIHRha2luZyBvbiB0aGlzIHdv cmsgZm9yIHJlYWwsIHdpdGggdGhlIHByb3Bvc2VkDQo+IHNjaGVkdWxlLCBpcyBhIGdvb2QgaWRl YS4NCj4gDQo+IEENCg0KDQpmb3IgdGhlIEdvYWxzIGFuZCBNaWxlc3RvbmVzIGFib3V0IGFsaWFz IG5hbWVzIGluIHRoZSBwcm9wb3NlZCBjaGFydGVyLA0KSSBzdWdnZXN0Og0KDQpKdW5lIDIwMTAg ICAgICBuZXcgY2hhcnRlciBkaXNjdXNzaW9uIGluIFdHDQpKdWx5IDIwMTAgICAgICAgTmV3IGNo YXJ0ZXIgdG8gSUVTRw0KSnVseSAyMDEwICAgICAgIEROUyBuYW1lIHNhbWUgcHJvYmxlbSBzdGF0 ZW1lbnQgZGlzY3Vzc2lvbg0KU2VwdCAyMDEwICAgICAgIEFkb3B0aW9uIG9mIHRoZSBkcmFmdHMg b2YgZG5zIG5hbWUgc2FtZSBzb2x1dGlvbiBhcyBXRyBpdGVtcyANCk5vdi4gIDIwMTAgICAgICAg V0cgY29uc2Vuc3VzIG9uIG5ldyBvciByZXZpc2VkIFJSVFlQRXMgZm9yIEROUyB0cmVlIGFsaWFz aW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgd29yaw0KRGVjICAyMDEwICAgICAgIEludGVy b3BlcmF0aW9uIHRlc3Rpbmcgb24gbmV3IG9yIHJldmlzZWQgUlJUWVBFcyBmb3INCiAgICAgICAg ICAgICAgICBETlMgdHJlZSBhbGlhc2luZyAocGFydGljdWxhcmx5IHdpdGggZXhpc3RpbmcgZGVw bG95ZWQgY29kZSkNCg0KIE1hci4gMjAxMSAgICAgICBETlMgbmFtZSBzYW1lIHByb2JsZW0gc3Rh dGVtZW50IGRyYWZ0IHRvIElFU0cNCiBBcHIuIDIwMTEgICAgICAgICBEb2N1bWVudCBvbiBuZXcg UlJUWVBFIG9yIHJldmlzZWQgUlJUWVBFIGhhbmRsaW5nIGZvcg0KICAgICAgICAgICAgICAgICAg ICAgICAgIEROUyB0cmVlIGFsaWFzaW5nIHRvIElFU0cNCg0KTm92ICAyMDExICAgICAgIERvY3Vt ZW50IG9uIGluLXpvbmUgbWV0YWRhdGEgZm9yIEROUyB0cmVlIGFsaWFzaW5nIHRvIElFU0cNCk5v diAgMjAxMSAgICAgICBEb2N1bWVudCBvbiB1c2VzIGFuZCBsaW1pdGF0aW9ucyBvZiBkaWZmZXJl bnQgRE5TIHRyZWUNCiAgICAgICAgICAgICAgICAgICAgICAgICBhbGlhc2luZyB0ZWNobmlxdWVz IHRvIElFU0cNCg0KDQpKaWFua2FuZyBZYW8NCg0KPiANCj4gDQo+IC0tIA0KPiBBbmRyZXcgU3Vs bGl2YW4NCj4gYWpzQHNoaW5rdXJvLmNvbQ0KPiBTaGlua3VybywgSW5jLg0KPg== From owner-namedroppers@ops.ietf.org Thu Jun 10 08:49:15 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5723A68FC; Thu, 10 Jun 2010 08:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.48 X-Spam-Level: ** X-Spam-Status: No, score=2.48 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCyvbGb0-rRH; Thu, 10 Jun 2010 08:49:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 90DFD3A69B6; Thu, 10 Jun 2010 08:49:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMjuY-000EsY-Vn for namedroppers-data0@psg.com; Thu, 10 Jun 2010 15:43:18 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMjuS-000Es1-Tk for namedroppers@ops.ietf.org; Thu, 10 Jun 2010 15:43:13 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 86A5B1ECB408 for ; Thu, 10 Jun 2010 15:43:11 +0000 (UTC) Date: Thu, 10 Jun 2010 11:43:09 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] RE: On adoption of two drafts ... Message-ID: <20100610154309.GB1471@shinkuro.com> References: <201005191433.QAA13726@TR-Sys.de> <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> <20100609161042.GY62459@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Jun 10, 2010 at 11:52:30AM +0300, Vaggelis Segredakis wrote: > Dear Andrew, > > I am interested in participating in this WG but the proposed schedule is > sending the xNAME discussion in 2011. Isn't there any way to speed things > up? This WG (and most others) has a long history of setting short deadlines and then repeatedly missing them. In this space, a few useful comparisons are worth considering. First, we have the example of the SHA-2 document, which was a "short" and "easy" document that nevertheless took a very long time to emerge. More controversial documents, such as AXFR-clarify, took even longer. We've moved the deliverable dates as a result. As another point of comparison, let us consider the milestones for the IDNAbis WG, which included extremely short timelines. Indeed, the work ended up being called "IDNA2008" even though it's now the middle of 2010 and we still don't have the RFCs published. I think that state of affairs is absurd. I do not believe it is realistic to commit to getting all the specification work of any of these items complete, particularly with respect to DNSSEC, before the deadlines that we included. But note that there is nothing at all preventing us from working faster: if we have fast revision cycles, and lots of extensive review, sooner than the dates there contemplated, then that's just a sign of a healthy, involved, and interested community coming together to get the work done. I'm all for it. But I'm not going to assume it and then be disappointed. Note, as well, that this is a volunteer effort. If we set short deadlines and then people don't do the work so that we miss them, there's basically nothing anyone can do about it. I'd rather have realistic deadlines that tell people when they can realistically expect work to be complete. Note also that I think the work needs actually to get done by roughly the milestone date. If we miss the milestone dates by wide margins, I will (and I think Olafur will too, but I don't want to put words in his mouth) take that to be an indication that the WG isn't actually willing to work on this stuff, and that it will not complete. At that point we'll have to decide whether the WG ought to give up on the work. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Jun 10 08:59:10 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4463A69B6; Thu, 10 Jun 2010 08:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.509 X-Spam-Level: ** X-Spam-Status: No, score=2.509 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQ39-nJWLNfV; Thu, 10 Jun 2010 08:59:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 67F553A696E; Thu, 10 Jun 2010 08:59:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMk67-000H6i-S0 for namedroppers-data0@psg.com; Thu, 10 Jun 2010 15:55:15 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMk61-000H5m-VO for namedroppers@ops.ietf.org; Thu, 10 Jun 2010 15:55:10 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6546C1ECB408 for ; Thu, 10 Jun 2010 15:55:07 +0000 (UTC) Date: Thu, 10 Jun 2010 11:55:05 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] RE: On adoption of two drafts ... Message-ID: <20100610155505.GC1471@shinkuro.com> References: <201005191433.QAA13726@TR-Sys.de> <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> <476100590.20169@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Jun 10, 2010 at 05:30:59PM +0800, Jiankang YAO wrote: > > June 2010 new charter discussion in WG > July 2010 New charter to IESG These of course can't go in the charter, because the charter would need changing ;-) > July 2010 DNS name same problem statement discussion The intent is that the charter provide a minimal problem statement. That's what those two paragraphs are in there for. > Sept 2010 Adoption of the drafts of dns name same solution as WG items > Nov. 2010 WG consensus on new or revised RRTYPEs for DNS tree aliasing > work This suggests that we will have two months between adopting the drafts and forging consensus. Perhaps I am being pessimistic, but I don't actually believe that this WG could forge a consensus on the colour of the sky or whether the sun will come up tomorrow in two months. We're just not that co-operative a group. I don't want to set unrealistic expectations. Note, also, that I'm sort of assuming we'll adopt the drafts in July, in conjunction with out Maastricht meeting. > Dec 2010 Interoperation testing on new or revised RRTYPEs for > DNS tree aliasing (particularly with existing deployed code) There are two problems I see with this. First, we don't have any regular IETF meetings secheduled in Dec., which means that this item would require additional travel by participants. Given the regular complaints about IETF travel we hear, that seems like a bad plan. But in any case, for this to happen, we need multiple implementers to have completed their implementation in time for this. I don't think a month is a reasonable time frame for that. Since I also don't think November is a reasonable time to expect consensus, there's no way I believe this will happen in Dec. I put the two consensus-and-interop things together because I think the emerging consensus (along with actual implementation) will be totally plain long before that. This step is basically a formal step: in the past, we have required interoperability tests rather like what one has when one moves a document along the standards track _just to send the documents out_ from the WG when they make big changes of this sort. (Cf. DNSSEC.) We've done this because of the proximity of the DNS to the Internet brain stem. > Mar. 2011 DNS name same problem statement draft to IESG > Apr. 2011 Document on new RRTYPE or revised RRTYPE handling for > DNS tree aliasing to IESG > > Nov 2011 Document on in-zone metadata for DNS tree aliasing to IESG > Nov 2011 Document on uses and limitations of different DNS tree > aliasing techniques to IESG I think that the last three documents are basically a package: they need to hang together in some sensible way, even if they don't rely on one another. In particular, the last will certainly refer to the other two. So I've set their deadlines together. Now, there is _nothing_ that says documents can't proceed faster than the milestones. If we have interested and engaged parties, maybe we'll move much faster than the milestones suggest. That'd be excellent. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Jun 10 10:47:42 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34323A6917; Thu, 10 Jun 2010 10:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.256 X-Spam-Level: ** X-Spam-Status: No, score=2.256 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VyRCc1-wN8c; Thu, 10 Jun 2010 10:47:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E4B7F3A6990; Thu, 10 Jun 2010 10:47:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMllW-0009Nb-KA for namedroppers-data0@psg.com; Thu, 10 Jun 2010 17:42:06 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMllS-0009Mz-Op for namedroppers@ops.ietf.org; Thu, 10 Jun 2010 17:42:03 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5AHfqjx081887; Thu, 10 Jun 2010 13:41:52 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Thu, 10 Jun 2010 13:42:00 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 10 Jun 2010 13:42:00 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20100610154309.GB1471@shinkuro.com> References: <201005191433.QAA13726@TR-Sys.de> <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> <20100609161042.GY62459@shinkuro.com> <20100610154309.GB1471@shinkuro.com> Date: Thu, 10 Jun 2010 13:32:40 -0400 To: Andrew Sullivan From: Edward Lewis Subject: Re: [dnsext] RE: On adoption of two drafts ... Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 11:43 -0400 6/10/10, Andrew Sullivan wrote: >I think that state of affairs is absurd. >Note, as well, that this is a volunteer effort. I agree with this. There have been cases where someone "comes to the IETF" asking for the WG to solve a problem. I guess the "IDN" fits the bill, but I am not singling this out as an example of bad behavior. What does it mean to have the WG take on a work item? Anyone can describe an issue as a sketch and some people can describe an issue in great detail. But who is going to provide the solution? The WG - which has no membership - will have people willing to volunteer some approaches. Much of the time the volunteer won't have the resources to commit to going further than a mere high-level suggestion. It's still up to somebody or some small group to "work" to solve something. Once there's a drafted solution, the WG can offer people willing to volunteer critical comments. The WG won't be able to make the solution, just give it a more refined shape. I've always wondered what it meant for the WG to "adopt" a document. I've begun to see a WG's adoption of a document as a millstone around the neck of the idea, not a promotion or recognition of an idea. Mechanically, the person writing the document does from an author to an editor. After adoption, what is in the document is supposed to be the consensus of the group as opposed to one person's perspective. Basically, it gets more vetting, that's all. Yes, that's helpful but it will slow progress and tends to retard innovation. I think the having milestones for a WG is absurd if there is no enforcement - by the chairs or anyone else - to meet the schedule. Our chairs have little leverage over volunteers, making their job particularly hard in enforcing dates. (If something is due on July 1 and they have no volunteer committed, what should the chair do?) It comes to this - if anyone wants anything ("IDN") to be solved, they pretty much have to supply the muscle. The WG isn't going to magically generate a solution beyond what's already been offered. The "muscle" might be funding some WG volunteers to take this on as consultants, if not supplying the expertise. Saying that the WG's milestones are too far out there and should be sooner for a problem is not something that will help progress because without anyone supplying the "muscle" to make the solution, the dates are meaningless. For every problem out there, there has to be someone championing it. This isn't a role for the chairs, they are there to help the process but not to make the progress. The champion will be the one that determines when a milestone will be set regardless of when the chairs list on the charter page. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Discussing IPv4 address policy is like deciding what to eat on the Titanic. From owner-namedroppers@ops.ietf.org Thu Jun 10 11:15:44 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02EE33A6917; Thu, 10 Jun 2010 11:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.535 X-Spam-Level: ** X-Spam-Status: No, score=2.535 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmVNOgUkkemP; Thu, 10 Jun 2010 11:15:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A9D243A69B6; Thu, 10 Jun 2010 11:15:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMmDB-000ELX-19 for namedroppers-data0@psg.com; Thu, 10 Jun 2010 18:10:41 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMmD7-000EL6-CA for namedroppers@ops.ietf.org; Thu, 10 Jun 2010 18:10:37 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 648A11ECB408 for ; Thu, 10 Jun 2010 18:10:35 +0000 (UTC) Date: Thu, 10 Jun 2010 14:10:33 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data Message-ID: <20100610181033.GI1471@shinkuro.com> References: <20100517143811.GA77756@shinkuro.com> <20100607212213.GR60255@shinkuro.com> <20100608210903.GP62459@shinkuro.com> <201006091311.o59DBvXk069700@stora.ogud.com> <20100609182832.GD62459@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Jun 09, 2010 at 08:28:04PM -0400, Michael StJohns wrote: > > >MAY return data without validating. > > It MUST return the data regardless of validation state. If there is > a local covering TA, the resolver MAY defer validation unless and > until it receives a CD=0 query. The second sentence there just muddies things -- I think it belongs in a different paragraph. So up to here: A security-aware recursive name server might receive queries either with CD=1 or with CD=0. In addition, it might have cached data that is the result of a query made with CD=1 or CD=0. A general rule is that each cache entry MUST include some indication of whether it came from a query performed with CD=1 or with CD=0, or else that all cache entries MUST be treated as though they were performed with CD=0. This rule prevents data that does not validate, but that may be cached to respond to CD=1 queries, from being returned in response to a query with CD=0. When returning data for a query with CD=1, a validating intermediate resolver MAY return data without validating, and SHOULD, if possible, return the requested data on the name server side regardless of whether the data is cached or validated. This text addresses your concern that the previous version could be read as saying that the intermediate resolver may _not_ return the data at all -- I find that reading a little strained, but I get it, and you're right that we need to be very clear. This says SHOULD instead of MUST following 4035. See more on this below. > > It MUST > > NOT return data without validating to a query with CD=0. > > It MUST NOT return data covered by a TA to a query with CD=0 unless it has been locally validated. In this case, I think the MUST NOT, unless is really a SHOULD NOT. Continuing from above, then: It SHOULD NOT return data without validating to a query with CD=0. The exception is when the security aware recursive name server does not have a trust anchor that allows the validator to construct an authentication chain. In that case, the recursive name server uses the unvalidated data to respond to every query, as though the name were unsigned, in keeping with [RFC 4035] section 5.1. This applies both to data that is available from cache, and to data that must first be fetched before returning it. A validating resolver MAY cache unvalidated data in order to respond to queries with CD=1. The validating resolver MUST NOT respond to queries with CD=0 using such cached data unless the data cannot be validated because of the lack of a covering trust anchor (see above). If the validating resolver subesequently validates that cached data, it MAY use it to resond to queries with CD=0. Ok? > > If a validating resolver has a cached response of RCODE=2 (server > > failure), and then receives a query with CD=1 to its name server > > side, then it SHOULD [Note 1] perform the query again with CD=1 > > from its resolver side. > > Why SHOULD? If I don't then I have to return the SERVFAIL to the querier which really seems wrong for a CD=1 query. I believe this is MUST. 4035 was wrong. 4033 has the philosophy for the CD bit and 4035 is out of step with it. the CD bit is the escape mechanism to bypass a resolver that may not actually know why you're asking the question. > The reason for the SHOULD is because that's what 4035 says, and 4035 defines the protocol. Changing this is just a modification to the protocol, even if you want to call that instead a "resolver behaviour change". We have no basis at all to decide that 4033 is more authoritative than 4035 on this: they're both products of the same group, at the same time, working on the same problem, so one can just as easily say that 4033 is wrong and 4035 is right. Speaking personally, I wish it said MUST, but it doesn't. Speaking with my chair hat on, I would be entirely happy, however, if a large number of people now came out of the woodwork to say, "It should be MUST." Then we can make that update. But until we hear that, I have to say that there is not consensus to make this protocol change, so we cannot. > And if you want to stick with SHOULD, you need to add the conditions for which not doing this is reasonable. I put the same "if possible" as was in 4035 in the text above. Ok? > Does any validating resolver implementation use the SHOULD escape clause? E.g. doesn't pass on non-validated data to a CD=1 query? If not, then changing this to a MUST has no affect on the Internet. > I invite you to go out and test this. I don't know, and I don't know who would, since I don't know that we have an enumeration of all the validating resolver implementations in the universe. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Jun 10 18:18:23 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B494C3A68C8; Thu, 10 Jun 2010 18:18:23 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 3.483 X-Spam-Level: *** X-Spam-Status: No, score=3.483 tagged_above=-999 required=5 tests=[AWL=-1.266, BAYES_50=0.001, FH_RELAY_NODNS=1.451, J_CHICKENPOX_28=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQZgiXFuAcHr; Thu, 10 Jun 2010 18:18:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DF7EC3A68C3; Thu, 10 Jun 2010 18:18:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMskZ-000FOJ-Mk for namedroppers-data0@psg.com; Fri, 11 Jun 2010 01:09:35 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMskV-000FNb-Ib for namedroppers@ops.ietf.org; Fri, 11 Jun 2010 01:09:31 +0000 Received: (eyou send program); Fri, 11 Jun 2010 09:09:29 +0800 Message-ID: <476218569.06137@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 11 Jun 2010 09:09:29 +0800 Message-ID: From: "Jiankang YAO" To: "Andrew Sullivan" , Cc: "Niall O'Reilly" , "lee" References: <201005191433.QAA13726@TR-Sys.de> <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> <476100590.20169@cnnic.cn> <20100610155505.GC1471@shinkuro.com> Subject: Re: [dnsext] RE: On adoption of two drafts ... Date: Fri, 11 Jun 2010 09:09:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFuZHJldyBTdWxsaXZhbiIg PGFqc0BzaGlua3Vyby5jb20+DQpUbzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50 OiBUaHVyc2RheSwgSnVuZSAxMCwgMjAxMCAxMTo1NSBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRd IFJFOiBPbiBhZG9wdGlvbiBvZiB0d28gZHJhZnRzIC4uLg0KDQoNCj4+IEp1bHkgMjAxMCAgICAg ICBETlMgbmFtZSBzYW1lIHByb2JsZW0gc3RhdGVtZW50IGRpc2N1c3Npb24NCj4gDQo+IFRoZSBp bnRlbnQgaXMgdGhhdCB0aGUgY2hhcnRlciBwcm92aWRlIGEgbWluaW1hbCBwcm9ibGVtIHN0YXRl bWVudC4NCj4gVGhhdCdzIHdoYXQgdGhvc2UgdHdvIHBhcmFncmFwaHMgYXJlIGluIHRoZXJlIGZv ci4NCj4gDQoNClN1emFubmUgV29vbGYsIG1lLHhpYW9kb25nIGFuZCBOaWFsbCBPJ1JlaWxseSBo YXZlIGFncmVlZCB0byBjby1hdXRob3IgYSBkcmFmdCBhYm91dCBkbnMgbmFtZSBzYW1lIHByb2Js ZW0gYmFzZWQgb24gdGhlIGJ1bmRsZSBuYW1lcyBpZGVudGljYWwgZG5zIHJlc29sdXRpb24gcHJv YmxlbSBzdGF0ZW1lbnQgZHJhZnQgc3VibWl0dGVkIGEgZmV3IG1vbnRocyBhZ28uDQoNCkppYW5r YW5nIFlhbw== From owner-namedroppers@ops.ietf.org Thu Jun 10 19:04:00 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2289C3A6893; Thu, 10 Jun 2010 19:04:00 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 3.301 X-Spam-Level: *** X-Spam-Status: No, score=3.301 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYI+q-CSgDLz; Thu, 10 Jun 2010 19:03:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 40A713A684C; Thu, 10 Jun 2010 19:03:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMtXe-000KfT-6P for namedroppers-data0@psg.com; Fri, 11 Jun 2010 02:00:18 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMtXa-000Kep-I5 for namedroppers@ops.ietf.org; Fri, 11 Jun 2010 02:00:15 +0000 Received: (eyou send program); Fri, 11 Jun 2010 10:00:12 +0800 Message-ID: <476221612.23265@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 11 Jun 2010 10:00:12 +0800 Message-ID: From: "Jiankang YAO" To: "Andrew Sullivan" , References: <201005191433.QAA13726@TR-Sys.de> <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> <476100590.20169@cnnic.cn> <20100610155505.GC1471@shinkuro.com> Subject: Re: [dnsext] RE: On adoption of two drafts ... Date: Fri, 11 Jun 2010 10:00:31 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFuZHJldyBTdWxsaXZhbiIg PGFqc0BzaGlua3Vyby5jb20+DQpUbzogPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50 OiBUaHVyc2RheSwgSnVuZSAxMCwgMjAxMCAxMTo1NSBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRd IFJFOiBPbiBhZG9wdGlvbiBvZiB0d28gZHJhZnRzIC4uLg0KDQo+IE5vdGUsIGFsc28sIHRoYXQg SSdtIHNvcnQgb2YgYXNzdW1pbmcgd2UnbGwgYWRvcHQgdGhlDQo+IGRyYWZ0cyBpbiBKdWx5LCBp biBjb25qdW5jdGlvbiB3aXRoIG91dCBNYWFzdHJpY2h0IG1lZXRpbmcuDQoNCisxDQoNCg== From owner-namedroppers@ops.ietf.org Thu Jun 10 22:53:34 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86DE23A69C2; Thu, 10 Jun 2010 22:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.394 X-Spam-Level: * X-Spam-Status: No, score=1.394 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6nBpK5ShUEk; Thu, 10 Jun 2010 22:53:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D9D53A68D0; Thu, 10 Jun 2010 22:53:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMx4m-000KRY-KZ for namedroppers-data0@psg.com; Fri, 11 Jun 2010 05:46:44 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OMx4i-000KQs-Be for namedroppers@ops.ietf.org; Fri, 11 Jun 2010 05:46:40 +0000 Received: (qmail 30904 invoked by uid 399); 11 Jun 2010 05:46:38 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 11 Jun 2010 05:46:38 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C11CDBB.7010002@dougbarton.us> Date: Thu, 10 Jun 2010 22:46:35 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Avri Doria CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] RE: On adoption of two drafts ... References: <201005191433.QAA13726@TR-Sys.de> <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> In-Reply-To: <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> X-Enigmail-Version: 1.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 6/9/2010 7:35 AM, Avri Doria wrote: > I have often tried to explain to people that the relationship between > labels and words is a happy coincidence and they should not count on > it. > > Other then people who either have at least one foot in the IETF > environment and some old timers, almost no one accepts that and most > people I talk to think it is an absurd idea. In case anyone isn't convinced yet, find me an English language word that is NOT already registered in COM (minus words that require non-allowed punctuation of course). The fact that it's even necessary to have this discussion is one of those "ivory tower" issues that people refer to when they talk about the IETF being out of touch with reality. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Fri Jun 11 10:23:26 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635413A6971; Fri, 11 Jun 2010 10:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.688 X-Spam-Level: X-Spam-Status: No, score=-4.688 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrpUIJJFoOkl; Fri, 11 Jun 2010 10:23:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BDEC93A6A1F; Fri, 11 Jun 2010 10:23:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ON7oP-0000Qf-1l for namedroppers-data0@psg.com; Fri, 11 Jun 2010 17:14:33 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ON7oL-0000QE-BX for namedroppers@ops.ietf.org; Fri, 11 Jun 2010 17:14:29 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Subject: [dnsext] New work and a proposed new charter was On adoption of two drafts ... From: Avri Doria In-Reply-To: <20100609161042.GY62459@shinkuro.com> Date: Fri, 11 Jun 2010 13:14:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2A2844F9-86B6-49E5-A02D-BBB360C6054C@psg.com> References: <201005191433.QAA13726@TR-Sys.de> <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> <20100609161042.GY62459@shinkuro.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 9 Jun 2010, at 12:10, Andrew Sullivan wrote: > All of that said, it would be most helpful if WG participants had a > look at the recently-posted proposed charter, and chimed in with > whether they think taking on this work for real, with the proposed > schedule, is a good idea. I have lurked for a long while and pretty much not participated in the = group. I have noticed that saying that one supports work items being chartered = means they would participate in the work. I would participate in the = work, at least to the extent of working on the problem statement and = being an active reviewer, involved with: > While the DNS offers two mechanisms for aliasing DNS labels -- CNAME > and DNAME -- neither of these provides the support necessary to alias > completely one part of the DNS tree as another part. There are claims > that the restriction has proven to be too great in practice, > particularly with burgeoning deployment of IDNA and the need to > provide domain name variants. The issue is made more complex by > DNSSEC >=20 > The DNSEXT WG will evaluate ways to provide such aliasing, to add > metadata to zones to allow easier operation of zones when such > aliasing is needed, or both. The WG will also provide an > informational document outlining the various strategies available, > what they might be used for, and what their limitations are. It is > possible that the WG will conclude no aliasing or metadata support is > possible, or that none of the proposals so far made are adequate. I do not expect to attend the next IETF meeting but will try to = participate remotely if I can. a. From owner-namedroppers@ops.ietf.org Fri Jun 11 12:04:11 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0473A6968; Fri, 11 Jun 2010 12:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyrNgxDLJs35; Fri, 11 Jun 2010 12:04:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BFD893A67F2; Fri, 11 Jun 2010 12:04:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ON9RX-000GDa-62 for namedroppers-data0@psg.com; Fri, 11 Jun 2010 18:59:03 +0000 Received: from [2001:4900:1:392:213:20ff:fe1b:3bfe] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ON9RT-000GCB-2J; Fri, 11 Jun 2010 18:58:59 +0000 Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ON9RR-000Gsr-2E; Fri, 11 Jun 2010 18:58:57 +0000 Subject: Re: [dnsext] RE: On adoption of two drafts ... Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Joe Abley In-Reply-To: <4C11CDBB.7010002@dougbarton.us> Date: Fri, 11 Jun 2010 14:58:55 -0400 Cc: Avri Doria , namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <36C8A940-D1F0-46B7-A850-449BB6563661@hopcount.ca> References: <201005191433.QAA13726@TR-Sys.de> <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> <4C11CDBB.7010002@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1078) X-SA-Exim-Connect-IP: 199.212.90.21 X-SA-Exim-Mail-From: jabley@hopcount.ca X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 2010-06-11, at 01:46, Doug Barton wrote: > On 6/9/2010 7:35 AM, Avri Doria wrote: >> I have often tried to explain to people that the relationship between >> labels and words is a happy coincidence and they should not count on >> it. >>=20 >> Other then people who either have at least one foot in the IETF >> environment and some old timers, almost no one accepts that and most >> people I talk to think it is an absurd idea. >=20 > In case anyone isn't convinced yet, find me an English language word > that is NOT already registered in COM [sharkbait:~]% while read word; do test -z "$(dig +norec ${word}.com. = soa | grep NXDOMAIN)" || echo "${word}.com"; done X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048D33A699D; Fri, 11 Jun 2010 12:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.987 X-Spam-Level: *** X-Spam-Status: No, score=3.987 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_QP_LONG_LINE=1.396, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+Gn8RDMXTCN; Fri, 11 Jun 2010 12:06:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A57D3A6976; Fri, 11 Jun 2010 12:06:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ON9Vp-000GsA-7v for namedroppers-data0@psg.com; Fri, 11 Jun 2010 19:03:29 +0000 Message-Id: Received: from [76.96.62.64] (helo=qmta07.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ON9Vl-000Grn-7i for namedroppers@ops.ietf.org; Fri, 11 Jun 2010 19:03:25 +0000 Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta07.westchester.pa.mail.comcast.net with comcast id UcQX1e0041ap0As57j3RfR; Fri, 11 Jun 2010 19:03:25 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta22.westchester.pa.mail.comcast.net with comcast id Uj3Q1e0021EtFYL3ij3Qg6; Fri, 11 Jun 2010 19:03:25 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Jun 2010 15:03:09 -0400 To: "George Barwood" , From: Michael StJohns Subject: Re: [dnsext] Setting CD=1 on upstream queries In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 01:57 PM 6/9/2010, George Barwood wrote: >It has been suggested that a resolver MAY/SHOULD/MUST set CD=3D1 on= recursive upstream >queries to forwarders when responding to a CD=3D0 query for which there is= a trust anchor. > >Possible advantages: > >A1 Less load on upstream resolver. >A2 May be faster. >A3 Avoids potential upstream validation failures. A4 - places the authority and responsibility for validating answers closest= to the querier and provides a local and known place to beat on when someone= screws up with the signing of the root or IN-ADDR.ARPA >Possible problems / disadvantages: > >D1 If there is CNAME or DNAME redirection, the response may not be covered= by the trust anchor. Since the CNAME or DNAME can actually chain through a name not covered by= any trust anchor, and that can't actually be detected by the end user, this= seems to be no worse than the defined behavior for DNSSEC over CNAME in= general. (I can point you to a long discussion on this from a while back,= but thing secured CNAME -> unsecured CNAME -> secured CNAME - fooling with= the unsecured CNAME can redirect you and you would still get a "secure"= indication from the resolver) >D2 The upstream resolver may implement an algorithm that the local resolver= does not implement. But the local resolver has no way - absent of manual configuration - to know= this. I'm perfectly happy to have a configuration item in the local= resolver to clear the CD bit is specific circumstances for TA covered= queries... but its probably not the best default to clear the CD bit. Besides, I think this may actually be a red herring. If I have a trust= anchor for zone A - and its a legitimate trust anchor - then it will be= pointing to an apex DNSKEY RRSet that contains a key with this algorithm,= or at least that's how I understand this is supposed to work. If the real= apex set doesn't contain a key with this algorithm, then the TA is lame or= bogus and needs local work to fix it. Remember a TA has two purposes - to= provide a key for validating a chain and to set a bit that says "this name= tree is presumed to be validly signed". Somewhere I remember a nice long= discussion with someone that says that the apex RRSet must contain at least= one key from each algorithm that signs the zone and that all entries in the= zone must be signed with those algorithms. So I should be able to get the= RRSet and the appropriate RRSig and if I can't then that's just a= validation failure caused one of a mistake on the local configuration, an= attack in the middle (to substitute the RRSig and RRSet), or a= configuration mistake on the authoritative side. >D3 The upstream resolver may have a closer, more trusted, anchor. Again, same response as to D2 - no way to know without configuration. The= upstream may also have a closer more broken TA which is actually acting as= a denial of service attack.. The local resolver has no way absent manual= configuration to determine this. =20 >D4 If the local resolver is flawed, security may be reduced. Possible flaws= are: > D4.1 Invalid trust anchor ( may have been inserted by an adversary ). > D4.2 Inaccurate local clock. > D4.3 Flaw in local DNSSEC software. Yes, but... The same can apply to a quantum-ly existent upstream resolver. = If your local resolver is broken, no amount of possibly non-existent= upstream patching of answers is going to do anything useful. >Disadvantages D1 and D2 may be overcome by repeating the upstream query= with CD=3D0 if in >fact the response cannot be fully validated locally. The other= disadvantages are not decisive. >Therefore setting CD=3D1 does seem reasonable. Sorry - should have read this first - I thought you were arguing against= CD=3D1. =20 >However it does involve extra complexity and can lead to reduced= performance / security >in some situations, therefore I don't think it should be mandatory.= Moreover a clarifications >document is not a suitable place to introduce mandatory behavior that is= not essential. I think it would be reasonable to define a mandatory default behavior with= an optional bypass, even in a clarification document. 4035 didn't clearly= define the behavior of the resolver side of an intermediate nameserver,= either for the presence of CD=3D1 on the query side (the language said= "pass the state" didn't say set the bit in the upstream, but that's now in= -11 bis), or for queries for which the resolver has a TA. 4033 is pretty= clear that if you have the ability to do your own validation, you should= set the CD bit to make sure you get the data you need to do your= validation. If we say "SHOULD" for the default, then RFC2119 Section suggests/requires= we document the adverse affects of not doing so. And the text for that is= probably quite a bit longer than just saying "MUST"! =20 I'm willing to write the explanatory text for a "MUST" - anyone else willing= to step up and write the text for SHOULD if we go that way? >Regards, >- George From owner-namedroppers@ops.ietf.org Fri Jun 11 13:00:32 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6F428C0F8; Fri, 11 Jun 2010 13:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.383 X-Spam-Level: *** X-Spam-Status: No, score=3.383 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQhwdiNQOFlG; Fri, 11 Jun 2010 13:00:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE5DC3A699D; Fri, 11 Jun 2010 13:00:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONALF-000O4e-FB for namedroppers-data0@psg.com; Fri, 11 Jun 2010 19:56:37 +0000 Message-Id: Received: from [76.96.62.16] (helo=qmta01.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONALB-000O4D-Tp for namedroppers@ops.ietf.org; Fri, 11 Jun 2010 19:56:34 +0000 Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta01.westchester.pa.mail.comcast.net with comcast id Ubee1e0091swQuc51jwaRb; Fri, 11 Jun 2010 19:56:34 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta15.westchester.pa.mail.comcast.net with comcast id UjwY1e00Q1EtFYL3bjwZrU; Fri, 11 Jun 2010 19:56:34 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Jun 2010 15:56:18 -0400 To: Andrew Sullivan ,namedroppers@ops.ietf.org From: Michael StJohns Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data In-Reply-To: <20100610181033.GI1471@shinkuro.com> References: <20100517143811.GA77756@shinkuro.com> <20100607212213.GR60255@shinkuro.com> <20100608210903.GP62459@shinkuro.com> <201006091311.o59DBvXk069700@stora.ogud.com> <20100609182832.GD62459@shinkuro.com> <20100610181033.GI1471@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 02:10 PM 6/10/2010, Andrew Sullivan wrote: >On Wed, Jun 09, 2010 at 08:28:04PM -0400, Michael StJohns wrote: >> >> >MAY return data without validating. >> >> It MUST return the data regardless of validation state. If there is >> a local covering TA, the resolver MAY defer validation unless and >> until it receives a CD=0 query. > >The second sentence there just muddies things -- I think it belongs in a different >paragraph. So up to here: > > A security-aware recursive name server might receive queries either > with CD=1 or with CD=0. In addition, it might have cached data that > is the result of a query made with CD=1 or CD=0. > > A general rule is that each cache entry MUST include some > indication of whether it came from a query performed with CD=1 or > with CD=0, or else that all cache entries MUST be treated as > though they were performed with CD=0. This rule prevents data > that does not validate, but that may be cached to respond to CD=1 > queries, from being returned in response to a query with CD=0. I think you're saying here is that you can either cache things with an indication, or refuse to cache things that were created as the result of a CD=1 query? I think this still is missing the point. For a CD=0 query, If you have data with CD=1 in cache, you can either locally validate it (if you have a covering TA for all of the data), or you need to repeat the query with CD=0. You can't treat CD=1 data as CD=0 data unless you can locally validate it. > When returning data for a query with CD=1, a validating > intermediate resolver MAY return data without validating, and > SHOULD, if possible, return the requested data on the name server > side regardless of whether the data is cached or validated. > >This text addresses your concern that the previous version could be >read as saying that the intermediate resolver may _not_ return the >data at all -- I find that reading a little strained, but I get it, >and you're right that we need to be very clear. This says SHOULD >instead of MUST following 4035. See more on this below. And this still doesn't get to the point of what the CD bit is there for. "When returning data for a query with CD=1, a validating intermediate resolver with cached data for the QNAME SHOULD return that data regardless of local validation status. Otherwise if it has no cached data or has only a SERVFAIL cached for the QNAME, it MUST repeat the query upstream with CD=1 and MUST return the result of that query to the querier." The SHOULDs and MUSTs are consistent with the fix to the CD=1 for CD=1 queries in -11bis as well as normal behavior of an intermediate resolver (must return result of query). >> > It MUST >> > NOT return data without validating to a query with CD=0. >> >> It MUST NOT return data covered by a TA to a query with CD=0 unless it has been locally validated. > >In this case, I think the MUST NOT, unless is really a SHOULD NOT. >Continuing from above, then: > > It SHOULD NOT return data without validating to a query with > CD=0. The exception is when the security aware recursive name > server does not have a trust anchor that allows the validator to > construct an authentication chain. In that case, the recursive > name server uses the unvalidated data to respond to every query, > as though the name were unsigned, in keeping with [RFC 4035] > section 5.1. This applies both to data that is available from > cache, and to data that must first be fetched before returning it. OK - then what's the point of the local trust anchor? This seems to be arguing both sides of the problem. If you have a validating resolver in validating mode (e.g. not just logging how it might validate), then isn't the point that the resolver MUST validate the data covered by a TA and MUST NOT return unvalidated data? I actually believe it should be possible for a validating resolver to go into log-only mode, but that's not what the SHOULD seems to mean here. If we mean that, then we need to expand the text a lot more. If we don't mean that, then what does SHOULD mean here? If you mean that you should do (or should be able to do) local validation, but return unvalidated data - I say "HUH?" > A validating resolver MAY cache unvalidated data in order to > respond to queries with CD=1. The validating resolver MUST NOT > respond to queries with CD=0 using such cached data unless the > data cannot be validated because of the lack of a covering trust > anchor (see above). If the validating resolver subesequently > validates that cached data, it MAY use it to resond to queries > with CD=0. > >Ok? No - because I think it disagrees with your previous paragraph. I think this is getting worse not better. This again confuses unvalidated (has a TA, but not locally validated) with unvaldatable (no local TA). "A validating resolver MAY cache data regardless of its validation status. If cached data is covered by a TA (and therefore be locally validated), the validating resolver MUST validate such data prior to using it to respond to queries with CD=0. Cached data not covered by a local TA may obviously be used to respond to any query without local validation. >> > If a validating resolver has a cached response of RCODE=2 (server >> > failure), and then receives a query with CD=1 to its name server >> > side, then it SHOULD [Note 1] perform the query again with CD=1 >> > from its resolver side. >> >> Why SHOULD? If I don't then I have to return the SERVFAIL to the querier which really seems wrong for a CD=1 query. I believe this is MUST. 4035 was wrong. 4033 has the philosophy for the CD bit and 4035 is out of step with it. the CD bit is the escape mechanism to bypass a resolver that may not actually know why you're asking the question. >> > >The reason for the SHOULD is because that's what 4035 says, and 4035 >defines the protocol. Changing this is just a modification to the >protocol, even if you want to call that instead a "resolver behaviour >change". We have no basis at all to decide that 4033 is more >authoritative than 4035 on this: they're both products of the same >group, at the same time, working on the same problem, so one can just >as easily say that 4033 is wrong and 4035 is right. > >Speaking personally, I wish it said MUST, but it doesn't. > >Speaking with my chair hat on, I would be entirely happy, however, if >a large number of people now came out of the woodwork to say, "It >should be MUST." Then we can make that update. But until we hear >that, I have to say that there is not consensus to make this protocol >change, so we cannot. > >> And if you want to stick with SHOULD, you need to add the conditions for which not doing this is reasonable. > >I put the same "if possible" as was in 4035 in the text above. Ok? Nope... define "possible". Its a subjective weasel word. Who decides what's possible? What are the criteria? Pick something measurable such as "If in cache" "if received from the upstream server", etc. In any event, see my restatement to your text including "possible" - it has more objective definitions. > >> Does any validating resolver implementation use the SHOULD escape clause? E.g. doesn't pass on non-validated data to a CD=1 query? If not, then changing this to a MUST has no affect on the Internet. >> > >I invite you to go out and test this. I don't know, and I don't know >who would, since I don't know that we have an enumeration of all the >validating resolver implementations in the universe. > >A >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Jun 11 13:24:25 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1016F3A6A4A; Fri, 11 Jun 2010 13:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.495 X-Spam-Level: ** X-Spam-Status: No, score=2.495 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzmU864MCVLs; Fri, 11 Jun 2010 13:24:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1CFB23A6A51; Fri, 11 Jun 2010 13:24:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONAgy-0001kC-ON for namedroppers-data0@psg.com; Fri, 11 Jun 2010 20:19:04 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONAgv-0001jk-Ny for namedroppers@ops.ietf.org; Fri, 11 Jun 2010 20:19:02 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 62D001ECB408 for ; Fri, 11 Jun 2010 20:19:00 +0000 (UTC) Date: Fri, 11 Jun 2010 16:18:58 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data Message-ID: <20100611201858.GX1471@shinkuro.com> References: <20100607212213.GR60255@shinkuro.com> <20100608210903.GP62459@shinkuro.com> <201006091311.o59DBvXk069700@stora.ogud.com> <20100609182832.GD62459@shinkuro.com> <20100610181033.GI1471@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Fri, Jun 11, 2010 at 03:56:18PM -0400, Michael StJohns wrote: > > I think you're saying here is that you can either cache things with > an indication, or refuse to cache things that were created as the > result of a CD=1 query? I think this still is missing the point. I was just trying to write an introductory general-principle sentence. I'm willing to drop it. > For a CD=0 query, If you have data with CD=1 in cache, you can either locally validate it (if you have a covering TA for all of the data), or you need to repeat the query with CD=0. You can't treat CD=1 data as CD=0 data unless you can locally validate it. > Hrm, this makes me think that we need two different paths in the text, one for CD=1 and one for CD=0. I don't have time to try again from scratch right now, but that might be clearer than what we've been doing. > OK - then what's the point of the local trust anchor? This seems to > be arguing both sides of the problem. If you have a validating > resolver in validating mode (e.g. not just logging how it might > validate), then isn't the point that the resolver MUST validate the > data covered by a TA and MUST NOT return unvalidated data? No, because that's not what 4035 says. It says SHOULD NOT. > No - because I think it disagrees with your previous paragraph. I think this is getting worse not better. This again confuses unvalidated (has a TA, but not locally validated) with unvaldatable (no local TA). > It wasn't confused in my mind, but if it's not clear to you then we still have a problem. As I suggested above, I'll try to come up with completely new text treating CD=1 and CD=0 separately. I will note that your choppy way of suggesting text isn't helping me -- I almost never understand what it is you're trying to say. That's undoubtedly my failing, but given that we clearly aren't getting very far with this and I'm actually trying to understand, I take that to be _prima facie_ evidence that the text you're supplying isn't clearing things up. If others want to chime in that this is all crystal clear to them, I'm willing to defer. > >> And if you want to stick with SHOULD, you need to add the conditions for which not doing this is reasonable. > > > >I put the same "if possible" as was in 4035 in the text above. Ok? > > Nope... define "possible". Its a subjective weasel word. Who decides what's possible? What are the criteria? Pick something measurable such as "If in cache" "if received from the upstream server", etc. In any event, see my restatement to your text including "possible" - it has more objective definitions. > 4035 says "SHOULD if possible". I don't know what that meant. Perhaps those who were involved in its writing can elucidate. I am loathe to change this text without pretty strong agreement on what it means, even if I wish it were different. And I don't know which restatement you're talking about. If you could post a single, unbroken candidate text and say exactly where in the draft you would like it and what you'd like to replace, I might have a better grasp of your point. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Jun 11 17:10:16 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23EE23A67AC; Fri, 11 Jun 2010 17:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.207 X-Spam-Level: *** X-Spam-Status: No, score=3.207 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azCFw++ZuxG9; Fri, 11 Jun 2010 17:10:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 304683A66B4; Fri, 11 Jun 2010 17:10:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONEC1-000PSv-59 for namedroppers-data0@psg.com; Sat, 12 Jun 2010 00:03:21 +0000 Message-Id: Received: from [76.96.62.40] (helo=qmta04.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONEBx-000PSe-5o for namedroppers@ops.ietf.org; Sat, 12 Jun 2010 00:03:17 +0000 Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id UnMk1e0021ei1Bg54o3GkB; Sat, 12 Jun 2010 00:03:16 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta24.westchester.pa.mail.comcast.net with comcast id Uo3F1e0031EtFYL3ko3FXA; Sat, 12 Jun 2010 00:03:16 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Jun 2010 20:03:01 -0400 To: Andrew Sullivan ,namedroppers@ops.ietf.org From: Michael StJohns Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data In-Reply-To: <20100611201858.GX1471@shinkuro.com> References: <20100607212213.GR60255@shinkuro.com> <20100608210903.GP62459@shinkuro.com> <201006091311.o59DBvXk069700@stora.ogud.com> <20100609182832.GD62459@shinkuro.com> <20100610181033.GI1471@shinkuro.com> <20100611201858.GX1471@shinkuro.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_622414177==.ALT" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --=====================_622414177==.ALT Content-Type: text/plain; charset="us-ascii" At 04:18 PM 6/11/2010, Andrew Sullivan wrote: >Hrm, this makes me think that we need two different paths in the text, >one for CD=1 and one for CD=0. I don't have time to try again from >scratch right now, but that might be clearer than what we've been doing. From 5/14: >if query CD bit is set >if response is cached >if SERVFAIL is cached >Set CD bit upstream and query >Else >Return cached >else // response not cached >Set CD bit upstream and query >else // query CD bit clear >if response is cached >if cached response had CD bit set >if resolver has covering trust anchor >run validation against cached and return >else // resolver can't validate locally and data wasn't validated upstream >clear CD bit and query >else // prev data was validated upstream if at all >return cached data >else // response not cached >if resolver has covering trust anchor >set CD bit and query then validate locally >else >clear CD bit query and return --=====================_622414177==.ALT Content-Type: text/html; charset="us-ascii" At 04:18 PM 6/11/2010, Andrew Sullivan wrote:

Hrm, this makes me think that we need two different paths in the text,
one for CD=1 and one for CD=0. I don't have time to try again from
scratch right now, but that might be clearer than what we've been doing.

From 5/14:


if query CD bit is set
if response is cached
if SERVFAIL is cached
Set CD bit upstream and query
Else
Return cached
else // response not cached
Set CD bit upstream and query
else // query CD bit clear
if response is cached
if cached response had CD bit set
if resolver has covering trust anchor
run validation against cached and return
else // resolver can't validate locally and data wasn't validated upstream
clear CD bit and query
else // prev data was validated upstream if at all
return cached data
else // response not cached
if resolver has covering trust anchor
set CD bit and query then validate locally
else
clear CD bit query and return


--=====================_622414177==.ALT-- From owner-namedroppers@ops.ietf.org Fri Jun 11 18:11:09 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25A63A67E6; Fri, 11 Jun 2010 18:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.045 X-Spam-Level: ** X-Spam-Status: No, score=2.045 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXgCPTDAGUrX; Fri, 11 Jun 2010 18:11:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CAAA23A6804; Fri, 11 Jun 2010 18:10:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONF4d-0004Nk-VZ for namedroppers-data0@psg.com; Sat, 12 Jun 2010 00:59:48 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONF4X-0004NC-RH for namedroppers@ops.ietf.org; Sat, 12 Jun 2010 00:59:42 +0000 Received: (qmail 41259 invoked from network); 12 Jun 2010 01:21:49 -0000 Received: from softbank219001188004.bbtec.net (HELO ?192.168.1.27?) (219.1.188.4) by necom830.hpcl.titech.ac.jp with SMTP; 12 Jun 2010 01:21:49 -0000 Message-ID: <4C12DB6B.3060308@necom830.hpcl.titech.ac.jp> Date: Sat, 12 Jun 2010 09:57:15 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF DNSEXT WG Subject: [dnsext] URL friendly use of SRV RR Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: How about this idea? The problem of SRV is that it is *NOT* URL friendly that web people should have no idea on how to use it. While SRV is designed following the syntax of IP as: _Service._Proto.Name TTL Class SRV Priority Weight Port Target most applications know and by number from the beginning that there is no room to convert them to ASCII strings. The only notable exception, of course, is when URLs are used. However, as the syntax of Internet URLs is: ://:@:/ applications have no information on the ASCII representation of Proto. So, SRV should be used as: _Scheme.Name TTL Class SRV Priority Weight Proto Port Target where Weight and Proto are 8 bit quantities to make the RR format compatible to todays. Then, if we recommend web people try SRV when "Name" is not resolved to addresses, they should be happy to use it. Masataka Ohta From owner-namedroppers@ops.ietf.org Sat Jun 12 15:01:03 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0673A6405; Sat, 12 Jun 2010 15:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Xtk6MiUcz5Z; Sat, 12 Jun 2010 15:00:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E349F3A6359; Sat, 12 Jun 2010 15:00:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONYcP-000Cat-8P for namedroppers-data0@psg.com; Sat, 12 Jun 2010 21:51:57 +0000 Received: from [204.14.89.4] (helo=mail2.fluidhosting.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ONYcK-000CaV-DL for namedroppers@ops.ietf.org; Sat, 12 Jun 2010 21:51:52 +0000 Received: (qmail 10649 invoked by uid 399); 12 Jun 2010 21:51:50 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Jun 2010 21:51:50 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C140174.9050600@dougbarton.us> Date: Sat, 12 Jun 2010 14:51:48 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: Joe Abley CC: Avri Doria , namedroppers@ops.ietf.org Subject: Re: [dnsext] RE: On adoption of two drafts ... References: <201005191433.QAA13726@TR-Sys.de> <6A9D8FF7-B811-4EC6-84BC-FB405E03B445@psg.com> <4C11CDBB.7010002@dougbarton.us> <36C8A940-D1F0-46B7-A850-449BB6563661@hopcount.ca> In-Reply-To: <36C8A940-D1F0-46B7-A850-449BB6563661@hopcount.ca> X-Enigmail-Version: 1.0.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 06/11/10 11:58, Joe Abley wrote: > > On 2010-06-11, at 01:46, Doug Barton wrote: > >> On 6/9/2010 7:35 AM, Avri Doria wrote: >>> I have often tried to explain to people that the relationship between >>> labels and words is a happy coincidence and they should not count on >>> it. >>> >>> Other then people who either have at least one foot in the IETF >>> environment and some old timers, almost no one accepts that and most >>> people I talk to think it is an absurd idea. >> >> In case anyone isn't convinced yet, find me an English language word >> that is NOT already registered in COM > > [sharkbait:~]% while read word; do test -z "$(dig +norec ${word}.com. soa | grep NXDOMAIN)" || echo "${word}.com"; done abshenry.com > [sharkbait:~]% > > I don't know what abshenry means, for the record. :-) It seems to be a typo for abhenry, which is registered in COM: http://dictionary.reference.com/browse/abshenry -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-namedroppers@ops.ietf.org Mon Jun 14 00:35:47 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295A63A6806; Mon, 14 Jun 2010 00:35:47 -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=[BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1Q7P3MAj-HY; Mon, 14 Jun 2010 00:35:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A3CE33A67AC; Mon, 14 Jun 2010 00:35:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OO45Q-000CR0-SA for namedroppers-data0@psg.com; Mon, 14 Jun 2010 07:28:00 +0000 Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OO45M-000CQ3-1D for namedroppers@ops.ietf.org; Mon, 14 Jun 2010 07:27:56 +0000 Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o5E7RhNT071363 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 14 Jun 2010 09:27:47 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4C15D9EF.9050907@nlnetlabs.nl> Date: Mon, 14 Jun 2010 09:27:43 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4 MIME-Version: 1.0 To: Michael StJohns CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] Setting CD=1 on upstream queries References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 14 Jun 2010 09:27:48 +0200 (CEST) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, On 06/11/2010 09:03 PM, Michael StJohns wrote: > Since the CNAME or DNAME can actually chain through a name not > covered by any trust anchor, and that can't actually be detected by > the end user, this seems to be no worse than the defined behavior for > DNSSEC over CNAME in general. (I can point you to a long discussion > on this from a while back, but thing secured CNAME -> unsecured CNAME > -> secured CNAME - fooling with the unsecured CNAME can redirect you > and you would still get a "secure" indication from the resolver) This is not true. The validator detects the unsecured CNAME in the chain and does not give the result the denomination 'secure', it indicates 'insecure'. Trying to avoid the rest of the CD=1 or BAD cache stuff; I agree with Andrew and Mark; and I think that these approaches for caches with different sets of trust anchors and cooperating to some degree (over untrusted channels?) is not something that should be done in a couple of lines in the dnssec-bis-updates document. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkwV2e8ACgkQkDLqNwOhpPjimACfcxk6jGmQpvkqIfjpmb1eXQtn wg4AnRKyyK9DotpUoqbw76EyJ6nXfCF/ =hINg -----END PGP SIGNATURE----- From info@webmaster.com Mon Jun 14 05:01:03 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FBFE3A682A for ; Mon, 14 Jun 2010 05:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.325 X-Spam-Level: **** X-Spam-Status: No, score=4.325 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_99=3.5, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tceAOEvyi7xp for ; Mon, 14 Jun 2010 05:01:02 -0700 (PDT) Received: from mail.xmgd.com (mail.xmgd.com [211.156.95.230]) by core3.amsl.com (Postfix) with ESMTP id 0E94A3A68C5 for ; Mon, 14 Jun 2010 05:01:02 -0700 (PDT) Received: from xmgd.com (localhost [127.0.0.1]) by mail.xmgd.com (Postfix) with ESMTP id E6FEB1205A3; Mon, 14 Jun 2010 15:25:43 +0800 (CST) From: "Info_webmaster" Reply-To: customercarewebdept210@hotmail.com Subject: Confirma Tu Cuenta=?UTF-8?Q?_Webmail=E2=80=8F?= Date: Mon, 14 Jun 2010 15:25:43 +0800 Message-Id: <20100614071823.M53409@webmaster.com> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 209.107.217.164 (yjy313@xmgd.com) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 To: undisclosed-recipients:; Estimado Cuenta de Usuario, Estamos actualizando nuestra base de datos y e-mail vista de la cuenta central Es decir, Página de inicio. Vamos a eliminar las cuentas de correo electrónico antigua que ya no es el utilizado y Activos para crear más espacio para las nuevas cuentas también users.we también carring a cabo Investigar sobre la comprobación del sistema de seguridad para la mejora y amplia y mejorar nuestra seguridad hoy en día. Para continuar utilizando nuestros servicios es su cuenta de correo electrónico deben ser reconfirmado. Vuelva a confirmar sus datos en la cuenta de correo electrónico, tal como se solicita a continuación. Para completar su re-cuenta el comfirmation, debe responder Este correo electrónico de inmediato y entrar en los detalles de cuentas como Pidió a continuación. Nombre de usuario: Correo electrónico Nombre de usuario: Contraseña: Confirmar contraseña: Fecha de nacimiento: Contraseña futuro: No lo hagas sólo para obtener su cuenta desactivada de nuestro Base de datos y servir a los § no va a detener, los mensajes importantes se pueden también perdieron debido a su negativa de volver a confirmar los detalles de la cuenta Pedimos disculpas por los inconvenientes y la inconvineses ser puestos en escena con usted durante Este período, pero confiando en que estamos aquí para servirle mejor y La disposición de más tecnología que gira en torno a correo electrónico e Internet. Te damos gracias por tu pertinentes una entendemos que nuestra principal preocupación para nuestros clientes es la seguridad de sus archivos y datos. El el comfirmation CÓDIGO: Equipo de Soporte TÃ © cnica -/93-1A388-480 Webmail. From owner-namedroppers@ops.ietf.org Mon Jun 14 07:34:07 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1D9E3A68F2; Mon, 14 Jun 2010 07:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.966 X-Spam-Level: ** X-Spam-Status: No, score=2.966 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76IO3uBflaZC; Mon, 14 Jun 2010 07:34:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7DAEC3A67B3; Mon, 14 Jun 2010 07:34:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOAcC-000NzC-Fi for namedroppers-data0@psg.com; Mon, 14 Jun 2010 14:26:16 +0000 Message-Id: Received: from [76.96.59.227] (helo=qmta12.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOAc8-000Nyh-Kv for namedroppers@ops.ietf.org; Mon, 14 Jun 2010 14:26:13 +0000 Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta12.westchester.pa.mail.comcast.net with comcast id Voue1e0050bG4ec5CqSCdx; Mon, 14 Jun 2010 14:26:12 +0000 Received: from Mike-PC3.comcast.net ([12.236.246.2]) by omta03.westchester.pa.mail.comcast.net with comcast id VqRz1e00H03qFlG3PqS2NV; Mon, 14 Jun 2010 14:26:10 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Jun 2010 10:25:58 -0400 To: "W.C.A. Wijngaards" From: Michael StJohns Subject: Re: [dnsext] Setting CD=1 on upstream queries Cc: namedroppers@ops.ietf.org In-Reply-To: <4C15D9EF.9050907@nlnetlabs.nl> References: <4C15D9EF.9050907@nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 03:27 AM 6/14/2010, W.C.A. Wijngaards wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hi Michael, > >On 06/11/2010 09:03 PM, Michael StJohns wrote: >> Since the CNAME or DNAME can actually chain through a name not >> covered by any trust anchor, and that can't actually be detected by >> the end user, this seems to be no worse than the defined behavior for >> DNSSEC over CNAME in general. (I can point you to a long discussion >> on this from a while back, but thing secured CNAME -> unsecured CNAME >> -> secured CNAME - fooling with the unsecured CNAME can redirect you >> and you would still get a "secure" indication from the resolver) > >This is not true. The validator detects the unsecured CNAME in the >chain and does not give the result the denomination 'secure', it >indicates 'insecure'. To be more specific it doesn't set the AD=1 bit in the reply. As I read it, AD=0 means "unknown" not "bogus" or "unsecure". You also get this result if the validation is done in two parts and both are secure - the original CNAME answer by your local resolver (that has a TA covering this) and the CNAME target by an upstream resolver that validates the target data. Both parts are secure, but the local resolver can't set the AD bit, because it can't trust the AD bit from the upstream and so can't say for itself that both are valid. I probably should have used another word than "secured" here. The client thinking the resolver(s) is/are protecting his could get data for a bogus target query where they might have expected a SERVFAIL. Differing from a secure delegation to an unsecure zone, the client (and intermediate resolvers) has no way to determine whether the owner of the CNAME intended to send us into an unsecure zone - there's no indication in the CNAME of the CNAME owner's expectation of the trust state of the target. >Trying to avoid the rest of the CD=1 or BAD cache stuff; I agree with >Andrew and Mark; and I think that these approaches for caches with >different sets of trust anchors and cooperating to some degree (over >untrusted channels?) is not something that should be done in a couple of >lines in the dnssec-bis-updates document. I've actually tried to do in on more than a few lines, because I knew it was complex, but got push back to "make it simpler". I agree that it can't be done in a few lines, (although I think the pseudo code I sent out in May does a pretty good job of it), and I guess I'm done trying. Thanks for your indulgence. Mike >Best regards, > Wouter >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v2.0.14 (GNU/Linux) >Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > >iEYEARECAAYFAkwV2e8ACgkQkDLqNwOhpPjimACfcxk6jGmQpvkqIfjpmb1eXQtn >wg4AnRKyyK9DotpUoqbw76EyJ6nXfCF/ >=hINg >-----END PGP SIGNATURE----- From owner-namedroppers@ops.ietf.org Mon Jun 14 08:59:33 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173823A69EA; Mon, 14 Jun 2010 08:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.148 X-Spam-Level: X-Spam-Status: No, score=-4.148 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBhzoRymezq6; Mon, 14 Jun 2010 08:59:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B8393A69E3; Mon, 14 Jun 2010 08:59:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOBw5-000BjJ-HG for namedroppers-data0@psg.com; Mon, 14 Jun 2010 15:50:53 +0000 Received: from [193.1.169.37] (helo=cali.ucd.ie) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOBvw-000Beu-6M for namedroppers@ops.ietf.org; Mon, 14 Jun 2010 15:50:44 +0000 Received: from conversion-daemon.cali.ucd.ie by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0L4000601HBWGG00@cali.ucd.ie> (original mail from Niall.oReilly@ucd.ie) for namedroppers@ops.ietf.org; Mon, 14 Jun 2010 16:50:41 +0100 (IST) Received: from [10.0.1.177] (bark.no8.be [83.141.81.52]) by cali.ucd.ie (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTPSA id <0L4000KB9HBQT100@cali.ucd.ie>; Mon, 14 Jun 2010 16:50:32 +0100 (IST) Date: Mon, 14 Jun 2010 16:50:13 +0100 From: Niall O'Reilly Subject: Re: [dnsext] RE: On adoption of two drafts ... In-reply-to: <201005191433.QAA13726@TR-Sys.de> To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= Cc: segred@ics.forth.gr, namedroppers@ops.ietf.org, =?UTF-8?B?IuWnmuWBpeW6tw==?= =?UTF-8?B?IChZQU8gSmlhbmthbmcpIg==?= , Suzanne Woolf , lee@cnnic.cn Message-id: <4C164FB5.3050108@ucd.ie> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT References: <201005191433.QAA13726@TR-Sys.de> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-IE.utf8; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Alfred, I appreciate your careful observations, and feel they deserve a response. I'm not sure I'm the best person to do that, but as no-one else has just yet, here goes. [In context] On 19/05/10 15:33, Alfred � wrote: > Vaggelis Segredakis wrote: > >> In the .gr ccTLD we have presented in 2005 the option of registering >> IDN domain names in Greek. The Greek language requires for all >> multi syllabus words to have an accent sign called "tonos" over >> one of the letters. [...] > > Unfortunately, hereby we apparently are back at one of the greatest > ratholes ever seen in DNS internationalization. Hopefully not. > Wasn't it one of the fundamental characteristics of the DNS that > DNS labels are _not_ "words" (in any language), but simply abstract > _identifiers_ in a more user friendly alphabet than IP addresses? Yes. > I vaguely recall from IDNA discussion on the use of IDNA with the > Arabic languages (and scripts) that it had been reported to the > IETF community that "The hardest part in this work was to escape > from the (mis)concept of a couple of stakeholders that DNS labels > were 'words' in one of the Arabic languages and therefore linguistic > rules would have to be superimposed on DNS labels." > > If application of a linguistic rule for Greek is the sole background > of your requirement, aren't we in a similar position again? > > I do not support work on DNS protocol changes based on such > specific (and arguably inappropriate) reasoning. If we shall > undertake such effort, a "neutral" problem statement needs to be > formulated and taken as the _only_ base for the subsequent work. Yes, but ... I expect that such a neutral problem statement will have to allow registries to offer clusters or bundles of labels which meet the anticipated or actual demand of the marketplace in which each registry operates. This demand will inevitably be shaped by the cultural (including linguistic) background of the target registrant community. As I see it, how a registry addresses the cultural parameters of its market is a matter to be dealt with in the respective naming policy (Charte de Nommage, comme le disent les gens de l'AFNIC), and must remain out of scope here. On the other hand, I would expect an appropriate neutral problem statement to take account of the size of any cluster or bundle which is likely to arise in the field. > IMO, for any purpose to be discussed here, the definition of DNS > labels from the basic DNS standards should be taken for given, > and this WG should refrain from imposing semantic rules of any kind > on DNS labels. I think I agree. > In other words: DNS Protocol mechanisms should work > with any semantics imposed in a uniform manner by other bodies on > *all* DNS labels. Scoped semantics of specific classes of DNS labels > MUST remain out of scope of the discussion in this WG. I'm not sure that this is indeed the same thing "in other words", as you suggest. Perhaps I've misunderstood the scope of that "*all*". It seem to me that support for (a term which I prefer to "imposition of") particular semantics will vary between registries, not least because of different demand from their respective markets. For example, I don't imagine that Han-based IDN is a high priority for the .GR ccTLD. In other words, as I see it, local semantics may apply, but will be a local, operational matter, and not a protocol matter. Is that what you meant? IMO, the only export from the cultural/semantic context of a particular registry's naming policy to this WG's attempt to make sense of bundles or clusters of domain names should be the issue of scale, which is likely to show up as both "label multiplicity" and "fanout". > If we agree on a generally desirable scheme/model of "equivalence" > of domain _names_ (any restriction to equivalence of single _labels_ > within a zone IMO is not worth such effort), IMO also. > it may happen that > someone can apply the ensuing protocol extensions for purposes not > amenable to consensus in the IETF; they may deploy such usage, > but that MUST NOT become topic of discussion in this WG, if we > actually want to arrive at success *within any finite time span*. Absolutely. > A few general thoughts: > > The examples shown so far seem to indicate that any generally > useful equivalence scheme needs to admit composition and iteration. > I.e., it must be possible to store an equivalence for a single label > that somehow automagically applies to all compositions containing > the domain name which an instance of the equivalence mechanism is > regarded to have as its owner, and such equivalences can happen > to be 'crossed' multiple times in the resolution process of a multi- > label DNS name. +1 > The variety, complexity, and context-specifity of equivalence 'nets' > envisioned makes it clear that neither end system resolvers nor > caches should be burdened with extraneous storing and/or processing > requirements for equivalences. Equivalences mentioned so far > apparently are neither generic nor symmetrical. > This IMO implies that these 'equivalences' are not equivalence > relations in a mathematical (set theoretical) sense; I think this is arguable, but that probably doesn't matter right now. > each instance > of an 'equivalence class' instead needs to be represented by a > simply-connected, loop-free, directed graph with a 'canonical' name > form (chosen by the entity defining the instance of equivalence) > at its (inverted) root. Makes sense to me. > Each byte of information on any instance of equivalence must be located > in the respective authoritative zones, and the nodes and arcs of that > graph must be represented "in the DNS way", to allow transporting the > information from the authorities to the resolvers in the standard way > that admits "vouching" for these components of the graph by normal > DNSSEC. In this model, the nodes in the equivalence graphs are > represented by DNS nodes, and a directed arc ("arrow") in an > equivalence graph is represented by an RR at the 'source' of the arc, > pointing to the 'target' of the arc. > (This is the model already present in CNAME and DNAME -- set aside > synthetic CNAME generation for DNAME.) We may need to make a distinction between "node data" and "DNS metadata" in interpreting the phrase, "Each byte of information". > Kind regards, > Alfred. The same. Niall From owner-namedroppers@ops.ietf.org Mon Jun 14 09:21:13 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633E53A68FB; Mon, 14 Jun 2010 09:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.364 X-Spam-Level: * X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xCAgZI-6F4S; Mon, 14 Jun 2010 09:21:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 651BE3A67C2; Mon, 14 Jun 2010 09:21:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOCLA-000GGF-Tv for namedroppers-data0@psg.com; Mon, 14 Jun 2010 16:16:48 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOCL6-000GEC-4c for namedroppers@ops.ietf.org; Mon, 14 Jun 2010 16:16:44 +0000 Received: by pwj1 with SMTP id 1so1782675pwj.11 for ; Mon, 14 Jun 2010 09:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DCFQQLizP0WLgh5XdQV9pDCFmQefiJQe2h4vqVQRPOk=; b=ewMUZDtu0E6C0dSvESsrMTkL0n4OqHU+u8W4sC2Wyp5/24rsZfjuAEclOU2l96jLVJ pjhVvn2NLZ0hIAhcZ1EMQY+Y9CtK5CYDelELRqF1ufuYtK5u33D0XbJdyj/zIIzD8RMk ex5ILVvCa5ugWr8HaJURcr1FhqufpmA+37bxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cRug3iRZwHu7lSyZZBQeVYu9Xjv6oLNbaJXedTxVVE/g7FepRPrpyfbxQD9F0wEslq xAZX+ua61LbXq3nsY5vaDw9gMZM1WeSIleUx9sySIzwqIMieBQ6KZK0nVf8gGW3hY/1X /8FFteplOH8HzDLcHMl0ptFc/9RHVejt3c/NA= MIME-Version: 1.0 Received: by 10.143.21.30 with SMTP id y30mr4292607wfi.127.1276532199779; Mon, 14 Jun 2010 09:16:39 -0700 (PDT) Received: by 10.142.98.10 with HTTP; Mon, 14 Jun 2010 09:16:39 -0700 (PDT) In-Reply-To: <4C12DB6B.3060308@necom830.hpcl.titech.ac.jp> References: <4C12DB6B.3060308@necom830.hpcl.titech.ac.jp> Date: Mon, 14 Jun 2010 09:16:39 -0700 Message-ID: Subject: Re: [dnsext] URL friendly use of SRV RR From: Ted Hardie To: Masataka Ohta Cc: IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Ohta-san, I do not think I understand the proposal. Some clarifying questions below: 2010/6/11 Masataka Ohta : > How about this idea? > > The problem of SRV is that it is *NOT* URL friendly that web people > should have no idea on how to use it. > > While SRV is designed following the syntax of IP as: > > =A0 =A0 =A0 =A0_Service._Proto.Name TTL Class SRV Priority Weight Port Ta= rget > > most applications know and by number from > the beginning that there is no room to convert them to ASCII > strings. > > The only notable exception, of course, is when URLs are used. > However, as the syntax of Internet URLs is: > > =A0 =A0 =A0 =A0://:@:/ > > applications have no information on the ASCII representation of > Proto. > > So, SRV should be used as: > > =A0 =A0 =A0 =A0_Scheme.Name TTL Class SRV Priority Weight Proto Port Targ= et > So we would create a new RR like SRV which changed the syntax from _Service._Proto.Name to _Scheme.Name? This would allow the DNS to answer the question: what target(s) are available for scheme imap at Name? > where Weight and Proto are 8 bit quantities to make the RR > format compatible to todays. > > Then, if we recommend web people try SRV when "Name" is not > resolved to addresses, they should be happy to use it. > So the logic would be first try to find an A or AAAA record looking up the host portion of a URL, then look for this SRVbis? regards, Ted Hardie > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0Masataka Ohta > > From owner-namedroppers@ops.ietf.org Mon Jun 14 10:45:43 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440BC28C0E7; Mon, 14 Jun 2010 10:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QNKmSpD+c3V; Mon, 14 Jun 2010 10:45:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA4B53A690C; Mon, 14 Jun 2010 10:45:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OODdp-0002wl-K3 for namedroppers-data0@psg.com; Mon, 14 Jun 2010 17:40:09 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OODdk-0002vl-V1 for namedroppers@ops.ietf.org; Mon, 14 Jun 2010 17:40:05 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANYFFkxAZnwN/2dsb2JhbACfA3GmcJoGgnuCHwQ X-IronPort-AV: E=Sophos;i="4.53,415,1272844800"; d="scan'208";a="121451529" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 14 Jun 2010 17:40:03 +0000 Received: from ams3-vpn-dhcp4690.cisco.com (ams3-vpn-dhcp4690.cisco.com [10.61.82.81]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5EHe20r015156; Mon, 14 Jun 2010 17:40:03 GMT Subject: Re: [dnsext] URL friendly use of SRV RR Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Mon, 14 Jun 2010 19:40:01 +0200 Cc: Masataka Ohta , IETF DNSEXT WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C12DB6B.3060308@necom830.hpcl.titech.ac.jp> To: Ted Hardie X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Ohta-san, Is it the URI RR-Type that I wrote about in a draft (but never finished) = that you are looking for? http://stupid.domain.name/ietf/draft-faltstrom-uri-04.txt I am, and I know Olaf is, happy to push this. What do other people say? Patrik On 14 jun 2010, at 18.16, Ted Hardie wrote: > Ohta-san, >=20 > I do not think I understand the proposal. Some clarifying > questions below: >=20 > 2010/6/11 Masataka Ohta : >> How about this idea? >>=20 >> The problem of SRV is that it is *NOT* URL friendly that web people >> should have no idea on how to use it. >>=20 >> While SRV is designed following the syntax of IP as: >>=20 >> _Service._Proto.Name TTL Class SRV Priority Weight Port Target >>=20 >> most applications know and by number from >> the beginning that there is no room to convert them to ASCII >> strings. >>=20 >> The only notable exception, of course, is when URLs are used. >> However, as the syntax of Internet URLs is: >>=20 >> ://:@:/ >>=20 >> applications have no information on the ASCII representation of >> Proto. >>=20 >> So, SRV should be used as: >>=20 >> _Scheme.Name TTL Class SRV Priority Weight Proto Port Target >>=20 >=20 > So we would create a new RR like SRV which changed the syntax from > _Service._Proto.Name to _Scheme.Name? This would allow the DNS > to answer the question: what target(s) are available for scheme imap > at Name? >=20 >> where Weight and Proto are 8 bit quantities to make the RR >> format compatible to todays. >>=20 >> Then, if we recommend web people try SRV when "Name" is not >> resolved to addresses, they should be happy to use it. >>=20 > So the logic would be first try to find an A or AAAA record looking up > the host portion of a URL, then look for this SRVbis? >=20 > regards, >=20 > Ted Hardie >=20 >=20 >=20 >> Masataka Ohta >>=20 >>=20 >=20 From owner-namedroppers@ops.ietf.org Mon Jun 14 11:44:11 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059AB3A6977; Mon, 14 Jun 2010 11:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.517 X-Spam-Level: ** X-Spam-Status: No, score=2.517 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ElD-nQkqQQw; Mon, 14 Jun 2010 11:44:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 835E93A6899; Mon, 14 Jun 2010 11:44:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOEZI-000BcM-Eq for namedroppers-data0@psg.com; Mon, 14 Jun 2010 18:39:32 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOEZF-000Bbv-Lk for namedroppers@ops.ietf.org; Mon, 14 Jun 2010 18:39:29 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 85CED1ECB41F for ; Mon, 14 Jun 2010 18:39:27 +0000 (UTC) Date: Mon, 14 Jun 2010 14:39:25 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Setting CD=1 on upstream queries Message-ID: <20100614183925.GG1471@shinkuro.com> References: <4C15D9EF.9050907@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Michael, On Mon, Jun 14, 2010 at 10:25:58AM -0400, Michael StJohns wrote: > > I've actually tried to do in on more than a few lines, because I > knew it was complex, but got push back to "make it simpler". I > agree that it can't be done in a few lines, (although I think the > pseudo code I sent out in May does a pretty good job of it), and I > guess I'm done trying. In case this hasn't been clear from the interactions we've had, the more than a few lines that you suggested did not raise objections because they were too long. It was because they were too hard to understand, which is what the "simpler" request was, I think, about. The pseudo-code that you sent entails a difference with RFC 4035 that, as near as I can tell, does not attract wide support, because it is a series of if/thens with pure entailment in them. You argue, of course, that that's what the specification should be doing: if you cannot capture the rules in a set of if/then statements, then the rules are underspecified. I have a great deal of personal sympathy with this view, but in the absence of a bunch more people saying they're willing to alter the meaning of 4035 in the way you seem to want, I don't think we're in a position to make that change. Moreover, we actually have to produce text, not just pseudo-code, and it would appear that there were not only disagreements about whether we could do what your pseudo-code said, but also the right way to capture that pseudo-code as prose. That prose has to specify the result in question, not the mechanism by which it is achieved. I think that one issue with the pseudo-code is that it tends to be read as the latter, not the former. Do I take the end of the paragraph above to suggest that you no longer want to work on text for the draft, and that your previous objections to the draft going ahead without the change you were proposing are lifted? Thanks, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dnsext-archive@ietf.org Mon Jun 14 19:44:31 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8153A67D7 for ; Mon, 14 Jun 2010 19:44:31 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: dnsext-archive VIAGRA \256 Official Site -23%\n X-Spam-Flag: NO X-Spam-Score: -5.673 X-Spam-Level: X-Spam-Status: No, score=-5.673 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id racZ-EcvRYm8 for ; Mon, 14 Jun 2010 19:44:18 -0700 (PDT) Received: from bzq-79-179-38-52.red.bezeqint.net (bzq-79-179-38-52.red.bezeqint.net [79.179.38.52]) by core3.amsl.com (Postfix) with SMTP id 2D0793A67AD for ; Mon, 14 Jun 2010 19:44:16 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive VIAGRA ® Official Site -23% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100615024417.2D0793A67AD@core3.amsl.com> Date: Mon, 14 Jun 2010 19:44:16 -0700 (PDT)
Click here.

Dear dnsext-archive@ietf.org
From owner-namedroppers@ops.ietf.org Tue Jun 15 02:05:19 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8013D28C103; Tue, 15 Jun 2010 02:05:19 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.042 X-Spam-Level: ** X-Spam-Status: No, score=2.042 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1N+Fh6T-GWq; Tue, 15 Jun 2010 02:05:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F1A728C102; Tue, 15 Jun 2010 02:05:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OORw7-0006kN-S1 for namedroppers-data0@psg.com; Tue, 15 Jun 2010 08:55:59 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OORw3-0006ja-Gy for namedroppers@ops.ietf.org; Tue, 15 Jun 2010 08:55:55 +0000 Received: (eyou send program); Tue, 15 Jun 2010 16:55:52 +0800 Message-ID: <476592152.09177@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 15 Jun 2010 16:55:52 +0800 Message-ID: <0741E8B908DF4F8880C02861749E0B2D@LENOVO47E041CF> From: "Jiankang YAO" To: Subject: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-02.txt Date: Tue, 15 Jun 2010 16:56:15 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_008A_01CB0CAB.AB03B940" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_008A_01CB0CAB.AB03B940 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCiAgIG5ldyB2ZXJzaW9uIG9mIGJuYW1lIGRyYWZ0IGlzIHB1Ymxpc2hlZCB3 aXRoIHNvbWUgaW1wcm92ZWQgdGV4dCBhbmQgZG5zc2VjIGRpc2N1c3Npb24uDQoNCiAgYW55IGNv bW1lbnRzIGFyZSB3ZWxjb21lLg0KDQp0aGFua3MuDQoNCg0KSmlhbmthbmcgWWFvDQoNCg0KLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206IDxJbnRlcm5ldC1EcmFmdHNAaWV0Zi5v cmc+DQpUbzogPGktZC1hbm5vdW5jZUBpZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTUs IDIwMTAgOTozMCBBTQ0KU3ViamVjdDogSS1EIEFjdGlvbjpkcmFmdC15YW8tZG5zZXh0LWJuYW1l LTAyLnR4dCANCg0KDQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiANCj4gVGl0bGUgICAgICAg ICAgIDogQnVuZGxlIEROUyBOYW1lIFJlZGlyZWN0aW9uDQo+IEF1dGhvcihzKSAgICAgICA6IEou IFlhbywgZXQgYWwuDQo+IEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LXlhby1kbnNleHQtYm5hbWUt MDIudHh0DQo+IFBhZ2VzICAgICAgICAgICA6IDEyDQo+IERhdGUgICAgICAgICAgICA6IDIwMTAt MDYtMTQNCj4gDQo+IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBETlMgUmVzb3VyY2UgUmVj b3JkIGNhbGxlZCAiQk5BTUUiLCB3aGljaA0KPiBwcm92aWRlcyB0aGUgY2FwYWJpbGl0eSB0byBt YXAgaXRzZWxmIGFuZCBpdHMgc3VidHJlZSBvZiB0aGUgRE5TIG5hbWUNCj4gc3BhY2UgdG8gYW5v dGhlciBkb21haW4uICBJdCBkaWZmZXJzIGZyb20gdGhlIENOQU1FIHJlY29yZCB3aGljaCBvbmx5 DQo+IG1hcHMgYSBzaW5nbGUgbm9kZSBvZiB0aGUgRE5TIG5hbWUgc3BhY2UsIGZyb20gdGhlIERO QU1FIHdoaWNoIG9ubHkNCj4gbWFwcyB0aGUgc3VidHJlZSBvZiB0aGUgRE5TIG5hbWUgc3BhY2Ug dG8gYW5vdGhlciBkb21haW4uDQo+IA0KPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBp czoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteWFvLWRuc2V4 dC1ibmFtZS0wMi50eHQNCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUg YnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy8NCj4gDQo+IEJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21w bGlhbnQgbWFpbCByZWFkZXINCj4gaW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRy aWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGUNCj4gSW50ZXJuZXQtRHJhZnQuDQo+DQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4gSS1E LUFubm91bmNlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaS1kLWFubm91bmNlDQo+IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3 LmlldGYub3JnL3NoYWRvdy5odG1sDQo+IG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFk b3ctc2l0ZXMudHh0DQo+ ------=_NextPart_000_008A_01CB0CAB.AB03B940 Content-Type: text/plain; name="draft-yao-dnsext-bname-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-yao-dnsext-bname-02.txt" Content-Type: text/plain Content-ID: <2010-06-14182757.I-D@ietf.org> ------=_NextPart_000_008A_01CB0CAB.AB03B940-- From dnsext-archive@ietf.org Tue Jun 15 06:44:03 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ACF43A6A63 for ; Tue, 15 Jun 2010 06:44:03 -0700 (PDT) X-Quarantine-ID: <1XDhE7vYgV+2> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: dnsext-archive VIAGRA \256 Official Site -36%\n X-Spam-Flag: NO X-Spam-Score: -22.845 X-Spam-Level: X-Spam-Status: No, score=-22.845 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XDhE7vYgV+2 for ; Tue, 15 Jun 2010 06:44:02 -0700 (PDT) Received: from 43-23-134-95.pool.ukrtel.net (43-23-134-95.pool.ukrtel.net [95.134.23.43]) by core3.amsl.com (Postfix) with SMTP id 445C23A67D6 for ; Tue, 15 Jun 2010 06:44:01 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive VIAGRA ® Official Site -36% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100615134401.445C23A67D6@core3.amsl.com> Date: Tue, 15 Jun 2010 06:44:01 -0700 (PDT)
Click here.

Dear dnsext-archive@ietf.org
From owner-namedroppers@ops.ietf.org Tue Jun 15 21:30:37 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779253A6949; Tue, 15 Jun 2010 21:30:37 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 3.303 X-Spam-Level: *** X-Spam-Status: No, score=3.303 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxwEGSbCC06l; Tue, 15 Jun 2010 21:30:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 557573A67F2; Tue, 15 Jun 2010 21:30:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOk8f-000B3n-BS for namedroppers-data0@psg.com; Wed, 16 Jun 2010 04:22:09 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOk8c-000B3a-Ls for namedroppers@ops.ietf.org; Wed, 16 Jun 2010 04:22:07 +0000 Received: (eyou send program); Wed, 16 Jun 2010 12:21:58 +0800 Message-ID: <476662118.26775@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 16 Jun 2010 12:21:58 +0800 Message-ID: <61575D2F242046DFA1109CD4AFCBB098@LENOVO47E041CF> From: "Jiankang YAO" To: "George Barwood" , Cc: "Suzanne Woolf" References: <476592152.09177@cnnic.cn> <476596425.17068@cnnic.cn> Subject: Re: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-02.txt Date: Wed, 16 Jun 2010 12:22:03 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkdlb3JnZSBCYXJ3b29kIiA8 Z2VvcmdlLmJhcndvb2RAYmx1ZXlvbmRlci5jby51az4NClRvOiAiSmlhbmthbmcgWUFPIiA8eWFv amtAY25uaWMuY24+OyA8bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXks IEp1bmUgMTUsIDIwMTAgNTo0MiBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIEZ3OiBJLUQgQWN0 aW9uOmRyYWZ0LXlhby1kbnNleHQtYm5hbWUtMDIudHh0IA0KDQoNCj4gVGhlIGRyYWZ0IHN0YXRl cw0KPiANCj4gIldpdGhvdXQgdGhlIEJOQU1FIG1lY2hhbmlzbSwgY3VycmVudCBtZWNoYW5pc21z DQo+IHN1Y2ggYXMgRE5BTUUgb3IgQ05BTUUgYXJlIG5vdCBlbm91Z2ggY2FwYWJsZSB0byBzb2x2 ZSBhbGwgdGhlDQo+IHByb2JsZW1zIHdpdGggdGhlIGVtZXJnZW5jZSBvZiBpbnRlcm5hdGlvbmFs aXplZCBkb21haW4gbmFtZXMuIg0KPiANCj4gQ2FuIHlvdSBnaXZlIGEgbW9yZSBkZXRhaWxlZCBh Y2NvdW50IG9mIHdoYXQgdGhlIHByb2JsZW1zIGFyZSwNCj4gYW5kIGhvdyB0aGV5IGNhbm5vdCBi ZSBzb2x2ZWQgYnkgb3RoZXIgbWVhbnM/DQoNCg0KdGhlcmUgd2lsbCBoYXZlIGEgbmV3IHByb2Js ZW0gc3RhdGVtZW50IGRyYWZ0LCB3aGljaCBkaXNjdXNzIHRoZSByZWxhdGVkIHNpdHVhdGlvbnMu DQoNCkkgdGhpbmsgdGhhdCBzdXphbm5lIFdvb2xmIHdpdGggY28tYXV0aG9yIHdpdGggbWUsIHhp YW9kb25nIGFuZCBOaWFsbCB3aWxsIHVwZGF0ZSBpdCBzb29uLg0K From owner-namedroppers@ops.ietf.org Wed Jun 16 04:30:57 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2B6B3A6B2C; Wed, 16 Jun 2010 04:30:56 -0700 (PDT) X-Quarantine-ID: <4j-+iQjfzuEw> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 3.387 X-Spam-Level: *** X-Spam-Status: No, score=3.387 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j-+iQjfzuEw; Wed, 16 Jun 2010 04:30:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6483828C146; Wed, 16 Jun 2010 04:30:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOqhO-000C5M-7H for namedroppers-data0@psg.com; Wed, 16 Jun 2010 11:22:26 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOqhI-000C3N-Qn for namedroppers@ops.ietf.org; Wed, 16 Jun 2010 11:22:23 +0000 Received: (eyou send program); Wed, 16 Jun 2010 19:21:50 +0800 Message-ID: <476687310.07502@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 16 Jun 2010 19:21:50 +0800 Message-ID: From: "Jiankang YAO" To: "George Barwood" , References: <476592152.09177@cnnic.cn> <833E80C68446499A9F68638299F2F349@local> Subject: Re: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-02.txt Date: Wed, 16 Jun 2010 19:21:41 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkdlb3JnZSBCYXJ3b29kIiA8 Z2VvcmdlLmJhcndvb2RAYmx1ZXlvbmRlci5jby51az4NClRvOiAiSmlhbmthbmcgWUFPIiA8eWFv amtAY25uaWMuY24+OyA8bmFtZWRyb3BwZXJzQG9wcy5pZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXks IEp1bmUgMTUsIDIwMTAgNTo0MiBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIEZ3OiBJLUQgQWN0 aW9uOmRyYWZ0LXlhby1kbnNleHQtYm5hbWUtMDIudHh0IA0KDQo+IEFzIGZhciBhcyBJIGNhbiBz ZWUsIEROQU1FIGlzIGNhcGFibGUgb2YgcHJldmVudGluZyBhbiBleHBvbmVudGlhbCBpbmNyZWFz ZQ0KPiBpbiByZWNvcmRzLCBhbmQgdGhlIG5lY2Vzc2l0eSBvZiBtaXJyb3JpbmcgYW55IGRhdGEg cmVjb3JkcyBpbiB0aGUgem9uZSBhcGV4DQo+IHRoYXQgYXJlIG5vdCByZWRpcmVjdGVkIGJ5IERO QU1FIGlzIGEgcmVsYXRpdmVseSBtaW5vciBhZG1pbmlzdHJhdGl2ZSBpbmNvbnZlbmllbmNlLA0K PiB0aGF0IGNhbiBwcm9iYWJseSBiZSBtaXRpZ2F0ZWQgYnkganVkaWNpb3VzIHVzZSBvZiB0aGUg JElOQ0xVREUgZGlyZWN0aXZlLg0KPiANCg0KdGhlcmUgaXMgYSBkbmFtZSBkaXNjdXNzaW9uIHJl bGF0ZWQgdG8gdGhlIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC15YW8tZG5z b3AtaWRudGxkLWltcGxlbWVudGF0aW9uLTAxLnR4dA0KaW4gZG5zb3AgbGlzdC4gIHlvdSBtYXkg c2VlIGl0IGluIGRuc29wIGxpc3QNCg0KPiBUaGUgZHJhZnQgZG9lcyBub3Qgc2VlbSB0byBtZW50 aW9uIHRoZSBpbmNvbXBhdGliaWxpdHkgb2YgQk5BTUUgd2l0aCBleGlzdGluZyB2YWxpZGF0aW5n DQo+IHJlc29sdmVycy4gSSB0aGluayBzb21lIGRpc2N1c3Npb24gb2YgaG93IGEgdHJhbnNpdGlv biBtaWdodCBiZSBtYW5hZ2VkICggbmV3IGFsZ29yaXRobXM/KSwNCg0KZG8geW91IHdhbnQgdG8g bWFrZSB0aGUgZXhpc3RpbmcgdmFsaWRhdGluZyAgcmVzb2x2ZXJzIHRvIHJlY29nbml6ZSB0aGUg Ym5hbWU/DQppZiB5ZXMsIHlvdSBuZWVkIHRvIHVwZGF0ZSB0aGUgdmFsaWRhdGluZyByZXNvbHZl cnMgdG8gc3VwcG9ydCBibmFtZS4NCmlmIG5vdCwgdGhlICBleGlzdGluZyB2YWxpZGF0aW5nICBy ZXNvbHZlcnMgd2lsbCBkbyBpdCBhcyBpZiB0aGVyZSB3ZXJlIG5vdCBibmFtZS4NCnNvIHRoZSBk cmFmdCBzYWlkICIgSW4gb3JkZXIgdG8gbWFrZSBCTkFNRSB2YWxpZCBpbiBETlNTRUMNCiAgIHZl cmlmaWNhdGlvbiwgdGhlIEROU1NFQyBlbmFibGVkIHJlc29sdmVycyBhbmQgc2VydmVycyBNVVNU IHN1cHBvcnQNCiAgIEJOQU1FLiAiDQoNCnlvdXIgcG9zc2libGUgc3VnZ2VzdGlvbiAgKCBuZXcg YWxnb3JpdGhtcz8pIGFsc28gbmVlZCB1cGRhdGUgdGhlIHJlc29sdmVycyBvciBzZXJ2ZXJzLg0K DQppZiB5b3UgZG9lc24ndCB1cGRhdGUgYW55dGhpbmcgYnV0IG1ha2UgdGhlIGV4aXN0aW5nIHZh bGlkYXRpbmcgIHJlc29sdmVycyB0byByZWNvZ25pemUgdGhlIGJuYW1lLCBpdCBzZWVtcyB0byBi ZSBpbXBvc3NpYmxlIHRvIGRvIHNvLg0KDQpkbyB1IGhhdmUgZ29vZCBpZGVhIGFib3V0IGl0Pw0K DQoNCg0K From owner-namedroppers@ops.ietf.org Wed Jun 16 13:22:51 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6480228C193; Wed, 16 Jun 2010 13:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A35b8i-9y5-z; Wed, 16 Jun 2010 13:22:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 237A928C172; Wed, 16 Jun 2010 13:22:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOz32-000Jav-Sq for namedroppers-data0@psg.com; Wed, 16 Jun 2010 20:17:20 +0000 Received: from [140.186.190.103] (helo=haybaler.sackheads.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOz2y-000JaM-D9 for namedroppers@ops.ietf.org; Wed, 16 Jun 2010 20:17:16 +0000 Received: from localhost (localhost.sackheads.org [127.0.0.1]) by haybaler.sackheads.org (Postfix) with ESMTP id E649E28A37; Wed, 16 Jun 2010 16:17:14 -0400 (EDT) Authentication-Results: haybaler.sackheads.org; domainkeys=pass (testing) header.from=john@sackheads.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1276719435; bh=fIa8fRAlK8jyv5L+AxW29qUQLS/9L+C120K4H2xhKqg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Fis6k44tbKRt0fI1QPCdXYoBe9Gu1/TytARN5/N/aAInT1gmxRN76gtRtjSJtPLhr /cOohOfkZkmIfRfFt4yTPIGKG/hR8yzCAmSn8oQDEqNMHktmFEFBPpsF9Df7Oc7g23 ZtfcpcadMqq4z4ayc7hBsx/NGh90iKdJVf9lSDxM= Received: from haybaler.sackheads.org ([127.0.0.1]) by localhost (haybaler.sackheads.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NG4hFfrd2I0X; Wed, 16 Jun 2010 16:17:14 -0400 (EDT) Received: by haybaler.sackheads.org (Postfix, from userid 65534) id A23C828A36; Wed, 16 Jun 2010 16:17:14 -0400 (EDT) Received: from [172.19.33.4] (unknown [72.246.0.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: john@sackheads.org) by haybaler.sackheads.org (Postfix) with ESMTP id D8BDF28597; Wed, 16 Jun 2010 16:17:13 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=haybaler; d=sackheads.org; c=nofws; q=dns; h=dkim-signature:subject:mime-version:content-type:from: in-reply-to:date:cc:content-transfer-encoding:message-id:references:to:x-mailer; b=ocXt1DFhPwsGEBU4MWrX/YIQ+Dfp+GEFbA0qydpKAw4iWc9zZ0AwtflwO08LBCeCG K6AtcPkyNOOUIMy8wmXyQHYyvlUwjzPothwX1gOyNzWXENsGCWx1pYV5CItxXUzHJWJ Il14HXhEUX4btkg2kZrUQPDbHLxEhYPf9zn4YUA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1276719434; bh=fIa8fRAlK8jyv5L+AxW29qUQLS/9L+C120K4H2xhKqg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=YjDpW3cT8UXg38NoRHWe5Qv61OOTTAt3QJGrtSco0AbXp+N3+11kkAz08asPAmWv5 Q4SII6IH5Jn79YnVghY8drzc6q3nfbUstW6J53x7LDchQmMjv4nd8CbnpiSaZAXxUG 1VqkNnvwyZthamqWx2xRt0gELNxwH49X2EMo23kA= Subject: Re: The third poison (was Re: [dnsext] Re: draft-vandergaast-edns-client-ip-01) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: John Payne In-Reply-To: Date: Wed, 16 Jun 2010 16:17:10 -0400 Cc: Nicholas Weaver , Jim Reid , IETF DNSEXT WG Content-Transfer-Encoding: quoted-printable Message-Id: <624D7D11-76F9-4317-9470-47C4CCBD065C@sackheads.org> References: To: Ted Hardie X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 2, 2010, at 1:51 PM, Ted Hardie wrote: > Just to clarify, there is another poison.... >=20 > On Sat, May 29, 2010 at 2:18 PM, Nicholas Weaver > wrote: >=20 >> Pick your poison: >>=20 >> a: Enable these tricks to work with 3rd party resolvers >>=20 >> or >>=20 >> b: Accept a world where third party resolvers WILL produce inferior = results: >> http://www.sajalkayan.com/in-a-cdnd-world-opendns-is-the-enemy.html >>=20 >>=20 >> Can any of those who oppose this solution make a compelling = explanation why B is preferable, because from as far as I can tell, ANY = solution for A is opposed by a vocal portion of this group? >>=20 >=20 > As a third option, you can make these DNS tricks opt-in from the node > originating > the query, rather than deciding for it what the right query should be. It is opt-in.... I don't get why you don't think it is. Stub resolvers can add the option. Stub resolvers that don't add the option can opt-in to a third-party = resolver that does. >=20 > Paul's point is that this is basically an addition to the q-tuple; = this option > adds network topology to the q-tuple and asks the authoritative to > consider that in constructing the answer. If we are to do that, I = think > the right place to do it is at the node emitting the query. First and = foremost > because it is the only node that knows whether or not the node cares > about topology being used to construct the answer. There are many > applications for which this data is not useful or important, and = turning > it on only when needed is more efficient; if the originating node = cares > about that efficiency it can use it only when the application requires = it. >=20 > Second, the originating node may have data on what the appropriate > piece of topology to use to augment the q-tuple might be. Given the > extent of tunneling used in the Internet today, this is not trivial. = To take > one example discussed before, a host with a mobile IP tunnel back to > a home network may consistently use the home network's DNS servers > but use the outbound interface on the visited network to actually = source > application traffic (to avoid triangle routing for jitter-sensitve = traffic > like VoIP traffic, for example). If it can pass the home network > the visited network subnet it wishes to use, the home network's > DNS servers can use that to construct this augmented query. > Note that this particular use case applies even if the node = originating > the query asks the authoritative server itself, using the tunnel = interface > to source the DNS query. >=20 > Third, the node originating the query is the only node which can > reasonably determine whether providing topology is a privacy issue. > That issue has been discussed at length, but the opt-out nature > of the current solution remains deficient--there is no way for the > originating node to know whether the upstream is using this > option in the current case, so it must deal with adding this option. > That shifts a burden on to it for every query, to support the CDN's > value proposition--which is present at only some queries. >=20 > I understand that Nick and others believe that requiring opt-in > will mean this never deploys. If the end-users or OS producers > actually see the value being asserted here, I think that deployment > could occur. It also seems to me by far the better long term solution = if > we do want topology (or anything else) include in the q-tuple. The > node originating the q-tuple should originate any additional > constraints on the results it desires. That just makes sense. >=20 > regards, >=20 > Ted Hardie >=20 From owner-namedroppers@ops.ietf.org Wed Jun 16 13:22:53 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7AE328C16C; Wed, 16 Jun 2010 13:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUcfHhhU5wwa; Wed, 16 Jun 2010 13:22:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 24DC028C18A; Wed, 16 Jun 2010 13:22:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOz1C-000JPn-D5 for namedroppers-data0@psg.com; Wed, 16 Jun 2010 20:15:26 +0000 Received: from [140.186.190.103] (helo=haybaler.sackheads.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOz15-000JOt-Me for namedroppers@ops.ietf.org; Wed, 16 Jun 2010 20:15:20 +0000 Received: from localhost (localhost.sackheads.org [127.0.0.1]) by haybaler.sackheads.org (Postfix) with ESMTP id 1784028A63; Wed, 16 Jun 2010 16:15:16 -0400 (EDT) Authentication-Results: haybaler.sackheads.org; domainkeys=pass (testing) header.from=john@sackheads.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1276719316; bh=4VD8UtqYb8IhZ01Y5Fq0G+XBLyowcN7+6dvE7aHZaog=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=v0kD4e/Sd6+M33ge1JrQHkZ/Gr54M0r9Fh61s4Ty/ctyAHo4a1YO5FBtvYF5vbuGI i2cq9mi83jr1lFus4BpTLhoe88VnEWJf/MLQSHYx31dYNm9S2dv/mz+k3tBFJpmjWh gPtPxIHaPwfiSF2jG0uUn6N2+HIGmZna5iFFUJU0= Received: from haybaler.sackheads.org ([127.0.0.1]) by localhost (haybaler.sackheads.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu34q4+0W8Yk; Wed, 16 Jun 2010 16:15:15 -0400 (EDT) Received: by haybaler.sackheads.org (Postfix, from userid 65534) id CAA0E28A52; Wed, 16 Jun 2010 16:15:15 -0400 (EDT) Received: from [172.19.33.4] (unknown [72.246.0.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: john@sackheads.org) by haybaler.sackheads.org (Postfix) with ESMTP id C18ED28A37; Wed, 16 Jun 2010 16:15:14 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=haybaler; d=sackheads.org; c=nofws; q=dns; h=dkim-signature:subject:mime-version:content-type:from: in-reply-to:date:cc:message-id:references:to:x-mailer; b=L8rY/HUwkq9/rKpKeH7S4eBQo0T4ePYvnl+l5/iYupZAeQQmH2hEKKOaQMe23P5s1 5e5Vckmwl4Heyk7TV+ziYuBulzrmifz3f5L8YNeFMb8qacOXbGcLmXlcxDx2tffOfPW XTmoiZg/Bq+ZBsM6CEvWPVJCha2h8HhtKmIGxAI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1276719315; bh=4VD8UtqYb8IhZ01Y5Fq0G+XBLyowcN7+6dvE7aHZaog=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=QegWgUyGJlJtmFMDgBIXL4yawEvPSULKvZQw4+lxWsqW/zvqhWBYVS8WuWbbFYd8Z 5is89DN9hOHLZPECR7EQ7nnihR6yXMaRgbwyI8bLZHCfj0EVMVVP2vhG7gqZmIpWX8 0RsGux5H5BRZdTD/8nzFk6MzsYOVnIBxDOOs+fvo= Subject: Re: [dnsext] Re: client-subnet - questions for the authors, and outside-the-box brainstorming Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-285--88115463 From: John Payne In-Reply-To: Date: Wed, 16 Jun 2010 16:15:11 -0400 Cc: Tony Finch , namedroppers@ops.ietf.org Message-Id: <4CFDA2DA-DDCA-4D05-8765-C7D5E907B347@sackheads.org> References: To: Brian Dickson X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --Apple-Mail-285--88115463 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 3, 2010, at 11:18 AM, Brian Dickson wrote: >=20 > On Thu, Jun 3, 2010 at 11:51 AM, Tony Finch wrote: > On Wed, 2 Jun 2010, Brian Dickson wrote: > > > > Have the "big cache" (resolvers) actually be authoritative for the = CDN > > "trick" zones, by way of being slaves. >=20 > Your idea implies that you have to standardize the logic in the stunt > authoritative server so that the open resolver can do it on behalf of = the > CDN. This isn't feasible because this logic is part of the CDN's = secret > sauce, so they wouldn't want to offload it onto another company or = ossify > it into a standard. >=20 > I'd like to hear it from them, that this is the case, if it is indeed = the case. What answer to give to queries is part of the secret sauce. In many = cases, it's more than just latency, there's liveness, load, fiscal and = political considerations as well. There's no way CDNs are going to open everything to everyone to allow = this. > AFAIK, the "secret sauce" is in the "how" of doing geo-IP, and the = "how" of transmogrifying web pages on their web servers. > The DNS side, to an outside observer, looks like DNS, because it has = to. The only differences are in the quantity of entries, and the rate at = which they are updated. Also, CDNs do more than HTTP, RTSP and friends. Broadly speaking, if = your app talks IP it's a candidate for taking advantage of CDN = technology. >=20 > =20 > Your idea would also require extensions to the master > file format and to AXFR and IXFR to encode complicated information = about > the CDN's connectivity for use by the stunt DNS logic, which is a lot = less > plausible than the EDNS option we have been discussing. >=20 >=20 > Yes. However, it scales better, removes caching issues (TTLs, lack of = pre-fetch, cacheability, lack of "push"/notify), and is by its very = nature completely compatible with existing clients and resolvers (where = existing can include really old, obsolete systems). >=20 > I don't think it directly touches AXFR/IXFR. >=20 > It does, however, definitely require some means for automated = provisioning of zones, i.e. delegate, create, modify, delete, = undelegate, etc. This could be out-of-band, or more likely, via some = kind of convention to some kind of well-known child zones, along the = lines of _srv "magic". > =20 > Tony. > -- > f.anthony.n.finch http://dotat.at/ > LUNDY: EAST, VEERING SOUTH LATER, 3 OR 4. SLIGHT OR MODERATE. SHOWERS = LATER. > MODERATE OR GOOD, OCCASIONALLY POOR. >=20 > Brian --Apple-Mail-285--88115463 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jun 3, 2010, at 11:18 AM, Brian Dickson wrote:


On Thu, Jun 3, 2010 at 11:51 AM, Tony Finch <dot@dotat.at> wrote:
On Wed, 2 Jun 2010, Brian Dickson wrote:
>
> Have the "big cache" (resolvers) actually be authoritative for the CDN
> "trick" zones, by way of being slaves.

Your idea implies that you have to standardize the logic in the stunt
authoritative server so that the open resolver can do it on behalf of the
CDN. This isn't feasible because this logic is part of the CDN's secret
sauce, so they wouldn't want to offload it onto another company or ossify
it into a standard.

I'd like to hear it from them, that this is the case, if it is indeed the case.

What answer to give to queries is part of the secret sauce.  In many cases, it's more than just latency, there's liveness, load, fiscal and political considerations as well.
There's no way CDNs are going to open everything to everyone to allow this.


AFAIK, the "secret sauce" is in the "how" of doing geo-IP, and the "how" of transmogrifying web pages on their web servers.
The DNS side, to an outside observer, looks like DNS, because it has to. The only differences are in the quantity of entries, and the rate at which they are updated.

Also, CDNs do more than HTTP, RTSP and friends. Broadly speaking,  if your app talks IP it's a candidate for taking advantage of CDN technology.



 
Your idea would also require extensions to the master
file format and to AXFR and IXFR to encode complicated information about
the CDN's connectivity for use by the stunt DNS logic, which is a lot less
plausible than the EDNS option we have been discussing.


Yes. However, it scales better, removes caching issues (TTLs, lack of pre-fetch, cacheability, lack of "push"/notify), and is by its very nature completely compatible with existing clients and resolvers (where existing can include really old, obsolete systems).

I don't think it directly touches AXFR/IXFR.

It does, however, definitely require some means for automated provisioning of zones, i.e. delegate, create, modify, delete, undelegate, etc. This could be out-of-band, or more likely, via some kind of convention to some kind of well-known child zones, along the lines of _srv "magic".
 
Tony.
--
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
LUNDY: EAST, VEERING SOUTH LATER, 3 OR 4. SLIGHT OR MODERATE. SHOWERS LATER.
MODERATE OR GOOD, OCCASIONALLY POOR.

Brian

--Apple-Mail-285--88115463-- From owner-namedroppers@ops.ietf.org Wed Jun 16 13:24:52 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A5828C18E; Wed, 16 Jun 2010 13:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkbNVOnwj3oK; Wed, 16 Jun 2010 13:24:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC62E28C18D; Wed, 16 Jun 2010 13:24:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOz6m-000K7c-TW for namedroppers-data0@psg.com; Wed, 16 Jun 2010 20:21:12 +0000 Received: from [140.186.190.103] (helo=haybaler.sackheads.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOz6h-000K6g-CR for namedroppers@ops.ietf.org; Wed, 16 Jun 2010 20:21:08 +0000 Received: from localhost (localhost.sackheads.org [127.0.0.1]) by haybaler.sackheads.org (Postfix) with ESMTP id 8182C28A43; Wed, 16 Jun 2010 16:21:05 -0400 (EDT) Authentication-Results: haybaler.sackheads.org; domainkeys=pass (testing) header.from=john@sackheads.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1276719665; bh=O6OqKayw1myscQrmscE4deMdLyZVwzI118kSIvhgeyc=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TY9ugm7oVH05semxSDIV0rlVsH7/L9AuDz4FFwgL45A6+zX/4H/9ONnJjpRoXWOW7 iQMQNSq1qHZrc8nH0wj7nuPTytNsKyD5svj/z6JgoMzM/N/5vY9GG8V/ukIacuaTz9 /pV8VQIZ5dTnL5DPyraFPYpnr5qHTSGDbxy53tzU= Received: from haybaler.sackheads.org ([127.0.0.1]) by localhost (haybaler.sackheads.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DUvJdg43GMT; Wed, 16 Jun 2010 16:21:05 -0400 (EDT) Received: by haybaler.sackheads.org (Postfix, from userid 65534) id 5BC4528A37; Wed, 16 Jun 2010 16:21:05 -0400 (EDT) Received: from [172.19.33.4] (unknown [72.246.0.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: john@sackheads.org) by haybaler.sackheads.org (Postfix) with ESMTP id D376F28597; Wed, 16 Jun 2010 16:21:04 -0400 (EDT) DomainKey-Signature: a=rsa-sha1; s=haybaler; d=sackheads.org; c=nofws; q=dns; h=dkim-signature:subject:mime-version:content-type:from: in-reply-to:date:cc:content-transfer-encoding:message-id:references:to:x-mailer; b=l8Z+fPLHvMp9HUvXOyQRy0ymc05qu+N/Zjla5wqTnbVqzVnCiXSqOAy6Zh8JVQAWC 5/t4dG5KWl7czjn3iAqGCpz91yUw8alq1tPjIn01PewmujaxPc2OUScKoRAsbFsYtWv mwFHBOMLD54QJa7VNU2n126+ddBWbSKk2Ns7BnI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sackheads.org; s=haybaler; t=1276719665; bh=O6OqKayw1myscQrmscE4deMdLyZVwzI118kSIvhgeyc=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TY9ugm7oVH05semxSDIV0rlVsH7/L9AuDz4FFwgL45A6+zX/4H/9ONnJjpRoXWOW7 iQMQNSq1qHZrc8nH0wj7nuPTytNsKyD5svj/z6JgoMzM/N/5vY9GG8V/ukIacuaTz9 /pV8VQIZ5dTnL5DPyraFPYpnr5qHTSGDbxy53tzU= Subject: Re: [dnsext] Chairs statement on "client-option" debate Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: John Payne In-Reply-To: <13242.1275509728@nsa.vix.com> Date: Wed, 16 Jun 2010 16:21:03 -0400 Cc: IETF DNSEXT WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C054F87.5010608@ogud.com> <10165.1275506928@nsa.vix.com> <13242.1275509728@nsa.vix.com> To: Paul Vixie X-Mailer: Apple Mail (2.1078) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 2, 2010, at 4:15 PM, Paul Vixie wrote: >> Date: Wed, 2 Jun 2010 12:59:49 -0700 >> From: Colm MacC=E1rthaigh >>=20 >>> confidence expressed by those without a possible business motivation = in >>> the outcome would convince me moreso. >>=20 >> Me too, I would love to see an independent party run - and if not = run; >> audit - a series of experiments designed to settle these issues. ... >=20 > note that while i can imagine becoming convinced that changes to dns = would > support the web industry better, i don't think i could agree that the = web's > desires warrant the complexity now being proposed. the web is smaller = and > younger than the internet, and is only one of many internet = applications > the internet will likely outlast "the web" by many centuries. just = sayin'. CDN technology is not limited to "the web". That's where it started, = thats where most CDN bits are today, but CDN technology can be applied = to almost any IP application. From owner-namedroppers@ops.ietf.org Wed Jun 16 13:54:39 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6993A6948; Wed, 16 Jun 2010 13:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVQeYkqG1sow; Wed, 16 Jun 2010 13:54:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 30E873A69DD; Wed, 16 Jun 2010 13:54:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOzYp-000O4v-9P for namedroppers-data0@psg.com; Wed, 16 Jun 2010 20:50:11 +0000 Received: from [74.125.83.180] (helo=mail-pv0-f180.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OOzYk-000O3y-NM for namedroppers@ops.ietf.org; Wed, 16 Jun 2010 20:50:07 +0000 Received: by pvh11 with SMTP id 11so1884099pvh.11 for ; Wed, 16 Jun 2010 13:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oU7sHIrORMePXcOSGK0E/czPQbOxt2Okd+aHXavZ+IE=; b=mYa9JleMuan/s0BgpoNyRAk+d6r4fL+VsDo3V8zm5MjQaxEaaeoJanmFkvRw5jSbG2 1V1fhhVQnjezfat/AAVQht355YqJPv0xRnSji13PYov76xnqLONE/nb89r96KnJel1Zp VWaW2qJTvhHbA98y7Al921QNjMpia9l7Yrao4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GUiCwiYtsVIrHutK82cof3rgsaD+cy2hSKcMIuKtMqGh+UnzNOXpJybEsNBsubVJM/ 5Tvk2VdbOtZaJhEyiFzO0Vrc7xSTe7WtjfCucJJ5qLa5whD1Rpdyp6RJh2fb5XDsFeII 0tK6gBVi4qNVBZTr+qazjOolBuauwPzMCpds8= MIME-Version: 1.0 Received: by 10.142.209.4 with SMTP id h4mr6695872wfg.245.1276721405820; Wed, 16 Jun 2010 13:50:05 -0700 (PDT) Received: by 10.142.98.10 with HTTP; Wed, 16 Jun 2010 13:50:05 -0700 (PDT) In-Reply-To: <624D7D11-76F9-4317-9470-47C4CCBD065C@sackheads.org> References: <624D7D11-76F9-4317-9470-47C4CCBD065C@sackheads.org> Date: Wed, 16 Jun 2010 13:50:05 -0700 Message-ID: Subject: Re: The third poison (was Re: [dnsext] Re: draft-vandergaast-edns-client-ip-01) From: Ted Hardie To: John Payne Cc: Nicholas Weaver , Jim Reid , IETF DNSEXT WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Wed, Jun 16, 2010 at 1:17 PM, John Payne wrote: > > On Jun 2, 2010, at 1:51 PM, Ted Hardie wrote: > >> Just to clarify, there is another poison.... >> As a third option, you can make these DNS tricks opt-in from the node >> originating >> the query, rather than deciding for it what the right query should be. > > It is opt-in.... I don't get why you don't think it is. > Stub resolvers can add the option. > Stub resolvers that don't add the option can opt-in to a third-party reso= lver that does. > Uh, I think we disagree about who should be doing the opt-in. The proposed mechanism at the time I made that comment had no way for the end system to tell if the stub resolver was using the option or not. So they are forced to opt-out if they don't want it, rather than opt-in if they do. I hope that's clear, regards, Ted > >> >> Paul's point is that this is basically an addition to the q-tuple; this = option >> adds network topology to the q-tuple and asks the authoritative to >> consider that in constructing the answer. =A0If we are to do that, I thi= nk >> the right place to do it is at the node emitting the query. =A0First and= foremost >> because it is the only node that knows whether or not the node cares >> about topology being used to construct the answer. =A0There are many >> applications for which this data is not useful or important, and turning >> it on only when needed is more efficient; if the originating node cares >> about that efficiency it can use it only when the application requires i= t. >> >> Second, the originating node may have data on what the appropriate >> piece of topology to use to augment the q-tuple might be. =A0Given the >> extent of tunneling used in the Internet today, this is not trivial. =A0= To take >> one example discussed before, a host with a mobile IP tunnel back to >> a home network may consistently use the home network's DNS servers >> but =A0use the outbound interface on the visited network to actually sou= rce >> application traffic (to avoid triangle routing for jitter-sensitve traff= ic >> like =A0VoIP traffic, for example). =A0If it can pass the home network >> the visited network subnet it wishes to use, the home network's >> DNS servers can use that to construct this augmented query. >> Note that this particular use case applies even if the node originating >> the query asks the authoritative server itself, using the tunnel interfa= ce >> to source the DNS query. >> >> Third, the node originating the query is the only node which can >> reasonably determine whether providing topology is a privacy issue. >> That issue has been discussed at length, but the opt-out nature >> of the current solution remains deficient--there is no way for the >> originating node to know whether the upstream is using this >> option in the current case, so it must deal with adding this option. >> That shifts a burden on to it for every query, to support the CDN's >> value proposition--which is present at only some queries. >> >> I understand that Nick and others believe that requiring opt-in >> will mean this never deploys. =A0If the end-users or OS producers >> actually see the value being asserted here, I think that deployment >> could occur. =A0It also seems to me by far the better long term solution= if >> we do want topology (or anything else) include in the q-tuple. =A0The >> node originating the q-tuple should originate any additional >> constraints on the results it desires. =A0That just makes sense. >> >> regards, >> >> Ted Hardie >> > > From owner-namedroppers@ops.ietf.org Wed Jun 16 14:42:59 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1AEF3A6934; Wed, 16 Jun 2010 14:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.232 X-Spam-Level: X-Spam-Status: No, score=-0.232 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_50=0.001, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfT-qJi6oD6u; Wed, 16 Jun 2010 14:42:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 88F723A6936; Wed, 16 Jun 2010 14:42:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OP0Iy-0003sv-B4 for namedroppers-data0@psg.com; Wed, 16 Jun 2010 21:37:52 +0000 Received: from [2001:4f8:0:2::2b] (helo=mx.pao1.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OP0It-0003sI-FY for namedroppers@ops.ietf.org; Wed, 16 Jun 2010 21:37:47 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id BC0BCC9420; Wed, 16 Jun 2010 21:37:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id EAC27EFA1D; Wed, 16 Jun 2010 21:37:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o5GLbSjM042451; Thu, 17 Jun 2010 07:37:29 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201006162137.o5GLbSjM042451@drugs.dv.isc.org> To: "George Barwood" Cc: "Jiankang YAO" , namedroppers@ops.ietf.org From: Mark Andrews References: <476592152.09177@cnnic.cn> <833E80C68446499A9F68638299F2F349@local> <476687310.07502@cnnic.cn> <9497997BEBD1436AA9B3BB63A1DBB7D7@local> Subject: Re: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-02.txt In-reply-to: Your message of "Wed, 16 Jun 2010 15:54:31 +0100." <9497997BEBD1436AA9B3BB63A1DBB7D7@local> Date: Thu, 17 Jun 2010 07:37:28 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <9497997BEBD1436AA9B3BB63A1DBB7D7@local>, "George Barwood" writes: > > ----- Original Message ----- > > From: "George Barwood" > > To: "Jiankang YAO" ; > > Sent: Tuesday, June 15, 2010 5:42 PM > > Subject: Re: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-02.txt > > > >> As far as I can see, DNAME is capable of preventing an exponential increase > >> in records, and the necessity of mirroring any data records in the zone apex > >> that are not redirected by DNAME is a relatively minor administrative inconvenience, > >> that can probably be mitigated by judicious use of the $INCLUDE directive. > >> > > > > there is a dname discussion related to the draft http://tools.ietf.org/id/draft-yao-dnsop-idntld-implementation-01.txt > > in dnsop list. you may see it in dnsop list > > > >> The draft does not seem to mention the incompatibility of BNAME with existing validating > >> resolvers. I think some discussion of how a transition might be managed ( new algorithms?), > > > > do you want to make the existing validating resolvers to recognize the bname? > > if yes, you need to update the validating resolvers to support bname. > > if not, the existing validating resolvers will do it as if there were not bname. > > so the draft said " In order to make BNAME valid in DNSSEC > > verification, the DNSSEC enabled resolvers and servers MUST support > > BNAME. " Correct which is why we need to signal BNAME support with a algorithm number change the same way as we did for NSEC3. > This is an obstacle for the introduction of BNAME. If existing algorithms are used, then > resolvers that have not been updated would get validation errors ( Bogus => SERVERFAIL ), > since the CNAME records cannot be validated. This is almost certainly unacceptable. > > If new algorithms are used, resolvers that have not been updated will get Insecure, which is probably > more acceptable, but still a major disadvantage. Which is what I've been recommending all along. > Either way, a long time would have to elapse before (for example) the root zone could use BNAME, > to allow people time to update their resolver software. No. Lots of validators out there don't support RSASHA256 but the root is using that. BNAME doesn't require resolvers to be upgraded for it to be used. > > your possible suggestion ( new algorithms?) also need update the resolvers or servers. > > > > if you doesn't update anything but make the existing validating resolvers to recognize the bname, it seems to be impossible to do so. > > > > do u have good idea about it? > > I think relaxing the restriction on CNAME+DNAME, as per > > http://tools.ietf.org/id/draft-sury-dnsext-cname-dname-00.txt > > may be a more practical way forward, since apparently it is not necessary in practice for resolvers to be updated. > This assertion needs to be checked carefully - I have personally checked BIND and Unbound (via the public resolvers at https://www.dns-oarc.net/oarc/services/odvr ) and my own implementation, and they all appear to work fine. Only the authoritative server software need be updated, which is under the control of anyone who wishes to publish CNAME+DNAME. CNAME+DNAME also has DNSSEC validation issues. CNAME is used instead of a NSEC to prove non-existance of the type. Change the rules requires old servers to send NSEC's as well as the CNAME records to answer DNAME queries. > Regards, > George Barwood -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Wed Jun 16 17:02:27 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE5D28C1B5; Wed, 16 Jun 2010 17:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_20=-0.74, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxJrmF2GtZYt; Wed, 16 Jun 2010 17:02:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1AF8928C1B2; Wed, 16 Jun 2010 17:02:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OP29z-000I23-Ku for namedroppers-data0@psg.com; Wed, 16 Jun 2010 23:36:43 +0000 Received: from [2001:4f8:0:2::2b] (helo=mx.pao1.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OP29u-000I1c-7t for namedroppers@ops.ietf.org; Wed, 16 Jun 2010 23:36:38 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id B33B6C9420; Wed, 16 Jun 2010 23:36:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D64E8EFA49; Wed, 16 Jun 2010 23:36:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o5GNaM9p083818; Thu, 17 Jun 2010 09:36:22 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201006162336.o5GNaM9p083818@drugs.dv.isc.org> To: "George Barwood" Cc: "Jiankang YAO" , namedroppers@ops.ietf.org From: Mark Andrews References: <476592152.09177@cnnic.cn> <833E80C68446499A9F68638299F2F349@local> <476687310.07502@cnnic.cn> <9497997BEBD1436AA9B3BB63A1DBB7D7@local> <201006162137.o5GLbSjM042451@drugs.dv.isc.org> Subject: Re: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-02.txt In-reply-to: Your message of "Thu, 17 Jun 2010 00:04:14 +0100." Date: Thu, 17 Jun 2010 09:36:22 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , "George Barwood" writes: > ----- Original Message ----- > From: "Mark Andrews" > To: "George Barwood" > Cc: "Jiankang YAO" ; > Sent: Wednesday, June 16, 2010 10:37 PM > Subject: Re: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-02.txt > > > In message <9497997BEBD1436AA9B3BB63A1DBB7D7@local>, "George Barwood" writes: > >> > ----- Original Message ----- > >> > From: "George Barwood" > >> > To: "Jiankang YAO" ; > >> > Sent: Tuesday, June 15, 2010 5:42 PM > >> > Subject: Re: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-02.txt > >> > > >> I think relaxing the restriction on CNAME+DNAME, as per > >> > >> http://tools.ietf.org/id/draft-sury-dnsext-cname-dname-00.txt > >> > >> may be a more practical way forward, since apparently it is not necessary in practice for resolvers to be updated. > >> This assertion needs to be checked carefully - I have personally checked BIND and Unbound (via the public resolvers at https://www.dns-oarc.net/oarc/services/odvr ) and my own implementation, and they all appear to work fine. Only the authoritative server software need be updated, which is under the control of anyone who wishes to publish CNAME+DNAME. > > > > CNAME+DNAME also has DNSSEC validation issues. CNAME is used instead of a > > NSEC to prove non-existance of the type. Change the rules requires old > > servers to send NSEC's as well as the CNAME records to answer DNAME queries. > > I think the issue you are referring to is that if a cache has the CNAME cached, it will restart the query at > the target and not return the DNAME that may be present (but not cached). That means that to reliably query for > [foo DNAME], you actually need to send a query [xx.foo A], and see if the DNAME is present in the response. > It's a bit odd, but I think there are similar issues with NSEC/NSEC3. I don't see any big problem, > since explicit DNAME queries are not needed in "normal" operation. Just because they are not normally needed doesn't mean we should not be able to cryptographicaly prove that the answer is correct when they are made. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dnsext-archive@ietf.org Wed Jun 16 20:17:25 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8633A67E6 for ; Wed, 16 Jun 2010 20:17:25 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: dnsext-archive VIAGRA \256 Official Site -15%\n X-Spam-Flag: NO X-Spam-Score: -24.796 X-Spam-Level: X-Spam-Status: No, score=-24.796 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O36AcxpDGX30 for ; Wed, 16 Jun 2010 20:17:24 -0700 (PDT) Received: from pc-46-240-104-200.cm.vtr.net (pc-46-240-104-200.cm.vtr.net [200.104.240.46]) by core3.amsl.com (Postfix) with SMTP id 2C7423A6783 for ; Wed, 16 Jun 2010 20:17:23 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive VIAGRA ® Official Site -15% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100617031724.2C7423A6783@core3.amsl.com> Date: Wed, 16 Jun 2010 20:17:23 -0700 (PDT)
Click here.

Dear dnsext-archive@ietf.org
From dnsext-archive@ietf.org Wed Jun 16 23:56:32 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179253A6973 for ; Wed, 16 Jun 2010 23:56:32 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: dnsext-archive VIAGRA \256 Official Site -87%\n X-Spam-Flag: NO X-Spam-Score: -5.878 X-Spam-Level: X-Spam-Status: No, score=-5.878 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttAhXgkrifgi for ; Wed, 16 Jun 2010 23:56:31 -0700 (PDT) Received: from 123-174-133-95.pool.ukrtel.net (123-174-133-95.pool.ukrtel.net [95.133.174.123]) by core3.amsl.com (Postfix) with SMTP id 697203A6967 for ; Wed, 16 Jun 2010 23:56:30 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive VIAGRA ® Official Site -87% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100617065630.697203A6967@core3.amsl.com> Date: Wed, 16 Jun 2010 23:56:30 -0700 (PDT)
Click here.

Dear dnsext-archive@ietf.org
From dnsext-archive@ietf.org Thu Jun 17 04:14:55 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8EF93A67E3 for ; Thu, 17 Jun 2010 04:14:54 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: dnsext-archive VIAGRA \256 Official Site -89%\n X-Spam-Flag: NO X-Spam-Score: -23.069 X-Spam-Level: X-Spam-Status: No, score=-23.069 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgW+gpl0P0UF for ; Thu, 17 Jun 2010 04:14:48 -0700 (PDT) Received: from cm-85-152-239-110.telecable.es (cm-85-152-239-110.telecable.es [85.152.239.110]) by core3.amsl.com (Postfix) with SMTP id C32EA3A6A2A for ; Thu, 17 Jun 2010 04:14:36 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive VIAGRA ® Official Site -89% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100617111436.C32EA3A6A2A@core3.amsl.com> Date: Thu, 17 Jun 2010 04:14:36 -0700 (PDT)
Click here.

Dear dnsext-archive@ietf.org
From owner-namedroppers@ops.ietf.org Thu Jun 17 07:38:20 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F643A67D6; Thu, 17 Jun 2010 07:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS25AICdWodX; Thu, 17 Jun 2010 07:38:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D2FA3A687F; Thu, 17 Jun 2010 07:38:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPG6u-0004Sz-6R for namedroppers-data0@psg.com; Thu, 17 Jun 2010 14:30:28 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPG6o-0004Pd-26 for namedroppers@ops.ietf.org; Thu, 17 Jun 2010 14:30:22 +0000 Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o5HEU4bI001791 for ; Thu, 17 Jun 2010 10:30:04 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 17 Jun 2010 10:30:04 -0400 From: "Rose, Scott W." To: IETF DNSEXT WG Date: Thu, 17 Jun 2010 10:30:03 -0400 Subject: [dnsext] Proposed fixes for draft-registry-fixes Thread-Topic: Proposed fixes for draft-registry-fixes Thread-Index: AcsOKYRpeQNOova3RRaIv3DXTIRQwA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Based on the comments on the mailing list regarding draft-registry-fixes regarding terminology, and Section 2.2, the following changes are proposed. Right now, this is what will appear in -05 version of the draft (not posted yet): 1. The draft now updates [RFC2536], [RFC2539], [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and draft-dnssec-gost (RFC TBD). The IANA considerations section is also updated accordingly. 2. Terminology section (terms in -04 used to indicate status): MANDATORY: Implementations MUST support this algorithm to be considered currently inter-operable. DISCRETIONARY: Implementation MAY support this algorithm. The presence or lack thereof this algorithm MUST NOT be used to judge standards compliance. ENCOURAGED: Implementations SHOULD support this algorithm, but like DISCRETIONARY, lack of support MUST NOT be used to judge standards compliance. This term is also used to hint of a possible status change in the future to MANDATORY. OBSOLETE: New implementations SHOULD NOT support this algorithm. Comment: "DISCRETIONARY" or "OPTIONAL"? I have no strong feelings. OPTIONAL is already used in the documents so I would like the change. 3. New section 2.3: 2.3. Specifying New Algorithms and Updating Status of Existing Entries The requirement status for all new algorithms specified using the process in [I-D.ietf-dnsext-dnssec-alg-allocation] MUST be DISCRETIONARY by default. Only a Standards Track document may change the status of any new or existing registry entry. Such a document would necessarily update this document. Comment: Ok, I'm not too thrilled with having the MUST there, suggestions? Scott =================================== Scott Rose NIST scottr@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== From owner-namedroppers@ops.ietf.org Thu Jun 17 08:48:31 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5873A6916; Thu, 17 Jun 2010 08:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHNuCsbhNq2o; Thu, 17 Jun 2010 08:48:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 003EE3A6AA9; Thu, 17 Jun 2010 08:48:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPHFj-000GkV-CB for namedroppers-data0@psg.com; Thu, 17 Jun 2010 15:43:39 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPHFg-000Gk2-51 for namedroppers@ops.ietf.org; Thu, 17 Jun 2010 15:43:36 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5HFhJft015610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jun 2010 08:43:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 17 Jun 2010 08:43:17 -0700 To: "Rose, Scott W." , IETF DNSEXT WG From: Paul Hoffman Subject: Re: [dnsext] Proposed fixes for draft-registry-fixes Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 10:30 AM -0400 6/17/10, Rose, Scott W. wrote: >Based on the comments on the mailing list regarding draft-registry-fixes regarding terminology, and Section 2.2, the following changes are proposed. Right now, this is what will appear in -05 version of the draft (not posted yet): Did you update the pre-draft to say what "implementations" means? That is, one of the important changes that we discussed is that you need to be clear that "implementations" means "implementations of this document", not "implementations in general". This is also extremely important for the IANA Considerations section. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Thu Jun 17 09:10:37 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02543A695E; Thu, 17 Jun 2010 09:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.138 X-Spam-Level: * X-Spam-Status: No, score=1.138 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUVRzimYoX2i; Thu, 17 Jun 2010 09:10:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 48D4D3A6863; Thu, 17 Jun 2010 09:10:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPHcf-000Kk4-ID for namedroppers-data0@psg.com; Thu, 17 Jun 2010 16:07:21 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPHcd-000Kjh-8Y for namedroppers@ops.ietf.org; Thu, 17 Jun 2010 16:07:19 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E9E111ECB41F for ; Thu, 17 Jun 2010 16:07:17 +0000 (UTC) Date: Thu, 17 Jun 2010 12:07:16 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Proposed fixes for draft-registry-fixes Message-ID: <20100617160716.GE82966@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Jun 17, 2010 at 10:30:03AM -0400, Rose, Scott W. wrote: > 1. The draft now updates [RFC2536], > [RFC2539], [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and > draft-dnssec-gost (RFC TBD). The IANA considerations section is also updated accordingly. Good. > 2. Terminology section (terms in -04 used to indicate status): > > MANDATORY: Implementations MUST support this algorithm to be > considered currently inter-operable. See Paul's comment on this. I'm not exactly sure how to make the text clearer that it's "implementations conforming to this document", since the document can hardly specify conformance to some other document. > DISCRETIONARY: Implementation MAY support this algorithm. The > presence or lack thereof this algorithm MUST NOT be used to judge > standards compliance. The "judge standards compliance" here and in the next one probably ought to say instead "to determine conformance with this document" (or "compliance" if you like). > Comment: "DISCRETIONARY" or "OPTIONAL"? I have no strong feelings. > OPTIONAL is already used in the documents so I would like the > change. I have no objection to OPTIONAL. I presume there's no definition of DISCOURAGED because we don't have any right now? > > 3. New section 2.3: > 2.3. Specifying New Algorithms and Updating Status of Existing Entries > > The requirement status for all new algorithms specified using the > process in [I-D.ietf-dnsext-dnssec-alg-allocation] MUST be > DISCRETIONARY by default. Only a Standards Track document may change > the status of any new or existing registry entry. Such a document > would necessarily update this document. > > > Comment: Ok, I'm not too thrilled with having the MUST there, suggestions? It needs to be MUST (or I guess I should say it MUST be MUST). Also drop the "by default". There is no way for any algorithm to get specified under [I-D.ietf-dnsext-dnssec-alg-allocation] and be anything other than optional because to make it REQUIRED would entail updating one of the documents that the present draft is updating. I find your text a little awkward, however. How's this: [I-D.ietf-dnsext-dnssec-alg-allocation] provides a procedure for obtaining an algorithm number for new algorithms. Algorithms entered into the registry using that procedure are always OPTIONAL. Adding an algorithm to the registry with any status other than OPTIONAL SHALL entail an update of this document, in order to specify new contents for the registry. Altering the status of any algorithm in the registry SHALL entail an update of this document, in order to specify new contents of the registry. ? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Jun 17 10:20:34 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7FD3A69B2; Thu, 17 Jun 2010 10:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.003 X-Spam-Level: X-Spam-Status: No, score=-3.003 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxp6HXxRsLkk; Thu, 17 Jun 2010 10:20:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B80333A68F6; Thu, 17 Jun 2010 10:20:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPIfG-000548-CF for namedroppers-data0@psg.com; Thu, 17 Jun 2010 17:14:06 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPIfD-00053p-Gm for namedroppers@ops.ietf.org; Thu, 17 Jun 2010 17:14:03 +0000 Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o5HHDsiV021948 for ; Thu, 17 Jun 2010 13:13:54 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 17 Jun 2010 13:13:29 -0400 From: "Rose, Scott W." To: IETF DNSEXT WG Date: Thu, 17 Jun 2010 13:13:53 -0400 Subject: Re: [dnsext] Proposed fixes for draft-registry-fixes Thread-Topic: [dnsext] Proposed fixes for draft-registry-fixes Thread-Index: AcsOQGeyJPnkAejTQ2CqyXPHeBR+8w== Message-ID: References: <20100617160716.GE82966@shinkuro.com> In-Reply-To: <20100617160716.GE82966@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 17, 2010, at 12:07 PM, Andrew Sullivan wrote: > On Thu, Jun 17, 2010 at 10:30:03AM -0400, Rose, Scott W. wrote: > >> 2. Terminology section (terms in -04 used to indicate status): >> >> MANDATORY: Implementations MUST support this algorithm to be >> considered currently inter-operable. > > See Paul's comment on this. I'm not exactly sure how to make the text > clearer that it's "implementations conforming to this document", since > the document can hardly specify conformance to some other document. > Forgot that - It will go before the other terminology: "In the definitions below, 'implementation' refers to components (e.g. validators, signers, etc.) seeking to conform to this document." >> DISCRETIONARY: Implementation MAY support this algorithm. The >> presence or lack thereof this algorithm MUST NOT be used to judge >> standards compliance. > > The "judge standards compliance" here and in the next one probably > ought to say instead "to determine conformance with this document" (or > "compliance" if you like). > Will fix. >> Comment: "DISCRETIONARY" or "OPTIONAL"? I have no strong feelings. >> OPTIONAL is already used in the documents so I would like the >> change. > > I have no objection to OPTIONAL. > > I presume there's no definition of DISCOURAGED because we don't have > any right now? > Basically - yes. Plus I don't know if DISCOURAGED will be used that much. If it requires one standards track doc to move an entry to DISCOURAGED, then another to move it again to OBSOLETE, it seems to be a lot of churn. >> >> 3. New section 2.3: >> 2.3. Specifying New Algorithms and Updating Status of Existing Entries >> >> The requirement status for all new algorithms specified using the >> process in [I-D.ietf-dnsext-dnssec-alg-allocation] MUST be >> DISCRETIONARY by default. Only a Standards Track document may change >> the status of any new or existing registry entry. Such a document >> would necessarily update this document. >> >> >> Comment: Ok, I'm not too thrilled with having the MUST there, suggestions? > > It needs to be MUST (or I guess I should say it MUST be MUST). Also > drop the "by default". There is no way for any algorithm to get > specified under [I-D.ietf-dnsext-dnssec-alg-allocation] and be > anything other than optional because to make it REQUIRED would entail > updating one of the documents that the present draft is updating. I > find your text a little awkward, however. How's this: > > [I-D.ietf-dnsext-dnssec-alg-allocation] provides a procedure for > obtaining an algorithm number for new algorithms. Algorithms > entered into the registry using that procedure are always > OPTIONAL. > > Adding an algorithm to the registry with any status other than > OPTIONAL SHALL entail an update of this document, in order to > specify new contents for the registry. > > Altering the status of any algorithm in the registry SHALL entail > an update of this document, in order to specify new contents of > the registry. > > ? > Better, but for the last paragraph: Altering the status of any algorithm in the registry SHALL entail an update of this document in order to change the contents of the registry. (minor wording, but it isn't adding new content, but changing existing stuff). Scott > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > =================================== Scott Rose NIST scottr@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== From owner-namedroppers@ops.ietf.org Thu Jun 17 13:48:18 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75DBE3A6B15; Thu, 17 Jun 2010 13:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.229 X-Spam-Level: *** X-Spam-Status: No, score=3.229 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZccG-a7ordt; Thu, 17 Jun 2010 13:48:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6EC563A6B08; Thu, 17 Jun 2010 13:48:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPLvF-00084D-5O for namedroppers-data0@psg.com; Thu, 17 Jun 2010 20:42:49 +0000 Message-Id: Received: from [76.96.62.48] (helo=qmta05.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPLvC-00083v-SD for namedroppers@ops.ietf.org; Thu, 17 Jun 2010 20:42:47 +0000 Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta05.westchester.pa.mail.comcast.net with comcast id X6Xz1e0050cZkys558imwu; Thu, 17 Jun 2010 20:42:46 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta10.westchester.pa.mail.comcast.net with comcast id X8il1e00A1EtFYL3W8ilQ5; Thu, 17 Jun 2010 20:42:46 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 17 Jun 2010 16:42:44 -0400 To: Andrew Sullivan ,namedroppers@ops.ietf.org From: Michael StJohns Subject: Re: [dnsext] Setting CD=1 on upstream queries In-Reply-To: <20100614183925.GG1471@shinkuro.com> References: <4C15D9EF.9050907@nlnetlabs.nl> <20100614183925.GG1471@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 02:39 PM 6/14/2010, Andrew Sullivan wrote: >Do I take the end of the paragraph above to suggest that you no longer >want to work on text for the draft, and that your previous objections >to the draft going ahead without the change you were proposing are >lifted? The definition of insanity is doing the same thing over and over again and expecting a different result... I doubt that my further objections will result in any different result in the end. So do what you need to do, as will I. From owner-namedroppers@ops.ietf.org Thu Jun 17 15:19:56 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24C2C3A69F6; Thu, 17 Jun 2010 15:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.041 X-Spam-Level: ** X-Spam-Status: No, score=2.041 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+w32fnJKxH9; Thu, 17 Jun 2010 15:19:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 933263A69C2; Thu, 17 Jun 2010 15:19:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPNMv-000J5v-3n for namedroppers-data0@psg.com; Thu, 17 Jun 2010 22:15:29 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPNMt-000J5e-1l for namedroppers@ops.ietf.org; Thu, 17 Jun 2010 22:15:27 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 29CDC1ECB41F for ; Thu, 17 Jun 2010 22:15:24 +0000 (UTC) Date: Thu, 17 Jun 2010 18:15:22 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Setting CD=1 on upstream queries Message-ID: <20100617221522.GS82966@shinkuro.com> References: <4C15D9EF.9050907@nlnetlabs.nl> <20100614183925.GG1471@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Michael, On Thu, Jun 17, 2010 at 04:42:44PM -0400, Michael StJohns wrote: > > The definition of insanity is doing the same thing over and over again and expecting a different result... I doubt that my further objections will result in any different result in the end. > > So do what you need to do, as will I. Since we're trying to work through the objection by doing similar things over and over, I understand your frustration but have little sympathy with your unwillingness to be clear. It seems to me that we have an item here that probably needs detailed discussion at the Maastricht meeting, but I only want to turn the time over to it if you haven't already withdrawn your objection. Cryptic answers of this sort don't actually help with making that kind of determination. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Fri Jun 18 11:38:41 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A8B3A68E9; Fri, 18 Jun 2010 11:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUjadPsNwEHQ; Fri, 18 Jun 2010 11:38:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BDEB33A68BF; Fri, 18 Jun 2010 11:38:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPgKT-000PXK-K2 for namedroppers-data0@psg.com; Fri, 18 Jun 2010 18:30:13 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPgKQ-000PWV-FC for namedroppers@ops.ietf.org; Fri, 18 Jun 2010 18:30:10 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 2687E3A67EC; Fri, 18 Jun 2010 11:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnssec-registry-fixes-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100618183003.2687E3A67EC@core3.amsl.com> Date: Fri, 18 Jun 2010 11:30:02 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security (DNSSEC) DNSKEY IANA Registry Algorithm Status Addition Author(s) : S. Rose Filename : draft-ietf-dnsext-dnssec-registry-fixes-05.txt Pages : 9 Date : 2010-06-18 The DNS Security Extensions (DNSSEC) has an IANA registry to allocate cryptographic algorithm suites for use in generating digital signatures over DNS data. Newly introduced cryptographic algorithms to DNSSEC mean implementors need to know which algorithms need to be implemented, which are optional, and which are obsolete. This document adds a column to the IANA registry table for Domain Name System Security (DNSSEC) Algorithm Numbers which lists their current status for use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-fixes-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-registry-fixes-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-18112606.I-D@ietf.org> --NextPart-- From owner-namedroppers@ops.ietf.org Fri Jun 18 11:38:43 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE49F3A68BF; Fri, 18 Jun 2010 11:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.081 X-Spam-Level: X-Spam-Status: No, score=-4.081 tagged_above=-999 required=5 tests=[AWL=0.967, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0635nZpod2Gp; Fri, 18 Jun 2010 11:38:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC94A3A68BA; Fri, 18 Jun 2010 11:38:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPgN2-0000EA-UI for namedroppers-data0@psg.com; Fri, 18 Jun 2010 18:32:52 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPgMx-0000CI-LG for namedroppers@ops.ietf.org; Fri, 18 Jun 2010 18:32:47 +0000 Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o5IIWbbp019133 for ; Fri, 18 Jun 2010 14:32:38 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 18 Jun 2010 14:32:37 -0400 From: "Rose, Scott W." To: IETF DNSEXT WG Date: Fri, 18 Jun 2010 14:32:36 -0400 Subject: [dnsext] draft-registry-fixes-05 posted Thread-Topic: draft-registry-fixes-05 posted Thread-Index: AcsPFJDIboGFDzmZRj22u3NoR9sb0g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Just posted. Simply to have something for people to beat against instead of trying to follow a bunch of deltas in an email thread. Changes from -04: 1. added terminology section 2. added section 2.3 on status updating process 3. Lists all the RFC's that this document will update 4. cleaned up the IANA considerations section a bit Scott =================================== Scott Rose NIST scottr@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== From owner-namedroppers@ops.ietf.org Fri Jun 18 15:22:18 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A163A694E; Fri, 18 Jun 2010 15:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.413 X-Spam-Level: * X-Spam-Status: No, score=1.413 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOrUIAyjR8xh; Fri, 18 Jun 2010 15:22:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 022433A67EA; Fri, 18 Jun 2010 15:22:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OPjrc-00064L-Vh for namedroppers-data0@psg.com; Fri, 18 Jun 2010 22:16:40 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPjra-00063j-J2 for namedroppers@ops.ietf.org; Fri, 18 Jun 2010 22:16:38 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5IMGXtk025127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jun 2010 15:16:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 18 Jun 2010 15:16:31 -0700 To: "Rose, Scott W." , IETF DNSEXT WG From: Paul Hoffman Subject: Re: [dnsext] draft-registry-fixes-05 posted Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 2:32 PM -0400 6/18/10, Rose, Scott W. wrote: >Just posted. Simply to have something for people to beat against instead of trying to follow a bunch of deltas in an email thread. > >Changes from -04: >1. added terminology section >2. added section 2.3 on status updating process >3. Lists all the RFC's that this document will update >4. cleaned up the IANA considerations section a bit Thanks for the update, but it still mostly fails to deal with the core issue of what the column in the table refers to. The abstract says: The DNS Security Extensions (DNSSEC) has an IANA registry to allocate cryptographic algorithm suites for use in generating digital signatures over DNS data. Newly introduced cryptographic algorithms to DNSSEC mean implementors need to know which algorithms need to be implemented, which are optional, and which are obsolete. This document adds a column to the IANA registry table for Domain Name System Security (DNSSEC) Algorithm Numbers which lists their current status for use. What does "need to be implemented" mean? As was discussed earlier, one only needs to implement an algorithm if they want to conform to a particular RFC, but that is not mentioned here. The same problem appears for "their current status for use". Anyone can implement "for use" to conform to the RFC in which the algorithm was defined, so this sentence is meaningless. There is nothing in section 1 that clears this up. For example, 1.1 says: MANDATORY: Implementations MUST support this algorithm to be considered currently inter-operable. Interoperable with what? The text is still broadly hinting at "interoperable with other DNSSEC implementations", which is just plain wrong. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Sat Jun 19 11:39:11 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1140D3A684E; Sat, 19 Jun 2010 11:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.877 X-Spam-Level: X-Spam-Status: No, score=0.877 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoSRUPtmrQqX; Sat, 19 Jun 2010 11:39:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B30BE3A6907; Sat, 19 Jun 2010 11:39:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OQ2oz-000GKf-6J for namedroppers-data0@psg.com; Sat, 19 Jun 2010 18:31:13 +0000 Received: from [74.125.82.52] (helo=mail-ww0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OQ2ow-000GK6-FA for namedroppers@ops.ietf.org; Sat, 19 Jun 2010 18:31:10 +0000 Received: by wwb28 with SMTP id 28so2216866wwb.11 for ; Sat, 19 Jun 2010 11:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=gaf7cLsuVgJt3YeRp8hFkCsGJeIaeualT4ws8mhcm/0=; b=Bvn5im7gQ3ISnKZVc8qljcCG0gvWjbmRV3UT3qXwg6xa9d3n+SdXFkxSda56lcDbXg WfCv4Q3fKINxUBXXyhTb+zd9Wjmtvs+n4zjzPySOdpe2RUn+vOau+4krY5N77MFlgnP0 4aFsJ4FhflEPNR+DucKKZw39M+rLspgm9+p6k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=haSrImtXwpZqFzS3FVcg85XK6T0RNw7qU5LTaRqW8AbCaFvmyycvcbZ8R0ICZ0sxLw vZKGeB5brUgS7pAvFFnUrh2P/iqI7hFQNozxOUC+ygMasLEBq6LCy3oZf24O5ORehOW8 NlA2hVqzAm32sdWCop2CEsXG8VFPTORbID0rE= MIME-Version: 1.0 Received: by 10.216.163.204 with SMTP id a54mr1996324wel.2.1276972268940; Sat, 19 Jun 2010 11:31:08 -0700 (PDT) Received: by 10.216.229.210 with HTTP; Sat, 19 Jun 2010 11:31:08 -0700 (PDT) In-Reply-To: <20100608171340.GE62459@shinkuro.com> References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> <20100608171340.GE62459@shinkuro.com> Date: Sat, 19 Jun 2010 14:31:08 -0400 Message-ID: Subject: Re: [dnsext] CNAME and NXDOMAIN From: Donald Eastlake To: namedroppers@ops.ietf.org Content-Type: multipart/alternative; boundary=0016367f9f6e7a74760489664689 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016367f9f6e7a74760489664689 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Tue, Jun 8, 2010 at 1:13 PM, Andrew Sullivan wrote: > On Tue, Jun 08, 2010 at 03:47:38PM +0000, Paul Vixie wrote: > > perhaps others should chime in, since our disagreement is pretty clear > here. > > I'd like to suggest that people go and read and comment on > http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02. That > draft (wich Donald volunteered to write the last time this flared up) > is an attempt to lay things out systematically. Is it right? I believe Andrew's question above is whether that draft correctly describes the two alternative view so that, for example, it could be used as the basis for a consensus call. I don't think anyone has responded to this question... I think it does describe them clearly. > Thanks, > > A > Thanks, Donald > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > --0016367f9f6e7a74760489664689 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On Tue, Jun 8, 2010 at 1:13 PM, Andr= ew Sullivan <ajs@s= hinkuro.com> wrote:
On Tue, Jun 08, 2010 at 03:47:38PM +0000, Paul Vixie wrot= e:
> perhaps others should chime in, since our disagreement is pretty clear= here.

I'd like to suggest that people go and read and comment on
http://tools.ietf.org/html/draft-eastlake-dnsext-xnamerco= de-02. =A0That
draft (wich Donald volunteered to write the last time this flared up)
is an attempt to lay things out systematically. =A0Is it right?

I believe Andrew's question above is whether that = draft correctly describes the two alternative view so that, for example, it= could be used as the basis for a consensus call. I don't think anyone = has responded to this question... I think it does describe them clearly.
=A0
Thanks,

A

Thanks,
Donald<= /div>
=A0
--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
--0016367f9f6e7a74760489664689-- From owner-namedroppers@ops.ietf.org Sat Jun 19 12:51:19 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262C83A68B0; Sat, 19 Jun 2010 12:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.399 X-Spam-Level: ** X-Spam-Status: No, score=2.399 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3BYCeo2ipOR; Sat, 19 Jun 2010 12:51:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0E6C63A67A5; Sat, 19 Jun 2010 12:51:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OQ3z4-000P7Y-PI for namedroppers-data0@psg.com; Sat, 19 Jun 2010 19:45:42 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OQ3z2-000P7J-Gm for namedroppers@ops.ietf.org; Sat, 19 Jun 2010 19:45:40 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3FA301ECB408 for ; Sat, 19 Jun 2010 19:45:39 +0000 (UTC) Date: Sat, 19 Jun 2010 15:45:37 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] CNAME and NXDOMAIN Message-ID: <20100619194537.GC91748@shinkuro.com> References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> <20100608171340.GE62459@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Sat, Jun 19, 2010 at 02:31:08PM -0400, Donald Eastlake wrote: > I believe Andrew's question above is whether that draft correctly describes > the two alternative view so that, for example, it could be used as the basis > for a consensus call. Yes, this was exactly my question. Thanks for clarifying. And yes, responses are needed, please. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Sun Jun 20 08:36:28 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D863A69DE; Sun, 20 Jun 2010 08:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.82 X-Spam-Level: X-Spam-Status: No, score=0.82 tagged_above=-999 required=5 tests=[AWL=-1.285, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3NYkCLChing; Sun, 20 Jun 2010 08:36:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0197F3A69E7; Sun, 20 Jun 2010 08:36:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OQMSy-000ONM-Gk for namedroppers-data0@psg.com; Sun, 20 Jun 2010 15:29:48 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OQMSu-000OMR-Kp for namedroppers@ops.ietf.org; Sun, 20 Jun 2010 15:29:45 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5KFTfuc003577 for ; Sun, 20 Jun 2010 11:29:42 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4C1E33E5.9010603@ogud.com> Date: Sun, 20 Jun 2010 11:29:41 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: [dnsext] Setting CD=1 on upstream queries References: <4C15D9EF.9050907@nlnetlabs.nl> <20100614183925.GG1471@shinkuro.com> <20100617221522.GS82966@shinkuro.com> In-Reply-To: <20100617221522.GS82966@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: We have organized a face to face meeting of the chairs, Michael StJohns, and David Blacka (one of the editors of the document). The meeting will take place on July 6'th, in Maryland, at 16:00 local time. Any member of the working group that wants to be there let us know, or if you want to call in we can try to arrange for a conference bridge to be set up. This meeting is a "design team" meeting and the results of the meeting will be posted to namedroppers afterwards. If you have opinion/view on this topic please post that to namedroppers before July 2'nd. Olafur On 17/06/2010 6:15 PM, Andrew Sullivan wrote: > Michael, > > On Thu, Jun 17, 2010 at 04:42:44PM -0400, Michael StJohns wrote: >> >> The definition of insanity is doing the same thing over and over again and expecting a different result... I doubt that my further objections will result in any different result in the end. >> >> So do what you need to do, as will I. > > Since we're trying to work through the objection by doing similar > things over and over, I understand your frustration but have little > sympathy with your unwillingness to be clear. It seems to me that we > have an item here that probably needs detailed discussion at the > Maastricht meeting, but I only want to turn the time over to it if you > haven't already withdrawn your objection. Cryptic answers of this > sort don't actually help with making that kind of determination. > > A > From owner-namedroppers@ops.ietf.org Mon Jun 21 01:00:22 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE9F43A6A2F; Mon, 21 Jun 2010 01:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.462 X-Spam-Level: *** X-Spam-Status: No, score=3.462 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igwIcMlAEM5n; Mon, 21 Jun 2010 01:00:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C9BCB3A6A35; Mon, 21 Jun 2010 01:00:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OQbpb-000Miu-Fy for namedroppers-data0@psg.com; Mon, 21 Jun 2010 07:54:11 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OQbpU-000Mhz-5W for namedroppers@ops.ietf.org; Mon, 21 Jun 2010 07:54:05 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5L7rxLQ008786 for ; Mon, 21 Jun 2010 03:53:59 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o5L7rx7F008785 for namedroppers@ops.ietf.org; Mon, 21 Jun 2010 03:53:59 -0400 (EDT) (envelope-from namedroppers) Message-Id: <201006210753.o5L7rx7F008785@stora.ogud.com> Received: from [76.96.62.40] (helo=qmta04.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OPS9f-000MAf-Vs for namedroppers@ops.ietf.org; Fri, 18 Jun 2010 03:22:08 +0000 Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta04.westchester.pa.mail.comcast.net with comcast id XEms1e0031HzFnQ54FN7Fk; Fri, 18 Jun 2010 03:22:07 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta14.westchester.pa.mail.comcast.net with comcast id XFN61e0081EtFYL3aFN6Yz; Fri, 18 Jun 2010 03:22:07 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 17 Jun 2010 23:22:05 -0400 To: Andrew Sullivan , namedroppers@ops.ietf.org From: Michael StJohns Subject: Re: [dnsext] Setting CD=1 on upstream queries In-Reply-To: <20100617221522.GS82966@shinkuro.com> References: <4C15D9EF.9050907@nlnetlabs.nl> <20100614183925.GG1471@shinkuro.com> <20100617221522.GS82966@shinkuro.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_254489672==.ALT" X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --=====================_254489672==.ALT Content-Type: text/plain; charset="us-ascii" Hi Andrew - I have a bit different view of the process. 18 months or so ago I raised the objection to the text, worked with the document editor to get it at least somewhat correct and was assured that we were good to go. Since my day job no longer involves DNS, I wandered off to do things I get paid for. I was quite surprised with the text in the current document that as near as I can tell was crafted by one of the document editors, wasn't discussed (could have been, I might have missed it) and still didn't fix the problem. After discovering this at the last IETF F2F meeting, I objected, and for my part to support the objection crafted a diagram that showed what I believed the appropriate DNSSEC processing of CD bit related data was at an intermediate resolver. The diagram drew total silence and as near as I can tell. I noted to the document editor a lack of comments and was told it would be gotten to. Skip to the current cycle. I restated the diagram as an if/then/else structure for discussion purposes, suggest that there is a SHOULD/MUST issues, and we immediately get tied up on my assertion that a SHOULD really should be a MUST, but there's no discussion or analysis of the generic processing model. After a number of go arounds - mostly with George, but also with you I try and write text (5/17) that reflects the processing model. After a number of discussion with you on list about what I did or didn't say (mostly what I did or didn't say about George's comments) which seemed to be of no real point, I re-submit the 5/17 text with some small changes on 5/19 to cover the issues with caching CD=1 data. Still no evidence that you've read or considered it. No response from you. Finally, on 5/23 Sam drops a note about George's note of the 5/15 which starts a long and involved back and forth with George and me that goes on for a few days and also draws a side note from Don E. Two weeks later - 6/7 - you start munging my 5/19 text, pointing at the arguments from George as "ample" "counter-arguments" A few more emails later - I ask for what I thought was a simple thing - predictable name resolution behavior and point out where the text doesn't really provide any directive text - at this point I don't really care about what the default is, so much as having one. Your response seems to be that you've decided that you will be "ruling on rough consensus" and that rough consensus seems to be to leave the broken text. I try and repair what - in my opinion - were the greatest issues of your text. Your response is not encouraging. Next is splitting the CD=X cache vs the CD=1 upstream queries setting into two threads. Etc etc etc.. At some point you comment about splitting the consideration into CD=0 and CD=1 - I resubmit the if/then/else text simply to show I've actually got a model that represents this. You complain privately to me that I'm not cooperating by not providing text. I respond privately, that perhaps we should get a common view of the processing model first and then graft on text. And the wheels go around. I've provided a) a diagram that describes what I think the processing model should be, b) an if/then/else text representation of the diagram, c) prose text that as near as I can tell maps to a and b. In the discussions on-line I've seen no one propose an alternate processing model, nor try to describe what processing model they think is represented by 4035. I've asked you for this a number of times, especially since you've claimed my text is inconsistent with 4035. I don't really have much more to say on the matter - the diagram and text represents my best understanding of appropriate processing at the Intermediate resolver for CD=X cached data and for upstream queries covered by a local resolver TA. Unless and until someone wants to have that discussion, all I would really be doing is beating my head against the wall. But I am happy to have that discussion. For those who care, following Andrew's note is my analysis of 4035 - everywhere the CD bit is mentioned - and what I feel the flaws are. This was part of the in-person discussion some 18-24 months ago, but probably was never captured in text. My comments are in brackets. Mike At 06:15 PM 6/17/2010, Andrew Sullivan wrote: >Michael, > >On Thu, Jun 17, 2010 at 04:42:44PM -0400, Michael StJohns wrote: >> >> The definition of insanity is doing the same thing over and over again and expecting a different result... I doubt that my further objections will result in any different result in the end. >> >> So do what you need to do, as will I. > >Since we're trying to work through the objection by doing similar >things over and over, I understand your frustration but have little >sympathy with your unwillingness to be clear. It seems to me that we >have an item here that probably needs detailed discussion at the >Maastricht meeting, but I only want to turn the time over to it if you >haven't already withdrawn your objection. Cryptic answers of this >sort don't actually help with making that kind of determination. > >A > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. [As far as I can tell, this is every scrap of text in 4035 that talks about the CD bit.] DNSSEC allocates two new bits in the DNS message header: the CD (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit is controlled by resolvers; a security-aware name server MUST copy the CD bit from a query into the corresponding response. [No Issue] A security-aware name server does not perform signature validation for authoritative data during query processing, even when the CD bit is clear. A security-aware name server SHOULD clear the CD bit when composing an authoritative response. [No issue, but note this text as it describe mandatory behavior without actually using MUST/SHOULD/MAY. An appropriate modification is "A security-aware names server MUST NOT perform signature validation for authoritative data during query processing... ". I cite this because of similar omissions and mistakes later on.] A security-aware name server that supports recursion MUST follow the rules for the CD and AD bits given in Section 3.2 when generating a response that involves data obtained via recursion. [No issue here, but the rules in 3.2.2 aren't complete.] 3.2.2. The CD Bit The CD bit exists in order to allow a security-aware resolver to disable signature validation in a security-aware name server's processing of a particular query. The name server side MUST copy the setting of the CD bit from a query to the corresponding response. [No issues for either of these, but interestingly enough, the setting of the CD bit is supposed to be ignored by the query receiver as noted in later 4035 text] The name server side of a security-aware recursive name server MUST pass the state of the CD bit to the resolver side along with the rest of an initiating query, so that the resolver side will know whether it is required to verify the response data it returns to the name server side. [There is no text anywhere else in the document that indicates what the setting of the CD bit in an upstream query should be - "pass the state of the CD bit" does not say to set the upstream bit. If there is a validating resolver upstream of this intermediate resolver, then not setting CD=1 may result in a RCODE=2 error even if the local resolver could have verified the data. So this section should actually require CD=1 in the upstream if the CD bit is set in the query.] If the CD bit is set, it indicates that the originating resolver is willing to perform whatever authentication its local policy requires. Thus, the resolver side of the recursive name server need not perform authentication on the RRsets in the response. When the CD bit is set, the recursive name server SHOULD, if possible, return the requested data to the originating resolver, even if the recursive name server's local authentication policy would reject the records in question. [The "SHOULD" and "if possible" are not useful without explanatory text. RFC 2119 says "Document authors should take the time to elaborate the security implications of not following recommendations" which suggests that this section is incomplete. E.g. text should be included here that describes when its OK not to "return the requested data" and actually, probably should define the error code. In any event, given other text here, its clear that the resolver should get out of the way and return the raw data - its stated two or three times] **That is, by setting the CD bit, the originating resolver has indicated that it takes responsibility for performing its own authentication, and the recursive name server should not interfere. [The "should not interfere" buttresses my argument that the CD bit means "get the hell out of my way and give me the data straight from the source"] If the resolver side implements a BAD cache (see Section 4.7) and the name server side receives a query that matches an entry in the resolver side's BAD cache, the name server side's response depends on the state of the CD bit in the original query. [The section describes what can happens to a CD=0 upstream query that is locally unvalidatable. What about data retrieved by a CD=1 upstream query that is cached, but not covered by a local trust anchor? Normal DNSSEC practices suggest that later CD=0 queries can't use the CD=1 cached data (because the data might have missed an upstream validation), but I find nothing covering this case.] If the CD bit is set, the name server side SHOULD return the data from the BAD cache; if the CD bit is not set, the name server side MUST return RCODE 2 (server failure). [What should the resolver do instead if it doesn't return the data from the BAD cache? Send an error code, or requery upstream or something else?] ***The intent of the above rule is to provide the raw data to clients that are capable of performing their own signature verification checks while protecting clients that depend on the resolver side of a security-aware recursive name server to perform such checks. Several of the possible reasons why signature validation might fail involve conditions that may not apply equally to the recursive name server and the client that invoked it. For example, the recursive name server's clock may be set incorrectly, or the client may have knowledge of a relevant island of security that the recursive name server does not share. In such cases, "protecting" a client that is capable of performing its own signature validation from ever seeing the "bad" data does not help the client. [We've gotten to the end of the major section describing CD handling without ever any requirement to set the CD bit in the upstream query. Obviously, for recursive upstream queries that are the result of CD=0 queries, it makes no sense to set CD=1 unless this resolver has a TA covering the query. Given that text at ** and *** this suggests that if you have a TA covering the query you should, absent of local security policy, set CD=1 in the upstream query.] 4.2. Signature Verification Support A security-aware resolver MUST support the signature verification mechanisms described in Section 5 and SHOULD apply them to every received response, except when: o the security-aware resolver is part of a security-aware recursive name server, and the response is the result of recursion on behalf of a query received with the CD bit set; [I *think* this is OK and basically in agreement with my suggestion that CD=1 data covered by a TA can be cached without immediate validation] 4.6. Handling of the CD and AD Bits A security-aware resolver MAY set a query's CD bit in order to indicate that the resolver takes responsibility for performing whatever authentication its local policy requires on the RRsets in the response. [This is a gratuitous MAY. The sentence can be re-written without loss of meaning to "The setting of a query's CD bit by a security aware resolver indicates the resolver takes responsibility...". This restatement is in line with previous statements in 4035 about the purpose of setting the CD bit.] See Section 3.2 for the effect this bit has on the behavior of security-aware recursive name servers. ... A resolver MUST disregard the meaning of the CD and AD bits in a response unless the response was obtained by using a secure channel or the resolver was specifically configured to regard the message header bits without using a secure channel. [As I noted above in the comments to setting the bits in the response. Much of the text in 4035 is written as if the only possible querier for a recursive validating resolver is a stub resolver - where it might be possible to have such a secure connection. The reality is that with various configuration directives and IP redirection, there can be a chain of intermediate resolvers between a stub and the authoritative server.] 4.7. Caching BAD Data ... This document refers to a cache of data with invalid signatures as a "BAD cache". [CD=1 data not locally validatable probably needs to be put in an UNKNOWN cache or thrown away?] 4.9.2. Handling of the CD Bit A non-validating security-aware stub resolver SHOULD NOT set the CD bit when sending queries unless it is requested by the application layer, as by definition, a non-validating stub resolver depends on the security-aware recursive name server to perform validation on its behalf. A validating security-aware stub resolver SHOULD set the CD bit, because otherwise the security-aware recursive name server will answer the query using the name server's local policy, which may prevent the stub resolver from receiving data that would be acceptable to the stub resolver's local policy. [This section has an unspoken assumption - that it has a single root trust anchor. I infer this from the text that sets the CD bit without consdering you might not be able to do the validation. The default policy (absent an indication from an application) should be to set CD=1 if the stub resolver has a covering TA and clear it if it doesn't. It may have a local policy that varies from this. The SHOULD's here may also require 2119 elaboration.] 5.5. Resolver Behavior When Signatures Do Not Validate If for whatever reason none of the RRSIGs can be validated, the response SHOULD be considered BAD. ****If the validation was being done to service a recursive query, the name server MUST return RCODE 2 to the originating client. However, it MUST return the full response if and only if the original query had the CD bit set. Also see Section 4.7 on caching responses that do not validate. [****This seems to conflict with section 3.2.2 which says "the resolver side of the recursive name server need not perform authentication" if the CD bit is set. You can't return an RCODE 2 if you don't attempt validation.] 7. Security Considerations .... An active attacker who can set the CD bit in a DNS query message or the AD bit in a DNS response message can use these bits to defeat the protection that DNSSEC attempts to provide to security-oblivious recursive-mode resolvers. For this reason, use of these control bits by a security-aware recursive-mode resolver requires a secure channel. See Sections 3.2.2 and 4.9 for further discussion. [For the CD bit, this is might be correct for an oblivious stub to a validating resolver, but not correct between two security aware resolvers.] --=====================_254489672==.ALT Content-Type: text/html; charset="us-ascii"


Hi Andrew -

I have a bit different view of the process.

18 months or so ago I raised the objection to the text, worked with the document editor to get it at least somewhat correct and was assured that we were good to go.  Since my day job no longer involves DNS, I wandered off to do things I get paid for.  I was quite surprised with the text in the current document that as near as I can tell was crafted by one of the document editors, wasn't discussed (could have been, I might have missed it) and still didn't fix the problem.

After discovering this at the last IETF F2F meeting, I objected, and for my part to support the objection crafted a diagram that showed what I believed the appropriate DNSSEC processing of CD bit related data was at an intermediate resolver.  The diagram drew total silence and as near as I can tell.  I noted to the document editor a lack of comments and was told it would be gotten to.

Skip to the current cycle.

I restated the diagram as an if/then/else structure for discussion purposes, suggest that there is a SHOULD/MUST issues, and we immediately get tied up on my assertion that a SHOULD really should be a MUST, but there's no discussion or analysis of the generic processing model.  After a number of go arounds - mostly with George, but also with you I try and write text (5/17) that reflects the processing model.  

After a number of discussion with you on list about what I did or didn't say (mostly what I did or didn't say about George's comments)  which seemed to be of no real point, I re-submit the 5/17 text with some small changes on 5/19 to cover the issues with caching CD=1 data.  Still no evidence that you've read or considered it.

No response from you.  Finally, on 5/23 Sam drops a note about  George's note of the 5/15 which starts a long and involved back and forth with George and me that goes on for a few days and also draws a side note from Don E. 

Two weeks later - 6/7 - you start munging my 5/19 text, pointing at the arguments from George as "ample" "counter-arguments"

A few more emails later - I ask for what I thought was a simple thing - predictable name resolution behavior and point out where the text doesn't really provide any directive text - at this point I don't really care about what the default is, so much as having one.   Your response seems to be that you've decided that you will be "ruling on rough consensus" and that rough consensus seems to be to leave the broken text.

I try and repair what - in my opinion - were  the greatest issues of your text.  Your response is not encouraging.
 
Next is splitting the CD=X cache vs the CD=1 upstream queries setting into two threads.

Etc etc etc..

At some point you comment about splitting the consideration into CD=0 and CD=1 - I resubmit the if/then/else text simply to show I've actually got a model that represents this.   You complain privately to me that I'm not cooperating by not providing text.  I respond privately, that perhaps we should get a common view of the processing model first and then graft on text. 

And the wheels go around.    I've provided a) a diagram that describes what I think the processing model should be, b) an if/then/else text representation of the diagram, c) prose text that as near as I can tell maps to a and b.

In the discussions on-line I've seen no one propose an alternate processing model, nor try to describe what processing model they think is represented by 4035.  I've asked you for this a number of times, especially since you've claimed my text is inconsistent with 4035. 

I don't really have much more to say on the matter - the diagram and text represents my best understanding of appropriate processing at the Intermediate resolver for CD=X cached data and for upstream queries covered by a local resolver TA.  Unless and until someone wants to have that discussion, all I would really be doing is beating my head against the wall.  But I am happy to have that discussion.

For those who care, following Andrew's note is my analysis of 4035 - everywhere the CD bit is mentioned - and what I feel the flaws are.  This was part of the in-person discussion some 18-24 months ago, but probably was never captured in text.  My comments are in brackets.

Mike





At 06:15 PM 6/17/2010, Andrew Sullivan wrote:
Michael,

On Thu, Jun 17, 2010 at 04:42:44PM -0400, Michael StJohns wrote:
>
> The definition of insanity is doing the same thing over and over again and expecting a different result... I doubt that my further objections will result in any different result in the end.
>
>  So do what you need to do, as will I.

Since we're trying to work through the objection by doing similar
things over and over, I understand your frustration but have little
sympathy with your unwillingness to be clear.  It seems to me that we
have an item here that probably needs detailed discussion at the
Maastricht meeting, but I only want to turn the time over to it if you
haven't already withdrawn your objection.  Cryptic answers of this
sort don't actually help with making that kind of determination.

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

[As far as I can tell, this is every scrap of text in 4035 that talks about the CD bit.]


   DNSSEC allocates two new bits in the DNS message
header: the CD
   (Checking Disabled) bit and the AD (Authentic Data)
bit.  The CD bit
   is controlled by resolvers; a security-aware name server
MUST copy
   the CD bit from a query into the corresponding response.
[No Issue]

   A security-aware name server does not perform signature
validation
   for authoritative data during query processing, even when
the CD bit
   is clear.  A security-aware name server SHOULD clear
the CD bit when
   composing an authoritative response.
[No issue, but note this text as it describe mandatory behavior without actually using MUST/SHOULD/MAY.  An appropriate modification is "A security-aware names server MUST NOT perform signature validation for authoritative data during query processing... ".  I cite this because of similar omissions and mistakes later on.]

   A security-aware name server that supports recursion
MUST follow the
   rules for the CD and AD bits given in Section 3.2 when
generating a
   response that involves data obtained via recursion.
[No issue here, but the rules in 3.2.2 aren't complete.]

3.2.2.  The CD Bit

   The CD bit exists in order to allow a security-aware
resolver to
   disable signature validation in a security-aware name
server's
   processing of a particular query.

   The name server side MUST copy the setting of the CD bit
from a query
   to the corresponding response.

[No issues for either of these, but interestingly enough, the setting of
the CD bit is supposed to be ignored by the query receiver as noted in
later 4035 text]

   The name server side of a security-aware recursive name
server MUST
   pass the state of the CD bit to the resolver side along with
the rest
   of an initiating query, so that the resolver side will know
whether
   it is required to verify the response data it returns to the
name
   server side. 

[There is no text anywhere else in the document that indicates what the
setting of the CD bit in an upstream query should be - "pass the
state of the CD bit" does not say to set the upstream bit.  If
there is a validating resolver upstream of this intermediate resolver,
then not setting CD=1 may result in a RCODE=2 error even if the local
resolver could have verified the data.  So this section should
actually require CD=1 in the upstream if the CD bit is set in the
query.]

   If the CD bit is set, it indicates that the originating
   resolver is willing to perform whatever authentication its
local
   policy requires.  Thus, the resolver side of the
recursive name
   server need not perform authentication on the RRsets in the
response.
   When the CD bit is set, the recursive name server SHOULD,
if
   possible, return the requested data to the originating
resolver, even
   if the recursive name server's local authentication policy
would
   reject the records in question. 

[The "SHOULD" and "if possible" are not useful
without explanatory text.  RFC 2119 says "Document authors
should take the time  to elaborate the security implications of not
following recommendations" which suggests that this section is
incomplete.  E.g. text should be included here that describes when
its OK not to "return the requested data" and actually,
probably should define the error code.  In any event, given other
text here, its clear that the resolver should get out of the way and
return the raw data - its stated two or three times]


   **That is, by setting the CD bit, the
   originating resolver has indicated that it takes
responsibility for
   performing its own authentication, and the recursive name
server
   should not interfere.

[The "should not interfere" buttresses my argument that the CD
bit means "get the hell out of my way and give me the data straight
from the source"]

   If the resolver side implements a BAD cache (see Section
4.7) and the
   name server side receives a query that matches an entry in
the
   resolver side's BAD cache, the name server side's response
depends on
   the state of the CD bit in the original query.  

[The section describes what can happens to a CD=0 upstream query that is
locally unvalidatable.  What about data retrieved by a CD=1 upstream
query that is cached, but not covered by a local trust anchor? 
Normal DNSSEC practices suggest that later CD=0 queries can't use the
CD=1 cached data (because the data might have missed an upstream
validation), but I find nothing covering this case.]

   If the CD bit is set,
   the name server side SHOULD return the data from the BAD
cache; if
   the CD bit is not set, the name server side MUST return
RCODE 2
   (server failure).

[What should the resolver do instead if it doesn't return the data from
the BAD cache?  Send an error code, or requery upstream or something
else?]

   ***The intent of the above rule is to provide the raw data
to clients
   that are capable of performing their own signature
verification
   checks while protecting clients that depend on the resolver
side of a
   security-aware recursive name server to perform such
checks.  Several
   of the possible reasons why signature validation might fail
involve
   conditions that may not apply equally to the recursive name
server
   and the client that invoked it.  For example, the
recursive name
   server's clock may be set incorrectly, or the client may
have
   knowledge of a relevant island of security that the
recursive name
   server does not share.  In such cases,
"protecting" a client that is
   capable of performing its own signature validation from ever
seeing
   the "bad" data does not help the client.
[We've gotten to the end of the major section describing CD handling without ever any requirement to set the CD bit in the upstream query.  Obviously, for recursive upstream queries that are the result of CD=0 queries, it makes no sense to set CD=1 unless this resolver has a TA covering the query.  Given that text at ** and *** this suggests that if you have a TA covering the query you should, absent of local security policy, set CD=1 in the upstream query.]


4.2.  Signature Verification Support

   A security-aware resolver MUST support the signature
verification
   mechanisms described in Section 5 and SHOULD apply them to
every
   received response, except when:

   o  the security-aware resolver is part of a
security-aware recursive
      name server, and the response is the
result of recursion on behalf
      of a query received with the CD bit set;

[I *think* this is OK and basically in agreement with my suggestion that
CD=1 data covered by a TA can be cached without immediate validation]



4.6.  Handling of the CD and AD Bits

   A security-aware resolver MAY set a query's CD bit in order
to
   indicate that the resolver takes responsibility for
performing
   whatever authentication its local policy requires on the
RRsets in
   the response.

[This is a gratuitous MAY.  The sentence can be re-written without
loss of meaning to "The setting of a query's CD bit by a security
aware resolver indicates the resolver takes responsibility...". This
restatement is in line with previous statements in 4035 about the purpose
of setting the CD bit.]

   See Section 3.2 for the effect this bit has on the
   behavior of security-aware recursive name servers.

   ...

   A resolver MUST disregard the meaning of the CD and AD bits
in a
   response unless the response was obtained by using a secure
channel
   or the resolver was specifically configured to regard the
message
   header bits without using a secure channel.

[As I noted above in the comments to setting the bits in the
response.  

Much of the text in 4035 is written as if the only possible querier for a
recursive validating resolver is a stub resolver - where it might be
possible to have such a secure connection.  The reality is that with
various configuration directives and IP redirection, there can be a chain
of intermediate resolvers between a stub and the authoritative server.]



4.7.  Caching BAD Data

   ... This document refers to a cache of data with
   invalid signatures as a "BAD cache".

[CD=1 data not locally validatable probably needs to be put in an UNKNOWN
cache or thrown away?]


4.9.2.  Handling of the CD Bit

   A non-validating security-aware stub resolver SHOULD NOT set
the CD
   bit when sending queries unless it is requested by the
application
   layer, as by definition, a non-validating stub resolver
depends on
   the security-aware recursive name server to perform
validation on its
   behalf.

   A validating security-aware stub resolver SHOULD set the CD
bit,
   because otherwise the security-aware recursive name server
will
   answer the query using the name server's local policy, which
may
   prevent the stub resolver from receiving data that would be
   acceptable to the stub resolver's local policy.

[This section has an unspoken assumption - that it has a single root
trust anchor.  I infer this from the text that sets the CD bit
without consdering you might not be able to do the validation.  The
default policy (absent an indication from an application) should be to
set CD=1 if the stub resolver has a covering TA and clear it if it
doesn't.  It may have a local policy that varies from this. 
The SHOULD's here may also require 2119 elaboration.]



5.5.  Resolver Behavior When Signatures Do Not Validate

   If for whatever reason none of the RRSIGs can be validated,
the
   response SHOULD be considered BAD.  ****If the
validation was being done
   to service a recursive query, the name server MUST return
RCODE 2 to
   the originating client.  However, it MUST return the
full response if
   and only if the original query had the CD bit set. 
Also see Section
   4.7 on caching responses that do not validate.

[****This seems to conflict with section 3.2.2 which says "the
resolver side of the recursive name server need not perform
authentication" if the CD bit is set.  You can't return an
RCODE 2 if you don't attempt validation.]


7.  Security Considerations

   ....

   An active attacker who can set the CD bit in a DNS query
message or
   the AD bit in a DNS response message can use these bits to
defeat the
   protection that DNSSEC attempts to provide to
security-oblivious
   recursive-mode resolvers.  For this reason, use of
these control bits
   by a security-aware recursive-mode resolver requires a
secure
   channel.  See Sections 3.2.2 and 4.9 for further
discussion.
[For the CD bit, this is might be correct for an oblivious stub to a validating resolver, but not correct between two security aware resolvers.]
--=====================_254489672==.ALT-- From owner-namedroppers@ops.ietf.org Mon Jun 21 01:00:39 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D148B3A6A35; Mon, 21 Jun 2010 01:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[AWL=-1.552, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZNFs+QEttyy; Mon, 21 Jun 2010 01:00:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4FB753A6A2F; Mon, 21 Jun 2010 01:00:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OQbnq-000MND-Kh for namedroppers-data0@psg.com; Mon, 21 Jun 2010 07:52:22 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OQbnm-000MLS-Ue for namedroppers@ops.ietf.org; Mon, 21 Jun 2010 07:52:20 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5L7qF0G008719 for ; Mon, 21 Jun 2010 03:52:15 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o5L7qF9p008718 for namedroppers@ops.ietf.org; Mon, 21 Jun 2010 03:52:15 -0400 (EDT) (envelope-from namedroppers) Received: from [147.11.1.11] (helo=mail.windriver.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OPpMg-000Hfx-Tm for namedroppers@ops.ietf.org; Sat, 19 Jun 2010 04:09:07 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id o5J48xOn013800; Fri, 18 Jun 2010 21:08:59 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jun 2010 21:08:59 -0700 Received: from [172.25.44.2] ([172.25.44.2]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jun 2010 21:08:59 -0700 Subject: [dnsext] tsv-dir review of draft-ietf-dnsext-dns-tcp-requirements (DNS Transport over TCP - Implementation Requirements) to Proposed Standard Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <3F1B41B0-8A45-4F97-BF86-2540752D2D16@nokia.com> Date: Fri, 18 Jun 2010 23:08:57 -0500 Cc: TSV Dir , namedroppers@ops.ietf.org, ray.bellis@nominet.org.uk Content-Transfer-Encoding: 7bit Message-Id: <140C5410-0A59-42C3-8589-13B0B7617E5B@windriver.com> References: <20100528142345.311183A6A3E@core3.amsl.com> <57C89477-7BDB-48BF-ACF3-098FEBA22F9A@nokia.com> <9FF2F481-2B3E-40BB-8089-BCC434BF8813@windriver.com> <3F1B41B0-8A45-4F97-BF86-2540752D2D16@nokia.com> To: "iesg@ietf.org IESG" , tsv-ads@tools.ietf.org X-Mailer: Apple Mail (2.1081) X-OriginalArrivalTime: 19 Jun 2010 04:08:59.0174 (UTC) FILETIME=[24AECC60:01CB0F65] X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. Summary ------- The primary purpose of this document is stated in the abstract: This document updates the requirements for the support of TCP as a transport protocol for DNS implementations. As such, it does not introduce any changes to how DNS operates over TCP. Additions since the original DNS specification have extended the amount of information that can be communicated, and if there is too much data sent in a UDP packet it will be truncated at 512 bytes. Using TCP as the transport instead of UDP avoids this truncation. The document also recommends that dormant connections be closed on the order of seconds, rather than minutes, as in the original specification, to avoid tying up resources. This document also clarifies that client resolvers must be able to process responses that arrive in a different order than they were sent, regardless of what transport is used. Comments and recommendations: ----------------------------- I do not see any transport related issues with this document. As the summary states, this document is mostly about maing DNS over TCP a must for implementors, and clarifying some minor items in the original DNS specification. So from that standpoint I have no concerns with the publication of this document. -David Borman, david.borman@windriver.com From dnsext-archive@ietf.org Mon Jun 21 05:25:00 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA9428C0ED for ; Mon, 21 Jun 2010 05:25:00 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: dnsext-archive VIAGRA \256 Official Site -60%\n X-Spam-Flag: NO X-Spam-Score: -18.706 X-Spam-Level: X-Spam-Status: No, score=-18.706 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAnlGH6lmtXn for ; Mon, 21 Jun 2010 05:24:59 -0700 (PDT) Received: from ppp-124-122-234-11.revip2.asianet.co.th (ppp-124-122-234-11.revip2.asianet.co.th [124.122.234.11]) by core3.amsl.com (Postfix) with SMTP id 8690928C0F1 for ; Mon, 21 Jun 2010 05:24:58 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive VIAGRA ® Official Site -60% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100621122458.8690928C0F1@core3.amsl.com> Date: Mon, 21 Jun 2010 05:24:58 -0700 (PDT)
Click here.

Dear dnsext-archive@ietf.org
From owner-namedroppers@ops.ietf.org Tue Jun 22 08:24:31 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 692333A682E; Tue, 22 Jun 2010 08:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_50=0.001, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFYlsosAu9My; Tue, 22 Jun 2010 08:24:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B34B3A67E3; Tue, 22 Jun 2010 08:24:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OR5F9-000Hz0-Oo for namedroppers-data0@psg.com; Tue, 22 Jun 2010 15:18:31 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OR5F5-000Hxa-Sz for namedroppers@ops.ietf.org; Tue, 22 Jun 2010 15:18:28 +0000 Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o5MFI6r2022449; Tue, 22 Jun 2010 11:18:06 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 22 Jun 2010 11:17:51 -0400 From: "Rose, Scott W." To: Paul Hoffman CC: IETF DNSEXT WG Date: Tue, 22 Jun 2010 11:18:05 -0400 Subject: Re: [dnsext] draft-registry-fixes-05 posted Thread-Topic: [dnsext] draft-registry-fixes-05 posted Thread-Index: AcsSHhRXmrOhId5SS++XvfLlRmOAbQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 18, 2010, at 6:16 PM, Paul Hoffman wrote: > At 2:32 PM -0400 6/18/10, Rose, Scott W. wrote: >> Just posted. Simply to have something for people to beat against instead of trying to follow a bunch of deltas in an email thread. >> >> Changes from -04: >> 1. added terminology section >> 2. added section 2.3 on status updating process >> 3. Lists all the RFC's that this document will update >> 4. cleaned up the IANA considerations section a bit > > Thanks for the update, but it still mostly fails to deal with the core issue of what the column in the table refers to. > > The abstract says: > The DNS Security Extensions (DNSSEC) has an IANA registry to allocate > cryptographic algorithm suites for use in generating digital > signatures over DNS data. Newly introduced cryptographic algorithms > to DNSSEC mean implementors need to know which algorithms need to be > implemented, which are optional, and which are obsolete. This > document adds a column to the IANA registry table for Domain Name > System Security (DNSSEC) Algorithm Numbers which lists their current > status for use. > What does "need to be implemented" mean? As was discussed earlier, one only needs to implement an algorithm if they want to conform to a particular RFC, but that is not mentioned here. The same problem appears for "their current status for use". Anyone can implement "for use" to conform to the RFC in which the algorithm was defined, so this sentence is meaningless. > How about: The DNS Security Extensions (DNSSEC) has an IANA registry to allocate cryptographic algorithm suites for use in generating digital signatures over DNS data. Newly introduced cryptographic algorithms to DNSSEC (and algorithm migration) mean implementors need to know the status of algorithms according to the current RFC's. This document adds a column to the IANA registry table for Domain Name System Security (DNSSEC) Algorithm Numbers which lists each algorithm's status based on the current reference. > There is nothing in section 1 that clears this up. For example, 1.1 says: > MANDATORY: Implementations MUST support this algorithm to be > considered currently inter-operable. > Interoperable with what? The text is still broadly hinting at "interoperable with other DNSSEC implementations", which is just plain wrong. > second half of first paragraph, section 1.1: Throughout this text, "implementation" refers to any component (e.g. validator, signer, etc.) that conforms to this document. Some of these terms were used without definition in previous documents and are defined here. MANDATORY: Implementations MUST support this algorithm to be considered conforming to the specification reference and this document. Scott > --Paul Hoffman, Director > --VPN Consortium =================================== Scott Rose NIST scottr@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== From owner-namedroppers@ops.ietf.org Tue Jun 22 09:29:58 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26703A67AB; Tue, 22 Jun 2010 09:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.766 X-Spam-Level: * X-Spam-Status: No, score=1.766 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dz5UkRqCUbea; Tue, 22 Jun 2010 09:29:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C3E0B3A6896; Tue, 22 Jun 2010 09:29:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OR6HY-0004T7-G8 for namedroppers-data0@psg.com; Tue, 22 Jun 2010 16:25:04 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OR6HV-0004SL-SA for namedroppers@ops.ietf.org; Tue, 22 Jun 2010 16:25:02 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5MGOof5020938; Tue, 22 Jun 2010 12:24:52 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Tue, 22 Jun 2010 12:24:59 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 22 Jun 2010 12:24:59 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20100619194537.GC91748@shinkuro.com> References: <55156.1274856474@nsa.vix.com> <64615.1276012058@nsa.vix.com> <20100608171340.GE62459@shinkuro.com> <20100619194537.GC91748@shinkuro.com> Date: Tue, 22 Jun 2010 12:24:48 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: [dnsext] CNAME and NXDOMAIN Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 15:45 -0400 6/19/10, Andrew Sullivan wrote: >On Sat, Jun 19, 2010 at 02:31:08PM -0400, Donald Eastlake wrote: >> I believe Andrew's question above is whether that draft correctly describes >> the two alternative view so that, for example, it could be used as the basis >> for a consensus call. > >Yes, this was exactly my question. Thanks for clarifying. > >And yes, responses are needed, please. I'm responding to thank Donald for taking the initiative to do the right thing - form a draft to capture this. Beyond that I'm not much help. Outside of once believing alternative B was true and then diving into the spec and coming out believing alternative A was true, I can't add much. Through in that I've then seen other parts of the spec that support alternative B again. The difference is very fine, not a common case. The difference is seen only when examining the implementations that have diverged because of the unclear specification. I could really live with either alternative, mostly because it isn't an earth shattering matter. For the sake of closure we should fix this. But when it comes to the practicality of the debate, we'd be more productive ... cleaning up a oil spill somewhere. I do not mean to demean's Donald's document nor am trying to be sarcastic. Just trying to justify why I haven't had anything to add to Donald's document. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 The World Cup would be more fun if they didn't interrupt it with soccer games. From owner-namedroppers@ops.ietf.org Tue Jun 22 09:38:11 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981B43A68A9; Tue, 22 Jun 2010 09:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.44 X-Spam-Level: * X-Spam-Status: No, score=1.44 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pB7s0iKW4trU; Tue, 22 Jun 2010 09:38:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B6C073A687D; Tue, 22 Jun 2010 09:38:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OR6RR-0005pr-5c for namedroppers-data0@psg.com; Tue, 22 Jun 2010 16:35:17 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OR6Qs-0005j3-Qy for namedroppers@ops.ietf.org; Tue, 22 Jun 2010 16:34:43 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5MGYcGe000502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jun 2010 09:34:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 22 Jun 2010 09:34:38 -0700 To: "Rose, Scott W." From: Paul Hoffman Subject: Re: [dnsext] draft-registry-fixes-05 posted Cc: IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 11:18 AM -0400 6/22/10, Rose, Scott W. wrote: >On Jun 18, 2010, at 6:16 PM, Paul Hoffman wrote: > > What does "need to be implemented" mean? As was discussed earlier, one only needs to implement an algorithm if they want to conform to a particular RFC, but that is not mentioned here. The same problem appears for "their current status for use". Anyone can implement "for use" to conform to the RFC in which the algorithm was defined, so this sentence is meaningless. >> >How about: > >The DNS Security Extensions (DNSSEC) has an IANA registry to allocate > cryptographic algorithm suites for use in generating digital > signatures over DNS data. Newly introduced cryptographic algorithms > to DNSSEC (and algorithm migration) mean implementors need to know > the status of algorithms according to the current RFC's. This > document adds a column to the IANA registry table for Domain Name > System Security (DNSSEC) Algorithm Numbers which lists each > algorithm's status based on the current reference. What does "the current reference" mean? > > There is nothing in section 1 that clears this up. For example, 1.1 says: >> MANDATORY: Implementations MUST support this algorithm to be >> considered currently inter-operable. >> Interoperable with what? The text is still broadly hinting at "interoperable with other DNSSEC implementations", which is just plain wrong. >> > >second half of first paragraph, section 1.1: > >Throughout this text, > "implementation" refers to any component (e.g. validator, signer, > etc.) that conforms to this document. Some of these terms were used > without definition in previous documents and are defined here. > > MANDATORY: Implementations MUST support this algorithm to be > considered conforming to the specification reference and this > document. That would help immensely, but it still does not clear up what the IANA registry is supposed to say. --Paul Hoffman, Director --VPN Consortium From dnsext-archive@ietf.org Wed Jun 23 00:18:16 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD5C3A67B4 for ; Wed, 23 Jun 2010 00:18:16 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: dnsext-archive VIAGRA \256 Official Site -24%\n X-Spam-Flag: NO X-Spam-Score: -17.289 X-Spam-Level: X-Spam-Status: No, score=-17.289 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_STATICB=1.372, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RELAY_IS_203=0.994, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-7kGOnisDaX for ; Wed, 23 Jun 2010 00:18:15 -0700 (PDT) Received: from static-mum-203.94.231.114.mtnl.net.in (static-mum-203.94.231.114.mtnl.net.in [203.94.231.114]) by core3.amsl.com (Postfix) with SMTP id EE4FF3A67B2 for ; Wed, 23 Jun 2010 00:18:14 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive VIAGRA ® Official Site -24% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100623071814.EE4FF3A67B2@core3.amsl.com> Date: Wed, 23 Jun 2010 00:18:14 -0700 (PDT)
Click here.

Dear dnsext-archive@ietf.org
From owner-namedroppers@ops.ietf.org Wed Jun 23 17:39:01 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715283A68B5; Wed, 23 Jun 2010 17:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q79RR77VgVo4; Wed, 23 Jun 2010 17:39:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D89F53A68A0; Wed, 23 Jun 2010 17:38:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORaL5-000Duq-IF for namedroppers-data0@psg.com; Thu, 24 Jun 2010 00:30:43 +0000 Received: from [2001:4f8:0:2::2b] (helo=mx.pao1.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORaL1-000Du2-S2 for namedroppers@ops.ietf.org; Thu, 24 Jun 2010 00:30:40 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 03698C9429; Thu, 24 Jun 2010 00:30:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 61EC5E601A; Thu, 24 Jun 2010 00:30:30 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o5O0UNQY071797; Thu, 24 Jun 2010 10:30:25 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201006240030.o5O0UNQY071797@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews References: <201006081432.o58EWSEB034243@drugs.dv.isc.org> <201006082226.o58MQXlh041976@drugs.dv.isc.org> Subject: Re: [dnsext] Section 5.1 of draft-dnssec-bis In-reply-to: Your message of "Wed, 09 Jun 2010 07:37:42 -0400." Date: Thu, 24 Jun 2010 10:30:23 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message , Edward Lewis writes: > At 8:26 +1000 6/9/10, Mark Andrews wrote: > > >Deployed code. RFC 4034 were rollups of lots of other RFC's. We stuffed > >the rollup. > > The reason I'm not letting this go like a sane person would is that > it's not simply that we "stuffed the rollup." And that's why I > supplied text in a previous message. > > In RFC 2065 (the first stab at DNSSEC) is says this towards the end of 4.1: > > The "signer's name" field is the domain name of the signer generating > the SIG RR. This is the owner of the public KEY RR that can be used > to verify the signature. It is frequently the zone which contained > the RR(s) being authenticated. The signer's name may be compressed > with standard DNS name compression when being transmitted over the > network. > > In RFC 2535 carries this forward: > > 4.1.7 Signer's Name Field > > ....................... The signer's name may be compressed with > standard DNS name compression when being transmitted over the > network. > > Because both were specified to be compressible they needed to be down > cased. So to undo this mistaken assumption we should document the > reason for the change explicitly. (The reason I was so convinced we > needed to down case was because when I wrote code on this I had to > down case given the assumptions of the time. No truth to the rumor > that my code is so old it is in Fortran IV.) > > If a signer down cased as part of writing the entire zone, meaning it > also down cases the RDATA, this all worked. When the signer didn't > down case the RDATA this caused problems. I got that from David. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Discussing IPv4 address policy is like deciding what to eat on the Titanic. This comment got me looking in the code and named does downcase the signer's name when generating the rrsig. This was a hold over from how it generates sig records which do need to be downcased (the same code does both sig and rrsig generation). rrsig records don't provided the casing is preserved everywhere. mea culpa as I failed to change that part in doing the type code roll in named. The question is where do we go from here? * We can cause breakage and make everything consistent with RFC 3755 or RFC 4034. Doing either will cause validation failures. * We can document the current code base. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Thu Jun 24 02:12:40 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9402D3A6A1C; Thu, 24 Jun 2010 02:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.35 X-Spam-Level: *** X-Spam-Status: No, score=3.35 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FDPbjz8DyCE; Thu, 24 Jun 2010 02:12:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 15DD83A67B4; Thu, 24 Jun 2010 02:12:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORiOw-000Loo-GE for namedroppers-data0@psg.com; Thu, 24 Jun 2010 09:07:14 +0000 Received: from [193.227.124.2] (helo=mx01.bfk.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORiOt-000Lnn-Tp for namedroppers@ops.ietf.org; Thu, 24 Jun 2010 09:07:12 +0000 Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1ORiOk-00073a-Lh; Thu, 24 Jun 2010 09:07:02 +0000 Received: by bfk.de with local id 1ORiOp-0000HS-30; Thu, 24 Jun 2010 09:07:07 +0000 To: "Rose\, Scott W." Cc: IETF DNSEXT WG Subject: Re: [dnsext] Proposed fixes for draft-registry-fixes References: From: Florian Weimer Date: Thu, 24 Jun 2010 09:07:07 +0000 In-Reply-To: (Scott W. Rose's message of "Thu\, 17 Jun 2010 10\:30\:03 -0400") Message-ID: <821vbwbxz8.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: * Scott W. Rose: > 2. Terminology section (terms in -04 used to indicate status): > > MANDATORY: Implementations MUST support this algorithm to be > considered currently inter-operable. Not "compliant with this specification"? (You can't define interoperability in a standard.) > DISCRETIONARY: Implementation MAY support this algorithm. The > presence or lack thereof this algorithm MUST NOT be used to judge > standards compliance. > > ENCOURAGED: Implementations SHOULD support this algorithm, but > like DISCRETIONARY, lack of support MUST NOT be used to judge > standards compliance. This term is also used to hint of a > possible status change in the future to MANDATORY. > > OBSOLETE: New implementations SHOULD NOT support this algorithm. > > Comment: "DISCRETIONARY" or "OPTIONAL"? I have no strong feelings. > OPTIONAL is already used in the documents so I would like the > change. Isn't the official set of adjectives REQUIRED, OPTIONAL and RECOMMENDED, anyway? > 3. New section 2.3: > 2.3. Specifying New Algorithms and Updating Status of Existing Entries > > The requirement status for all new algorithms specified using the > process in [I-D.ietf-dnsext-dnssec-alg-allocation] MUST be > DISCRETIONARY by default. Only a Standards Track document may change > the status of any new or existing registry entry. Such a document > would necessarily update this document. > > > Comment: Ok, I'm not too thrilled with having the MUST there, suggestion= s?=20=20 I wonder what the reasons are behind putting those attributes in the IANA registry. Implementations cannot claim compliance with the registry in general, only with specific RFCs (or versions of the registry in certain points of time). The requirement not to use MUST in RFCs for new algorithms means that you can be compliant with the RFC without actually implementing the algorithm, which is just bizarre. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From owner-namedroppers@ops.ietf.org Thu Jun 24 02:35:24 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF07D3A6A50; Thu, 24 Jun 2010 02:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNYT7up1aPUY; Thu, 24 Jun 2010 02:35:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 501A03A6A40; Thu, 24 Jun 2010 02:35:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORin9-000PXH-8T for namedroppers-data0@psg.com; Thu, 24 Jun 2010 09:32:15 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORin7-000PWu-7Q for namedroppers@ops.ietf.org; Thu, 24 Jun 2010 09:32:13 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id B69DEA1028 for ; Thu, 24 Jun 2010 09:32:12 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: [dnsext] draft-vixie-dnsext-resimprove-00: Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Date: Thu, 24 Jun 2010 09:32:12 +0000 Message-ID: <34857.1277371932@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --=-=-= after years of rejections, i finally realized that the ietf reject-o-bot could be fooled into accepting my internet drafts if i moved the abstract to the second page, after the boilerplate, and if i stopped tagging the creation date with "Creation Date:" and stopped representing the creation date in the same yyyy-mm-dd format as the expiration date, but rather in "mmmm dd, yyyy" format under the list of author names. what a glorious way to spend my time. anyway we can apparently, finally share this. looks like the URI is: http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 i'll find out what else has been jammed in my queue, that i'd given up ever publishing. abstract on the second page, what a hoot. re: --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=9685 Content-Description: forwarded message Return-Path: X-Original-To: vixie@vix.com Delivered-To: vixie@nsa.vix.com Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx.pao1.isc.org", Issuer "ISC CA" (not verified)) by nsa.vix.com (Postfix) with ESMTPS id 93D0EA101E for ; Wed, 23 Jun 2010 14:24:57 +0000 (UTC) (envelope-from wwwrun@core3.amsl.com) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by mx.pao1.isc.org (Postfix) with ESMTP id 9A29DC9423 for ; Wed, 23 Jun 2010 14:24:55 +0000 (UTC) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id 783C73A69AD; Wed, 23 Jun 2010 07:24:46 -0700 (PDT) From: IETF I-D Submission Tool To: vixie@isc.org Cc: rjoffe@centergate.com,fneves@registro.br Subject: New Version Notification for draft-vixie-dnsext-resimprove-00 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100623142446.783C73A69AD@core3.amsl.com> Date: Wed, 23 Jun 2010 07:24:46 -0700 (PDT) X-Spam-Status: No, score=-101.9 required=5.0 tests=BAYES_00, USER_IN_ALL_SPAM_TO autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.pao1.isc.org A new version of I-D, draft-vixie-dnsext-resimprove-00.txt has been successfully submitted by Paul Vixie and posted to the IETF repository. Filename: draft-vixie-dnsext-resimprove Revision: 00 Title: Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness Creation_date: 2010-06-22 WG ID: Independent Submission Number_of_pages: 6 Abstract: This document describes several mechanisms which can be employed by iterative caching DNS resolvers to improve resiliency, robustness, and responsiveness. These improvements are optional and they require no changes to the protocol, or to authority servers, or to DNS stub resolver clients. The IETF Secretariat. --=-=-=-- From owner-namedroppers@ops.ietf.org Thu Jun 24 05:56:52 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 142DD3A6944; Thu, 24 Jun 2010 05:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.691 X-Spam-Level: * X-Spam-Status: No, score=1.691 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDNcEcTvsdr7; Thu, 24 Jun 2010 05:56:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3AD423A659C; Thu, 24 Jun 2010 05:56:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORlt9-0006pJ-8Z for namedroppers-data0@psg.com; Thu, 24 Jun 2010 12:50:39 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORlt6-0006ok-R9 for namedroppers@ops.ietf.org; Thu, 24 Jun 2010 12:50:37 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5OCoNPv038232; Thu, 24 Jun 2010 08:50:25 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Thu, 24 Jun 2010 08:50:34 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 24 Jun 2010 08:50:34 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201006240030.o5O0UNQY071797@drugs.dv.isc.org> References: <201006081432.o58EWSEB034243@drugs.dv.isc.org> <201006082226.o58MQXlh041976@drugs.dv.isc.org> <201006240030.o5O0UNQY071797@drugs.dv.isc.org> Date: Thu, 24 Jun 2010 08:14:01 -0400 To: From: Edward Lewis Subject: Re: [dnsext] Section 5.1 of draft-dnssec-bis Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 10:30 +1000 6/24/10, Mark Andrews wrote: >The question is where do we go from here? >* We can cause breakage and make everything consistent with RFC 3755 > or RFC 4034. Doing either will cause validation failures. >* We can document the current code base. I prefer the latter - from the age-old IETF mantra, restated for today's generation "code rulz!" Avoiding another requirement to have everyone validating DNSSEC update their code would be good thing too. But we do need clean specs so code bases all are on the same page. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 The World Cup would be more fun if they didn't interrupt it with soccer games. From owner-namedroppers@ops.ietf.org Thu Jun 24 06:57:17 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87B623A6816; Thu, 24 Jun 2010 06:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_50=0.001, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkNomLaUNXJO; Thu, 24 Jun 2010 06:57:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 527E33A67A3; Thu, 24 Jun 2010 06:57:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORmqi-000H6z-Ra for namedroppers-data0@psg.com; Thu, 24 Jun 2010 13:52:12 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORmqg-000H6P-97 for namedroppers@ops.ietf.org; Thu, 24 Jun 2010 13:52:10 +0000 Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o5ODphcX008237; Thu, 24 Jun 2010 09:51:43 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 24 Jun 2010 09:51:43 -0400 From: "Rose, Scott W." To: Florian Weimer CC: IETF DNSEXT WG Date: Thu, 24 Jun 2010 09:51:42 -0400 Subject: Re: [dnsext] Proposed fixes for draft-registry-fixes Thread-Topic: [dnsext] Proposed fixes for draft-registry-fixes Thread-Index: AcsTpFedJ62PsZRlRiWbeJMskWQsaA== Message-ID: <09637CA4-6946-4BD0-A9EA-AAD0EA61CE99@nist.gov> References: <821vbwbxz8.fsf@mid.bfk.de> In-Reply-To: <821vbwbxz8.fsf@mid.bfk.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 24, 2010, at 5:07 AM, Florian Weimer wrote: > * Scott W. Rose: >=20 >> 2. Terminology section (terms in -04 used to indicate status): >>=20 >> MANDATORY: Implementations MUST support this algorithm to be >> considered currently inter-operable. >=20 > Not "compliant with this specification"? (You can't define > interoperability in a standard.) >=20 Noted prior, changing to: MANDATORY: Implementations MUST support this algorithm to be=20 considered conforming to this document. >> DISCRETIONARY: Implementation MAY support this algorithm. The >> presence or lack thereof this algorithm MUST NOT be used to judge >> standards compliance. >>=20 >> ENCOURAGED: Implementations SHOULD support this algorithm, but >> like DISCRETIONARY, lack of support MUST NOT be used to judge >> standards compliance. This term is also used to hint of a >> possible status change in the future to MANDATORY. >>=20 >> OBSOLETE: New implementations SHOULD NOT support this algorithm. >>=20 >> Comment: "DISCRETIONARY" or "OPTIONAL"? I have no strong feelings. >> OPTIONAL is already used in the documents so I would like the >> change. >=20 > Isn't the official set of adjectives REQUIRED, OPTIONAL and > RECOMMENDED, anyway? >=20 Could go with the 2119 defs and use REQUIRED and OPTIONAL, but there isn't = anything that syncs with ENCOURAGED. "RECOMMENDED" comes close, but there'= s a need to give a hint about future path (the RFC 2119 def of RECOMMENDED = doesn't have this, so we can't assume it will be implied). =20 The terms were originally from draft-ogud-iana-protocol-maintenance-words >> 3. New section 2.3: >> 2.3. Specifying New Algorithms and Updating Status of Existing Entries >>=20 >> The requirement status for all new algorithms specified using the >> process in [I-D.ietf-dnsext-dnssec-alg-allocation] MUST be >> DISCRETIONARY by default. Only a Standards Track document may change >> the status of any new or existing registry entry. Such a document >> would necessarily update this document. >>=20 >>=20 >> Comment: Ok, I'm not too thrilled with having the MUST there, suggestio= ns? =20 >=20 > I wonder what the reasons are behind putting those attributes in the > IANA registry. Implementations cannot claim compliance with the > registry in general, only with specific RFCs (or versions of the > registry in certain points of time). The requirement not to use MUST > in RFCs for new algorithms means that you can be compliant with the > RFC without actually implementing the algorithm, which is just > bizarre. >=20 The document does not state that the goal is to make the registry authorita= tive, the document (RFC) would be (and any updating doc). The goal of the = column is to put the status of each algorithm (based on the relevant RFC) s= o implementors don't have to search through RFC's and DNSSEC history (since= some RFC's that specify algorithms do not give their status) to find out w= hat algorithms should be included, what the future direction might be, and = which algorithms are falling out of favor. =20 Scott > --=20 > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra=DFe 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 scottr@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 owner-namedroppers@ops.ietf.org Thu Jun 24 07:28:23 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414793A6802; Thu, 24 Jun 2010 07:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[AWL=1.157, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6t0b9JEb89v; Thu, 24 Jun 2010 07:28:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 452EC3A67C1; Thu, 24 Jun 2010 07:28:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORnMH-000MYT-1a for namedroppers-data0@psg.com; Thu, 24 Jun 2010 14:24:49 +0000 Received: from [74.125.82.52] (helo=mail-ww0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORnME-000MXy-DS for namedroppers@ops.ietf.org; Thu, 24 Jun 2010 14:24:46 +0000 Received: by wwb13 with SMTP id 13so1610730wwb.11 for ; Thu, 24 Jun 2010 07:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mr6a77bxRl36QVUvRo4ReIFykLTu/zTfsLZ8KGByxfg=; b=noKY1yktPefk5ApVVLOSUiYCj3m/mydB8mgo+Fk590jFhHAy2nFmSgDlnAk7aBQ8v9 pDNcy5R+3ib9bMCC6qIAhMit1uAXr+MLDHjW0QrpaMFX9AIk32wAXefcMea5qZTcbis/ Xw+44IVtO6yxZYOzwDymQ1fVZxtisl1aPU1QQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sxpVIyj4wBHKtD/WBiR/z1rWtx/SZ3xRJZIrf93TizBbkFYjpM8nXkkJDPOdqwByri ZIXAxUz7MhlqAiMcLL1Z/ywH7tUqeIQpvt7vS80VBFl+30p2NuPJdoB/bwVNn7Dpl47q K3vlWEQGNHAYMZ102SMO2IFP1J+aAV+5513qg= MIME-Version: 1.0 Received: by 10.216.85.194 with SMTP id u44mr7422926wee.10.1277389482326; Thu, 24 Jun 2010 07:24:42 -0700 (PDT) Received: by 10.216.229.210 with HTTP; Thu, 24 Jun 2010 07:24:42 -0700 (PDT) In-Reply-To: <3D60313831F7497FB1BFE9D732C55089@local> References: <201006081432.o58EWSEB034243@drugs.dv.isc.org> <201006082226.o58MQXlh041976@drugs.dv.isc.org> <201006240030.o5O0UNQY071797@drugs.dv.isc.org> <3D60313831F7497FB1BFE9D732C55089@local> Date: Thu, 24 Jun 2010 10:24:42 -0400 Message-ID: Subject: Re: [dnsext] Section 5.1 of draft-dnssec-bis From: Donald Eastlake To: George Barwood Cc: Edward Lewis , Mark Andrews , namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: See below.. On Thu, Jun 24, 2010 at 2:56 AM, George Barwood wrote: > > ----- Original Message ----- > From: "Mark Andrews" > >> This comment got me looking in the code and named does downcase the >> signer's name when generating the rrsig. =A0This was a hold over from >> how it generates sig records which do need to be downcased (the >> same code does both sig and rrsig generation). =A0rrsig records don't >> provided the casing is preserved everywhere. =A0mea culpa as I failed >> to change that part in doing the type code roll in named. > > http://tools.ietf.org/html/rfc4034#section-3.1.8 > > says > > << > RRSIG_RDATA is the wire format of the RRSIG RDATA fields > with the Signer's Name field in canonical form and the Signature field ex= cluded; >>> > > Unfortunately, AFAICS, no definition is given for the canonical form of a= domain name. See Section 6.2: 6.2. Canonical RR Form For the purposes of DNS security, the canonical form of an RR is the wire format of the RR where: 1. every domain name in the RR is fully expanded (no DNS name compression) and fully qualified; 2. all uppercase US-ASCII letters in the owner name of the RR are replaced by the corresponding lowercase US-ASCII letters; 3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in the DNS names contained within the RDATA are replaced by the corresponding lowercase US-ASCII letters; 4. if the owner name of the RR is a wildcard name, the owner name is in its original unexpanded form, including the "*" label (no wildcard substitution); and 5. the RR's TTL is set to its original value as it appears in the originating authoritative zone or the Original TTL field of the covering RRSIG RR. Thanks, Donald > Regardless, when generating authoritative RRSIG/NSEC records (signing), a= n implementation is free to downcase names without causing validation probl= ems ( a validating resolver cannot go wrong once this is done), and given t= he conflicting RFCs, I think this is highly advisable. > >> The question is where do we go from here? >> * We can cause breakage and make everything consistent with RFC 3755 >> =A0or RFC 4034. =A0Doing either will cause validation failures. >> * We can document the current code base. > > I suggest documenting that signers MUST downcase the NSEC NextName field > and the RRSIG Signer's Name field. > > George > From owner-namedroppers@ops.ietf.org Thu Jun 24 09:01:41 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9953E3A69B3; Thu, 24 Jun 2010 09:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.449 X-Spam-Level: * X-Spam-Status: No, score=1.449 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45ID-Ws474+Q; Thu, 24 Jun 2010 09:01:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4559A3A68A4; Thu, 24 Jun 2010 09:01:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORomF-000BRi-Ld for namedroppers-data0@psg.com; Thu, 24 Jun 2010 15:55:43 +0000 Received: from [207.182.41.81] (helo=hoffman.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORomD-000BRA-5J for namedroppers@ops.ietf.org; Thu, 24 Jun 2010 15:55:41 +0000 Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5OFtPpZ072945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jun 2010 08:55:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <09637CA4-6946-4BD0-A9EA-AAD0EA61CE99@nist.gov> References: <821vbwbxz8.fsf@mid.bfk.de> <09637CA4-6946-4BD0-A9EA-AAD0EA61CE99@nist.gov> Date: Thu, 24 Jun 2010 08:55:24 -0700 To: "Rose, Scott W." , Florian Weimer From: Paul Hoffman Subject: Re: [dnsext] Proposed fixes for draft-registry-fixes Cc: IETF DNSEXT WG Content-Type: text/plain; charset="us-ascii" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 9:51 AM -0400 6/24/10, Rose, Scott W. wrote: > > Isn't the official set of adjectives REQUIRED, OPTIONAL and >> RECOMMENDED, anyway? >> >Could go with the 2119 defs and use REQUIRED and OPTIONAL, but there isn't anything that syncs with ENCOURAGED. "RECOMMENDED" comes close, but there's a need to give a hint about future path (the RFC 2119 def of RECOMMENDED doesn't have this, so we can't assume it will be implied). > >The terms were originally from draft-ogud-iana-protocol-maintenance-words There are at least two ways to go here: - Use the official word "SHOULD" with an in-line augmentation - Define a new word-meaning pair The first way would be a lot clearer to most implementers. For example, the text can say "SHOULD implement because it is expected that this will become a MUST-level requirement in the future". In the Security Area, we have experimented with defining this as "SHOULD+" (with a related "MUST-" which means "MUST implement now, but it is expected this will be downgraded in the future"). These definitions were only somewhat popular. IETF regulars understood them well, but other developers were confused. >The document does not state that the goal is to make the registry authoritative, the document (RFC) would be (and any updating doc). The goal of the column is to put the status of each algorithm (based on the relevant RFC) so implementors don't have to search through RFC's and DNSSEC history (since some RFC's that specify algorithms do not give their status) to find out what algorithms should be included, what the future direction might be, and which algorithms are falling out of favor. In essence, this document proposes adding a column to the IANA registry with the normative levels from this document. The result is that an implementer would see a column with MUST and SHOULD and so on. What happens if a different standards-track document adds another column with different values? Will the implementer be better off or worse off? (Yes, that's an obviously leading question.) Instead of adding such a column to the registry, it might be more helpful to have the registry list standards track RFCs that are collections of normative levels. In the best situation, that list lists exactly one RFC (this one). If in the future there is a reason to have two different standards track RFCs listed, the developer could easily read each of them and make a judgement about which RFC they want to follow, if any. --Paul Hoffman, Director --VPN Consortium From owner-namedroppers@ops.ietf.org Thu Jun 24 09:47:34 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 807E93A67E3; Thu, 24 Jun 2010 09:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.027 X-Spam-Level: *** X-Spam-Status: No, score=3.027 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNMsv2glIZ+2; Thu, 24 Jun 2010 09:47:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 66B193A6403; Thu, 24 Jun 2010 09:47:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORpWO-000JAP-IM for namedroppers-data0@psg.com; Thu, 24 Jun 2010 16:43:24 +0000 Received: from [74.125.82.52] (helo=mail-ww0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORpWL-000J9j-Sr for namedroppers@ops.ietf.org; Thu, 24 Jun 2010 16:43:22 +0000 Received: by wwb13 with SMTP id 13so1792139wwb.11 for ; Thu, 24 Jun 2010 09:43:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.69.204 with SMTP id a12mr9311649wbj.153.1277397798808; Thu, 24 Jun 2010 09:43:18 -0700 (PDT) Received: by 10.220.164.144 with HTTP; Thu, 24 Jun 2010 09:43:18 -0700 (PDT) In-Reply-To: <34857.1277371932@nsa.vix.com> References: <34857.1277371932@nsa.vix.com> Date: Thu, 24 Jun 2010 09:43:18 -0700 Message-ID: Subject: Re: [dnsext] draft-vixie-dnsext-resimprove-00: Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Paul Vixie Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 2.6 - I not sure that randomly reducing the TTL as suggested is a good idea. Instead it may be better to randomise when the record is revalidated (or prefetched). The difference is that I think that the resolver should advertise the "honest" decrementing TTL to any queries. That way if you have a hierarchy of resolvers they aren't simply making the effective TTL shorter and shorter still. On 3.4 - I see the security note at 5.1, but still - an attacker might poison with a long-ttl NXDOMAIN response for "com" or "." and it will cause a lot of problems for the resolver. As written, it may even cause the cache to have to purge potentially a large volume of data. I'm not sure I see the benefit, insulating upstream servers from slightly more queries seems less important. Are NXDOMAIN subtrees really a big problem? On 4.4 - what happens when no nameservers are returned? Sometimes the nameservers to which a domain have been delegated have incoherent opinions about where the apex even is. E.g. example.com delegates www.example.com to ns-1.foo.com ns-1.foo.com considers itself authoritative for "example.com" and has a record configured for www.example.com A query for www.example.com's NS records would return 0 answers, but NOE= RROR. This works right now, and while it's incoherent, it's a relatively common misconfiguration. On Thu, Jun 24, 2010 at 2:32 AM, Paul Vixie wrote: > after years of rejections, i finally realized that the ietf reject-o-bot > could be fooled into accepting my internet drafts if i moved the abstract > to the second page, after the boilerplate, and if i stopped tagging the > creation date with "Creation Date:" and stopped representing the creation > date in the same yyyy-mm-dd format as the expiration date, but rather in > "mmmm dd, yyyy" format under the list of author names. what a glorious wa= y > to spend my time. > > anyway we can apparently, finally share this. =A0looks like the URI is: > > =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-0= 0 > > i'll find out what else has been jammed in my queue, that i'd given up ev= er > publishing. abstract on the second page, what a hoot. > > re: > > > > ---------- Forwarded message ---------- > From:=A0IETF I-D Submission Tool > To:=A0vixie@isc.org > Date:=A0Wed, 23 Jun 2010 07:24:46 -0700 (PDT) > Subject:=A0New Version Notification for draft-vixie-dnsext-resimprove-00 > > A new version of I-D, draft-vixie-dnsext-resimprove-00.txt has been succe= ssfully submitted by Paul Vixie and posted to the IETF repository. > > Filename: =A0 =A0 =A0 =A0draft-vixie-dnsext-resimprove > Revision: =A0 =A0 =A0 =A000 > Title: =A0 =A0 =A0 =A0 =A0 Improvements to DNS Resolvers for Resiliency, = Robustness, and Responsiveness > Creation_date: =A0 2010-06-22 > WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission > Number_of_pages: 6 > > Abstract: > This document describes several mechanisms which can be employed by > iterative caching DNS resolvers to improve resiliency, robustness, > and responsiveness. =A0These improvements are optional and they require > no changes to the protocol, or to authority servers, or to DNS stub > resolver clients. > > > > The IETF Secretariat. > > > > --=20 Colm From owner-namedroppers@ops.ietf.org Thu Jun 24 10:02:24 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFEFA3A6831; Thu, 24 Jun 2010 10:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9NfhR40KyRH; Thu, 24 Jun 2010 10:02:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E2FF63A683A; Thu, 24 Jun 2010 10:02:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORpjY-000LRW-Kw for namedroppers-data0@psg.com; Thu, 24 Jun 2010 16:57:00 +0000 Received: from [209.85.161.180] (helo=mail-gx0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORpjU-000LQx-M4 for namedroppers@ops.ietf.org; Thu, 24 Jun 2010 16:56:56 +0000 Received: by gxk1 with SMTP id 1so3386617gxk.11 for ; Thu, 24 Jun 2010 09:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+/m5KG2W0nQYc0E4saQWqbpFZmBaNfRykIsIZktWUd4=; b=eZP4n0iiVTbiOl1QU9yn5sYbvvJGvohU+o7yMFEPGRFSbDb+a7ltFoDDcyU1Y782+G bFCOHRDYK+vOuaS3Jwo14exxFbSyDyj91UG1DbRhAOvSIya9co1PnOt6khuDXtyvIffC R1f3a9f1xcvhv0ovAlnsD7TpMViCmpj5UAyTc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=j2a0QkngRqdgoJlwNfTXwlhE4otK7MihAUywHYKJtwmfze0ZlMuPHXabZCjiTc20c7 4jFVBK2V0D+1JOVxNAo+ic3hmdc11Pq945Vfbgi7k1RQXqCjjcxhsPY8XdxUSHPt3yPp iYdBVXy2X3DvphWrBf6fZUkF/8D26vSlYCgPY= MIME-Version: 1.0 Received: by 10.101.2.4 with SMTP id e4mr8324543ani.54.1277398614277; Thu, 24 Jun 2010 09:56:54 -0700 (PDT) Received: by 10.100.151.6 with HTTP; Thu, 24 Jun 2010 09:56:54 -0700 (PDT) In-Reply-To: References: <821vbwbxz8.fsf@mid.bfk.de> <09637CA4-6946-4BD0-A9EA-AAD0EA61CE99@nist.gov> Date: Thu, 24 Jun 2010 13:56:54 -0300 Message-ID: Subject: Re: [dnsext] Proposed fixes for draft-registry-fixes From: Brian Dickson To: Paul Hoffman Cc: "Rose, Scott W." , Florian Weimer , IETF DNSEXT WG Content-Type: multipart/alternative; boundary=0016368e35a5a3ff940489c98a91 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: --0016368e35a5a3ff940489c98a91 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 24, 2010 at 12:55 PM, Paul Hoffman wrote: > At 9:51 AM -0400 6/24/10, Rose, Scott W. wrote: > > > Isn't the official set of adjectives REQUIRED, OPTIONAL and > >> RECOMMENDED, anyway? > >> > >Could go with the 2119 defs and use REQUIRED and OPTIONAL, but there isn't > anything that syncs with ENCOURAGED. "RECOMMENDED" comes close, but there's > a need to give a hint about future path (the RFC 2119 def of RECOMMENDED > doesn't have this, so we can't assume it will be implied). > > > >The terms were originally from draft-ogud-iana-protocol-maintenance-words > > There are at least two ways to go here: > > - Use the official word "SHOULD" with an in-line augmentation > > - Define a new word-meaning pair > > The first way would be a lot clearer to most implementers. For example, the > text can say "SHOULD implement because it is expected that this will become > a MUST-level requirement in the future". > > What about associating the word-to-use (and optionally its meaning if a new word-meaning pair are used), with the document status? It's a bit self-referential, but allows the document to essentially self-modify as the standard progresses along the standards track, without actually changing any of the text itself, only the current reading of the text. The challenge is in making the text readable, and yet having the definition both clear and sufficiently generic so as to be usable in any such document. In the abstract, it would be "metaterm(term,state)", where "term" would be the generic form (or eventual form, once full standard state is reached), and "state" is a way of representing the current document state (draft, proposed, full standard), and the "metaterm" function combines the two inputs with suitable syntactic sugar. Candidates for metaterm might be, for example: ${term}_\$${shortstate} (for example, "MUST_$SS" ) ${term}[${shortstate}] (for example, "MUST[SS] ) ${term}%${shortstate} (for example, "MUST%SS" ) This then needs "definemetaterm(term, state, @term_state_list)" which produces an instantiated list of metaterm definitions, for each metaterm used. Each document would need to include in a definitions section, with table(s) (the "definemetaterm" output(s)), that would look like: metaterm(term,state) is defined as follows: ${shortstate1} REALTERM1 ${shortstate2} REALTERM2 ... For example: MUST[SS] is defined as follows: SS MUST[SS] -- -------- DS SHOULD PS MUST STD MUST (and so on, for each term that might want to change as the standard "matures".) This could even be done as a normal 2-d table, with the x-axis being metaterms, and y-axis being document state, and cells being per-state terms. It's a bit more explicit, and certainly unambiguous, and fits nicely into tables such as the one we're thinking of for IANA. Thoughts? Brian > In the Security Area, we have experimented with defining this as "SHOULD+" > (with a related "MUST-" which means "MUST implement now, but it is expected > this will be downgraded in the future"). These definitions were only > somewhat popular. IETF regulars understood them well, but other developers > were confused. > > >The document does not state that the goal is to make the registry > authoritative, the document (RFC) would be (and any updating doc). The goal > of the column is to put the status of each algorithm (based on the relevant > RFC) so implementors don't have to search through RFC's and DNSSEC history > (since some RFC's that specify algorithms do not give their status) to find > out what algorithms should be included, what the future direction might be, > and which algorithms are falling out of favor. > > In essence, this document proposes adding a column to the IANA registry > with the normative levels from this document. The result is that an > implementer would see a column with MUST and SHOULD and so on. > > What happens if a different standards-track document adds another column > with different values? Will the implementer be better off or worse off? > (Yes, that's an obviously leading question.) > > Instead of adding such a column to the registry, it might be more helpful > to have the registry list standards track RFCs that are collections of > normative levels. In the best situation, that list lists exactly one RFC > (this one). If in the future there is a reason to have two different > standards track RFCs listed, the developer could easily read each of them > and make a judgement about which RFC they want to follow, if any. > > --Paul Hoffman, Director > --VPN Consortium > > --0016368e35a5a3ff940489c98a91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 24, 2010 at 12:55 PM, Paul H= offman <paul.= hoffman@vpnc.org> wrote:
At 9:51 AM -0400 6/24/10, Rose, Scott W. wrote:
> > Isn't the official set of adjectives REQUIRED, OPTIONAL and >> RECOMMENDED, anyway?
>>
>Could go with the 2119 defs and use REQUIRED and OPTIONAL, but there is= n't anything that syncs with ENCOURAGED. =A0"RECOMMENDED" com= es close, but there's a need to give a hint about future path (the RFC = 2119 def of RECOMMENDED doesn't have this, so we can't assume it wi= ll be implied).
>
>The terms were originally from draft-ogud-iana-protocol-maintenance-wor= ds

There are at least two ways to go here:

- Use the official word "SHOULD" with an in-line augmentation

- Define a new word-meaning pair

The first way would be a lot clearer to most implementers. For example, the= text can say "SHOULD implement because it is expected that this will = become a MUST-level requirement in the future".


What about associating the word-to-use (and optio= nally its meaning if a new word-meaning pair are used), with the document s= tatus?

It's a bit self-referential, but allows the document to e= ssentially self-modify as the standard progresses along the standards track= , without actually changing any of the text itself, only the current readin= g of the text.

The challenge is in making the text readable, and yet having the defini= tion both clear and sufficiently generic so as to be usable in any such doc= ument.

In the abstract, it would be "metaterm(term,state)"= , where "term" would be the generic form (or eventual form, once = full standard state is reached), and "state" is a way of represen= ting the current document state (draft, proposed, full standard), and the &= quot;metaterm" function combines the two inputs with suitable syntacti= c sugar.

Candidates for metaterm might be, for example:
${term}_\$${shortstat= e} (for example, "MUST_$SS" )
${term}[${shortstate}] (for exam= ple, "MUST[SS] )
${term}%${shortstate} (for example, "MUST%SS&= quot; )

This then needs "definemetaterm(term, state, @term_state_list)&quo= t; which produces an instantiated list of metaterm definitions, for each me= taterm used.
Each document would need to include in a definitions sectio= n, with table(s) (the "definemetaterm" output(s)), that would loo= k like:

metaterm(term,state) is defined as follows:
${shortstate1}=A0 REALTE= RM1
${shortstate2}=A0 REALTERM2
...

For example:

MUST[S= S] is defined as follows:
SS=A0=A0=A0=A0 MUST[SS]
--=A0=A0=A0=A0 ----= ----
DS=A0=A0=A0 SHOULD
PS=A0=A0=A0 MUST
STD=A0 MUST

(and so on, for each term that might= want to change as the standard "matures".)

This could eve= n be done as a normal 2-d table, with the x-axis being metaterms, and y-axi= s being document state, and cells being per-state terms.

It's a bit more explicit, and certainly unambiguous, and fits nicel= y into tables such as the one we're thinking of for IANA.

Though= ts?

Brian
=A0
In the Security Area, we have experimented with defining this as "SHOU= LD+" (with a related "MUST-" which means "MUST implemen= t now, but it is expected this will be downgraded in the future"). The= se definitions were only somewhat popular. IETF regulars understood them we= ll, but other developers were confused.

>The document does not state that the goal is to make the registry autho= ritative, the document (RFC) would be (and any updating doc). =A0The goal o= f the column is to put the status of each algorithm (based on the relevant = RFC) so implementors don't have to search through RFC's and DNSSEC = history (since some RFC's that specify algorithms do not give their sta= tus) to find out what algorithms should be included, what the future direct= ion might be, and which algorithms are falling out of favor.

In essence, this document proposes adding a column to the IANA regist= ry with the normative levels from this document. The result is that an impl= ementer would see a column with MUST and SHOULD and so on.

What happens if a different standards-track document adds another column wi= th different values? Will the implementer be better off or worse off? (Yes,= that's an obviously leading question.)

Instead of adding such a column to the registry, it might be more helpful t= o have the registry list standards track RFCs that are collections of norma= tive levels. In the best situation, that list lists exactly one RFC =A0(thi= s one). If in the future there is a reason to have two different standards = track RFCs listed, the developer could easily read each of them and make a = judgement about which RFC they want to follow, if any.

--Paul Hoffman, Director
--VPN Consortium


--0016368e35a5a3ff940489c98a91-- From owner-namedroppers@ops.ietf.org Thu Jun 24 10:09:26 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1DC93A68AC; Thu, 24 Jun 2010 10:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DX1aT3sH+Ybk; Thu, 24 Jun 2010 10:09:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 052FF3A6874; Thu, 24 Jun 2010 10:09:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORpsZ-000N67-19 for namedroppers-data0@psg.com; Thu, 24 Jun 2010 17:06:19 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORpsW-000N5f-LQ for namedroppers@ops.ietf.org; Thu, 24 Jun 2010 17:06:17 +0000 Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5OH5l2r040194; Thu, 24 Jun 2010 13:05:48 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.100] by Work-Laptop-2.local (PGP Universal service); Thu, 24 Jun 2010 13:05:58 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 24 Jun 2010 13:05:58 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <201006081432.o58EWSEB034243@drugs.dv .isc.org><201006082226.o58MQXlh041976 @drugs.dv.isc.org><201006240030.o5O0U NQY071797@drugs.dv.isc.org><3D60313831F7497FB1BFE9D732C55089@local> Date: Thu, 24 Jun 2010 13:05:32 -0400 To: "George Barwood" From: Edward Lewis Subject: Re: [dnsext] Section 5.1 of draft-dnssec-bis Cc: "Donald Eastlake" , "Edward Lewis" , "Mark Andrews" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At 15:41 +0100 6/24/10, George Barwood wrote: >Nowhere does it define the canonical form of a domain name, >so we are apparently left to guess what this might be. I disagree - it is pretty clear if you read the RFC for what an RFC is. True that there's no mention of "canonical form of a domain name" in the section, but it is clear that the intent is to down case. (I'm reflecting what the text says, not trying to re-ignite the debate over whether the down casing is correct.) If one wants to pick nits on the fact that in one place it says "canonical domain name" in one location and then "canonical RR" in another place, you might as well start at the beginning and nit pick all of the documents. The RFCs have to be read with an understanding that they are describing the engineering intent and not the precise verbiage of a proscriptive specification. Even if we try to write them as specifications. For example, I often lean on RFC 1034's section 4.3.2. In a comment early in the wild card "clarify" document discussion, Rob Austein made it clear that that section was about intent, not about code and not even pseudo-code. The algorithm described the intended result of the search, not how you would code it up. The specs do say "down case" the name. But the rationale was in error. The question is how to fix this, as Mark has already asked. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 The World Cup would be more fun if they didn't interrupt it with soccer games. From owner-namedroppers@ops.ietf.org Thu Jun 24 10:25:30 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B730C28C0E2; Thu, 24 Jun 2010 10:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.781 X-Spam-Level: X-Spam-Status: No, score=0.781 tagged_above=-999 required=5 tests=[AWL=-1.138, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZkjNCje9991; Thu, 24 Jun 2010 10:25:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A8FE83A6837; Thu, 24 Jun 2010 10:25:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORq7c-000PNH-Pm for namedroppers-data0@psg.com; Thu, 24 Jun 2010 17:21:52 +0000 Received: from [74.125.82.52] (helo=mail-ww0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORq7a-000PMn-9p for namedroppers@ops.ietf.org; Thu, 24 Jun 2010 17:21:50 +0000 Received: by wwb13 with SMTP id 13so1842270wwb.11 for ; Thu, 24 Jun 2010 10:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yJ5zlKBKSSjy1rLB/Rt5jIprWz3XuD2YDb3UWCkUvII=; b=pKXvlXU4L0b3DUD7RFkARLxAwzByiABzST75+2oPBU1h9as1+krkNIPtdb0lfGKej7 RIZToXbGtiH1kp30aCzoEfPHx4VFWzFhaNM8hUxDDR6aTfduF/NwH3yVL2kNfNnf6MXQ 4kt9ST+z8Mn+B9C92iNzFGDM6NTqMkzkltdZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dduaz35NzeMiMLoEEYPHrwrNbRrcXb86NsVeQID5SvppcdBMishFOoApXNyUYJTClx OpIo3Aev/78avJmpbXX+JC0dHhPpsD9fIVlWcVb4wdL+4L/5O8xB9pusazAAA9Az6fpj 9+hRDHsDFkyv2Mtt+ONV0gScvriDoz3b3wN3M= MIME-Version: 1.0 Received: by 10.216.87.200 with SMTP id y50mr7614554wee.0.1277400108728; Thu, 24 Jun 2010 10:21:48 -0700 (PDT) Received: by 10.216.229.210 with HTTP; Thu, 24 Jun 2010 10:21:48 -0700 (PDT) In-Reply-To: References: <3D60313831F7497FB1BFE9D732C55089@local> Date: Thu, 24 Jun 2010 13:21:48 -0400 Message-ID: Subject: Re: [dnsext] Section 5.1 of draft-dnssec-bis From: Donald Eastlake To: George Barwood Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: +1 Donald On Thu, Jun 24, 2010 at 1:05 PM, Edward Lewis wrote: > At 15:41 +0100 6/24/10, George Barwood wrote: > >> Nowhere does it define the canonical form of a domain name, >> so we are apparently left to guess what this might be. > > I disagree - it is pretty clear if you read the RFC for what an RFC is. > =A0True that there's no mention of "canonical form of a domain name" in t= he > section, but it is clear that the intent is to down case. =A0(I'm reflect= ing > what the text says, not trying to re-ignite the debate over whether the d= own > casing is correct.) > > If one wants to pick nits on the fact that in one place it says "canonica= l > domain name" in one location and then "canonical RR" in another place, yo= u > might as well start at the beginning and nit pick all of the documents. = =A0The > RFCs have to be read with an understanding that they are describing the > engineering intent and not the precise verbiage of a proscriptive > specification. =A0Even if we try to write them as specifications. > > For example, I often lean on RFC 1034's section 4.3.2. =A0In a comment ea= rly > in the wild card "clarify" document discussion, Rob Austein made it clear > that that section was about intent, not about code and not even pseudo-co= de. > =A0The algorithm described the intended result of the search, not how you > would code it up. > > The specs do say "down case" the name. =A0But the rationale was in error.= =A0The > question is how to fix this, as Mark has already asked. > -- > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= - > Edward Lewis > NeuStar =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0You can leave a voice mess= age at +1-571-434-5468 > > The World Cup would be more fun if they didn't interrupt it with soccer > games. > From owner-namedroppers@ops.ietf.org Thu Jun 24 11:52:58 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24A03A657C; Thu, 24 Jun 2010 11:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8eXKCubfAmS; Thu, 24 Jun 2010 11:52:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BBABB3A6837; Thu, 24 Jun 2010 11:52:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORrS7-000C3P-TK for namedroppers-data0@psg.com; Thu, 24 Jun 2010 18:47:07 +0000 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORrS4-000C2f-Ih for namedroppers@ops.ietf.org; Thu, 24 Jun 2010 18:47:04 +0000 Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o5OIkmgr014206 for ; Thu, 24 Jun 2010 14:46:48 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 24 Jun 2010 14:46:32 -0400 From: "Rose, Scott W." To: IETF DNSEXT WG Date: Thu, 24 Jun 2010 14:46:46 -0400 Subject: Re: [dnsext] Proposed fixes for draft-registry-fixes Thread-Topic: [dnsext] Proposed fixes for draft-registry-fixes Thread-Index: AcsTzZA20I6rmlatTeWEq1akN7FDPQ== Message-ID: References: <821vbwbxz8.fsf@mid.bfk.de> <09637CA4-6946-4BD0-A9EA-AAD0EA61CE99@nist.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scott.rose@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 24, 2010, at 11:55 AM, Paul Hoffman wrote: > At 9:51 AM -0400 6/24/10, Rose, Scott W. wrote: >>> Isn't the official set of adjectives REQUIRED, OPTIONAL and >>> RECOMMENDED, anyway? >>> >> Could go with the 2119 defs and use REQUIRED and OPTIONAL, but there isn't anything that syncs with ENCOURAGED. "RECOMMENDED" comes close, but there's a need to give a hint about future path (the RFC 2119 def of RECOMMENDED doesn't have this, so we can't assume it will be implied). >> >> The terms were originally from draft-ogud-iana-protocol-maintenance-words > > There are at least two ways to go here: > > - Use the official word "SHOULD" with an in-line augmentation > > - Define a new word-meaning pair > > The first way would be a lot clearer to most implementers. For example, the text can say "SHOULD implement because it is expected that this will become a MUST-level requirement in the future". > > In the Security Area, we have experimented with defining this as "SHOULD+" (with a related "MUST-" which means "MUST implement now, but it is expected this will be downgraded in the future"). These definitions were only somewhat popular. IETF regulars understood them well, but other developers were confused. > That's the driving force behind draft-ogud-iana-protocol-maintance-words (or was, anyway). >> The document does not state that the goal is to make the registry authoritative, the document (RFC) would be (and any updating doc). The goal of the column is to put the status of each algorithm (based on the relevant RFC) so implementors don't have to search through RFC's and DNSSEC history (since some RFC's that specify algorithms do not give their status) to find out what algorithms should be included, what the future direction might be, and which algorithms are falling out of favor. > > In essence, this document proposes adding a column to the IANA registry with the normative levels from this document. The result is that an implementer would see a column with MUST and SHOULD and so on. > > What happens if a different standards-track document adds another column with different values? Will the implementer be better off or worse off? (Yes, that's an obviously leading question.) > > Instead of adding such a column to the registry, it might be more helpful to have the registry list standards track RFCs that are collections of normative levels. In the best situation, that list lists exactly one RFC (this one). If in the future there is a reason to have two different standards track RFCs listed, the developer could easily read each of them and make a judgement about which RFC they want to follow, if any. > Ok - not opposed to that. The reasoning behind a column was to have the registry sync with the DS RR Type Digest Algorithm registry. One question: Should there be 3 or 4 lists? I can see the MUST list, an OPTIONAL list an OBSOLETE list, but should there be a RECOMMENDED/ENCOURAGED/SHOULD+ list? Scott > --Paul Hoffman, Director > --VPN Consortium =================================== Scott Rose NIST scottr@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =================================== From owner-namedroppers@ops.ietf.org Thu Jun 24 18:32:06 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DD913A68A3; Thu, 24 Jun 2010 18:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.249 X-Spam-Level: ** X-Spam-Status: No, score=2.249 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvKt1jvJBiF6; Thu, 24 Jun 2010 18:32:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE0543A677D; Thu, 24 Jun 2010 18:32:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORxeW-00078s-HD for namedroppers-data0@psg.com; Fri, 25 Jun 2010 01:24:20 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORxeT-00078a-DU for namedroppers@ops.ietf.org; Fri, 25 Jun 2010 01:24:17 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1652F1ECB408 for ; Fri, 25 Jun 2010 01:24:16 +0000 (UTC) Date: Thu, 24 Jun 2010 21:24:14 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: [dnsext] DNSEXT sessions at IETF 78 Message-ID: <20100625012414.GC9741@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, The IETF 78 agenda is up. We have two sessions scheduled. The first of these is intended to be regular WG business, and is intended to discuss the new proposed charter, the various drafts we have on our plate, and so on. If you are a regular participant in DNSEXT, this meeting session is aimed squarely at you. We have two hours scheduled, from 15:20-17:20 local time on Monday. Here's what's in that slot: httpbis, dnsext, mext, opsarea, enum, soc, pim, rtgarea. The other session is a one hour session aimed just at the topic of aliasing, and in particular at gathering more requirements, objections, corner cases, worries, and so on about this topic. It is primarily aimed at requirements gathering, which means that any telling anyone what is simply impossible in the DNS won't be allowed. The point is not, in this session, to say what we can or can't do, but to try to get straight as much as possible all the issues that people have with aliasing, what doesn't work, what does, what current behaviour people rely on, and so on. This session is for one hour on Wed, 10:30-11:30 local time. Here's what's in that slot: core, vcarddav, dnsext, mboned, drinks, mpls. We'll have more to say about this soon. Thanks very much to Ralph for making our case for this extra special spot. We don't intend to do this often! Best regards, Andrew -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Thu Jun 24 19:34:32 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8930C3A69F4; Thu, 24 Jun 2010 19:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2hIRe2Lnu0C; Thu, 24 Jun 2010 19:34:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5DF8E3A696C; Thu, 24 Jun 2010 19:34:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORyfX-000Dr2-53 for namedroppers-data0@psg.com; Fri, 25 Jun 2010 02:29:27 +0000 Received: from [207.210.219.233] (helo=stpeter.im) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ORyfT-000Doz-GP for namedroppers@ops.ietf.org; Fri, 25 Jun 2010 02:29:23 +0000 Received: from squire.local (dsl-251-119.dynamic-dsl.frii.net [216.17.251.119]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A75BB40E66; Thu, 24 Jun 2010 20:29:19 -0600 (MDT) Message-ID: <4C24147E.6060907@stpeter.im> Date: Thu, 24 Jun 2010 20:29:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrew Sullivan CC: namedroppers@ops.ietf.org, alexey Melnikov Subject: Re: [dnsext] DNSEXT sessions at IETF 78 References: <20100625012414.GC9741@shinkuro.com> In-Reply-To: <20100625012414.GC9741@shinkuro.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070001070801000707010003" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a cryptographically signed message in MIME format. --------------ms070001070801000707010003 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/24/10 7:24 PM, Andrew Sullivan wrote: > The other session is a one hour session aimed just at the topic of > aliasing, and in particular at gathering more requirements, > objections, corner cases, worries, and so on about this topic. It is > primarily aimed at requirements gathering, which means that any > telling anyone what is simply impossible in the DNS won't be allowed. > The point is not, in this session, to say what we can or can't do, but > to try to get straight as much as possible all the issues that people > have with aliasing, what doesn't work, what does, what current > behaviour people rely on, and so on. This session is for one hour on > Wed, 10:30-11:30 local time. Here's what's in that slot: core, > vcarddav, dnsext, mboned, drinks, mpls. Thanks for organizing that session. Let's make sure we advertise it far and wide (among APPS, RAI, etc.). I'm sure that Alexey and I would be happy for you to give a short plug in the AppsArea meeting. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms070001070801000707010003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYyNTAyMjkxOFowIwYJKoZIhvcNAQkEMRYEFIGSTn9sk6r2ZzAnWwwk +UPwGArgMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAXKMwc+uZCQeO+X3B0yZiyCsj4FHePUbRP4i/+3lr 0NO1enNSKU+eO0qD5iXYZFvuf1lX76Pel6DZmZD27MKjzNNgGjlwRJh/hhoitr1MO7aQNO6+ BIaIPgn0cHW8XlAndzZ1mC7/joe7L6SSUXlyTdlXGujpovDHkVSMLGstVAy1OwlLg7DFk5SO xLcXoXkW6JHfrbvyh7LdaAGr+MqX69RGXBcc/L1vsVpyB4OtH+aNxwUYF5Htt45MJEFbe+t0 9PfcwuS8p4fMO6VFpQrqgIKNVx9Zn+zW+oFdD4Va7pADzUlK3yIwMkNc7irQ1SyFJv8LSRfX 5tbVKtAzKKcj7gAAAAAAAA== --------------ms070001070801000707010003-- From owner-namedroppers@ops.ietf.org Thu Jun 24 22:22:52 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093823A67D0; Thu, 24 Jun 2010 22:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.355 X-Spam-Level: ** X-Spam-Status: No, score=2.355 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aXHG3y9mD6G; Thu, 24 Jun 2010 22:22:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B3A83A659B; Thu, 24 Jun 2010 22:22:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OS1HX-0005IC-0B for namedroppers-data0@psg.com; Fri, 25 Jun 2010 05:16:51 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OS1HU-0005HX-1N for namedroppers@ops.ietf.org; Fri, 25 Jun 2010 05:16:48 +0000 Received: (eyou send program); Fri, 25 Jun 2010 13:16:45 +0800 Message-ID: <477443005.14379@cnnic.cn> Received: from 140.113.167.130 by mail.cnnic.cn with HTTP; Fri, 25 Jun 2010 13:16:45 +0800 X-WebMAIL-MUA: [140.113.167.130] From: "Zheng Wang" To: colm@allcosts.net Cc: vixie@isc.org, namedroppers@ops.ietf.org Date: Fri, 25 Jun 2010 13:16:45 +0800 Reply-To: "Zheng Wang" X-Priority: 3 Subject: Re: [dnsext] draft-vixie-dnsext-resimprove-00: Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness Content-Type: text/plain Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: >On 2.6 - I not sure that randomly reducing the TTL as suggested is a >good idea. Instead it may be better to randomise when the record is >revalidated (or prefetched). The difference is that I think that the >resolver should advertise the "honest" decrementing TTL to any >queries. That way if you have a hierarchy of resolvers they aren't >simply making the effective TTL shorter and shorter still. > In my view, they are separate concepts. The advertised TTL adheres to the original definition, while the TTL used for delegation validation is randomly reduced. >On 3.4 - I see the security note at 5.1, but still - an attacker might >poison with a long-ttl NXDOMAIN response for "com" or "." and it will >cause a lot of problems for the resolver. As written, it may even >cause the cache to have to purge potentially a large volume of data. >I'm not sure I see the benefit, insulating upstream servers from >slightly more queries seems less important. Are NXDOMAIN subtrees >really a big problem? > No, the purpose of delegation validation is likewise right here to maintain the coherency. >On 4.4 - what happens when no nameservers are returned? Sometimes the >nameservers to which a domain have been delegated have incoherent >opinions about where the apex even is. E.g. > > example.com delegates www.example.com to ns-1.foo.com > > ns-1.foo.com considers itself authoritative for "example.com" and >has a record configured for www.example.com > > A query for www.example.com's NS records would return 0 answers, but NOERROR. > >This works right now, and while it's incoherent, it's a relatively >common misconfiguration. > This still works, but the delegated nameservers have no chance to be replaced by the true authoritative ones and thus have to be relied on. Regards, ------------------------------ Zheng Wang CNNIC Labs _________________________________________________________ China Internet Network Information Center Phone: (8610)-58813212 Fax: (8610)-58812666-123 Email: wangzheng@cnnic.cn Address: 4, South 4th Street, Zhongguancun Haidian District, Beijing P.R.China 100190 ________________________________________ From dnsext-archive@ietf.org Fri Jun 25 01:38:05 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD7B3A691D for ; Fri, 25 Jun 2010 01:38:05 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: dnsext-archive VIAGRA \256 Official Site -44%\n X-Spam-Flag: NO X-Spam-Score: -19.813 X-Spam-Level: X-Spam-Status: No, score=-19.813 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yruWhuYX7q+k for ; Fri, 25 Jun 2010 01:38:04 -0700 (PDT) Received: from 78-25-39-52.static.vega-ua.net (78-25-39-52.static.vega-ua.net [78.25.39.52]) by core3.amsl.com (Postfix) with SMTP id B46BB3A694E for ; Fri, 25 Jun 2010 01:38:02 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive VIAGRA ® Official Site -44% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100625083802.B46BB3A694E@core3.amsl.com> Date: Fri, 25 Jun 2010 01:38:02 -0700 (PDT)
Click here.

Dear dnsext-archive@ietf.org
From owner-namedroppers@ops.ietf.org Fri Jun 25 02:36:04 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892043A67B4; Fri, 25 Jun 2010 02:36:04 -0700 (PDT) X-Quarantine-ID: <74Iqf3G4yWHi> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 3.457 X-Spam-Level: *** X-Spam-Status: No, score=3.457 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74Iqf3G4yWHi; Fri, 25 Jun 2010 02:36:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 42ED93A63C9; Fri, 25 Jun 2010 02:36:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OS5DY-000Dfg-NU for namedroppers-data0@psg.com; Fri, 25 Jun 2010 09:29:00 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OS5DV-000DfI-LA for namedroppers@ops.ietf.org; Fri, 25 Jun 2010 09:28:58 +0000 Received: (eyou send program); Fri, 25 Jun 2010 17:28:54 +0800 Message-ID: <477458134.25573@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 25 Jun 2010 17:28:54 +0800 Message-ID: <0006E9B2E0A64E8B9574B416A00AECE7@LENOVO47E041CF> From: "Jiankang YAO" To: "George Barwood" , "Mark Andrews" Cc: References: <476592152.09177@cnnic.cn> <833E80C68446499A9F68638299F2F349@local> <476687310.07502@cnnic.cn> <9497997BEBD1436AA9B3BB63A1DBB7D7@local> <476725138.09630@cnnic.cn> Subject: [dnsext] bname new algorithm identifier Date: Fri, 25 Jun 2010 17:28:55 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk1hcmsgQW5kcmV3cyIgPG1h cmthQGlzYy5vcmc+DQpUbzogIkdlb3JnZSBCYXJ3b29kIiA8Z2VvcmdlLmJhcndvb2RAYmx1ZXlv bmRlci5jby51az4NCkNjOiAiSmlhbmthbmcgWUFPIiA8eWFvamtAY25uaWMuY24+OyA8bmFtZWRy b3BwZXJzQG9wcy5pZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBKdW5lIDE3LCAyMDEwIDU6Mzcg QU0NClN1YmplY3Q6IFJlOiBbZG5zZXh0XSBGdzogSS1EIEFjdGlvbjpkcmFmdC15YW8tZG5zZXh0 LWJuYW1lLTAyLnR4dCANCg0KDQo+IA0KPiBJbiBtZXNzYWdlIDw5NDk3OTk3QkVCRDE0MzZBQTlC M0JCNjNBMURCQjdEN0Bsb2NhbD4sICJHZW9yZ2UgQmFyd29vZCIgd3JpdGVzOg0KPj4gPiAtLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPj4gPiBGcm9tOiAiR2VvcmdlIEJhcndvb2QiIDxn ZW9yZ2UuYmFyd29vZEBibHVleW9uZGVyLmNvLnVrPg0KPj4gPiBUbzogIkppYW5rYW5nIFlBTyIg PHlhb2prQGNubmljLmNuPjsgPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQo+PiA+IFNlbnQ6 IFR1ZXNkYXksIEp1bmUgMTUsIDIwMTAgNTo0MiBQTQ0KPj4gPiBTdWJqZWN0OiBSZTogW2Ruc2V4 dF0gRnc6IEktRCBBY3Rpb246ZHJhZnQteWFvLWRuc2V4dC1ibmFtZS0wMi50eHQgDQo+PiA+IA0K Pj4gPj4gQXMgZmFyIGFzIEkgY2FuIHNlZSwgRE5BTUUgaXMgY2FwYWJsZSBvZiBwcmV2ZW50aW5n IGFuIGV4cG9uZW50aWFsIGluY3JlYXNlDQo+PiA+PiBpbiByZWNvcmRzLCBhbmQgdGhlIG5lY2Vz c2l0eSBvZiBtaXJyb3JpbmcgYW55IGRhdGEgcmVjb3JkcyBpbiB0aGUgem9uZSBhcGV4DQo+PiA+ PiB0aGF0IGFyZSBub3QgcmVkaXJlY3RlZCBieSBETkFNRSBpcyBhIHJlbGF0aXZlbHkgbWlub3Ig YWRtaW5pc3RyYXRpdmUgaW5jb252ZW5pZW5jZSwNCj4+ID4+IHRoYXQgY2FuIHByb2JhYmx5IGJl IG1pdGlnYXRlZCBieSBqdWRpY2lvdXMgdXNlIG9mIHRoZSAkSU5DTFVERSBkaXJlY3RpdmUuDQo+ PiA+PiANCj4+ID4gDQo+PiA+IHRoZXJlIGlzIGEgZG5hbWUgZGlzY3Vzc2lvbiByZWxhdGVkIHRv IHRoZSBkcmFmdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQteWFvLWRuc29wLWlkbnRs ZC1pbXBsZW1lbnRhdGlvbi0wMS50eHQNCj4+ID4gaW4gZG5zb3AgbGlzdC4gIHlvdSBtYXkgc2Vl IGl0IGluIGRuc29wIGxpc3QNCj4+ID4gDQo+PiA+PiBUaGUgZHJhZnQgZG9lcyBub3Qgc2VlbSB0 byBtZW50aW9uIHRoZSBpbmNvbXBhdGliaWxpdHkgb2YgQk5BTUUgd2l0aCBleGlzdGluZyB2YWxp ZGF0aW5nDQo+PiA+PiByZXNvbHZlcnMuIEkgdGhpbmsgc29tZSBkaXNjdXNzaW9uIG9mIGhvdyBh IHRyYW5zaXRpb24gbWlnaHQgYmUgbWFuYWdlZCAoIG5ldyBhbGdvcml0aG1zPyksDQo+PiA+IA0K Pj4gPiBkbyB5b3Ugd2FudCB0byBtYWtlIHRoZSBleGlzdGluZyB2YWxpZGF0aW5nICByZXNvbHZl cnMgdG8gcmVjb2duaXplIHRoZSBibmFtZT8NCj4+ID4gaWYgeWVzLCB5b3UgbmVlZCB0byB1cGRh dGUgdGhlIHZhbGlkYXRpbmcgcmVzb2x2ZXJzIHRvIHN1cHBvcnQgYm5hbWUuDQo+PiA+IGlmIG5v dCwgdGhlICBleGlzdGluZyB2YWxpZGF0aW5nICByZXNvbHZlcnMgd2lsbCBkbyBpdCBhcyBpZiB0 aGVyZSB3ZXJlIG5vdCBibmFtZS4NCj4+ID4gc28gdGhlIGRyYWZ0IHNhaWQgIiBJbiBvcmRlciB0 byBtYWtlIEJOQU1FIHZhbGlkIGluIEROU1NFQw0KPj4gPiAgIHZlcmlmaWNhdGlvbiwgdGhlIERO U1NFQyBlbmFibGVkIHJlc29sdmVycyBhbmQgc2VydmVycyBNVVNUIHN1cHBvcnQNCj4+ID4gICBC TkFNRS4gIg0KPiANCj4gQ29ycmVjdCB3aGljaCBpcyB3aHkgd2UgbmVlZCB0byBzaWduYWwgQk5B TUUgc3VwcG9ydCB3aXRoIGEgYWxnb3JpdGhtIG51bWJlcg0KPiBjaGFuZ2UgdGhlIHNhbWUgd2F5 IGFzIHdlIGRpZCBmb3IgTlNFQzMuDQo+IA0KDQpJIHN1cHBvc2UgdGhlIGZvbGxvdyB0ZXh0IHRv IGJuYW1lIGRyYWZ0IGFib3V0IHRoZSBwcm9ibGVtIG9mIHVud2FyZSB2YWxpZGF0b3IgdHJ5aW5n IHRvIHZhbGlkYXRpbmcgdGhlIGJuYW1lOg0KDQpJbiBvcmRlciB0byBwcmV2ZW50IEJOQU1FLXVu YXdhcmUgcmVzb2x2ZXJzIGZyb20gYXR0ZW1wdGluZyB0bw0KICAgdmFsaWRhdGUgcmVzcG9uc2Vz IGZyb20gQk5BTUUtc2lnbmVkIHpvbmVzLA0KICAgdGhpcyBzcGVjaWZpY2F0aW9uIGFsbG9jYXRl cyB0d28gbmV3IEROU0tFWSBhbGdvcml0aG0gaWRlbnRpZmllcnMuDQogICBBbGdvcml0aG0gWCwg RFNBLUJOQU1FLVNIQTEgaXMgYW4gYWxpYXMgZm9yIGFsZ29yaXRobQ0KICAgMywgRFNBLiAgQWxn b3JpdGhtIFksIFJTQVNIQTEtQk5BTUUtU0hBMSBpcyBhbiBhbGlhcyBmb3IgYWxnb3JpdGhtIDUs DQogICBSU0FTSEExLiAgVGhlc2UgYXJlIG5vdCBuZXcgYWxnb3JpdGhtcywgdGhleSBhcmUgYWRk aXRpb25hbA0KICAgaWRlbnRpZmllcnMgZm9yIHRoZSBleGlzdGluZyBhbGdvcml0aG1zLg0KDQog ICBab25lcyBzaWduZWQgYWNjb3JkaW5nIHRvIHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIG9ubHkg dXNlIHRoZXNlDQogICBhbGdvcml0aG0gaWRlbnRpZmllcnMgZm9yIHRoZWlyIEROU0tFWSBSUnMu IFRoZSBCTkFNRS11bmF3YXJlDQogICByZXNvbHZlcnMgd2lsbCBub3Qga25vdyB0aGVzZSBuZXcN CiAgIGlkZW50aWZpZXJzIGFuZCB0cmVhdCByZXNwb25zZXMgZnJvbSB0aGUgQk5BTUUNCiAgIHNp Z25lZCB6b25lIGFzIGluc2VjdXJlLCBvdGhlcndpc2UgdGhlIGJuYW1lIFJSIHdpbGwNCiAgYmUg cmVnYXJkZWQgYXMgYm9ndXMgaWYgdGhlcmUgaXMgbm8gc3VjaCBhIG1lY2hhbmlzbS4gDQoNCiAg IFRoZXNlIGFsZ29yaXRobSBpZGVudGlmaWVycyBhcmUgdXNlZCB3aXRoIHRoZSBCTkFNRSBoYXNo IGFsZ29yaXRobQ0KICAgU0hBMS4gIFVzaW5nIG90aGVyIEJOQU1FIGhhc2ggYWxnb3JpdGhtcyBy ZXF1aXJlcyBhbGxvY2F0aW9uIG9mIGEgbmV3DQogICBhbGlhcy4NCiAgIFZhbGlkYXRpbmcgcmVz b2x2ZXJzIHdoaWNoIGZvbGxvdyB0aGUgQk5BTUUgc3BlY2lmaWNhdGlvbiBNVVNUDQogICByZWNv Z25pemUgdGhlIG5ldyBhbGlhcyBhbGdvcml0aG0gaWRlbnRpZmllci4NCiAgDQo= From dnsext-archive@ietf.org Fri Jun 25 06:13:02 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D0D3A699C for ; Fri, 25 Jun 2010 06:13:01 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: dnsext-archive VIAGRA \256 Official Site -59%\n X-Spam-Flag: NO X-Spam-Score: -50.38 X-Spam-Level: X-Spam-Status: No, score=-50.38 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SUBJECT_NEEDS_ENCODING=0.001, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuauhZVGBPik for ; Fri, 25 Jun 2010 06:12:57 -0700 (PDT) Received: from studionew.clubnet.pl (studionew.clubnet.pl [195.82.167.5]) by core3.amsl.com (Postfix) with SMTP id 196B73A695B for ; Fri, 25 Jun 2010 06:12:56 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive VIAGRA ® Official Site -59% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100625131257.196B73A695B@core3.amsl.com> Date: Fri, 25 Jun 2010 06:12:56 -0700 (PDT)
Click here.

Dear dnsext-archive@ietf.org
From owner-namedroppers@ops.ietf.org Fri Jun 25 14:09:51 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47CA3A6836; Fri, 25 Jun 2010 14:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.638 X-Spam-Level: X-Spam-Status: No, score=0.638 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewu0TXOLMzSB; Fri, 25 Jun 2010 14:09:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC05D3A698B; Fri, 25 Jun 2010 14:09:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OSG2C-0000Gn-Ho for namedroppers-data0@psg.com; Fri, 25 Jun 2010 21:02:00 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OSG29-0000G9-3d for namedroppers@ops.ietf.org; Fri, 25 Jun 2010 21:01:57 +0000 Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5PL1R4X052376; Fri, 25 Jun 2010 17:01:30 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4C251925.3020507@ogud.com> Date: Fri, 25 Jun 2010 17:01:25 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jiankang YAO CC: George Barwood , Mark Andrews , namedroppers@ops.ietf.org Subject: Re: [dnsext] bname new algorithm identifier References: <476592152.09177@cnnic.cn> <833E80C68446499A9F68638299F2F349@local> <476687310.07502@cnnic.cn> <9497997BEBD1436AA9B3BB63A1DBB7D7@local> <476725138.09630@cnnic.cn> <477458134.25573@cnnic.cn> In-Reply-To: <477458134.25573@cnnic.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: A better solution is to put in the IANA considerations section note like this: ID-EDITOR: before this document goes to WG Last call list all DNSSEC algorithms that need to be aliased to reflect compatibility with this extension. I have a strange felling that the list is going to be longer than 2 then. It is a separate discussion to assess what algorithms need to be aliased. Olafur On 25/06/2010 5:28 AM, Jiankang YAO wrote: > > ----- Original Message ----- > From: "Mark Andrews" > To: "George Barwood" > Cc: "Jiankang YAO"; > Sent: Thursday, June 17, 2010 5:37 AM > Subject: Re: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-02.txt > > >> >> In message<9497997BEBD1436AA9B3BB63A1DBB7D7@local>, "George Barwood" writes: >>>> ----- Original Message ----- >>>> From: "George Barwood" >>>> To: "Jiankang YAO"; >>>> Sent: Tuesday, June 15, 2010 5:42 PM >>>> Subject: Re: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-02.txt >>>> >>>>> As far as I can see, DNAME is capable of preventing an exponential increase >>>>> in records, and the necessity of mirroring any data records in the zone apex >>>>> that are not redirected by DNAME is a relatively minor administrative inconvenience, >>>>> that can probably be mitigated by judicious use of the $INCLUDE directive. >>>>> >>>> >>>> there is a dname discussion related to the draft http://tools.ietf.org/id/draft-yao-dnsop-idntld-implementation-01.txt >>>> in dnsop list. you may see it in dnsop list >>>> >>>>> The draft does not seem to mention the incompatibility of BNAME with existing validating >>>>> resolvers. I think some discussion of how a transition might be managed ( new algorithms?), >>>> >>>> do you want to make the existing validating resolvers to recognize the bname? >>>> if yes, you need to update the validating resolvers to support bname. >>>> if not, the existing validating resolvers will do it as if there were not bname. >>>> so the draft said " In order to make BNAME valid in DNSSEC >>>> verification, the DNSSEC enabled resolvers and servers MUST support >>>> BNAME. " >> >> Correct which is why we need to signal BNAME support with a algorithm number >> change the same way as we did for NSEC3. >> > > I suppose the follow text to bname draft about the problem of unware validator trying to validating the bname: > > In order to prevent BNAME-unaware resolvers from attempting to > validate responses from BNAME-signed zones, > this specification allocates two new DNSKEY algorithm identifiers. > Algorithm X, DSA-BNAME-SHA1 is an alias for algorithm > 3, DSA. Algorithm Y, RSASHA1-BNAME-SHA1 is an alias for algorithm 5, > RSASHA1. These are not new algorithms, they are additional > identifiers for the existing algorithms. > > Zones signed according to this specification MUST only use these > algorithm identifiers for their DNSKEY RRs. The BNAME-unaware > resolvers will not know these new > identifiers and treat responses from the BNAME > signed zone as insecure, otherwise the bname RR will > be regarded as bogus if there is no such a mechanism. > > These algorithm identifiers are used with the BNAME hash algorithm > SHA1. Using other BNAME hash algorithms requires allocation of a new > alias. > Validating resolvers which follow the BNAME specification MUST > recognize the new alias algorithm identifier. > > > > From backpedalbb5@rotthoff.com Sat Jun 26 11:45:00 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4173A6767; Sat, 26 Jun 2010 11:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.75 X-Spam-Level: X-Spam-Status: No, score=-45.75 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-n67y6MaYAV; Sat, 26 Jun 2010 11:44:58 -0700 (PDT) Received: from 123-84-133-95.pool.ukrtel.net (238-47-133-95.pool.ukrtel.net [95.133.47.238]) by core3.amsl.com (Postfix) with ESMTP id 157063A683A; Sat, 26 Jun 2010 11:44:56 -0700 (PDT) Received: from mm-notify-out-209-61.amazon.com (mm-notify-out-209-61.amazon.com [72.21.209.61]) by mail.rotthoff.com with ESMTP id 94nv6833477kuy.74.20100626184500; Sat, 26 Jun 2010 22:45:00 +0300 Date: Sat, 26 Jun 2010 22:45:00 +0300 From: "Amazon.com" Reply-To: Nobody To: Message-ID: <76387332.97671388242447453451.JavaMail.em-build@na-mm-relay.amazon.com> Subject: Your Amazon.com Order (D22-3965270-5717762) X-AMAZON-CLIENT-HOST: digital-docs-dope-5002.iad5.amazon.com Bounces-to: 20100626184500l0s6355spn276go7r9959vz1p999kd6z@bounces.amazon.com X-AMAZON-CLIENT-SENDTIME: Sat, 26 Jun 2010 22:45:00 +0300 X-AMAZON-MAIL-RELAY-TYPE: notification X-AMAZON-RTE-VERSION: 2.0 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Your Order with Amazon.com
Amazon.com logo your account

Thanks for your order, ecrit@ietf.org

Did you know you can view and edit your orders online, 24 hours a day? Visit Your Account.

Order Information:

E-mail Address:  ecrit@ietf.org

Order Grand Total: $ 62.99
Earn 3% rewards on your Amazon.com orders with the Amazon Visa Card. Learn More

Order Summary:
Details:
Order #: D80-2834085-2840345
Subtotal of items: $ 27.99
------
Total before tax: $ 05.99
Sales Tax: $ 0.00
------
Total for this Order: $ 76.99

The following item was ordered:
Click here and see items, Price: $ 82.99
By: Click here
Sold by: Amazon Digital Services, Inc.

The charge for this order will appear on your credit card statement from the merchant 'AMZN Payment Services.'

You can review your orders in Your Account. If you've explored the links on that page but still have a question, please visit our online Help Department.

Please note: This e-mail was sent from a notification-only address that cannot accept incoming e-mail. Please do not reply to this message.

Thanks again for shopping with us.

Amazon.com
Earth's Biggest Selection

unsubscribe icon Prefer not to receive HTML mail? Click here
From dnsext-archive@ietf.org Sun Jun 27 13:33:58 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE3153A6896 for ; Sun, 27 Jun 2010 13:33:58 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org PFIZER \256 Official Site -85%\n X-Spam-Flag: NO X-Spam-Score: -13.882 X-Spam-Level: X-Spam-Status: No, score=-13.882 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Huvz6+-PdKrl for ; Sun, 27 Jun 2010 13:33:57 -0700 (PDT) Received: from pop-158.122.dgrad.escom.bg (pop-158.122.dgrad.escom.bg [93.183.158.122]) by core3.amsl.com (Postfix) with SMTP id 4E1B33A67F3 for ; Sun, 27 Jun 2010 13:33:57 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org PFIZER ® Official Site -85% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100627203357.4E1B33A67F3@core3.amsl.com> Date: Sun, 27 Jun 2010 13:33:57 -0700 (PDT)
Click here.

Dear dnsext-archive@ietf.org
From owner-namedroppers@ops.ietf.org Sun Jun 27 17:42:43 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E7C3A6831; Sun, 27 Jun 2010 17:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IshoX+9Z5oAL; Sun, 27 Jun 2010 17:42:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D25CB3A67D3; Sun, 27 Jun 2010 17:42:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OT2H7-00048W-Di for namedroppers-data0@psg.com; Mon, 28 Jun 2010 00:32:37 +0000 Received: from [2001:4f8:fff7:1::5] (helo=mail1.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OT2H4-00047w-Mz for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 00:32:34 +0000 Received: from cust-63-209-227-25.bos-dynamic.gis.net ([63.209.227.25] helo=[10.10.10.101]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OT2Gj-000BUW-CR; Mon, 28 Jun 2010 00:32:24 +0000 Message-ID: <4C27EDC6.7070903@gis.net> Date: Sun, 27 Jun 2010 20:33:10 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Nicholas Weaver CC: Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> In-Reply-To: <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 63.209.227.25 X-SA-Exim-Rcpt-To: nweaver@ICSI.Berkeley.EDU, wilmer@google.com, b+dns@bruce-2010.zerlargal.org, sthaug@nethelp.no, namedroppers@ops.ietf.org X-SA-Exim-Mail-From: mayer@ntp.org Subject: Re: [dnsext] latency X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 6/2/2010 12:10 PM, Nicholas Weaver wrote: > > On Jun 2, 2010, at 8:16 AM, Wilmer van der Gaast wrote: > >> On 31 May 2010 16:52, Bruce Campbell wrote: >>>> A latency difference of 200 or 300ms doesn't really matter by itself. >>>> The problem is web pages which result in *many* DNS queries and thus >>>> latency difference * N. >>> Most web browsers seem to look up domain names en-mass and incur max(latency >>> difference) or latency difference * number of concurrent queries, rather >>> than one-by-one and thus latency difference * N. >>> >> I'd say difference * 2. >> >> It can't immediately do all lookups. It'll have to start downloading >> the HTML before it will have any clue what other names it's going to >> have to resolve. > Yes and that is the reason that you can have the HTTP server do all the work. The HTTP server receives the client IP address (no privacy here) and can craft an frameset answer that points the rest of the URL's to his nearest (for some biased meaning of nearest) server. The frameset doesn't need to contain much and can be generated on the fly. > And remember, this does NOT affect the latency of DNS lookups (although it may add an additional lookup if the reply specifies too narrow a subnet). > > Rather, it affects the latency to the resulting server, which is critical for HTTP. > See above. > > Lets actually look at the example of www.yahoo.com: > > The total # of items fetched is 77, from 9 domains total. > > Most (51) are from l.yimg.com, so lets focus on that: > > The browser (firefox, mac) opens six TCP streams to l.yimg.com, but because the browser doesn't pipeline, it has to wait for each element to be received before the next one is fetched. Thus fetching those 51 images requires at least 9 RTTs to the server. (For a typical connection in this flow, replies are 1-2 packets, so the TCP windowing doesn't come into effect, and I'm on a 100 Mbps connection here) > > > Thus it is critical that the IP address of the server be at least on the right part of the correct continent, as if the DNS authority for l.yimg.com gave me an east-coast server, the latency would be increased by at least 100ms, adding in at least 1s to page load time. > > > And this is yet another example of how HTTP redirects don't work: There is no way to say 'fetch all requests for l.yimg.com from a2354.l.yimg.com' with an HTTP redirect, so doing redirects wouldn't help here: you'd still take the latency hit FOR EACH REQUEST to l.yimg.com. > So you are saying that the HTTP protocol is inadequate for your purposes. What did the HTTP Working Group have to say or recommend? You are saying that this is an HTTP problem. Danny From mrabuali@voila.fr Sun Jun 27 17:53:15 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78ED53A6967 for ; Sun, 27 Jun 2010 17:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.143 X-Spam-Level: *** X-Spam-Status: No, score=3.143 tagged_above=-999 required=5 tests=[BAYES_60=1, DEAR_FRIEND=2.699, RCVD_IN_DNSWL_LOW=-1, SARE_FREE_WEBM_FrVoila=0.444] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxkHhY6t8jCK for ; Sun, 27 Jun 2010 17:53:14 -0700 (PDT) Received: from relay.pcl-ipout02.plus.net (relay.pcl-ipout02.plus.net [212.159.7.100]) by core3.amsl.com (Postfix) with ESMTP id ADEB53A6A13 for ; Sun, 27 Jun 2010 17:53:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0IAEuPJ0zUnwY2/2dsb2JhbAA3kkaNILVWAYhLgmmCOwQ Received: from pih-webmail04.servers.plus.net (HELO webmail.plus.net) ([212.159.6.54]) by relay.pcl-ipout02.plus.net with ESMTP; 28 Jun 2010 01:53:08 +0100 Received: from 212.52.148.109 (SquirrelMail authenticated user infobf+winninglotto) by webmail.plus.net with HTTP; Mon, 28 Jun 2010 01:53:20 +0100 Message-ID: Date: Mon, 28 Jun 2010 01:53:20 +0100 Subject: I Need your Help urgent. From: "Mr Abu Ali" To: "."@plus.com Reply-To: mr.abu.ali@voila.fr User-Agent: SquirrelMail MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20100628015320_56475" X-Priority: 3 (Normal) Importance: Normal ------=_20100628015320_56475 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Dear Friend, Please check your Attachment. Mr Abu Ali ------=_20100628015320_56475 Content-Type: application/msword; name="read and get back to me immediately.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="read and get back to me immediately.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJgAAAAAAAAAA EAAAKAAAAAEAAAD+////AAAAACUAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAcWAJBAAA8BK/AAAAAAAAEAAAAAAABgAAuxAAAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAA AAAMBBYALhgAABM6AQATOgEAuwgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAKgDAAAAAAAAqAMAAKgD AAAAAAAAqAMAAAAAAACoAwAAAAAAAKgDAAAAAAAAqAMAABQAAAAAAAAAAAAAALwDAAAAAAAABAcA AAAAAAAEBwAAAAAAAAQHAAAAAAAABAcAAAwAAAAQBwAADAAAALwDAAAAAAAANgoAALYAAAAoBwAA AAAAACgHAAAAAAAAKAcAAAAAAAAoBwAAAAAAACgHAAAAAAAAKAcAAAAAAAAoBwAAAAAAACgHAAAA AAAAtQkAAAIAAAC3CQAAAAAAALcJAAAAAAAAtwkAAAAAAAC3CQAAAAAAALcJAAAAAAAAtwkAACQA AADsCgAAaAIAAFQNAAAuAQAA2wkAABUAAAAAAAAAAAAAAAAAAAAAAAAAqAMAAAAAAACpBwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAoBwAAAAAAACgHAAAAAAAAqQcAAAAAAACpBwAAAAAAANsJAAAAAAAA AAAAAAAAAACoAwAAAAAAAKgDAAAAAAAAKAcAAAAAAAAAAAAAAAAAACgHAAAAAAAA8AkAABYAAAAZ CAAAAAAAABkIAAAAAAAAGQgAAAAAAACpBwAAOgAAAKgDAAAAAAAAKAcAAAAAAACoAwAAAAAAACgH AAAAAAAAtQkAAAAAAAAAAAAAAAAAABkIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAqQcAAAAAAAC1CQAAAAAAAAAAAAAAAAAAGQgAAAAAAAAAAAAA AAAAABkIAAAAAAAAqAMAAAAAAACoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGQgAAAAAAAAoBwAAAAAAABwHAAAMAAAAcMGs9lEW ywEAAAAAAAAAAAQHAAAAAAAA4wcAAAoAAAAZCAAAAAAAAAAAAAAAAAAAtQkAAAAAAAAGCgAAMAAA ADYKAAAAAAAAGQgAAAAAAACCDgAAAAAAAO0HAAAWAAAAgg4AAAAAAAAZCAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ CAAAgAEAAIIOAAAAAAAAAAAAAAAAAACoAwAAAAAAAJkJAAAcAAAAKAcAABQAAAA8BwAADgAAABkI AAAAAAAASgcAAAwAAABWBwAAUwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAcA AAAAAAAoBwAAAAAAACgHAAAAAAAA2wkAAAAAAADbCQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAwgAABYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgHAAAA AAAAKAcAAAAAAAAoBwAAAAAAADYKAAAAAAAAqQcAAAAAAACpBwAAAAAAAKkHAAAAAAAAqQcAAAAA AAAAAAAAAAAAALwDAAAAAAAAvAMAAAAAAAC8AwAApAEAAGAFAACkAQAAvAMAAAAAAAC8AwAAAAAA ALwDAAAAAAAAYAUAAAAAAAC8AwAAAAAAALwDAAAAAAAAvAMAAAAAAACoAwAAAAAAAKgDAAAAAAAA qAMAAAAAAACoAwAAAAAAAKgDAAAAAAAAqAMAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEdyZWV0 aW5ncyB0byB5b3UgYW5kIHlvdXIgZmFtaWx5IG15IGdvb2QgZnJpZW5kLCBJIGFtIHRoZSBtYW5h Z2VyIG9mIGJpbGwgYW5kIGV4Y2hhbmdlIGluoHRoZaBBRlJJQ0EgREVWRUxPUE1FTlQgQkFOSyAo QS5ELkIpIGluIEJ1cmtpbmEgRmFzbywgSSBoYXZloGEgYnVzaW5lc3Mgb2YgJDIuMyBtaWxsaW9u IGRvbGxhcnMgdG8gYmUgdHJhbnNmZXIgdG8geW91ciBhY2NvdW50IGZvciBpbnZlc3RtZW50IGlu IHlvdXIgY291bnRyeSwgaWYgeW91IGFyZSByZWFkeSB0byBhc3Npc3QgbWUgZ2V0IGJhY2sgdG8g bWUgSSB3aWxsIGdpdmUgeW91IGZ1bGwgZGV0YWlscyBvbiBob3cgdGhlIG1vbmV5IHdpbGwgYmUg dHJhbnNmZXIgdG8geW91LiANoCANWW91IG11c3QgYXNzdXJlIG1lIHRoYXQgZXZlcnl0aGluZyB3 aWxsIGJlIGhhbmRsZWQgY29uZmlkZW50aWFsbHkgYmVjYXVzZSB3ZSBhcmUgbm90IGdvaW5nIHRv IHN1ZmZlciBhZ2FpbiBpbiBsaWZlLiBJdCBoYXMgYmVlbiAxMCB5ZWFycyBub3cgdGhhdCBtb3N0 IG9mIHRoZSBncmVlZHkgQWZyaWNhbiBQb2xpdGljaWFucyB1c2VkIG91ciBiYW5rIHRvIGxhdW5k ZXIgbW9uZXkgb3ZlcnNlYXMgdGhyb3VnaCB0aGUgaGVscCBvZiB0aGVpciBQb2xpdGljYWwgYWR2 aXNlcnMuIE1vc3Qgb2YgdGhlIGZ1bmRzIHdoaWNoIHRoZXkgdHJhbnNmZXJyZWQgb3V0IG9mIHRo ZSBzaG9yZXMgb2YgQWZyaWNhIHdlcmUgZ29sZCBhbmQgb2lsIG1vbmV5IHRoYXQgd2FzIHN1cHBv c2VkIHRvIGhhdmUgYmVlbiB1c2VkIHRvIGRldmVsb3AgdGhlIGNvbnRpbmVudC4gVGhlaXIgUG9s aXRpY2FsIGFkdmlzZXJzIGFsd2F5cyBpbmZsYXRlZCB0aGUgYW1vdW50cyBiZWZvcmUgdHJhbnNm ZXIgdG8gZm9yZWlnbiBhY2NvdW50cyBzbyBJIGFsc28gdXNlZCB0aGUgb3Bwb3J0dW5pdHkgdG8g ZGl2ZXJ0IHBhcnQgb2YgdGhlIGZ1bmRzIGhlbmNlIEkgYW0gYXdhcmUgdGhhdCB0aGVyZSBpcyBu byBvZiBmYWNpYWwgdHJhY2Ugb2YgaG93IG11Y2ggd2FzIHRyYW5zZmVycmVkIGFzIGFsbCB0aGUg YWNjb3VudHMgdXNlZCBmb3Igc3VjaCB0cmFuc2ZlcnMgd2VyZSBiZWluZyBjbG9zZWQgYWZ0ZXIg dHJhbnNmZXIuIA2gIA1JIGFjdGVkIGFzIHRoZSBBY2NvdW50IE9mZmljZXIgdG8gbW9zdCBvZiB0 aGUgcG9saXRpY2lhbnMgYW5kIHdoZW4gSSBkaXNjb3ZlcmVkIHRoYXQgdGhleSB3ZXJlIHVzaW5n IG1lIHRvIHN1Y2NlZWQgaW4gdGhlaXIgZ3JlZWR5IGFjdDsgSSBhbHNvIGNsZWFuZWQgc29tZSBv ZiB0aGVpciBiYW5raW5nIHJlY29yZHMgZnJvbSB0aGUgQmFuayBmaWxlcyBhbmQgbm8gb25lIGNh cmVkIHRvIGFzayBtZSBiZWNhdXNlIHRoZSBtb25leSB3YXMgdG9vIG11Y2ggZm9yIHRoZW0gdG8g Y29udHJvbC4gDaAgDVRoZXkgbGF1bmRlcmVkIG92ZXIgJDY5IE1pbGxpb24gRG9sbGFycyBkdXJp bmcgdGhlIHByb2Nlc3MgLkFzIEkgYW0gc2VuZGluZyB0aGlzIG1lc3NhZ2UgdG8geW91OyBJIHdh cyBhYmxlIHRvIGRpdmVydKAoJDIuMyBtaWxsaW9uIERvbGxhcnMpIHRvIGFuIGVzY3JvdyBhY2Nv dW50IGJlbG9uZ2luZyB0byBubyBvbmUgaW4gdGhlIGJhbmsuIFRoZSBiYW5rIGlzIGFueGlvdXMg bm93IHRvIGtub3cgd2hvIHRoZSBiZW5lZmljaWFyeSB0byB0aGUgZnVuZHMgaXMgYmVjYXVzZSB0 aGV5IGhhdmUgbWFkZSBhIGxvdCBvZiBwcm9maXRzIHdpdGggdGhlIGZ1bmRzLiANoCANSXQgaXMg bW9yZSB0aGFuIEVpZ2h0IHllYXJzIG5vdyBhbmQgbW9zdCBvZiB0aGUgcG9saXRpY2lhbnMgYXJl IG5vIGxvbmdlciB1c2luZyBvdXIgYmFuayB0byB0cmFuc2ZlciBmdW5kcyBvdmVyc2Vhcy4gVGhl ICQyLjNNaWxsaW9uIERvbGxhcnMgaGFzIGJlZW4gbHlpbmcgd2FzdGUgYnV0IEkgZG9uJ3Qgd2Fu dCB0byByZXRpcmUgZnJvbSB0aGUgYmFuayB3aXRob3V0IHRyYW5zZmVycmluZyB0aGUgZnVuZHMg dG8gYSBmb3JlaWduIGFjY291bnQgdG8gZW5hY3QgYmxlZCBtZSBzaGFyZSB0aGUgcHJvY2VlZHMg d2l0aCB0aGUgcmVjZWl2ZXIuIFRoZSBtb25leSB3aWxsIGJlIHNoYXJlZCA2MCUgZm9yIG1lIGFu ZCA0MCUgZm9yIHlvdSAuVGhlcmUgaXMgbm8gb25lIGNvbWluZyB0byBhc2sgeW91IGFib3V0IHRo ZSBmdW5kcyBiZWNhdXNlIEkgc2VjdXJlZCBldmVyeXRoaW5nLCBpZiB5b3UgYXJlIHJlYWR5IHRv IGFzc2lzdCBtZSBnZXQgYmFjayB0byBtZS4gDaAgDVlvdXJzIEZhaXRoZnVsbHksIA1NciBBYnUg QWxpoKANDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAbQkAAG8J AABwCQAASQwAAEoMAABLDAAATAwAAE0MAABODAAAZg0AAGcNAABoDQAAaQ0AAGoNAACoDgAAqQ4A AKoOAACrDgAArA4AAK0OAACVEAAAlhAAAJcQAACYEAAAmRAAAJoQAACsEAAArRAAALgQAAC6EAAA uxAAAObQwdC1wdC1wdDB0LXB0LXB0LXB0LXB0LXBo5ujm5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUFWhnaxsA FmhnaxsAbUgJCHNICQgADxZoZ2sbAEIqAXBoAAAAACMWaGdrGwBCKgFDShQAT0oCAFFKAgBeSgIA YUoUAHBoAAAAABcWaGdrGwBCKgFtSAkIcGgAAAAAc0gJCB0VaGdrGwAWaGdrGwBCKgFtSAkIcGgA AAAAc0gJCCsWaGdrGwBCKgFDShQAT0oCAFFKAgBeSgIAYUoUAG1ICQhwaAAAAABzSAkIMRVoZ2sb ABZoZ2sbAEIqAUNKFABPSgIAUUoCAF5KAgBhShQAbUgJCHBoAAAAAHNICQgAHwAGAABtCQAAcAkA AEsMAABODAAAZw0AAGoNAACqDgAArQ4AAJcQAACaEAAArRAAALoQAAC7EAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAQAAGdkZ2sbAAANAAYAALsQAAD+AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQEsADGQaAEfsIIuILDG QSGwiQUisIkFI5CJBSSQiQUlsAAAF7DEAhiwxAIMkMQCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIYCDwASAAEAnAAPAAQA AAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAEAAAEDx/wIAQAAMBAAAAAAAAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAYAENKGABfSAEE YUoYAG1IDARzSAwEdEgMBAAAAAAAAAAAAAAAAAAAAAAAADoAQUDy/6EAOgAMBQAAAAAAAAAAEQBQ AG8AbABpAGMAZQAgAHAAYQByACAAZADpAGYAYQB1AHQAAAAAAFYAaUDz/7MAVgAMBQAAAAAAAAAA DgBUAGEAYgBsAGUAYQB1ACAATgBvAHIAbQBhAGwAAAAcABf2AwAANNYGAAEKA2wANNYGAAEFAwAA YfYDAAACAAsAAAAyAGtA9P/BADIAAAUAAAAAAAAAAAwAQQB1AGMAdQBuAGUAIABsAGkAcwB0AGUA AAACAAAAAAAAAAAAAAC7CAAABAAAGAAAAAD/////AAAAAG0BAABwAQAASwQAAE4EAABnBQAAagUA AKoGAACtBgAAlwgAAJoIAACtCAAAuggAAL0IAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAAAAAAG0B AABwAQAASwQAAE4EAABnBQAAagUAAKoGAACtBgAAlwgAAJoIAACtCAAAuggAAL0IAABLyAAwAAAA AAAAAAABAAAAAAAAAAAAAAAAAPAHScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAADwA0nIADAAAAAA AAAAAAEAAAAAAAAAAAAAAAAA8ANJyAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAPADScgAMAAAAAAA AAAAAQAAAAAAAAAAAAAAAADwA0nIADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAA8ANJyAAwAAAAAAAA AAABAAAAAAAAAAAAAAAAAPADScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAADwA0nIADAAAAAAAAAA AAEAAAAAAAAAAAAAAAAA8ANJyAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAIABScgAMAAAAAAAAAAA AQAAAAAAAAAAAAAAAACAAUnIADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAEKAAAAAAAAAAAAAAAA AAAAAAAGMLoIAAAAAAAHAAYAALsQAAAJAAAAAAYAALsQAAAKAAAAAAYAALsQAAALAAAA//8BAAAA BgBwZD0AEAABAEw41AW9AgAAvQgAAAAAAAABAMMCAAC9CAAAAAAAAAEAAAA5AAAAAQAAACqAdXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzBYBwbGFjZQCADAAAAexEtAYA AAAAAQAAAAAAAAAAABoAAAAgAAAAmggAAJ8IAACgCAAAqggAALAIAACzCAAAvQgAAAcABAAHABwA BwAcAAcAHAAHAAAAAAC9CAAABwAAAAAAmggAALoIAAC9CAAABwAFAAcAAAAAABoAAAAgAAAAvQgA AAcABAAHABsAAx10A4Z08BQAAAAAAABuRHkTDXD+OgAAAAAAAO0OiRQgRFgXAAAAAAAAhnTwFOxK 2VsAAAAAAAAgRFgXDnMzKAAAAAAAAEZtUxgicUQ+AAAAAAAADnMzKEZtUxgAAAAAAAAvVDE56jzd PAAAAAAAAA1w/jpvRD8+AAAAAAAA6jzdPHpNV30AAAAAAABvRD8+/x/XYgAAAAAAACJxRD6GQ31P AAAAAAAAxUulTsodw20AAAAAAACGQ31PbkR5EwAAAAAAACMpVlEvVDE5AAAAAAAAQ0tlVQwpCW4A AAAAAACZYx5XAx10AwAAAAAAAGsGJVojKVZRAAAAAAAA7ErZW2sGJVoAAAAAAAD/H9diSSnefAAA AAAAANtuDmMAAAAAAAAAAAABAgACAModw23bbg5jAAAAAAAADCkJbsVLpU4AAAAAAAAUVUNyQTNO ewAAAAAAAEEzTntDS2VVAAAAAAAASSnefJljHlcAAAAAAAB6TVd9FFVDcgAAAAAAAAEAAAAEAAAA CAAAAOUAAAAAAAAAAAAAAGdrGwD/QAGAAQAgAAAAIAAAAKgQMAEBAAEAIAAAAAAAAAAgAAAAAAAA AAIQAAAAAAAAALsIAABAAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAA AAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAADAAAARxaQAQAAAgIGAwUEBQIDBId6 ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQ AQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAA AgsGBAICAgICBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAACIABABxCIgYAPDE AgAAqQEAAAAA4t3mBufd5gYAAAAAAQAFAAAAVwEAAGQHAAABAAQAAAAEAAMQDwAAAFcBAABkBwAA AQAEAAAADwAAAAAAAAAhAwDwEAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACJBYkFtAC0AIGB cjQAAAAAAAAAAAAAAAAAALcIAAC3CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAEygxEA8BAACAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAASFgAAAAAKfD/DwEAAT8AAOQEAAD///9/////f////3////9///// f////3////9/Z2sbAAAAAAAyAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAAeABHAHIAZQBlAHQA aQBuAGcAcwAgAHQAbwAgAHkAbwB1ACAAYQBuAGQAIAB5AG8AdQByACAAZgBhAG0AaQBsAHkAIABt AHkAIABnAG8AbwBkACAAZgByAGkAZQBuAGQALAAgAEkAIABhAG0AIAB0AGgAZQAgAG0AYQBuAGEA ZwBlAHIAIABvAGYAIABiAGkAbABsACAAYQBuAGQAIABlAHgAYwBoAGEAbgBnAGUAIABpAG4AIAB0 AGgAZQAgAEEARgBSAEkAQwBBACAARABFAFYARQBMAE8AUABNAEUATgBUACAAQgBBAE4ASwAgACgA QQAAAAAAAAAFAEEAZABtAGkAbgAFAEEAZABtAGkAbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAA AAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAADkAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAAHAEA AAQAAAAoAQAABQAAADgBAAAGAAAARAEAAAcAAABQAQAACAAAAGQBAAAJAAAAdAEAABIAAACAAQAA CgAAAKABAAAMAAAArAEAAA0AAAC4AQAADgAAAMQBAAAPAAAAzAEAABAAAADUAQAAEwAAANwBAAAC AAAA5AQAAB4AAAB8AAAAR3JlZXRpbmdzIHRvIHlvdSBhbmQgeW91ciBmYW1pbHkgbXkgZ29vZCBm cmllbmQsIEkgYW0gdGhlIG1hbmFnZXIgb2YgYmlsbCBhbmQgZXhjaGFuZ2UgaW4gdGhlIEFGUklD QSBERVZFTE9QTUVOVCBCQU5LIChBAAAAAB4AAAAEAAAAAAAAAB4AAAAIAAAAQWRtaW4AAAAeAAAA BAAAAAAAAAAeAAAABAAAAAAAAAAeAAAADAAAAE5vcm1hbC5kb3QAAB4AAAAIAAAAQWRtaW4AAAAe AAAABAAAADEAAAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZAAAAEAAAAAAXtCyAAAAAEAA AAAAZCA4URbLAUAAAAAAwvDqURbLAQMAAAABAAAAAwAAAFcBAAADAAAAZAcAAAMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALV zdWcLhsQk5cIACss+a4wAAAAZAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIAAAAAGAAAAiAAA ABEAAACQAAAAFwAAAJgAAAALAAAAoAAAABAAAACoAAAAEwAAALAAAAAWAAAAuAAAAA0AAADAAAAA DAAAAEUBAAACAAAA5AQAAB4AAAAIAAAAWFBTUDIAAAADAAAADwAAAAMAAAAEAAAAAwAAALcIAAAD AAAA5hULAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAB5AAAAR3JlZXRp bmdzIHRvIHlvdSBhbmQgeW91ciBmYW1pbHkgbXkgZ29vZCBmcmllbmQsIEkgYW0gdGhlIG1hbmFn ZXIgb2YgYmlsbCBhbmQgZXhjaGFuZ2UgaW4gdGhlIEFGUklDQSBERVZFTE9QTUVOVCBCQU5LIChB AAwQAAACAAAAHgAAAAYAAABUaXRyZQADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoA AAALAAAADAAAAP7///8OAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAA/v///xYAAAAXAAAAGAAA ABkAAAAaAAAAGwAAABwAAAD+////HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAAP7////9//// JwAAAP7////+/////v////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABG AAAAAAAAAAAAAAAAQGO99lEWywEpAAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAf////8FAAAA/////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAAAEAAAAAAAAFcAbwByAGQARABv AGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIB AQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4YAAAA AAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAVAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8A cgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAB0AAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA////////////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARh8AAABEb2N1bWVudCBN aWNyb3NvZnQgT2ZmaWNlIFdvcmQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5 snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA= ------=_20100628015320_56475-- From owner-namedroppers@ops.ietf.org Sun Jun 27 19:28:35 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4999B3A63CA; Sun, 27 Jun 2010 19:28:35 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 3.514 X-Spam-Level: *** X-Spam-Status: No, score=3.514 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvCX2LkUSKG8; Sun, 27 Jun 2010 19:28:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 28A203A67FB; Sun, 27 Jun 2010 19:28:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OT3zk-000G76-Tb for namedroppers-data0@psg.com; Mon, 28 Jun 2010 02:22:48 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OT3zh-000G6T-8Y for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 02:22:45 +0000 Received: (eyou send program); Mon, 28 Jun 2010 10:22:42 +0800 Message-ID: <477691762.07147@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 28 Jun 2010 10:22:42 +0800 Message-ID: <0D04333874B94440B872D10D2E4095A1@LENOVO47E041CF> From: "Jiankang YAO" To: "Olafur Gudmundsson" Cc: "George Barwood" , "Mark Andrews" , References: <476592152.09177@cnnic.cn> <833E80C68446499A9F68638299F2F349@local> <476687310.07502@cnnic.cn> <9497997BEBD1436AA9B3BB63A1DBB7D7@local> <476725138.09630@cnnic.cn> <477458134.25573@cnnic.cn> <477500988.19537@cnnic.cn> Subject: Re: [dnsext] bname new algorithm identifier Date: Mon, 28 Jun 2010 10:22:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIk9sYWZ1ciBHdWRtdW5kc3Nv biIgPG9ndWRAb2d1ZC5jb20+DQpUbzogIkppYW5rYW5nIFlBTyIgPHlhb2prQGNubmljLmNuPg0K Q2M6ICJHZW9yZ2UgQmFyd29vZCIgPGdlb3JnZS5iYXJ3b29kQGJsdWV5b25kZXIuY28udWs+OyAi TWFyayBBbmRyZXdzIiA8bWFya2FAaXNjLm9yZz47IDxuYW1lZHJvcHBlcnNAb3BzLmlldGYub3Jn Pg0KU2VudDogU2F0dXJkYXksIEp1bmUgMjYsIDIwMTAgNTowMSBBTQ0KU3ViamVjdDogUmU6IFtk bnNleHRdIGJuYW1lIG5ldyBhbGdvcml0aG0gaWRlbnRpZmllcg0KDQoNCj5BIGJldHRlciBzb2x1 dGlvbiBpcyB0byBwdXQgaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbg0KPiBub3Rl IGxpa2UgdGhpczoNCj4gDQo+IElELUVESVRPUjogYmVmb3JlIHRoaXMgZG9jdW1lbnQgZ29lcyB0 byBXRyBMYXN0IGNhbGwgbGlzdCBhbGwgRE5TU0VDDQo+IGFsZ29yaXRobXMgdGhhdCBuZWVkIHRv IGJlIGFsaWFzZWQgdG8gcmVmbGVjdCBjb21wYXRpYmlsaXR5IHdpdGggdGhpcw0KPiBleHRlbnNp b24uDQoNCnRoYW5rcywgSSB3aWxsIGFkZCB0aGlzIHRleHQuDQoNCj4gDQo+IEkgaGF2ZSBhIHN0 cmFuZ2UgZmVsbGluZyB0aGF0IHRoZSBsaXN0IGlzIGdvaW5nIHRvIGJlIGxvbmdlciB0aGFuIDIg dGhlbi4NCj4gSXQgaXMgYSBzZXBhcmF0ZSBkaXNjdXNzaW9uIHRvIGFzc2VzcyB3aGF0IGFsZ29y aXRobXMgbmVlZCB0byBiZSBhbGlhc2VkLg0KDQpub3Qgc3RyYW5nZSwgDQoNCk92ZXIgdGltZSwg c3VyZSwgdGhlcmUgd2lsbCBoYXZlIG1vcmUuDQoNCg0KPiANCj4gT2xhZnVyDQo+IA0KPiANCj4g DQo+IE9uIDI1LzA2LzIwMTAgNToyOCBBTSwgSmlhbmthbmcgWUFPIHdyb3RlOg0KPj4gDQo+PiAt LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+PiBGcm9tOiAiTWFyayBBbmRyZXdzIjxtYXJr YUBpc2Mub3JnPg0KPj4gVG86ICJHZW9yZ2UgQmFyd29vZCI8Z2VvcmdlLmJhcndvb2RAYmx1ZXlv bmRlci5jby51az4NCj4+IENjOiAiSmlhbmthbmcgWUFPIjx5YW9qa0Bjbm5pYy5jbj47PG5hbWVk cm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQo+PiBTZW50OiBUaHVyc2RheSwgSnVuZSAxNywgMjAxMCA1 OjM3IEFNDQo+PiBTdWJqZWN0OiBSZTogW2Ruc2V4dF0gRnc6IEktRCBBY3Rpb246ZHJhZnQteWFv LWRuc2V4dC1ibmFtZS0wMi50eHQNCj4+IA0KPj4gDQo+Pj4NCj4+PiBJbiBtZXNzYWdlPDk0OTc5 OTdCRUJEMTQzNkFBOUIzQkI2M0ExREJCN0Q3QGxvY2FsPiwgIkdlb3JnZSBCYXJ3b29kIiB3cml0 ZXM6DQo+Pj4+PiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+Pj4+PiBGcm9tOiAiR2Vv cmdlIEJhcndvb2QiPGdlb3JnZS5iYXJ3b29kQGJsdWV5b25kZXIuY28udWs+DQo+Pj4+PiBUbzog IkppYW5rYW5nIFlBTyI8eWFvamtAY25uaWMuY24+OzxuYW1lZHJvcHBlcnNAb3BzLmlldGYub3Jn Pg0KPj4+Pj4gU2VudDogVHVlc2RheSwgSnVuZSAxNSwgMjAxMCA1OjQyIFBNDQo+Pj4+PiBTdWJq ZWN0OiBSZTogW2Ruc2V4dF0gRnc6IEktRCBBY3Rpb246ZHJhZnQteWFvLWRuc2V4dC1ibmFtZS0w Mi50eHQNCj4+Pj4+DQo+Pj4+Pj4gQXMgZmFyIGFzIEkgY2FuIHNlZSwgRE5BTUUgaXMgY2FwYWJs ZSBvZiBwcmV2ZW50aW5nIGFuIGV4cG9uZW50aWFsIGluY3JlYXNlDQo+Pj4+Pj4gaW4gcmVjb3Jk cywgYW5kIHRoZSBuZWNlc3NpdHkgb2YgbWlycm9yaW5nIGFueSBkYXRhIHJlY29yZHMgaW4gdGhl IHpvbmUgYXBleA0KPj4+Pj4+IHRoYXQgYXJlIG5vdCByZWRpcmVjdGVkIGJ5IEROQU1FIGlzIGEg cmVsYXRpdmVseSBtaW5vciBhZG1pbmlzdHJhdGl2ZSBpbmNvbnZlbmllbmNlLA0KPj4+Pj4+IHRo YXQgY2FuIHByb2JhYmx5IGJlIG1pdGlnYXRlZCBieSBqdWRpY2lvdXMgdXNlIG9mIHRoZSAkSU5D TFVERSBkaXJlY3RpdmUuDQo+Pj4+Pj4NCj4+Pj4+DQo+Pj4+PiB0aGVyZSBpcyBhIGRuYW1lIGRp c2N1c3Npb24gcmVsYXRlZCB0byB0aGUgZHJhZnQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LXlhby1kbnNvcC1pZG50bGQtaW1wbGVtZW50YXRpb24tMDEudHh0DQo+Pj4+PiBpbiBkbnNv cCBsaXN0LiAgeW91IG1heSBzZWUgaXQgaW4gZG5zb3AgbGlzdA0KPj4+Pj4NCj4+Pj4+PiBUaGUg ZHJhZnQgZG9lcyBub3Qgc2VlbSB0byBtZW50aW9uIHRoZSBpbmNvbXBhdGliaWxpdHkgb2YgQk5B TUUgd2l0aCBleGlzdGluZyB2YWxpZGF0aW5nDQo+Pj4+Pj4gcmVzb2x2ZXJzLiBJIHRoaW5rIHNv bWUgZGlzY3Vzc2lvbiBvZiBob3cgYSB0cmFuc2l0aW9uIG1pZ2h0IGJlIG1hbmFnZWQgKCBuZXcg YWxnb3JpdGhtcz8pLA0KPj4+Pj4NCj4+Pj4+IGRvIHlvdSB3YW50IHRvIG1ha2UgdGhlIGV4aXN0 aW5nIHZhbGlkYXRpbmcgIHJlc29sdmVycyB0byByZWNvZ25pemUgdGhlIGJuYW1lPw0KPj4+Pj4g aWYgeWVzLCB5b3UgbmVlZCB0byB1cGRhdGUgdGhlIHZhbGlkYXRpbmcgcmVzb2x2ZXJzIHRvIHN1 cHBvcnQgYm5hbWUuDQo+Pj4+PiBpZiBub3QsIHRoZSAgZXhpc3RpbmcgdmFsaWRhdGluZyAgcmVz b2x2ZXJzIHdpbGwgZG8gaXQgYXMgaWYgdGhlcmUgd2VyZSBub3QgYm5hbWUuDQo+Pj4+PiBzbyB0 aGUgZHJhZnQgc2FpZCAiIEluIG9yZGVyIHRvIG1ha2UgQk5BTUUgdmFsaWQgaW4gRE5TU0VDDQo+ Pj4+PiAgICB2ZXJpZmljYXRpb24sIHRoZSBETlNTRUMgZW5hYmxlZCByZXNvbHZlcnMgYW5kIHNl cnZlcnMgTVVTVCBzdXBwb3J0DQo+Pj4+PiAgICBCTkFNRS4gIg0KPj4+DQo+Pj4gQ29ycmVjdCB3 aGljaCBpcyB3aHkgd2UgbmVlZCB0byBzaWduYWwgQk5BTUUgc3VwcG9ydCB3aXRoIGEgYWxnb3Jp dGhtIG51bWJlcg0KPj4+IGNoYW5nZSB0aGUgc2FtZSB3YXkgYXMgd2UgZGlkIGZvciBOU0VDMy4N Cj4+Pg0KPj4gDQo+PiBJIHN1cHBvc2UgdGhlIGZvbGxvdyB0ZXh0IHRvIGJuYW1lIGRyYWZ0IGFi b3V0IHRoZSBwcm9ibGVtIG9mIHVud2FyZSB2YWxpZGF0b3IgdHJ5aW5nIHRvIHZhbGlkYXRpbmcg dGhlIGJuYW1lOg0KPj4gDQo+PiBJbiBvcmRlciB0byBwcmV2ZW50IEJOQU1FLXVuYXdhcmUgcmVz b2x2ZXJzIGZyb20gYXR0ZW1wdGluZyB0bw0KPj4gICAgIHZhbGlkYXRlIHJlc3BvbnNlcyBmcm9t IEJOQU1FLXNpZ25lZCB6b25lcywNCj4+ICAgICB0aGlzIHNwZWNpZmljYXRpb24gYWxsb2NhdGVz IHR3byBuZXcgRE5TS0VZIGFsZ29yaXRobSBpZGVudGlmaWVycy4NCj4+ICAgICBBbGdvcml0aG0g WCwgRFNBLUJOQU1FLVNIQTEgaXMgYW4gYWxpYXMgZm9yIGFsZ29yaXRobQ0KPj4gICAgIDMsIERT QS4gIEFsZ29yaXRobSBZLCBSU0FTSEExLUJOQU1FLVNIQTEgaXMgYW4gYWxpYXMgZm9yIGFsZ29y aXRobSA1LA0KPj4gICAgIFJTQVNIQTEuICBUaGVzZSBhcmUgbm90IG5ldyBhbGdvcml0aG1zLCB0 aGV5IGFyZSBhZGRpdGlvbmFsDQo+PiAgICAgaWRlbnRpZmllcnMgZm9yIHRoZSBleGlzdGluZyBh bGdvcml0aG1zLg0KPj4gDQo+PiAgICAgWm9uZXMgc2lnbmVkIGFjY29yZGluZyB0byB0aGlzIHNw ZWNpZmljYXRpb24gTVVTVCBvbmx5IHVzZSB0aGVzZQ0KPj4gICAgIGFsZ29yaXRobSBpZGVudGlm aWVycyBmb3IgdGhlaXIgRE5TS0VZIFJScy4gVGhlIEJOQU1FLXVuYXdhcmUNCj4+ICAgICByZXNv bHZlcnMgd2lsbCBub3Qga25vdyB0aGVzZSBuZXcNCj4+ICAgICBpZGVudGlmaWVycyBhbmQgdHJl YXQgcmVzcG9uc2VzIGZyb20gdGhlIEJOQU1FDQo+PiAgICAgc2lnbmVkIHpvbmUgYXMgaW5zZWN1 cmUsIG90aGVyd2lzZSB0aGUgYm5hbWUgUlIgd2lsbA0KPj4gICAgYmUgcmVnYXJkZWQgYXMgYm9n dXMgaWYgdGhlcmUgaXMgbm8gc3VjaCBhIG1lY2hhbmlzbS4NCj4+IA0KPj4gICAgIFRoZXNlIGFs Z29yaXRobSBpZGVudGlmaWVycyBhcmUgdXNlZCB3aXRoIHRoZSBCTkFNRSBoYXNoIGFsZ29yaXRo bQ0KPj4gICAgIFNIQTEuICBVc2luZyBvdGhlciBCTkFNRSBoYXNoIGFsZ29yaXRobXMgcmVxdWly ZXMgYWxsb2NhdGlvbiBvZiBhIG5ldw0KPj4gICAgIGFsaWFzLg0KPj4gICAgIFZhbGlkYXRpbmcg cmVzb2x2ZXJzIHdoaWNoIGZvbGxvdyB0aGUgQk5BTUUgc3BlY2lmaWNhdGlvbiBNVVNUDQo+PiAg ICAgcmVjb2duaXplIHRoZSBuZXcgYWxpYXMgYWxnb3JpdGhtIGlkZW50aWZpZXIuDQo+PiANCj4+ IA0KPj4gDQo+PiANCj4gDQo+ From owner-namedroppers@ops.ietf.org Sun Jun 27 20:28:45 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19F93A683E; Sun, 27 Jun 2010 20:28:45 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.243 X-Spam-Level: ** X-Spam-Status: No, score=2.243 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEh6IKNjsknB; Sun, 27 Jun 2010 20:28:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A10A03A67A5; Sun, 27 Jun 2010 20:28:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OT4w1-000Mww-15 for namedroppers-data0@psg.com; Mon, 28 Jun 2010 03:23:01 +0000 Received: from [159.226.7.146] (helo=cnnic.cn) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OT4vy-000MwJ-95 for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 03:22:58 +0000 Received: (eyou send program); Mon, 28 Jun 2010 11:22:57 +0800 Message-ID: <477695377.29471@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 28 Jun 2010 11:22:57 +0800 Message-ID: <9853A159205D4D02867167E737FA9C73@LENOVO47E041CF> From: "Jiankang YAO" To: Subject: [dnsext] Fw: I-D Action:draft-yao-dnsext-bname-03.txt Date: Mon, 28 Jun 2010 11:23:03 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_061C_01CB16B4.461CAD80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_061C_01CB16B4.461CAD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 dGhhbmtzIGEgbG90IGZvciAgTWFyayBBbmRyZXdzICwgR2VvcmdlIEJhcndvb2QgYW5kIE9sYWZ1 ciBHdWRtdW5kc3Nvbg0KDQppbXByb3ZpbmcgdGhpcyBkb2N1bWVudC4NCg0Kbm93LCBpdCBpcyB1 cGRhdGVkIHRvIHZlcnNpb24gMDMuDQoNCmFueSBjb21tZW50cyBhcmUgd2VsY29tZS4NCg0KDQpK aWFua2FuZyBZYW8NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogPElu dGVybmV0LURyYWZ0c0BpZXRmLm9yZz4NClRvOiA8aS1kLWFubm91bmNlQGlldGYub3JnPg0KU2Vu dDogTW9uZGF5LCBKdW5lIDI4LCAyMDEwIDExOjE1IEFNDQpTdWJqZWN0OiBJLUQgQWN0aW9uOmRy YWZ0LXlhby1kbnNleHQtYm5hbWUtMDMudHh0IA0KDQoNCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMu DQo+IA0KPiBUaXRsZSAgICAgICAgICAgOiBCdW5kbGUgRE5TIE5hbWUgUmVkaXJlY3Rpb24NCj4g QXV0aG9yKHMpICAgICAgIDogSi4gWWFvLCBldCBhbC4NCj4gRmlsZW5hbWUgICAgICAgIDogZHJh ZnQteWFvLWRuc2V4dC1ibmFtZS0wMy50eHQNCj4gUGFnZXMgICAgICAgICAgIDogMTINCj4gRGF0 ZSAgICAgICAgICAgIDogMjAxMC0wNi0yNw0KPiANCj4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEg bmV3IEROUyBSZXNvdXJjZSBSZWNvcmQgY2FsbGVkICJCTkFNRSIsIHdoaWNoDQo+IHByb3ZpZGVz IHRoZSBjYXBhYmlsaXR5IHRvIG1hcCBpdHNlbGYgYW5kIGl0cyBzdWJ0cmVlIG9mIHRoZSBETlMg bmFtZQ0KPiBzcGFjZSB0byBhbm90aGVyIGRvbWFpbi4gIEl0IGRpZmZlcnMgZnJvbSB0aGUgQ05B TUUgcmVjb3JkIHdoaWNoIG9ubHkNCj4gbWFwcyBhIHNpbmdsZSBub2RlIG9mIHRoZSBETlMgbmFt ZSBzcGFjZSwgZnJvbSB0aGUgRE5BTUUgd2hpY2ggb25seQ0KPiBtYXBzIHRoZSBzdWJ0cmVlIG9m IHRoZSBETlMgbmFtZSBzcGFjZSB0byBhbm90aGVyIGRvbWFpbi4NCj4gDQo+IEEgVVJMIGZvciB0 aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC15YW8tZG5zZXh0LWJuYW1lLTAzLnR4dA0KPiANCj4gSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4gQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2ls bCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcg0KPiBpbXBsZW1lbnRhdGlvbiB0 byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0KPiBJbnRl cm5ldC1EcmFmdC4NCj4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSS1ELUFubm91bmNl IG1haWxpbmcgbGlzdA0KPiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4gSW50ZXJuZXQtRHJhZnQgZGly ZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4gb3IgZnRwOi8vZnRw LmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4= ------=_NextPart_000_061C_01CB16B4.461CAD80 Content-Type: text/plain; name="draft-yao-dnsext-bname-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-yao-dnsext-bname-03.txt" Content-Type: text/plain Content-ID: <2010-06-27200305.I-D@ietf.org> ------=_NextPart_000_061C_01CB16B4.461CAD80-- From owner-namedroppers@ops.ietf.org Mon Jun 28 09:06:48 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74DA28C0D9; Mon, 28 Jun 2010 09:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.028 X-Spam-Level: *** X-Spam-Status: No, score=3.028 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urre62-VfBIL; Mon, 28 Jun 2010 09:06:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 374373A698F; Mon, 28 Jun 2010 09:06:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTGjp-0002GG-L7 for namedroppers-data0@psg.com; Mon, 28 Jun 2010 15:59:13 +0000 Received: from [209.85.212.52] (helo=mail-vw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTGjm-0002Fj-SW for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 15:59:10 +0000 Received: by vws3 with SMTP id 3so537439vws.11 for ; Mon, 28 Jun 2010 08:59:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.196 with SMTP id v4mr3060701vcr.35.1277740749193; Mon, 28 Jun 2010 08:59:09 -0700 (PDT) Received: by 10.220.164.144 with HTTP; Mon, 28 Jun 2010 08:59:09 -0700 (PDT) In-Reply-To: <4C27EDC6.7070903@gis.net> References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C27EDC6.7070903@gis.net> Date: Mon, 28 Jun 2010 08:59:09 -0700 Message-ID: Subject: Re: [dnsext] latency From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: mayer@gis.net Cc: Nicholas Weaver , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Sun, Jun 27, 2010 at 5:33 PM, Danny Mayer wrote: > Yes and that is the reason that you can have the HTTP server do all the > work. The HTTP server receives the client IP address (no privacy here) > and can craft an frameset answer that points the rest of the URL's to > his nearest (for some biased meaning of nearest) server. The frameset > doesn't need to contain much and can be generated on the fly. Please see the numerous posts on this list debunking this idea. But to repeat just a little; Latencies; C = client, R = resolver, A = authoritative nameserver , I = intermediary HTTP server, S = Ultimate HTTP server (i) DNS tricks Client queries the resolver for example.com Resolver queries the auth server, auth server responds Resolver responds to client Client initialises TCP connection to Ultimate HTTP server Total network time to first byte; |CR| + |RA| + 2x |CS| (ii) HTTP tricks Client queries the resolver for example.com Resolver queries the auth server, auth server responds Resolver responds to the client Client initiaises TCP connection to Intermediary HTTP server Client Receives redirect to "192.0.2.1.example.com" say (or a frameset, or an iframe). Client queries the resolver for this new name. Resolver queries the auth server, auth server responds Resolver responds to the client Client initialises TCP connection to ultimate HTTP server Total network time to first byte: 2x |CR| + 2x |RA| + 2x |CI| + 2x |CS| Total difference between the two; |CR| + |RA| + 2x |CI| . > So you are saying that the HTTP protocol is inadequate for your > purposes. What did the HTTP Working Group have to say or recommend? You > are saying that this is an HTTP problem. The utility of finding low-latency endpoints is not restricted to HTTP, it's merely a common example :) -- Colm From owner-namedroppers@ops.ietf.org Mon Jun 28 09:19:05 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A07553A6915; Mon, 28 Jun 2010 09:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.027 X-Spam-Level: *** X-Spam-Status: No, score=3.027 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRbFiLla-jhC; Mon, 28 Jun 2010 09:19:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ABCC63A68C2; Mon, 28 Jun 2010 09:19:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTGyJ-0004lF-4j for namedroppers-data0@psg.com; Mon, 28 Jun 2010 16:14:11 +0000 Received: from [209.85.212.52] (helo=mail-vw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTGyG-0004kl-2B for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 16:14:08 +0000 Received: by vws3 with SMTP id 3so562280vws.11 for ; Mon, 28 Jun 2010 09:14:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.226 with SMTP id v34mr3011296vcr.203.1277741646658; Mon, 28 Jun 2010 09:14:06 -0700 (PDT) Received: by 10.220.164.144 with HTTP; Mon, 28 Jun 2010 09:14:06 -0700 (PDT) In-Reply-To: <477443005.14379@cnnic.cn> References: <477443005.14379@cnnic.cn> Date: Mon, 28 Jun 2010 09:14:06 -0700 Message-ID: Subject: Re: [dnsext] draft-vixie-dnsext-resimprove-00: Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Zheng Wang Cc: vixie@isc.org, namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Thu, Jun 24, 2010 at 10:16 PM, Zheng Wang wrote: >>On 2.6 - I not sure that randomly reducing the TTL as suggested is a >>good idea. Instead it may be better to randomise when the record is >>revalidated (or prefetched). The difference is that I think that the >>resolver should advertise the "honest" decrementing TTL to any >>queries. That way if you have a hierarchy of resolvers they aren't >>simply making the effective TTL shorter and shorter still. >> > > In my view, they are separate concepts. The advertised TTL adheres to the original > definition, while the TTL used for delegation validation is randomly reduced. That's my view too, but it's not what the I-D says. The I-D says to reduce it before storing it in the cache :) >>On 3.4 - I see the security note at 5.1, but still - an attacker might >>poison with a long-ttl NXDOMAIN response for "com" or "." and it will >>cause a lot of problems for the resolver. As written, it may even >>cause the cache to have to purge potentially a large volume of data. >>I'm not sure I see the benefit, insulating upstream servers from >>slightly more queries seems less important. Are NXDOMAIN subtrees >>really a big problem? >> > > No, the purpose of delegation validation is likewise right here to maintain the > coherency. I don't see NXDOMAIN for an entire subtree as that closely tied to delegation validation - as the I-D itself says the current state of things is ambiguous. >>On 4.4 - what happens when no nameservers are returned? Sometimes the >>nameservers to which a domain have been delegated have incoherent >>opinions about where the apex even is. E.g. > > This still works, but the delegated nameservers have no chance to be replaced by > the true authoritative ones and thus have to be relied on. That should be clarified - one reading is that it implies "this domain has no nameservers". -- Colm From owner-namedroppers@ops.ietf.org Mon Jun 28 09:32:30 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B983A6A68; Mon, 28 Jun 2010 09:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoCWcKq5hSAg; Mon, 28 Jun 2010 09:32:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C11D93A67C1; Mon, 28 Jun 2010 09:32:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTHBU-0006ry-7y for namedroppers-data0@psg.com; Mon, 28 Jun 2010 16:27:48 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTHBO-0006rO-RU for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 16:27:42 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 86EF6A103E for ; Mon, 28 Jun 2010 16:27:42 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] latency In-Reply-To: Your message of "Mon\, 28 Jun 2010 08\:59\:09 MST." References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C27EDC6.7070903@gis.net> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jun 2010 16:27:42 +0000 Message-ID: <20914.1277742462@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Mon, 28 Jun 2010 08:59:09 -0700 > From: Colm MacC=C3=A1rthaigh >=20 > > ... >=20 > Please see the numerous posts on this list debunking this idea. ... you say debunked, i say armwaved. > > ... >=20 > The utility of finding low-latency endpoints is not restricted to > HTTP, it's merely a common example :) there is however no non-HTTP global industry clamouring for this DNS change. From owner-namedroppers@ops.ietf.org Mon Jun 28 09:56:28 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6FAF3A6910; Mon, 28 Jun 2010 09:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6Dv2B7TXzr5; Mon, 28 Jun 2010 09:56:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D25583A681B; Mon, 28 Jun 2010 09:56:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTHZ9-000AmL-DT for namedroppers-data0@psg.com; Mon, 28 Jun 2010 16:52:15 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTHZ6-000Am1-NU for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 16:52:12 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 75A7BA103E for ; Mon, 28 Jun 2010 16:52:12 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dnsext] draft-vixie-dnsext-resimprove-00: Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness In-Reply-To: Your message of "Mon\, 28 Jun 2010 09\:14\:06 MST." References: <477443005.14379@cnnic.cn> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jun 2010 16:52:12 +0000 Message-ID: <22367.1277743932@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Date: Mon, 28 Jun 2010 09:14:06 -0700 > From: Colm MacC=C3=A1rthaigh >=20 > > In my view, they are separate concepts. The advertised TTL adheres to > > the original definition, while the TTL used for delegation validation > > is randomly reduced. >=20 > That's my view too, but it's not what the I-D says. The I-D says to > reduce it before storing it in the cache :) here's the text: 2.6. To make the timing of a revalidation event unpredictable from the point of view of a potential cache-spoof attacker, the parent's delegating NS RRset TTL should be reduced by a random fraction of its value before being stored for use in revalidation activities. the intent was what you guys are saying here. i'll clarify the text. i really thought "stored for use in revalidation activities" was clear. > > > On 3.4 - I see the security note at 5.1, but still - an attacker > > > might poison with a long-ttl NXDOMAIN response for "com" or "." and > > > it will cause a lot of problems for the resolver. As written, it may > > > even cause the cache to have to purge potentially a large volume of > > > data. I'm not sure I see the benefit, insulating upstream servers > > > from slightly more queries seems less important. Are NXDOMAIN > > > subtrees really a big problem? > > > > No, the purpose of delegation validation is likewise right here to > > maintain the coherency. >=20 > I don't see NXDOMAIN for an entire subtree as that closely tied to > delegation validation it's not. but it is intended to maintain coherency. > - as the I-D itself says the current state of things is ambiguous. the -00 text says it was ambiguous before DNSSEC clarified it. if we believe that a poisoned response can overwrite . or COM in the cache, then we should worry about false NS RRsets as much as we'd worry about false NXDOMAIN. i assert that those are equivilent risks (same possibility of it occurring, same danger to a victim when it occurs.) i'm not talking about "slightly more queries" either. this is a DDoS vector the leaving open of which supports a protocol ambiguity that's long since been decided. the more i think about this, it should be STD nor FYI. > > > On 4.4 - what happens when no nameservers are returned? Sometimes the > > > nameservers to which a domain have been delegated have incoherent > > > opinions about where the apex even is. E.g. > > > > This still works, but the delegated nameservers have no chance to be > > replaced by the true authoritative ones and thus have to be relied on. >=20 > That should be clarified - one reading is that it implies "this domain > has no nameservers". will do. From owner-namedroppers@ops.ietf.org Mon Jun 28 11:51:52 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69ECA3A693B; Mon, 28 Jun 2010 11:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.809 X-Spam-Level: X-Spam-Status: No, score=-0.809 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTp+SJml1UYI; Mon, 28 Jun 2010 11:51:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 317D83A693E; Mon, 28 Jun 2010 11:51:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTJMk-0001Al-Tp for namedroppers-data0@psg.com; Mon, 28 Jun 2010 18:47:34 +0000 Received: from [2001:4f8:fff7:1::5] (helo=mail1.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTJMi-0001AK-Fa for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 18:47:32 +0000 Received: from [198.22.153.9] (helo=[10.60.111.37]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OTJM7-000FHI-6I; Mon, 28 Jun 2010 18:47:05 +0000 Message-ID: <4C28EE56.9070908@gis.net> Date: Mon, 28 Jun 2010 14:47:50 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= CC: Nicholas Weaver , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C27EDC6.7070903@gis.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 198.22.153.9 X-SA-Exim-Rcpt-To: colm@allcosts.net, nweaver@icsi.berkeley.edu, wilmer@google.com, b+dns@bruce-2010.zerlargal.org, sthaug@nethelp.no, namedroppers@ops.ietf.org X-SA-Exim-Mail-From: mayer@ntp.org Subject: Re: [dnsext] latency X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 6/28/2010 11:59 AM, Colm MacCárthaigh wrote: > On Sun, Jun 27, 2010 at 5:33 PM, Danny Mayer wrote: >> Yes and that is the reason that you can have the HTTP server do all the >> work. The HTTP server receives the client IP address (no privacy here) >> and can craft an frameset answer that points the rest of the URL's to >> his nearest (for some biased meaning of nearest) server. The frameset >> doesn't need to contain much and can be generated on the fly. > > Please see the numerous posts on this list debunking this idea. But to > repeat just a little; > > Latencies; > C = client, R = resolver, A = authoritative nameserver , I = > intermediary HTTP server, S = Ultimate HTTP server > > (i) DNS tricks > > Client queries the resolver for example.com > Resolver queries the auth server, auth server responds > Resolver responds to client > Client initialises TCP connection to Ultimate HTTP server > > Total network time to first byte; |CR| + |RA| + 2x |CS| > > (ii) HTTP tricks > > Client queries the resolver for example.com > Resolver queries the auth server, auth server responds > Resolver responds to the client > Client initiaises TCP connection to Intermediary HTTP server > Client Receives redirect to "192.0.2.1.example.com" say (or a > frameset, or an iframe). > Client queries the resolver for this new name. > Resolver queries the auth server, auth server responds > Resolver responds to the client > Client initialises TCP connection to ultimate HTTP server > > Total network time to first byte: 2x |CR| + 2x |RA| + 2x |CI| + 2x |CS| > > Total difference between the two; |CR| + |RA| + 2x |CI| . > This means that you didn't understand my comments about framesets. When you send the initial request to the server, it figures out where your browser is and then constructs a frameset response containing the closest URL's to fetch when populating each frame in the frameset. There are no additional queries that need to be made. >> So you are saying that the HTTP protocol is inadequate for your >> purposes. What did the HTTP Working Group have to say or recommend? You >> are saying that this is an HTTP problem. > > The utility of finding low-latency endpoints is not restricted to > HTTP, it's merely a common example :) Really? Then please provide a list (at least one) of other protocols that needs take advantage of this proposal. I still want to know what the HTTP WG has to say about all this. Danny From owner-namedroppers@ops.ietf.org Mon Jun 28 12:12:30 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F423A6969; Mon, 28 Jun 2010 12:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ct3hNC3WInRH; Mon, 28 Jun 2010 12:12:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DCCC73A6962; Mon, 28 Jun 2010 12:12:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTJgx-00040Z-7v for namedroppers-data0@psg.com; Mon, 28 Jun 2010 19:08:27 +0000 Received: from [209.85.212.180] (helo=mail-px0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTJgu-000400-B7 for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 19:08:24 +0000 Received: by pxi4 with SMTP id 4so23878pxi.11 for ; Mon, 28 Jun 2010 12:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=3NN0IMreBgLI2R2qUgmTzi+hOBOQ/O2qWmkdEGJNEmk=; b=QvzNsE62X1DY4p81VSTF5qCVfhThLq8pzuVlV26jzwWYQLPdrCnaqIXlyRRdHpLhn1 SuUeO78b5/K54XLlT0pb5MTEK6fkzYCB9IAWSbeMHYDR3oOSYWnP18t6Wi/YHwmkSTdr xSC5OynQy4bzkbcUR9yaGqr918EzPqTMJDb88= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=MsYAaVCmeW2WNgesS/TypR1m0SQk0cZOHwnM4Bg3TKSm0Lrv9azYMQLx1iyrV+Ll0G YhrhU+sSg950oL7GBXwZ3j3/bTGoSnQSao8SKqj8pSZwc+FnFNhDqx8lzDe7QxcgH+20 IM5ejofzONFf+rrB3DNP4lAwlcGxT+Zr4n3Kw= Received: by 10.142.152.12 with SMTP id z12mr6555572wfd.71.1277752103551; Mon, 28 Jun 2010 12:08:23 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id i19sm3932794rvn.4.2010.06.28.12.08.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jun 2010 12:08:23 -0700 (PDT) References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C27EDC6.7070903@gis.net> <4C28EE56.9070908@gis.net> In-Reply-To: <4C28EE56.9070908@gis.net> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: [dnsext] latency Date: Mon, 28 Jun 2010 12:08:21 -0700 To: mayer@gis.net X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 28, 2010, at 11:47 AM, Danny Mayer wrote: >> The utility of finding low-latency endpoints is not restricted to >> HTTP, it's merely a common example :) >=20 > Really? Then please provide a list (at least one) of other protocols > that needs take advantage of this proposal. I still want to know what > the HTTP WG has to say about all this. vpn.mybigcompany.com should ideally resolve to different systems whether you are on the east = or west coast of the US, unless you LIKE an additional 100ms latency in = your VPN tunnels. From owner-namedroppers@ops.ietf.org Mon Jun 28 12:38:12 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93E63A6960; Mon, 28 Jun 2010 12:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.027 X-Spam-Level: *** X-Spam-Status: No, score=3.027 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZPdFgQRzUQf; Mon, 28 Jun 2010 12:38:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A283A3A683A; Mon, 28 Jun 2010 12:38:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTK5r-0007DI-KG for namedroppers-data0@psg.com; Mon, 28 Jun 2010 19:34:11 +0000 Received: from [209.85.212.52] (helo=mail-vw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTK5p-0007Cu-7C for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 19:34:09 +0000 Received: by vws3 with SMTP id 3so905044vws.11 for ; Mon, 28 Jun 2010 12:34:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.128.203 with SMTP id l11mr3174159vcs.125.1277753647915; Mon, 28 Jun 2010 12:34:07 -0700 (PDT) Received: by 10.220.164.144 with HTTP; Mon, 28 Jun 2010 12:34:07 -0700 (PDT) In-Reply-To: <4C28EE56.9070908@gis.net> References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C27EDC6.7070903@gis.net> <4C28EE56.9070908@gis.net> Date: Mon, 28 Jun 2010 12:34:07 -0700 Message-ID: Subject: Re: [dnsext] latency From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: mayer@gis.net Cc: Nicholas Weaver , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: 2010/6/28 Danny Mayer : >> =A0Total network time to first byte: =A02x |CR| + 2x |RA| + 2x |CI| + 2x= |CS| >> >> =A0Total difference between the two; =A0|CR| + |RA| + 2x |CI| =A0. >> > > This means that you didn't understand my comments about framesets. When > you send the initial request to the server, it figures out where your > browser is and then constructs a frameset response containing the > closest URL's to fetch when populating each frame in the frameset. There > are no additional queries that need to be made. Plainly an additional query is neccessary - the initial request to the server (which generates the page containing the frameset reference). Additionally your solution is HTML specific, not HTTP. Please re-read the steps involved, it should be clear where the additional latency comes from. >>> So you are saying that the HTTP protocol is inadequate for your >>> purposes. What did the HTTP Working Group have to say or recommend? You >>> are saying that this is an HTTP problem. >> >> The utility of finding low-latency endpoints is not restricted to >> HTTP, it's merely a common example :) > > Really? Then please provide a list (at least one) of other protocols > that needs take advantage of this proposal. I still want to know what > the HTTP WG has to say about all this. Any layer 4+ protocol which uses DNS for endpoint resolution would benefit from the technique. The list is practically endless, but it's been used for VOIP conference bridges, FTP and more. Questions directed at the HTTP WG are best sent there - but working groups don't speak with single anthropomorphic voices. Fwiw, if it helps, I'm a contributor to the HTTP WG, and a HTTP implementation (Apache) and there is no HTTP technique that I am aware of that is comparable to DNS tricks. --=20 Colm From dnsext-archive@ietf.org Mon Jun 28 12:42:20 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB29C3A6974 for ; Mon, 28 Jun 2010 12:42:20 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org VIAGRA \256 Official Site -89%\n X-Spam-Flag: NO X-Spam-Score: -22.56 X-Spam-Level: X-Spam-Status: No, score=-22.56 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIH5ADY6lFgZ for ; Mon, 28 Jun 2010 12:42:19 -0700 (PDT) Received: from cheering.congruence.volia.net (cheering.congruence.volia.net [77.122.30.7]) by core3.amsl.com (Postfix) with SMTP id 0FBF53A6960 for ; Mon, 28 Jun 2010 12:42:18 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org VIAGRA ® Official Site -89% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100628194219.0FBF53A6960@core3.amsl.com> Date: Mon, 28 Jun 2010 12:42:18 -0700 (PDT)
Click here.

Dear dnsext-archive@ietf.org
From owner-namedroppers@ops.ietf.org Mon Jun 28 12:59:53 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5963A6973; Mon, 28 Jun 2010 12:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.82 X-Spam-Level: X-Spam-Status: No, score=-101.82 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xz8Y23Yiet5C; Mon, 28 Jun 2010 12:59:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 89B4128C10D; Mon, 28 Jun 2010 12:59:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTKQt-000AiM-2o for namedroppers-data0@psg.com; Mon, 28 Jun 2010 19:55:55 +0000 Received: from [2001:1890:1112:1::2f] (helo=rfc-editor.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTKQp-000Ahf-JX for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 19:55:51 +0000 Received: by rfc-editor.org (Postfix, from userid 30) id A62D9E06B2; Mon, 28 Jun 2010 12:55:50 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: [dnsext] RFC 5936 on DNS Zone Transfer Protocol (AXFR) From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org Message-Id: <20100628195550.A62D9E06B2@rfc-editor.org> Date: Mon, 28 Jun 2010 12:55:50 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: A new Request for Comments is now available in online RFC libraries. RFC 5936 Title: DNS Zone Transfer Protocol (AXFR) Author: E. Lewis, A. Hoenes, Ed. Status: Standards Track Stream: IETF Date: June 2010 Mailbox: ed.lewis@neustar.biz, ah@TR-Sys.de Pages: 29 Characters: 66337 Updates: RFC1034, RFC1035 I-D Tag: draft-ietf-dnsext-axfr-clarify-14.txt URL: http://www.rfc-editor.org/rfc/rfc5936.txt The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035. The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. [STANDARDS TRACK] This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From owner-namedroppers@ops.ietf.org Mon Jun 28 13:43:37 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869A83A6A72; Mon, 28 Jun 2010 13:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.072 X-Spam-Level: ** X-Spam-Status: No, score=2.072 tagged_above=-999 required=5 tests=[AWL=-0.691, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_93=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bOKYPK3oQQq; Mon, 28 Jun 2010 13:43:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1F3628C0E5; Mon, 28 Jun 2010 13:43:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTL4H-000GOU-Jn for namedroppers-data0@psg.com; Mon, 28 Jun 2010 20:36:37 +0000 Received: from [209.86.89.65] (helo=elasmtp-kukur.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTL4E-000GMy-Dg for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 20:36:34 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=EpxfRpJSUzK19wjAZ2C4VHS5FP1f54++HnTLvR6iNUm8k6UMJYAOnGV8WQzcEvNM; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.37] (helo=elwamui-karabash.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OTL41-0001KH-1F; Mon, 28 Jun 2010 16:36:21 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Mon, 28 Jun 2010 16:36:20 -0400 Message-ID: <26133709.1277757380997.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Date: Mon, 28 Jun 2010 15:36:20 -0500 (GMT-05:00) From: "Jeffrey A. Williams" Reply-To: "Jeffrey A. Williams" To: rfc-editor@rfc-editor.org, ietf-announce@ietf.org, rfc-dist@rfc-editor.org, ah@TR-Sys.de, ed.lewis@neustar.biz Subject: Re: [dnsext] RFC 5936 on DNS Zone Transfer Protocol (AXFR) Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688e7d626e2e55336e0764a46fdc699f0c1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.37 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: All, Just as an aside note of interest, does everyone recognize that TR-Sys.de refrenced below in the original message has an open relay? See: http://www.dnsstuff.com/tools/dnsreport?domain=TR-Sys.de&format=raw&loadresults=true&token=24f10c06c4cf7f7c04b5a0051ef10019 -----Original Message----- >From: rfc-editor@rfc-editor.org >Sent: Jun 28, 2010 2:55 PM >To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org >Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org >Subject: [dnsext] RFC 5936 on DNS Zone Transfer Protocol (AXFR) > > >A new Request for Comments is now available in online RFC libraries. > > > RFC 5936 > > Title: DNS Zone Transfer Protocol (AXFR) > Author: E. Lewis, A. Hoenes, Ed. > Status: Standards Track > Stream: IETF > Date: June 2010 > Mailbox: ed.lewis@neustar.biz, > ah@TR-Sys.de > Pages: 29 > Characters: 66337 > Updates: RFC1034, RFC1035 > > I-D Tag: draft-ietf-dnsext-axfr-clarify-14.txt > > URL: http://www.rfc-editor.org/rfc/rfc5936.txt > >The standard means within the Domain Name System protocol for >maintaining coherence among a zone's authoritative name servers >consists of three mechanisms. Authoritative Transfer (AXFR) is one >of the mechanisms and is defined in RFC 1034 and RFC 1035. > >The definition of AXFR has proven insufficient in detail, thereby >forcing implementations intended to be compliant to make assumptions, >impeding interoperability. Yet today we have a satisfactory set of >implementations that do interoperate. This document is a new >definition of AXFR -- new in the sense that it records an accurate >definition of an interoperable AXFR mechanism. [STANDARDS TRACK] > >This document is a product of the DNS Extensions Working Group of the IETF. > >This is now a Proposed Standard Protocol. > >STANDARDS TRACK: This document specifies an Internet standards track >protocol for the Internet community,and requests discussion and suggestions >for improvements. Please refer to the current edition of the Internet >Official Protocol Standards (STD 1) for the standardization state and >status of this protocol. Distribution of this memo is unlimited. > >This announcement is sent to the IETF-Announce and rfc-dist lists. >To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > >For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. >For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution. > > >The RFC Editor Team >Association Management Solutions, LLC > > > Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300+k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From owner-namedroppers@ops.ietf.org Mon Jun 28 14:21:42 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277C93A6A8B; Mon, 28 Jun 2010 14:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.607 X-Spam-Level: X-Spam-Status: No, score=-94.607 tagged_above=-999 required=5 tests=[AWL=-1.457, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96u9xqmRCDuv; Mon, 28 Jun 2010 14:21:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D7F063A6A7F; Mon, 28 Jun 2010 14:21:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTLgH-000LaM-O7 for namedroppers-data0@psg.com; Mon, 28 Jun 2010 21:15:53 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTLgE-000LZo-FE for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 21:15:51 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA044289690; Mon, 28 Jun 2010 23:14:50 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA23142; Mon, 28 Jun 2010 23:14:49 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201006282114.XAA23142@TR-Sys.de> Subject: Re: claimed open relay [was: Re: [dnsext] RFC 5936 on DNS Zone Transfer Protocol (AXFR)] To: jwkckid1@ix.netcom.com Date: Mon, 28 Jun 2010 23:14:48 +0200 (MESZ) Cc: namedroppers@ops.ietf.org In-Reply-To: <26133709.1277757380997.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> from "Jeffrey A. Williams" at Jun "28," 2010 "03:36:20" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Jeffrey A. Williams wrote: > All, > > Just as an aside note of interest, does everyone recognize that > TR-Sys.de refrenced below in the original message has an open relay? > See: > http://www.dnsstuff.com/tools/dnsreport?domain=TR-Sys.de&format=raw&loadresults=true&token=24f10c06c4cf7f7c04b5a0051ef10019 > > ... This sounds rather incredibly -- the recursive server operated by TR-Sys is behind a NAT/firewall and does not answer any queries arriving on the WAN interface. Of course, it is operated in an officially undefined mode -- split DNS. :-) Kind regards, Alfred. From owner-namedroppers@ops.ietf.org Mon Jun 28 14:22:15 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B833A6A72; Mon, 28 Jun 2010 14:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.153 X-Spam-Level: ** X-Spam-Status: No, score=2.153 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ8M25TaWkqP; Mon, 28 Jun 2010 14:22:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DE7223A69E7; Mon, 28 Jun 2010 14:22:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTLj5-000LvU-0r for namedroppers-data0@psg.com; Mon, 28 Jun 2010 21:18:47 +0000 Received: from [209.86.89.65] (helo=elasmtp-kukur.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTLj2-000Lv9-7d for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 21:18:44 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=uC9Wv0GFdEwagVJzkq9zPkrpOzd0WNfAcIeIMrxUU6oiZbFuuRuYo5CLb3akjQbA; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.37] (helo=elwamui-karabash.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OTLj0-0001PD-Ej; Mon, 28 Jun 2010 17:18:42 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Mon, 28 Jun 2010 17:18:42 -0400 Message-ID: <10217833.1277759922522.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Date: Mon, 28 Jun 2010 16:18:42 -0500 (GMT-05:00) From: "Jeffrey A. Williams" Reply-To: "Jeffrey A. Williams" To: Alfred =?hp-roman8?B?SM5uZXM=?= Subject: Re: claimed open relay [was: Re: [dnsext] RFC 5936 on DNS Zone Transfer Protocol (AXFR)] Cc: namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068858868ab088d725ca7aab13becbc718eb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.37 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Alfred and all, Understood, but still closing up that open relay is in your and everyone elses best interests don't you think? >:) -----Original Message----- >From: Alfred =?hp-roman8?B?SM5uZXM=?= >Sent: Jun 28, 2010 4:14 PM >To: jwkckid1@ix.netcom.com >Cc: namedroppers@ops.ietf.org >Subject: Re: claimed open relay [was: Re: [dnsext] RFC 5936 on DNS Zone Transfer Protocol (AXFR)] > >Jeffrey A. Williams wrote: > >> All, >> >> Just as an aside note of interest, does everyone recognize that >> TR-Sys.de refrenced below in the original message has an open relay? >> See: >> http://www.dnsstuff.com/tools/dnsreport?domain=TR-Sys.de&format=raw&loadresults=true&token=24f10c06c4cf7f7c04b5a0051ef10019 >> >> ... > >This sounds rather incredibly -- the recursive server operated >by TR-Sys is behind a NAT/firewall and does not answer any queries >arriving on the WAN interface. Of course, it is operated in an >officially undefined mode -- split DNS. :-) > >Kind regards, > Alfred. > Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300+k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From owner-namedroppers@ops.ietf.org Mon Jun 28 14:42:14 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6554B3A67FE; Mon, 28 Jun 2010 14:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HinM5a3jZPPL; Mon, 28 Jun 2010 14:42:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 01F133A67EA; Mon, 28 Jun 2010 14:42:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTM28-000O94-MK for namedroppers-data0@psg.com; Mon, 28 Jun 2010 21:38:28 +0000 Received: from [209.85.160.52] (helo=mail-pw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTM26-000O8j-3O for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 21:38:26 +0000 Received: by pwj10 with SMTP id 10so1135577pwj.11 for ; Mon, 28 Jun 2010 14:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=Jt9Buz+MWTV72OQrnxMhvwW5868DXDZxoyw+33hpDQo=; b=c8PzJpW1qTmn8SBPyg1Lt7Tu3U8p8jJFNMu2miVG5zL844Y1hBLzj4CwaVpy3QnppE CHFAKWJibghWjyfnvrr4hmjJB1MD+6rvvXBdTyXhUDK6BP1r4eRtXmuDPjxNOEPkf2o2 KRwtlvZ1iJKzOKf6kpAELiTMzvlJC01uvco14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=vv2IUCW/oVEbV5Io3MSmpRAVIKP0vOT2J6tY/Q1UB3nfCa+6/ifK9lUYYT0M97QSnS JiTYZqFGP4bgAqm1PG+5YpCIVbesQGErW8Jt9HNT1Havdh19RZH8PbDqWis/7O8cDpvs gaPuRah+BakEcO+lqjr+lZS/yuW7SRdS6lX+E= Received: by 10.142.119.20 with SMTP id r20mr6541390wfc.15.1277761104706; Mon, 28 Jun 2010 14:38:24 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id w36sm3965048wfh.14.2010.06.28.14.38.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jun 2010 14:38:24 -0700 (PDT) References: <10217833.1277759922522.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> In-Reply-To: <10217833.1277759922522.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <086CEB99-5F30-4E0F-AC1E-C84B06154DAB@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , =?iso-8859-1?Q?Alfred_H=CEnes?= , namedroppers@ops.ietf.org From: Nicholas Weaver Subject: Re: claimed open relay [was: Re: [dnsext] RFC 5936 on DNS Zone Transfer Protocol (AXFR)] Date: Mon, 28 Jun 2010 14:38:21 -0700 To: "Jeffrey A. Williams" X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 28, 2010, at 2:18 PM, Jeffrey A. Williams wrote: > Alfred and all, >=20 > Understood, but still closing up that open relay is in your and > everyone elses best interests don't you think? >:) HU? dig www.google.com @tr-sys.de ; <<>> DiG 9.6.0-APPLE-P2 <<>> www.google.com @tr-sys.de ;; global options: +cmd ;; connection timed out; no servers could be reached [gala:~/archive/svn_nweaver] nweaver%=20 Also, frankly, with 3%+ of the residential NATs tested having open DNS = relays, who cares? From owner-namedroppers@ops.ietf.org Mon Jun 28 15:00:46 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0A93A6800; Mon, 28 Jun 2010 15:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iotpy9yVjHt; Mon, 28 Jun 2010 15:00:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C92E53A67CC; Mon, 28 Jun 2010 15:00:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTMJa-0000CK-VU for namedroppers-data0@psg.com; Mon, 28 Jun 2010 21:56:31 +0000 Received: from [204.152.189.190] (helo=virtualized.org) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTMJY-0000C0-IN for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 21:56:28 +0000 Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 78E61CE8D75; Mon, 28 Jun 2010 14:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1eHnv7XaXqX; Mon, 28 Jun 2010 14:56:25 -0700 (PDT) Received: from [10.96.18.16] (wlan39-021.mdr.icann.org [192.0.39.21]) by virtualized.org (Postfix) with ESMTP id D8037CE8D61; Mon, 28 Jun 2010 14:56:24 -0700 (PDT) Subject: [dnsext] 3% of residental NAT boxes? [was Re: claimed open relay [was something else]] Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <086CEB99-5F30-4E0F-AC1E-C84B06154DAB@icsi.berkeley.edu> Date: Mon, 28 Jun 2010 14:56:24 -0700 Cc: "namedroppers@ops.ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <1EEF364B-1C2B-46C2-8FEE-B59420AC19F1@virtualized.org> References: <10217833.1277759922522.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <086CEB99-5F30-4E0F-AC1E-C84B06154DAB@icsi.berkeley.edu> To: Nicholas Weaver X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > Also, frankly, with 3%+ of the residential NATs tested having open DNS = relays, who cares? Egads. Do you have an idea of the vendor(s) who facilitate this? Also, do you have an estimate for the order of magnitude of the total = number of boxes we're talking here? Thanks, -drc From owner-namedroppers@ops.ietf.org Mon Jun 28 15:06:03 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60F33A6A90; Mon, 28 Jun 2010 15:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqrI4NsWMhv5; Mon, 28 Jun 2010 15:06:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D677F3A6A8D; Mon, 28 Jun 2010 15:06:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTMQD-00010j-Gp for namedroppers-data0@psg.com; Mon, 28 Jun 2010 22:03:21 +0000 Received: from [74.125.83.180] (helo=mail-pv0-f180.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTMQA-0000yq-M1 for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 22:03:19 +0000 Received: by pva18 with SMTP id 18so3499851pva.11 for ; Mon, 28 Jun 2010 15:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=Wb8bBGP1uqCrdm/yuG1OjmKWHPlquxc8yqEncXV/xqI=; b=f+PluVwBBhRlct9SKi2TdZ3gsN1B42DWAPs2oXBj2HqGtfc6LuklX9QLRhDBT7VBw+ QH++Eh/Y9uJ28cU4GAlqH8aSyYQkitf/SFayTkxzEYsisfJmu2HYGSSx86mgZV1IcpZb aBJjCq3LgGejRu5yHWesCfEyztRDootQg4jss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=GYquNYJ8aUey4wXjY47iRzl6b60AcBz4xxNH7WyO2lo2IXZs+DvzLFl3eFKqG4BCBQ GxWdMZ7VFNB7nRGBSdS6Cl0Vw+g9+hlEyEuALMbIWje2g8lZCV79XE2kAJPoE8y5xKSn ojlLiKDO05uemkVdYto60YuVEoRpwcRUZ7t50= Received: by 10.142.2.29 with SMTP id 29mr6515990wfb.204.1277762597170; Mon, 28 Jun 2010 15:03:17 -0700 (PDT) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by mx.google.com with ESMTPS id g37sm974734rvb.5.2010.06.28.15.03.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jun 2010 15:03:16 -0700 (PDT) References: <10217833.1277759922522.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <086CEB99-5F30-4E0F-AC1E-C84B06154DAB@icsi.berkeley.edu> <1EEF364B-1C2B-46C2-8FEE-B59420AC19F1@virtualized.org> In-Reply-To: <1EEF364B-1C2B-46C2-8FEE-B59420AC19F1@virtualized.org> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Nicholas Weaver , "namedroppers@ops.ietf.org WG" From: Nicholas Weaver Subject: [dnsext] Re: 3% of residental NAT boxes? [was Re: claimed open relay [was something else]] Date: Mon, 28 Jun 2010 15:03:14 -0700 To: David Conrad X-Mailer: Apple Mail (2.1081) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Jun 28, 2010, at 2:56 PM, David Conrad wrote: >> Also, frankly, with 3%+ of the residential NATs tested having open = DNS relays, who cares? >=20 > Egads. Do you have an idea of the vendor(s) who facilitate this? Nope, we aren't doing NAT fingerprinting (would require connecting to = port 80 and 443 on the NAT and we are uncertain whether we want to do = that). > Also, do you have an estimate for the order of magnitude of the total = number of boxes we're talking here? Hard to tell. The problem is we have a strong "geek bias" in our dataset = for Netalyzr, so really, its 3% of the systems we check. If you wanted to find out for yourself by just doing a full scan, thats = only 4G addresses, at ~40B/packet, so $30 worth of bandwidth at EC2... From owner-namedroppers@ops.ietf.org Mon Jun 28 16:16:14 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2DB63A6973; Mon, 28 Jun 2010 16:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.701 X-Spam-Level: ** X-Spam-Status: No, score=2.701 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-sxqhbjgKAU; Mon, 28 Jun 2010 16:16:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49F253A6897; Mon, 28 Jun 2010 16:16:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTNTS-0008Wf-AY for namedroppers-data0@psg.com; Mon, 28 Jun 2010 23:10:46 +0000 Received: from [38.229.66.8] (helo=obelisk11.ord01.cymru.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTNTO-0008WM-Rc for namedroppers@ops.ietf.org; Mon, 28 Jun 2010 23:10:42 +0000 Received: from t61p (vpn-21-37.svcs.iad01.cymru.com [192.168.21.37]) by obelisk11.ord01.cymru.com (Postfix) with ESMTP id E2E59B0109; Mon, 28 Jun 2010 23:10:40 +0000 (GMT) Date: Mon, 28 Jun 2010 18:10:39 -0500 From: John Kristoff To: David Conrad Cc: Nicholas Weaver , "namedroppers@ops.ietf.org WG" Subject: Re: [dnsext] 3% of residental NAT boxes? [was Re: claimed open relay [was something else]] Message-ID: <20100628181039.05fa8d61@t61p> In-Reply-To: <1EEF364B-1C2B-46C2-8FEE-B59420AC19F1@virtualized.org> References: <10217833.1277759922522.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <086CEB99-5F30-4E0F-AC1E-C84B06154DAB@icsi.berkeley.edu> <1EEF364B-1C2B-46C2-8FEE-B59420AC19F1@virtualized.org> X-Mailer: Claws Mail Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On Mon, 28 Jun 2010 14:56:24 -0700 David Conrad wrote: > Also, do you have an estimate for the order of magnitude of the total > number of boxes we're talking here? We're currently seeing about 6-7 million unique IPv4 addresses per month that appear to be open resolvers. I think it may be slightly higher than that, but its noisy if not annoying to some folks if we were to check more aggressively than we are. There are many more, that are half open. That is, you can query them and the qname will be resolved, but the answer won't be returned to the original querier. This is likely due to one-way filtering near the resolver. There are also a fair number more that may not be completely open, but answer with a referral, cached answer or something else. John From owner-namedroppers@ops.ietf.org Mon Jun 28 17:14:05 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF523A6949; Mon, 28 Jun 2010 17:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.358 X-Spam-Level: X-Spam-Status: No, score=0.358 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfUJBc1z5y2j; Mon, 28 Jun 2010 17:14:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2F3403A68D3; Mon, 28 Jun 2010 17:14:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTOOT-000EJm-Vt for namedroppers-data0@psg.com; Tue, 29 Jun 2010 00:09:42 +0000 Received: from [2001:4f8:fff7:1::5] (helo=mail1.ntp.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTOOR-000EJS-DE for namedroppers@ops.ietf.org; Tue, 29 Jun 2010 00:09:39 +0000 Received: from cust-63-209-227-25.bos-dynamic.gis.net ([63.209.227.25] helo=[10.10.10.101]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OTOO1-0003PJ-DF; Tue, 29 Jun 2010 00:09:24 +0000 Message-ID: <4C2939E4.403@gis.net> Date: Mon, 28 Jun 2010 20:10:12 -0400 From: Danny Mayer Reply-To: mayer@gis.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= CC: Nicholas Weaver , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C27EDC6.7070903@gis.net> <4C28EE56.9070908@gis.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 63.209.227.25 X-SA-Exim-Rcpt-To: colm@allcosts.net, nweaver@icsi.berkeley.edu, wilmer@google.com, b+dns@bruce-2010.zerlargal.org, sthaug@nethelp.no, namedroppers@ops.ietf.org X-SA-Exim-Mail-From: mayer@ntp.org Subject: Re: [dnsext] latency X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: On 6/28/2010 3:34 PM, Colm MacCárthaigh wrote: > 2010/6/28 Danny Mayer : >>> Total network time to first byte: 2x |CR| + 2x |RA| + 2x |CI| + 2x |CS| >>> >>> Total difference between the two; |CR| + |RA| + 2x |CI| . >>> >> >> This means that you didn't understand my comments about framesets. When >> you send the initial request to the server, it figures out where your >> browser is and then constructs a frameset response containing the >> closest URL's to fetch when populating each frame in the frameset. There >> are no additional queries that need to be made. > > Plainly an additional query is neccessary - the initial request to the > server (which generates the page containing the frameset reference). > Additionally your solution is HTML specific, not HTTP. Please re-read > the steps involved, it should be clear where the additional latency > comes from. > Please reread. Just about all Web sites use framesets to lay out the pages and create menus etc. There is no additional requests involved. Now you are saying that there is also a problem with including HTML in the solution? >>>> So you are saying that the HTTP protocol is inadequate for your >>>> purposes. What did the HTTP Working Group have to say or recommend? You >>>> are saying that this is an HTTP problem. >>> >>> The utility of finding low-latency endpoints is not restricted to >>> HTTP, it's merely a common example :) >> >> Really? Then please provide a list (at least one) of other protocols >> that needs take advantage of this proposal. I still want to know what >> the HTTP WG has to say about all this. > > Any layer 4+ protocol which uses DNS for endpoint resolution would > benefit from the technique. The list is practically endless, but it's > been used for VOIP conference bridges, FTP and more. Questions > directed at the HTTP WG are best sent there - but working groups don't > speak with single anthropomorphic voices. Fwiw, if it helps, I'm a > contributor to the HTTP WG, and a HTTP implementation (Apache) and > there is no HTTP technique that I am aware of that is comparable to > DNS tricks. > I hear nothing but HTTP here. If it helps I used to work with the people who worked on the original HTTP protocol spec and had many discussions with them, particularly at W3C. Maybe if you are knowledgeable you can explain how VOIP uses this technique and why nothing else would work. Danny From owner-namedroppers@ops.ietf.org Mon Jun 28 17:32:44 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ECF53A6A0E; Mon, 28 Jun 2010 17:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.727 X-Spam-Level: * X-Spam-Status: No, score=1.727 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAEUm1wUvwdR; Mon, 28 Jun 2010 17:32:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 40D1B3A6A05; Mon, 28 Jun 2010 17:32:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTOh9-000GGh-H9 for namedroppers-data0@psg.com; Tue, 29 Jun 2010 00:28:59 +0000 Received: from [209.85.212.52] (helo=mail-vw0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTOh7-000GGI-1b for namedroppers@ops.ietf.org; Tue, 29 Jun 2010 00:28:57 +0000 Received: by vws3 with SMTP id 3so1386043vws.11 for ; Mon, 28 Jun 2010 17:28:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.127.18 with SMTP id e18mr3353704vcs.275.1277771335427; Mon, 28 Jun 2010 17:28:55 -0700 (PDT) Received: by 10.220.164.144 with HTTP; Mon, 28 Jun 2010 17:28:55 -0700 (PDT) In-Reply-To: <4C2939E4.403@gis.net> References: <0FB48184-C581-44FF-AFC7-258ED9DBADC5@rfc1035.com> <48348A72-07A9-498D-BC93-BEF737AE2193@rfc1035.com> <20100531.140942.74675907.sthaug@nethelp.no> <9DFBC1E7-E761-449D-82FA-1985859A09FA@icsi.berkeley.edu> <4C27EDC6.7070903@gis.net> <4C28EE56.9070908@gis.net> <4C2939E4.403@gis.net> Date: Mon, 28 Jun 2010 17:28:55 -0700 Message-ID: Subject: Re: [dnsext] latency From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: mayer@gis.net Cc: Nicholas Weaver , Wilmer van der Gaast , Bruce Campbell , sthaug@nethelp.no, namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: 2010/6/28 Danny Mayer : > Please reread. Just about all Web sites use framesets to lay out the > pages and create menus etc. There is no additional requests involved. Respectfully, I'm going to bow out of this conversation. -- Colm From owner-namedroppers@ops.ietf.org Mon Jun 28 18:36:03 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EFFA3A684E; Mon, 28 Jun 2010 18:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3FFOGh1mw5x; Mon, 28 Jun 2010 18:36:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 578343A67D1; Mon, 28 Jun 2010 18:36:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTPda-000Mpb-Uu for namedroppers-data0@psg.com; Tue, 29 Jun 2010 01:29:23 +0000 Received: from [2001:4f8:0:2::2b] (helo=mx.pao1.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTPdY-000MoU-Ia for namedroppers@ops.ietf.org; Tue, 29 Jun 2010 01:29:20 +0000 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 1914CC9421; Tue, 29 Jun 2010 01:29:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 70196E601A; Tue, 29 Jun 2010 01:29:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id o5T1SvDF044544; Tue, 29 Jun 2010 11:28:57 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <201006290128.o5T1SvDF044544@drugs.dv.isc.org> To: Nicholas Weaver Cc: "Jeffrey A. Williams" , ?iso-8859-1?Q?Alfred_H=CEnes?= , namedroppers@ops.ietf.org From: Mark Andrews References: <10217833.1277759922522.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <086CEB99-5F30-4E0F-AC1E-C84B06154DAB@icsi.berkeley.edu> Subject: Re: claimed open relay [was: Re: [dnsext] RFC 5936 on DNS Zone Transfer Protocol (AXFR)] In-reply-to: Your message of "Mon, 28 Jun 2010 14:38:21 MST." <086CEB99-5F30-4E0F-AC1E-C84B06154DAB@icsi.berkeley.edu> Date: Tue, 29 Jun 2010 11:28:57 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: In message <086CEB99-5F30-4E0F-AC1E-C84B06154DAB@icsi.berkeley.edu>, Nicholas W eaver writes: > On Jun 28, 2010, at 2:18 PM, Jeffrey A. Williams wrote: > > > Alfred and all, > > > > Understood, but still closing up that open relay is in your and > > everyone elses best interests don't you think? >:) > > HU? > > dig www.google.com @tr-sys.de > > ; <<>> DiG 9.6.0-APPLE-P2 <<>> www.google.com @tr-sys.de > ;; global options: +cmd > ;; connection timed out; no servers could be reached > [gala:~/archive/svn_nweaver] nweaver%=20 > > > Also, frankly, with 3%+ of the residential NATs tested having open DNS > relays, who cares? A journey of a thousand miles starts with a single step. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-namedroppers@ops.ietf.org Mon Jun 28 19:49:22 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB2B73A6774; Mon, 28 Jun 2010 19:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9rh4XKy5J0J; Mon, 28 Jun 2010 19:49:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF4043A657C; Mon, 28 Jun 2010 19:49:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTQm2-00042H-0i for namedroppers-data0@psg.com; Tue, 29 Jun 2010 02:42:10 +0000 Received: from [74.125.82.52] (helo=mail-ww0-f52.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTQly-00041w-S1 for namedroppers@ops.ietf.org; Tue, 29 Jun 2010 02:42:07 +0000 Received: by wwb17 with SMTP id 17so1134888wwb.11 for ; Mon, 28 Jun 2010 19:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=cZ7In3j1+Mt1aIj+vSI4XiBRV/HD06frIaq1ysII3G8=; b=QByl07h6Xki4i+BCEn2i4qov53dcaUNlMENdkWRwXYXjOphGYDELiUkXZDeTOcEPTA bDV/hfREPmWhWarqQlonZmfMJr4s5OssJrFvmQqazhVulu/So63vmWDmSRvH1bo0Ral/ hnzyRFkVMNmuVprqV4lUuKFpGe0bhPTwyho10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=dtu+ccncaCrQuApZOg7G3Mt62p8hRz/YlRCfpxr87QYQfL0tSl9OxH45Vo4sjJUWCc rwJkJ4tDA5uitG5TEBcmjqgrdPElUgIAw9fk39+lFnEKFxWKtA22cMH9c3tPkrtqZkwm 89dVAYXt/uVej7P+aqPcohdGByiz25kfPDPTU= MIME-Version: 1.0 Received: by 10.216.154.76 with SMTP id g54mr8882133wek.36.1277779325186; Mon, 28 Jun 2010 19:42:05 -0700 (PDT) Received: by 10.216.85.4 with HTTP; Mon, 28 Jun 2010 19:42:05 -0700 (PDT) In-Reply-To: <33BE205400654B708840CBF6E0A3D5D8@local> References: <55156.1274856474@nsa.vix.com> <33BE205400654B708840CBF6E0A3D5D8@local> Date: Mon, 28 Jun 2010 22:42:05 -0400 Message-ID: Subject: Re: [dnsext] CNAME and NXDOMAIN From: Donald Eastlake To: namedroppers@ops.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I also agree that B is the best alternative and should be the mandatory behavior. Thanks, Donald On Tue, Jun 22, 2010 at 1:30 PM, George Barwood wrote: > It's my view that alternative 3.B is correct. > > =A0 =A0When an xNAME chain is followed, all but the last query cycle > =A0=A0 necessarily had no error. The RCODE in the ultimate DNS response M= UST > =A0=A0 BE set based on the final query cycle leading to that response. If > =A0=A0 the xNAME chain was terminated by an error, it will be that error > =A0=A0 code. If the xNAME chain terminated without error, it will be zero= . > > If the final query cycle gives rise to a NXDOMAIN, then there must be a > NXDOMAIN > NSEC proof in the response, and a validating resolver will check that thi= s > proof is correct. > > It=A0would be bizarre I think for the RCODE not to match the NSEC proof t= hat > is present. > > George > > ----- Original Message ----- > From: Donald Eastlake > To: namedroppers@ops.ietf.org > Sent: Tuesday, June 08, 2010 3:27 PM > Subject: Re: [dnsext] CNAME and NXDOMAIN > To help facilitate the resolution of this question I have written a draft= , > current version > http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02 > > From owner-namedroppers@ops.ietf.org Mon Jun 28 21:05:10 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5763A6804; Mon, 28 Jun 2010 21:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN8NPG-LKV7y; Mon, 28 Jun 2010 21:05:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C1D443A67FB; Mon, 28 Jun 2010 21:05:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTRzj-000BdS-PB for namedroppers-data0@psg.com; Tue, 29 Jun 2010 04:00:23 +0000 Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTRzh-000BcH-K4 for namedroppers@ops.ietf.org; Tue, 29 Jun 2010 04:00:21 +0000 Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 320C5A101E for ; Tue, 29 Jun 2010 04:00:20 +0000 (UTC) (envelope-from vixie@nsa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: claimed open relay [was: Re: [dnsext] RFC 5936 on DNS Zone Transfer Protocol (AXFR)] In-Reply-To: Your message of "Tue, 29 Jun 2010 11:28:57 +1000." <201006290128.o5T1SvDF044544@drugs.dv.isc.org> References: <10217833.1277759922522.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <086CEB99-5F30-4E0F-AC1E-C84B06154DAB@icsi.berkeley.edu> <201006290128.o5T1SvDF044544@drugs.dv.isc.org> X-Mailer: MH-E 8.1; nil; GNU Emacs 23.1.1 Date: Tue, 29 Jun 2010 04:00:20 +0000 Message-ID: <61270.1277784020@nsa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: > From: Mark Andrews > Date: Tue, 29 Jun 2010 11:28:57 +1000 > > > Also, frankly, with 3%+ of the residential NATs tested having open DNS > > relays, who cares? > > A journey of a thousand miles starts with a single step. +1. From dnsext-archive@ietf.org Tue Jun 29 01:36:42 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6173A6AB2 for ; Tue, 29 Jun 2010 01:36:42 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org VIAGRA \256 Official Site -80%\n X-Spam-Flag: NO X-Spam-Score: -21.941 X-Spam-Level: X-Spam-Status: No, score=-21.941 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SUBJECT_NEEDS_ENCODING=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdN4eBVKefEs for ; Tue, 29 Jun 2010 01:36:35 -0700 (PDT) Received: from costumeless-motive.volia.net (costumeless-motive.volia.net [77.123.96.197]) by core3.amsl.com (Postfix) with SMTP id DE8693A6981 for ; Tue, 29 Jun 2010 01:36:34 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org VIAGRA ® Official Site -80% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100629083634.DE8693A6981@core3.amsl.com> Date: Tue, 29 Jun 2010 01:36:34 -0700 (PDT)
Click here.

Dear dnsext-archive@ietf.org
From owner-namedroppers@ops.ietf.org Tue Jun 29 06:27:38 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCB743A6B93; Tue, 29 Jun 2010 06:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Llsx-Ep6EEGF; Tue, 29 Jun 2010 06:27:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D9F33A6A1D; Tue, 29 Jun 2010 06:27:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTajK-0005Vp-EI for namedroppers-data0@psg.com; Tue, 29 Jun 2010 13:20:02 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTajH-0005U7-RY for namedroppers@ops.ietf.org; Tue, 29 Jun 2010 13:20:00 +0000 Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN6PKUxAZnwN/2dsb2JhbACfO3GkRJpNAoJ1gi0E X-IronPort-AV: E=Sophos;i="4.53,505,1272844800"; d="scan'208";a="126762077" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 29 Jun 2010 13:19:58 +0000 Received: from [161.44.71.243] ([161.44.71.243]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5TDJwZk026520; Tue, 29 Jun 2010 13:19:58 GMT Message-ID: <4C29F2FE.50302@cisco.com> Date: Tue, 29 Jun 2010 09:19:58 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Donald Eastlake CC: namedroppers@ops.ietf.org Subject: Re: [dnsext] CNAME and NXDOMAIN References: <55156.1274856474@nsa.vix.com> <33BE205400654B708840CBF6E0A3D5D8@local> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: I think the I-D captures the alternatives correctly, and I agree that "B" is the best alternative, as well as being consistent with RFC 2308. -josh Donald Eastlake wrote: > I also agree that B is the best alternative and should be the > mandatory behavior. > > Thanks, > Donald > > On Tue, Jun 22, 2010 at 1:30 PM, George Barwood > wrote: > >> It's my view that alternative 3.B is correct. >> >> When an xNAME chain is followed, all but the last query cycle >> necessarily had no error. The RCODE in the ultimate DNS response MUST >> BE set based on the final query cycle leading to that response. If >> the xNAME chain was terminated by an error, it will be that error >> code. If the xNAME chain terminated without error, it will be zero. >> >> If the final query cycle gives rise to a NXDOMAIN, then there must be a >> NXDOMAIN >> NSEC proof in the response, and a validating resolver will check that this >> proof is correct. >> >> It would be bizarre I think for the RCODE not to match the NSEC proof that >> is present. >> >> George >> >> ----- Original Message ----- >> From: Donald Eastlake >> To: namedroppers@ops.ietf.org >> Sent: Tuesday, June 08, 2010 3:27 PM >> Subject: Re: [dnsext] CNAME and NXDOMAIN >> To help facilitate the resolution of this question I have written a draft, >> current version >> http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02 >> >> >> > > -- Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue Phone: +1 978-936-0001 Boxborough, MA 01719-2205 From dnsext-archive@ietf.org Wed Jun 30 05:57:30 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B835F3A6AB1 for ; Wed, 30 Jun 2010 05:57:30 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): Subject: ...-archive@ietf.org VIAGRA \256 Official Site -77%\n X-Spam-Flag: NO X-Spam-Score: -18.642 X-Spam-Level: X-Spam-Status: No, score=-18.642 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DRUGS_ERECTILE=1, DRUG_ED_CAPS=0.322, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SUBJECT_NEEDS_ENCODING=0.001, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vE+gej1IKTVt for ; Wed, 30 Jun 2010 05:57:23 -0700 (PDT) Received: from 7-135-93-178.pool.ukrtel.net (7-135-93-178.pool.ukrtel.net [178.93.135.7]) by core3.amsl.com (Postfix) with SMTP id 0ECAD3A6AA7 for ; Wed, 30 Jun 2010 05:57:22 -0700 (PDT) From: dnsext-archive@ietf.org To: dnsext-archive@ietf.org Subject: dnsext-archive@ietf.org VIAGRA ® Official Site -77% MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20100630125723.0ECAD3A6AA7@core3.amsl.com> Date: Wed, 30 Jun 2010 05:57:22 -0700 (PDT)
Click here.

Dear dnsext-archive@ietf.org
From owner-namedroppers@ops.ietf.org Wed Jun 30 07:52:05 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E345A3A685C; Wed, 30 Jun 2010 07:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.358 X-Spam-Level: ** X-Spam-Status: No, score=2.358 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9wFrJt4K4qn; Wed, 30 Jun 2010 07:52:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8A8E93A65A5; Wed, 30 Jun 2010 07:52:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTyW9-000FDR-6s for namedroppers-data0@psg.com; Wed, 30 Jun 2010 14:44:01 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTyW6-000FCt-MY for namedroppers@ops.ietf.org; Wed, 30 Jun 2010 14:43:58 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 53E5F1ECB41D; Wed, 30 Jun 2010 14:43:57 +0000 (UTC) Date: Wed, 30 Jun 2010 10:43:55 -0400 From: Andrew Sullivan To: "Jeffrey A. Williams" , namedroppers@ops.ietf.org Subject: Re: [dnsext] RFC 5936 on DNS Zone Transfer Protocol (AXFR) Message-ID: <20100630144355.GE9741@shinkuro.com> References: <26133709.1277757380997.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26133709.1277757380997.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Jeffrey, colleagues: On Mon, Jun 28, 2010 at 03:36:20PM -0500, Jeffrey A. Williams wrote: > All, > > Just as an aside note of interest, does everyone recognize that > TR-Sys.de refrenced below in the original message has an open relay? The contents of your post are completely off-topic for the namedroppers list. I have no clue why you thought it needed to be sent to your distribution list anyway. Don't do it again. Andrew (as namedroppers moderator). -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Jun 30 07:52:13 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E50943A685C; Wed, 30 Jun 2010 07:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.283 X-Spam-Level: ** X-Spam-Status: No, score=2.283 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTScHsLAihWw; Wed, 30 Jun 2010 07:52:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF1193A68F2; Wed, 30 Jun 2010 07:52:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTyZX-000Fp8-F1 for namedroppers-data0@psg.com; Wed, 30 Jun 2010 14:47:31 +0000 Received: from [208.86.224.201] (helo=mail.yitter.info) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OTyZU-000Fnh-US for namedroppers@ops.ietf.org; Wed, 30 Jun 2010 14:47:29 +0000 Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A74E41ECB41D for ; Wed, 30 Jun 2010 14:47:27 +0000 (UTC) Date: Wed, 30 Jun 2010 10:47:26 -0400 From: Andrew Sullivan To: namedroppers@ops.ietf.org Subject: Re: [dnsext] RFC 5936 on DNS Zone Transfer Protocol (AXFR) Message-ID: <20100630144725.GF9741@shinkuro.com> References: <20100628195550.A62D9E06B2@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100628195550.A62D9E06B2@rfc-editor.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Dear colleagues, On Mon, Jun 28, 2010 at 12:55:50PM -0700, rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 5936 > > Title: DNS Zone Transfer Protocol (AXFR) > Author: E. Lewis, A. Hoenes, Ed. > Status: Standards Track > Stream: IETF > Date: June 2010 > Mailbox: ed.lewis@neustar.biz, > ah@TR-Sys.de > Pages: 29 > Characters: 66337 > Updates: RFC1034, RFC1035 > > I-D Tag: draft-ietf-dnsext-axfr-clarify-14.txt > > URL: http://www.rfc-editor.org/rfc/rfc5936.txt Apologies for not having got to this sooner -- I was occupied for the last two days. In any case, I want to acknowledge the publication as an RFC of this draft, which has been a working group item for a very long time. I especially want to note the contributions of Ed and Alfred, who worked hard to get this out the door, and of Andreas Gustafsson, who held the pen previously. Thanks all! Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From owner-namedroppers@ops.ietf.org Wed Jun 30 11:23:01 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767513A6AD5; Wed, 30 Jun 2010 11:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.747 X-Spam-Level: X-Spam-Status: No, score=-95.747 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFDAe86v8B0f; Wed, 30 Jun 2010 11:23:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7816F3A6921; Wed, 30 Jun 2010 11:23:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OU1qm-000OFS-RN for namedroppers-data0@psg.com; Wed, 30 Jun 2010 18:17:33 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OU1qi-000OEd-Cr for namedroppers@ops.ietf.org; Wed, 30 Jun 2010 18:17:29 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA055681782; Wed, 30 Jun 2010 20:16:22 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA26126; Wed, 30 Jun 2010 20:16:21 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201006301816.UAA26126@TR-Sys.de> Subject: [dnsext] New Version Notification - draft-gudmundsson-dnsext-srv-clarify-01.txt (fwd) To: namedroppers@ops.ietf.org, dnsop@ietf.org, apps-discuss@ietf.org Date: Wed, 30 Jun 2010 20:16:20 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: My apologies for cross-posting, but this is inherently a cross-wg and cross-area topic: The revised draft contains clarifications for DNS service discovery using SRV RRs and suggests methods to deal with the restrictions imposed by draft-ietf-tsvwg-iana-ports. It is intended that both drafts will eventually be published in a coordinated manner. Abstract The DNS SRV record has been specified in RFC 2052 and RFC 2782 for use in dynamic service discovery for a domain. These two RFCs did not clearly specify an IANA registry for the names of the services and their underlying protocols. This document clarifies RFC 2782 regarding the formation and use of the Service Prefix in the owner name of SRV records, based on the unified IANA registry for "Service Names and Transport Protocol Port Numbers". Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ ----- Forwarded message from Internet-Draft@ietf.org ----- > From: Internet-Draft@ietf.org > Message-Id: <20100630180001.DEC133A6A84@core3.amsl.com> > Date: Wed, 30 Jun 2010 11:00:01 -0700 (PDT) > Subject: New Version Notification - > draft-gudmundsson-dnsext-srv-clarify-01.txt > New version (-01) has been submitted for > draft-gudmundsson-dnsext-srv-clarify-01.txt. > > http://www.ietf.org/internet-drafts/draft-gudmundsson-dnsext-srv-clarify-01.txt > > > Diff from previous version: > http://tools.ietf.org/rfcdiff?url2=draft-gudmundsson-dnsext-srv-clarify-01 > > IETF Secretariat. > ----- End of forwarded message from Internet-Draft@ietf.org ----- From owner-namedroppers@ops.ietf.org Wed Jun 30 13:14:19 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED4D28C114; Wed, 30 Jun 2010 13:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.464 X-Spam-Level: X-Spam-Status: No, score=-94.464 tagged_above=-999 required=5 tests=[AWL=-1.314, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCFb2QNQPoxe; Wed, 30 Jun 2010 13:14:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8AA0C28C107; Wed, 30 Jun 2010 13:14:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OU3ZX-000Baw-GO for namedroppers-data0@psg.com; Wed, 30 Jun 2010 20:07:51 +0000 Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OU3ZT-000BaT-Mc for namedroppers@ops.ietf.org; Wed, 30 Jun 2010 20:07:48 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA056088378; Wed, 30 Jun 2010 22:06:18 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA26281; Wed, 30 Jun 2010 22:06:16 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201006302006.WAA26281@TR-Sys.de> Subject: [dnsext] Re: [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 To: touch@isi.edu Date: Wed, 30 Jun 2010 22:06:16 +0200 (MESZ) Cc: namedroppers@ops.ietf.org, apps-discuss@ietf.org, tsvwg@ietf.org, draft-ietf-tsvwg-iana-ports@tools.IETF.ORG In-Reply-To: <4C2B9097.4060009@isi.edu> from Joe Touch at Jun "30," 2010 "11:44:39" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: Joe Touch wrote: > Hi, Alfred, > > Alfred H=CEnes wrote: > ... >> Please do not neglect the criticism spelled out repeatedly for >> draft-ietf-tsvwg-iana-ports but rejected by your team. This >> draft tries to accommodate the restrictions imposed by that memo. >> Yet, to be useful for aligning previous RFCs now deemed non- >> conformant with these rules and recent/ongoing work specifically >> calling for multi-label hierarchical Service Prefixes, this >> draft needs to show a uniform path that can be recommended >> to the authors / WGs where these RFCs are originating from. >> >> Thus, as a replacement mechanism for specifications using >> Service Prefixes with non-transport protocol Protocol Labels >> and/or more than two labels, the non-normative extension >> mechanism proposed is an essential part of this memo. >> >> Unless the restrictions imposed by draft-ietf-tsvwg-iana-ports >> on the lenght of Service Names and the one-service-name-per- >> application rule are being relaxed substantially, this extension >> mechanism will remain in this document. > > I don't understand this position. Sec 5 of that doc allows aliases. > The only constraint is that one be designated primary so that > reverse lookups can determine when aliasing occurs. Sorry Joe, the quote above is the summary I had prepended to my detailed response. You have silently cut off the pointer to in-depth inline responses. Do I have to conclude that you pushed out a response without having read either the details of my response nor the new draft version? I have no idea what reverse lookup has to do with the topic. RFC 2782 calls for a "primary" *service name* in the Service Label of an SRV RR. If the new registry does not contain this important tag to distinguish the primary service name from the aliases (if present) -- as we had requested repeatedly --, it cannot be used as a reasonable guide for users and admins. It looks like you once more deliberately mangle the "alias" topic with the "one-service-name-per-application" rule in your draft that recommends against assigning multiple service names to the instances of a particular service offered over different intermediate "substrate" layers (for instance HTTP, SIP, XMPP, etc.) or employing different security services. This all is discussed in detail in various sections of our draft -- interestingly just in those that you once have suggested to drop. Please read these sections; you might have skipped text prematurely. > > draft-ietf-tsvwg-iana-ports is updating the length of service names. > Having this document concurrently undermine that update, especially > in a "non-normative" appendix seems inconsistent at best. Don't bend facts, please. We accept the back-cutting of the maximum lenght for *service names* from 40 chars (RFC 952) to 15 chars (tsvwg-iana-ports). This has nothing to do with the canonical limit for DNS labels (63 char), but the latter gives room for extensions to service labels -- iff the related specification explicitly wants to do that. We purposely suggest to construct extended service labels in a manner that does not conflict with the definition of service names and the related restrictions in your draft, and that allows instantaneous recognition of the basic service name used to construct the service label. You still neglect the presence of RFCs 4386, 3921, 5026, 5509 et al. These are IETF specifications for service prefixes not conforming to the rules you want and the rules we have accepted to inforce in our draft for standard service prefixes. Unless you point out a workable solution of your own for a sensical revision of the various service prefixes defined in Standards Track RFCs like _im._sip, _pres.xmpp or _pkixrep._ocsp, you should stop to argue against our offered extended prefix system. The same document that accepts your restrictions needs to offer a solution. We are not protocol gods saying just *no* (as you apparently want) and now declaring a "sin" documents once approved by the IESG. When we introduce restrictions (negotiated as a compromise with you), we want to present a workaround as well, as an offer to document authors that want to revise affected RFCs (and other specifications) now becoming non-conformant, an offer that *can* be adopted on a case-by-case (per application spec) scenario. This offer is an integral part of our acceptance of the restrictions you want to impose. > > I'd expect that a substantive change to the specification of SRV > names - i.e., introducing a hierarchical namespace - would require > a standards-track document whose main body focused on the changes > proposed, and that they need to be coordinated with > draft-ietf-tsvwg-iana-ports. Please answer the related question I have posed in my response: Are you willing to make a *useful* alternate proposal or to refer normatively in tsvwg-iana-ports to such additional document, such that it is ascertained that the new restrictions will not be published without coordinated publication of a document showing a way out of the dilemma for several existing Standards Track RFCs? Or do you now intend to Obsolete with tsvwg-iana-ports all the RFCs once listed in draft-gudmundsson-dns-srv-iana-registry as references for service prefixes to be considered non-conformant in the future -- as per the agreement in Hiroshima? I strongly suspect that you will run into trouble in the IESG with such intent. > > Can you clarify? > > Joe I think my detailed responses and the revised draft submitted today (draft-gudmundsson-dnsext-srv-clarify-01) should contain enough clarification. Please read on. Due to time constraints (business needs and short vacation before IETF), I'll become unavailable for email discussion soon, and therefore I suggest that we discuss the topic in Maastricht. Kind regards, Alfred. From owner-namedroppers@ops.ietf.org Wed Jun 30 16:02:05 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0203A692E; Wed, 30 Jun 2010 16:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozZB64pWgyLP; Wed, 30 Jun 2010 16:02:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 51C373A6816; Wed, 30 Jun 2010 16:02:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OU6Cv-00046P-0e for namedroppers-data0@psg.com; Wed, 30 Jun 2010 22:56:41 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OU6Cr-000465-TQ for namedroppers@ops.ietf.org; Wed, 30 Jun 2010 22:56:38 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5UMuaN5021750 for ; Wed, 30 Jun 2010 18:56:36 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o5UMuaEe021749 for namedroppers@ops.ietf.org; Wed, 30 Jun 2010 18:56:36 -0400 (EDT) (envelope-from namedroppers) Received: from [128.9.64.64] (helo=vapor.isi.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OU2Ju-0001eC-1J for namedroppers@ops.ietf.org; Wed, 30 Jun 2010 18:47:38 +0000 Received: from [75.212.107.9] (9.sub-75-212-107.myvzw.com [75.212.107.9]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o5UIidLH022615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jun 2010 11:44:50 -0700 (PDT) Message-ID: <4C2B9097.4060009@isi.edu> Date: Wed, 30 Jun 2010 11:44:39 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Alfred_=3F?= CC: namedroppers@ops.ietf.org, apps-discuss@ietf.org, tsvwg@ietf.org, draft-ietf-tsvwg-iana-ports@tools.IETF.ORG Subject: [dnsext] Re: [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 References: <201006301801.UAA26017@TR-Sys.de> In-Reply-To: <201006301801.UAA26017@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig11C26585775D6B3276946C7B" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig11C26585775D6B3276946C7B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Alfred, Alfred ? wrote: =2E.. > Please do not neglect the criticism spelled out repeatedly for > draft-ietf-tsvwg-iana-ports but rejected by your team. This > draft tries to accommodate the restrictions imposed by that memo. > Yet, to be useful for aligning previous RFCs now deemed non- > conformant with these rules and recent/ongoing work specifically > calling for multi-label hierarchical Service Prefixes, this > draft needs to show a uniform path that can be recommended > to the authors / WGs where these RFCs are originating from. >=20 > Thus, as a replacement mechanism for specifications using > Service Prefixes with non-transport protocol Protocol Labels > and/or more than two labels, the non-normative extension > mechanism proposed is an essential part of this memo. >=20 > Unless the restrictions imposed by draft-ietf-tsvwg-iana-ports > on the lenght of Service Names and the one-servie-name-per- > application rule are being relaxed substantially, this extension > mechanism will remain in this document. I don't understand this position. Sec 5 of that doc allows aliases. The o= nly constraint is that one be designated primary so that reverse lookups can determine when aliasing occurs. draft-ietf-tsvwg-iana-ports is updating the length of service names. Havi= ng this document concurrently undermine that update, especially in a "non-normati= ve" appendix seems inconsistent at best. I'd expect that a substantive change to the specification of SRV names - = i.e., introducing a hierarchical namespace - would require a standards-track do= cument whose main body focused on the changes proposed, and that they need to be= coordinated with draft-ietf-tsvwg-iana-ports. Can you clarify? Joe --------------enig11C26585775D6B3276946C7B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwrkJcACgkQE5f5cImnZrsQAgCgjZzZyltk1ACWtltxbYPW2xX5 y34AnAoVdL+G3tDzkAM6FUAWHgvI3ZfB =3qtd -----END PGP SIGNATURE----- --------------enig11C26585775D6B3276946C7B-- From owner-namedroppers@ops.ietf.org Wed Jun 30 16:02:10 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6039E3A6816; Wed, 30 Jun 2010 16:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.867 X-Spam-Level: X-Spam-Status: No, score=-0.867 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq7ybER37s6r; Wed, 30 Jun 2010 16:02:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C17493A68CF; Wed, 30 Jun 2010 16:02:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OU6D8-00047D-R4 for namedroppers-data0@psg.com; Wed, 30 Jun 2010 22:56:54 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OU6D5-000470-8R for namedroppers@ops.ietf.org; Wed, 30 Jun 2010 22:56:51 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5UMunFp021760 for ; Wed, 30 Jun 2010 18:56:49 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o5UMun6B021759 for namedroppers@ops.ietf.org; Wed, 30 Jun 2010 18:56:49 -0400 (EDT) (envelope-from namedroppers) Received: from [128.9.64.64] (helo=vapor.isi.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OU5Lu-000Oye-LM for namedroppers@ops.ietf.org; Wed, 30 Jun 2010 22:01:54 +0000 Received: from [75.212.107.9] (9.sub-75-212-107.myvzw.com [75.212.107.9]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o5UM1CIT008132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jun 2010 15:01:22 -0700 (PDT) Message-ID: <4C2BBEA8.6070904@isi.edu> Date: Wed, 30 Jun 2010 15:01:12 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= CC: namedroppers@ops.ietf.org, apps-discuss@ietf.org, tsvwg@ietf.org, draft-ietf-tsvwg-iana-ports@tools.IETF.ORG Subject: [dnsext] Re: [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 References: <201006302006.WAA26281@TR-Sys.de> In-Reply-To: <201006302006.WAA26281@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF73847D2795F0A1F115B1358" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF73847D2795F0A1F115B1358 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alfred, Alfred =EF=BF=BD wrote: > Joe Touch wrote: >=20 >> Hi, Alfred, >> >> Alfred H=EF=BF=BDnes wrote: >> ... >>> Please do not neglect the criticism spelled out repeatedly for >>> draft-ietf-tsvwg-iana-ports but rejected by your team. This >>> draft tries to accommodate the restrictions imposed by that memo. >>> Yet, to be useful for aligning previous RFCs now deemed non- >>> conformant with these rules and recent/ongoing work specifically >>> calling for multi-label hierarchical Service Prefixes, this >>> draft needs to show a uniform path that can be recommended >>> to the authors / WGs where these RFCs are originating from. >>> >>> Thus, as a replacement mechanism for specifications using >>> Service Prefixes with non-transport protocol Protocol Labels >>> and/or more than two labels, the non-normative extension >>> mechanism proposed is an essential part of this memo. >>> >>> Unless the restrictions imposed by draft-ietf-tsvwg-iana-ports >>> on the lenght of Service Names and the one-service-name-per- >>> application rule are being relaxed substantially, this extension >>> mechanism will remain in this document. >> I don't understand this position. Sec 5 of that doc allows aliases. >> The only constraint is that one be designated primary so that >> reverse lookups can determine when aliasing occurs. >=20 > Sorry Joe, > the quote above is the summary I had prepended to my detailed response.= > You have silently cut off the pointer to in-depth inline responses. That is because I am addressing the summary. If the summary does not accu= rately portray the remainder of the contents, you should address that. > I have no idea what reverse lookup has to do with the topic. > RFC 2782 calls for a "primary" *service name* in the Service Label > of an SRV RR. If the new registry does not contain this important > tag to distinguish the primary service name from the aliases (if > present) -- as we had requested repeatedly --, it cannot be used > as a reasonable guide for users and admins. The IANA draft already indicates that one name needs to be assigned as pr= imary (from Sec 5): ... In such cases, one of the service names SHOULD be designated primary, for use with mechanisms such as DNS SRV Records [RFC2782], and the others SHOULD be designated as aliases of the primary service name... > It looks like you once more deliberately mangle the "alias" topic > with the "one-service-name-per-application" rule in your draft > that recommends against assigning multiple service names to the > instances of a particular service offered over different intermediate > "substrate" layers (for instance HTTP, SIP, XMPP, etc.) or employing > different security services.=20 Draft-ietf-tsvwg-iana-ports states that: o IANA will allocate only one assigned port number for all versions of a service (e.g., running the service with or without a security mechanism, or for updated variants of a service) Versions means version 1, version 2, etc. This is to avoid allocating dif= ferent ports as was done with HTTP and HTTPS, esp. since TLS allows the negotiat= ion of optional security, where the goal is to allocate the secure version of th= e protocol and allow that protocol to negotiate when and whether security i= s required. The goal is to avoid allocating new ports where the service sho= uld be capable of negotiating in-band. However, it is currently common practice to allocate different ports for different "stacks", e.g., X over HTTP, X over SOAP - i.e., where such negotiation in-band is not possible. Layering info is included in the nam= e when multiple such requests are received concurrently, but not when a single r= equest is received (e.g., a control protocol that happens to use XML over HTTP d= oes not necessarily include either in the short name). In summary, what part of draft-ietf-tsvwg-iana-ports are you disagreeing = with? Also, with specific reference to your 01 doc, can you clarify whether it = is consistent with draft-ietf-tsvwg-iana-ports on the following point?: ...Any system that includes a service name inside a longer string is itself responsible for delineating the service name. Such systems MUST NOT rely on the syntax of a service name alone for such delineation. FWIW, this is the part where I think draft-ietf-tsvwg-iana-ports and your= draft disagree, as well as our section 5.2. > You still neglect the presence of RFCs 4386, 3921, 5026, 5509 et al. > These are IETF specifications for service prefixes not conforming > to the rules you want and the rules we have accepted to inforce > in our draft for standard service prefixes. > Unless you point out a workable solution of your own for a sensical > revision of the various service prefixes defined in Standards Track > RFCs like _im._sip, _pres.xmpp or _pkixrep._ocsp, you should stop > to argue against our offered extended prefix system. =46rom RFC 2782: Proto The symbolic name of the desired protocol, with an underscore (_) prepended to prevent collisions with DNS labels that occur in nature. _TCP and _UDP are at present the most useful values for this field, though any name defined by Assigned Numbers or locally may be used (as for Service). The Proto is case insensitive. "xmpp" is does not have an Assigned Number, and is not being used 'locall= y', and was never registered with the SRV registry either. Yes, there appear to b= e a few other uses of SRV records other than for the kind of services indicated i= n the IANA ports tale or the SRV registry. It would be worthwhile indicating those exceptions, but AFAICT they are u= ses of DNS SRV records for discovery of capabilities outside the scope of the iana-ports document (i.e., NOT referring to "L7-L5 service stacks over a transport protocol", for lack of a better description). >> I'd expect that a substantive change to the specification of SRV >> names - i.e., introducing a hierarchical namespace - would require >> a standards-track document whose main body focused on the changes >> proposed, and that they need to be coordinated with >> draft-ietf-tsvwg-iana-ports. >=20 > Please answer the related question I have posed in my response: > Are you willing to make a *useful* alternate proposal or to refer > normatively in tsvwg-iana-ports to such additional document, > such that it is ascertained that the new restrictions will not > be published without coordinated publication of a document > showing a way out of the dilemma for several existing Standards > Track RFCs? If you want to propose an alternate structure, e.g., using either a diffe= rent record type, or somehow can be recognized as not supporting the current u= se (without *internal* parsing of the service name), then that might be a wa= y forward. Joe --------------enigF73847D2795F0A1F115B1358 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwrvqgACgkQE5f5cImnZrtAqACg9MbZI44zUypCnWIaq/WPtBFy flAAoIfln/vbgdiREuZpaFA0Oo8fO462 =ryai -----END PGP SIGNATURE----- --------------enigF73847D2795F0A1F115B1358-- From owner-namedroppers@ops.ietf.org Wed Jun 30 16:02:46 2010 Return-Path: X-Original-To: ietfarch-dnsext-archive@core3.amsl.com Delivered-To: ietfarch-dnsext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8613A692E; Wed, 30 Jun 2010 16:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.385 X-Spam-Level: X-Spam-Status: No, score=-94.385 tagged_above=-999 required=5 tests=[AWL=-1.190, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_53=0.6, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fpx18AEcMaIq; Wed, 30 Jun 2010 16:02:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3ADB13A68CF; Wed, 30 Jun 2010 16:02:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OU6Ca-00045Y-Gs for namedroppers-data0@psg.com; Wed, 30 Jun 2010 22:56:20 +0000 Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OU6CS-00042x-JS for namedroppers@ops.ietf.org; Wed, 30 Jun 2010 22:56:14 +0000 Received: from stora.ogud.com (localhost [127.0.0.1]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5UMu6j0021739 for ; Wed, 30 Jun 2010 18:56:06 -0400 (EDT) (envelope-from namedroppers@stora.ogud.com) Received: (from namedroppers@localhost) by stora.ogud.com (8.14.4/8.14.4/Submit) id o5UMu6X1021738 for namedroppers@ops.ietf.org; Wed, 30 Jun 2010 18:56:06 -0400 (EDT) (envelope-from namedroppers) Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OU1dP-000MSV-Q9 for namedroppers@ops.ietf.org; Wed, 30 Jun 2010 18:03:46 +0000 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA055580922; Wed, 30 Jun 2010 20:02:02 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA26017; Wed, 30 Jun 2010 20:01:51 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201006301801.UAA26017@TR-Sys.de> Subject: [dnsext] Re: [port-srv-reg] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-00 To: touch@ISI.EDU Date: Wed, 30 Jun 2010 20:01:51 +0200 (MESZ) Cc: namedroppers@ops.ietf.org, apps-discuss@ietf.org, tsvwg@ietf.org, draft-ietf-tsvwg-iana-ports@tools.IETF.ORG In-Reply-To: <4B6DF12D.9070808@isi.edu> from Joe Touch at Feb "6," 2010 "02:46:05" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk List-ID: List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body. List-Archive: At Sat, 06 Feb 2010 14:46:05 -0800, Joe Touch wrote: > > Hi, all, > > I completely agree with the abstract and the first bullet of section > 1.1, and section 1.2 EXCEPT in proposing the extension (appendix A). > > I don't think adding an extension "clarifies"; this doc ought to focus > on the clarification issue, and would be useful if doing so. > > Specific comments below, though IMO the structural issues are worth > addressing *before* the specific comments indicated. > > Joe Joe and all, my apologies for the delayed response. Thanks to Joe for the detailed comments. Summary response (please see more inline below): Please do not neglect the criticism spelled out repeatedly for draft-ietf-tsvwg-iana-ports but rejected by your team. This draft tries to accommodate the restrictions imposed by that memo. Yet, to be useful for aligning previous RFCs now deemed non- conformant with these rules and recent/ongoing work specifically calling for multi-label hierarchical Service Prefixes, this draft needs to show a uniform path that can be recommended to the authors / WGs where these RFCs are originating from. Thus, as a replacement mechanism for specifications using Service Prefixes with non-transport protocol Protocol Labels and/or more than two labels, the non-normative extension mechanism proposed is an essential part of this memo. Unless the restrictions imposed by draft-ietf-tsvwg-iana-ports on the lenght of Service Names and the one-servie-name-per- application rule are being relaxed substantially, this extension mechanism will remain in this document. NOTE: A slightly revised update to draft-gudmundsson-dnsext-srv-clarify has just been submitted: draft-gudmundsson-dnsext-srv-clarify-01. Due to time constraints, this version however does not yet contain all the edits planned. >> ... >> >> 1.1. Problem Statement >> >> RFC 2782 says that the source of names for "Service" and "Proto" is >> "Assigned Numbers" (STD2) or a locally defined repository. >> >> However, upon reflection, both alternatives do not seem to make >> particular sense: >> >> o The STD2 series of documents was obsoleted by RFC 3232 [RFC3232] >> and IANA registration publication was handed over to on-line >> registries maintained by IANA. Unfortunately it is not explicitly >> explained in RFC 2782 which section of STD2 it is referring to, >> nor does RFC 3232 help. By common knowledge, RFC 2782 referred to >> the Keyword columns of the "Protocol Numbers" and "Port Numbers" >> IANA registries, respectively. >> >> As SRV records contain the port where each server provides the >> service, the outmost utility of SRV RRs is for services that do >> not have a registered port number. > > or where they are provided on ports other than the registered one. The draft says "outmost utility" for this specific case. For brevity in this part of the introduction, not all "important" use cases are listed. >> Also, the number of ports >> available is small compared to the possible number of service >> names that could be registered. Therefore, the "Port Number" >> registry needs a more strict registration policy and is not the >> proper place for registering service names for use with SRV >> resource records. > > This implies that service names with assigned ports would not be used > with SRVs; this is not required by the SRV spec. It also implies that > SRV names are somehow independent of the port number registry, but the > IANA ports doc ID formalizes the unification of these two namespaces. Please note that this historical perspective is presenting the "state of the art" after publication of RFC 2782 and *before* the current effort with this memo and tsvwg-iana-ports. Thus, it refers to the pre-RFC 3232 situation and its evolution by current practice in the past. Will be clarified in the leading text above the bullets. >> o Having locally defined lists of service and/or protocol names >> would equally allow to list the full service information in such >> local databases and thus make the usage of SRV records redundant. > > This language is awkward, and the logic is backwards. It's like saying > "you don't need the DNS because you can have hosts.txt". SRV can replace > /etc/services (with the appropriate changes to standards); the converse > is not true, so "equal" may be misleading. Again, these bullets describe the consequences of literally following RFC 2782 text. Thus, it is correct that "locally defined lists" of service and/or protocol names (which indeed would be similar in content to the "/etc/services" and "/etc/protocols" POSIX database files) would "equally allow to list the full service information". If such local lists (as suggested by RFC 2782) could contain all the information contained in the SRV RDATA as well, they indeed would -- at first glance, and for local users -- make "SRV records redundant". >> In any case, this scenario is not applicable for publicly >> available services where potential clients are not under the >> control of the authority offering the services, and hence most >> probably would have no access to the proper "locally provided" >> information. The reader is reminded that locally maintained >> database solutions generally scale very poorly, and that this once >> was the major momentum for the deployment of the Domain Name > replace 'momentum' with 'impetus' (or motivation?) >> System. > > As above, confusing and may need rewording. I'm not sure what you're > primary point is. The primary point is to show that literally following the idea spelled out in RFC 2782, to have service and/or protocol names listed in a local repository, would be a step backward. >> 1.2. Objective for this Document and its Companions > > I completely agree with this section, but subsequent sections diverge > from this objective IMO. > > ... >> 2. General Considerations for SRV Service Prefixes >> >> SRV Service Prefixes SHOULD consist of exactly two labels. > > When do they not? Is it even possible they do not? Of course, some documents describe such use cases for SRV. We are not the Internet police and do not want to obsolete prior art, nor interfere with work in progress in various WGs. Thus, it does not make sense to impose a "MUST" on human behavior that connot be controlled. If a WG insists on using hierarchical, multi-label Service Prefixes for a specific application (as it e.g. currently is discusssed seriously for mass storage access protocols), we cannot enforce the two-label rule with this document. Pretending otherwise would IMO be foolish. > >> If the specification of a particular application/service indicates >> that this service is to be provided at a specific registered port >> number and does not mention DNS SRV based service discovery, >> prospective clients SHOULD NOT assume the existence of SRV records > > I'd go with "MUST NOT" assume (isn't that in the SRV spec?) Again, implementation practice can diverge from written specifications. So, although the specs of an application do not mention the use of SRV records, implementation and deployment practice may have evolved to actually make use of them where they are available. In particular, a revised specification could be in progress. That would be reasons for escaping the "SHOULD NOT", isn't it? Therefore, "MUST NOT" would not make sense and could not be enforced. The "SHOULD NOT" above is rephrased literally from the "Applicability Statement" on page 2 of RFC 2782. > >> for this application, unless the client has hints available that >> indicate otherwise -- for instance by means of configuration. In >> this case, only the rules of Sections 3 and 4 apply. > > No need for the rest of the sentence (unless...); in that case, there is > no assumption. A good "SHOULD NOT" needs to indicate what the possible exceptional cases are. Therefore, the "unless ..." clause is appropriate. The last sentence is necessary as well, because we want the rules in Sections 3 and 4 act as the "default specification" in such case; and other parts of your comment indicate that you also prefer these rules in favor of ad-hoc rules specific to such application or implementation. >> ... >> > > ******** > > From here down (see trailing ********, i.e., all of the rest of section > 3), the discussion diverges from the main point of this doc, and > introduces a new concept of layered services. That may be a useful > concept to explore, but belongs in a separate document, and IMO is > premature. This concept is neither new nor introduced by this draft. It can be found in various RFCs and other documents -- please refer to the expired draft-gudmundsson-dns-srv-iana-registry for a list of related RFCs (look for "overlay protocols"). In Hiroshima it has been decided that using the Protocol Label to indicate layered services is not the way to go, and we have agreed to this point of view because otherwise the port number in such SRV RDATA would be ambiguous or meaningless. Therefore, when saying "no no!" and thus "closing a road", we regard it as a duty to the community to point out an alternative road leading to such goals. >> Some services can be carried equivalently in different encapsulations >> using higher-level "substrate" protocols like HTTP, BEEP, SOAP, SIP, >> XMPP, some of which in turn can be carried over different transport >> protocols. In this case, it is possible that certain servers for an >> application only support specific protocol stacks, or that a Service >> Domain provides a different set of servers for each protocol stack. >> Consequently, there occasionally is a need to specify such details in >> the SRV Service Prefix. Since the Protocol Label is intentionally >> restricted (Section 3), this information has to be carried in the >> Service Label for this application. > > Interesting idea, but currently SRVs and port numbers are assigned to > the entirety of layers 5-7 (and any shims therein). > > This proposes a completely new structure for services that should be > considered as a separate issue, and IMO is far too premature to consider > for deployment. That's part of the problem to be solved. We admit these rules and present a method to maintain the restrictions on Service Names, by suggesting a syntax that unambiguously allows to recover the Service Name from the Service Label, by using a separator character not allowed in Service Names. Again, we believe that a document that essentially makes other work non-conformant after the fact would be ill-advised if not presenting one or more alternate solutions. > >> There are two possibilities to achieve this goal: >> >> a. If there is only a small number of "substrate" protocols to >> distinguish, it is RECOMMENDED that the application designers >> register multiple Service Names with IANA in the "Service Names >> and Port Numbers" registry [RFCyyyy], which usually will start >> with the same characters and contain a suffix attached with a >> hyphen embedded in the name. > > The 15-char limit doesn't support this option. ... The 15-char limit is artificial; the legacy IANA registry for Protocols and Well-Known Services (for the DNS WKS RR) had a 40-char limit. > ... There are far too many > current names that do not have this sort of syntax. There are some service names following this model, and there are very few existing service names using the hyphen for other purposes. Thus it looks like that idea is not new and already adopted by various communities. > > Finally, any structure in the service layering should be supported in > the SRV system, not in the syntax of the namespace. But that's another way that you are opposing to. Any changes to the SRV RDATA format would make it a new RR type. Further, the IAB "Design Choices When Expanding the DNS" document (RFC 5507) strongly recommends against selectors embedded within the RDATA of new DNS RRs; you apparently are advocating to the contrary. Example: A mass storage application looking for a read/write instance of a network based file system over a particular kind of secure channel should not have to deal with the bulk of SRV RRs for read-only copies of the same file system or those only supporting another security layer, and vice versa. This can easily be accommodated by the naming scheme, but not by embedded selectors. > >> One disadvantage of this solution is the length limitation >> imposed on the Service Name by [RFCyyyy] (15 characters, see >> Section 4). Also, [RFCyyyy] recommends that -- notwithstanding >> some very popular, and mostly legacy cases -- each service ought >> to be represented by a *single* Service Name. If the service is >> the same and only the substrate used is different, this solution >> arguably is in conflict with [RFCyyyy]. >> >> b. If the number of substrate stacks to be supported is larger, or >> if the 'canonical' labels that the application designers prefer >> would result in exceeding the maximum length of Service Names, or >> if multi-layer substrates shall be represented, or if the "unique >> Service Name per service" argument is deemed important, an >> extension scheme is needed for the construction of Service Labels >> for such exceptional services. > > This goes outside the scope of the IANA ports doc; service names are 15 > chars in that doc, and that doc doesn't address extension services. This > is premature. We now accept the 15-char limitation in the IANA ports doc, and we do not expect it to support sub-layer information. We also support the deprecation of non-transport protocol names in the Protocol Labels. Therefore, have to (at least) indicate a method pointing forward for the specifications affected by these restrictions. The method specified in the Appendix is non-normative, but it is intended to guide authors of replacement specifications for the affected applications as well as developers of ne application specifications that want to incorporate it and normatively fill in the details in a manner suitable for their context. > >> The non-normative Appendix A proposes a scheme for extended >> Service Labels that does not pollute the namespace of Service >> Names and hence adheres to the uniqueness and collision-freeness >> requirements of [RFCyyyy]. The basic Service Name can be easily >> extracted from these extended Service Labels, as they employ a >> separator character not allowed in Service Names to attach >> qualifier(s) to a 'basic' Service Label as specified in >> Section 4. >> >> Application designers who want to make use of that scheme MUST >> independently and unambiguously specify the application of that >> scheme for their service and ensure that a reference to the >> document containing this specification (if different from the >> document specifying the basic service) is added to the entry for >> that service in the "Service Names and Port Numbers" IANA >> registry, following the registration procedures of [RFCyyyy]. >> >> To re-iterate, absent such explicit, registered specification, >> the rules of Section 4 (and, of course, Section 3 as well) still >> apply in these cases. >> >> Application protocol designers ought to keep service discovery >> simple. The fewer alternatives a prospective client has to consider >> and the fewer choices he has to find suitable SRV records, the faster >> the service discovery can be performed, because it needs fewer DNS >> queries on average and thus incurs less latency. If alternative >> transports and/or variations of the service are really needed to be >> distinguished by service discovery, to foster interoperablity there >> SHOULD always be defined a default version supported by all clients >> and servers, and configured in the DNS, thus allowing an orderly >> fallback in case client preferences cannot be accommodated. > > Fallback is a property of a protocol; each service has different > requirements for such backward compatibility. Fallback rules are also common elements in service discovery procedures. (Recall the MX to A RR fallback for [E]SMTP!) > If such a default or > fallback is assumed, then the SRV system should have a flag indicating > that. The fallback rule has to deal with the lack of specific DNS RRs. (There are lots of reasons, ranging from inappropriate provisioning systems and business rules down to human error.) It does not make sense to expect the information on what to do in the absence of DNS records being stored in such records! > Port numbers are not intended to have any hierarchy or alternates > of services, so such a fallback is not appropriate to indicate there. The IANA registered port numbers have always been the default port numbers for a particular service; users/deployments have always been free to use alternate ports. For instance the URI standard explicitly specifies that the absence of a port number in a URI (of a scheme supporting host names and port numbers) is to be interpreted as an indication of the default port number as registered at IANA. Why should SRV usage introduce a different model? > (each service group can do this, but it's not realistic to write a > SHOULD unless you know when it is violated and can enforce it; there's > no requirement to explain when protocols are grouped or have defaults, > so requiring application designers to do this begs the question of how). Is a strong call for simplicity and specification of a working default actually too much burden? IIRC, that's what IAB statements have been calling for over and over again. Above, you have called for stronger "MUST" requirements for documents specifying SRV usage for some application. Why would the "SHOULD" here be too strong then? > > ******** (i.e., to end of section 3) Ooops! Section 3 is essential! > ... >> 4. Standard Service Labels >> >> Absent a normative document specifying otherwise, the SRV Service >> Label for a specific service/application SHOULD be in the form of a >> "Standard SRV Servcie Label" as specified in this section. >> >> Standard SRV Service Labels MUST be formed by prepending an >> underscore character ("_") to the Service Name of an application >> protocol registered in the IANA "Service Names and Port Numbers" >> registry [RFCyyyy]. >> >> Note that in order to make use of DNS based service discovery using >> SRV records, the application/service does *not* need an IANA-assigned >> port number (which would also be filed in the IANA "Service Names and >> Port Numbers" registry). >> >> The port numbers carried in the RDATA portion of the SRV records are >> locally assigned within the Service Domain; in case the service >> indeed has an IANA-assigned (default) port number, the locally > > IANA-assigned is not indicated as "default". There's no mechanism that > specifies it as a default. Defaults -- that's what they are! We have a Full Standard saying so (see the remark on URIs above). > >> assigned port number MAY coincide with that default port number, >> unless the documentation of the service specifies otherwise (it may >> say "MUST", "SHOULD", or recommend *against* using the default). There have been instances of protocol specifications changing the recommendations over time, during their evolution! >> >> As all domain name labels, SRV Service Labels are matched in a case- >> insensitive manner. >> >> [RFCyyyy] restricts IANA-registered Service Names to 15 characters in >> "ldh-syntax", informally: > > The rest of this section should be dropped. Just cite the IANA doc. > If/when the IANA spec changes, so should this. It's a bad idea to copy > requirements into a separate doc. This has been written when the IANA ports draft was not clear with respect to formal syntax. Will be modified as the latter contains an ABNF that is consistent with the prose. > ... >> Appendix A offers a scheme for "Extended SRV Service Labels" that can >> be adopted by service specifications that cannot contend with these >> restrictions, and which seek for a versatile naming scheme not >> violating the provisions of [RFCyyyy]. > > IMO this appendix should be offered and its necessity argued in a > separate document. As stated repeatedly above, we would regard it as very poor service to the community to have a document that makes existing RFCs non- conformant and does not (at least) suggest n alternative. However, if you agree to make a normative reference to such document in the IANA ports draft to ensure coordinated publication of all these drafts and the ADs agree having to deal with yet another I-D in the IESG, that could be done, but it would simply be more work for all and increase the delays. > >> 5. Service Discovery Client Considerations >> >> Implementations making use of dynamic service discovery based on DNS >> SRV records for a particular application/service will construct a >> prioritized list of applicable Service Prefixes, following the >> guidelines in the two subsections below. > > This appears to be describing new user-side requirements for the use of > SRVs. This needs further discussion in the WG; I don't think such a > prioritized list should be required. This is observed behavior and documented in many specifications (both published and work-in-progress). It is the recommended way to deal with service discovery in the APP area. This is not a new requirement, and there's no RFC 2119 language here. > --- > > I don't understand why the remainder of this section (below) is needed; > you're just restating how to use SRVs, and the SRV spec should have said > that. Didn't it? RFC 2782 did discuss some aspects,; the material here is largely supplementary, and it contains corrections for errata in RFC 2782. Your words seem to indicate that this actually is necessary text for a clarification document. We have introduced clarifying terminology and want to provide a decription of the process in these terms. >> To form the QNAME(s) for DNS SRV lookup, each Service Prefix is >> concatenated (with a period as the label separator character) to the >> FQDN of the Service Domain the application is interested in. >> >> Depending on application strategy and perhaps local policy >> (configuration), the DNS queries with QCLASS=IN and QTYPE=SRV can be >> performed serially or in parallel -- to decrease the latency in the >> case higher priority queries do not succeed in finding matching SRV >> record(s). Delays by non-use of parallel DNS lookup are frequent complaints (cf. recent threads on the DNSOP list!), and so emphasis on this possibility seems very appropriate too. >> >> The answers obtained are processed as specified in RFC 2782 >> [RFC2782], subject to the preferences of the service client for >> transport and/or "substrate" protocols. If necessary, the Target >> domain names obtained are then queried for address records (i.e., at >> the time of this writing, A and/or AAAA RRs) to determine the network >> layer addresses to be contacted over the corresponding transport >> protocol using the port number contained in the 'Port' element of the >> respective SRV record. >> >> Note: RFC 2782 [RFC2782] on page 7 imprecisely indicates the client >> "[SHOULD] ... try to connect to the (protocol, address, service)" >> tuple. Since at the transport layer the port number needs to be >> used, not the service (name?), and to let the order of the tuple >> components follow the protocol layers, it should refer to >> "(address, protocol, port)" tuples. >> >> 5.1. Protocol Label Selection >> >> Some services are defined to operate over only one transport >> protocol. In this case the application MUST use the appropriate >> transport label in forming the Service Prefix for SRV record lookup. >> >> If a service can operate over multiple transport protocols, then the >> specification of the service might indicate an order of preference, >> or local policy may supply it. Any service can provide a specific >> order in the Notes section of the "Service Names and Port Numbers" >> registry, during registration or via registration update [RFCyyyy]. > > I don't agree; prioritization should be a property of the SRV records, > not in the notes. This seems like an extension of the protocol. No. All prioritization given inside DNS RRs is always local, i.e. relative to the RRset, not global in nature. (See the DDDS specifications for more details.) So there cannot be any assumed relationship between preference values in SRV RRs for, say, TCP and SCTP because they have distinct owner names. > >> Absent such information, the following priority order SHOULD be used > > Absent what information? The "notes" aren't in the SRV records, so as The "Notes" in the Service Names & Port Numbers registry that implementers should follow ... -- as explained in the preceding paragraph of our draft you have quoted above. > such they ought to always be absent at the endpoint - so the rest of > this is the only real recommendation here, and it's a tautology > (endpoints should use only what they can use). .. including the knowlegde built into the service discovery code by their implementors, which in turn should be based on public records (specification documents and the IANA registry), for maximum interoperability. > >> as appropriate, based on what transports are defined and registered >> for the service, and supported by the client: _udp, _tcp, _sctp, >> _dccp. >> >> 5.2. Service Label Selection >> >> Absent service specific documentation saying otherwise or hints >> available to the client (e.g., by configuration), the following >> recommendations SHOULD be followed. >> >> If an application/service has a single registered Service Name, a >> prospective client uses the Standard Service Label derived from it >> according to Section 4. >> >> Contrary to the strong recommendation in RFC 2782 [RFC2782], several >> legacy services have been assigned more than one Service Name in the >> past. For instance, the well-know "systat" service is also referred >> to as "users" service, the DNS service, "domain", is also referred to >> as "nameserver" or "dns", "rlp" is also denoted as "resource", the >> WhoIs service is identified by "whois" and "nicname", the web service >> uses "http" or "www", "kerberos" is also indicated by "kdc", and the >> PCMail service has been assigned the equivalent Service Names >> "pcmail-srv" and "pcmail". >> In all these cases, the "Service Names and Port Numbers" registry >> will clearly indicate which name is the primary one and which names >> are considered aliases. > > I don't see why this should be expected or is necessary, except for the > deprecated names whose syntax needed to change based on the IANA ports > doc. Please explain. RFC 2782 said that aliases for Service Names "SHOULD NOT" be used. The distinction can only be made and this "SHOULD NOT" be followed in practice iff the tsvwg-iana-ports registry indeed contains this (primary/alias) information. Unless you have a specified primary name, SRV RRs would have to be entered in the DNS for all possible combinations in the Service Prefix. Having an explictly marked 'canonical' name allows to restrict the wealth and to implement fallback to it in the discovery code, even if the service discovery documentation for a particular application makes an exemption to the "SHOULD NOT" quoted above. Note that this distinction is a common practice in the context of the DNS; for instance MX RRs expect 'canonical' host names in their target, not alias names introduced into the DNS via CNAME RRs. These rules help to reduce to combinatorial explosion in the DNS and to contain the effort needed for service discovery. As the draft states ... >> Unless a prospective client has specific hints available (e.g., by >> configuration) indicating that a specific alias name ought to be >> tried preferentially, the primary Service Name SHOULD be used, and >> it also SHOULD be tried if the lookup of an alias name fails. > > I don't see what this accomplishes. It seems an unnecessarily restriction. Again, as above, a good default to make success much more likely in such scenarios (if there are SRV RRs present at all, of course!). As indicated above, RFC 2782 was even more restrictive. > The rest of this section should be moved to the separate doc arguing for > extended names... See above. >> If a service/application supports different well marked instances >> identified by different Service Names or a related specification has >> introduced the usage of extended Service Labels for discovery of this >> service (e.g., making use of the scheme specified in Appendix A), the >> specifications SHOULD always also define a single default service >> instance, and hence a default Service Label or Service Name (that can >> be used to construct the the corresponding Standard Service Label). >> Prospective clients MAY follow any service instance selection policy >> desired (by implementation, deployment, or configuration), but SHOULD >> be prepared to fall back to the default service instance if the SRV >> record lookup for preferred service instance(s) fails. >> >> >> 6. Provisioning of SRV records >> >> DNS zone administrators SHOULD support (and encourage) the >> provisioning of SRV records related to the basic domains they manage. >> Dynamic DNS Update ([RFC2136], [RFC3007]) is an option, but this is >> out of scope for this document. > > IMO, SRV provisioning ought to be outside the scope of this doc > entirely. The rest of this section is not related to the indicated focus > of this doc, and if needed should be in another (third) document. > ... No. Deficiencies in the provisioning paths are among the most painful hurdles in the use of "new" RRs (those not specified in RFCs 1034/1035). If we did not spell out such considerations, SRV-based service discovery would lag behind for many more years. Application designers and users have called for RFC text they can point to if DNS operators refuse to load valid DNS RRs. A document elaborating on SRV RRs is a splendid opportunity to supply such text. Further, these deliberations are kinda "management considerations" -- as strongly encouraged by the OPS ADs. >> 7. Security Considerations >> >> This document does not have any specific security implications. > > Agreed. > >> However it is hoped that the more orderly, and more frequent use of >> SRV-based dynamic service discovery, based on the rules clarified in >> this documents and the establishment of a unified service registry, >> will provide valuable information for administrators and security >> policy makers, to the benefit of the overall security of the >> Internet. > > I have no idea why this should be true; can you explain? Having documented rules gives justification to their deployment. This avoids ad-hoc hacks to circumvent stubbornness. Regular and uniform use of SRV RRs should foster operational practices to derive filtering rules (for a service domain) from the SRV RRs of that domain. This in turn should promote use of native services and help to reduce inappropriate application-layer tunneling practices. > > The rest of this section can be omitted; it does not add to the first > sentence of this entire section, which says it all IMO. It is common practice to point to security considerations in closely related documents, and SecDir reviews and the IESG regularly seem to call for such practice. So we'll keep these short paragraphs unless SecDir/IESG statements to the contrary will be received. > >> ... > AH: Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+