From dns-dir-bounces@ietf.org Mon Dec 1 10:51:27 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76A03A6B25; Mon, 1 Dec 2008 10:51:27 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324B33A6843 for ; Mon, 1 Dec 2008 10:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.538 X-Spam-Level: X-Spam-Status: No, score=-5.538 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-bJOtag3XLo for ; Mon, 1 Dec 2008 10:51:26 -0800 (PST) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 629993A6B25 for ; Mon, 1 Dec 2008 10:51:26 -0800 (PST) Received: from unknown.office.denic.de ([10.122.65.4]) by office.denic.de with esmtp id 1L7Dqq-0004TN-NH; Mon, 01 Dec 2008 19:50:32 +0100 Received: by unknown.office.denic.de (Postfix, from userid 501) id 9F0F91002B8; Mon, 1 Dec 2008 19:50:32 +0100 (CET) Date: Mon, 1 Dec 2008 19:50:32 +0100 From: Peter Koch To: IETF DNS Directorate Message-ID: <20081201185032.GH15069@unknown.office.denic.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [dns-dir] draft-bambenek-doubleflux-01.txt removed from RFC Ed Queue X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Dear Directorate, draft-bambenek-doubleflux-01.txt was on our review list. It has now disappeared with a "DNP" from the RFC Editor's Queue: RFC Editor Queue History File Name Date State Weeks Submitted draft-bambenek-doubleflux-00.txt 20080520 ISR 1.8 20080514 draft-bambenek-doubleflux-00.txt 20080602 ISR-AUTH 3.4 20080514 draft-bambenek-doubleflux-00.txt 20080626 REPL 0.0 20080514 draft-bambenek-doubleflux-01.txt 20080626 ISR-AUTH 18.1 20080514 draft-bambenek-doubleflux-01.txt 20081031 DNP **** 20080514 -Peter _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Dec 2 03:52:50 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5CF33A68E1; Tue, 2 Dec 2008 03:52:50 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6143A68E1 for ; Tue, 2 Dec 2008 03:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVJ0JR5xGMam for ; Tue, 2 Dec 2008 03:52:48 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3C47A3A67D7 for ; Tue, 2 Dec 2008 03:52:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,701,1220227200"; d="scan'208";a="27397463" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Dec 2008 11:52:43 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB2BqhLH012693 for ; Tue, 2 Dec 2008 12:52:43 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB2Bqh1l015663 for ; Tue, 2 Dec 2008 11:52:43 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 12:52:43 +0100 Received: from ams-townsley-8715.cisco.com ([10.55.233.230]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 12:52:42 +0100 Message-ID: <4935218A.4010600@cisco.com> Date: Tue, 02 Dec 2008 12:52:42 +0100 From: Mark Townsley User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: dns directorate X-OriginalArrivalTime: 02 Dec 2008 11:52:42.0829 (UTC) FILETIME=[7BE49FD0:01C95474] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=78; t=1228218763; x=1229082763; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Wikipedia=20over=20DNS |Sender:=20; bh=GOZ89sP3pxX+LFDzCxbnERvpi6+534S7svqPRIttCQ0=; b=lVAErSzfBcI1OJL6uXYubvkwJi0pqU6wKWvWb64I6gACipocLf/0H+ZPS2 sjlWYzuENGkqxPe/wXBPpeRRjC+yidz5OdtMks5JncO3eN4yhdYPtKZY/EKq /oeY5LjJfW; Authentication-Results: ams-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [dns-dir] Wikipedia over DNS X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org In case you didn't see it already... 1. https://dgl.cx/wikipedia-dns _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Dec 3 02:29:16 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49D93A6AD1; Wed, 3 Dec 2008 02:29:16 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55E23A6B31 for ; Wed, 3 Dec 2008 02:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 8jYxhU6EZ2pd for ; Wed, 3 Dec 2008 02:29:15 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id D85E93A6A74 for ; Wed, 3 Dec 2008 02:29:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,708,1220241600"; d="scan'208";a="144156242" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 03 Dec 2008 05:29:10 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Dec 2008 05:29:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Dec 2008 11:29:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dnsext-forgery-resilience Thread-Index: AclVMfk6kc8hIO7GSIWU5SRCCS03/A== From: "Romascanu, Dan (Dan)" To: "DNS Directorate" Subject: [dns-dir] draft-ietf-dnsext-forgery-resilience X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Was http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience -09.txt reviewed in DNS-DIR? It's for approval on the agenda of the IESG telechat tomorrow. Dan _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Dec 3 05:27:28 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2053A69EA; Wed, 3 Dec 2008 05:27:28 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA963A6A51 for ; Wed, 3 Dec 2008 05:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOcCuK7Yu7pb for ; Wed, 3 Dec 2008 05:27:26 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id B8EA13A67B3 for ; Wed, 3 Dec 2008 05:27:26 -0800 (PST) Received: from crankycanuck.ca (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E2DE52FE9555; Wed, 3 Dec 2008 13:27:19 +0000 (UTC) Date: Wed, 3 Dec 2008 08:27:18 -0500 From: Andrew Sullivan To: "Romascanu, Dan (Dan)" Message-ID: <20081203132718.GC91004@shinkuro.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: DNS Directorate Subject: Re: [dns-dir] draft-ietf-dnsext-forgery-resilience X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org On Wed, Dec 03, 2008 at 11:29:08AM +0100, Romascanu, Dan (Dan) wrote: > Was > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience > -09.txt reviewed in DNS-DIR? It's for approval on the agenda of the IESG > telechat tomorrow. Well, it's a product of the dnsext working group, and the co-chairs of that WG are part of the DNS directorate. Also, it was mentioned at the Minneapolis directorate meeting. Other than that, I can't say. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Dec 3 05:37:47 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310E43A6956; Wed, 3 Dec 2008 05:37:47 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49CF23A6956 for ; Wed, 3 Dec 2008 05:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 5-IvWC0493MY for ; Wed, 3 Dec 2008 05:37:45 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 2F8783A68D7 for ; Wed, 3 Dec 2008 05:37:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,708,1220241600"; d="scan'208";a="130115823" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Dec 2008 08:37:37 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Dec 2008 08:37:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Dec 2008 14:37:29 +0100 Message-ID: In-Reply-To: <20081203132718.GC91004@shinkuro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dns-dir] draft-ietf-dnsext-forgery-resilience Thread-Index: AclVSt/Rh/eZ+5QgS3aNVUp1Prx4DgAAB6Yg References: <20081203132718.GC91004@shinkuro.com> From: "Romascanu, Dan (Dan)" To: "Andrew Sullivan" Cc: DNS Directorate Subject: Re: [dns-dir] draft-ietf-dnsext-forgery-resilience X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Well, yes, but even in such cases one more review cannot do harm ... > -----Original Message----- > From: Andrew Sullivan [mailto:ajs@shinkuro.com] > Sent: Wednesday, December 03, 2008 3:27 PM > To: Romascanu, Dan (Dan) > Cc: DNS Directorate > Subject: Re: [dns-dir] draft-ietf-dnsext-forgery-resilience > > On Wed, Dec 03, 2008 at 11:29:08AM +0100, Romascanu, Dan (Dan) wrote: > > Was > > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilien > > ce -09.txt reviewed in DNS-DIR? It's for approval on the > agenda of the > > IESG telechat tomorrow. > > Well, it's a product of the dnsext working group, and the > co-chairs of that WG are part of the DNS directorate. Also, > it was mentioned at the Minneapolis directorate meeting. > > Other than that, I can't say. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Dec 3 05:47:14 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBFEA3A6B10; Wed, 3 Dec 2008 05:47:14 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81F73A6B10 for ; Wed, 3 Dec 2008 05:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 UxFX-sZcw1g4 for ; Wed, 3 Dec 2008 05:47:13 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id C3B723A6B25 for ; Wed, 3 Dec 2008 05:45:50 -0800 (PST) Received: from crankycanuck.ca (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4623D2FE9555; Wed, 3 Dec 2008 13:45:46 +0000 (UTC) Date: Wed, 3 Dec 2008 08:45:44 -0500 From: Andrew Sullivan To: "Romascanu, Dan (Dan)" Message-ID: <20081203134544.GD91004@shinkuro.com> References: <20081203132718.GC91004@shinkuro.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: DNS Directorate Subject: Re: [dns-dir] draft-ietf-dnsext-forgery-resilience X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org On Wed, Dec 03, 2008 at 02:37:29PM +0100, Romascanu, Dan (Dan) wrote: > Well, yes, but even in such cases one more review cannot do harm ... So to be clear, Olafur and I have of course reviewed it as chairs. I don't know whether there's been a formal review by the directorate, however. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Dec 3 05:47:49 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00503A69EA; Wed, 3 Dec 2008 05:47:49 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94D303A6A00 for ; Wed, 3 Dec 2008 05:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 DqHMPIlLN7+b for ; Wed, 3 Dec 2008 05:47:47 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id A6AF13A67B3 for ; Wed, 3 Dec 2008 05:47:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,708,1220241600"; d="scan'208";a="144174109" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 03 Dec 2008 08:47:42 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Dec 2008 08:47:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Dec 2008 14:47:40 +0100 Message-ID: In-Reply-To: <20081203134544.GD91004@shinkuro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dns-dir] draft-ietf-dnsext-forgery-resilience Thread-Index: AclVTXMcJ7esg+GjQge/fjzD5SJqNwAACoHw References: <20081203132718.GC91004@shinkuro.com> <20081203134544.GD91004@shinkuro.com> From: "Romascanu, Dan (Dan)" To: "Andrew Sullivan" Cc: DNS Directorate Subject: Re: [dns-dir] draft-ietf-dnsext-forgery-resilience X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org That's fine - thanks. I will assume that there are no pending issues at this point from your perspective. Dan > -----Original Message----- > From: Andrew Sullivan [mailto:ajs@shinkuro.com] > Sent: Wednesday, December 03, 2008 3:46 PM > To: Romascanu, Dan (Dan) > Cc: DNS Directorate > Subject: Re: [dns-dir] draft-ietf-dnsext-forgery-resilience > > On Wed, Dec 03, 2008 at 02:37:29PM +0100, Romascanu, Dan (Dan) wrote: > > Well, yes, but even in such cases one more review cannot do > harm ... > > So to be clear, Olafur and I have of course reviewed it as > chairs. I don't know whether there's been a formal review by > the directorate, however. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Dec 3 05:58:08 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591D23A6B68; Wed, 3 Dec 2008 05:58:08 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F5F3A6B7F for ; Wed, 3 Dec 2008 05:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acGNTLv4mPW8 for ; Wed, 3 Dec 2008 05:58:06 -0800 (PST) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id D45F63A6B37 for ; Wed, 3 Dec 2008 05:58:05 -0800 (PST) Received: from unknown.office.denic.de ([10.122.65.4]) by office.denic.de with esmtp id 1L7sEq-0006dG-Jy; Wed, 03 Dec 2008 14:58:00 +0100 Received: by unknown.office.denic.de (Postfix, from userid 501) id 82584102A06; Wed, 3 Dec 2008 14:58:00 +0100 (CET) Date: Wed, 3 Dec 2008 14:58:00 +0100 From: Peter Koch To: DNS Directorate Message-ID: <20081203135800.GI20326@unknown.office.denic.de> References: <20081203132718.GC91004@shinkuro.com> <20081203134544.GD91004@shinkuro.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20081203134544.GD91004@shinkuro.com> User-Agent: Mutt/1.4.2.1i Subject: Re: [dns-dir] draft-ietf-dnsext-forgery-resilience X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org On Wed, Dec 03, 2008 at 08:45:44AM -0500, Andrew Sullivan wrote: > don't know whether there's been a formal review by the directorate, > however. there wasn't as far as I recall. The question is whether we should do this for dnsext/dnsop documents. Also, a couple of us would be encumbered by already having particpated in the WG discussion and WGLC. That said, my view is that the document is OK, I only had formal issues during WGLC, like the calculation in section 9 better be in an appendix, but I can live with it as is. The other issue was BCP vs. Standards Track, where the WG was split and the chairs made a judgement call. Also OK, although the reasoning really confused me. Operationally, after the draft had been implemented by some (more) vendors, it turned out that some OSes seem to have "issues" with huge numbers of open sockets; not sure that needs to be added to the document because the solution is likely OS dependent. -Peter _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Dec 3 06:04:56 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937373A6AD6; Wed, 3 Dec 2008 06:04:56 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7423A6A59 for ; Wed, 3 Dec 2008 06:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, 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 TC2ksWFTC1As for ; Wed, 3 Dec 2008 06:04:54 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 539F43A69FE for ; Wed, 3 Dec 2008 06:04:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,708,1220227200"; d="scan'208,217";a="29814264" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Dec 2008 14:04:47 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB3E4lP1031115; Wed, 3 Dec 2008 09:04:47 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mB3E4lF8024543; Wed, 3 Dec 2008 14:04:47 GMT Received: from xmb-rtp-21e.amer.cisco.com ([64.102.31.103]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 09:04:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Dec 2008 09:04:38 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dns-dir] draft-ietf-dnsext-forgery-resilience Thread-Index: AclVSuV9s8TXXraTQbug9IKRNUa/zwABS8Vh From: "Mark Townsley (townsley)" To: "Andrew Sullivan" , "Romascanu, Dan (Dan)" X-OriginalArrivalTime: 03 Dec 2008 14:04:47.0216 (UTC) FILETIME=[199BDF00:01C95550] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3541; t=1228313087; x=1229177087; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20=22Mark=20Townsley=20(townsley)=22=20 |Subject:=20Re=3A=20[dns-dir]=20draft-ietf-dnsext-forgery-r esilience |Sender:=20 |To:=20=22Andrew=20Sullivan=22=20,=0A=20= 20=20=20=20=20=20=20=22Romascanu,=20Dan=20(Dan)=22=20; bh=6hkfMSNyJyPWdTq5awKnDi9jtNXq62i+eRHoDf79mtg=; b=LAtVE1y0JXGp1IsEQtjiVzsbrxPQBaJFiK3+SduTCIz15WCLbThT87N48/ zAAnVpG8raP/VqfXjoSqpkOeucWt3LdJz0BbghwIAMhppUMNED+g2LiIg6Ir G2rJz9twUW; Authentication-Results: rtp-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: DNS Directorate Subject: Re: [dns-dir] draft-ietf-dnsext-forgery-resilience X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0665566089==" Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org This is a multi-part message in MIME format. --===============0665566089== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95550.14855584" This is a multi-part message in MIME format. ------_=_NextPart_001_01C95550.14855584 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think that the automatic review function of the dns-dir is = operating at a level that one would realistically expect all dns = documents to be reviewed. That said, feel free to ask for a review and = there is a good.chance you will get lucky and get one. - Mark=20 Sent from my mobile. -----Original Message----- From: Andrew Sullivan [mailto:ajs@shinkuro.com] Sent: Wednesday, December 03, 2008 08:27 AM Eastern Standard Time To: Romascanu, Dan (Dan) Cc: DNS Directorate Subject: Re: [dns-dir] draft-ietf-dnsext-forgery-resilience On Wed, Dec 03, 2008 at 11:29:08AM +0100, Romascanu, Dan (Dan) wrote: > Was > = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience > -09.txt reviewed in DNS-DIR? It's for approval on the agenda of the = IESG > telechat tomorrow. =20 Well, it's a product of the dnsext working group, and the co-chairs of that WG are part of the DNS directorate. Also, it was mentioned at the Minneapolis directorate meeting. Other than that, I can't say. A --=20 Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir ------_=_NextPart_001_01C95550.14855584 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [dns-dir] draft-ietf-dnsext-forgery-resilience

I don't think that the automatic review function of = the dns-dir is operating at a level that one would realistically expect = all dns documents to be reviewed. That said, feel free to ask for a = review and there is a good.chance you will get lucky and get one.

- Mark



Sent from my mobile.

 -----Original Message-----
From:   Andrew Sullivan [mailto:ajs@shinkuro.com]
Sent:   Wednesday, December 03, 2008 08:27 AM Eastern Standard = Time
To:     Romascanu, Dan (Dan)
Cc:     DNS Directorate
Subject:        Re: [dns-dir] = draft-ietf-dnsext-forgery-resilience

On Wed, Dec 03, 2008 at 11:29:08AM +0100, Romascanu, Dan (Dan) = wrote:
> Was
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-re= silience
> -09.txt reviewed in DNS-DIR? It's for approval on the agenda of the = IESG
> telechat tomorrow. 

Well, it's a product of the dnsext working group, and the co-chairs = of
that WG are part of the DNS directorate.  Also, it was mentioned = at
the Minneapolis directorate meeting.

Other than that, I can't say.

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
_______________________________________________
dns-dir mailing list
dns-dir@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dns-dir

------_=_NextPart_001_01C95550.14855584-- --===============0665566089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir --===============0665566089==-- From dns-dir-bounces@ietf.org Wed Dec 3 11:32:40 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCBB03A6820; Wed, 3 Dec 2008 11:32:40 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E52D83A6A08 for ; Wed, 3 Dec 2008 11:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LynYBh-ffCI for ; Wed, 3 Dec 2008 11:32:39 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E77D53A67ED for ; Wed, 3 Dec 2008 11:32:38 -0800 (PST) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id mB3JWaNP077825; Wed, 3 Dec 2008 14:32:36 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <200812031932.mB3JWaNP077825@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 03 Dec 2008 09:09:29 -0500 To: Andrew Sullivan , "Romascanu, Dan (Dan)" From: Olafur Gudmundsson In-Reply-To: <20081203134544.GD91004@shinkuro.com> References: <20081203132718.GC91004@shinkuro.com> <20081203134544.GD91004@shinkuro.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Cc: DNS Directorate Subject: Re: [dns-dir] draft-ietf-dnsext-forgery-resilience X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0336874118==" Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org --===============0336874118== Content-Type: multipart/alternative; boundary="=====================_1291424029==.ALT" --=====================_1291424029==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed There was no formal review by the directorate, but I know at least 3 members (Andrew, Peter, me) of the directorate have read recent version of the document. Olafur At 08:45 03/12/2008, Andrew Sullivan wrote: >On Wed, Dec 03, 2008 at 02:37:29PM +0100, Romascanu, Dan (Dan) wrote: > > Well, yes, but even in such cases one more review cannot do harm ... > >So to be clear, Olafur and I have of course reviewed it as chairs. I >don't know whether there's been a formal review by the directorate, >however. > >A > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. >_______________________________________________ >dns-dir mailing list >dns-dir@ietf.org >https://www.ietf.org/mailman/listinfo/dns-dir --=====================_1291424029==.ALT Content-Type: text/html; charset="us-ascii" There was no formal review by the directorate, but I know at least 3 members
(Andrew, Peter, me) of the directorate have read recent version of the document.

        Olafur

At 08:45 03/12/2008, Andrew Sullivan wrote:
On Wed, Dec 03, 2008 at 02:37:29PM +0100, Romascanu, Dan (Dan) wrote:
> Well, yes, but even in such cases one more review cannot do harm ...

So to be clear, Olafur and I have of course reviewed it as chairs.  I
don't know whether there's been a formal review by the directorate,
however.

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
_______________________________________________
dns-dir mailing list
dns-dir@ietf.org
https://www.ietf.org/mailman/listinfo/dns-dir
--=====================_1291424029==.ALT-- --===============0336874118== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir --===============0336874118==-- From dns-dir-bounces@ietf.org Thu Dec 4 22:08:13 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B923A6BD6; Thu, 4 Dec 2008 22:08:13 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00DF83A688D; Thu, 4 Dec 2008 22:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 feXuW6MBWsiv; Thu, 4 Dec 2008 22:08:09 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 90D693A67EA; Thu, 4 Dec 2008 22:08:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,719,1220241600"; d="scan'208";a="153432855" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 05 Dec 2008 01:08:04 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Dec 2008 01:08:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 5 Dec 2008 07:08:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for December 11, 2008 Telechat Thread-Index: AclWZNMz+vC5C9RGSCKYt3mXp/6SigAOoLqA From: "Romascanu, Dan (Dan)" To: "MIB Doctors (E-mail)" , , , "DNS Directorate" Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for December 11, 2008 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Please find below the preliminary agenda o the IESG telechat on 12/11. The IESG will hold three telechats in three consecutive weeks in December, to share load and expedite the review process. Please review and comment on the relevant documents until 12/10 COB the latest. Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-rmt-bb-fec-basic-schemes-revised-06.txt Basic Forward Error Correction (FEC) Schemes (Proposed Standard) - 1 of 11 Token: Magnus Westerlund o draft-ietf-nfsv4-rfc1831bis-10.txt RPC: Remote Procedure Call Protocol Specification Version 2 (Draft Standard) - 2 of 11 Note: Document Shepherd: Spencer Shepler (spencer.shepler@gmail.com) Token: Lars Eggert o draft-ietf-avt-smpte-rtp-14.txt Associating Time-codes with RTP streams (Proposed Standard) - 3 of 11 Note: Tom Taylor is the PROTO Shepherd Token: Cullen Jennings o draft-melnikov-imapext-filters-07.txt IMAP4 extension for named searches (filters) (Proposed Standard) - 4 of 11 Note: Dave Cridland is document shepherd. Token: Chris Newman o draft-ietf-isis-hmac-sha-07.txt IS-IS Generic Cryptographic Authentication (Proposed Standard) - 5 of 11 Token: Ross Callon o draft-ietf-smime-sha2-09.txt Using SHA2 Algorithms with Cryptographic Message Syntax (Proposed Standard) - 6 of 11 Token: Tim Polk o draft-ietf-pce-path-key-05.txt Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism (Proposed Standard) - 7 of 11 Token: Ross Callon o draft-ietf-mext-nemo-v4traversal-06.txt Mobile IPv6 Support for Dual Stack Hosts and Routers (Proposed Standard) - 8 of 11 Token: Jari Arkko o draft-ietf-tcpm-rfc4138bis-04.txt Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP (Proposed Standard) - 9 of 11 Note: Wesley Eddy (wesley.m.eddy@nasa.gov) (TCPM co-chair) is the shepherd. Token: Lars Eggert o draft-ietf-dhc-dhcpv6-bulk-leasequery-05.txt DHCPv6 Bulk Leasequery (Proposed Standard) - 10 of 11 Token: Jari Arkko o draft-ietf-avt-rtp-g719-04.txt RTP Payload format for G.719 (Proposed Standard) - 11 of 11 Token: Cullen Jennings 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-daboo-imap-annotatemore-16.txt IMAP METADATA Extension (Proposed Standard) - 1 of 1 Note: Alexey Melnikov is document shepherd. Token: Chris Newman 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-lemonade-architecture-04.txt LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) using Internet Mail (Informational) - 1 of 3 Note: Alexey Melnikov is document shepherd. Token: Chris Newman o draft-ietf-mpls-te-scaling-analysis-04.txt An Analysis of Scaling Issues in MPLS-TE Core Networks (Informational) - 2 of 3 Token: Ross Callon o draft-ietf-pim-rpf-vector-06.txt The RPF Vector TLV (Informational) - 3 of 3 Token: David Ward 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-jerichow-msec-mikey-genext-oma-00.txt MIKEY General Extension Payload for OMA BCAST 1.0 (Informational) - 1 of 3 Token: Tim Polk o draft-housley-internet-draft-sig-file-06.txt Digital Signatures on Internet-Draft Documents (Informational) - 2 of 3 Token: Tim Polk o draft-igoe-secsh-aes-gcm-00.txt AES Galois Counter Mode for the Secure Shell Transport Layer Protocol (Informational) - 3 of 3 Token: Tim Polk 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item o draft-irtf-asrg-dnsbl-08.txt DNS Blacklists and Whitelists (Informational) - 1 of 1 Note: Propose to respond "1. The IESG has not found any conflict between this document and IETF work." Token: Lisa Dusseault _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Dec 9 06:49:32 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D2A3A683E; Tue, 9 Dec 2008 06:49:32 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23EDF3A67AA for ; Tue, 9 Dec 2008 06:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4QB-LUeWTGy for ; Tue, 9 Dec 2008 06:49:24 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 089AD3A683E for ; Tue, 9 Dec 2008 06:49:23 -0800 (PST) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id mB9EnKp1092112 for ; Tue, 9 Dec 2008 09:49:21 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <200812091449.mB9EnKp1092112@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Dec 2008 09:48:29 -0500 To: dns-dir@ietf.org From: Olafur Gudmundsson Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Subject: [dns-dir] Urgent question: how long to keep DNS state on NAT and firewall? X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1362050990==" Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org --===============1362050990== Content-Type: multipart/alternative; boundary="=====================_158002125==.ALT" --=====================_158002125==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Background: https://datatracker.ietf.org/idtracker/draft-ietf-dnsext-forgery-resilience/comment/88789/ Same issue applies to statefull firewalls. RFC4787 says keep state for 2-5 minutes RFC4787 req #5 says no less than 2 minutes RFC4787 req #5-a says ports <1024 MAY have shorter RFC4787 Req #5-c recommends 5 minutes. On area of particular concern is NAT boxes with limited port range or limited memory. To address this issue we are proposing to add the following text to the Forgery resilience draft: "DNS recursive servers sitting behind at NAT or a statefull firewall may consume all available NAT translation entries/ports when operating under high query load. Port randomization will cause translation entries to be consumed faster than with fixed query port. To avoid this NAT boxes and statefull firewalls can/should purge outgoing DNS query translation entries 10 seconds after the last outgoing query on that mapping was sent. [RFC4787] compliant devices need to treat UDP messages with port 53 differently than most other UDP protocols. To minimize the potential that port/state exhaustion attacks can be staged from the outside, it is recommended that services which generate number of DNS queries for each connection, should be rate limited. This applies in particular to e-mail servers." The question is: is the 10 second recommendation OK or should it be longer/shorter? Feel free to suggest better text. thanks Olafur --=====================_158002125==.ALT Content-Type: text/html; charset="us-ascii"
Background:
https://datatracker.ietf.org/idtracker/draft-ietf-dnsext-forgery-resilience/comment/88789/

Same issue applies to statefull firewalls.

RFC4787 says keep state for 2-5 minutes
RFC4787 req #5 says no less than 2 minutes
RFC4787 req #5-a says ports <1024 MAY have shorter
RFC4787 Req #5-c recommends 5 minutes.

On area of particular concern is NAT boxes with limited port range or limited
memory.

To address this issue we are proposing to add the following text to the
Forgery resilience draft:

"DNS recursive servers sitting behind at NAT or a statefull firewall
may consume all available NAT translation entries/ports when operating
under high query load. Port randomization will cause translation entries to
be consumed faster than with fixed query port.
To avoid this NAT boxes and statefull firewalls can/should purge outgoing
DNS query translation entries 10 seconds after the last outgoing query on
that mapping was sent. [RFC4787] compliant devices need to treat
UDP messages with port 53 differently than most other UDP protocols.

To minimize the potential that port/state exhaustion attacks can be staged from
the outside, it is recommended that services which generate number of DNS queries
for each connection, should be rate limited. This applies in particular to e-mail
servers."

The question is: is the 10 second recommendation OK or should it be longer/shorter?

Feel free to suggest better text.

        thanks
        Olafur
 --=====================_158002125==.ALT-- --===============1362050990== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir --===============1362050990==-- From dns-dir-bounces@ietf.org Tue Dec 9 11:25:00 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7155E3A6B54; Tue, 9 Dec 2008 11:25:00 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB5D3A6B46 for ; Tue, 9 Dec 2008 11:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.657 X-Spam-Level: X-Spam-Status: No, score=-5.657 tagged_above=-999 required=5 tests=[AWL=0.592, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-Zo5FClxIfF for ; Tue, 9 Dec 2008 11:24:58 -0800 (PST) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 059D13A6910 for ; Tue, 9 Dec 2008 11:24:58 -0800 (PST) Received: from unknown.office.denic.de ([10.122.65.4]) by office.denic.de with esmtp id 1LA8CQ-00087W-U1; Tue, 09 Dec 2008 20:24:50 +0100 Received: by unknown.office.denic.de (Postfix, from userid 501) id AB7EC10A5F3; Tue, 9 Dec 2008 20:24:49 +0100 (CET) Date: Tue, 9 Dec 2008 20:24:49 +0100 From: Peter Koch To: Olafur Gudmundsson Message-ID: <20081209192449.GH29638@unknown.office.denic.de> References: <200812091449.mB9EnKp1092112@stora.ogud.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <200812091449.mB9EnKp1092112@stora.ogud.com> User-Agent: Mutt/1.4.2.1i Cc: dns-dir@ietf.org Subject: Re: [dns-dir] Urgent question: how long to keep DNS state on NAT and firewall? X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org On Tue, Dec 09, 2008 at 09:48:29AM -0500, Olafur Gudmundsson wrote: > RFC4787 says keep state for 2-5 minutes > RFC4787 req #5 says no less than 2 minutes > RFC4787 req #5-a says ports <1024 MAY have shorter > RFC4787 Req #5-c recommends 5 minutes. with destination port 53 < 1024, DNS qualifies for less than 2 minutes under these rules - and that makes sense. > On area of particular concern is NAT boxes with limited port range or > limited > memory. Is the "attack scenario" an exhaustion of the table or an attack against a second (third, ...) resolver behind the same NAT by having one resolver grab all the available slots? > The question is: is the 10 second recommendation OK or should it be > longer/shorter? The trade off needs to be discussed. With 10 seconds you need 6500 q/s to consume all available ports (provided the randomization is good enough(?) not to reuse any port at the resolver side). However, shrinking the window may lead to an effect where the mapping is removed before the (increasing) resolver timeout expires. A later response would then be rejected. Strange enough, we don't have clear recommendations how long these resolver timeouts should be (at most), except RFC 1035 saying "expected round trip time of 5-10 seconds should be the worst case". Intuitively I'd have suggested 17 seconds to even cover a 16 second timeout, but 10 (or 9, for that matter) seconds might be OK. I'd feel more comfortable, though, if the number didn't come out of the blue. -Peter _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Tue Dec 9 12:45:35 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8FE73A6B68; Tue, 9 Dec 2008 12:45:35 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7023A6B6A for ; Tue, 9 Dec 2008 12:45:33 -0800 (PST) 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.223, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTg-dI-9xhOW for ; Tue, 9 Dec 2008 12:45:32 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 6DC193A6B68 for ; Tue, 9 Dec 2008 12:45:32 -0800 (PST) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id mB9KjS1K095024 for ; Tue, 9 Dec 2008 15:45:28 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <200812092045.mB9KjS1K095024@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Dec 2008 15:44:15 -0500 To: dns-dir@ietf.org From: Olafur Gudmundsson In-Reply-To: <20081209192449.GH29638@unknown.office.denic.de> References: <200812091449.mB9EnKp1092112@stora.ogud.com> <20081209192449.GH29638@unknown.office.denic.de> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4 Subject: Re: [dns-dir] Urgent question: how long to keep DNS state on NAT and firewall? X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0360522560==" Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org --===============0360522560== Content-Type: multipart/alternative; boundary="=====================_179347658==.ALT" --=====================_179347658==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 14:24 09/12/2008, Peter Koch wrote: >On Tue, Dec 09, 2008 at 09:48:29AM -0500, Olafur Gudmundsson wrote: > > > RFC4787 says keep state for 2-5 minutes > > RFC4787 req #5 says no less than 2 minutes > > RFC4787 req #5-a says ports <1024 MAY have shorter > > RFC4787 Req #5-c recommends 5 minutes. > >with destination port 53 < 1024, DNS qualifies for less than 2 minutes under >these rules - and that makes sense. > > > On area of particular concern is NAT boxes with limited port range or > > limited > > memory. > >Is the "attack scenario" an exhaustion of the table or an attack against >a second (third, ...) resolver behind the same NAT by having one resolver >grab all the available slots? We can not do anything against internal attack i.e. java script spewing out DNS questions. This is about using external services like e-mail that generate number of DNS questions for each e-mail message that arrives. > > The question is: is the 10 second recommendation OK or should it be > > longer/shorter? > >The trade off needs to be discussed. With 10 seconds you need 6500 q/s to >consume all available ports (provided the randomization is good enough(?) >not to reuse any port at the resolver side). You are thinking that the NAT has 64K ports available (or can keep track of 64K connections) that may not be true in all cases and some of the IPv4-IPv6 transition steps may restrict the number of ports available to each site. >However, shrinking the window may lead to an effect where the mapping is >removed before the (increasing) resolver timeout expires. A later >response would >then be rejected. Strange enough, we don't have clear recommendations how >long these resolver timeouts should be (at most), except RFC 1035 saying >"expected round trip time of 5-10 seconds should be the worst case". >Intuitively I'd have suggested 17 seconds to even cover a 16 second timeout, >but 10 (or 9, for that matter) seconds might be OK. I'd feel more >comfortable, though, if the number didn't come out of the blue. > >-Peter That is why I asked rather than write down a recommendation on my own. Olafur --=====================_179347658==.ALT Content-Type: text/html; charset="us-ascii" At 14:24 09/12/2008, Peter Koch wrote:
On Tue, Dec 09, 2008 at 09:48:29AM -0500, Olafur Gudmundsson wrote:

> RFC4787 says keep state for 2-5 minutes
> RFC4787 req #5 says no less than 2 minutes
> RFC4787 req #5-a says ports <1024 MAY have shorter
> RFC4787 Req #5-c recommends 5 minutes.

with destination port 53 < 1024, DNS qualifies for less than 2 minutes under
these rules - and that makes sense.

> On area of particular concern is NAT boxes with limited port range or
> limited
> memory.

Is the "attack scenario" an exhaustion of the table or an attack against
a second (third, ...) resolver behind the same NAT by having one resolver
grab all the available slots?


We can not do anything against internal attack i.e. java script spewing
out DNS questions.
This is about using external services like e-mail that generate
number of DNS questions for each e-mail message that arrives.


> The question is: is the 10 second recommendation OK or should it be
> longer/shorter?

The trade off needs to be discussed. With 10 seconds you need 6500 q/s to
consume all available ports (provided the randomization is good enough(?)
not to reuse any port at the resolver side).

You are thinking that the NAT has 64K ports available (or can keep
track of 64K connections) that may not
be true in all cases and some of the IPv4-IPv6 transition steps
may restrict the number of ports available to each site.

However, shrinking the window may lead to an effect where the mapping is
removed before the (increasing) resolver timeout expires.  A later response would
then be rejected.  Strange enough, we don't have clear recommendations how
long these resolver timeouts should be (at most), except RFC 1035 saying
"expected round trip time of 5-10 seconds should be the worst case".
Intuitively I'd have suggested 17 seconds to even cover a 16 second timeout,
but 10 (or 9, for that matter) seconds might be OK.  I'd feel more
comfortable, though, if the number didn't come out of the blue.

-Peter

That is why I asked rather than write down a recommendation on my own.

        Olafur
 --=====================_179347658==.ALT-- --===============0360522560== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir --===============0360522560==-- From dns-dir-bounces@ietf.org Tue Dec 9 13:07:59 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B7C33A67FD; Tue, 9 Dec 2008 13:07:59 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60173A67FD for ; Tue, 9 Dec 2008 13:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.664, 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 xh0PWiKS-BRi for ; Tue, 9 Dec 2008 13:07:57 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 01F813A67E4 for ; Tue, 9 Dec 2008 13:07:57 -0800 (PST) Received: from crankycanuck.ca (CPE001b63afe888-CM001adea9c5a6.cpe.net.cable.rogers.com [99.236.211.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BAC1E2FE9647 for ; Tue, 9 Dec 2008 21:07:48 +0000 (UTC) Date: Tue, 9 Dec 2008 16:07:47 -0500 From: Andrew Sullivan To: dns-dir@ietf.org Message-ID: <20081209210747.GC13443@shinkuro.com> References: <200812091449.mB9EnKp1092112@stora.ogud.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200812091449.mB9EnKp1092112@stora.ogud.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [dns-dir] Urgent question: how long to keep DNS state on NAT and firewall? X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org On Tue, Dec 09, 2008 at 09:48:29AM -0500, Olafur Gudmundsson wrote: > The question is: is the 10 second recommendation OK or should it be > longer/shorter? I'd prefer a little longer, but it all seems like a SWAG to me. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Dec 11 03:46:36 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2713A6A3A; Thu, 11 Dec 2008 03:46:36 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F013A6918 for ; Thu, 11 Dec 2008 03:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.934 X-Spam-Level: X-Spam-Status: No, score=-4.934 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgT9I-X4bA-k for ; Thu, 11 Dec 2008 03:46:33 -0800 (PST) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 0E71A3A6A1A for ; Thu, 11 Dec 2008 03:46:33 -0800 (PST) Received: from unknown.office.denic.de ([10.122.65.4]) by office.denic.de with esmtp id 1LAjzo-0006ko-7f; Thu, 11 Dec 2008 12:46:20 +0100 Received: by unknown.office.denic.de (Postfix, from userid 501) id 1247A10B498; Thu, 11 Dec 2008 12:46:19 +0100 (CET) Date: Thu, 11 Dec 2008 12:46:19 +0100 From: Peter Koch To: IETF DNS Directorate Message-ID: <20081211114619.GF30676@unknown.office.denic.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oC1+HKm2/end4ao3" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [dns-dir] Status/Review of draft-irtf-asrg-dnsbl-08 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org --oC1+HKm2/end4ao3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline DNS-Dir, we've been discussing draft-irtf-asrg-dnsbl-08.txt "DNS Blacklists and Whitelists" and its predecessors here. In Minneapolis I talked to both Lisa and Aaron. Lisa told me that the draft would not continue on its way to PS, but would go for informational instead. From Aaron I understood he was planning to publish it under the IRTF stream (which would imply Informational, in this case). Current state is that it's an RFC Ed Independent Submission aiming at Informational. Process wise this concerns me because even though I cannot prove it conflicts with an IETF WG's work, I could imagine both v6ops and dnsop could cover parts of it. Also, the "accompanying document" is missing. So, this isn't strictly an end run around the IETF, but still trying to avoid some pushback and correction. But that might be part of my sentiment against the Independent Stream. For the IRTF strem I'd be equally unhappy, less for the Stream per se, but for a research group that tries to document and influence current practice. FWIW, here's a review of -08. -Peter --oC1+HKm2/end4ao3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-irtf-asrg-dnsbl-08.review" > DNS Blacklists and Whitelists > draft-irtf-asrg-dnsbl-08 > Abstract > > The rise of spam and other anti-social behavior on the Internet has > led to the creation of shared blacklists and whitelists of IP > addresses or domains. The DNS has become the de-facto standard > method of distributing these blacklists and whitelists. This memo > documents the structure and usage of DNS based blacklists and > whitelists, and the protocol used to query them. The use of the word "standard", even if qualified as "de-facto" appears to me as potentially misleading, even more if this isn't getting IETF review. > IRTF Notice > > This document is a product of the Anti-Spam Research Group (ASRG) of > the Internet Research Task Force. It represents the consensus of the > ASRG with respect to practices to improve interoperability of DNS > based blacklists and whitelists, but does not constitute an IETF or > Internet standard. Can we please now clarify whether this is going on IRTF or Independent Stream/ > 1. Introduction > This document defines the structure of DNSBLs and DNSWLs. It > describes the structure, operation, and use of DNSBLs and DNSWLs but > does not describe or recommend policies for adding or removing > addresses to and from DNSBLs and DNSWLs, nor does it recommend > policies for using them. We anticipate that management policies will > be addressed in a companion document. The document isn't always clear where it describes current practice and where it adds additional recommendations. For v6 it can be assumed there is little to no current practice, yet. With regard to the "policies", the paragraph could be a bit more clear in stating that it only deals with the technical or DNS operations. It should also clearly identify the target audiences, which I understand are both providers and users of DNS[BW]Ls. If there's a companion document (and draft-irtf-asrg-bcp-blacklists-05.txt we know exists), it should be reviewed side-by-side. > > Requirements Notation: The key words "MUST", "MUST NOT", > "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", > "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be > interpreted as described in [RFC2119], with respect to > recommendations for improving technical interoperability of > DNSxLs. Now, which is true here: "requirements" or "recommendations for improving technical interoperability"? > 2. Structure of an IP address DNSBL or DNSWL > > A DNSxL is a zone in the DNS[RFC1034][RFC1035]. The zone containing > resource records identifies hosts present in a blacklist or > whitelist. Hosts were originally encoded into DNSxL zones using a > transformation of their IP addresses, but now host names are > sometimes encoded as well. Most DNSxLs still use IP addresses. DNSxLs are implemented as structured namespaces, but they are not necessarily "a zone". This terminology distinction is important. > 2.1. IP address DNSxL > > An IPv4 address DNSxL has a structure adapted from that of the rDNS. > (The rDNS, reverse DNS, is the IN-ADDR.ARPA[RFC1034] and > IP6.ARPA[RFC3596] domains used to map IP addresses to domain names.) "rDNS" is not an established term and there's no need for an introduction here. Also, when explicitly refering to "IPv4 address DNSxL"s, there's nothing to borrow from RFC3596. "An IPv4 address DNSxL has a structure adapted from that of the DNS reverse mapping, used to map IP addresses to domain names in the IN-ADDR.ARPA tree [RFC1034]." > Each IPv4 address listed in the DNSxL has a corresponding DNS entry. > The entry's name is created by reversing the order of the octets of > the text representation of the IP address, and appending the domain > name of the DNSxL. > > If, for example, the DNSxL is called bad.example.com, and the IPv4 > address to be listed is 192.0.2.99, the name of the DNS entry would > be 99.2.0.192.bad.example.com. Each entry in the DNSxL MUST have an > A record. DNSBLs SHOULD have a TXT record that describes the reason > for the entry. DNSWLs MAY have a TXT record that describes the Clarify "a TXT record" -> "a TXT record per entry". > reason for the entry. The contents of the A record MUST NOT be used > as an IP address. The A record contents conventionally has the value Well, by definition, it is an IP address. It shouldn't become the destination of traffic, though. Given this sematic overlay and the discussion around the draft, a short explanation mught be due giving the history of why A RRs were reused here (that is, the gethostbyname() like DNS interface in MTAs). > used in a scoring spam filter. The DNS records for this entry might > be: > > 99.2.0.192.bad.example.com A 127.0.0.2 > 99.2.0.192.bad.example.com TXT > "Dynamic address, see http://bad.example.com?192.0.2.99" Zone file format should have trailing dots for FQDNs and should follow the RFC 1034 multi-line syntax using "(" and ")". > Some DNSxLs use the same TXT record for all entries, while others > provide a different TXT record for each entry or range of entries Since a record includes the owner, what is "the same" here is probably only the data. > If a range of addresses is listed in the DNSxL, the DNSxL MUST > contain an A record (or a pair of A and TXT records) for every The language appears a bit inconsistent. The introduction stated that "a DNSxL is a zone", later it says "Each IPv4 address listed in the DNSxL has a corresponding DNS entry", now "the DNSxL MUST contain an A record [...] for every address in the DNSxL. I believe the expectation is that the DNS interface provides a consistent and complete mapping of the DNSxL. > address in the DNSxL. Conversely, if an IP address is not listed in > the DNSxL, there MUST NOT be any records for the address. I believe the expectation is even stronger, i.e., an NXDOMAIN response (rather than NOERROR/NODATA for empty non terminals). Therefore, the entry MUST NOT exist. > 2.3. Combined IP address DNSxL > There are three common methods of representing a DNSxL with multiple > sublists: subdomains, multiple A records, and bit encoded entries. > DNSxLs with sublists SHOULD use both subdomains and one of the other > methods. Does using both methods imply that there are two interfaces to the data and the multiple A RRs or "bit encoded entries" are to applied to the "main" list in addition to the sublists? > 2.4. IPv6 DNSxLs > For example, to represent the address: > > 2001:db8:1:2:3:4:567:89ab > > in the DNSxL ugly.example.com, the entry might be: > > b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2. > ugly.example.com. A 127.0.0.2 > TXT "Spam received." It's tough to represent these v6 induced domain names syntactically correct and RFC 3596 doesn't really help, unfortunately. > A single DNSxL could in principle contain both IPv4 and IPv6 > addresses, since the different lengths prevent any ambiguity. If a > DNSxL is represented using traditional zone files and wildcards, > there is no way to specify the length of the name that a wildcard > matches, so wildcard names would indeed be ambiguous for DNSxLs > served in that fashion. Operators should be pointed to RFC 4592 for wildcard syntax and semantics. That said, I see little "ambiguity" with wildcards, but an overlap of the namespaces used for v4 and v6, at least for 0/8 thru 9/8. > 3. Domain name DNSxLs > invalid.edu.doms.example.net A 127.0.0.2 > invalid.edu.doms.example.net TXT "Host name used in phish" > > Name-based DNSBLs are far less common than IP address based DNSBLs. > There is no agreed convention for wildcards. The problem is less with wildcards, but with the semantics of the listing, i.e., whether a domain name found in an email is "stripped" down to two components or not (better not). > 4. DNSxL cache behavior > > The per-record time-to-live and zone refresh intervals of DNSBLs and > DNSWLs vary greatly depending on the management policy of the list. > The TTL and refresh times SHOULD be chosen to reflect the expected > rate of change of the DNSxL. A list of IP addresses assigned to > dynamically allocated dialup and DHCP users could be expected to > change slowly, so the TTL might be several days and the zone > refreshed once a day. On the other hand, a list of IP addresses that > had been observed sending spam might change every few minutes, with > comparably short TTL and refresh intervals. The issues of RR TTLs and SOA refresh should be separated, because the refresh value depends on other factors but update frequency alone. In addition, the negTTL value should be in line with the (positive) TTL values and it should be made clear that "low" TTLs only apply to A and TXT RRs, not the NS RRSet. > 5. Test and contact addresses > > IPv4 based DNSxLs MUST contain an entry for 127.0.0.2 for testing > purposes. IPv4 based DNSxLs MUST NOT contain an entry for 127.0.0.1. > > DNSBLs that return multiple values SHOULD have multiple test > addresses so that, for example, a DNSBL that can return 127.0.0.5 > would have a test record for 127.0.0.5 that returns an A record with > the value 127.0.0.5, and a corresponding TXT record. That implies that 127.0.0.1 MUST NOT appear in an A RR. > IPv6 based DNSxLs MUST contain an entry for ::FFFF:7F00:2 (::FFFF: > 127.0.0.2), and MUST NOT contain an entry for ::FFFF:7F00:1 (::FFFF: > 127.0.0.1), the IPv4-Mapped IPv6 Address [RFC4291] equivalents of the > IPv4 test addresses. Is this a new suggestion or already used anywhere? Also, would the previous paragraph about providing TXT RRs explaining the A RR value semantics apply here, as well? > DNSxLs also MAY contain A and/or AAAA records at the apex of the > DNSxL zone that point to a web server, so that anyone wishing to > learn about the bad.example.net DNSBL can check > http://bad.example.net. Again, "zone" and "zone apex" are the wrong terms. Also, what about the sublists? Should there be address records for "malware.bad.example.net" and "relay.bad.example.net"? > The combination of a test address that MUST exist and an address that > MUST NOT exist allows a client system to check that a domain still > contains DNSxL data, and to defend against DNSxLs which deliberately > or by accident install a wildcard that returns an A record for all > queries. DNSxL clients SHOULD periodically check appropriate test > entries to ensure that the DNSxLs they are using are still operating. What are appropriate intervals for "periodically" and are MTAs expected to keep state? > 6. Typical usage of DNSBLs and DNSWLs > The mail server uses its normal local DNS cache to limit traffic to > the DNSxL servers and to speed up retests of IP addresses recently > seen. Long-running mail servers MAY cache DNSxL data internally, but > MUST respect the TTL values and discard expired records. Not sure I agree this is a good idea, but _if_ MTAs have their own cache, it SHOULD implement negative caching, as well. > An alternate approach is to check DNSxLs in a spam filtering package > after a message has been received. In that case, the IP(s) to test NIT: s/IP(s)/IP address(es)/ > 7. Security Considerations > Since DNSxL users usually make a query for every incoming e-mail > message, the operator of a DNSxL can extract approximate mail volume > statistics from the DNS server logs. This has been used in a few > instances to estimate the amount of mail individual IP addresses or > IP blocks send[SENDERBASE] [KSN]. By correlating the querying MTA's address with the data queried for, not only mail volumes, but also communication matrices can be observed. Submitting URL extracted domain names from mail bodies to a DNSBL server may expose otherwise confidential data. There is also a DoS potential with mails containing (long) lists of URIs or domain names. > As with any other DNS based services, DNSBLs and DNSWLs are subject > to various types of DNS attacks which are described in [RFC3833]. During the duiscussion of the draft we've seen arguments whether or not DNSSEC would be deployable (load wise) for DNSxLs. I think some of this should be reflected in this section. The use of URIs found in TXT RRs should only happen with due care. > 8. References > > 8.1. Normative References > > [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", > STD 13, RFC 1034, November 1987. > > [RFC1035] Mockapetris, P., "Domain names - implementation and > specification", STD 13, RFC 1035, November 1987. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS > Names", BCP 32, RFC 2606, June 1999. That's usually an informational one. ----------------------------------------------------------------------------- In total, the draft seems to reflect the IPv4 situation quite well but has room for improvement in terminology and with regard to some of the technical details. The level of experience with v6 BLs appears to be rather low and if the document tries to extrapolate from v4 to set precedents for v6, it should state that more clearly. The security considerations section needs more work. This draft and the operational guidelines mentioned in it should be evaluated together. In total, I'm not aware of any current work items this draft interferes with, but the topic at hand falls into the charters of both v6ops and dnsop, so I'd recommend to have it formally reviewed in these groups. Procedurally, I neither think the v4 part is actual research, nor do I think the Independent stream is an appropriate way forward once the IETF review has shown severe lack of consensus. -Peter --oC1+HKm2/end4ao3 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir --oC1+HKm2/end4ao3-- From dns-dir-bounces@ietf.org Thu Dec 11 04:05:10 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB5693A6A89; Thu, 11 Dec 2008 04:05:10 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699723A6A89 for ; Thu, 11 Dec 2008 04:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28xoD2sG6vn2 for ; Thu, 11 Dec 2008 04:05:08 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 7EA1F3A67B3 for ; Thu, 11 Dec 2008 04:05:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,753,1220241600"; d="scan'208";a="154165543" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 11 Dec 2008 07:04:58 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Dec 2008 07:04:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Dec 2008 13:04:56 +0100 Message-ID: In-Reply-To: <20081211114619.GF30676@unknown.office.denic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dns-dir] Status/Review of draft-irtf-asrg-dnsbl-08 Thread-Index: Aclbhh7L/CJNfca2QuaO7oc0n3LVNgAAf5lw References: <20081211114619.GF30676@unknown.office.denic.de> From: "Romascanu, Dan (Dan)" To: "Peter Koch" , "IETF DNS Directorate" Subject: Re: [dns-dir] Status/Review of draft-irtf-asrg-dnsbl-08 X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Peter, Can you be more exact with respect to > even though I cannot > prove it conflicts with an IETF WG's work, I could imagine > both v6ops and dnsop could cover parts of it. This is the principal call that the IESG is required to make, beyond making sure that the publication of the document does not cause harm to the Internet, but in order for me or another of the ADs to raise the issue under the form of a DISCUSS we need more substance about where the possible conflicts are. Also, have you forwarded your review to the document authors? If not I suggest you to do it, and copy the RFC Editor as well. Thanks and Regards, Dan > -----Original Message----- > From: dns-dir-bounces@ietf.org > [mailto:dns-dir-bounces@ietf.org] On Behalf Of Peter Koch > Sent: Thursday, December 11, 2008 1:46 PM > To: IETF DNS Directorate > Subject: [dns-dir] Status/Review of draft-irtf-asrg-dnsbl-08 > > DNS-Dir, > > we've been discussing draft-irtf-asrg-dnsbl-08.txt "DNS > Blacklists and Whitelists" > and its predecessors here. In Minneapolis I talked to both > Lisa and Aaron. > Lisa told me that the draft would not continue on its way to > PS, but would go for informational instead. From Aaron I > understood he was planning to publish it under the IRTF > stream (which would imply Informational, in this case). > > Current state is that it's an RFC Ed Independent Submission > aiming at Informational. > > Process wise this concerns me because even though I cannot > prove it conflicts with an IETF WG's work, I could imagine > both v6ops and dnsop could cover parts of it. Also, the > "accompanying document" is missing. So, this isn't strictly > an end run around the IETF, but still trying to avoid some > pushback and correction. But that might be part of my > sentiment against the Independent Stream. > For the IRTF strem I'd be equally unhappy, less for the > Stream per se, but for a research group that tries to > document and influence current practice. > > FWIW, here's a review of -08. > > -Peter > _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Fri Dec 12 00:20:57 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8833A6AD6; Fri, 12 Dec 2008 00:20:57 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F7E3A6AD6; Fri, 12 Dec 2008 00:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 3BaGIKbv6iJ7; Fri, 12 Dec 2008 00:20:55 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id C27373A6A9F; Fri, 12 Dec 2008 00:20:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,210,1228107600"; d="scan'208";a="131167823" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Dec 2008 03:20:46 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Dec 2008 03:20:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Dec 2008 09:20:42 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for December 18, 2008 Telechat Thread-Index: Aclb6eyKHjn9JLtuRi6ksvP7QMGqDAASEiSg From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , "IETF DNS Directorate" Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for December 18, 2008 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Please find below the preliminary agenda of the 12/18 telechat. Please review the relevant documents and let me know if there are any concerns or comments until 12/17 COB the latest. Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-tcpm-tcp-uto-10.txt TCP User Timeout Option (Proposed Standard) - 1 of 12 Token: Magnus Westerlund o draft-ietf-forces-protocol-19.txt ForCES Protocol Specification (Proposed Standard) - 2 of 12 Token: Ross Callon o draft-ietf-forces-mib-10.txt ForCES MIB (Proposed Standard) - 3 of 12 Token: Ross Callon o draft-ietf-calsify-rfc2445bis-09.txt Internet Calendaring and Scheduling Core Object Specification (iCalendar) (Proposed Standard) - 4 of 12 Token: Lisa Dusseault o draft-ietf-mext-nemo-v4traversal-06.txt Mobile IPv6 Support for Dual Stack Hosts and Routers (Proposed Standard) - 5 of 12 Token: Jari Arkko o draft-ietf-nfsv4-rpc-netid-05.txt IANA Considerations for RPC Net Identifiers and Universal Address Formats (Proposed Standard) - 6 of 12 Note: Document Shepherd: Spencer Shepler (shepler@storspeed.com) Token: Lars Eggert o draft-ietf-ospf-lls-05.txt OSPF Link-local Signaling (Proposed Standard) - 7 of 12 Token: David Ward o draft-ietf-smime-3851bis-08.txt Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification (Proposed Standard) - 8 of 12 Token: Tim Polk o draft-ietf-smime-3850bis-08.txt Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling (Proposed Standard) - 9 of 12 Token: Tim Polk o draft-ietf-pkix-ecc-subpubkeyinfo-10.txt Elliptic Curve Cryptography Subject Public Key Information (Proposed Standard) - 10 of 12 Note: Document shepherd is stefans@microsoft.com Token: Pasi Eronen o draft-freed-sieve-ihave-03.txt Sieve Email Filtering: Ihave Extension (Proposed Standard) - 11 of 12 Token: Lisa Dusseault o draft-ietf-mpls-cosfield-def-08.txt Multi-Protocol Label Switching (MPLS) label stack entry: "EXP" field renamed to "Traffic Class" field (Proposed Standard) - 12 of 12 Token: Ross Callon 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-kucherawy-sender-auth-header-18.txt Message Header Field for Indicating Message Authentication Status (Proposed Standard) - 1 of 1 Token: Lisa Dusseault 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-mpls-ldp-igp-sync-03.txt LDP IGP Synchronization (Informational) - 1 of 3 Token: David Ward o draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt OSPFv3 Based Layer 1 VPN Auto-Discovery (Experimental) - 2 of 3 Token: David Ward o draft-ietf-roll-urban-routing-reqs-02.txt Urban WSNs Routing Requirements in Low Power and Lossy Networks (Informational) - 3 of 3 Token: David Ward _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Wed Dec 17 09:45:24 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 656F928C1C6; Wed, 17 Dec 2008 09:45:24 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B37A28C1C5 for ; Wed, 17 Dec 2008 09:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.555 X-Spam-Level: X-Spam-Status: No, score=-5.555 tagged_above=-999 required=5 tests=[AWL=0.694, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp7ZTTfJosFW for ; Wed, 17 Dec 2008 09:45:22 -0800 (PST) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 5A0AD28C1B8 for ; Wed, 17 Dec 2008 09:45:22 -0800 (PST) Received: from unknown.office.denic.de ([10.122.65.4]) by office.denic.de with esmtp id 1LD0SP-0003Zt-4E; Wed, 17 Dec 2008 18:45:13 +0100 Received: by unknown.office.denic.de (Postfix, from userid 501) id 0E78711AA09; Wed, 17 Dec 2008 18:45:12 +0100 (CET) Date: Wed, 17 Dec 2008 18:45:12 +0100 From: Peter Koch To: "Romascanu, Dan (Dan)" Message-ID: <20081217174512.GF2147@unknown.office.denic.de> References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: IETF DNS Directorate Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for December 18, 2008 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org On Fri, Dec 12, 2008 at 09:20:42AM +0100, Romascanu, Dan (Dan) wrote: > Please find below the preliminary agenda of the 12/18 telechat. Please > review the relevant documents and let me know if there are any concerns > or comments until 12/17 COB the latest. the only draft that dealt with DNS was > 2.2 Individual Submissions > 2.2.1 New Item > o draft-kucherawy-sender-auth-header-18.txt > Message Header Field for Indicating Message Authentication Status > (Proposed > Standard) - 1 of 1 > Token: Lisa Dusseault The draft has issues with terminology, when it again uses 'domain' as a synonym for an organization - even though it goes the laudable approach of re-introducing the term ADMD (which reminds me of X.400, again). More to the protocol level, the references to DNS error conditions in sections 2.4.3 and 2.4.4 as well as 3 need a bit more thought; I'll add details tomorrow but would appreciate if another Dir member could have a look into this before. Regards, Peter _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Dec 18 04:56:20 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 792CF3A69AA; Thu, 18 Dec 2008 04:56:20 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97C53A69AA for ; Thu, 18 Dec 2008 04:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSInEe+-lo0S for ; Thu, 18 Dec 2008 04:56:17 -0800 (PST) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 78ADA3A69A2 for ; Thu, 18 Dec 2008 04:56:17 -0800 (PST) Received: from unknown.office.denic.de ([10.122.65.4]) by office.denic.de with esmtp id 1LDIQ7-0002vU-HK; Thu, 18 Dec 2008 13:56:03 +0100 Received: by unknown.office.denic.de (Postfix, from userid 501) id 73DAE11AD25; Thu, 18 Dec 2008 13:56:03 +0100 (CET) Date: Thu, 18 Dec 2008 13:56:03 +0100 From: Peter Koch To: "Romascanu, Dan (Dan)" Message-ID: <20081218125603.GD2533@unknown.office.denic.de> References: <20081217174512.GF2147@unknown.office.denic.de> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20081217174512.GF2147@unknown.office.denic.de> User-Agent: Mutt/1.4.2.1i Cc: IETF DNS Directorate Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for December 18, 2008 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org On Wed, Dec 17, 2008 at 06:45:12PM +0100, Peter Koch wrote: > > o draft-kucherawy-sender-auth-header-18.txt > > Message Header Field for Indicating Message Authentication Status > > (Proposed > > Standard) - 1 of 1 > > Token: Lisa Dusseault > > The draft has issues with terminology, when it again uses 'domain' as a synonym > for an organization - even though it goes the laudable approach of re-introducing > the term ADMD (which reminds me of X.400, again). 1.2 says: This document makes several references to the "trust boundary" of an administrative mail domain (ADMD). Given the diversity among existing mail environments, a precise definition of this term isn't possible. Fine, although the relation to X.400 ADMDs might be worth noting to appreciate the historical parallels. The problem I see is that later in the document the term isn't used consistently, but instead "domain" again appears as an acting entity, as in [2.4.3] "none: No policy records were published by the sender's domain". There is a fundamental and reoccuring disagreement about the nature of "a domain" between the DNS and the Mail community, which is fine as long as each group is having internal conversation. At the overlap areas we have this issue over and over again and I'd really appreciate if that issue would be wider acknowledged and addressed. This isn't only about wording, but also about implications of hierarchy, administrative boundaries, setting "domain wide" defaults and so on. cf. the DKIM debates and others. That said, introducing "ADMD" seems to be a good way forward, if it's used consistentnly and if the distinctions between an ADMD and a (DNS) domain are dealt with properly. Nit: 1.6 has a conflicting expansion of ADMD (s/Mail/Management/). > More to the protocol level, the references to DNS error conditions in sections > 2.4.3 and 2.4.4 as well as 3 need a bit more thought; I'll add details tomorrow > but would appreciate if another Dir member could have a look into this before. 2.4.4 defines the "iprev" method of "authentication" (which reminds me of our, dnsop's, reverse mapping draft under consideration). I can't tell the difference between softfail: The reverse DNS evaluation failed. In particular, one or both of the "reverse" and forward lookups returned no data (i.e. a DNS reply code of NODATA). and permerror: The reverse DNS evaluation could not be completed due to some error which is unrecoverable (e.g. a DNS reply code of NODATA or NXDOMAIN). A later attempt is unlikely to produce a final result. First, there is no real reply code of NODATA (the description is usually NOERROR/NODATA, meaning NOERROR and empty answer section), but it's unclear to me what the author really want's to achieve here. The description of the "iprev" method in section 3 defers details to RFC 4408, which is an experimental RFC, while the draft under consideration aims at proposed. Also, there's the conceptuyal/terminology issue again: A successful test using this algorithm constitutes a result of "pass" since the domain in which the client's PTR claims it belongs has confirmed that claim. A failure to match constitutes a "hardfail". It isn't that the match acknowledges the membership in some kind of administrative boundary; it's just a consistency check of some limited value. The whole discussion should take into account the long debate that has taken place in DNSOP regarding the draft-ietf-dnsop-reverse-mapping-considerations draft. This is currently expired, but will be revived and WGLCed "soon". -Peter _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Thu Dec 18 10:30:04 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319BE28C0EA; Thu, 18 Dec 2008 10:30:04 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49CEE3A6B9E for ; Thu, 18 Dec 2008 10:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 0aWtaDr4ttfl for ; Thu, 18 Dec 2008 10:30:02 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 0AE653A6A1E for ; Thu, 18 Dec 2008 10:30:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,244,1228107600"; d="scan'208";a="131955774" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Dec 2008 13:29:49 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 18 Dec 2008 13:29:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Dec 2008 19:29:46 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: draft-kucherawy-sender-auth-header Thread-Index: AclhPlgEgJZw+DNLSrCiqwDBYE4V8AAAC0WA From: "Romascanu, Dan (Dan)" To: "IETF DNS Directorate" Cc: msk+ietf@sendmail.com Subject: [dns-dir] FW: DISCUSS and COMMENT: draft-kucherawy-sender-auth-header X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org Murray's response to Peter's review. Dan -----Original Message----- From: Murray S. Kucherawy [mailto:msk@sendmail.com] Sent: Thursday, December 18, 2008 8:28 PM To: Romascanu, Dan (Dan) Cc: iesg@ietf.org; tony@att.com; draft-kucherawy-sender-auth-header@tools.ietf.org Subject: Re: DISCUSS and COMMENT: draft-kucherawy-sender-auth-header On Thu, 18 Dec 2008, Dan Romascanu wrote: > That said, introducing "ADMD" seems to be a good way forward, if it's > used consistentnly and if the distinctions between an ADMD and a (DNS) > domain are dealt with properly. Slightly unfamiliar territory for me, but I've got some help with it lined up. I'll send a diff to the current draft which addresses this after I've sorted it out. > 2. More to the protocol level, the references to DNS error conditions > in sections 2.4.3 and 2.4.4 as well as 3 need a bit more thought. > [...] Same (though the territory is more familiar). > 3. The description of the "iprev" method in section 3 defers details > to RFC 4408, which is an experimental RFC, while the draft under > consideration aims at Proposed. The reference is informative discussion only. Isn't the down-reference restriction applicable only to normative language? > It isn't that the match acknowledges the membership in some kind of > administrative boundary; it's just a consistency check of some limited > value. The whole discussion should take into account the long debate > that has taken place in DNSOP regarding the > draft-ietf-dnsop-reverse-mapping-considerations draft. This is > currently expired, but will be revived and WGLCed "soon". Thanks, this looks like a useful reference as well. > Comment: > Nit: 1.6 has a conflicting expansion of ADMD (s/Mail/Management/). Will be fixed in the next version. _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir From dns-dir-bounces@ietf.org Sun Dec 28 23:41:01 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE35F28C237; Sun, 28 Dec 2008 23:41:01 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E0028C125; Tue, 16 Dec 2008 00:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_72=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 t3CnjCSCaNE8; Tue, 16 Dec 2008 00:27:06 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 070EA28C0F8; Tue, 16 Dec 2008 00:27:06 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBY001QBNCCE5@szxga04-in.huawei.com>; Tue, 16 Dec 2008 16:24:12 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBY001I8NCCUF@szxga04-in.huawei.com>; Tue, 16 Dec 2008 16:24:12 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KBY007P9NCC1O@szxml05-in.huawei.com>; Tue, 16 Dec 2008 16:24:12 +0800 (CST) Date: Tue, 16 Dec 2008 16:24:07 +0800 From: Tina TSOU To: IETF DNS Directorate , ops-dir@ietf.org, "MIB Doctors (E-mail)" , aaa-doctors@ietf.org, "Romascanu, Dan (Dan)" Message-id: <015f01c95f57$ace5bae0$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: X-Mailman-Approved-At: Sun, 28 Dec 2008 23:41:01 -0800 Subject: Re: [dns-dir] [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18, 2008 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1326605591==" Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org This is a multi-part message in MIME format. --===============1326605591== Content-type: multipart/alternative; boundary="Boundary_(ID_mnkrxHfAPXSs++w409+qww)" This is a multi-part message in MIME format. --Boundary_(ID_mnkrxHfAPXSs++w409+qww) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Dan et al, Review of draft-ietf-tcpm-tcp-uto-10 is below. --------- Review Questions: Is the document readable? [Tina: Yes.] Does it contain nits? [Tina: 1) The connectivity sometimes appears as "connectivity", sometimes appears as "E2E connectivity". Should they be put consistent? Or does it mean intra-net, internet respectively? 2) Should "application-specified user timeout"be "application-specific user timeout"? 3) Section 3, "Performing these steps before an active or passive open causes UTO options to be exchanged in the SYN and SYN-ACK packets and is a reliable way to initially exchange, and potentially adapt to, UTO values." Should "active" be "proactive"? 4) Section 5, "Several approaches can help mitigate this issue." Should "mitigate" be "mitigating"?] Is the document class appropriate? [Tina: Yes.] Is the problem well stated? [Tina: what's the real benefit to the network? In the document, I see that the timeout can be changed bigger or smaller, but it is already in the network by configuration. The only benefit is that this timeout change can be advertised from one end to the other, and then the other end could use it as an input to compute its own timeout. It is not a big benefit, IMHO.] Is the problem really a problem? [Tina: concern is as above.] Does the document consider existing solutions? [Tina: yes, it does. However, same concern is as above.] Does the solution break existing technology? [Tina: No.] Does the solution preclude future activity? [Tina: No.] Is the solution sufficiently configurable? [Tina: I would like to see clearer procedure in this document. For example, Should the timeout be configured in the server, and then in the SYS segment, when the client requests, the server returns the time out to client? It is because one server has many unknown clients.] Can performance be measured? How? [Tina: it does not show very well in the document.] Does the solution scale well? [Tina: Yes.] ---------------- Wish you a joyful greeting season! :D B. R. Tina ----- Original Message ----- From: Romascanu, Dan (Dan) To: aaa-doctors@ietf.org ; MIB Doctors (E-mail) ; ops-dir@ietf.org ; IETF DNS Directorate Sent: Friday, December 12, 2008 4:20 PM Subject: [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18,2008 Telechat Please find below the preliminary agenda of the 12/18 telechat. Please review the relevant documents and let me know if there are any concerns or comments until 12/17 COB the latest. Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-tcpm-tcp-uto-10.txt TCP User Timeout Option (Proposed Standard) - 1 of 12 Token: Magnus Westerlund o draft-ietf-forces-protocol-19.txt ForCES Protocol Specification (Proposed Standard) - 2 of 12 Token: Ross Callon o draft-ietf-forces-mib-10.txt ForCES MIB (Proposed Standard) - 3 of 12 Token: Ross Callon o draft-ietf-calsify-rfc2445bis-09.txt Internet Calendaring and Scheduling Core Object Specification (iCalendar) (Proposed Standard) - 4 of 12 Token: Lisa Dusseault o draft-ietf-mext-nemo-v4traversal-06.txt Mobile IPv6 Support for Dual Stack Hosts and Routers (Proposed Standard) - 5 of 12 Token: Jari Arkko o draft-ietf-nfsv4-rpc-netid-05.txt IANA Considerations for RPC Net Identifiers and Universal Address Formats (Proposed Standard) - 6 of 12 Note: Document Shepherd: Spencer Shepler (shepler@storspeed.com) Token: Lars Eggert o draft-ietf-ospf-lls-05.txt OSPF Link-local Signaling (Proposed Standard) - 7 of 12 Token: David Ward o draft-ietf-smime-3851bis-08.txt Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification (Proposed Standard) - 8 of 12 Token: Tim Polk o draft-ietf-smime-3850bis-08.txt Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling (Proposed Standard) - 9 of 12 Token: Tim Polk o draft-ietf-pkix-ecc-subpubkeyinfo-10.txt Elliptic Curve Cryptography Subject Public Key Information (Proposed Standard) - 10 of 12 Note: Document shepherd is stefans@microsoft.com Token: Pasi Eronen o draft-freed-sieve-ihave-03.txt Sieve Email Filtering: Ihave Extension (Proposed Standard) - 11 of 12 Token: Lisa Dusseault o draft-ietf-mpls-cosfield-def-08.txt Multi-Protocol Label Switching (MPLS) label stack entry: "EXP" field renamed to "Traffic Class" field (Proposed Standard) - 12 of 12 Token: Ross Callon 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-kucherawy-sender-auth-header-18.txt Message Header Field for Indicating Message Authentication Status (Proposed Standard) - 1 of 1 Token: Lisa Dusseault 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-mpls-ldp-igp-sync-03.txt LDP IGP Synchronization (Informational) - 1 of 3 Token: David Ward o draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt OSPFv3 Based Layer 1 VPN Auto-Discovery (Experimental) - 2 of 3 Token: David Ward o draft-ietf-roll-urban-routing-reqs-02.txt Urban WSNs Routing Requirements in Low Power and Lossy Networks (Informational) - 3 of 3 Token: David Ward _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir --Boundary_(ID_mnkrxHfAPXSs++w409+qww) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Hi Dan et al,
Review of draft-ietf-tcpm-tcp-uto-10 is = below.
 
 ---------
Review = Questions:
 
Is the document readable?
[Tina:=20 Yes.]
 
Does it contain nits?
[Tina: =
1) The=20 connectivity sometimes appears as =93connectivity=94, sometimes appears = as =93E2E=20 connectivity=94. Should they be put consistent? Or does it mean = intra-net,=20 internet respectively?
2) Should =93application-specified user = timeout=93be=20 =93application-specific user timeout=94?
3) 
Section = 3,
=93Performing=20 these steps before an active or passive open causes UTO options to be = exchanged=20 in the SYN and SYN-ACK packets and is a reliable way to initially = exchange, and=20 potentially adapt to, UTO   values.=94 
Should = =93active=94 be=20 =93proactive=94?
4) Section 5,
=93Several approaches can help = mitigate this=20 issue.=94
Should =93mitigate=94 be =93mitigating=94?]
 
