From ogud@ogud.com Thu Sep 3 08:49:08 2009 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 A9E9728C2BA for ; Thu, 3 Sep 2009 08:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.501, 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 A8Eg-ap49fj6 for ; Thu, 3 Sep 2009 08:49:08 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id C312628C1ED for ; Thu, 3 Sep 2009 08:49:07 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n83FkvBW014167 for ; Thu, 3 Sep 2009 11:46:57 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 3 Sep 2009 11:46:57 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "ogud" Message-ID: <20090903_154657_000869.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-dempsky-dnscurve-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, 03 Sep 2009 15:49:08 -0000 Count: 84 Network Working Group M. Dempsky Internet-Draft OpenDNS, Inc. Intended status: Standards Track August 26, 2009 Expires: February 27, 2010 DNSCurve: Link-level security for the Domain Name System draft-dempsky-dnscurve-00 Abstract This document describes DNSCurve, a protocol extension that adds link-level security to the Domain Name System (DNS). From ogud@ogud.com Thu Sep 3 08:49:11 2009 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 C047B28C1ED for ; Thu, 3 Sep 2009 08:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 N1qsEKVR5fDN for ; Thu, 3 Sep 2009 08:49:11 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id DAE9A28C30E for ; Thu, 3 Sep 2009 08:49:10 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n83Fkv9V014187 for ; Thu, 3 Sep 2009 11:46:57 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 3 Sep 2009 11:46:57 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "ogud" Message-ID: <20090903_154657_026745.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-hoffman-dnssec-alg-allocation-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: Thu, 03 Sep 2009 15:49:11 -0000 Count: 16 Network Working Group P. Hoffman Internet-Draft VPN Consortium Updates: 2535, 3755, 4034 August 27, 2009 (if approved) Intended status: Standards Track Expires: February 28, 2010 Cryptographic Algorithm Identifier Allocation for DNSSEC draft-hoffman-dnssec-alg-allocation-01 Abstract This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the rule from "standard required" to "RFC required". From ogud@ogud.com Thu Sep 3 08:49:13 2009 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 656B828C319 for ; Thu, 3 Sep 2009 08:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, J_CHICKENPOX_42=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 u2WLpCvNaRDI for ; Thu, 3 Sep 2009 08:49:12 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 071CD28C1ED for ; Thu, 3 Sep 2009 08:49:11 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n83FktTK013909 for ; Thu, 3 Sep 2009 11:46:55 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 3 Sep 2009 11:46:55 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "ogud" Message-ID: <20090903_154655_055687.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-enum-enumservices-transition-02.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, 03 Sep 2009 15:49:13 -0000 Count: 12 ENUM -- Telephone Number Mapping B. Hoeneisen Working Group Swisscom Internet-Draft A. Mayrhofer Updates: 3762, 3764, 3953, 4143, enum.at 4002, 4238, 4355, 4415, 4769, Aug 18, 2009 4969, 4979, 5028, 5278 (if approved) Intended status: BCP Expires: February 19, 2010 Update of legacy IANA Registrations of Enumservices draft-ietf-enum-enumservices-transition-02 Abstract This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in [RFC3761]. From ogud@ogud.com Thu Sep 3 08:49:14 2009 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 005D828C1ED for ; Thu, 3 Sep 2009 08:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.426, 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 HPuVxrisf0CS for ; Thu, 3 Sep 2009 08:49:13 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 172B628C2BA for ; Thu, 3 Sep 2009 08:49:12 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n83FktwU013923 for ; Thu, 3 Sep 2009 11:46:55 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 3 Sep 2009 11:46:55 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "ogud" Message-ID: <20090903_154655_027659.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-wbeebee-v6ops-ipv6-cpe-router-bis-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, 03 Sep 2009 15:49:14 -0000 Count: 16 Network Working Group H. Singh Internet-Draft W. Beebee Intended status: Informational Cisco Systems, Inc. Expires: February 19, 2010 August 18, 2009 IPv6 CPE Router Recommendations(bis) draft-wbeebee-v6ops-ipv6-cpe-router-bis-00 Abstract This document continues the work undertaken by a earlier version of this document. IETF preferred to expedite the IPv6 CPE Router document. As a result, anything that was seen to be under development for a technology or feature for the IPv6 CPE Router has been moved to this document. From ogud@ogud.com Thu Sep 3 10:13:32 2009 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 95ED33A635F for ; Thu, 3 Sep 2009 10:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.401, 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 yoJr0E6R5LKp for ; Thu, 3 Sep 2009 10:13:31 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id CC0C028C37D for ; Thu, 3 Sep 2009 10:12:16 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n83Fku9w014051 for ; Thu, 3 Sep 2009 11:46:56 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 3 Sep 2009 11:46:56 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "ogud" Message-ID: <20090903_154656_041864.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-jones-dime-extended-naptr-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, 03 Sep 2009 17:13:32 -0000 Count: 37 Individual Submission M. Jones Internet-Draft Bridgewater Systems Updates: 3588 (if approved) J. Korhonen Intended status: Standards Track Nokia Siemens Networks Expires: February 24, 2010 August 23, 2009 Diameter Extended NAPTR draft-jones-dime-extended-naptr-00 Abstract This document describes an extended format for the NAPTR service fields used in dynamic Diameter agent discovery. The extended format allows NAPTR queries contain Diameter Application-Id information. From ogud@ogud.com Thu Sep 3 10:13:33 2009 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 5619728C2C6 for ; Thu, 3 Sep 2009 10:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.379, 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 opU8DE43foXU for ; Thu, 3 Sep 2009 10:13:32 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 8954028C380 for ; Thu, 3 Sep 2009 10:12:17 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n83Fkwpu014213 for ; Thu, 3 Sep 2009 11:46:58 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 3 Sep 2009 11:46:58 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "ogud" Message-ID: <20090903_154658_073007.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-dnsop-transport-for-dns-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, 03 Sep 2009 17:13:33 -0000 Count: 22 DNSOPS B. Manning Internet-Draft EP.NET Intended status: Informational August 27, 2009 Expires: February 28, 2010 Transport Considerations for DNS draft-dnsop-transport-for-dns-00 Abstract DNS queries and responses are available over a variety of transports (UDP/TCP) and may be ported to use other transports in the future. Current use profiles show that most user generated DNS traffic prefers one transport over another. This historical usage pattern has or may lead to the presumption that any DNS traffic, regardless of transport, should be considered on equal footing. From ogud@ogud.com Thu Sep 3 10:13:33 2009 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 71B5628C369 for ; Thu, 3 Sep 2009 10:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.359, 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 QXRro+odNGPa for ; Thu, 3 Sep 2009 10:13:32 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 4B05228C383 for ; Thu, 3 Sep 2009 10:12:18 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n83FkwFG014335 for ; Thu, 3 Sep 2009 11:46:58 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 3 Sep 2009 11:46:58 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "ogud" Message-ID: <20090903_154658_015946.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-barwood-dnsext-dns-transport-03.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, 03 Sep 2009 17:13:33 -0000 Count: 39 DNS Extensions Working Group G. Barwood Internet-Draft Intended status: Experimental 2 September 2009 Expires: March 2010 DNS Transport draft-barwood-dnsext-dns-transport-03 Abstract Describes an experimental transport protocol for DNS. IP fragmentation is avoided, blind spoofing, amplification attacks and other denial of service attacks are prevented. Latency for a typical DNS query is a single round trip, after a setup exchange that establishes a long term shared secret. No per-client server state is required between transactions. The protocol may have other applications. From ogud@ogud.com Thu Sep 3 10:13:33 2009 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 D636628C2C6 for ; Thu, 3 Sep 2009 10:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, J_CHICKENPOX_21=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 ynJbXvu0AEvD for ; Thu, 3 Sep 2009 10:13:33 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id C42A228C385 for ; Thu, 3 Sep 2009 10:12:20 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n83FkvPk014147 for ; Thu, 3 Sep 2009 11:46:57 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 3 Sep 2009 11:46:57 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "ogud" Message-ID: <20090903_154657_066043.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-behave-address-format-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, 03 Sep 2009 17:13:33 -0000 Count: 11 Network Working Group C. Huitema Internet-Draft Microsoft Corporation Obsoletes: 2765 (if approved) C. Bao Intended status: Standards Track CERNET Center/Tsinghua University Expires: February 27, 2010 M. Bagnulo UC3M M. Boucadair France Telecom X. Li CERNET Center/Tsinghua University August 26, 2009 IPv6 Addressing of IPv4/IPv6 Translators draft-ietf-behave-address-format-00.txt Abstract This document discusses how an individual IPv6 address can be algorithmically translated to a corresponding IPv4 address, and vice versa, using only statically configured information. This technique is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. From ogud@ogud.com Thu Sep 3 10:13:34 2009 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 F07D028C36E for ; Thu, 3 Sep 2009 10:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, J_CHICKENPOX_21=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 hKF2LLptFInB for ; Thu, 3 Sep 2009 10:13:33 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id ADBDD28C1B9 for ; Thu, 3 Sep 2009 10:12:25 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n83FksYZ013830 for ; Thu, 3 Sep 2009 11:46:54 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 3 Sep 2009 11:46:54 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "ogud" Message-ID: <20090903_154654_071162.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-behave-dns64-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, 03 Sep 2009 17:13:34 -0000 Count: 207 BEHAVE WG M. Bagnulo Internet-Draft UC3M Intended status: Standards Track A. Sullivan Expires: January 5, 2010 Shinkuro P. Matthews Alcatel-Lucent I. van Beijnum IMDEA Networks July 4, 2009 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers draft-ietf-behave-dns64-00 Abstract DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. From ogud@ogud.com Thu Sep 3 10:13:34 2009 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 2CF3228C1B9 for ; Thu, 3 Sep 2009 10:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.337, 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 GzJ4Dd7wU6e5 for ; Thu, 3 Sep 2009 10:13:33 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 6894228C390 for ; Thu, 3 Sep 2009 10:12:26 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n83FksdI013886 for ; Thu, 3 Sep 2009 11:46:54 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 3 Sep 2009 11:46:54 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "ogud" Message-ID: <20090903_154654_064366.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-tsvwg-iana-ports-02.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, 03 Sep 2009 17:13:34 -0000 Count: 18 Transport Area Working Group M. Cotton Internet-Draft ICANN Updates: 2780, 4340 L. Eggert (if approved) Nokia Intended status: BCP A. Mankin Expires: February 12, 2010 Johns Hopkins Univ. J. Touch USC/ISI M. Westerlund Ericsson August 11, 2009 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Transport Protocol Port Number and Service Name Registry draft-ietf-tsvwg-iana-ports-02 Abstract This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling registration and other requests related to the transport protocol port number and service name registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates RFC2780 by obsoleting Sections 8 and 9.1 of that RFC, and it updates the IANA allocation procedures for DCCP as defined in RFC4340. From dromasca@avaya.com Fri Sep 4 01:07:58 2009 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 4504E3A699C; Fri, 4 Sep 2009 01:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 lxsn5rTHV2vv; Fri, 4 Sep 2009 01:07:56 -0700 (PDT) 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 AFAD53A696F; Fri, 4 Sep 2009 01:07:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,330,1249272000"; d="scan'208";a="182259055" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Sep 2009 04:04:28 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 04 Sep 2009 04:04:28 -0400 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, 4 Sep 2009 10:04:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for September 10, 2009 Telechat thread-index: Acos2JL3tiXjifHhRu+pDxAR6CzQmwAXTzJQ From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for September 10, 2009 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, 04 Sep 2009 08:07:58 -0000 Please find below the preliminary agenda for the 9/10 IESG telechat. Please send me your comments, questions and concerns about the documents in review and the proposed WG charters before 9/9 COB.=20 Thanks and Regards, Dan =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2.1 WG Submissions 2.1.1 New Item o draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-10.txt Transmission of IP over Ethernet over IEEE 802.16 Networks (Proposed Standard) - 1 of 9=20 Note: Gabriel Montenegro is the Document Shepherd for this document.=20 Token: Ralph Droms o draft-ietf-mpls-3209-patherr-05.txt Node behavior upon originating and receiving Resource ReserVation Protocol=20 (RSVP) Path Error message (BCP) - 2 of 9=20 Note: This document should be processed in a batch with=20 draft-ietf-mpls-gmpls-lsp-reroute and draft-ietf-mpls-soft-preemption..=20 draft-ietf-mpls-soft-preemption should be read as the last of the batch.=20 Token: Adrian Farrel o draft-ietf-mpls-soft-preemption-18.txt MPLS Traffic Engineering Soft Preemption (Proposed Standard) - 3 of 9 Note: This document should be processed in a batch with=20 draft-ietf-mpls-gmpls-lsp-reroute and draft-ietf-mpls-3209-patherr.. draft-ietf-mpls-soft-preemption should be read as the last of the batch.=20 Token: Adrian Farrel o draft-ietf-mpls-gmpls-lsp-reroute-04.txt PathErr Message Triggered MPLS and GMPLS LSP Reroute (Proposed Standard) -=20 4 of 9=20 Note: This document should be processed in a batch with=20 draft-ietf-mpls-soft-preemption and draft-ietf-mpls-3209-patherr..=20 draft-ietf-mpls-soft-preemption should be read as the last of the batch.=20 Token: Adrian Farrel o draft-ietf-dime-pmip6-03.txt Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor=20 Interaction with Diameter Server (Proposed Standard) - 5 of 9=20 Token: Dan Romascanu o draft-ietf-dime-nai-routing-03.txt Diameter User-Name and Realm Based Request Routing Clarifications (Proposed=20 Standard) - 6 of 9=20 Token: Dan Romascanu o draft-ietf-mip4-generic-notification-message-09.txt Generic Notification Message for Mobile IPv4 (Proposed Standard) - 7 of 9=20 Note: Pete McCann (pete.mccann@motorola.com) is the document shepherd. =20 Token: Jari Arkko o draft-ietf-pcn-baseline-encoding-05.txt Baseline Encoding and Transport of Pre-Congestion Information (Proposed=20 Standard) - 8 of 9=20 Note: Steven Blake (sblake@petri-meat.com) is the document shepherd. Token: Lars Eggert o draft-ietf-pwe3-segmented-pw-13.txt Segmented Pseudowire (Proposed Standard) - 9 of 9=20 Note: Stewart Bryant (stbryant@cisco.com) is the document shepherd.=20 Token: Ralph Droms 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-rosenberg-sip-app-media-tag-03.txt A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application=20 Sub-Types (Proposed Standard) - 1 of 1=20 Token: Robert Sparks 2.2.2 Returning Item o draft-housley-iesg-rfc3932bis-08.txt IESG Procedures for Handling of Independent and IRTF Stream Submissions=20 (BCP) - 1 of 1=20 Note: There is no document shepherd=20 Token: Jari Arkko 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-sipping-service-identification-03.txt Identification of Communications Services in the Session Initiation=20 Protocol (SIP) (Informational) - 1 of 3=20 Token: Robert Sparks o draft-ietf-hip-nat-traversal-08.txt Basic HIP Extensions for Traversal of Network Address Translators=20 (Experimental) - 2 of 3=20 Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document=20 shepherd.=20 Token: Ralph Droms o draft-ietf-eai-imap-utf8-07.txt IMAP Support for UTF-8 (Experimental) - 3 of 3=20 Note: Harald Alvestrand has agreed to shepherd=20 the document.. Please note that SecDir and GenArt review comments are addressed via RFC Editor notes.. Also note that the reference to obsolete=20 RFC 1341 is intentional. The name parameter was defined in RFC 1341 across=20 all media types. The subsequent version of MIME (2045/2046) deprecated it.=20 Token: Alexey Melnikov 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-drage-sipping-service-identification-03.txt A Session Initiation Protocol (SIP) Extension for the Identification of=20 Services (Informational) - 1 of 1=20 Token: Robert Sparks 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 NONE 3.3.2 Returning Item o draft-ford-behave-top-07.txt Unintended Consequence of two NAT deployments with Overlapping Address =20 Space (Informational) - 1 of 1=20 Token: Magnus Westerlund 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Virtual World Region Agent Protocol (vwrap) - 1 of 1 Token: Alexey Melnikov 4.1.2 Proposed for Approval o SIP Common Log Format (sipclf) - 1 of 1 Token: Robert Sparks 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o IP Flow Information Export (ipfix) - 1 of 3 Token: Dan Romascanu o Security Issues in Network Event Logging (syslog) - 2 of 3 Token: Pasi Eronen o Network Endpoint Assessment (nea) - 3 of 3 Token: Tim Polk 4.2.2 Proposed for Approval o DNS Extensions (dnsext) - 1 of 1 Token: Ralph Droms From rdroms@cisco.com Sat Sep 5 04:43:36 2009 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 B3BDE3A6869; Sat, 5 Sep 2009 04:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 WewW4WFlxvb3; Sat, 5 Sep 2009 04:43:35 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 450413A67F2; Sat, 5 Sep 2009 04:43:34 -0700 (PDT) X-Files: charter-current.txt, charter-20090825.txt, charter-20090825-from-current.diff.html : 2655, 2192, 20974 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFACvroUpAZnme/2dsb2JhbACCKiy9NIhDAZAYBYQXgVk X-IronPort-AV: E=Sophos;i="4.44,337,1249257600"; d="txt'?html'217?scan'217,208,217";a="56898037" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Sep 2009 11:42:57 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n85Bgv6e012453; Sat, 5 Sep 2009 07:42:57 -0400 Received: from bxb-rdroms-8714.cisco.com (bxb-rdroms-8714.cisco.com [10.98.10.85]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n85BgpgU010680; Sat, 5 Sep 2009 11:42:56 GMT Message-Id: <72816477-A7BC-407D-95D1-0A42BAB7AF42@cisco.com> From: Ralph Droms To: IESG IESG , IAB IAB , IETF DNS Directorate Content-Type: multipart/mixed; boundary=Apple-Mail-13--1034140863 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 5 Sep 2009 07:42:45 -0400 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=27381; t=1252150977; x=1253014977; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20dnsext=20recharter |Sender:=20 |To:=20IESG=20IESG=20,=20IAB=20IAB=20,=0A=20=20=20=20=20=20=20=20IETF=20DNS=20Directorate=2 0; bh=9HbZxSaFIKcWWhr0KxRzLLcyzSPvHxxwnWcKPRwK2k4=; b=UddIo/G+a68IwIp86vVbzm1ejsYWasMGD5OHI8T2HzPrwUxPyjWpZIgxVL m/MI1pPj1lh+qAprwIzP7BQqUfO88IMXDs3uEPxjRfUjwUCPDFGn1rlcxJ+s VMt0Q3A7i+; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [dns-dir] dnsext recharter 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, 05 Sep 2009 11:43:36 -0000 --Apple-Mail-13--1034140863 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Attached is the latest proposed new charter for dnsext. The recharter is motivated by a need to add seven specific candidate work areas to the WG charter and add specific rules for initiating work in each of those candidate work areas. The milestones have been updated, as well. I've attached copies of the proposed charter, the current charter and a diff. The revised charter is on the agenda for the 9/10 telechat. - Ralph --Apple-Mail-13--1034140863 Content-Disposition: attachment; filename=charter-current.txt Content-Type: text/plain; x-mac-creator=454D4178; x-unix-mode=0644; x-mac-type=54455854; name="charter-current.txt" Content-Transfer-Encoding: 7bit Description of Working Group: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT WG group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will limit itself to review of proposals for new extensions, clarification to the DNS protocol, including DNSSEC, and review of DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working groups. Adoption of new DNSEXT standards track working group items will require changes to this charter. The WG does not intend to hold face to face meetings, though may do so if deemed necessary for resolution of a specific issue at hand. The DNSEXT WG will conduct the specified RFC2929bis review of RR templates as they are posted and also maintain a living ID of errata for the DNSSEC document set. Milestones: Done Forward NSEC rdata to IESG for Proposed Standard Done Forward RFC2535-bis to IESG for proposed standard Done Forward Case Insensitive to IESG for Proposed Standard Done Forward LLMNR to IESG for Proposed Standard Done Update boilerplate text on OPT-IN Done Forward Wildcard clarification to IESG for proposed standard Feb 2007 Submit KEY algorithm documents RFC253[69]bis and RFC3110 to IESG for proposed standard Done Finalize Zone Enumeration Requirements Jun 2007 Start of process of reviewing the following RFCs and to move them to Draft Standard status Jul 2007 RFC2930 (TKEY) to Draft standard Jul 2007 RFC2181 (Clarify) to Draft Standard Jul 2007 RFC2136 (Dynamic Update) to Draft Standard Jul 2007 RFC2308 (Neg Caching) to Draft Standard Jul 2007 RFC3007 (Secure Update) to Draft Standard Jul 2007 RFC2782 (SRV RR) to Draft Standard Jul 2007 RFC2671 (EDNS0) to Draft Standard Jul 2007 RFC1995 (IXFR) to Draft standard Jul 2007 RFC2672 (DNAME) to Draft Standard or revision Jul 2007 RFC1996 (Notify) to Draft Standard Jul 2007 Submit to IESG RFC2845 (TSIG)to Draft standard Jul 2007 RFC1982 (Serial Number Arithmetic) Jul 2007 FRC2539 (DH Key RR) to Draft Standard Jul 2007 RFC3226 (Message Size) to Draft Standard Done RFC2538 (CERT RR) to Draft Standard Done Forgery Resilience advanced to IESG Oct 2008 DNAMEbis advanced to IESG Nov 2008 ENDS0bis advanced to IESG Nov 2008 AXFR-clarify advanced to IESG Dec 2008 DNS-profile advanced to IESG Feb 2009 RFC2536bis and RFC2539bis advanced to IESG. --Apple-Mail-13--1034140863 Content-Disposition: attachment; filename=charter-20090825.txt Content-Type: text/plain; x-mac-creator=74747874; x-unix-mode=0644; x-mac-type=42494E41; name="charter-20090825.txt" Content-Transfer-Encoding: 7bit Description of Working Group: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT WG group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will limit itself to review of proposals for new extensions and clarification to the DNS protocol, including DNSSEC. Adoption of new work targeted for standards track will require changes to this charter. The working group can nevertheless undertake work in following subjects without a charter change: DNSSEC and TSIG/TKEY algorithm maintenance Hardening DNS protocol and providing guidance to implementors Advancing existing Proposed Standard RFCs to Draft/Full Standard Obsoleting RFCs. Maintaining a Wiki containing a guide to DNS protocol RFC's. Improving DNS zone synchronization mechanisms Examining transport protocols, possibly adding new ones. Before formal adoption of any such items at least 5 working group participants must publicly state that the item is within charter and is worthwhile item for further study. The DNSEXT WG will conduct the specified RFC5395 review of RR templates as they are posted, and EDNS0 Option templates if EDNS0-bis updates registration requirements. The WG will review DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working group. The WG does not intend to hold face to face meetings, though may do so if deemed necessary for resolution of a specific issue at hand. Milestones: Aug 2009 TSIG/MD5 Obsoleting to IESG. Sep 2009 EDNS0 Ping Option advanced to IESG Oct 2009 Resolver side Forgery Resilience advanced to IESG Oct 2009 DNSSEC Errata document to IESG Nov 2009 GOST DNSKEY and DS support advanced to IESG Dec 2009 EDNS0-bis update advanced to IESG Feb 2010 DNS existing transport protocol recommendations/clarifications to IESG Jan 2010 AXFR Clarify to IESG --Apple-Mail-13--1034140863 Content-Disposition: attachment; filename=charter-20090825-from-current.diff.html Content-Type: text/html; x-unix-mode=0644; name="charter-20090825-from-current.diff.html" Content-Transfer-Encoding: 7bit Diff: charter-current.txt - charter-20090825.txt
 charter-current.txt   charter-20090825.txt 
