From ogud@ogud.com Tue Feb 2 11:39:23 2010 Return-Path: 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 97EEF3A68AB for ; Tue, 2 Feb 2010 11:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 W9aSui83owUF for ; Tue, 2 Feb 2010 11:39:23 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id BB4523A687F for ; Tue, 2 Feb 2010 11:39:22 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o12Je16c012743 for ; Tue, 2 Feb 2010 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Tue, 2 Feb 2010 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100202_194001_024684.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-yao-dnsext-identical-resolution-00.txt 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: , X-List-Received-Date: Tue, 02 Feb 2010 19:39:23 -0000 Count: 44 Network Working Group J. Yao Internet-Draft X. Lee Intended status: Informational CNNIC Expires: August 5, 2010 February 1, 2010 Problem Statement for Identical DNS Resolution of Bundle Names draft-yao-dnsext-identical-resolution-00.txt Abstract This document specifies the problems related to the identical resolution of bundle DNS names. With the emergence of internationalized domain names, two names with the same meaning or visual similarity sometimes require the identical resolution. Current DNS protocols have not provided such ability to satisfy these requirements. From ogud@ogud.com Thu Feb 4 11:39:14 2010 Return-Path: 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 8EF6928C111 for ; Thu, 4 Feb 2010 11:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.87 X-Spam-Level: X-Spam-Status: No, score=-2.87 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt7tZPySGneh for ; Thu, 4 Feb 2010 11:39:13 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id A9C023A67AC for ; Thu, 4 Feb 2010 11:39:13 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o14Je0wb032796 for ; Thu, 4 Feb 2010 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Thu, 4 Feb 2010 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100204_194000_013881.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-huang-ipv6cp-options-00.txt 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: , X-List-Received-Date: Thu, 04 Feb 2010 19:39:14 -0000 Count: 16 Internet Engineering Task Force J. Huang Internet-Draft AT&T Labs Updates: 5072 (if approved) February 3, 2010 Intended status: Standards Track Expires: August 7, 2010 IPv6CP Options for PPP Host Configuration draft-huang-ipv6cp-options-00 Abstract The Softwire Hub and Spoke Framework document outlines three steps for the Softwire Initiator (SI) and PPP peer of the Softwire Concentrator (SC) over IPv4 connectivity to be fully configured for IPv6 once the PPP session has been established. For the same function over IPv6 connectivity, however, only one additional step is needed. This is because IPv6CP only defines the Interface-Identifier option. This document defines additional host configuration options for IPv6CP so that the operational model of IPCP is extended to IPv6CP to reduce requirements on the SI and SC. From dromasca@avaya.com Fri Feb 5 03:14:04 2010 Return-Path: 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 3D7A43A6B68 for ; Fri, 5 Feb 2010 03:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 9yNjxRs4nifs for ; Fri, 5 Feb 2010 03:14:03 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 2E0983A6AAE for ; Fri, 5 Feb 2010 03:14:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,412,1262581200"; d="scan'208";a="203882446" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Feb 2010 06:14:52 -0500 X-IronPort-AV: E=Sophos;i="4.49,412,1262581200"; d="scan'208";a="442817544" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Feb 2010 06:14:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Feb 2010 12:14:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] BOF / New Mailing List E2MD (E.164 To MetaData) DDDSapplication Thread-Index: AcqlevNor3avOG4XTVKKUyBEQhJ2vQA2WvnA From: "Romascanu, Dan (Dan)" To: "IETF DNS Directorate" Subject: [dns-dir] FW: [dispatch] BOF / New Mailing List E2MD (E.164 To MetaData) DDDSapplication 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: , X-List-Received-Date: Fri, 05 Feb 2010 11:14:04 -0000 =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernie Hoeneisen Sent: Thursday, February 04, 2010 11:18 AM To: IETF DISPATCH list; IETF ENUM list; dnsop@ietf.org; dnsext@ietf.org; EPP Provreg Subject: [dispatch] BOF / New Mailing List E2MD (E.164 To MetaData) DDDSapplication Dear DNS, ENUM and RAI experts, Please be informed that a new mailing list has been created for discussion related to a proposed DDDS application 'E.164 to MetaData' (E2MD). If you are interested in this topic, please subscribe to the new Mailing List via: https://www.ietf.org/mailman/listinfo/e2md E2MD is proposed to hold E.164-related information that does not fit the normal use cases for E2U. Known use cases include information that describes the structure of the E.164 numbering plan, and records which do not represent end-user communication URIs. A BOF about E2MD has been proposed for the upcoming IETF in Anaheim: http://trac.tools.ietf.org/bof/trac/#RAI Note: E2MD has been formerly known as E2M (a naming conflict with a legacy SIP WG item required a change of the acronym for this BOF) cheers, Bernie _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From ogud@ogud.com Mon Feb 8 11:38:58 2010 Return-Path: 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 AE9E728C106 for ; Mon, 8 Feb 2010 11:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-0.228, 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 fFyfcol85LDd for ; Mon, 8 Feb 2010 11:38:57 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 9F7B428C0FC for ; Mon, 8 Feb 2010 11:38:57 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o18Je08l018118 for ; Mon, 8 Feb 2010 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Mon, 8 Feb 2010 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100208_194000_082823.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-wang-dnsext-newzone-notify-00.txt 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: , X-List-Received-Date: Mon, 08 Feb 2010 19:38:58 -0000 Count: 24 DNS Extensions Working Group Cindy WANG Internet Draft Jian JIN Intended status: Standard Track Feng HAN Xiaodong LEE CNNIC Expires: August 7, 2010 February 8, 2010 A mechanism for synchronization across name servers on zone creation draft-wang-dnsext-newzone-notify-00.txt Abstract This memo describes the NEWZONE_NOTIFY opcode for DNS, by which a primary master server advises a set of slave servers that there is a zone has been created and that a query should be initiated to discover the new zone data. This draft also specifies a mechanism for the slave servers to achieve authenticated synchronization of zone data as well as zone synchronization information with the primary when a zone is created on the primary. From ogud@ogud.com Mon Feb 8 11:53:11 2010 Return-Path: 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 7C50C28C10F for ; Mon, 8 Feb 2010 11:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=-0.207, 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 BF4WuUB05A99 for ; Mon, 8 Feb 2010 11:53:10 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E61BE28C190 for ; Mon, 8 Feb 2010 11:52:00 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o18Je0D5018100 for ; Mon, 8 Feb 2010 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Mon, 8 Feb 2010 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100208_194000_007772.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-dnsext-newzone-notify-00.txt 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: , X-List-Received-Date: Mon, 08 Feb 2010 19:53:11 -0000 Count: 24 DNS Extensions Working Group Cindy WANG Internet Draft Jian JIN Intended status: Standard Track Feng HAN Xiaodong LEE CNNIC Expires: August 7, 2010 February 8, 2010 A mechanism for synchronization across name servers on zone creation draft-ietf-dnsext-newzone-notify-00.txt Abstract This memo describes the NEWZONE_NOTIFY opcode for DNS, by which a primary master server advises a set of slave servers that there is a zone has been created and that a query should be initiated to discover the new zone data. This draft also specifies a mechanism for the slave servers to achieve authenticated synchronization of zone data as well as zone synchronization information with the primary when a zone is created on the primary. From ogud@ogud.com Tue Feb 9 11:38:57 2010 Return-Path: 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 CB29C3A741B for ; Tue, 9 Feb 2010 11:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=-0.190, 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 MipfVjB60xx5 for ; Tue, 9 Feb 2010 11:38:55 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id ECD2E3A70CB for ; Tue, 9 Feb 2010 11:38:54 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o19Je1Td030200 for ; Tue, 9 Feb 2010 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Tue, 9 Feb 2010 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100209_194001_022456.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-iab-anycast-arch-implications-00.txt 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: , X-List-Received-Date: Tue, 09 Feb 2010 19:38:57 -0000 Count: 10 INTERNET-DRAFT Danny McPherson Arbor Networks Dave Oran Cisco Systems Expires: August 2010 February 9, 2010 Intended Status: Informational Architectural Considerations of IP Anycast Abstract This memo discusses architectural implications of IP anycast. From dromasca@avaya.com Wed Feb 10 07:13:33 2010 Return-Path: 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 4CB6C3A7590; Wed, 10 Feb 2010 07:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 UfrBNiAg1eXc; Wed, 10 Feb 2010 07:13:31 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 261E03A7375; Wed, 10 Feb 2010 07:13:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,443,1262581200"; d="scan'208";a="3069735" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 10 Feb 2010 10:14:40 -0500 X-IronPort-AV: E=Sophos;i="4.49,443,1262581200"; d="scan'208";a="444300687" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Feb 2010 10:14:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Feb 2010 16:14:12 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Keying and Authentication for Routing Protocols (karp) Thread-Index: AcqpvGVJkypTiv8hSgedtsOlPJbz9AApzgXg From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , "MIB Doctors (E-mail)" , Subject: [dns-dir] FW: WG Review: Keying and Authentication for Routing Protocols (karp) 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: , X-List-Received-Date: Wed, 10 Feb 2010 15:13:33 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, February 09, 2010 9:15 PM To: new-work@ietf.org Subject: WG Review: Keying and Authentication for Routing Protocols (karp)=20 A new IETF working group has been proposed in the Routing Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, February 16, 2010. =20 Keying and Authentication for Routing Protocols (karp) --------------------------------------------------- Current Status: Proposed Working Group Last Modified: 2010-02-05 Chair(s):=20 - Joel Halpern - Brian Weis Routing Area Director(s): - Ross Callon - Adrian Farrell Routing Area Advisor: - Ross Callon=20 Security Area Advisor: - Tim Polk =20 Mailing Lists: karp@ietf.org Description of Working Group: The KARP working group is tasked to work with the routing protocol working groups in order to improve the communication security of the packets on the wire used by the routing protocols. This working group is concerned with message authentication, packet integrity, and denial of service (DoS) protection. At present, this charter explicitly excludes confidentiality and non-repudiation concerns. Authenticating the routing peer sending a message, and message integrity protection, will be provided through the use of per-packet cryptographic message authentication. Peer authentication will protect against unrecognized peers, imposter peers, and some DoS attacks aimed at routers. Protecting against misbehavior of an otherwise allowed peer router is outside the scope of this working group. Many routing protocols (or groups of protocols) already have some method for accomplishing cryptographic message authentication. In many or most cases existing methods are vulnerable to known attack, and some employ cryptographic algorithms that have been deprecated. While much work has been done to update authentication of routing protocols, current status is not consistently up to date. It is important to review and update those mechanisms to use modern security practices. Ensuring algorithm agility within routing protocols is of particular importance. A goal of the working group is to add incremental security to existing mechanisms rather than replacing them. Better deployable solutions to which vendors and operators can migrate is more important than getting a perfect security solution. Although there are many candidate routing protocols to evaluate, KARP must by necessity begin with a restricted focus. The initial set of routing protocols in scope include BGP, OSPFv2, OSPFv3, PCE, PIM, LDP, RSVP-TE, ISIS, BFD, LMP, and MSDP. The working group must coordinate very closely with other working groups, such as: - Routing protocol working groups for any routing protocol being evaluated. This coordination will include cooperatively determining the current or already planned state of the security work in the protocol. It will also include ensuring that any proposed mechanisms are consistent with the architecture and use of the protocol. Also, any specific proposal accepted as a KARP document will be developed in cooperation with the concerned protocol working group. - Security area working groups for cryptographic advice, and/or key management protocol support. Cryptographic protocol support may be required in order to support certain KARP WG milestones. Coordination with an appropriate working group in the security area would be necessary in order to get the appropriate expertise in completing a milestone. This charter provides for preliminary work in this space, although it is expected that detailed work items will be added to the charter when the problem has been better analyzed. For example, this may include a key management protocol by which routing protcols automatically negotiate keying material and policy. More about the use of a key management protocol will be captured in a framework document described below. - OPSEC working group for advice on best practices to create and use integrity keys used with routing protocol message authentication. Routing protocols use a range of transport mechanisms and communication relationships. There are also differences in details among the various protocols. The working group will attempt to describe the security relevant characteristics of routings protocols, such as the use or non-use of TCP, or the frequent use of group communication versus purely pairwise communication. Using these characteristics, the working group will then provide suitable common frameworks that can be applied, and tailored, to improve the communication security of the routing protocols. In later phases, it is expected that the working group will investigate the suitably of defining conceptual structures and APIs, so as to enable further work to be more effective. Work Items: - Determine current threats to the routing protocol operation, and define general requirements for cryptographic authentication of routing protocols. A primary source for this document should be draft-lebovitz-karp-roadmap, although RFC 4393 may also be useful. - Identify deficiencies of each routing protocol in scope, and specify mechanisms that bring them in line with the general requirements. These are referred to as protocol gap analysis documents. - Define one or more frameworks describing the common elements for modern authentication in routing protocols. - Publish guidance on how to create a gap analysis for routing protocols. - Publish guidance on guidance to operators on how to create and use integrity keys used with routing protocol message authentication. - Specify automated key management needs for routing protocols. Goals and Milestones: Nov 2010 - Submit General Framework, General Requirements, and Priorities/Work-Plan documents to the IESG to be considered as Informational RFC Nov 2010 - Submit a framework document describing protocol groups and the common techniques and interfaces that apply to them to the IESG to be considered as Informational RFC Dec 2010 - Submit a document describing best practices for creating and using protocol message authentication integrity keys as a BCP Apr 2011 - Submit specification document for OSPFv2 to the IESG to be considered as a Proposed Standard Apr 2011 - Submit specification document for BGP to the IESG to be considered as a Proposed Standard Jul 2011 - Submit specification document for OSPFv3 to the IESG to be considered as a Proposed Standard Jul 2011 - Submit specification document for LDP to the IESG to be considered as a Proposed Standard Oct 2011 - Submit specification document for PIM to the IESG to be considered as a Proposed Standard Oct 2011 - Submit specification document for RSVP-TE to the IESG to be considered as a Proposed Standard Nov 2011 - Specify automated key management needs for routing protocols using unicast techniques Jan 2012 - Submit specification document for ISIS to the IESG to be considered as a Proposed Standard Jan 2012 - Submit specification document for PCE to the IESG to be considered as a Proposed Standard Apr 2012 - Submit specification document for MSDP to the IESG to be considered as a Proposed Standard Apr 2012 - Specify automated key management needs for routing protocols using multicast techniques Apr 2012 - Submit specification document for BFD to the IESG to be considered as a Proposed Standard Jul 2012 - Submit specification document for LMP to the IESG to be considered as a Proposed Standard From dromasca@avaya.com Wed Feb 10 07:14:45 2010 Return-Path: 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 9C1363A7375; Wed, 10 Feb 2010 07:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 s8UUFAzZEq5Z; Wed, 10 Feb 2010 07:14:35 -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 CFE873A6EDE; Wed, 10 Feb 2010 07:14:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,443,1262581200"; d="scan'208";a="175912197" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Feb 2010 10:15:40 -0500 X-IronPort-AV: E=Sophos;i="4.49,443,1262581200"; d="scan'208";a="444301162" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Feb 2010 10:15:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Feb 2010 16:15:16 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Peer-to-Peer Streaming Protocol (PPSP) Thread-Index: AcqpvIJvP9zYp0GCROeLhVBqnv6/TgAp0Z8g From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , "MIB Doctors (E-mail)" , Subject: [dns-dir] FW: WG Review: Peer-to-Peer Streaming Protocol (PPSP) 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: , X-List-Received-Date: Wed, 10 Feb 2010 15:14:47 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, February 09, 2010 9:15 PM To: new-work@ietf.org Subject: WG Review: Peer-to-Peer Streaming Protocol (PPSP)=20 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, February 16, 2010. =20 Peer-to-Peer Streaming Protocol (PPSP) -------------------------------------------------- Current Status: Proposed Working Group Chair(s): TBD Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert =20 Mailing Lists: ppsp@ietf.org Description of Working Group: The Peer-to-Peer Streaming Protocol (PPSP) working group develops two signaling and control protocols for a peer-to-peer (P2P) streaming system for transmitting live and pre-recorded media content with near real-time delivery requirements. Two kinds of nodes exist in the targeted P2P streaming system, i.e., "peers" and "trackers". Peers are nodes that are actively sending and receiving streamed media content, and include both statically connected hosts as well as mobile devices with connectivity and IP addresses that change over time. The set of peers that are participating in a streaming session will dynamically change over time. Trackers are well-known nodes with stable connectivity that maintain meta information about the streamed content and the dynamic peer set. The PPSP WG designs a protocol for signaling and control between trackers and peers (the PPSP "tracker protocol") and a signaling and control protocol for communication among the peers (the PPSP "peer protocol"). The two protocols enable peers to receive streaming data within the time constraints required by specific content items. The tracker protocol handles the initial and periodic exchange of meta information between trackers and peers, such as peer lists and content information. The peer protocol controls the advertising and exchange of media data availability between the peers. Existing IETF and other standards will be used for the encoding and transmission of the media content between peers. PPSP is not chartered to work on media transmission protocols, media encoding techniques or other components of a P2P streaming system such as playout scheduling and control, etc. The work items of the PPSP WG are: (1) A "problem statement" document that gives an overview of the proposed P2P streaming system, motivates the desire for=20 standardized protocols, defines the envisioned scope of those standardized components and discusses common terminologies and concepts. (2) A "requirements" document that details the specific functional, operational and performance requirements of the two PPSP protocols. (3) An "architectural survey" document that summarizes current P2P streaming architectures, in particular tracker-based P2P streaming systems, and highlights best current practices. (4) A detailed specification of the PPSP peer protocol. (5) A detailed specification of the PPSP tracker protocol. (6) A "usage guide" that describes how the two PPSP protocols and existing IETF protocols, such as RELOAD, ALTO or RTSP, can be combined to create a deployable operational P2P streaming system. This document may also discuss variants of such a system that, for example, use layered media encoding and related media chunk descriptions in the peer protocol for more robust streaming. The work items of the PPSP WG interacts with the work performed in other IETF WGs, including P2PSIP, ALTO, LEDBAT and MMUSIC. Whenever extensions or modification to the protocols developed in other WGs are deemed necessary, PPSP shall communicate and discuss the requirements for such extensions with the relevant WGs. The design of such extensions is out of scope for PPSP. Goals and Milestones: Dec 2010 Submit problem statement to IESG as Informational Apr 2011 Submit architectural survey to IESG as Informational Apr 2011 Submit requirements document to IESG as Informational Aug 2011 Submit PPSP peer protocol to IESG as Proposed Standard=20 Aug 2011 Submit PPSP tracker protocol to IESG as Proposed Standard Dec 2011 Submit usage guide to IESG to IESG as Informational From dromasca@avaya.com Wed Feb 10 07:15:54 2010 Return-Path: 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 8E2C228C1D3; Wed, 10 Feb 2010 07:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 N+j6SosRuNBE; Wed, 10 Feb 2010 07:15:53 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id DCCA43A771C; Wed, 10 Feb 2010 07:15:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,443,1262581200"; d="scan'208";a="204487463" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Feb 2010 10:17:03 -0500 X-IronPort-AV: E=Sophos;i="4.49,443,1262581200"; d="scan'208";a="444301672" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Feb 2010 10:17:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Feb 2010 16:16:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Inter-Domain Routing (idr) Thread-Index: AcqpuksyqeK9malXRiGXLY+MRsTkxAAqbU9g From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , "MIB Doctors (E-mail)" Subject: [dns-dir] FW: WG Review: Recharter of Inter-Domain Routing (idr) 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: , X-List-Received-Date: Wed, 10 Feb 2010 15:15:54 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, February 09, 2010 9:00 PM To: ietf-announce@ietf.org Cc: jgs@juniper.net; shares@ndzh.com; idr@ietf.org Subject: WG Review: Recharter of Inter-Domain Routing (idr)=20 A modified charter has been submitted for the Inter-Domain Routing (idr) working group in the Routing Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, February 16, 2010. Inter-Domain Routing (idr) ----------------------------- Last Modified: 2010-02-04 Additional information is available at tools.ietf.org/wg/idr Chair(s): - Susan Hares - John Scudder Routing Area Director(s): - Ross Callon - Adrian Farrel Routing Area Advisor: - Ross Callon Mailing Lists: General Discussion: idr@ietf.org To Subscribe: idr-request@ietf.org In Body: subscribe idr-post Archive: http://www.ietf.org/mail-archive/web/idr/index.html Description of Working Group: The Inter-Domain Routing Working Group is chartered to standardize, develop, and support the Border Gateway Protocol Version 4 (BGP-4) [RFC 4271] capable of supporting policy based routing for TCP/IP internets. The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks. The working group will also continue to work on improving the robustness and scalability of BGP. IDR will review extensions made to BGP in other working groups at least at WG document adoption and during working group last calls. The IDR working group will also provide advice and guidance on BGP to other working groups as requested. Work Items: The IDR working group will work on correctness, robustness and scalability of the BGP protocol, as well as clarity and accuracy of the BGP document set. The group will also work on extensions beyond these areas when specifically added to the charter. The current additional work items are: - Relax the definition of BGP identifiers to only require AS-wide uniqueness. This change must be made in a backward compatible way. - Specify a means to non-disruptively introduce new BGP Capabilities to an existing BGP session. - Upgrade of the base BGP specification to Full Standard - Define AS_PATH based Outbound Route Filtering. - MIB v2 for BGP-4 - Augment the BGP multiprotocol extensions to support the use of multiple concurrent sessions between a given pair of BGP speakers. Each session is used to transport routes related by some session- based attribute such as AFI/SAFI. This will provide an alternative to the MP-BGP approach of multiplexing all routes onto a single connection. - Support for four-octet AS Numbers in BGP. - Revisions to the BGP 'Minimum Route Advertisement Interval' deprecating the previously recommended values and allowing for withdrawals to be exempted from the MRAI. - Advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. Each path is identified by a path identifier in addition to the address prefix. - Revised error handling rules for optional transitive BGP attributes so that a BGP speaker is no longer required to reset the session over which a malformed attribute is received. Provide guidelines for authors of documents that define new optional transitive attributes, and re-assess procedures for existing optional transitive attributes - Specify Link Bandwidth Extended Community for use in unequal cost load balancing. - The definition of an "Accumulated IGP Metric" attribute for BGP to report the sum of the metric of each link along the path. This attribute is for use in a restricted environment where: - all ASes are subject to the administrative control - some form of tunneling is used to deliver a packet to its next BGP hop - where the path for a route leads outside the AS to which the BGP speaker adding the attribute belongs. - Advertisement of the best external route in BGP to assist with resolution of the next hop in the chosen data plane. Goals and Milestones: Done Submit to BGP Capability Advertisement to the IESG Done Submit BGP Security Vulnerabilities Analysis to IESG as an Informational Done Submit BGP4 MIB to IESG as a Proposed Standard Done Submit BGP4 document to IESG as a Draft Standard Done Submit Extended Communities draft to IESG as a Proposed Standard Done Submit BGP Graceful Restart to IESG as a Proposed Standard Done Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG as a Draft Standard Done Submit Subcodes for BGP Cease Notification Message to IESG as a Proposed Standard Done Submit 4-byte AS ID to IESG as a Proposed Standard Done Submit Outbound Route Filter and Prefix ORF draft to IESG as a Proposed Standard Done Prefix and ASpath ORF draft to IESG as a Proposed Standard Aug 2010 Submit AS-wide Unique BGP Identifier for BGP-4 as a Proposed Standard Aug 2010 Submit Dynamic Capability for BGP-4 to IESG as a Proposed Standard Aug 2010 ASpath ORF draft to IESG as a Proposed Standard Aug 2010 Submit MIB v2 for BGP-4 as a Proposed Standard Nov 2010 BGP Support for Four-octet AS Number Space (revised version) Nov 2010 Revisions to the BGP 'Minimum Route Advertisement Interval' Nov 2010 Advertisement of Multiple Paths in BGP Nov 2010 BGP Link Bandwidth Extended Community Nov 2010 Advertisement of the best external route in BGP Dec 2010 Submit Multisession BGP as a Proposed Standard Dec 2010 Error Handling for Optional Transitive BGP Attributes Dec 2010 ASpath ORF Dec 2010 Revise WG charter Mar 2011 The Accumulated IGP Metric Attribute for BGP Mar 2011 Base BGP specification (RFC 4271) as Full Standard From dromasca@avaya.com Wed Feb 10 07:16:38 2010 Return-Path: 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 37F0128C1D3; Wed, 10 Feb 2010 07:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 IYzlOOhxUl8C; Wed, 10 Feb 2010 07:16:36 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 6CCC43A7720; Wed, 10 Feb 2010 07:16:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,443,1262581200"; d="scan'208";a="204487596" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Feb 2010 10:17:47 -0500 X-IronPort-AV: E=Sophos;i="4.49,443,1262581200"; d="scan'208";a="444301971" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Feb 2010 10:17:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Feb 2010 16:17:22 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme) Thread-Index: AcqpumN4ELmAv+/xTWipFtBFqAR7UAAqbh3A From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , "MIB Doctors (E-mail)" Subject: [dns-dir] FW: WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme) 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: , X-List-Received-Date: Wed, 10 Feb 2010 15:16:38 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, February 09, 2010 9:00 PM To: ietf-announce@ietf.org Cc: ipsec@ietf.org; paul.hoffman@vpnc.org; yaronf@checkpoint.com Subject: WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)=20 A modified charter has been submitted for the IP Security Maintenance and Extensions (ipsecme) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, February 16, 2010. IP Security Maintenance and Extensions (ipsecme) --------------------------------------------------- Current Status: Active Working Group Last Modified: 2010-01-21 Chair(s): * Paul Hoffman (paul.hoffman@vpnc.org) * Yaron Sheffer (yaronf@checkpoint.com) Security Area Director(s): * Tim Polk (tim.polk@nist.gov) * Pasi Eronen (pasi.eronen@nokia.com) Security Area Advisor: * Pasi Eronen (pasi.eronen@nokia.com) Mailing Lists: General Discussion: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Description of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 4306, RFC 4718, and associated RFCs), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The work items are: - A standards-track IKEv2 extension that allows an IKE peer to quickly and securely detect that its opposite peer, while currently reachable, has lost its IKEv2/IPsec state. Changes to how the peers recover from this situation are beyond the scope of this work item, as is improving the detection of an unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as starting points. - A standards-track IKEv2 extension to allow mutual EAP-based authentication in IKEv2, eliminating the need for the responder to present a certificate. The document will define the conditions that EAP methods need to fulfill in order to use this extension. The document will recommend, but will not require, the use of EAP methods that provide EAP channel binding. The proposed starting point for this work is draft-eronen-ipsec-ikev2-eap-auth-07.txt. - IKEv2 supports mutual authentication with a shared secret, but this mechanism is intended for "strong" shared secrets. User-chosen passwords are typically of low entropy and subject to off-line dictionary attacks when used with this mechanism. Thus, RFC 4306 recommends using EAP with public-key based authentication of the responder instead. This approach would be typically used in enterprise remote access VPN scenarios where the VPN gateway does not usually even have the actual passwords for all users, but instead typically communicates with a back-end RADIUS server. However, user-configured shared secrets are still useful for many other IPsec scenarios, such as authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either peer can initiate an IKEv2 SA. These features make using EAP (with its strict client-server separation) undesirable. The WG will develop a standards-track extension to IKEv2 to allow mutual authentication based on "weak" (low-entropy) shared secrets. The goal is to avoid off-line dictionary attacks without requiring the use of certificates or EAP. There are many already-developed algorithms that can be used, and the WG would need to pick one that both is believed to be secure and is believed to have acceptable intellectual property features. The WG would also need to develop the protocol to use the chosen algorithm in IKEv2 in a secure fashion. It is noted up front that this work item poses a higher chance of failing to be completed than other WG work items; this is balanced by the very high expected value of the extension if it is standardized and deployed. - IPsec gateways are often deployed in clusters that look like a single gateway to the peer (such as for high availability and load balancing reasons). However, correctly maintaining the appearance to the peer of a single gateway is complicated; one of the main challenges is the strict use of sequence numbers both in IKEv2 and ESP/AH. This work item will define a problem statement and requirements for potential IPsec/IKEv2 mechanism (or multiple mechanisms) to simplify cluster implementations. The result will be an informational document that, once completed, may lead to chartering one or more new work items to specify the actual mechanisms. The scope is restricted to mechanism(s) that are visible to the peer, and thus usually require interoperability between vendors. Mixed-vendor clusters, and protocols between the cluster members, are explicitly out of scope of this work item. The starting point will be draft-nir-ipsecme-ipsecha-00. In addition, the following items from the existing charter are expected to be completed soon: - A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. In some cases, the revision may include small technical corrections; however, impact on existing implementations must be considered. Major changes and adding new features is beyond the scope of this work item. One part of this work item, clarifying how AES counter mode is used for the IKEv2 encrypted payload, is in a separate document. - An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. This document will be informational. - A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The scope of the WG is restricted to the work items listed above. The WG shall not consider adding new work items until there are four or fewer documents being actively worked on (not yet progressed to IETF Last Call). At that time, the WG can propose rechartering. Work on IPsec extensions that are not included in this charter can happen as usual in other WGs, or as individual submissions. This charter will expire in February 2012 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Goals and Milestones: Aug 2010 - WG last call on HA requirements Dec 2010 - WG last call on quick crash discovery Jan 2011 - WG last call on EAP-only authentication Mar 2011 - WG last call on password-based authentication From ogud@ogud.com Wed Feb 10 11:38:51 2010 Return-Path: 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 8AB3B28C22C for ; Wed, 10 Feb 2010 11:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.774 X-Spam-Level: X-Spam-Status: No, score=-2.774 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 lFlJghEyEfRh for ; Wed, 10 Feb 2010 11:38:50 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id ABA4728C224 for ; Wed, 10 Feb 2010 11:38:50 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o1AJe0XY040721 for ; Wed, 10 Feb 2010 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 10 Feb 2010 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100210_194001_027602.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-seantek-tid-urn-00.txt 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: , X-List-Received-Date: Wed, 10 Feb 2010 19:38:51 -0000 Count: 22 Network Working Group S. Leonard Internet-Draft Penango, Inc. Intended status: Informational February 9, 2010 Expires: August 13, 2010 A Uniform Resource Name (URN) Namespace for Transaction Identifiers draft-seantek-tid-urn-00 Abstract Transaction identifiers are used throughout modern commerce to memorialize particular economic events. This document describes a Uniform Resource Name (URN) namespace that contains transaction identifiers. From dromasca@avaya.com Thu Feb 11 21:49:11 2010 Return-Path: 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 5A3083A765C; Thu, 11 Feb 2010 21:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 eSonTYpGMnuC; Thu, 11 Feb 2010 21:49:10 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 215CC3A77B1; Thu, 11 Feb 2010 21:49:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,457,1262581200"; d="scan'208";a="204767103" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Feb 2010 00:50:25 -0500 X-IronPort-AV: E=Sophos;i="4.49,457,1262581200"; d="scan'208";a="430709724" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Feb 2010 00:50:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Feb 2010 06:49:49 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for February 18, 2010 Telechat Thread-Index: AcqrcOwUTZEeZorwQbazoB/9ZAU5dgANdoPg From: "Romascanu, Dan (Dan)" To: , , "MIB Doctors (E-mail)" , "IETF DNS Directorate" Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for February 18, 2010 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: , X-List-Received-Date: Fri, 12 Feb 2010 05:49:11 -0000 =20 Please find below the preliminary agenda of the 2/18 IESG telechat. Please send me your comments, questions and concerns related to the documents and Working Groups brought up for approval before 2/17 COB.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Friday, February 12, 2010 1:20 AM 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-geopriv-lis-discovery-13 Discovering the Local Location Information Server (LIS) (Proposed Standard) Note: Alissa Cooper (acooper@cdt.org) is the document shepherd. Token: Cullen Jennings o draft-ietf-geopriv-geo-uri-04 A Uniform Resource Identifier for Geographic Locations ('geo' URI) (Proposed Standard) Note: Richard Barnes (rbarnes@bbn.com) is the document shepherd. Token: Cullen Jennings o draft-ietf-ccamp-gmpls-dcsc-channel-ext-03 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions (Proposed Standard) Note: Deborah Brungard (db3546@att.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-dhc-dhcpv4-vendor-message-01 DHCPv4 Vendor-specific Message (Proposed Standard) Note: Ted Lemon (mellon@nominum.com) is the document shepherd. Token: Ralph Droms o draft-ietf-dhc-dhcpv6-vendor-message-01 DHCPv6 Vendor-specific Message (Proposed Standard) Note: Ted Lemon (mellon@nominum.com) is the document shepherd. Token: Ralph Droms 2.1.2 Returning Items o draft-ietf-avt-app-rtp-keepalive-07 Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows. (Proposed Standard) Token: Cullen Jennings o draft-ietf-trill-rbridge-protocol-15 Rbridges: Base Protocol Specification (Proposed Standard) Note: Erik Nordmark (erik.nordmark@sun.com) is the Document Shepherd. Token: Ralph Droms Was deferred by Adrian Farrel on 2010-01-20 2.2 Individual Submissions 2.2.1 New Items o draft-allbery-afs-srv-records-03 DNS SRV Resource Records for AFS (Proposed Standard) Note: After discussing this with Jari I am thinking that the normative downreference to RFC 1183 (Experimental) is Ok in this case. Token: Alexey Melnikov 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-tcpm-icmp-attacks-10 ICMP attacks against TCP (Informational) Note: Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. Token: Lars Eggert o draft-ietf-ecrit-location-hiding-req-02 Location Hiding: Problem Statement and Requirements (Informational) Token: Cullen Jennings o draft-ietf-pce-p2mp-req-05 PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE) (Informational) Note: JP Vasseur (jvasseur@cisco.com) is the document shepherd. Token: Ross Callon o draft-ietf-mpls-tp-nm-framework-04 MPLS-TP Network Management Framework (Informational) Note: Loa Andersson (loa@pi.nu) is the Document Shepherd. Token: Adrian Farrel 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-zorn-radius-pkmv1-10 RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support (Informational) Token: Dan Romascanu 3.2.2 Returning Items NONE 3.3 Independent Submissions Via RFC Editor 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.3.3 For Action o draft-sipforum-ua-config-02 IANA Registration of the SFUACFG Application Service Tags (None) Token: Russ Housley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Session Recording Protocol (srp) Token: Cullen Jennings 4.1.2 Proposed for Approval o Keying and Authentication for Routing Protocols (karp) Token: Ross Callon o Peer to Peer Streaming Protocol (ppsp) Token: Lars Eggert 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval o IP Security Maintenance and Extensions (ipsecme) Token: Pasi Eronen o Inter-Domain Routing (idr) Token: Ross Callon From ogud@ogud.com Fri Feb 12 11:38:44 2010 Return-Path: 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 3793228C1E1 for ; Fri, 12 Feb 2010 11:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 G6TuJXhl9A6F for ; Fri, 12 Feb 2010 11:38:43 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 5DF8428C1D3 for ; Fri, 12 Feb 2010 11:38:43 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o1CJe0pk067407 for ; Fri, 12 Feb 2010 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Fri, 12 Feb 2010 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100212_194001_094711.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-cao-behave-dsdns64-00.txt 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: , X-List-Received-Date: Fri, 12 Feb 2010 19:38:44 -0000 Count: 28 behave Working Group Z. Cao Internet-Draft H. Deng Intended status: Informational China Mobile Expires: August 16, 2010 February 12, 2010 Dual Stack Hosts with DNS64 draft-cao-behave-dsdns64-00 Abstract If a dual stack host is configured with a DNS64 server, the packet will be routed through the NAT64 translator instead of the plain IPv4 router or NAT44. This document suggest the DNS64 should handle type A DNS request normally to avoid packets being detoured to NAT64. From ogud@ogud.com Mon Feb 22 11:38:11 2010 Return-Path: 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 36BD43A833A for ; Mon, 22 Feb 2010 11:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 q9AlWg8eCYkO for ; Mon, 22 Feb 2010 11:38:10 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 5924C3A8339 for ; Mon, 22 Feb 2010 11:38:07 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o1MJe1NM064548 for ; Mon, 22 Feb 2010 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Mon, 22 Feb 2010 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100222_194001_084516.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-dnsop-dnssec-trust-history-01.txt 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: , X-List-Received-Date: Mon, 22 Feb 2010 19:38:11 -0000 Count: 44 Domain Name System Operations W. Wijngaards Internet-Draft O. Kolkman Intended status: Standards Track NLnet Labs Expires: August 26, 2010 February 22, 2010 DNSSEC Trust Anchor History Service draft-ietf-dnsop-dnssec-trust-history-01 Abstract When DNS validators have trusted keys, but have been offline for a longer period, key rollover will fail and they are stuck with stale trust anchors. History service allows validators to query for older DNSKEY RRsets and pick up the rollover trail where they left off. From dromasca@avaya.com Tue Feb 23 10:38:54 2010 Return-Path: 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 F13BD3A84D8; Tue, 23 Feb 2010 10:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 aE1LAcxdvHIW; Tue, 23 Feb 2010 10:38:54 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C43C33A84D4; Tue, 23 Feb 2010 10:38:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,527,1262581200"; d="scan'208";a="206417584" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Feb 2010 13:40:55 -0500 X-IronPort-AV: E=Sophos;i="4.49,527,1262581200"; d="scan'208";a="434771156" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Feb 2010 13:40:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Feb 2010 19:39:57 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: SIP Recording (SIPREC) Thread-Index: Acq0tqqCZk1zIjU8TVinERt0usWizgAAOHNQ From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , , "MIB Doctors (E-mail)" Subject: [dns-dir] FW: WG Review: SIP Recording (SIPREC) 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: , X-List-Received-Date: Tue, 23 Feb 2010 18:38:55 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, February 23, 2010 8:30 PM To: new-work@ietf.org Subject: WG Review: SIP Recording (SIPREC)=20 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, March 2, 2010. =20 SIP Recording (SIPREC) --------------------------------------------------- Current Status: Proposed Working Group Last Modified: 2010-02-18 Chair(s):=20 * TBD Real-time Applications and Infrastructure Area Director(s): * Robert Sparks * Cullen Jennings Real-time Applications and Infrastructure Area Advisor: * Cullen Jennings Mailing Lists: * TBD Description of Working Group: The Session Recording Protocol (SRP) working group is chartered to define a SIP-based protocol for controlling a session (media) recorder. Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control, business analytics, or consumer protection. Recording is typically done by sending a copy of the media to the recording devices. The working group will determine requirements and produce a specification for a protocol that will manage delivery of media from an end-point that originates media, or that has access to it, to a recording device. PBX and recording vendors today implement proprietary, incompatible mechanisms to facilitate recording. A standard protocol will reduce the complexity and cost of providing such recording services. The Session Recording problem presents certain unique requirements that are not addressed in the current SIP protocol specification. These include requirements such as the need for a distinction between the session that is being recorded versus the session that has been established for recording. Privacy and security of conversations are significant concerns. The working group will make sure that any protocol specified addresses these concerns and includes mechanisms to alert users to the fact that a session they are participating in is being recorded. The working group must take care that the session recording requirements and protocol does not conflict with the IETF statement on wiretapping contained in RFC 2804. The SRP Working Group will thoroughly identify use cases, provide example system architectures and deployment scenarios, and define requirements. The scope of the activity includes: * Recorder Control * Session metadata content and format * Security mechanisms, including transport and media encryption * Privacy concerns, including end-user notification * Negotiation of recording media streams The group will define these issues and rationalize with IETF standards and practices. This includes encryption, NAT traversal, SIP-enabled firewalls, authorization, and security. The group will produce: * Updated Requirements, Use Cases, Architecture draft * Specification for Session Recording Protocol Goals and Milestones: Apr 2010 Use Cases and Requirements to IESG as Informational Draft Nov 2010 Architecture to IESG as Informational Draft Nov 2010 Submit protocol draft to IESG as standards track From dromasca@avaya.com Tue Feb 23 11:22:59 2010 Return-Path: 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 692103A84E8; Tue, 23 Feb 2010 11:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 uXQGTDInE1bm; Tue, 23 Feb 2010 11:22:58 -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 492A43A84E3; Tue, 23 Feb 2010 11:22:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,527,1262581200"; d="scan'208";a="177695341" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Feb 2010 14:24:57 -0500 X-IronPort-AV: E=Sophos;i="4.49,527,1262581200"; d="scan'208";a="434788009" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Feb 2010 14:24:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Feb 2010 20:24:12 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of ADSL MIB (adslmib) Thread-Index: Acq0urM0s8R6XDy5Rw+uWN0BQYmJzAAAwm/w From: "Romascanu, Dan (Dan)" To: "MIB Doctors (E-mail)" , "IETF DNS Directorate" , , Subject: [dns-dir] FW: WG Review: Recharter of ADSL MIB (adslmib) 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: , X-List-Received-Date: Tue, 23 Feb 2010 19:22:59 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, February 23, 2010 9:00 PM To: ietf-announce@ietf.org Cc: adslmib@ietf.org; Menachem.Dodge@ecitele.com Subject: WG Review: Recharter of ADSL MIB (adslmib)=20 A modified charter has been submitted for the ADSL MIB (adslmib) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, March 2, 2010. ADSL MIB (adslmib) ------------------------------- Current Status: Active Working Group Last Modified: 2010-02-14=20 Additional information is available at tools.ietf.org/wg/adslmib Chair(s): * Menachem Dodge Operations and Management Area Director(s): * Dan Romascanu * Ronald Bonica Operations and Management Area Advisor: * Dan Romascanu Editor(s): * Scott Baillie * Moti Morgenstern * Umberto Bonollo * Edward Beili =20 Mailing Lists: General Discussion: adslmib@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/adslmib Archive: http://www.ietf.org/mail-archive/web/adslmib/current/maillist.html Description of Working Group: The working group will define:=20 1. A set of managed objects to handle the bonding of xDSL lines according to the ITU-T Recommendations G.998.1 (ATM), G.998.2 (Ethernet) and G.998.3 (TDIM). A common MIB module will be developed to handle the common objects and three specific MIB modules will be developed to handle the three separate layer-2 technologies. Use will be made of the ifStack and ifInvStack Tables defined in RFC 2863 and RFC 2864 respectively. Use will also be made of the ifCapStack and ifInvCapStack tables as defined in RFC 5066. The Broadband forum TR-159 will be used in the definition of these MIBs. 2. The working group will develop a set of managed objects as an optional extension to RFC 5650 that shall provide an alternative approach, known as the "Vector of Profiles", for the configuration of DSL lines. The Vector of Profiles MIB will be based on the Broadband Forum TR-165 document. The ITU-T G.997.1 will also be considered in the definition of this extension. The MIB modules defined by this group will be generated using SMIv2, will be consistent with the SNMP management framework, and will describe the relationship of the objects defined to existing MIBs such as those described in other work products of this Working Group, the interfaces MIB, the Ethernet MIB modules and the AToM MIB.=20 Goals and Milestones: Done Submit Internet-Draft to cover subscriber equipment Done Meet at Chicago IETF to review Internet-Drafts Done Submit Internet-Draft to IESG for consideration as Proposed=20 Standard.=20 Done Meet at Oslo IETF to review new Internet-Drafts and discuss=20 implementation experience on initial MIB Done Submit supplementary Internet-Draft to IESG for consideration as=20 Proposed Standard.=20 Done Produce Internet-Draft covering HDSL2 management objects.=20 Done Submit updated HDSL2/SHDSL Internet-Draft Done Complete WG last call for HDSL2/SHDSL management objects Done Collect implementation reports for ADSL MIB Done Submit HDSL2/SHDSL MIB to IESG for consideration as Proposed=20 Standard Done Submit initial Internet-Draft VDSL MIB Done Complete WG last call on VDSL MIB Done Submit updated VDSL MIB Internet-Draft Done Submit final VDSL MIB Internet-Draft Done Submit VDSL MIB to IESG for consideration as Proposed Standard Done New WG I-Ds for the LCS MCM and SCM MIB modules Done Initial WG Internet-Draft covering ADSL2 management objects Done Integrate working group changes and produce revised draft Done Complete WG last call on ADSL2 MIB Done Submit ADSL2 MIB to IESG for consideration as Proposed Standard Done Re-charter or close down Done Initial WG Internet-Draft covering VDSL2 management objects Done Inform the ITU-T and DSL Forum that work on the VDSL2 MIB has begun Done Integrate working group changes and produce revised VDSL2 MIB draft Done Post Initial Drafts of all the xDsl Bonding MIB drafts Done Post Vdsl2 draft version 03 Done Post Vdsl2 draft version 04.=20 Done Complete Thorough Working Group Reviews of the Vdsl2 draft and=20 produce version 05.=20 Done Working Group Last Call for the Vdsl2 document.=20 Done Early MIB Doctor Reviews of the Vdsl2 draft.=20 Done Make Correction to the draft following the review.=20 Done Working Group Last Call for the Vdsl2 document following=20 corrections.=20 Done Present the Vdsl2 document to the IESG.=20 Feb 2010 Submit updated ATM and Ethernet G.Bond MIB drafts. Mar 2010 Initial Vector of Profiles draft to be accepted by the Working=20 Group. Apr 2010 Submit G.Bond MIB and TDIM MIB Drafts Apr 2010 Submit Vector of Profiles Draft version 01 May 2010 Working Group Last Call on all the G. Bond documents. Jun 2010 Submit G.Bond documents to IESG as Proposed Standard Jun 2010 Revise the draft and post vector of Profiles draft version 02. Jul 2010 Working Group Last Call for the Vector of Profiles draft. Aug 2010 Post Vector of Profiles Draft version 03. Sep 2010 Submit the Vector Of Profile document to the IESG as Proposed=20 Standard. Oct 2010 Re-charter or close down. From ogud@ogud.com Wed Feb 24 11:38:00 2010 Return-Path: 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 3FCA628C17A for ; Wed, 24 Feb 2010 11:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 tfvL48mf1XBn for ; Wed, 24 Feb 2010 11:37:59 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 403DF3A84D3 for ; Wed, 24 Feb 2010 11:37:59 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o1OJe0Wa087839 for ; Wed, 24 Feb 2010 14:40:00 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 24 Feb 2010 14:40:00 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100224_194000_027543.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-carpenter-v6ops-isp-scenarios-01.txt 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: , X-List-Received-Date: Wed, 24 Feb 2010 19:38:00 -0000 Count: 15 V6OPS B. Carpenter Internet-Draft Univ. of Auckland Intended status: Informational S. Jiang Expires: August 27, 2010 Huawei Technologies Co., Ltd February 23, 2010 Emerging Service Provider Scenarios for IPv6 Deployment draft-carpenter-v6ops-isp-scenarios-01 Abstract This document describes scenarios that are emerging among Internet Service Providers for the deployment of IPv6. They are based on practical experience so far, as well as current plans and requirements, but they are not intended as binding recommendations. From ogud@ogud.com Sat Feb 27 11:38:11 2010 Return-Path: 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 8CCE73A68C7 for ; Sat, 27 Feb 2010 11:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 MdqqvQGXmpmt for ; Sat, 27 Feb 2010 11:38:10 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E0E8728C114 for ; Sat, 27 Feb 2010 11:37:48 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o1RJe1ib019963 for ; Sat, 27 Feb 2010 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Sat, 27 Feb 2010 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100227_194001_097685.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-vixie-dnsext-dnsshadow-00.txt 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: , X-List-Received-Date: Sat, 27 Feb 2010 19:38:11 -0000 Count: 25 DNSEXT Working Group P. Vixie, ISC INTERNET-DRAFT Creation Date: 2010-02-26 Intended Status: Full Standard Use of DNS to Carry Configuration Metadata Concerning Automatic Replication of Zones Abstract Whenever it is desireable to exactly replicated the content of a DNS zone into one or more other DNS zones so that the content is reachable by multiple names at different zone apexes, it is likewise desireable that this behaviour be automated so that cooperating primary and secondary nameservers can generate and serve the entire set of shadows without human intervention and in an open multivendor manner. This document describes a new CLONE resource record for a zone apex which can guide such cooperation. From ogud@ogud.com Sat Feb 27 11:50:54 2010 Return-Path: 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 F1DE128C0F6 for ; Sat, 27 Feb 2010 11:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 i4WS5I0exjOv for ; Sat, 27 Feb 2010 11:50:53 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 22DC63A8993 for ; Sat, 27 Feb 2010 11:50:52 -0800 (PST) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o1RJe1us020033 for ; Sat, 27 Feb 2010 14:40:01 -0500 (EST) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Sat, 27 Feb 2010 14:40:01 -0500 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100227_194001_074178.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-kong-dnsop-dlv-trust-alliance-00.txt 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: , X-List-Received-Date: Sat, 27 Feb 2010 19:50:54 -0000 Count: 49 Internet Engineering Task Force N. Kong Internet-Draft Y. Zhang Intended status: Informational X. Lee Expires: August 31, 2010 CNNIC February 27, 2010 DNSSEC Lookaside Validation Trust Alliance (DLVTA) of Multiple DNSSEC Lookaside Validation (DLV) Domains draft-kong-dnsop-dlv-trust-alliance-00 Abstract This document describes a methodology for constructing DNSSEC Lookaside Validation Trust Alliance (DLVTA) of multiple DNSSEC Lookaside Validation (DLV) domains without disrupting the deployment of standard DNSSEC. The DLVTA allows validating resolvers to validate DNSSEC-signed data from multiple DLV domains without maintaining a series of trust anchors for those different DLV domains in their name server configurations.