Is the document class = appropriate?
[Tina:=20 Yes.]
 
Is the problem well stated?
[Tina: = what=92s the=20 real benefit to the network? In the document, I see that the timeout can = be=20 changed bigger or smaller, but it is already in the network by = configuration.=20 The only benefit is that this timeout change can be advertised from one = end to=20 the other, and then the other end could use it as an input to compute = its own=20 timeout. It is not a big benefit, IMHO.]
 
Is the problem really a = problem?
[Tina: concern=20 is as above.]
 
Does the document consider existing=20 solutions?
[Tina: yes, it does. However, same concern is as=20 above.]
 
Does the solution break existing=20 technology?
[Tina: No.]
 
Does the solution preclude future=20 activity?
[Tina: No.]
 
Is the solution sufficiently=20 configurable?
[Tina: I would like to see clearer procedure in this = document.=20 For example,
Should the timeout be configured in the server, and then = in the=20 SYS segment, when the client requests, the server returns the time out = to=20 client? It is because one server has many unknown clients.]
 
Can performance be measured?  = How?
[Tina:=20 it does not show very well in the document.]
 
Does the solution scale well?
[Tina: = Yes.]
 ----------------
 
Wish you a joyful greeting season! :D
 
B. R.
Tina
----- Original Message -----
From:=20 Romascanu, Dan=20 (Dan)
To: aaa-doctors@ietf.org ; MIB = Doctors=20 (E-mail) ; ops-dir@ietf.org ; IETF DNS = Directorate=20
Sent: Friday, December 12, 2008 = 4:20=20 PM
Subject: [OPS-DIR] FW: = PRELIMINARY Agenda=20 and Package for December 18,2008 Telechat