Description of Working Group: Description of Working Group:
The DNS has a large installed base and repertoire of protocol The DNS has a large installed base and repertoire of protocol
specifications. The DNSEXT WG group will actively advance DNS specifications. The DNSEXT WG group will actively advance DNS
protocol-related RFCs on the standards track while thoroughly protocol-related RFCs on the standards track while thoroughly
reviewing further proposed extensions. The scope of the DNSEXT WG is reviewing further proposed extensions. The scope of the DNSEXT WG is
confined to the DNS protocol, particularly changes that affect DNS confined to the DNS protocol, particularly changes that affect DNS
protocols "on the wire" or the internal processing of DNS data. DNS protocols "on the wire" or the internal processing of DNS data. DNS
operations are out of scope for the WG. operations are out of scope for the WG.
The WG will limit itself to review of proposals for new extensions, The WG will limit itself to review of proposals for new extensions
clarification to the DNS protocol, including DNSSEC, and review of and clarification to the DNS protocol, including DNSSEC. Adoption of
DNS protocol related work which may originate elsewhere in the IETF, new work targeted for standards track will require changes to this
including AD-sponsored submissions or drafts in other working groups. charter.
Adoption of new DNSEXT standards track working group items will require
changes to this charter. The WG does not intend to hold face to face The working group can nevertheless undertake work in following
subjects without a charter change:
DNSSEC and TSIG/TKEY algorithm maintenance
Hardening DNS protocol and providing guidance to implementors
Advancing existing Proposed Standard RFCs to Draft/Full Standard
Obsoleting RFCs.
Maintaining a Wiki containing a guide to DNS protocol RFC's.
Improving DNS zone synchronization mechanisms
Examining transport protocols, possibly adding new ones.
Before formal adoption of any such items at least 5 working group
participants must publicly state that the item is within charter and is
worthwhile item for further study.
The DNSEXT WG will conduct the specified RFC5395 review of RR
templates as they are posted, and EDNS0 Option templates if EDNS0-bis
updates registration requirements.
The WG will review DNS protocol related work which may originate
elsewhere in the IETF, including AD-sponsored submissions or drafts
in other working group. The WG does not intend to hold face to face
meetings, though may do so if deemed necessary for resolution of a meetings, though may do so if deemed necessary for resolution of a
specific issue at hand. specific issue at hand.
The DNSEXT WG will conduct the specified RFC2929bis review of RR
templates as they are posted and also maintain a living ID of errata
for the DNSSEC document set.
Milestones: Milestones:
Done Forward NSEC rdata to IESG for Proposed Standard Aug 2009 TSIG/MD5 Obsoleting to IESG.
Done Forward RFC2535-bis to IESG for proposed standard Sep 2009 EDNS0 Ping Option advanced to IESG
Done Forward Case Insensitive to IESG for Proposed Standard Oct 2009 Resolver side Forgery Resilience advanced to IESG
Done Forward LLMNR to IESG for Proposed Standard Oct 2009 DNSSEC Errata document to IESG
Done Update boilerplate text on OPT-IN Nov 2009 GOST DNSKEY and DS support advanced to IESG
Done Forward Wildcard clarification to IESG for proposed standard Dec 2009 EDNS0-bis update advanced to IESG
Feb 2007 Submit KEY algorithm documents RFC253[69]bis and RFC3110 to IESG for proposed standard Feb 2010 DNS existing transport protocol recommendations/clarifications to IESG
Done Finalize Zone Enumeration Requirements Jan 2010 AXFR Clarify to IESG
Jun 2007 Start of process of reviewing the following RFCs and to move them to Draft Standard status
Jul 2007 RFC2930 (TKEY) to Draft standard
Jul 2007 RFC2181 (Clarify) to Draft Standard
Jul 2007 RFC2136 (Dynamic Update) to Draft Standard
Jul 2007 RFC2308 (Neg Caching) to Draft Standard
Jul 2007 RFC3007 (Secure Update) to Draft Standard
Jul 2007 RFC2782 (SRV RR) to Draft Standard
Jul 2007 RFC2671 (EDNS0) to Draft Standard
Jul 2007 RFC1995 (IXFR) to Draft standard
Jul 2007 RFC2672 (DNAME) to Draft Standard or revision
Jul 2007 RFC1996 (Notify) to Draft Standard
Jul 2007 Submit to IESG RFC2845 (TSIG)to Draft standard
Jul 2007 RFC1982 (Serial Number Arithmetic)
Jul 2007 FRC2539 (DH Key RR) to Draft Standard
Jul 2007 RFC3226 (Message Size) to Draft Standard
Done RFC2538 (CERT RR) to Draft Standard
Done Forgery Resilience advanced to IESG
Oct 2008 DNAMEbis advanced to IESG
Nov 2008 ENDS0bis advanced to IESG
Nov 2008 AXFR-clarify advanced to IESG
Dec 2008 DNS-profile advanced to IESG
Feb 2009 RFC2536bis and RFC2539bis advanced to IESG.
 End of changes. 3 change blocks. 