Please find below the preliminary agenda of the 12/18 = telechat.=20 Please
review the relevant documents and let me know if there are = any=20 concerns
or comments until 12/17 COB the latest.

Thanks and = Regards,

Dan


-----Original Message-----
From: iesg-bounces@ietf.org=20 [mailto:iesg-bounces@ietf.org] On Behalf Of
IESG = Secretary


2.=20 Protocol Actions
Reviews should focus on these questions: "Is this = document=20 a
reasonable basis on which to build the salient part of=20 the
Internet
infrastructure? If not, what changes would make it=20 so?"


2.1 WG Submissions
2.1.1 New Item
  o=20 draft-ietf-tcpm-tcp-uto-10.txt
    TCP User Timeout = Option=20 (Proposed Standard) - 1 of 12
    Token: Magnus=20 Westerlund
  o = draft-ietf-forces-protocol-19.txt
   =20 ForCES Protocol Specification (Proposed Standard) - 2 of 12=20
    Token: Ross Callon
  o=20 draft-ietf-forces-mib-10.txt
    ForCES MIB = (Proposed=20 Standard) - 3 of 12
    Token: Ross = Callon
  o=20 draft-ietf-calsify-rfc2445bis-09.txt
    Internet=20 Calendaring and Scheduling Core Object Specification
(iCalendar)=20
    (Proposed Standard) - 4 of 12 =
   =20 Token: Lisa Dusseault
  o=20 draft-ietf-mext-nemo-v4traversal-06.txt
    Mobile = IPv6=20 Support for Dual Stack Hosts and Routers (Proposed
Standard) -=20
    5 of 12
    Token: Jari=20 Arkko
  o = draft-ietf-nfsv4-rpc-netid-05.txt
    IANA=20 Considerations for RPC Net Identifiers and Universal = Address
Formats=20
    (Proposed Standard) - 6 of 12 =
   =20 Note: Document Shepherd: Spencer Shepler (shepler@storspeed.com)=20
    Token: Lars Eggert
  o=20 draft-ietf-ospf-lls-05.txt
    OSPF Link-local = Signaling=20 (Proposed Standard) - 7 of 12
    Token: David=20 Ward
  o draft-ietf-smime-3851bis-08.txt
    = Secure/Multipurpose Internet Mail Extensions (S/MIME) Version = 3.2
Message=20
    Specification (Proposed Standard) - 8 of 12=20
    Token: Tim Polk
  o=20 draft-ietf-smime-3850bis-08.txt
    = Secure/Multipurpose=20 Internet Mail Extensions (S/MIME) Version 3.2
   =20 Certificate Handling (Proposed Standard) - 9 of 12 =
   =20 Token: Tim Polk
  o=20 draft-ietf-pkix-ecc-subpubkeyinfo-10.txt
    = Elliptic Curve=20 Cryptography Subject Public Key Information=20 (Proposed

    Standard) - 10 of 12=20
    Note: Document shepherd is stefans@microsoft.com=20
    Token: Pasi Eronen
  o=20 draft-freed-sieve-ihave-03.txt
    Sieve Email = Filtering:=20 Ihave Extension (Proposed Standard) - 11 = of