10 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/
--Apple-Mail-13--1034140863-- From ogud@ogud.com Tue Sep 8 08:38:00 2009 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 194503A6A60 for ; Tue, 8 Sep 2009 08:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 1jORHPnkm0+S for ; Tue, 8 Sep 2009 08:37:59 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 8BA473A698C for ; Tue, 8 Sep 2009 08:37:58 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n88FcOsn035673; Tue, 8 Sep 2009 11:38:24 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200909081538.n88FcOsn035673@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 08 Sep 2009 11:35:04 -0400 To: "Romascanu, Dan (Dan)" , From: Olafur Gudmundsson In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for September 10, 2009 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: Tue, 08 Sep 2009 15:38:00 -0000 None of the documents is in the DNS-early warning system. Olafur At 04:04 04/09/2009, Romascanu, Dan (Dan) wrote: >Please find below the preliminary agenda for the 9/10 IESG telechat. >Please send me your comments, questions and concerns about the documents >in review and the proposed WG charters before 9/9 COB. > >Thanks and Regards, > >Dan > > >-----Original Message----- >From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of >IESG Secretary > > >2.1 WG Submissions >2.1.1 New Item > o draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-10.txt > Transmission of IP over Ethernet over IEEE 802.16 Networks (Proposed > > Standard) - 1 of 9 > Note: Gabriel Montenegro is the Document > > Shepherd for this document. > Token: Ralph Droms > o draft-ietf-mpls-3209-patherr-05.txt > Node behavior upon originating and receiving Resource ReserVation >Protocol > (RSVP) Path Error message (BCP) - 2 of 9 > Note: This document should be processed in a batch with > draft-ietf-mpls-gmpls-lsp-reroute and >draft-ietf-mpls-soft-preemption.. > draft-ietf-mpls-soft-preemption should be read as the last of the >batch. > Token: Adrian Farrel > o draft-ietf-mpls-soft-preemption-18.txt > MPLS Traffic Engineering Soft Preemption (Proposed Standard) - 3 of >9 > > Note: This document should be processed in a batch with > draft-ietf-mpls-gmpls-lsp-reroute and draft-ietf-mpls-3209-patherr.. > > draft-ietf-mpls-soft-preemption should be read as the last of the >batch. > Token: Adrian Farrel > o draft-ietf-mpls-gmpls-lsp-reroute-04.txt > PathErr Message Triggered MPLS and GMPLS LSP Reroute (Proposed >Standard) - > 4 of 9 > Note: This document should be processed in a batch with > draft-ietf-mpls-soft-preemption and draft-ietf-mpls-3209-patherr.. > draft-ietf-mpls-soft-preemption should be read as the last of the >batch. > Token: Adrian Farrel > o draft-ietf-dime-pmip6-03.txt > Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility >Anchor > Interaction with Diameter Server (Proposed Standard) - 5 of 9 > Token: Dan Romascanu > o draft-ietf-dime-nai-routing-03.txt > Diameter User-Name and Realm Based Request Routing Clarifications >(Proposed > Standard) - 6 of 9 > Token: Dan Romascanu > o draft-ietf-mip4-generic-notification-message-09.txt > Generic Notification Message for Mobile IPv4 (Proposed Standard) - 7 >of 9 > Note: Pete McCann (pete.mccann@motorola.com) is the document >shepherd. > > Token: Jari Arkko > o draft-ietf-pcn-baseline-encoding-05.txt > Baseline Encoding and Transport of Pre-Congestion Information >(Proposed > Standard) - 8 of 9 > Note: Steven Blake (sblake@petri-meat.com) is the document shepherd. > > Token: Lars Eggert > o draft-ietf-pwe3-segmented-pw-13.txt > Segmented Pseudowire (Proposed Standard) - 9 of 9 > Note: Stewart Bryant (stbryant@cisco.com) is the document shepherd. > Token: Ralph Droms > >2.1.2 Returning Item >NONE > >2.2 Individual Submissions >2.2.1 New Item > o draft-rosenberg-sip-app-media-tag-03.txt > A Session Initiation Protocol (SIP) Media Feature Tag for MIME >Application > Sub-Types (Proposed Standard) - 1 of 1 > Token: Robert Sparks > >2.2.2 Returning Item > o draft-housley-iesg-rfc3932bis-08.txt > IESG Procedures for Handling of Independent and IRTF Stream >Submissions > (BCP) - 1 of 1 > Note: There is no document shepherd > Token: Jari Arkko > > >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-sipping-service-identification-03.txt > Identification of Communications Services in the Session Initiation > Protocol (SIP) (Informational) - 1 of 3 > Token: Robert Sparks > o draft-ietf-hip-nat-traversal-08.txt > Basic HIP Extensions for Traversal of Network Address Translators > (Experimental) - 2 of 3 > Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the >document > shepherd. > Token: Ralph Droms > o draft-ietf-eai-imap-utf8-07.txt > IMAP Support for UTF-8 (Experimental) - 3 of 3 > Note: Harald Alvestrand has agreed to >shepherd > the document.. Please note that SecDir and GenArt review comments >are > > addressed via RFC Editor notes.. Also note that the reference to >obsolete > RFC 1341 is intentional. The name parameter was defined in RFC 1341 >across > all media types. The subsequent version of MIME (2045/2046) >deprecated >it. > Token: Alexey Melnikov > >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-drage-sipping-service-identification-03.txt > A Session Initiation Protocol (SIP) Extension for the Identification >of > Services (Informational) - 1 of 1 > Token: Robert Sparks > >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 >NONE >3.3.2 Returning Item > o draft-ford-behave-top-07.txt > Unintended Consequence of two NAT deployments with Overlapping >Address > > Space (Informational) - 1 of 1 > Token: Magnus Westerlund > > >4. Working Group Actions >4.1 WG Creation >4.1.1 Proposed for IETF Review > o Virtual World Region Agent Protocol (vwrap) - 1 of 1 > Token: Alexey Melnikov >4.1.2 Proposed for Approval > o SIP Common Log Format (sipclf) - 1 of 1 > Token: Robert Sparks >4.2 WG Rechartering >4.2.1 Under evaluation for IETF Review > o IP Flow Information Export (ipfix) - 1 of 3 > Token: Dan Romascanu > o Security Issues in Network Event Logging (syslog) - 2 of 3 > Token: Pasi Eronen > o Network Endpoint Assessment (nea) - 3 of 3 > Token: Tim Polk >4.2.2 Proposed for Approval > o DNS Extensions (dnsext) - 1 of 1 > Token: Ralph Droms > >_______________________________________________ >dns-dir mailing list >dns-dir@ietf.org >https://www.ietf.org/mailman/listinfo/dns-dir From ogud@ogud.com Tue Sep 8 11:29:32 2009 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 B049628C241 for ; Tue, 8 Sep 2009 11:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.366, 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 Ooylr-Sv3Cbt for ; Tue, 8 Sep 2009 11:29:31 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 98CE428C277 for ; Tue, 8 Sep 2009 11:29:31 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n88IU0XN037025 for ; Tue, 8 Sep 2009 14:30:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 8 Sep 2009 14:30:00 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090908_183000_003246.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-iucg-wgidnabislc-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, 08 Sep 2009 18:29:32 -0000 Count: 80 Network Working Group Jean-Francois C. Morfin Internet-Draft Intlnet Intended status: Independent submission September 7, 2009 Expires: March 8, 2010 WG-IDNABIS/LC comments and responses draft-iucg-wgidnabislc-00.txt Abstract The IDNA is a key issue for the IUCG as a paradigm for the future of the Internet. There is therefore a need to make sure its description document set reflects a complete IETF and users consensus. To help this, this memo keeps track of the WG-IDNABIS/LC requested and received answers. The IAB Draft on IDN has been added because some remarks have been made which are important. The author is quoted if the comment is not from IUCG From dromasca@avaya.com Wed Sep 9 06:57:51 2009 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 052973A6869; Wed, 9 Sep 2009 06:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 4FL5kGJlsBBD; Wed, 9 Sep 2009 06:57:50 -0700 (PDT) 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 64AA63A6976; Wed, 9 Sep 2009 06:57:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,358,1249272000"; d="scan'208";a="156290019" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Sep 2009 09:58:10 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Sep 2009 09:58:09 -0400 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, 9 Sep 2009 15:57:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-carpenter-renum-needs-work (Renumbering still needswork) to Informational RFC thread-index: AcoxT03DzaJIDCuvQQWxXLS/jI9tvgABQvDA From: "Romascanu, Dan (Dan)" To: , , Cc: Brian E Carpenter Subject: [dns-dir] FW: Last Call: draft-carpenter-renum-needs-work (Renumbering still needswork) to Informational RFC 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, 09 Sep 2009 13:57:51 -0000 I am drawing the attention of the IP, DNS and OPS directorates on this document now in IETF LC.=20 Comments are welcome.=20 Thanks and Regards, Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Wednesday, September 09, 2009 4:12 PM To: IETF-Announce Subject: Last Call: draft-carpenter-renum-needs-work (Renumbering still needswork) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Renumbering still needs work ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-03. txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 17818&rfc_flag=3D0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From dromasca@avaya.com Wed Sep 9 08:01:10 2009 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 CE9CA28C217; Wed, 9 Sep 2009 08:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 QvYyr0GOKyFn; Wed, 9 Sep 2009 08:01:09 -0700 (PDT) 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 85B9128C212; Wed, 9 Sep 2009 08:01:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,358,1249272000"; d="scan'208";a="182723104" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Sep 2009 11:01:41 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Sep 2009 11:01:40 -0400 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, 9 Sep 2009 17:01:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available thread-index: AcoxW3x0itr054ovT3Oh2zchhv74PgAALA6gAACI9JA= From: "Romascanu, Dan (Dan)" To: , , , "MIB Doctors (E-mail)" Subject: [dns-dir] FW: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available 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, 09 Sep 2009 15:01:10 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Wednesday, September 09, 2009 5:47 PM To: Working Group Chairs Subject: FW: Nomcom 2009-10: Important Reminder: Call for Nominations,Local Office hours, Nominee Questionnaires available=20 Hi all, Thanks to the ADs and chairs that forwarded the previous reminder to their mailing lists. I would appreciate it if other chairs and ADs could do so, since we are really in need of more nominations. Thanks, Mary.=20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of Barnes, Mary (RICH2:AR00) Sent: Wednesday, September 09, 2009 9:38 AM To: IETF Announcement list Cc: ietf@ietf.org Subject: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available=20 Hi all, This is a 2nd reminder of the Call for Nominations that is underway. We *really* need more nominations in order to properly execute the task of selecting candidates for the open positions. At this time, the number of nominations for all the positions is about 1/2 of what is necessary for the Nomcom to do a conscientious job of evaluating the nominees and we are over 2/3 of the way through the nominations period. Nomcom cannot do their job without this important input from the community.=20 So, please consider making nominations for the open positions - it takes just a few minutes of your time - the details are below. Right now, we just need the names/email addresses for the nominees - we'll be soliciting feedback later. Also, consider that over 1/2 the nominees are not able to accept the nominations for a variety of reasons - e.g., lack of funding, lack of sponsor support, etc. Thus, please consider nominating more than one individual for each of the positions. =20 As well as the reminder for the call for nominations, this email also serves as a reminder for: 2) Local Office Hours 3) Questionnaires available for nominees=20 Best Regards, Mary Barnes nomcom-chair@ietf.org mary.h.barnes@gmail.com mary.barnes@nortel.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D 1) Call for Nominations ------------------------ The nomination period ends in less than 2 weeks on Sept. 18th, 2009. We appreciate the folks that have taken the time to make nominations thus far. But, we do need more nominations. Please use the online tool to nominate - it's fast, easy and secure: https://wiki.tools.ietf.org/group/nomcom/09/nominate Details on the open positions, as well as other details and options for making nominations are available on the Nomcom homepage: https://wiki.tools.ietf.org/group/nomcom/09/ Please consider that the sooner you make the nominations, the more time your nominee(s) will have to complete the necessary questionnaire (item 3 below). As well, please consider nominating more than one person for a particular position. You will have the opportunity to provide additional feedback later and it's important to consider that not all nominees will be able to accept the nomination.=20 2) Local office hours ----------------------- In order facilitate additional feedback, the Nomcom has decided to make themselves available for office areas at various geographic locations for 3 weeks in September, starting on the 8th.=20 Below please find the list of locations where Nomcom members will be available for these f2f meetings . Unless dates are identified below, the Nomcom member is generally available for part of the day during the weeks of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than English in which the Nomcom member is fluent are identfied. =20 Please contact a Nomcom member in a specific geographic location to arrange a convenient meeting time and place. Most Nomcom members are flexible as to meeting locations - i.e., we can travel to your office, meet at our offices or somewhere in between. =20 As a reminder folks can always contact any Nomcom member to provide feedback at anytime - i.e., you don't need to participate in these f2f sessions to provide feedback.=20 Belgium:=20 Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 21-25) (Languages: French)=20 Boston, Mass, USA: =20 Stephen Kent - kent@bbn.com (Sept 16-18)=20 Boulder, CO, USA:=20 Wassim Haddad - wmhaddad@gmail.com (Sept 14-18) Dallas/Ft. Worth, TX, USA: =20 Mary Barnes - mary.h.barnes@gmail.com=20 Lucy Yong - lucyyong@huawei.com (Languages: Chinese)=20 Helsinki, Finland:=20 Simo Veikkolainen - simo.veikkolainen@nokia.com (Languages: Finnish) =20 Ithaca, NY, USA:=20 Scott Brim - scott.brim@gmail.com Montevideo, Uruguay:=20 Roque Gagliano - roque@lacnic.net (Sept 14-18, 21-25) (Languages: Spanish, Portuguese)=20 Montreal, Quebec, Canada=20 Wassim Haddad - wmhaddad@gmail.com (Sept 8-11) -- Can also be available in Ottawa if folks are interested=20 Paris, France:=20 Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 15-18) (Languages: French) San Diego, CA, USA:=20 Randall Gellens - rg+ietf@qualcomm.com =20 Dave Crocker - dcrocker@bbiw.net (Sept 16-18) Silicon Valley/SF Bay, CA, USA:=20 Dave Crocker - dcrocker@bbiw.net (Sept 8-11, Sept 14-15, Sept 21-25) =20 Dorothy Gellert - Dorothy.gellert@gmail.com 3) Questionnaires available for nominees:=20 For folks that have been notified that they have been nominated for any of the positions, the questionnaires are now available on the Nomcom09 tools website: https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire If you have any questions, please let me know. I will be contacting everyone individually, as well as sending reminders.=20 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From ogud@ogud.com Wed Sep 9 11:29:35 2009 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 81D533A689F for ; Wed, 9 Sep 2009 11:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 dHSJLE30sHaU for ; Wed, 9 Sep 2009 11:29:34 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 8EE393A67AE for ; Wed, 9 Sep 2009 11:29:31 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n89IU1YA022968 for ; Wed, 9 Sep 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Wed, 9 Sep 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090909_183001_009603.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-yao-ccn-ddds-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, 09 Sep 2009 18:29:35 -0000 Count: 26 Network Working Group J. YAO Internet-Draft X. Lee Intended status: BCP CNNIC Expires: March 12, 2010 September 8, 2009 Chinese Common Name to Uniform Resource Identifier(URI) Dynamic Delegation Discovery System(DDDS) Application(CCN) draft-yao-ccn-ddds-00.txt Abstract This document discusses the use of the Domain Name System(DNS) for storage of Chinese Common Name to URI mapping. More specifically, how DNS can be used for identifying URIs or services associated with the Chinese Common Names. The method used to discover the mapping is the Dynamic Delegation Discovery System, which can be found in a series of documents specified in RFC 3401. Understanding of RFC 3401 is necessary for understanding this document. From ogud@ogud.com Thu Sep 10 11:29:38 2009 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 7F63728C199 for ; Thu, 10 Sep 2009 11:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.340, 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 h4-xzOwt0j44 for ; Thu, 10 Sep 2009 11:29:37 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 7D5E43A6A94 for ; Thu, 10 Sep 2009 11:29:37 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n8AIU02W032703 for ; Thu, 10 Sep 2009 14:30:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 10 Sep 2009 14:30:00 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090910_183000_090480.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-dekok-radext-nai-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, 10 Sep 2009 18:29:38 -0000 Count: 24 Network Working Group DeKok, Alan (Ed.) INTERNET-DRAFT FreeRADIUS Obsoletes: 4282 Category: Standards Track 9 September 2009 The Network Access Identifier draft-dekok-radext-nai-00 This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support. This document is a revised version of RFC 4282, which addresses issues with international character sets, as well as a number of other corrections to the previous RFC. From rdroms@cisco.com Thu Sep 10 14:14:36 2009 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 533DD3A6883 for ; Thu, 10 Sep 2009 14:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, 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 XgC+t9ExWhoM for ; Thu, 10 Sep 2009 14:14:35 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 201593A6849 for ; Thu, 10 Sep 2009 14:14:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKoJqUpAZnmf/2dsb2JhbADGS4hGAZBDBYQYgVk X-IronPort-AV: E=Sophos;i="4.44,366,1249257600"; d="scan'208";a="57599228" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Sep 2009 21:15:09 +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 n8ALF9eY019254 for ; Thu, 10 Sep 2009 17:15:09 -0400 Received: from bxb-rdroms-8714.cisco.com (bxb-rdroms-8714.cisco.com [10.98.10.85]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8ALF4TD014821 for ; Thu, 10 Sep 2009 21:15:09 GMT Message-Id: <53D2001E-3489-4E7F-8C5B-07150F9740D4@cisco.com> From: Ralph Droms To: IETF DNS Directorate Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 10 Sep 2009 17:15:03 -0400 References: <20090909014501.DB9093A6AD0@core3.amsl.com> X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=867; t=1252617309; x=1253481309; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Fwd=3A=20New=20Version=20Notification=20-=20=20 draft-cheshire-dnsext-multicastdns-08.txt=20 |Sender:=20 |To:=20IETF=20DNS=20Directorate=20; bh=VG7CTbYjNb7QYq4n6tEwvUuT4si1nI55VQUBpsSizq4=; b=lGYgo+9T40ekTKKH1mgrTrnfZIBBVBgcD2T8zo28kmbWW1fwRsGiUwFcxf ndRccdJgXXeu67agbjCPy/KM/YMXu2HhlHLlZyXtRqTUsK4Ue2TLZ1kEuX1B o4ZcEwOzbD; Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [dns-dir] Fwd: New Version Notification - draft-cheshire-dnsext-multicastdns-08.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, 10 Sep 2009 21:14:36 -0000 FYI... I've come late to the review of this doc. I'd appreciate review and comments on the latest rev, and any history or other background I should know about. - Ralph Begin forwarded message: > From: Internet-Draft@ietf.org > Date: September 8, 2009 9:45:01 PM EDT > To: marc@apple.com, cheshire@apple.com, draft-cheshire-dnsext-multicastdns@tools.ietf.org > , rdroms@cisco.com > Subject: New Version Notification - draft-cheshire-dnsext- > multicastdns-08.txt > > New version (-08) has been submitted for draft-cheshire-dnsext- > multicastdns-08.txt. > http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-multicastdns-08.txt > Sub state has been changed to AD Follow up from New Id Needed > > Diff from previous version: > http://tools.ietf.org/rfcdiff?url2=draft-cheshire-dnsext-multicastdns-08 > > IETF Secretariat. From tina.dam@icann.org Mon Sep 14 09:56:37 2009 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 2397828C1B4 for ; Mon, 14 Sep 2009 09:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.316 X-Spam-Level: X-Spam-Status: No, score=-5.316 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6bHoh3lxJOl for ; Mon, 14 Sep 2009 09:56:36 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 37CF928C1B2 for ; Mon, 14 Sep 2009 09:56:36 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 14 Sep 2009 09:57:21 -0700 From: Tina Dam To: Peter Koch , IETF DNS Directorate Date: Mon, 14 Sep 2009 09:57:07 -0700 Thread-Topic: [dns-dir] draft-liman-tld-names-00 Thread-Index: Acopry/rwNvdYDTPRPunCbTOJGAKHQLrHMZQ Message-ID: <05B243F724B2284986522B6ACD0504D7C0842F0483@EXVPMBX100-1.exc.icann.org> References: <200908251601.n7PG1lKO016004@cichlid.raleigh.ibm.com> <20090826030713.GD5405@shinkuro.com> <200908261228.n7QCS8OF014747@cichlid.raleigh.ibm.com> <20090826132745.GC6533@shinkuro.com> <05B243F724B2284986522B6ACD0504D7C083C6A7F3@EXVPMBX100-1.exc.icann.org> <22y6p3pugw.fsf@zaptop.autonomica.net> <20090830195950.GE30426@x27.adm.denic.de> In-Reply-To: <20090830195950.GE30426@x27.adm.denic.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dns-dir] draft-liman-tld-names-00 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, 14 Sep 2009 16:56:37 -0000 Peter, all, I believe the draft has now expired. This is generating some co= ncerns about timing for IDN TLDs in the root vs the revision of RFC1123. I = personally believe we have time to get this moving forward, but please note= that the IDN ccTLD Fast Track Process is scheduled for Board consideration= at the Korea meeting (26-30 October 09). A positive Board consideration wo= uld mean an almost immediate launch of the process. Several countries have = indicated that they will be sending in applications and are ready to launch= , right away. I am not stating this to force the revision forward in an inappropriate way= . But based on the previous discussions on the subject it looks feasible to= propose a revision that is not inappropriate or forced in time. I personally do not know the IETF process well enough (yet :) ) to know how= to make this discussion continue (i.e. updating the draft or other). Is th= is the authors job or can it be done by others? In other words if someone c= an point me to what needs to be done then I am happy to help, either person= ally, or by finding some adequate resources. Tina > -----Original Message----- > From: Peter Koch [mailto:peter@denic.de] On Behalf Of Peter Koch > Sent: Sunday, August 30, 2009 1:00 PM > To: IETF DNS Directorate > Cc: Tina Dam > Subject: Re: [dns-dir] draft-liman-tld-names-00 >=20 > On Fri, Aug 28, 2009 at 10:13:51PM +0200, Lars-Johan Liman wrote: > > tina.dam@icann.org: > > > All, just catching up on this note. A few comments: > > > > > 1) I agree that we should do this as minimal as possible, and goal > is > > > to allow A-label TLDs. > > > > At least that is the short term goal. >=20 > Not sure we should actually be so narrowly focussed since it looks like > "lip service" on a protocol level. From an IETF point of view I'd say > we somehow found that the phrase "will be alphabetic" appears to be > ambiguous to say the least. It is unclear whetehr it's normative and > when > it's normative whether that's a protocol or a policy statement. For > confusability in the context of that same paragraph, "will not be > digit-only" would be fine (and maintain the ambiguity, but that's a > different issue). It is this and the extreme positioning of "-" that > we > should be concerned about here. ``xn--'' (and inner dashes) would > return > into protocol boundaries as a side effect. >=20 > > > 2) on the digit concern, I previously agreed with the authors that > > > this did not belong in the RFC but instead should be controlled by > > > ICANN. Currently ICANN does not allow leading or trailing digits in > > > TLDs. It does not really matter to me where that rule sits, as long > as > > > it is observed. The reason for the ICANN requirement was not "just" > > > the confusability with octets or numeric addresses but also due to > the > > > results we see with leading trailing digits in a right-to-left > > > environment. Because this is a new area it was thought that we > better > > > be conservative and restrict it completely. > > > > That is indeed a valid remark, IMO. This should be documented in the > > draft, and that makes the motivation for such a rule even stronger. >=20 > IMHO we (=3D=3DIETF) should constrain ourselves to solve an observed > ambiguity. ICANN is to set the policy and if there are valid reasons > for restrictions, they don't completely have to originate from IETF > documents. If there are special conceerns with digits in IDN TLDs, > that's something hopefully covered in operational connsiderations in > IDN documents, at least it is different from the 1123 amendment. >=20 > > > Also, please let me know what I can help with to get this > finalized. I > > > do believe it is necessary in order for ICANN not to be in > violation > > > of the RFC when launching IDN TLDs. > > > > I still haven't heard any voices from the DNSOP chairs. I suppose > they > > are busy building a solid case defending how to make this document > > _not_ end up on their table ... (Hi, Peter and Rob! ;-). >=20 > First, given the sensitivity of the topic, I don't think an individual > submission sets the right signal. I know that some core IETF protocols > have been worked on this way recently, but it's my firm belief this is > a step in the wrong direction. Open discussion is key here and for > BCP or STD track, there'd be an main IETF list debac^Hte anyway. > I'm happy to have the discussion continue on dnsop. >=20 > FWIW, the draft is about to expire in a few days. >=20 > Best regards, > Peter From dromasca@avaya.com Tue Sep 15 11:27:44 2009 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 67F1F3A6A37; Tue, 15 Sep 2009 11:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 NNwkbbPq1Ywp; Tue, 15 Sep 2009 11:27:43 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 0D7053A6812; Tue, 15 Sep 2009 11:27:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,391,1249272000"; d="scan'208";a="173448898" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 15 Sep 2009 14:28:29 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Sep 2009 14:28:28 -0400 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, 15 Sep 2009 20:28:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Virtual World Region Agent Protocol (vwrap) thread-index: Aco2MKU7gsGGtRhUSbyE4VqkI95/MAAAZFBQ From: "Romascanu, Dan (Dan)" To: , Subject: [dns-dir] FW: WG Review: Virtual World Region Agent Protocol (vwrap) 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, 15 Sep 2009 18:27:44 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, September 15, 2009 9:15 PM To: new-work@ietf.org Subject: WG Review: Virtual World Region Agent Protocol (vwrap)=20 A new IETF working group has been proposed in the Applications 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, September 22, 2009 Virtual World Region Agent Protocol (vwrap) ---------------------------------------------------------- Current Status: Proposed Working Group Last Modified: 2009-09-03 Chairs: TBD Area and Area Directors: Applications Area Lisa Dusseault Alexey Melnikov Responsible Area Director: TBD Mailing List: ogpx@ietf.org http://www.ietf.org/mailman/listinfo/ogpx Description of Working Group: The working group will define the Virtual World Region Agent Protocol (VWRAP) for a collaborative 3-dimensional virtual environment. The protocol permits users to interact as digital representations called "avatars". An avatar exists in at most one location within a shared virtual space. Conforming client applications use the protocol to manipulate and move the user's avatar, create virtual objects, interact with other users and their surroundings, consume and create media and information from sources inside and outside their simulated environment. A virtual space can be partitioned into "regions" to facilitate the computational and communication load balancing required to simulate the virtual environment. A region provides the service environment in which inhabitants and objects can interact. A region uniquely represents a partition of the virtual space; they are not a mechanism for load balancing by having multiple instances of the same space. Different regions may be administered by different organizations. The state of a virtual world is independent of the client applications that access it and may persist between user sessions. Within a VWRAP virtual environment, services may be deployed by multiple organizations having varying policies and trust domains. The VWRAP protocol will provide the mechanisms for these services to interoperate, when permitted by policy. The working group may document examples of policies applicable to a VWRAP environment. Foundational components of the protocol include the publication of: * an abstract type system, suitable for describing the application protocol in an implementation neutral manner, * a security model describing trust relationships between participating entities, * guidelines for the use of existing authentication and confidentiality mechanisms, * an application-layer protocol for establishing the user's avatar in a region, * an application-layer protocol for changing an avatar's position, including moving between regions, * format descriptions for objects and avatars, and * an application-layer protocol for identifying entities, and requesting information about them. The protocol defined by this group will carry information about the virtual environment, its contents and its inhabitants. It is an application layer protocol, independent of transport, based partially on these previously published internet drafts: * http://tools.ietf.org/html/draft-hamrick-ogp-intro * http://tools.ietf.org/html/draft-hamrick-llsd * http://tools.ietf.org/html/draft-hamrick-ogp-auth * http://tools.ietf.org/html/draft-hamrick-ogp-launch * http://tools.ietf.org/html/draft-lentczner-ogp-base * http://tools.ietf.org/html/draft-levine-ogp-clientcap * http://tools.ietf.org/html/draft-levine-ogp-layering The protocol should describe interaction semantics independent of transport, leveraging existing standards where practical. It should define interoperability expectations for server to server interactions as well as client-server interactions. Though the protocol is independent of transport, early interoperability trials used HTTP(S) for non-real-time messages. The working group will define specific features that must be replicated in other transports and will define the use of HTTP(S) as a transport of protocol messages. Goals and Milestones: * February 2010 "Introduction and Goals" to the IESG as an Informational RFC * February 2010 "Abstract Type System for the Transmission of Dynamic Structured Data" to the IESG as Proposed Standard * June 2010 "Foundational Concepts and Transport Expectations" to the IESG as Proposed Standard * June 2010 "Client Application Launch Message" to the IESG as an Informational RFC * October 2010 "Trust Model and User Authentication" to the IESG as Proposed Standard * October 2010 "Voice and Text Communication Channel Establishment" to the IESG as Proposed Standard * February 2011 "Agent Presence Establishment" to the IESG as Proposed Standard * February 2011 "Region Description Format" to the IESG as Proposed Standard * June 2011 "Digital Asset Access" to the IESG as Proposed Standard * June 2011 "Primitive Object Format" to the IESG as Proposed Standard * October 2011 "Avatar Format" to the IESG as Proposed Standard * October 2011 "Entity Identifiers" to the IESG as Proposed Standard * February 2012 "Time Sensitive Messages" to the IESG as Proposed Standard From dromasca@avaya.com Tue Sep 15 11:27:45 2009 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 5A94F3A6812; Tue, 15 Sep 2009 11:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 WKg3jGUlg6ex; Tue, 15 Sep 2009 11:27:44 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 8EDB43A679F; Tue, 15 Sep 2009 11:27:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,391,1249272000"; d="scan'208";a="173448901" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 15 Sep 2009 14:28:29 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Sep 2009 14:28:29 -0400 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, 15 Sep 2009 20:28:24 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Network Endpoint Assessment (nea) thread-index: Aco2LpgSKBPWUx0uQu28bH95F1+CDgAA7HOw From: "Romascanu, Dan (Dan)" To: , , Subject: [dns-dir] FW: WG Review: Recharter of Network Endpoint Assessment (nea) 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, 15 Sep 2009 18:27:45 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, September 15, 2009 9:00 PM To: new-work@ietf.org Subject: WG Review: Recharter of Network Endpoint Assessment (nea)=20 A modified charter has been submitted for the Network Endpoint Assessment (nea) 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, September 22, 2009. Network Endpoint Assessment (nea) ------------------------------------------------------------ Last Modified: 2009-08-24 Additional information is available at tools.ietf.org/wg/nea Chair(s): * Stephen Hanna (shanna@juniper.net) * Susan Thomson (sethomso@cisco.com) Security Area Director(s): * Tim Polk (tim.polk@nist.gov) * Pasi Eronen (pasi.eronen@nokia.com) Security Area Advisor: * Tim Polk (tim.polk@nist.gov) Mailing Lists: General Discussion: nea@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/nea Archive: http://www.ietf.org/mail-archive/web/nea Description of Working Group: Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring compliance to an organization's posture policy and optionally restricting access until the endpoint has been updated to satisfy the posture requirements. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. Note that an endpoint that is deemed compliant may still be vulnerable to threats that may exist on the network. The network may thus continue to be exposed to such threats as well as the range of other threats not addressed by maintaining endpoint compliance. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge that software installed to protect the machine (e.g. patch management software, anti-virus software, host firewall software, host intrusion protection software or any custom software) is enabled and up-to-date. An endpoint supporting NEA protocols can be queried for posture information. An organization may make a range of policy decisions based on the posture of an endpoint. NEA is not intended to be prescriptive in this regard. Supported deployment scenarios will include, but are not limited to, providing normal access regardless of compliance result along with any recommendations for remediation ("advisory mode"), as well as providing restricted access sufficient for remediation purposes and any essential services until an endpoint is in compliance ("mandatory mode"). Specifying mechanisms for providing restricted access is outside the scope of the NEA WG. Since NEA involves many different components from different vendors, interoperability is important. The NEA working group will develop standard protocols at the following three layers in the architecture: the Posture Attribute protocol (PA), the Posture Broker protocol (PB), and the Posture Transport protocol (PT). PA and PB will be designed to support a variety of PT protocols. Together, PA, PB and the mandatory to implement PT protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another. Since there are already several non-standard protocols at these layers, the NEA working group will consider these existing protocols as candidates for the standard protocols. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed. The NEA Requirements document will include a problem statement, definition of terms, requirements for the PA and PB protocols, and an overall security analysis. It will also include generic requirements for the protocol transporting PA, PB: the Posture Transport protocol (PT). The PA (Posture Attribute) protocol consists of posture attributes that are carried between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. A base set of standard posture attributes will be specified that are expected to address many common posture policies. Vendor-specific attributes will also be supported; vendor-specific attributes will be identified by a private enterprise number and a vendor assigned value. Vendors are strongly encouraged to document vendor-specific attributes in an RFC. The NEA WG will investigate the use of a standard syntax for all attributes. The PB (Posture Broker) protocol aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. The PT (Posture Transport) protocol carries the PB protocol. The expectation is that the PT protocol is a shim protocol that defines an encapsulation of PB within an existing standard transport protocol.=20 Existing standard transport protocols will be leveraged to the extent possible. The NEA WG may specify more than one PT to meet the requirements of different deployment scenarios. The NEA WG will specify at least one mandatory to implement PT protocol. PT protocol specifications must describe any limitations that they impose on PB and PA (e.g. half duplex). One commonly discussed issue with NEA systems is how to handle compromised endpoints, whose reports of their own posture may not be accurate. Detecting or handling such endpoints is out of scope of the NEA WG. Work on PA will focus on attributes useful for assessing posture of those endpoints reporting accurate information. However, the protocols developed by the NEA WG must be designed to accommodate emerging technologies for identifying and dealing with lying endpoints. Note that NEA is not chartered to develop standard protocols for remediation. NEA is intended to be used with new or existing tools that can be used in the absence of NEA. NEA is applicable to computing enterprise environments, where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. NEA applicability and security considerations will be described in the appropriate NEA documents. Further work in the NEA WG will be considered via the rechartering process after the completion of these milestones. Milestones Done At IETF 67, discuss issues with NEA Requirements I-D Done Submit first draft of NEA Requirements I-D Done At IETF 68, resolve any open issues with requirements I-D Done Submit revised NEA requirements I-D Done Discuss NEA Requirements I-D Done Submit revised NEA requirements I-D Done WGLC on NEA requirements I-D Done At IETF 69, resolve any remaining issues raised at Last Call Done Submit revised NEA requirements I-D Done Submit NEA Requirements I-D to the IESG for IETF Last Call as=20 Informational RFC Done Submit revised NEA requirements I-D Done Proposals for PA and PB due Done Review and resolve proposals at IETF 71 Done Post first WG version of PA and PB Done Post second version of PA and PB Done Resolve issues at IETF 72 Done Post third version of PA and PB Done WGLC on PA and PB Done Resolve WGLC comments at IETF 73 Done Post fourth version of PA and PB Done IETF LC for PA and PB Done IESG considers PA and PB for Proposed Standard Sep 2009 Call for proposals for the PT protocol(s) Oct 2009 Proposals due Nov 2009 Review PT protocol proposals at IETF 76 Decide how to resolve differences and issues Dec 2009 Post first WG version of PT protocol(s) Jan 2010 Review and resolve issues Feb 2010 Post second WG version of PT protocol(s) Mar 2010 WG Last Call on PT protocol(s) Resolve issues from WG Last Call at IETF 77 Apr 2010 Post third WG version of PT protocol(s) May 2010 Submit PT protocol(s) to IESG From dromasca@avaya.com Tue Sep 15 11:28:27 2009 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 9035D3A6B27; Tue, 15 Sep 2009 11:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 ImQ79Sg9Viga; Tue, 15 Sep 2009 11:28:26 -0700 (PDT) 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 D53E23A6A37; Tue, 15 Sep 2009 11:28:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,391,1249272000"; d="scan'208";a="156885102" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Sep 2009 14:29:10 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 15 Sep 2009 14:29:09 -0400 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, 15 Sep 2009 20:28:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of IP Flow Information Export (ipfix) thread-index: Aco2LpgZXwm0bKCSSPulAdlsoChN6QAA7+WQ From: "Romascanu, Dan (Dan)" To: , Subject: [dns-dir] FW: WG Review: Recharter of IP Flow Information Export (ipfix) 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, 15 Sep 2009 18:28:27 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, September 15, 2009 9:00 PM To: new-work@ietf.org Subject: WG Review: Recharter of IP Flow Information Export (ipfix)=20 A modified charter has been submitted for the IP Flow Information Export (ipfix) 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, September 22, 2009 IP Flow Information Export (ipfix) -------------------------------------------- Current Status: Active Working Group Last Modified: 2009-09-01 Chair(s): * Nevil Brownlee (n.brownlee@auckland.ac.nz) * Juergen Quittek (quittek@netlab.nec.de) Operations and Management Area Director(s): * Dan Romascanu (dromasca@avaya.com) * Ronald Bonica (rbonica@juniper.net) Operations and Management Area Advisor: * Dan Romascanu (dromasca@avaya.com) Mailing Lists: General Discussion: ipfix@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/ipfix Archive: http://www.ietf.org/mail-archive/web/ipfix Description of Working Group: The IPFIX working group has specified the Information Model (to describe IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX exporters to collectors). Several implementers have already built applications using the IPFIX protocol. As a result of a series of IPFIX interoperability testing events the WG has produced guidelines for IPFIX implementation and testing as well as recommendations for handling special cases such as bidirectional flow reporting and reducing redundancy in flow records. Practical experiences with IPFIX implementations exposed new requirements for the IPFIX protocol that so far have not been addressed by the WG. The major current goal of the WG is developing solutions that meet the new requirements without modifying the core IPFIX protocol specifications. 1. The IPFIX WG has developed a MIB module for monitoring IPFIX implementations. Means for configuring these devices have not been standardized yet. The WG will develop an XML-based configuration data model that can be used for configuring IPFIX devices and for storing, modifying and managing IPFIX configurations parameter sets. This work will be performed in close collaboration with the NETCONF WG. 2. First applications of IPFIX at large operator networks showed the need for mediation of flow information, for example, for aggregating huge amounts of flow data and for anomymization of flow information. The IPFIX WG will investigate this issue and produce a problem Statement and a framework for IPFIX flow mediation. 3. The PSAMP WG has developed a protocol for reporting observed packets. The PSAMP protocol is an extension of the IPFIX protocol. The IPFIX WG will develop a MIB module for monitoring PSAMP implementations. The new MIB module will be an extension of the IPFIX MIB module. 4. Anonymization of flow information has been identified as a requirement for flow information export already in RFC 3917. However, technologies for flow anonymization are still a research issue and have so far not been considered to be mature enough for standardization. As one step in this direction, the IPFIX WG will develop guidelines for the implementation of anonymized data export and storage over IPFIX and define an information model for configuring and reporting anonymization applied at IPFIX devices. 5. The IPFIX and PSAMP WGs have defined standards for selecting observed IP packets and collecting information in flow records. In order to reduce the amount of data to be processed, packet selection methods have been defined. Another method for reducing flow data is flow selection. The IPFIX WG will define methods for flow selection and provide an information model for configuring and reporting flow selection applied at IPFIX devices. 6. Being designed for the export of flow records the IPFIX protocol provides very limited means for structuring information elements within IPFIX records. With the increasing number of IPFIX applications there is a need for exporting more complex information. The IPFIX WG will develop an extension of the IPFIX protocol that supports hierarchically structured data and lists (sequences) of Information Elements in data records. Goals and Milestones: Oct 2009 Submit Mediation Problem Statement I-D to IESG for publication as Informational RFC Oct 2009 Submit initial draft on anonymization support Oct 2009 Submit initial draft on flow selection Oct 2009 Submit initial draft on structuring information elements Jan 2010 Submit Configuration Data Model draft to IESG for publication as Standards track RFC Jan 2010 Submit Mediation Framework I-D to IESG for publication as Informational RFC Jan 2010 Submit final version of PSAMP MIB module Jun 2010 Submit anonymization support I-D to IESG for publication as Experimental RFC Jun 2010 Submit flow selection I-D to IESG for publication as Standards Track RFC Jun 2010 Submit structuring information elements I-D to IESG for publication as Standards Track RFC From dromasca@avaya.com Thu Sep 17 01:38:38 2009 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 EC9653A67E3; Thu, 17 Sep 2009 01:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Frjxq+VyaOWV; Thu, 17 Sep 2009 01:38:38 -0700 (PDT) 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 AC59928C12F; Thu, 17 Sep 2009 01:38:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,402,1249272000"; d="scan'208";a="183607540" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Sep 2009 04:39:28 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Sep 2009 04:39:27 -0400 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: Thu, 17 Sep 2009 10:39:04 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom 2009-10: FINAL Call for Nominations, Local Office hours, Nominee Questionnaires thread-index: Aco3RBVohLPLHLLKTMmfTZpXjGQXMAALh7lA From: "Romascanu, Dan (Dan)" To: , , "MIB Doctors (E-mail)" , , Subject: [dns-dir] FW: Nomcom 2009-10: FINAL Call for Nominations, Local Office hours, Nominee Questionnaires 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, 17 Sep 2009 08:38:39 -0000 =20 -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, September 17, 2009 6:07 AM To: IETF Announcement list Cc: ietf@ietf.org Subject: Nomcom 2009-10: FINAL Call for Nominations, Local Office hours, Nominee Questionnaires=20 Hi all, This is the Final Call for Nominations - the nominations period ends in two days on Sept 18, 2009. =20 We do not have a sufficient number of nominations for the following AD positions: APP, OPS, RAI and SEC In addition, we have not received responses from almost half of the nominees. I will be sending reminders for all the outstanding nominations. =20 We need Community input and participation!!! We cannot properly execute the task of selecting the best candidates for these positions with so few accepted nominations. So, please consider making nominations for the open positions, in particular those for which we have so few nominations - it takes just a few minutes of your time. Right now, we just need the names/email addresses - we'll be soliciting feedback later.=20 Also, please note that although draft-dawkins-nomcom-openlist-06 has been approved, the 2009-10 Nomcom is NOT operating under these new guidelines. As well as the reminder for the call for nominations, this email also serves as a reminder for: 2) Local Office Hours through Sept. 25, 2009.=20 3) Questionnaires due from Nominees on Sept. 25, 2009. Best Regards, Mary Barnes nomcom-chair@ietf.org mary.h.barnes@gmail.com mary.barnes@nortel.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D 1) Call for Nominations ------------------------ The nomination period ends in less than 2 days on Sept. 18th, 2009. We appreciate the folks that have taken the time to make nominations thus far. But, we do need more nominations. Please use the online tool to nominate - it's fast, easy and secure: https://wiki.tools.ietf.org/group/nomcom/09/nominate Details on the open positions, as well as other details and options for making nominations are available on the Nomcom homepage: https://wiki.tools.ietf.org/group/nomcom/09/ You will have the opportunity to provide additional feedback later and it's important to consider that not all nominees will be able to accept the nomination.=20 2) Local office hours ----------------------- In order facilitate additional feedback, the Nomcom has decided to make themselves available for office areas at various geographic locations from September 8th through Sept. 25th.=20 Below please find the list of locations where Nomcom members will be available for these f2f meetings . Unless dates are identified below, the Nomcom member is generally available for part of the day during the weeks of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than English in which the Nomcom member is fluent are identfied. =20 Please contact a Nomcom member in a specific geographic location to arrange a convenient meeting time and place. Most Nomcom members are flexible as to meeting locations - i.e., we can travel to your office, meet at our offices or somewhere in between. =20 As a reminder folks can always contact any Nomcom member to provide feedback at anytime - i.e., you don't need to participate in these f2f sessions to provide feedback.=20 Belgium:=20 Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 21-25) (Languages: French)=20 Boston, Mass, USA: =20 Stephen Kent - kent@bbn.com (Sept 16-18)=20 Boulder, CO, USA:=20 Wassim Haddad - wmhaddad@gmail.com (Sept 14-18) Dallas/Ft. Worth, TX, USA: =20 Mary Barnes - mary.h.barnes@gmail.com=20 Lucy Yong - lucyyong@huawei.com (Languages: Chinese)=20 Helsinki, Finland:=20 Simo Veikkolainen - simo.veikkolainen@nokia.com (Languages: Finnish) =20 Ithaca, NY, USA:=20 Scott Brim - scott.brim@gmail.com Montevideo, Uruguay:=20 Roque Gagliano - roque@lacnic.net (Sept 14-18, 21-25) (Languages: Spanish, Portuguese)=20 Montreal, Quebec, Canada=20 Wassim Haddad - wmhaddad@gmail.com (Sept 8-11) -- Can also be available in Ottawa if folks are interested=20 Paris, France:=20 Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 15-18) (Languages: French) San Diego, CA, USA:=20 Randall Gellens - rg+ietf@qualcomm.com =20 Dave Crocker - dcrocker@bbiw.net (Sept 16-18) Silicon Valley/SF Bay, CA, USA:=20 Dave Crocker - dcrocker@bbiw.net (Sept 8-11, Sept 14-15, Sept 21-25) =20 Dorothy Gellert - Dorothy.gellert@gmail.com 3) Questionnaires available for nominees:=20 For folks that have been notified that they have been nominated for any of the positions, the questionnaires are available on the Nomcom09 tools website: https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire The questionnaires are due no later than Sept. 25th, 2009. If you have any questions or concerns with meeting the deadline, please let me know. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From dromasca@avaya.com Fri Sep 18 01:29:42 2009 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 F0CC63A67A6; Fri, 18 Sep 2009 01:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 wLDjXpJ6jq8q; Fri, 18 Sep 2009 01:29:41 -0700 (PDT) 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 B0C163A6839; Fri, 18 Sep 2009 01:29:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,408,1249272000"; d="scan'208";a="183750642" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Sep 2009 04:30:34 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Sep 2009 04:30:34 -0400 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, 18 Sep 2009 10:30:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for September 24, 2009 Telechat thread-index: Aco35edZ6VsRglumS6Oh+LfzONcXcwAU/Ckw From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for September 24, 2009 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, 18 Sep 2009 08:29:43 -0000 Please find below the preliminary agenda of the 9/24 IESG telechat. Please let me know if there are any comments, questions or concerns before 9/23 COB.=20 Thanks and Regards, Dan ............................... 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-calsify-2446bis-09.txt iCalendar Transport-Independent Interoperability Protocol (iTIP) (Proposed=20 Standard) - 1 of 6=20 Token: Lisa Dusseault o draft-ietf-dnsext-dnssec-rsasha256-14.txt Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for=20 DNSSEC (Proposed Standard) - 2 of 6=20 Note: Andrew Sullivan (ajs@shinkuro.com) is the document shepherd.=20 Token: Ralph Droms o draft-ietf-tls-extractor-07.txt Keying Material Exporters for Transport Layer Security (TLS) (Proposed =20 Standard) - 3 of 6=20 Token: Pasi Eronen o draft-ietf-dime-pmip6-03.txt Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor=20 Interaction with Diameter Server (Proposed Standard) - 4 of 6=20 Token: Dan Romascanu o draft-ietf-pkix-ta-format-03.txt Trust Anchor Format (Proposed Standard) - 5 of 6=20 Token: Tim Polk o draft-ietf-pmol-sip-perf-metrics-04.txt SIP End-to-End Performance Metrics (Proposed Standard) - 6 of 6=20 Note: Vijay Gurbani is the PROTO-shepherd=20 Token: Dan Romascanu 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-peterson-rai-rfc3427bis-03.txt Change Process for the Session Initiation Protocol (SIP) (Proposed=20 Standard) - 1 of 1=20 Token: Russ Housley 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-simple-interdomain-scaling-analysis-08.txt Presence Interdomain Scaling Analysis for SIP/SIMPLE (Informational) - 1 of=20 4=20 Note: Ben Campbell is document shepherd=20 Token: Robert Sparks o draft-ietf-roll-building-routing-reqs-07.txt Building Automation Routing Requirements in Low Power and Lossy Networks=20 (Informational) - 2 of 4=20 Note: JP Vasseur (jvasseur@cisco.com) is the document shepherd=20 Token: Adrian Farrel o draft-ietf-opsawg-operations-and-management-09.txt Guidelines for Considering Operations and Management of New Protocols and=20 Protocol Extensions (Informational) - 3 of 4=20 Token: Dan Romascanu o draft-ietf-pkix-other-certs-05.txt Other Certificates Extension (Experimental) - 4 of 4=20 Token: Tim Polk 3.1.2 Returning Item o draft-ietf-sipcore-presence-scaling-requirements-02.txt Scaling Requirements for Presence in SIP/SIMPLE (Informational) - 1 of 1=20 Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document=20 shepherd.=20 Token: Robert Sparks 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-seokung-msec-mikey-seed-03.txt Addition of the new values to use the SEED Cipher Algorithm in the=20 Multimedia Internet KEYing (MIKEY) (Informational) - 1 of 3=20 Note: Brian Weis (bew@cisco.com) is the document shepherd.=20 Token: Tim Polk o draft-harkins-emu-eap-pwd-06.txt EAP Authentication Using Only A Password (Informational) - 2 of 3=20 Token: Russ Housley o draft-solinas-rfc4753bis-00.txt ECP Groups for IKE and IKEv2 (Informational) - 3 of 3=20 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 NONE 3.3.2 Returning Item NONE 3.3.3 For Action o draft-templin-ranger-07.txt Routing and Addressing in Next-Generation EnteRprises (RANGER)=20 (Informational) - 1 of 3=20 Token: Jari Arkko o draft-levy-sip-diversion-10.txt Diversion Indication in SIP (Historic) - 2 of 3=20 Token: Robert Sparks o draft-irtf-mobopts-mmcastv6-ps-08.txt Multicast Mobility in MIPv6: Problem Statement and Brief Survey=20 (Informational) - 3 of 3=20 Note: Rajeev Koodli (rajeev.koodli@gmail.com) is the document shepherd.=20 Token: Russ Housley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Multipath TCP (mptcp) - 1 of 1 Token: Magnus Westerlund 4.1.2 Proposed for Approval o Virtual World Region Agent Protocol (vwrap) - 1 of 1 Token: Alexey Melnikov 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o Behavior Engineering for Hindrance Avoidance (behave) - 1 of 2 Token: Magnus Westerlund o Access Node Control Protocol (ancp) - 2 of 2 Token: Ralph Droms 4.2.2 Proposed for Approval o IP Flow Information Export (ipfix) - 1 of 2 Token: Dan Romascanu o Network Endpoint Assessment (nea) - 2 of 2 Token: Tim Polk From ogud@ogud.com Fri Sep 18 11:29:09 2009 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 7E3BA3A68BE for ; Fri, 18 Sep 2009 11:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.396, 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 Q2NM2mwl+msU for ; Fri, 18 Sep 2009 11:29:08 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 9EB413A68A9 for ; Fri, 18 Sep 2009 11:29:08 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n8IIU1Jg041822 for ; Fri, 18 Sep 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Fri, 18 Sep 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090918_183001_031946.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-yourtchenko-tran-announce-dns-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, 18 Sep 2009 18:29:09 -0000 Count: 22 Network Working Group A. Yourtchenko Internet-Draft D. Wing Intended status: Standards Track cisco Expires: March 22, 2010 September 18, 2009 A la carte: Announcing the supported transport protocols via DNS draft-yourtchenko-tran-announce-dns-00 Abstract While TCP has enjoyed many enhancements over the decades, it is useful to allow applications to use transports beyond just UDP and TCP and to use TCP in new ways. It is inefficient to naively probe the server using the new protocol. This document proposes a new DNS resource record which provides an efficient way to query which protocols are supported by a server. From ogud@ogud.com Sat Sep 19 11:29:18 2009 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 550CE3A6819 for ; Sat, 19 Sep 2009 11:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.384, 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 TNjh4rXVzkOQ for ; Sat, 19 Sep 2009 11:29:17 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 7F5E828C105 for ; Sat, 19 Sep 2009 11:29:06 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n8JIU1ME008456 for ; Sat, 19 Sep 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Sat, 19 Sep 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090919_183001_093370.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-baker-ietf-core-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: Sat, 19 Sep 2009 18:29:18 -0000 Count: 14 Network Working Group F. Baker Internet-Draft Cisco Systems Intended status: Informational September 18, 2009 Expires: March 22, 2010 Core Protocols in the Internet Protocol Suite draft-baker-ietf-core-01 Abstract This note attempts to identify the core of the Internet Protocol Suite. The target audience is NIST, in the Smart Grid discussion, as they have requested guidance on how to profile the Internet Protocol Suite. In general, that would mean selecting what they need from the picture presented here. From ogud@ogud.com Sun Sep 20 19:11:50 2009 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 426E23A688B for ; Sun, 20 Sep 2009 19:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.482 X-Spam-Level: X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7p51nJtVqHdv for ; Sun, 20 Sep 2009 19:11:49 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id A4DDD3A68C1 for ; Sun, 20 Sep 2009 19:11:47 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n8L2CclH018174; Sun, 20 Sep 2009 22:12:44 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200909210212.n8L2CclH018174@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 20 Sep 2009 22:12:18 -0400 To: "Romascanu, Dan (Dan)" , From: Olafur Gudmundsson In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for September 24, 2009 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: Mon, 21 Sep 2009 02:11:50 -0000 At 04:30 18/09/2009, Romascanu, Dan (Dan) wrote: >2.1 WG Submissions >2.1.1 New Item > o draft-ietf-calsify-2446bis-09.txt > iCalendar Transport-Independent Interoperability Protocol (iTIP) >(Proposed > Standard) - 1 of 6 > Token: Lisa Dusseault This one is in the DNS early waning but it is a false positive, they have the string srv in a domain name in their examples. > o draft-ietf-dnsext-dnssec-rsasha256-14.txt > Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource >Records >for > DNSSEC (Proposed Standard) - 2 of 6 > Note: Andrew Sullivan (ajs@shinkuro.com) is the document shepherd. > Token: Ralph Droms This one is product of dnsext and is in the EW db. Nothing else is showing up. Olafur From ogud@ogud.com Mon Sep 21 11:29:01 2009 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 8A4BE3A685B for ; Mon, 21 Sep 2009 11:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 yewJQvoio6zs for ; Mon, 21 Sep 2009 11:29:00 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 9AED83A6822 for ; Mon, 21 Sep 2009 11:29:00 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n8LIU0Jo024623 for ; Mon, 21 Sep 2009 14:30:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Mon, 21 Sep 2009 14:30:00 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090921_183000_098609.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-barwood-dnsext-dns-transport-signal-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, 21 Sep 2009 18:29:01 -0000 Count: 13 DNS Extensions Working Group G. Barwood Internet-Draft Intended status: Standards Track 20 September 2009 Expires: March 2010 DNS Transport Signal draft-barwood-dnsext-dns-transport-signal-00 Abstract Describes a DNS resource record that is used to signal support for DNS transport protocols. From ogud@ogud.com Wed Sep 23 11:28:59 2009 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 660273A68CE for ; Wed, 23 Sep 2009 11:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.391, 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 Cd2xDNKVfgSm for ; Wed, 23 Sep 2009 11:28:58 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 928EB3A67AD for ; Wed, 23 Sep 2009 11:28:58 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n8NIU1Xw045751 for ; Wed, 23 Sep 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Wed, 23 Sep 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090923_183001_025878.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-dnsext-dnssec-alg-allocation-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, 23 Sep 2009 18:28:59 -0000 Count: 21 Network Working Group P. Hoffman Internet-Draft VPN Consortium Updates: 2535, 3755, 4034 September 22, 2009 (if approved) Intended status: Standards Track Expires: March 26, 2010 Cryptographic Algorithm Identifier Allocation for DNSSEC draft-ietf-dnsext-dnssec-alg-allocation-00 Abstract This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the rule from "standard required" to "RFC required". It does not change the list of algorithms that are recommended or required for DNSSEC implementations. From olaf@nlnetlabs.nl Thu Sep 24 02:15:52 2009 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 537B93A67B4 for ; Thu, 24 Sep 2009 02:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, NO_RELAYS=-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 qdNpzSFk7Tpe for ; Thu, 24 Sep 2009 02:15:50 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 21E4C3A6824 for ; Thu, 24 Sep 2009 02:15:49 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:21b:63ff:feb8:a9eb] ([IPv6:2001:7b8:206:1:21b:63ff:feb8:a9eb]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n8O9Gkk6052367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 24 Sep 2009 11:16:46 +0200 (CEST) (envelope-from olaf@nlnetlabs.nl) From: Olaf Kolkman Content-Type: multipart/signed; boundary=Apple-Mail-12-598699733; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 24 Sep 2009 11:16:46 +0200 Message-Id: To: IETF DNS Directorate Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 24 Sep 2009 11:16:46 +0200 (CEST) Subject: [dns-dir] FYI: net4d X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "iab@iab.org IAB" , Bill Graham , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 09:15:52 -0000 --Apple-Mail-12-598699733 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes DNS Folk, I've just mailed this to the IAB, I think it is relevant for the =20 directorate as well. I've set the reply field to include the IAB and =20 others. ----- Over the last month several folk made me aware of a propsal from Dr. =20 Frcancis Muget. A recent mail from Austrian colleagues is the first =20 blob below, and gives the context. When I was first approached by Desiree Milosovich I've answered her =20 with "Some personal views and the question, Should we really spend =20 time on this". When Bill Graham approached me and Patrik I forwarded =20 the initial mail I send to Desiree and Bill and Patrik improved the =20 text to be more of a 'briefing form'. That is replicated in the second =20= blob. Although I don't think we should turn this into an agenda item =20 just yet I think that it would be good to not say to much divergent =20 things when approached. From: Alexander Mayrhofer Subject: IETF and the "net4d" proposal > > We recently (again) stumbled across a topic that *could* have =20 > potential > to pose a threat to the stability of the internet (particularly the =20= > DNS > namespace), hasn't raised much attention in the IETF so far, but has > been pushed in Internet Government etc. circles for a while: > > It's an initiative called "net4d" http://www.net4d.org/index1.html - > primarily driven by Dr Francis Muguet of the University of Geneva. > > His proposal is (in short) to use the DNS *classes* registration > process, rather than extending the namespace of the "IN" class with =20= > new > top level domains, and includes proposals such as creating a dedicated > DNS class for each of the 45 WIPO trademark classes... The proposal =20= > aims > at creating "alternate roots" that are politically independent of =20 > ICANN > (and also the IETF, funny enough - see below). > > An introduction is in the slides here: > http://net4d.org/geneva-may09-slidy.html#%281%29 > > While his proposal is full of technical flaws (and does not mention =20= > that > rolling that out would probably be magnitudes more effort than > introducing both IPv6 and DNSSEC) he mostly speaks in front of > "political" organisations like IGF, ITU WSIS, where he seems to raise > significant attention among the mostly non-technical attendees - =20 > look at > his schedule of speeches on the homepage - IGF, WSIS, multilingual > conferences, ITU... > > Of course it's mostly about "Anti-ICANN", but the proposal also claims > that the IETF shouldn't administrate the DNS class registration =20 > process > besides the "IN" class (argumenting that anything that's not =20 > "Internet" > shouldn't be administrated be the "Internet Engineering Task Force"), > and the class registration process should rather be handed over the =20= > the > ITU/UN (sic!). > > Worst of all, he seems to be contracted by the ITU to do an "expert > mission" on how to "open up competition in the DNS" - giving it a more > serious touch than a simple white paper: > http://www.net4d.org/18sep09-index.html > > I've never seen anybody within the IETF looking into those proposals > yet. Clearly, the proposal is technically flawed (especially how to > access the new namespaces by using class%domain.tld, which obviously > wouldn't work in most protocols) - but if his proposal gains support =20= > on > the political level (and, for whatever reason, those political forces > decide to push it), it *could* have the potential to damage the > stability of the DNS (and therefore an important part of the Internet) > significantly. > > So, my question: Are you aware of anybody in the IETF looking into =20 > those > things, and providing counter-arguments, particularly on the > "non-technical" level? If not, do you think the IETF should look into > this, provide counter-arguments, and/or be present in the circles =20 > where > this proposal is being discussed? > My response as modified by Patrik and Bill: > On Friday Sep 18, the International Telecommunication Union's =20 > Development Sector (ITU-D) is hosting an Expert Workshop" on =20 > "Opening the Namespace infrastructures to Competition". Information =20= > about the workshop can be found on the following webpage: > > http://net4d.org/18sep09-index.html > > Specifically, the workshop is built upon some conceptual work funded =20= > under contract by the ITU. See this webpage for information on the =20= > call for proposals: > > http://net4d.org/itu-expert-jul09.html > > The work was awarded to Dr. Francis Muguet, who is active in the =20 > Net4D project (homepage http://www.net4D.org/). > > The proposal was previously presented at some WSIS process-related =20 > meetings, for example in Geneva in May 2009. On this webpage one can =20= > see pointers to version 1.1 of the paper, plus some slides that =20 > explains the proposal: > > http://net4d.org/net4d-geneva-may09.html > > The core of the proposal implies the introduction of "a new class" =20 > into the domain name system. A "Class" is one of the three =20 > parameters that is used when sending a query to the Domain Name =20 > System. The two others are the domain name and the "type" (that =20 > specifies what kind of data is requested). Today on the Internet, =20 > the class "IN" is the class that is in use, and it is correct to =20 > state that the protocol itself can theoretically handle more than =20 > 65000 classes. > > So far the paper is factually correct, but there are significant =20 > issues not mentioned. > > For example, consider the following points: > > - Using a "Class" is a well known extension mechanism which would =20 > come with some well-understood and documented concerns. See for =20 > example section 3.4 in RFC 5507 (Design Choices When Expanding the =20 > DNS: http://www.rfc-editor.org/rfc/rfc5507.txt). > > - Domain names are used in various places, not only for indicating =20 > where a specific web page or web service can be found (HTTP URI, =20 > often called a "URL"). Apparently the proposal only looked at HTTP =20 > URIs while there are a myriad of other applications that use domain =20= > names or protocols that exchange domain name information. Very =20 > thorough specification and thought are needed to make this work =20 > generically for any protocol (such as telephony, e-mail and text =20 > messaging). > > The proposal on how to select the class a specific domain name is to =20= > be looked up in (i.e., having a prefix) requires changes in the =20 > protocol(s) using domain names as protocol parameters, and if =20 > attempted will require _very_ thorough specification and thought. > > - In practice each new class will establish a new namespace; hence a =20= > new network. See RFC 2826 (IAB Technical Comment on the Unique DNS =20 > Root: http://www.ietf.org/rfc/rfc2826.txt) for considerations =20 > regarding creation of new namespaces. > > The proposal does seem to recognize that a new class introduces new =20= > networks and that conceptually a 'new Internet' is created, however =20= > a new CLASS namespace would still run on the Internet and might not =20= > be completely separable, which might introduce leakage. There are =20 > not only protocol but also operational issues to address. > > - The document/proposal is a bit confusing: is the document =20 > proposing to conduct an experiment or to launch new network(s) into =20= > production? The ICANN recommendations cited are for experiments, not =20= > production. The implications are quite different. > > But those are all technical comments and the proposal lists other =20 > arguments than technical. Specifically the paper says: > > "If IETF were to decide to block classes assignments to stifle =20 > competition, one could legitimately ask why the IETF, whose =20 > governance sphere is limited to the Internet, is entitled to assign =20= > a class to a network other than his own ie: the Internet. Under =20 > international public law, governance and arbitrage between networks =20= > should be the responsibility of an international organization such =20 > as the International Telecommunication Union, a situation that has =20 > been acknowledged by ICANN in its article 4 of incorporation: ICANN =20= > =93shall operate [=85] its activities in conformity with relevant =20 > principles of international law and applicable international =20 > conventions and local law=94 and =93shall corporate as appropriate = with =20 > relevant international organizations.=94 > > This is unfortunately a straw man proposal that might result in =20 > breaking the technical system that underlies the Internet, by just =20 > changing the procedures and policies. > > The IETF review for the assignment is a technical review. The IETF =20= > will not block assignment to stifle competition. It would only block =20= > assignment on the grounds that a technical proposal is not solid. =20 > All interested in the continuing stability and functioning of the =20 > Internet must hope that Dr Muguet will eventually write a =20 > technically solid piece of work that would give him an experimental =20= > code point. Then the participants in the Net4D project would see =20 > that deployment is not so trivial as they claim, and would be able =20 > to discover that in a non-disruptive manner. > > However, This straw man proposal seems to prejudge that if the =20 > technical review fails, it is not the proposal but the process that =20= > is broken, and thus that procedures and policies should change. > > While the IETF has not reviewed this proposal, some people working =20 > with DNS in the IETF do not so far see anything in this proposal =20 > that has not been discussed before -- and rejected for technical =20 > reasons. There might be some new ideas in there somewhere, but a =20 > solid technical proposal is needed before proper technical review =20 > can start. > > The IETF process is open to all. ________________________________________________________ Olaf M. Kolkman NLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam --Apple-Mail-12-598699733 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMTCCBS0w ggMVoAMCAQICAwbqdTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA1MjUwODQ4MTJaFw0x MTA1MjUwODQ4MTJaMDkxFTATBgNVBAMTDE9sYWYgS29sa21hbjEgMB4GCSqGSIb3DQEJARYRb2xh ZkBubG5ldGxhYnMubmwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxtZNngmuLgcf rto+Uax1WhonECqb5W8US2Z+ZPw/ASKsjKEF8Wa3Nnispys6Gj9Sl7C1X0/2pH//qauLpBqA+lHW L9mgdGW1T9KU1Fb8Odqw0PBnIIhbLNQzecZL+BchEetcrubplQWzDOpROCJ00IwXksusBiKqhew4 u7X2QoraW+z32Knj5ogajIhdkAeBHUy1pwXsk/mDnV8cIEdz1MhaZWDSn7kJUQtRMVCpFBjVoiXh ToXMJfiMvn0CKaeFxFm72dcdzvFsw906Ndafd2MOfdP7QSsTVP6sG9am790AOgkzxT5CM77IDPbD zxZlQ8jTdhcp/WtUrFWIU4QBAgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhCAQ0E SRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBodHRw Oi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3 CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZo dHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW9sYWZAbmxuZXRsYWJzLm5sMA0GCSqG SIb3DQEBBQUAA4ICAQCLpawAoUQAxivf6blyMswVokRmDl2JGEbtmEu8j0h1BVOlGh6hlI8WaeWy 3x2jJ9uun3VK6oYnHy45ez+dUDjBLjOZdAgwFg225lm1OPdmisghDDVwCIiEogHPqmJtvKYMFoPF 3iFUambJDoQF8DeVeg8ctDvsxsaVGjA8OrMpo0K4I11vnNbCLv7mWCjnaZWt/6Y6TD8ErHQl5dmI rpsHmEZx1/nsocdPkZGRA4QVf1omYHUNs79DtxpYdGKHoorpBNzlzIIjpceiqeOeykoDeYLTZX2G c7Mh4Gdj2MHFqZucxV1cHibb8XKv8ebaGltMV5SrciqRn8yFXmiyTvmId6myNXLiOx+VJiGbLSS3 TltM/kf7UejXeEHulEKufU6Ya6EfH7W2/spTayYCauyLljOjE2Ey5A4oIoJV9eY64OCDuLF2nmGR jOh3JB9nGkZIPhmTUwGZnMELLhzKz+eOZoulM4tXH6KEubed1shQEq1dkJ+tFtRS3Lm+vLCKWvVo 1iZScqPaQf9riPApAVrL+3Wat0p/jtCk5gLBF02uTiWvT2t4ZfSHMEBXR7CvVm58etRQuyZSMHyz UQC4wkDvCeVawNRCZjq6wWdvx5hmr2JeDSkkRtSZ/Fa1WXf26b3BZugI75p5JXafbWdOTRpNc8M5 YMk7tx29ZG3u0qODgDGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMG6nUwCQYFKw4DAhoFAKCCAYcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTI0MDkxNjQ2WjAj BgkqhkiG9w0BCQQxFgQU/mXduidW112Ig8DPbhsAevZ+gpUwgZEGCSsGAQQBgjcQBDGBgzCBgDB5 MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDBup1MIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBB dXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBup1MA0GCSqGSIb3 DQEBAQUABIIBAGpMnb5yt7vJ5Mz0hEqO9g/SmvNBb7KJuD3WuwFTAaL3x86BkFy0HhyWjK6/cxMM Fh22gSXSnkh5hjU6VVecX5KajuzdjJhEMqcy2CcVqH1fRUUORnvbknS7NGLP3qq9kwF8RVx8ufv/ 7P1dxdgEF57hGZ5o2yFKbpl8kXb2qL/wYDIQ57LXKI/Arq5XbEuW/+bRxoZ/f53C/MsWZqS6D0+V AzdXfyhmjjTyfJp0tCFbs5TAPZzuj9wMwhQgWlxwnwLYOd0T2KFHrm8eIOG3hT9KrmkZkhI/2rFc 2/dUjBHzbIJwTDL5rv0J++Wml9nxjbESXyrX4/mseFyOR2T4kRMAAAAAAAA= --Apple-Mail-12-598699733-- From ogud@ogud.com Thu Sep 24 08:18:51 2009 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 9935D3A68DD; Thu, 24 Sep 2009 08:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, J_CHICKENPOX_31=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 Bx6sK7VN3oUm; Thu, 24 Sep 2009 08:18:50 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 7FDC83A6922; Thu, 24 Sep 2009 08:18:49 -0700 (PDT) Received: from Puki.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n8OEvFOb053632; Thu, 24 Sep 2009 10:57:16 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <200909241457.n8OEvFOb053632@stora.ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 24 Sep 2009 10:36:10 -0400 To: "iab@iab.org IAB" , Bill Graham , IETF DNS Directorate From: Olafur Gudmundsson In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: Re: [dns-dir] FYI: net4d 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, 24 Sep 2009 15:18:51 -0000 Looks look like we need "Why classes are bad" document that includes a clear explanation on "Why class is not sufficient as separator to allow the use of UTF"= . To me this looks like a power-grab/fishing-expedition by the ITU and some other parties. I think Iran would love to restrict Internet traffic to name in IR class :-) Olafur At 05:16 24/09/2009, Olaf Kolkman wrote: >DNS Folk, > >I've just mailed this to the IAB, I think it is relevant for the >directorate as well. I've set the reply field to include the IAB and >others. > >----- > > >Over the last month several folk made me aware of a propsal from Dr. >Frcancis Muget. A recent mail from Austrian colleagues is the first >blob below, and gives the context. > >When I was first approached by Desiree Milosovich I've answered her >with "Some personal views and the question, Should we really spend >time on this". When Bill Graham approached me and Patrik I forwarded >the initial mail I send to Desiree and Bill and Patrik improved the >text to be more of a 'briefing form'. That is replicated in the second >blob. Although I don't think we should turn this into an agenda item >just yet I think that it would be good to not say to much divergent >things when approached. > > From: Alexander Mayrhofer > Subject: IETF and the "net4d" proposal >> >>We recently (again) stumbled across a topic that *could* have >>potential >>to pose a threat to the stability of the internet (particularly the >>DNS >>namespace), hasn't raised much attention in the IETF so far, but has >>been pushed in Internet Government etc. circles for a while: >> >>It's an initiative called "net4d" http://www.net4d.org/index1.html - >>primarily driven by Dr Francis Muguet of the University of Geneva. >> >>His proposal is (in short) to use the DNS *classes* registration >>process, rather than extending the namespace of the "IN" class with >>new >>top level domains, and includes proposals such as creating a dedicated >>DNS class for each of the 45 WIPO trademark classes... The proposal >>aims >>at creating "alternate roots" that are politically independent of >>ICANN >>(and also the IETF, funny enough - see below). >> >>An introduction is in the slides here: >>http://net4d.org/geneva-may09-slidy.html#%281%29 >> >>While his proposal is full of technical flaws (and does not mention >>that >>rolling that out would probably be magnitudes more effort than >>introducing both IPv6 and DNSSEC) he mostly speaks in front of >>"political" organisations like IGF, ITU WSIS, where he seems to raise >>significant attention among the mostly non-technical attendees - >>look at >>his schedule of speeches on the homepage - IGF, WSIS, multilingual >>conferences, ITU... >> >>Of course it's mostly about "Anti-ICANN", but the proposal also claims >>that the IETF shouldn't administrate the DNS class registration >>process >>besides the "IN" class (argumenting that anything that's not >>"Internet" >>shouldn't be administrated be the "Internet Engineering Task Force"), >>and the class registration process should rather be handed over the >>the >>ITU/UN (sic!). >> >>Worst of all, he seems to be contracted by the ITU to do an "expert >>mission" on how to "open up competition in the DNS" - giving it a more >>serious touch than a simple white paper: >>http://www.net4d.org/18sep09-index.html >> >>I've never seen anybody within the IETF looking into those proposals >>yet. Clearly, the proposal is technically flawed (especially how to >>access the new namespaces by using class%domain.tld, which obviously >>wouldn't work in most protocols) - but if his proposal gains support >>on >>the political level (and, for whatever reason, those political forces >>decide to push it), it *could* have the potential to damage the >>stability of the DNS (and therefore an important part of the Internet) >>significantly. >> >>So, my question: Are you aware of anybody in the IETF looking into >>those >>things, and providing counter-arguments, particularly on the >>"non-technical" level? If not, do you think the IETF should look into >>this, provide counter-arguments, and/or be present in the circles >>where >>this proposal is being discussed? > > >My response as modified by Patrik and Bill: > > > >>On Friday Sep 18, the International Telecommunication Union's >>Development Sector (ITU-D) is hosting an Expert Workshop" on >>"Opening the Namespace infrastructures to Competition". Information >>about the workshop can be found on the following webpage: >> >>http://net4d.org/18sep09-index.html >> >>Specifically, the workshop is built upon some conceptual work funded >>under contract by the ITU. See this webpage for information on the >>call for proposals: >> >>http://net4d.org/itu-expert-jul09.html >> >>The work was awarded to Dr. Francis Muguet, who is active in the >>Net4D project (homepage http://www.net4D.org/). >> >>The proposal was previously presented at some WSIS process-related >>meetings, for example in Geneva in May 2009. On this webpage one can >>see pointers to version 1.1 of the paper, plus some slides that >>explains the proposal: >> >>http://net4d.org/net4d-geneva-may09.html >> >>The core of the proposal implies the introduction of "a new class" >>into the domain name system. A "Class" is one of the three >>parameters that is used when sending a query to the Domain Name >>System. The two others are the domain name and the "type" (that >>specifies what kind of data is requested). Today on the Internet, >>the class "IN" is the class that is in use, and it is correct to >>state that the protocol itself can theoretically handle more than >>65000 classes. >> >>So far the paper is factually correct, but there are significant >>issues not mentioned. >> >>For example, consider the following points: >> >>- Using a "Class" is a well known extension mechanism which would >>come with some well-understood and documented concerns. See for >>example section 3.4 in RFC 5507 (Design Choices When Expanding the >>DNS: http://www.rfc-editor.org/rfc/rfc5507.txt). >> >>- Domain names are used in various places, not only for indicating >>where a specific web page or web service can be found (HTTP URI, >>often called a "URL"). Apparently the proposal only looked at HTTP >>URIs while there are a myriad of other applications that use domain >>names or protocols that exchange domain name information. Very >>thorough specification and thought are needed to make this work >>generically for any protocol (such as telephony, e-mail and text >>messaging). >> >>The proposal on how to select the class a specific domain name is to >>be looked up in (i.e., having a prefix) requires changes in the >>protocol(s) using domain names as protocol parameters, and if >>attempted will require _very_ thorough specification and thought. >> >>- In practice each new class will establish a new namespace; hence a >>new network. See RFC 2826 (IAB Technical Comment on the Unique DNS >>Root: http://www.ietf.org/rfc/rfc2826.txt) for considerations >>regarding creation of new namespaces. >> >>The proposal does seem to recognize that a new class introduces new >>networks and that conceptually a 'new Internet' is created, however >>a new CLASS namespace would still run on the Internet and might not >>be completely separable, which might introduce leakage. There are >>not only protocol but also operational issues to address. >> >>- The document/proposal is a bit confusing: is the document >>proposing to conduct an experiment or to launch new network(s) into >>production? The ICANN recommendations cited are for experiments, not >>production. The implications are quite different. >> >>But those are all technical comments and the proposal lists other >>arguments than technical. Specifically the paper says: >> >>"If IETF were to decide to block classes assignments to stifle >>competition, one could legitimately ask why the IETF, whose >>governance sphere is limited to the Internet, is entitled to assign >>a class to a network other than his own ie: the Internet. Under >>international public law, governance and arbitrage between networks >>should be the responsibility of an international organization such >>as the International Telecommunication Union, a situation that has >>been acknowledged by ICANN in its article 4 of incorporation: ICANN >>=93shall operate [=85] its activities in conformity with relevant >>principles of international law and applicable international >>conventions and local law=94 and =93shall corporate as appropriate with >>relevant international organizations.=94 >> >>This is unfortunately a straw man proposal that might result in >>breaking the technical system that underlies the Internet, by just >>changing the procedures and policies. >> >>The IETF review for the assignment is a technical review. The IETF >>will not block assignment to stifle competition. It would only block >>assignment on the grounds that a technical proposal is not solid. >>All interested in the continuing stability and functioning of the >>Internet must hope that Dr Muguet will eventually write a >>technically solid piece of work that would give him an experimental >>code point. Then the participants in the Net4D project would see >>that deployment is not so trivial as they claim, and would be able >>to discover that in a non-disruptive manner. >> >>However, This straw man proposal seems to prejudge that if the >>technical review fails, it is not the proposal but the process that >>is broken, and thus that procedures and policies should change. >> >>While the IETF has not reviewed this proposal, some people working >>with DNS in the IETF do not so far see anything in this proposal >>that has not been discussed before -- and rejected for technical >>reasons. There might be some new ideas in there somewhere, but a >>solid technical proposal is needed before proper technical review >>can start. >> >>The IETF process is open to all. > > > >________________________________________________________ > >Olaf M. Kolkman NLnet Labs > Science Park 140, >http://www.nlnetlabs.nl/ 1098 XG Amsterdam > > > > >_______________________________________________ >dns-dir mailing list >dns-dir@ietf.org >https://www.ietf.org/mailman/listinfo/dns-dir From ogud@ogud.com Thu Sep 24 11:28:54 2009 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 E05223A6845 for ; Thu, 24 Sep 2009 11:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, 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 AE5-wPMuhbsE for ; Thu, 24 Sep 2009 11:28:54 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 0D9E53A68B0 for ; Thu, 24 Sep 2009 11:28:53 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n8OIU0uN055312 for ; Thu, 24 Sep 2009 14:30:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 24 Sep 2009 14:30:00 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090924_183000_050904.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-dnsext-dnssec-gost-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, 24 Sep 2009 18:28:55 -0000 Count: 32 DNS Extensions working group V.Dolmatov, Ed. Internet-Draft Cryptocom Ltd. Intended status: Standards Track September 24, 2009 Expires: March 24, 2010 Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC draft-ietf-dnsext-dnssec-gost-00 Abstract This document describes how to produce GOST signature and hash algorithms DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). From ogud@ogud.com Thu Sep 24 11:48:50 2009 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 302773A68C2 for ; Thu, 24 Sep 2009 11:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, 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 qGL1im06Iy+5 for ; Thu, 24 Sep 2009 11:48:49 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 466EF3A67AF for ; Thu, 24 Sep 2009 11:48:49 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n8OIU0l7055325 for ; Thu, 24 Sep 2009 14:30:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Thu, 24 Sep 2009 14:30:00 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090924_183000_081247.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-ietf-dnsext-rfc3597-bis-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, 24 Sep 2009 18:48:50 -0000 Count: 41 INTERNET-DRAFT A. Gustafsson Araneus Information Systems Oy September 23, 2009 Intended status: Draft Standard Obsoletes: RFC3597 Handling of Unknown DNS Resource Record (RR) Types draft-ietf-dnsext-rfc3597-bis-00.txt Abstract Extending the Domain Name System (DNS) with new Resource Record (RR) types should not requires changes to name server software. This document specifies how new RR types are transparently handled by DNS software. From dromasca@avaya.com Tue Sep 29 09:32:59 2009 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 F0B693A6AF9; Tue, 29 Sep 2009 09:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzGK6zl9Qn17; Tue, 29 Sep 2009 09:32:58 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 392A83A6AF5; Tue, 29 Sep 2009 09:32:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,474,1249272000"; d="scan'208";a="175036969" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 29 Sep 2009 12:34:18 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 29 Sep 2009 12:34:17 -0400 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, 29 Sep 2009 18:33:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) thread-index: AcpBIlaYkEgMSq1dST+bC93f3ZD0hwAADTwQ From: "Romascanu, Dan (Dan)" To: , , "MIB Doctors (E-mail)" , Subject: [dns-dir] FW: WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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, 29 Sep 2009 16:33:00 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, September 29, 2009 6:30 PM To: ietf-announce@ietf.org Cc: behave@ietf.org; dthaler@microsoft.com; dwing@cisco.com Subject: WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave)=20 A modified charter has been submitted for the Behavior Engineering for Hindrance Avoidance (behave) working group in the Transport 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, October 6, 2009. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- Current Status: Active Working Group Last Modified: 2009-09-09 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/behave Chair(s): * Dan Wing * Dave Thaler Transport Area Director(s): * Magnus Westerlund * Lars Eggert Transport Area Advisor: * Magnus Westerlund Mailing Lists: General Discussion: behave@ietf.org To Subscribe: behave-request@ietf.org In Body: In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group: The behavior of NATs varies from one implementation to another. As a result it is very difficult for applications to predict or discover the behavior of these devices. Predicting and/or discovering the behavior of NATs is important for designing application protocols and NAT traversal techniques that work reliably in existing networks. This situation is especially problematic for end-to-end applications where one or both end-points are behind a NAT, such as multiuser games, interactive multimedia and P2P download. The working group documents best current practices to enable NATs to function in as deterministic a fashion as possible. The NAT behavior practices will be application independent. This has already completed for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any additional protocol deemed necessary to handle. The WG has documented approaches for characterizing and testing NAT devices. BEHAVE will develop protocol-independent toolkits usable by application protocols for NAT traversal. The WG has already produced an update of the binding discovery protocol STUN. It will now produce a relay protocol that focuses on security and is usable with both IPv4 and IPv6, and capable of relaying between the two IP versions. Due to the WG's experience with translators and their behavior it has been given the following tasks to help encourage migration to IPv6. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. The BEHAVE WG will design solutions for the following six translation scenarios; other scenarios are out of scope: 1. An IPv6 network to IPv4 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv6 network of arbitary size. Port translation is necessary on the IPv4 side for efficient IPv4 address usage. 2. IPv6 Internet to an IPv4 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv4 network using either private or public IPv4 addresses. This scenario has different constraints compared to (1), e.g. the IPv4 hosts that are to be reachable over IPv6 can be enumerated. Therefore, the WG should attempt to design a simpler solution with less impact on applications. 3. An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. 4. IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. 5. An IPv6 network to an IPv4 network, i.e., perform translation between IPv6 and IPv4 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). 6. An IPv4 network to an IPv6 network, i.e., perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The parts of ICMP that can be translated are also required to work across a translation solution. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation. The translators should support multicast traffic and its control traffic (IGMP and MLD) across them, both Single Source Multicast (SSM) and Any Source Multicast (ASM). However, the WG may determine that it becomes too complex or too difficult to realize with maintained functionality, for some or all cases of multicast functionality. Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications. DNS is a crucial part in making a large number of applications work across a translator. Thus the solution to the above translation cases shall include recommendations for DNS. If additional DNS functionality is needed, it may be developed. Any DNS extensions must be developed together with the DNSEXT WG, including issuing a joint WG last call for any documents. The WG needs to determine the best method for providing address space to a translator in the different deployment cases and documenting the pros and cons of the suggested approaches. The WG is to seek input from the Routing, Operations and Internet areas. Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution. Goals and Milestones: Done Submit BCP that defines unicast UDP behavioral requirements=20 for NATs to IESG Done Submit a BCP that defines TCP behavioral requireents for NATs=20 to IESG Done Submit a BCP that defines ICMP behavioral requirements for=20 NATs to IESG Done Submit informational that discusses current NAT traversal=20 techniques used by applications Done Submit BCP that defines multicast UDP Done Submit revision of RFC 3489 to IESG behavioral requirements for=20 NATs to IESG Done Submit informational document for rfc3489bis test vectors Done Submit experimental document that describes how an application can determine the type of NAT it is behind Done Submit BCP document for DCCP NAT behavior Dec 2009 Submit to IESG: SCTP NAT behavior (BCP) Done Submit to IESG: relay protocol (std) Done Determine relative prioritization of the four translation=20 cases. Documented in IETF74 minutes. Sep 2009 Submit to IESG: relaying of a TCP bytestream (std) Dec 2009 Submit to IESG: IPv6 relay protocol (std) Done Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components. Documented in IETF74 minutes. Done Submit to IESG: TURN-URI document (std) Dec 2009 Submit to IESG: framework for IPv6/IPv4 translation (info) Dec 2009 Submit to IESG: stateless IPv6/IPv4 translation (std) Dec 2009 Submit to IESG: stateful IPv6/IPv4 translation (std) Dec 2009 Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) Jan 2010 Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) Jan 2010 Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) Mar 2010 Submit to IESG: large scale NAT requirements (BCP) From dromasca@avaya.com Tue Sep 29 09:47:02 2009 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 4724128C18C; Tue, 29 Sep 2009 09:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 nBXqC9s2y3VP; Tue, 29 Sep 2009 09:47:01 -0700 (PDT) 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 10E3728C18B; Tue, 29 Sep 2009 09:47:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,474,1249272000"; d="scan'208";a="185019141" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 29 Sep 2009 12:48:20 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 29 Sep 2009 12:48:19 -0400 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, 29 Sep 2009 18:47:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Access Node Control Protocol (ancp) thread-index: AcpBJGUUmmNRPf6ZSoKlwYDd3d6rLwAAA06g From: "Romascanu, Dan (Dan)" To: , , "MIB Doctors (E-mail)" , Subject: [dns-dir] FW: WG Review: Recharter of Access Node Control Protocol (ancp) 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, 29 Sep 2009 16:47:02 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, September 29, 2009 6:45 PM To: ietf-announce@ietf.org Cc: matthew.bocci@alcatel-lucent.com; wdec@cisco.com; ancp@ietf.org Subject: WG Review: Recharter of Access Node Control Protocol (ancp)=20 A modified charter has been submitted for the Access Node Control Protocol (ancp) working group in the Internet 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, October 6, 2009. Access Node Control Protocol (ancp) ----------------------------------- Current Status: Active Working Group Chair(s): Wojciech Dec Matthew Bocci Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Technical Advisor(s): Dan Romascanu Mailing Lists: General Discussion: ancp@ietf.org To Subscribe: ancp-request@ietf.org In Body: In Body: subscribe your_email_address Archive: =20 http://www.ietf.org/mail-archive/web/ancp/current/maillist.html Description of Working Group:=20 Purpose:=20 The purpose of the ANCP WG is to standardize an IP-based Access Node Control Protocol (ANCP) for use in service provider Digital Subscriber Line (DSL) and Passive Optical Network (PON) access and aggregation networks. ANCP operates between an Access Node (AN) and Network Access Server (NAS). Necessary Terminology:=20 Access Node (AN) - Network device, usually located at a service provider central office or street cabinet, that terminates access loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is usually comprised of an Optical Network Termination (ONT) / Optical Network Unit (ONU) and an Optical Line Termination (OLT). Network Access Server (NAS) - Network device which aggregates multiplexed Subscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subscriber policy enforcement and QoS. This is often referred to as a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A detailed definition of the NAS is given in RFC2881. Goals:=20 ANCP is intended to address the requirement for a bidirectional, IP- based, control protocol that operates across multiple types (i.e., Ethernet, ATM) of DSL and PON access and aggregation networks. The goal of an ANCP message exchange is to convey status and control information between one or more ANs and one or more NASs without going through intermediate element managers. The ANCP WG will address the following four use-cases:=20 1. Dynamic Access Loop Attributes Various queuing and scheduling mechanisms are used in access networks to avoid congestion while dealing with multiple flows and distinct QoS profiles. Communicating the access-loop status, attributes and current DSL synchronization rate between the AN and Subscriber up to the NAS is desirable, particularly when the NAS is providing QoS for individual flows and subscribers. ANCP will provide a mechanism to communicate dynamic access-loop attributes from the AN to the NAS. 2. Access Loop Configuration In additional to reporting Access Loop characteristics from the AN to the NAS, ANCP will allow a NAS to send loop-specific configuration information to an AN based on the results of subscriber authentication and authorization (e.g., after AAA responses have been received at the NAS). 3. Remote Connectivity Test Traditional DSL access and aggregation networks employ point-to-point ATM circuits between the AN and NAS for each subscriber, allowing troubleshooting of the local loop from the NAS via ATM OAM tools. With the increasing deployment of Ethernet in the access and aggregation network, operators require consistent methods to test and troubleshoot connectivity for mixed Ethernet and ATM access networks (including the local loop). ANCP will allow a remote procedure for a local loop connectivity test to be triggered from the NAS with results communicated back to the NAS. 4. Multicast When multicast replication for subscriber-bound traffic is performed at the AN, it offloads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership. Non-Goals:=20 ANCP is an IP-based protocol that operates between the AN and NAS. It will not address setup or configuration of circuits or connections in the access and aggregation network itself. The focus of this WG is on one very specific application space. While the design of the protocol must be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of service provider broadband (such as xDSL, xPON) access and aggregation networks. Security:=20 The ANCP working group will provide a threat analysis and address the associated security aspects of the control protocol. Resiliency and Scalability:=20 A graceful restart mechanism will be defined to enable the protocol to be resilient to network failures between the AN and NAS. Scalability at the NAS is of primary concern, as it may be aggregating traffic from a large number of ANs, which in turn may be serving a large number of Subscribers. ANCP traffic should not become a denial of service attack on the NAS control plane. Format of messages, pacing, transport over UDP or TCP, etc. will be considered with this in mind. For reasons of aggregation network scalability, some use cases require that aspects of NAS or AN functionality may be distributed in nodes in the aggregation network. In these cases, ANCP can run between these nodes. Deliverables:=20 The working group will define a basic framework and requirements document intended for Informational publication, focusing on the four use-cases outlined in this charter. This document will include a security threat analysis and associated requirements. The WG will then investigate and define a solution for an IP based control protocol meeting these requirements. There are early interoperable implementations of an ANCP-like protocol which are based on an extended subset of the GSMPv3 protocol. This running code will be the the starting point for the working group solution, and will be abandoned only if the WG determines it is not adequate to meet requirements going forward. Coordination with other Working Groups or Organizations:=20 The working group will coordinate with the ADSL MIB working group so the management framework and MIB modules are consistent for DSL access environments. The working group will re-use, as far as possible, standard MIB modules that have already been defined. The remote connectivity test use case may require coordination with ITU-T Ethernet OAM and PON work and with IEEE 802.1ag. Goals and Milestones:=20 Done Accept WG I-D for ANCP Framework and Requirements=20 Done Accept WG I-D for Access Node Control Protocol (ANCP)=20 Done Accept WG ID for Security Threats analysis=20 Done Accept WG I-D for ANCP MIB=20 Done Security Threats Analysis last call=20 Done Framework and Requirements last call=20 Done Accept WG I-D for ANCP Multicast Extensions Nov 2009 Accept WG I-D for ANCP applicability to PON=20 Jan 2010 Access Node Control Protocol (ANCP) Last Call=20 Jan 2010 ANCP Multicast Extensions last call Jan 2010 ANCP MIB Last Call=20 Apr 2010 ANCP applicability to PON last call Jul 2010 Re-charter or conclude Working Group From dromasca@avaya.com Tue Sep 29 10:07:11 2009 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 8FBD83A698B; Tue, 29 Sep 2009 10:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 ogrKgVtm-nXi; Tue, 29 Sep 2009 10:07:10 -0700 (PDT) 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 5E6AD3A68DB; Tue, 29 Sep 2009 10:07:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,474,1249272000"; d="scan'208";a="158325423" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 Sep 2009 13:08:27 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Sep 2009 13:08:26 -0400 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, 29 Sep 2009 19:08:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Multipath TCP (mptcp) thread-index: AcpBJnt923x603VCRr+L1+2J0hJkWQAAOBzw From: "Romascanu, Dan (Dan)" To: , , "MIB Doctors (E-mail)" , Subject: [dns-dir] FW: WG Review: Multipath TCP (mptcp) 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, 29 Sep 2009 17:07:11 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, September 29, 2009 7:00 PM To: ietf-announce@ietf.org Cc: multipathtcp@ietf.org Subject: WG Review: Multipath TCP (mptcp)=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, October 6, 2009. Multipath TCP (mptcp) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Current Status: Proposed Working Group Last updated: 2009-09-28 Chair(s): =20 * To be decided Transport Area Director(s): * Magnus Westerlund * Lars Eggert Transport Area Advisor: * Magnus Westerlund Mailing List: To subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp Archive: http://www.ietf.org/mail-archive/web/multipathtcp/ Description of Working Group: The Multipath TCP (MPTCP) working group develops mechanisms that add the capability of simultaneously using multiple paths to a regular TCP session. The primary output of the group will be the protocol extensions needed to deploy MPTCP, and adaptations to congestion control to safely support multipath resource sharing. Initially the WG will only produce documents that are experimental or informational.=20 Key goals for MPTCP are: to be deployable and usable without significant changes to existing Internet infrastructure; to be usable by unmodified applications; and to be stable and congestion-safe over the wide range of existing Internet paths. That will include handling MTU discovery on a per path basis and NAT interactions. The design's success in meeting the goals should be determined through experiments.=20 However, it is expected that some results from large scale experiments can only be achievable after the publication of the initial design.=20 The working group will provide a modular architecture that is designed to be easily extensible and adaptable. In particular, the congestion control mechanism is separated from the mechanisms for identifying and using multiple paths. The working group will focus on a solution requiring modification of both peers. One or both peers are expected to have multiple addresses, which often results in different network paths that are at least partially divergent. However, multiple addresses, even on different network interfaces, are no guarantee that the paths are divergent at all. The design needs to address the issues associated with fully or partially joint paths and shared bottlenecks. The design should allow for future extensions to handle cases where path diversity is attempted through other means than using different addresses. The design must also consider what happens when end-point pairs become unavailable during an ongoing session, especially pairs used to establish connections between additional end-point pairs.=20 Whilst MPTCP will require modifications to the TCP stack at both the peers, all existing applications should be able to use the new MPTCP stack without modification and gain benefits from multipath usage. The impact on different classes of applications will be considered and documented. An extended API will be defined to allow applications to express particular preferences for how MPTCP operates, and to get additional information about MPTCP-specific run-time events.=20 The WG will carefully analyze and address in the appropriate protocol documents all new security threats introduced by MPTCP. The following items will be worked on: a. An architectural framework for congestion-dependent multipath transport protocols. This is an overview document which tracks the technical documents, describing how the modular components fit together, and will describe the motivations and the general approach that should be followed to enable congestion-dependent multipath transport. It will also analyze how MPTCP interacts with existing infrastructure elements and other address agility mechanisms, such as Mobile IP, HIP and SHIM6. The results of any experiment performed during the development should also be included or referenced in this document.=20 b. A security threat analysis for multipath TCP. The ability to change the addresses used during a TCP session opens up new types of vulnerabilities and attacks. These and their mitigations will be documented.=20 c. A coupled multipath-aware congestion control algorithm. This algorithm is the multipath equivalent of SACK/NewReno congestion control. As experience is gathered from implementations of various congestion control algorithms, it is expected that the working group will be rechartered to pursue additional work in these areas.=20 d. Extensions to current TCP to support multi-addressed multipath TCP.=20 This covers all on-the-wire changes required to create a two-ended MPTCP solution using multiple addresses at one or both ends. It will be designed in a modular fashion to allow alternative address management schemes to be explored in future. This document will also include a basic security model. e. An application considerations document, presenting the impacts that MPTCP may have on applications, such as performance changes, and including an extended API describing how applications can exploit additional features of multipath transport. While MPTCP needs to be usable without any application changes, this API should be an optional extension that provides access to multipath information and enables control over the usage of multipath.=20 Where appropriate, this group is expected to coordinate with, and will use input from, the MIF working group to support the use of multiple interfaces. Goals and Milestones: Mar 2010 - Established WG consensus on the Architecture Aug 2010 - Submit to IESG architectural guidelines and security threat analysis as informational RFC(s) Mar 2011 - Submit to IESG basic coupled congestion control as an=20 experimental RFC Mar 2011 - Submit to IESG protocol specification for MPTCP extensions=20 as an experimental RFC Mar 2011 - Submit to IESG application considerations and API as an=20 informational RFC Mar 2011 - Recharter or close WG From ogud@ogud.com Tue Sep 29 11:28:43 2009 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 A36A63A659B for ; Tue, 29 Sep 2009 11:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 CQ3IKMd9-HYl for ; Tue, 29 Sep 2009 11:28:42 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id B460A3A6904 for ; Tue, 29 Sep 2009 11:28:42 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id n8TIU1kj027113 for ; Tue, 29 Sep 2009 14:30:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: Olafur_DNS_EARLY_WARNING Date: Tue, 29 Sep 2009 14:30:01 -0400 X-Mailer: Perl script "early-new.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20090929_183001_041561.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.64 on 66.92.146.20 Subject: [dns-dir] DNS Early Warn: draft-iucg-punyplus-02.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, 29 Sep 2009 18:28:43 -0000 Count: 11 Network Working Group Jean-Francois C. Morfin Internet-Draft Intlnet Intended status: Independent submission September 29, 2009 Expires: March 29, 2010 Case sensitive IDNA draft-iucg-punyplus-02.txt Abstract This memo documents an IDNA proposition (AKA IDNAPLUS), which supports upper and lowercases and new possibilities for the Internet name space.