12

   =20 Token: Lisa Dusseault
  o=20 draft-ietf-mpls-cosfield-def-08.txt
    = Multi-Protocol Label=20 Switching (MPLS) label stack entry: "EXP" = field

   =20 renamed to "Traffic Class" field (Proposed Standard) - 12 of 12=20
    Token: Ross Callon

2.1.2 Returning=20 Item
NONE

2.2 Individual Submissions
2.2.1 New = Item
  o=20 draft-kucherawy-sender-auth-header-18.txt
    = Message Header=20 Field for Indicating Message Authentication Status
(Proposed=20
    Standard) - 1 of 1
    = Token: Lisa=20 Dusseault

2.2.2 Returning Item
NONE

3. Document=20 Actions

3.1 WG Submissions
Reviews should focus on these = questions:=20 "Is this document a
reasonable
contribution to the area of = Internet=20 engineering which it
covers? If
not, what changes would make it=20 so?"

3.1.1 New Item
  o=20 draft-ietf-mpls-ldp-igp-sync-03.txt
    LDP IGP=20 Synchronization (Informational) - 1 of 3
    Token: = David=20 Ward
  o=20 draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt
    = OSPFv3=20 Based Layer 1 VPN Auto-Discovery (Experimental) - 2 of 3=20
    Token: David Ward
  o=20 draft-ietf-roll-urban-routing-reqs-02.txt
    Urban = WSNs=20 Routing Requirements in Low Power and Lossy Networks =
   =20 (Informational) - 3 of 3
    Token: David=20 Ward

_______________________________________________
OPS-DIR = mailing=20 list
OPS-DIR@ietf.org
https://www.ietf.o= rg/mailman/listinfo/ops-dir --Boundary_(ID_mnkrxHfAPXSs++w409+qww)-- --===============1326605591== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir --===============1326605591==-- From dns-dir-bounces@ietf.org Sun Dec 28 23:41:01 2008 Return-Path: X-Original-To: dns-dir-archive@ietf.org Delivered-To: ietfarch-dns-dir-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D539C28C23D; Sun, 28 Dec 2008 23:41:01 -0800 (PST) X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE763A6A7B; Tue, 16 Dec 2008 20:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.682 X-Spam-Level: X-Spam-Status: No, score=-0.682 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, 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 JJnJ5t85PxFo; Tue, 16 Dec 2008 20:08:06 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id BD09F3A6A7A; Tue, 16 Dec 2008 20:08:05 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KC0001JO64ZSO@szxga01-in.huawei.com>; Wed, 17 Dec 2008 12:07:48 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KC000M9C64ZF5@szxga01-in.huawei.com>; Wed, 17 Dec 2008 12:07:47 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KC0009H264ZFV@szxml05-in.huawei.com>; Wed, 17 Dec 2008 12:07:47 +0800 (CST) Date: Wed, 17 Dec 2008 12:07:47 +0800 From: Tina TSOU To: IETF DNS Directorate , ops-dir@ietf.org, "MIB Doctors (E-mail)" , aaa-doctors@ietf.org, "Romascanu, Dan (Dan)" Message-id: <00d601c95ffd$05192b70$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: X-Mailman-Approved-At: Sun, 28 Dec 2008 23:41:01 -0800 Subject: Re: [dns-dir] [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18, 2008 Telechat X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0690364230==" Sender: dns-dir-bounces@ietf.org Errors-To: dns-dir-bounces@ietf.org This is a multi-part message in MIME format. --===============0690364230== Content-type: multipart/alternative; boundary="Boundary_(ID_6PeqhQavCc/eh21FzWe4sQ)" This is a multi-part message in MIME format. --Boundary_(ID_6PeqhQavCc/eh21FzWe4sQ) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Dan et al, This is a review of Review of draft-ietf-mext-nemo-v4traversal-06 for its operational impact. Summary: The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. Review summary: ----------- Possible Operational Issues: Below are listed a number of issues that may have significant operational impact. Further explanation or investigations is warranted on each of these. --------- Review Questions: Is the document readable? [Tina: Yes] Does it contain nits? [Tina: In section 5.1, 5.4.2, 6.2.1, vanilla occurs 6 times and is ambiguous, Should "vanilla UDP encapsulation" be "valid UDP encapsulation" ] Is the document class appropriate? [Tina: Yes.] Is the problem well stated? [Tina: In section 5.3, it mentioned that if the mobile node is not active, it will send binding update to the home agent, I'm wondering what home agent operates upon receiving the binding update message? Also if the mobile node is not active, does it mean the mobile node is not reachable? And in section 5.3, it mentions that the mobile node maintains NAT binding, if the mobile node is not reachable, then it need not to refresh the NAT binding? What I confuse here is that NAT device also maintains NAT binding associated with the mobile node, so if the mobile node is not reachable, whether the mobile node refreshes the NAT binding in itself or in NAT on the path between the mobile node and the home agent? Moreover if the mobile node is not reachable, does it mean the mobile node change the port or private address? What's the difference for NAT keep alive between the mobile node behind NAT and the home agent behind NAT?] Is the problem really a problem? [Tina: See comment above.] Does the document consider existing solutions? [Tina: Yes.] Does the solution break existing technology? [Tina: No.] Does the solution preclude future activity? [Tina: No.] Is the solution sufficiently configurable? [Tina: Yes.] Can performance be measured? How? [Tina: Yes.] Does the solution scale well? [Tina: Yes.] ---------------- Wish you a joyful greeting season! :D B. R. Tina ----- Original Message ----- From: Romascanu, Dan (Dan) To: aaa-doctors@ietf.org ; MIB Doctors (E-mail) ; ops-dir@ietf.org ; IETF DNS Directorate Sent: Friday, December 12, 2008 4:20 PM Subject: [OPS-DIR] FW: PRELIMINARY Agenda and Package for December 18,2008 Telechat Please find below the preliminary agenda of the 12/18 telechat. Please review the relevant documents and let me know if there are any concerns or comments until 12/17 COB the latest. Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-tcpm-tcp-uto-10.txt TCP User Timeout Option (Proposed Standard) - 1 of 12 Token: Magnus Westerlund o draft-ietf-forces-protocol-19.txt ForCES Protocol Specification (Proposed Standard) - 2 of 12 Token: Ross Callon o draft-ietf-forces-mib-10.txt ForCES MIB (Proposed Standard) - 3 of 12 Token: Ross Callon o draft-ietf-calsify-rfc2445bis-09.txt Internet Calendaring and Scheduling Core Object Specification (iCalendar) (Proposed Standard) - 4 of 12 Token: Lisa Dusseault o draft-ietf-mext-nemo-v4traversal-06.txt Mobile IPv6 Support for Dual Stack Hosts and Routers (Proposed Standard) - 5 of 12 Token: Jari Arkko o draft-ietf-nfsv4-rpc-netid-05.txt IANA Considerations for RPC Net Identifiers and Universal Address Formats (Proposed Standard) - 6 of 12 Note: Document Shepherd: Spencer Shepler (shepler@storspeed.com) Token: Lars Eggert o draft-ietf-ospf-lls-05.txt OSPF Link-local Signaling (Proposed Standard) - 7 of 12 Token: David Ward o draft-ietf-smime-3851bis-08.txt Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification (Proposed Standard) - 8 of 12 Token: Tim Polk o draft-ietf-smime-3850bis-08.txt Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling (Proposed Standard) - 9 of 12 Token: Tim Polk o draft-ietf-pkix-ecc-subpubkeyinfo-10.txt Elliptic Curve Cryptography Subject Public Key Information (Proposed Standard) - 10 of 12 Note: Document shepherd is stefans@microsoft.com Token: Pasi Eronen o draft-freed-sieve-ihave-03.txt Sieve Email Filtering: Ihave Extension (Proposed Standard) - 11 of 12 Token: Lisa Dusseault o draft-ietf-mpls-cosfield-def-08.txt Multi-Protocol Label Switching (MPLS) label stack entry: "EXP" field renamed to "Traffic Class" field (Proposed Standard) - 12 of 12 Token: Ross Callon 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-kucherawy-sender-auth-header-18.txt Message Header Field for Indicating Message Authentication Status (Proposed Standard) - 1 of 1 Token: Lisa Dusseault 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-mpls-ldp-igp-sync-03.txt LDP IGP Synchronization (Informational) - 1 of 3 Token: David Ward o draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt OSPFv3 Based Layer 1 VPN Auto-Discovery (Experimental) - 2 of 3 Token: David Ward o draft-ietf-roll-urban-routing-reqs-02.txt Urban WSNs Routing Requirements in Low Power and Lossy Networks (Informational) - 3 of 3 Token: David Ward _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir --Boundary_(ID_6PeqhQavCc/eh21FzWe4sQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable
Hi Dan et al,
  This is a review of Review of=20 draft-ietf-mext-nemo-v4traversal-06 for its
  operational=20 impact.
 
  Summary: The current Mobile IPv6 = and NEMO=20 specifications support IPv6 only.
   This specification = extends=20 those standards to allow the registration
   of IPv4 = addresses and=20 prefixes, respectively, and the transport of
   both IPv4 = and IPv6=20 packets over the tunnel to the home agent.  This
  =20 specification also allows the Mobile Node to roam over both IPv6=20 and
   IPv4, including the case where Network Address = Translation=20 is present
   on the path between the mobile node and its = home=20 agent.
 
Review summary:
  = -----------
 =20 Possible Operational Issues: Below are listed a number of issues that = may have=20 significant operational impact. Further explanation or investigations is = warranted on each of these.
 ---------
Review = Questions:
 
Is the document readable?
[Tina:=20 Yes]
 
Does it contain nits?
[Tina:
In = section 5.1,=20 5.4.2, 6.2.1, vanilla occurs 6 times and is ambiguous, Should =93vanilla = UDP=20 encapsulation=94 be =93valid UDP encapsulation=94
]
 
Is the document class = appropriate?
[Tina:=20 Yes.]
 
Is the problem well = stated?
[Tina:
In section=20 5.3, it mentioned that if the mobile node is not active, it will send = binding=20 update to the home agent, I=92m wondering what home agent operates upon = receiving=20 the binding update message? Also if the mobile node is not active, does = it mean=20 the mobile node is not reachable?
And in section 5.3, it mentions = that the=20 mobile node maintains NAT binding, if the mobile node is not reachable, = then it=20 need not to refresh the NAT binding? What I confuse here is that
NAT = device=20 also maintains NAT binding associated with the mobile node, so if the = mobile=20 node is not reachable, whether the mobile node refreshes the NAT binding = in=20 itself or in NAT on the path between the mobile node and the home=20 agent?
Moreover if the mobile node is not reachable, does it mean the = mobile=20 node change the port or private address?
 
What=92s the difference for NAT keep = alive between=20 the mobile node behind NAT and the home agent behind NAT?]
 
Is the problem really a = problem?
[Tina: See=20 comment above.]
 
Does the document consider existing=20 solutions?
[Tina: Yes.]
 
Does the solution break existing=20 technology?
[Tina: No.]
 
Does the solution preclude future=20 activity?
[Tina: No.]
 
Is the solution sufficiently=20 configurable?
[Tina: Yes.]
 
Can performance be measured?  = How?
[Tina:=20 Yes.]
 
Does the solution scale well?
[Tina: = Yes.]
 ----------------
 

Wish you a joyful greeting = season!=20 :D
 
B. R.
Tina
----- Original Message -----
From:=20 Romascanu, Dan=20 (Dan)
To: aaa-doctors@ietf.org ; MIB = Doctors=20 (E-mail) ; ops-dir@ietf.org ; IETF DNS = Directorate=20
Sent: Friday, December 12, 2008 = 4:20=20 PM
Subject: [OPS-DIR] FW: = PRELIMINARY Agenda=20 and Package for December 18,2008 Telechat

Please find below the preliminary agenda of the 12/18 = telechat.=20 Please
review the relevant documents and let me know if there are = any=20 concerns
or comments until 12/17 COB the latest.

Thanks and = Regards,

Dan


-----Original Message-----
From: iesg-bounces@ietf.org=20 [mailto:iesg-bounces@ietf.org] On Behalf Of
IESG = Secretary


2.=20 Protocol Actions
Reviews should focus on these questions: "Is this = document=20 a
reasonable basis on which to build the salient part of=20 the
Internet
infrastructure? If not, what changes would make it=20 so?"


2.1 WG Submissions
2.1.1 New Item
  o=20 draft-ietf-tcpm-tcp-uto-10.txt
    TCP User Timeout = Option=20 (Proposed Standard) - 1 of 12
    Token: Magnus=20 Westerlund
  o = draft-ietf-forces-protocol-19.txt
   =20 ForCES Protocol Specification (Proposed Standard) - 2 of 12=20
    Token: Ross Callon
  o=20 draft-ietf-forces-mib-10.txt
    ForCES MIB = (Proposed=20 Standard) - 3 of 12
    Token: Ross = Callon
  o=20 draft-ietf-calsify-rfc2445bis-09.txt
    Internet=20 Calendaring and Scheduling Core Object Specification
(iCalendar)=20
    (Proposed Standard) - 4 of 12 =
   =20 Token: Lisa Dusseault
  o=20 draft-ietf-mext-nemo-v4traversal-06.txt
    Mobile = IPv6=20 Support for Dual Stack Hosts and Routers (Proposed
Standard) -=20
    5 of 12
    Token: Jari=20 Arkko
  o = draft-ietf-nfsv4-rpc-netid-05.txt
    IANA=20 Considerations for RPC Net Identifiers and Universal = Address
Formats=20
    (Proposed Standard) - 6 of 12 =
   =20 Note: Document Shepherd: Spencer Shepler (shepler@storspeed.com)=20
    Token: Lars Eggert
  o=20 draft-ietf-ospf-lls-05.txt
    OSPF Link-local = Signaling=20 (Proposed Standard) - 7 of 12
    Token: David=20 Ward
  o draft-ietf-smime-3851bis-08.txt
    = Secure/Multipurpose Internet Mail Extensions (S/MIME) Version = 3.2
Message=20
    Specification (Proposed Standard) - 8 of 12=20
    Token: Tim Polk
  o=20 draft-ietf-smime-3850bis-08.txt
    = Secure/Multipurpose=20 Internet Mail Extensions (S/MIME) Version 3.2
   =20 Certificate Handling (Proposed Standard) - 9 of 12 =
   =20 Token: Tim Polk
  o=20 draft-ietf-pkix-ecc-subpubkeyinfo-10.txt
    = Elliptic Curve=20 Cryptography Subject Public Key Information=20 (Proposed

    Standard) - 10 of 12=20
    Note: Document shepherd is stefans@microsoft.com=20
    Token: Pasi Eronen
  o=20 draft-freed-sieve-ihave-03.txt
    Sieve Email = Filtering:=20 Ihave Extension (Proposed Standard) - 11 = of
12

   =20 Token: Lisa Dusseault
  o=20 draft-ietf-mpls-cosfield-def-08.txt
    = Multi-Protocol Label=20 Switching (MPLS) label stack entry: "EXP" = field

   =20 renamed to "Traffic Class" field (Proposed Standard) - 12 of 12=20
    Token: Ross Callon

2.1.2 Returning=20 Item
NONE

2.2 Individual Submissions
2.2.1 New = Item
  o=20 draft-kucherawy-sender-auth-header-18.txt
    = Message Header=20 Field for Indicating Message Authentication Status
(Proposed=20
    Standard) - 1 of 1
    = Token: Lisa=20 Dusseault

2.2.2 Returning Item
NONE

3. Document=20 Actions

3.1 WG Submissions
Reviews should focus on these = questions:=20 "Is this document a
reasonable
contribution to the area of = Internet=20 engineering which it
covers? If
not, what changes would make it=20 so?"

3.1.1 New Item
  o=20 draft-ietf-mpls-ldp-igp-sync-03.txt
    LDP IGP=20 Synchronization (Informational) - 1 of 3
    Token: = David=20 Ward
  o=20 draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt
    = OSPFv3=20 Based Layer 1 VPN Auto-Discovery (Experimental) - 2 of 3=20
    Token: David Ward
  o=20 draft-ietf-roll-urban-routing-reqs-02.txt
    Urban = WSNs=20 Routing Requirements in Low Power and Lossy Networks =
   =20 (Informational) - 3 of 3
    Token: David=20 Ward

_______________________________________________
OPS-DIR = mailing=20 list
OPS-DIR@ietf.org
https://www.ietf.o= rg/mailman/listinfo/ops-dir --Boundary_(ID_6PeqhQavCc/eh21FzWe4sQ)-- --===============0690364230== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dns-dir mailing list dns-dir@ietf.org https://www.ietf.org/mailman/listinfo/dns-dir --===============0690364230==--