From ogud@ogud.com Fri Jun 4 11:41:14 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA6C3A684D for ; Fri, 4 Jun 2010 11:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.604 X-Spam-Level: X-Spam-Status: No, score=0.604 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoVvGAFQypAb for ; Fri, 4 Jun 2010 11:41:13 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id A91E228C0F5 for ; Fri, 4 Jun 2010 11:40:16 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o54Ie0gV028410 for ; Fri, 4 Jun 2010 14:40:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Fri, 4 Jun 2010 14:40:01 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100604_184001_078659.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-penno-alto-cdn-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, 04 Jun 2010 18:41:14 -0000 Count: 49 Network Working Group R. Penno Internet-Draft S. Raghunath Intended status: Experimental J. Medved Expires: December 6, 2010 M. Bakshi Juniper Networks R. Alimi Yale University S. Previdi Cisco Systems June 04, 2010 ALTO and Content Delivery Networks draft-penno-alto-cdn-00 Abstract Networking applications can request through the ALTO protocol information about the underlying network topology from the ISP or Content Provider (henceforth referred as Provider) point of view. In other words, what a Provider prefers in terms of traffic optimization -- and a way to distribute it. The ALTO Service provides information such as preferences of network resources with the goal of modifying network resource consumption patterns while maintaining or improving application performance. A main use case of the ALTO Service is its integration with of Content Delivery Networks (CDN). In this document we describe the deployment scenarios and considerations for a ALTO Service in the case of CDNs. From jari.arkko@piuha.net Mon Jun 7 15:30:47 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520853A6837 for ; Mon, 7 Jun 2010 15:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[AWL=1.278, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+-uvOgOzmRf for ; Mon, 7 Jun 2010 15:30:46 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 1AC0B3A687E for ; Mon, 7 Jun 2010 15:30:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9EEEB2CED5; Tue, 8 Jun 2010 01:30:30 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Si6Q7O4+zla; Tue, 8 Jun 2010 01:30:30 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 924A82CCA5; Tue, 8 Jun 2010 01:30:29 +0300 (EEST) Message-ID: <4C0D2431.7030703@piuha.net> Date: Mon, 07 Jun 2010 12:54:09 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: dns directorate , David Harrington , draft-ietf-behave-dns64@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dns-dir] review sought: dns64 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, 07 Jun 2010 22:30:47 -0000 Directorate, I would like to get a review or reviews of draft-ietf-behave-dns64. This draft is a part of a package that has gone to last call recently, specifications relating to IPv6 to IPv4 translation (aka improved but not perfect NAT-PT). Jari From ajs@shinkuro.com Tue Jun 8 08:23:22 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2B043A69C2 for ; Tue, 8 Jun 2010 08:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.5 X-Spam-Level: * X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ptkUZrHhn5z for ; Tue, 8 Jun 2010 08:23:22 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 1D64B3A67A2 for ; Tue, 8 Jun 2010 08:23:19 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A7EB31ECB408; Tue, 8 Jun 2010 15:23:18 +0000 (UTC) Date: Tue, 8 Jun 2010 11:23:17 -0400 From: Andrew Sullivan To: Jari Arkko Message-ID: <20100608152316.GC62459@shinkuro.com> References: <4C0D2431.7030703@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C0D2431.7030703@piuha.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: David Harrington , dns directorate , draft-ietf-behave-dns64@tools.ietf.org Subject: Re: [dns-dir] review sought: dns64 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 Jun 2010 15:23:22 -0000 On Mon, Jun 07, 2010 at 12:54:09PM -0400, Jari Arkko wrote: > Directorate, > > I would like to get a review or reviews of draft-ietf-behave-dns64. This > draft is a part of a package that has gone to last call recently, > specifications relating to IPv6 to IPv4 translation (aka improved but > not perfect NAT-PT). I would also appreciate review. I've asked more than once in DNSEXT for reviews, and the response has been -- well, I don't want to say "paltry", but you get the drift. We just got an excellent review forwarded (by Dave Thaler) from inside Microsoft -- it's really helpful. Please, please someone review this. And don't be gentle :) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ogud@ogud.com Wed Jun 9 11:40:01 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7DE3A67EA for ; Wed, 9 Jun 2010 11:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXbjl8E4wrHU for ; Wed, 9 Jun 2010 11:40:00 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id F26053A6767 for ; Wed, 9 Jun 2010 11:39:59 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o59Ie0JI072639 for ; Wed, 9 Jun 2010 14:40:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 9 Jun 2010 14:40:00 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100609_184000_003033.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-stiemerling-alto-deployments-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: Wed, 09 Jun 2010 18:40:01 -0000 Count: 11 ALTO M. Stiemerling Internet-Draft NEC Europe Ltd. Intended status: Standards Track S. Kiesel Expires: December 11, 2010 University of Stuttgart June 9, 2010 ALTO Deployment Considerations draft-stiemerling-alto-deployments-03 Abstract Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to these applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. The protocol is under specification in the ALTO working group. However, this document discusses the deployment considerations of ALTO and also some preliminary security considerations. From dromasca@avaya.com Fri Jun 11 00:47:43 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06AF03A6A0A; Fri, 11 Jun 2010 00:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.243 X-Spam-Level: X-Spam-Status: No, score=-0.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNtJOwFamRSb; Fri, 11 Jun 2010 00:47:41 -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 D87693A677D; Fri, 11 Jun 2010 00:47:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,402,1272859200"; d="scan'208";a="192947575" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Jun 2010 03:47:40 -0400 X-IronPort-AV: E=Sophos;i="4.53,402,1272859200"; d="scan'208";a="471541479" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Jun 2010 03:47:39 -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, 11 Jun 2010 09:47:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the June 17, 2010 IESG Teleconference Thread-Index: AcsI6YTBDzPc89uDQoC2Yy7/rVs8vwAUGjXA From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for the June 17, 2010 IESG Teleconference 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, 11 Jun 2010 07:47:43 -0000 Please find below the preliminary agenda of the IESG telechat scheduled for 6/17. Please send me your comments, questions and concerns about the documents brought up for approval before Wednesday 6/16 COB.=20 Thanks and Regards, Dan ---------------------------------------------- 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-enum-3761bis-08 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) (Proposed Standard) Note: Richard Shockey (richard@shockey.us) is the document shepherd.Cluster - draft-ietf-enum-3761bis- draft-ietf-enum-enumservices-guide- draft-ietf-enum-enumservices-transition Token: Gonzalo Camarillo o draft-ietf-enum-enumservices-guide-20 IANA Registration of Enumservices: Guide, Template and IANA Considerations (Proposed Standard) Note: Bernie Hoeneisen is shepherd fro this. Proto write up entered as IESG note on 2010-0225. Should cluster with- draft-ietf-enum-3761bis- draft-ietf-enum-enumservices-guide- draft-ietf-enum-enumservices-transition Token: Gonzalo Camarillo o draft-ietf-enum-enumservices-transition-05 Update of legacy IANA Registrations of Enumservices (Proposed Standard) Note: Richard Shockey (richard@shockey.us) is the document shepherd.cluster with- draft-ietf-enum-3761bis- draft-ietf-enum-enumservices-guide- draft-ietf-enum-enumservices-transition Token: Gonzalo Camarillo o draft-ietf-netconf-monitoring-14 YANG Module for NETCONF Monitoring (Proposed Standard) Note: Mehmet Ersue (mehmet.ersue@nsn.com) is the Document Shepard for this document. Token: Dan Romascanu o draft-ietf-mboned-ipv4-uni-based-mcast-06 Unicast-Prefix-based IPv4 Multicast Addresses (Proposed Standard) Note: Lenny Giuliano (lenny@juniper.net) is the Document Shepherd. Token: Ron Bonica o draft-ietf-dnsext-dns-tcp-requirements-03 DNS Transport over TCP - Implementation Requirements (Proposed Standard) Note: Olafur Gudmundsson (ogud@ogud.com) is the document shepherd. Token: Ralph Droms o draft-ietf-ipsecme-eap-mutual-03 An Extension for EAP-Only Authentication in IKEv2 (Proposed Standard) Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd. Token: Sean Turner o draft-ietf-mpls-tp-data-plane-03 MPLS Transport Profile Data Plane Architecture (Proposed Standard) Note: Loa Andersson (loa@pi.nu) is the Document Shepherd. Token: Adrian Farrel 2.1.2 Returning Items o draft-freed-sieve-notary-09 Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions (Proposed Standard) Note: This is a Sieve WG document, despite the name. Cyrus Daboo is the document shepherd. Bringing this document for another IESG review after changes resulting from SecDir review. Token: Alexey Melnikov 2.2 Individual Submissions 2.2.1 New Items o draft-kucherawy-authres-header-b-02 Authentication-Results Registration For Differentiating Among Cryptographic Results (Proposed Standard) Note: Barry Leiba is the document shepherd.The example would need to be fixed as per an IETF LC comment. Token: Alexey Melnikov o rfc4049 BinaryTime: An alternate format for representing date and time in ASN.1 (Proposed) Token: Alexey Melnikov 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-nsis-applicability-mobility-signaling-17 NSIS Protocols operation in Mobile Environments (Informational) Note: The document shepherd is Martin Stiemerling (martin.stiemerling@neclab.eu). Token: Lars Eggert o draft-ietf-bmwg-protection-term-08 Benchmarking Terminology for Protection Performance (Informational) Note: Al Morton (acmorton@att.com) is the shepherd. Token: Ron Bonica o draft-ietf-hip-via-01 Host Identity Protocol (HIP) Multi-hop Routing Extension (Experimental) Note: David Ward (dward@juniper.net) is the document shepherd. Token: Ralph Droms o draft-ietf-hip-hiccups-02 HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS) (Experimental) Note: David Ward (dward@juniper.net) is the document shepherd. Token: Ralph Droms o draft-ietf-hip-bone-06 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (Experimental) Note: David Ward (dward@juniper.net) is the document shepherd. Token: Ralph Droms o rfc5652 Cryptographic Message Syntax (CMS) (Standard) Token: Tim Polk 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items NONE 3.3 Independent Submissions Via RFC Editor 3.3.1 New Items o draft-rosen-vpn-mcast-15 Cisco Systems' Solution for Multicast in MPLS/BGP IP VPNs (Informational) Token: Adrian Farrel 3.3.2 Returning Items NONE 3.3.3 For Action o draft-keromytis-tls-authz-keynote-06 Transport Layer Security (TLS) Authorization Using KeyNote (Informational) Token: Russ Housley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Call Control UUI for SIP (cuss) Token: Gonzalo o Sip ALerting for User Devices (salud) Token: Gonzalo o DISaggregated Media Architecture for Network-enabled Transmissions among Loosely-coupled End-devices (dismantle) Token: Gonzalo 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE ------------------------------------------------------------------------ From ogud@ogud.com Fri Jun 11 12:06:57 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B779628C122 for ; Fri, 11 Jun 2010 12:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_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 Kkp+DdLyOrEj for ; Fri, 11 Jun 2010 12:06:56 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id C25CF3A6968 for ; Fri, 11 Jun 2010 12:06:55 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5BJ6sep091761; Fri, 11 Jun 2010 15:06:55 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4C12894D.7020002@ogud.com> Date: Fri, 11 Jun 2010 15:06:53 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: DNS Directorate Subject: Re: [dns-dir] FW: PRELIMINARY Agenda and Package for the June 17, 2010 IESG Teleconference 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, 11 Jun 2010 19:06:57 -0000 Starting DNS Scan dnsext-dns-tcp-requirements 00 42 01 43 02 50 03 53 enum-3761bis 00 68 01 68 02 201 03 225 04 243 05 245 06 245 07 156 08 156 enum-enumservices-guide 03 22 04 27 05 26 06 27 07 30 08 30 09 30 10 30 11 30 12 31 13 27 16 28 17 29 18 29 19 34 20 34 enum-enumservices-transition 02 12 03 12 04 12 05 12 The first document is just perfect :-) (speaking as DS) The second document is harmless from DNS perspective. Olafur On 11/06/2010 3:47 AM, Romascanu, Dan (Dan) wrote: > Please find below the preliminary agenda of the IESG telechat scheduled > for 6/17. Please send me your comments, questions and concerns about the > documents brought up for approval before Wednesday 6/16 COB. > > Thanks and Regards, > > Dan > > ---------------------------------------------- > > > 2. Protocol Actions > 2.1 WG Submissions > 2.1.1 New Items > > o draft-ietf-enum-3761bis-08 > The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation > Discovery System (DDDS) Application (ENUM) (Proposed Standard) > Note: Richard Shockey (richard@shockey.us) is the document > shepherd.Cluster - draft-ietf-enum-3761bis- > draft-ietf-enum-enumservices-guide- > draft-ietf-enum-enumservices-transition > Token: Gonzalo Camarillo > > o draft-ietf-enum-enumservices-guide-20 > IANA Registration of Enumservices: Guide, Template and IANA > Considerations (Proposed Standard) > Note: Bernie Hoeneisen is shepherd > fro this. Proto write up entered as IESG note on 2010-0225. > Should cluster with- draft-ietf-enum-3761bis- > draft-ietf-enum-enumservices-guide- > draft-ietf-enum-enumservices-transition > Token: Gonzalo Camarillo > > o draft-ietf-enum-enumservices-transition-05 > Update of legacy IANA Registrations of Enumservices (Proposed > Standard) > Note: Richard Shockey (richard@shockey.us) is the document > shepherd.cluster with- draft-ietf-enum-3761bis- > draft-ietf-enum-enumservices-guide- > draft-ietf-enum-enumservices-transition > Token: Gonzalo Camarillo > > o draft-ietf-netconf-monitoring-14 > YANG Module for NETCONF Monitoring (Proposed Standard) > Note: Mehmet Ersue (mehmet.ersue@nsn.com) is the Document Shepard > for this document. > Token: Dan Romascanu > > o draft-ietf-mboned-ipv4-uni-based-mcast-06 > Unicast-Prefix-based IPv4 Multicast Addresses (Proposed Standard) > Note: Lenny Giuliano (lenny@juniper.net) is the Document Shepherd. > Token: Ron Bonica > > o draft-ietf-dnsext-dns-tcp-requirements-03 > DNS Transport over TCP - Implementation Requirements (Proposed > Standard) > Note: Olafur Gudmundsson (ogud@ogud.com) is the document shepherd. > Token: Ralph Droms > > o draft-ietf-ipsecme-eap-mutual-03 > An Extension for EAP-Only Authentication in IKEv2 (Proposed > Standard) > Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd. > Token: Sean Turner > > o draft-ietf-mpls-tp-data-plane-03 > MPLS Transport Profile Data Plane Architecture (Proposed Standard) > Note: Loa Andersson (loa@pi.nu) is the Document Shepherd. > Token: Adrian Farrel > > 2.1.2 Returning Items > > o draft-freed-sieve-notary-09 > Sieve Email Filtering: Delivery Status Notifications and Deliver-By > Extensions (Proposed Standard) > Note: This is a Sieve WG document, despite the name. Cyrus Daboo is > the document shepherd. Bringing this document for another IESG > review after changes resulting from SecDir review. > Token: Alexey Melnikov > > 2.2 Individual Submissions > 2.2.1 New Items > > o draft-kucherawy-authres-header-b-02 > Authentication-Results Registration For Differentiating Among > Cryptographic Results (Proposed Standard) > Note: Barry Leiba is the document > shepherd.The example would need to be fixed as per an IETF LC > comment. > Token: Alexey Melnikov > > o rfc4049 > BinaryTime: An alternate format for representing date and time in > ASN.1 (Proposed) > Token: Alexey Melnikov > > 2.2.2 Returning Items > > NONE > > 3. Document Actions > 3.1 WG Submissions > 3.1.1 New Items > > o draft-ietf-nsis-applicability-mobility-signaling-17 > NSIS Protocols operation in Mobile Environments (Informational) > Note: The document shepherd is Martin Stiemerling > (martin.stiemerling@neclab.eu). > Token: Lars Eggert > > o draft-ietf-bmwg-protection-term-08 > Benchmarking Terminology for Protection Performance (Informational) > Note: Al Morton (acmorton@att.com) is the shepherd. > Token: Ron Bonica > > o draft-ietf-hip-via-01 > Host Identity Protocol (HIP) Multi-hop Routing Extension > (Experimental) > Note: David Ward (dward@juniper.net) is the document shepherd. > Token: Ralph Droms > > o draft-ietf-hip-hiccups-02 > HIP (Host Identity Protocol) Immediate Carriage and Conveyance of > Upper- layer Protocol Signaling (HICCUPS) (Experimental) > Note: David Ward (dward@juniper.net) is the document shepherd. > Token: Ralph Droms > > o draft-ietf-hip-bone-06 > HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking > Environment (Experimental) > Note: David Ward (dward@juniper.net) is the document shepherd. > Token: Ralph Droms > > o rfc5652 > Cryptographic Message Syntax (CMS) (Standard) > Token: Tim Polk > > 3.1.2 Returning Items > > NONE > > 3.2 Individual Submissions Via AD > 3.2.1 New Items > > NONE > > 3.2.2 Returning Items > > NONE > > 3.3 Independent Submissions Via RFC Editor > 3.3.1 New Items > > o draft-rosen-vpn-mcast-15 > Cisco Systems' Solution for Multicast in MPLS/BGP IP VPNs > (Informational) > Token: Adrian Farrel > > 3.3.2 Returning Items > > NONE > > 3.3.3 For Action > > o draft-keromytis-tls-authz-keynote-06 > Transport Layer Security (TLS) Authorization Using KeyNote > (Informational) > Token: Russ Housley > > 4. Working Group Actions > 4.1 WG Creation > 4.1.1 Proposed for IETF Review > > o Call Control UUI for SIP (cuss) > Token: Gonzalo > > o Sip ALerting for User Devices (salud) > Token: Gonzalo > > o DISaggregated Media Architecture for Network-enabled Transmissions > among Loosely-coupled End-devices (dismantle) > Token: Gonzalo > > 4.1.2 Proposed for Approval > > NONE > > 4.2 WG Rechartering > 4.2.1 Under Evaluation for IETF Review > > NONE > > 4.2.2 Proposed for Approval > > NONE > > ------------------------------------------------------------------------ > > > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir > > > From ogud@ogud.com Mon Jun 14 11:40:06 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D163A69C8 for ; Mon, 14 Jun 2010 11:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, J_CHICKENPOX_54=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 XegN5a5AGVDA for ; Mon, 14 Jun 2010 11:40:05 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id E63AC3A69E9 for ; Mon, 14 Jun 2010 11:39:57 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5EIe0aV016125 for ; Mon, 14 Jun 2010 14:40:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Mon, 14 Jun 2010 14:40:00 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100614_184000_049629.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-ietf-mboned-mcast-arpa-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: Mon, 14 Jun 2010 18:40:06 -0000 Count: 10 Network Working Group P. Koch Internet-Draft DENIC eG Intended status: BCP L. Vegoda Expires: December 16, 2010 ICANN June 14, 2010 Moving MCAST.NET into the ARPA infrastructure top level domain draft-ietf-mboned-mcast-arpa-02 Abstract This document proposes to migrate the MCAST.NET domain into the ARPA top level domain that is dedicated to infrastructure support. It also provides for a maintenance policy for the new MCAST.ARPA domain and covers migration issues and caveats. This document updates RFC 5771 and forms part of BCP 51. XXX reverse mapping From ogud@ogud.com Mon Jun 21 11:40:24 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8CA3A6AB1 for ; Mon, 21 Jun 2010 11:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.054 X-Spam-Level: X-Spam-Status: No, score=-0.054 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-qraT3GXUji for ; Mon, 21 Jun 2010 11:40:12 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 610CD3A6A07 for ; Mon, 21 Jun 2010 11:39:54 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5LIe0aa012927 for ; Mon, 21 Jun 2010 14:40:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Mon, 21 Jun 2010 14:40:00 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100621_184000_072784.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-carpenter-referral-ps-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 Jun 2010 18:40:24 -0000 Count: 23 Network Working Group B. Carpenter Internet-Draft Univ. of Auckland Intended status: Informational S. Jiang Expires: December 23, 2010 Huawei Technologies Co., Ltd B. Zhou ChinaMobile June 21, 2010 Problem Statement for Referral draft-carpenter-referral-ps-00 Abstract The purpose of a referral is to enable a given entity in a multiparty Internet application to pass information to another party. It enables a communication initiator to be aware of relevant information of its destination entity before launching the communication. This memo discusses the problems involved in referral scenarios. From dromasca@avaya.com Wed Jun 23 03:05:37 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884953A68AF; Wed, 23 Jun 2010 03:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.793, 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 qOnQhMxXzom2; Wed, 23 Jun 2010 03:05:36 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id D1D983A67F6; Wed, 23 Jun 2010 03:05:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="21954687" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 23 Jun 2010 06:05:34 -0400 X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="475122964" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Jun 2010 06:04:58 -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, 23 Jun 2010 12:04:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Call Control UUI for SIP (cuss) Thread-Index: AcsSLG1A83zuJOvPQq6o9Y1ihb30owAjr3kQ From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [dns-dir] FW: WG Review: Call Control UUI for SIP (cuss) 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 Jun 2010 10:05:37 -0000 Please find below the proposed charter of the CUSS WG in RAI. Please send your questions, comments and concerns before 6/29 COB.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, June 22, 2010 8:00 PM To: new-work@ietf.org Subject: WG Review: Call Control UUI for SIP (cuss)=20 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. =20 Call Control UUI for SIP (cuss) -------------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-06-21 Chair(s): TBD Real-time Applications and Infrastructure Area Director(s): Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: TBD Description of Working Group: The Call Control UUI for SIP (CUSS) working group is chartered to define a Session Initiation Protocol (SIP) mechanism for transporting call-control related user-to-user information (UUI) between User Agents. =20 The mechanism developed in this working group is applicable in the following situations: 1. The information is generated and consumed by an application using SIP during session setup but the application is not necessarily even SIP aware. 2. The behavior of SIP entities that support it is not significantly changed (as discussed in Section 4 of RFC 5727). 3. Generally only the User Agent Client (UAC) and User Agent Server (UAS) are interested in the information. 4. The information is expected to survive retargeting, redirection, and transfers. 5. SIP elements may need to apply policy about passing and screening the information. 6. Multi-vendor interoperability is important. This mechanism is not applicable in the following situations: 1. The behavior of SIP entities that support it is significantly changed (as discussed in Section 4 of RFC 5727). 2. The information is generated and consumed at the SIP layer by SIP elements. 3. SIP elements besides the UAC and UAS might be interested in consuming (beyond applying policy) the information. 4. There are specific privacy issues involved with the information being transported (e.g., geolocation or emergency-related information). User data of the mechanism will be clearly marked with the application, encoding, semantics, and content type, allowing policy to be applied by UAs. The working group will define the information that each application must specify to utilize the mechanism. This type of application-specific information will be specified in standards-track documents. =20 One important application of this mechanism is interworking with the ISDN User to User Information Service. This application defined by ITU-T Q.931 is extensively deployed in the PSTN today supporting such applications as contact centers, call centers, and automatic call distributors (ACDs). A major barrier to the movement of these applications to SIP is the lack of a standard mechanism to transport this information in SIP. For interworking with ISDN, minimal information about the content of the UUI is available to the PSTN-SIP gateways. In this case only, the content will just indicate ISDN UUI Service 1 interworking rather than the actual content. =20 Call control UUI is user information conveyed between user agents during call control operations. As a result, the information must be conveyed with the INVITE transaction, and must survive proxy retargeting, redirection, and transfers. The mechanism must utilize a minimum of SIP extensions since it will need to be supported by many simple SIP user agents such as PSTN gateways. The mechanism must interwork with the existing ISDN service but should also be extensible for use by other applications and non-ISDN protocols. Even though interworking with the PSTN is an important requirement, call control UUI can be exchanged between native SIP clients that do not have any ISUP support. Therefore, existing SIP-T encapsulation-based approaches defined in RFC3372 do not meet the requirements to transport this type of information. Mechanisms based on the SIP INFO method, RFC2976, will not be considered by the working group since the UUI contents carry information that must be conveyed during session setup at the user agent - the information must be conveyed with the INVITE transaction. The information must be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases. =20 The group will produce: - A problem statement and requirements document for implementing a SIP call control UUI mechanism =20 - A specification of the SIP extension to best meet those requirements. =20 Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Sep 10 - Problem statement and requirements document to IESG (Informational) Mar 11 - SIP call control UUI specification to IESG (PS) From dromasca@avaya.com Wed Jun 23 03:06:03 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6771B3A67F6; Wed, 23 Jun 2010 03:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.776, 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 v7+fEWpx7Usc; Wed, 23 Jun 2010 03:06:02 -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 3DA7A3A68AF; Wed, 23 Jun 2010 03:06:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="194820593" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Jun 2010 06:06:07 -0400 X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="475123469" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Jun 2010 06:06:05 -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, 23 Jun 2010 12:06:04 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Loosely-coupled SIP Devices (LSD) Thread-Index: AcsSMLLSU8ceL4aSQbaZDQnoTuL/HgAiuXEQ From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [dns-dir] FW: WG Review: Loosely-coupled SIP Devices (LSD) 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 Jun 2010 10:06:03 -0000 =20 Please find below the proposed charter of the LSD WG in RAI. Please send your questions, comments and concerns before 6/29 COB.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, June 22, 2010 8:30 PM To: new-work@ietf.org Subject: WG Review: Loosely-coupled SIP Devices (LSD)=20 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. =20 Loosely-coupled SIP Devices (LSD) -------------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-06-21 Chair(s): TBD Real-time Applications and Infrastructure Area Director(s): Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: TBD Description of Working Group: Loosely-coupled SIP Devices (LSD) -------------------------------------------- Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams coming from different devices under his or her control so that they are treated by the far end of the session as a single media session.=20 Generally, a given participant uses a single device to establish (or participate in) a given multimedia session. Consequently, the SIP signaling to manage the multimedia session and the actual media streams are typically co-located in the same device. In scenarios involving disaggregated media, a user wants to establish a single multimedia session combining different media streams coming from different devices under his or her control. This creates a need to coordinate the exchange of the those media streams within the multimedia session. There are a number of existing mechanisms that can be used to coordinate different devices under user's control and to involve them in the call (e.g. Message Bus (Mbus) [RFC3259], Megaco [ITU-T H.248.1] and SIP 3pcc [RFC3725]). However, these mechanisms are intended to be used in "tightly coupled" scenarios. The use of all those mechanisms requires the presence of a "master" device. That is, at least one among the different devices under the control of the same user must support the control mechanism and be able to become a controller for the other devices in the call. Moreover, the "master" device is supposed to remain involved in the user's session for its entire duration given that performing a handover of the master role is typically cumbersome and sometimes impossible. The objective of this working group is to develop a framework for disaggregated media in "loosely-coupled" scenarios, where no single device needs to remain in the session for its entire duration and no single device needs to act as a master. Coordination among devices in this type of scenario is less tight than in the scenarios described above since they do not assume central elements with complete knowledge of the whole media session. While the framework may describe how to use existing mechanisms (e.g., the SIP REFER method) to coordinate devices, the working group will not develop new device coordination mechanisms. The framework may identify the need for new (non-device-coordination) mechanisms to enable the implementation of loosely-coupled scenarios. In case the need for such new mechanisms is identified, the working group will specify them. Specifically, the proposed working group will develop the following deliverables: 1. A framework document describing key considerations for the exchange of disaggregated media in SIP. The document will include use cases and examples. The document may indentify the need for new mechanisms or extensions to existing mechanisms. 2. Specifications of new mechanisms or extensions to existing mechanisms if the need is identified in the framework. Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Feb 2011 - Framework document sent to the IESG (Informational) From dromasca@avaya.com Wed Jun 23 03:07:08 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F05B3A697B; Wed, 23 Jun 2010 03:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.761, 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 Lowty-y+6y4y; Wed, 23 Jun 2010 03:07:07 -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 EDFDD3A6910; Wed, 23 Jun 2010 03:07:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="194820741" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Jun 2010 06:07:11 -0400 X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="485701327" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jun 2010 06:07:10 -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, 23 Jun 2010 12:06:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Sip ALerting for User Devices (salud) Thread-Index: AcsSLou6FtIRcVsoR9aya0rxCpvz9gAjTDYA From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [dns-dir] FW: WG Review: Sip ALerting for User Devices (salud) 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 Jun 2010 10:07:08 -0000 Please find below the proposed charter of the SALUD WG in RAI. Please send your questions, comments and concerns before 6/29 COB.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, June 22, 2010 8:15 PM To: ietf-announce@ietf.org Subject: WG Review: Sip ALerting for User Devices (salud)=20 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. =20 Sip ALerting for User Devices (salud) -------------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-06-21 Chair(s): TBD Real-time Applications and Infrastructure Area Director(s): Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: TBD Description of Working Group: The SALUD (Sip ALerting for User Devices) working group is chartered to define a new URN namespace that allows SIP to convey a particular alert indication using a name instead of a referenced URI. The Alert-Info URN namespace addresses issues encountered in current systems that use the Alert-Info header field. It is expected that this group will collaborate with the Applications area on the definition of the URN namespace. RFC 3261 allows a user agent server to provide a specific ringing tone, which can be played to the calling user, as a reference (e.g., an HTTP URI) in the Alert-Info header. In some situations, the calling user may not be able to understand the meaning of the ringing tone being played. For example, a user from a given country may not be familiar with the tone used to indicate call waiting in another country. Similarly, a hearing impaired person may prefer to get a visual call waiting indication instead of a call waiting tone. RFC 3261 also allows a user agent client to provide a reference to a specific alerting tone, which can be played to the called user (e.g., tones for emergency announcements sent over PBX systems or over the local telephone network). As in the previous examples, in some situations, the calling user may not be able to understand the meaning of the alerting tone being played. These issues can be resolved with a mechanism for user agents to exchange this type of alerting information in a semantic way. In this way, different user agents can use different renderings for the same semantics. For example, a user agent client instructed to inform its user about a call waiting service being provided can use the personalized tones that were previously configured by the user. Traditionally, SIP has used status codes to encode session state information (e.g., 180 Ringing). Status codes are used by SIP entities in an automatic fashion. The information this working group is concerned with is related to rendering and may not represent the state of the session. Additionally, the exchange of this information does not affect the way SIP entities process the session. That is why status codes are not an appropriate vehicle to encode this type of information. This working group will work on encoding this information in URNs. In addition to defining URNs that are associated to particular events (e.g., a call waiting service is being applied), this working group will also define URNs that describe the characteristics of the alerting to be applied (e.g., play a short tone followed by a long tone). There are a variety of non-interoperable URI conventions and proprietary Alert-Info header field parameters to provide this type of information today. A standardized set of Alert-Info URNs will increase SIP interoperability for this header field by replacing proprietary conventions. The group will produce a specification that: * describes the problem statement. * describes requirements and use cases. * defines an Alert-Info URN-scheme which allows to resolve the interoperability problems described in the use cases. * defines the specific Alert-Info URNs identifiers for some of the use cases above. The Alert-Info URN namespace must be open, so that additional Alert-Info URNs can be defined later if necessary. Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Aug 2011 - Alert-Info URN specification to IESG (PS) From dromasca@avaya.com Wed Jun 23 06:33:22 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A19E28C11F; Wed, 23 Jun 2010 06:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.717, 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 npwTKQDKMQ9e; Wed, 23 Jun 2010 06:33:20 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 80E2A28C131; Wed, 23 Jun 2010 06:32:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="21987362" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 23 Jun 2010 09:32:49 -0400 X-IronPort-AV: E=Sophos;i="4.53,466,1272859200"; d="scan'208";a="485762311" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jun 2010 09:32:48 -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, 23 Jun 2010 15:32:46 +0200 Message-ID: In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A649EFEEE@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: WG Review: Call Control UUI for SIP (cuss) Thread-Index: AcsSLG1A83zuJOvPQq6o9Y1ihb30owAjr3kQAABByQAABurm4A== References: <80A0822C5E9A4440A5117C2F4CD36A649EFEEE@DEMUEXC006.nsn-intra.net> From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Munich)" , , "MIB Doctors (E-mail)" , , Subject: Re: [dns-dir] [OPS-DIR] FW: WG Review: Call Control UUI for SIP (cuss) 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 Jun 2010 13:33:22 -0000 This is the mode of work that is being used by RAI for the last year or so, and this is the result of their previous experience with SIPPING, which was running in parallel a large number of items and many of them were going nowhere. Now they use DISPATCH to approve and charter new items and they create WG's to solve defined sets of problems, in some cases smaller than the typical WG goals.=20 Dan =20 > -----Original Message----- > From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com]=20 > Sent: Wednesday, June 23, 2010 4:22 PM > To: Romascanu, Dan (Dan); aaa-doctors@ietf.org; MIB Doctors=20 > (E-mail); dns-dir@ietf.org; ops-dir@ietf.org > Subject: RE: [OPS-DIR] FW: WG Review: Call Control UUI for SIP (cuss) >=20 >=20 > Hi, >=20 > > The group will produce: > > - A problem statement and requirements document for=20 > implementing a SIP=20 > > call control UUI mechanism > > - A specification of the SIP extension to best meet those=20 > > requirements. >=20 > It might be an old issue and already discussed earlier but I=20 > still have some problems to understand why a workgroup is=20 > necessary for such a (more or less) small issue? >=20 > I think a RAI area WG is still interesting for issues without=20 > a home in existing RAI area workgroups.=20 >=20 > Cheers, > Mehmet >=20 > =20 >=20 > > -----Original Message----- > > From: ops-dir-bounces@ietf.org > > [mailto:ops-dir-bounces@ietf.org] On Behalf Of ext Romascanu, Dan=20 > > (Dan) > > Sent: Wednesday, June 23, 2010 12:05 PM > > To: aaa-doctors@ietf.org; MIB Doctors (E-mail); dns-dir@ietf.org;=20 > > ops-dir@ietf.org > > Subject: [OPS-DIR] FW: WG Review: Call Control UUI for SIP (cuss) > >=20 > > Please find below the proposed charter of the CUSS WG in=20 > RAI. Please=20 > > send your questions, comments and concerns before 6/29 COB. > >=20 > > Thanks and Regards, > >=20 > > Dan > >=20 > >=20 > > -----Original Message----- > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org]=20 > On Behalf=20 > > Of IESG Secretary > > Sent: Tuesday, June 22, 2010 8:00 PM > > To: new-work@ietf.org > > Subject: WG Review: Call Control UUI for SIP (cuss) > >=20 > > A new IETF working group has been proposed in the Real-time=20 > > Applications and Infrastructure Area. The IESG has not made any=20 > > determination as yet. > > The following draft charter was submitted, and is provided for=20 > > informational purposes only. Please send your comments to the IESG=20 > > mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. > >=20 > > Call Control UUI for SIP (cuss) > > -------------------------------------------------- > > Current Status: Proposed Working Group > >=20 > > Last modified: 2010-06-21 > >=20 > > Chair(s): > > TBD > >=20 > > Real-time Applications and Infrastructure Area Director(s): > > Gonzalo Camarillo > > Robert Sparks > >=20 > > Real-time Applications and Infrastructure Area Advisor: > > Gonzalo Camarillo > >=20 > > Mailing Lists: TBD > >=20 > > Description of Working Group: > >=20 > > The Call Control UUI for SIP (CUSS) working group is chartered to=20 > > define a Session Initiation Protocol (SIP) mechanism for=20 > transporting=20 > > call-control related user-to-user information (UUI) between User=20 > > Agents. > > =20 > > The mechanism developed in this working group is applicable in the=20 > > following situations: > >=20 > > 1. The information is generated and consumed by an application using > > SIP during session setup but the application is not necessarily > > even SIP aware. > > 2. The behavior of SIP entities that support it is not significantly > > changed (as discussed in Section 4 of RFC 5727). > > 3. Generally only the User Agent Client (UAC) and User Agent Server > > (UAS) are interested in the information. > > 4. The information is expected to survive retargeting, redirection, > > and transfers. > > 5. SIP elements may need to apply policy about passing and screening > > the information. > > 6. Multi-vendor interoperability is important. > >=20 > > This mechanism is not applicable in the following situations: > >=20 > > 1. The behavior of SIP entities that support it is significantly > > changed (as discussed in Section 4 of RFC 5727). > > 2. The information is generated and consumed at the SIP layer by SIP > > elements. > > 3. SIP elements besides the UAC and UAS might be interested in > > consuming (beyond applying policy) the information. > > 4. There are specific privacy issues involved with the information > > being transported (e.g., geolocation or emergency-related > > information). > >=20 > > User data of the mechanism will be clearly marked with the=20 > > application, encoding, semantics, and content type,=20 > allowing policy to=20 > > be applied by UAs. The working group will define the=20 > information that=20 > > each application must specify to utilize the mechanism.=20 > This type of=20 > > application-specific information will be specified in=20 > standards-track=20 > > documents. > > =20 > > One important application of this mechanism is interworking=20 > with the=20 > > ISDN User to User Information Service. This application defined by=20 > > ITU-T Q.931 is extensively deployed in the PSTN today=20 > supporting such=20 > > applications as contact centers, call centers, and automatic call=20 > > distributors (ACDs). A major barrier to the movement of these=20 > > applications to SIP is the lack of a standard mechanism to=20 > transport=20 > > this information in SIP. For interworking with ISDN, minimal=20 > > information about the content of the UUI is available to=20 > the PSTN-SIP=20 > > gateways. In this case only, the content will just=20 > indicate ISDN UUI=20 > > Service 1 interworking rather than the actual content. > > =20 > > Call control UUI is user information conveyed between user agents=20 > > during call control operations. As a result, the=20 > information must be=20 > > conveyed with the INVITE transaction, and must survive proxy=20 > > retargeting, redirection, and transfers. The mechanism=20 > must utilize a=20 > > minimum of SIP extensions since it will need to be=20 > supported by many=20 > > simple SIP user agents such as PSTN gateways. The mechanism must=20 > > interwork with the existing ISDN service but should also be=20 > extensible=20 > > for use by other applications and non-ISDN protocols. > >=20 > > Even though interworking with the PSTN is an important requirement,=20 > > call control UUI can be exchanged between native SIP=20 > clients that do=20 > > not have any ISUP support. Therefore, existing SIP-T=20 > > encapsulation-based approaches defined in RFC3372 do not meet the=20 > > requirements to transport this type of information. > >=20 > > Mechanisms based on the SIP INFO method, RFC2976, will not be=20 > > considered by the working group since the UUI contents carry=20 > > information that must be conveyed during session setup at the user=20 > > agent - the information must be conveyed with the INVITE=20 > transaction. > > The information must be passed with the session setup request=20 > > (INVITE), responses to that INVITE, or session termination requests. > > As a result, it is not possible to use INFO in these cases. > > =20 > > The group will produce: > >=20 > > - A problem statement and requirements document for=20 > implementing a SIP=20 > > call control UUI mechanism > > =20 > > - A specification of the SIP extension to best meet those=20 > > requirements. > > =20 > > Goals and Milestones > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =20 > > Sep 10 - Problem statement and requirements document to IESG > > (Informational) > > Mar 11 - SIP call control UUI specification to IESG (PS)=20 > > _______________________________________________ > > OPS-DIR mailing list > > OPS-DIR@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-dir > >=20 >=20 From ogud@ogud.com Wed Jun 23 11:39:59 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F20A13A6AF9 for ; Wed, 23 Jun 2010 11:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.048 X-Spam-Level: X-Spam-Status: No, score=-0.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjXxFROwUKX7 for ; Wed, 23 Jun 2010 11:39:57 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id DFF8E3A6A01 for ; Wed, 23 Jun 2010 11:39:53 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5NIe01j031151 for ; Wed, 23 Jun 2010 14:40:00 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Wed, 23 Jun 2010 14:40:00 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100623_184000_007689.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-vixie-dnsext-resimprove-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 Jun 2010 18:39:59 -0000 Count: 22 DNSEXT Working Group P. Vixie, ISC INTERNET-DRAFT R. Joffe, Centergate F. Neves, Registro Intended Status: For Your Information June 22, 2010 Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness Abstract This document describes several mechanisms which can be employed by iterative caching DNS resolvers to improve resiliency, robustness, and responsiveness. These improvements are optional and they require no changes to the protocol, or to authority servers, or to DNS stub resolver clients. From dromasca@avaya.com Fri Jun 25 00:47:30 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6DA3A6915; Fri, 25 Jun 2010 00:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.714, 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 elMabxsFyAUV; Fri, 25 Jun 2010 00:47:28 -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 D698D3A68AD; Fri, 25 Jun 2010 00:47:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,480,1272859200"; d="scan'208";a="195173279" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Jun 2010 03:47:34 -0400 X-IronPort-AV: E=Sophos;i="4.53,480,1272859200"; d="scan'208";a="475832338" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Jun 2010 03:47:33 -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, 25 Jun 2010 09:47:29 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the July 1, 2010 IESG Teleconference Thread-Index: AcsT67sAyQuS/gNVTti7wXiIruURtwATpBBg From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for the July 1, 2010 IESG Teleconference 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, 25 Jun 2010 07:47:30 -0000 =20 Please find below the preliminary agenda of the 7/1 IESG teleconference. Please let me know if there are any questions, issues, or concerns related to the documents and WG charters brought up for approval.=20 Thanks and Regards, Dan 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-behave-turn-ipv6-09 Traversal Using Relays around NAT (TURN) Extension for IPv6 (Proposed Standard) Note: Dan Wing (dwing@cisco.com) is the document shepherd. Token: David Harrington o draft-ietf-behave-turn-tcp-06 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations (Proposed Standard) Note: Dan Wing, dwing@cisco.com is the document shepherd. Token: David Harrington o draft-ietf-sipcore-invfix-01 Correct transaction handling for 2xx responses to Session Initiation Protocol (SIP) INVITE requests (Proposed Standard) Note: Adam Roach (adam@nostrum.com) is the document shepherd. Token: Gonzalo Camarillo o draft-ietf-6man-dns-options-bis-03 IPv6 Router Advertisement Options for DNS Configuration RFC 5006-bis (Proposed Standard) Note: Bob Hinden (bob.hinden@gmail.com) is the document shepherd. Token: Jari Arkko 2.1.2 Returning Items o draft-ietf-avt-seed-srtp-14 The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP) (Proposed Standard) Token: Robert Sparks 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-nsis-applicability-mobility-signaling-18 NSIS Protocols operation in Mobile Environments (Informational) Note: The document shepherd is Martin Stiemerling (martin.stiemerling@neclab.eu). Token: Lars Eggert Was deferred by Tim Polk on 2010-06-15 o draft-ietf-mpls-tp-survive-fwk-06 Multiprotocol Label Switching Transport Profile Survivability Framework (Informational) Note: Loa Andersson (loa@pi.nu) is the Document Shepherd. Token: Stewart Bryant o draft-ietf-csi-proxy-send-04 Secure Proxy ND Support for SEND (Experimental) Note: Marcelo Bagnulo (marcelo@it.uc3m.es) is the document shepherd. Token: Ralph Droms o draft-ietf-ipsecme-ipsec-ha-07 IPsec Cluster Problem Statement (Informational) Note: Yaron Sheffer (yaronf.ietf@gmail.com) is the document shepherd. Token: Sean Turner o draft-ietf-nsis-tunnel-11 NSIS Operation Over IP Tunnels (Experimental) Note: The document shepherd is Jukka Manner (jukka.manner@tkk.fi). Token: Lars Eggert 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-hoffman-tls-master-secret-input-01 Additional Master Secret Inputs for TLS (Experimental) Note: There is no document shepherd. Token: Sean Turner o draft-c1222-transport-over-ip-03 ANSI C12.22, IEEE 1703 and MC12.22 Transport Over IP (Informational) Note: Fred Baker is the Document Shepherd. Token: Ralph Droms 3.2.2 Returning Items NONE 3.3 Independent Submissions Via RFC Editor 3.3.1 New Items NONE 3.3.2 Returning Items o draft-keromytis-tls-authz-keynote-06 Transport Layer Security (TLS) Authorization Using KeyNote (Informational) Token: Tim Polk 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o Call Control UUI for SIP (cuss) Token: Gonzalo o Sip ALerting for User Devices (salud) Token: Gonzalo o Loosely-coupled SIP Devices (lsd) Token: Gonzalo 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE From ogud@ogud.com Tue Jun 29 11:39:52 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B135C3A685F for ; Tue, 29 Jun 2010 11:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.07 X-Spam-Level: X-Spam-Status: No, score=-0.07 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C38clgB7BjIa for ; Tue, 29 Jun 2010 11:39:51 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 9D7DA3A6823 for ; Tue, 29 Jun 2010 11:39:51 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5TIe1Zm010494 for ; Tue, 29 Jun 2010 14:40:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Tue, 29 Jun 2010 14:40:01 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100629_184001_039940.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-mekking-dnsop-auto-cpsync-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, 29 Jun 2010 18:39:53 -0000 Count: 31 Domain Name System Operations W. Mekking Internet-Draft NLnet Labs Intended status: Standards Track June 29, 2010 Expires: December 31, 2010 Automated (DNSSEC) Child Parent Synchronization using DNS UPDATE draft-mekking-dnsop-auto-cpsync-00 Abstract This document proposes a way to synchronise existing trust anchors automatically between a child zone and its parent. The algorithm can be used for other Resource Records that are required to delegate from a parent to a child such as NS and glue records. From ogud@ogud.com Tue Jun 29 11:39:55 2010 Return-Path: X-Original-To: dns-dir@core3.amsl.com Delivered-To: dns-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA51A3A685F for ; Tue, 29 Jun 2010 11:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[AWL=1.312, 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 rZl7K7xFOFXG for ; Tue, 29 Jun 2010 11:39:54 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 4C00D3A6823 for ; Tue, 29 Jun 2010 11:39:51 -0700 (PDT) Received: from localhost (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5TIe1uR010485 for ; Tue, 29 Jun 2010 14:40:01 -0400 (EDT) (envelope-from ogud@ogud.com) To: dns-dir@ietf.org From: DNS_EARLY_WARNING Date: Tue, 29 Jun 2010 14:40:01 -0400 X-Mailer: Perl script "early-2010.pl" using Mail::Sender 0.8.16 by Jenda Krynicky, Czechlands running on localhost (127.0.0.1) under account "idmbox" Message-ID: <20100629_184001_089739.ogud@ogud.com> X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Subject: [dns-dir] DNS-EW: draft-huang-behave-bih-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, 29 Jun 2010 18:39:55 -0000 Count: 15 Behave B. Huang Internet-Draft H. Deng Obsoletes: 3338, 2767 China Mobile (if approved) T. Savolainen Intended status: Standards Track Nokia Expires: December 31, 2010 June 29, 2010 Dual Stack Hosts Using "Bump-in-the-Host" (BIH) draft-huang-behave-bih-00 Abstract This document describes the "Bump-In-the-Host" (BIH), a host based protocol translation mechanism that allows a subset of applications supporting only one IP address family to communicate with peers that are reachable or supporting only the other address family. This specification addresses scenarios where a host is provided dual stack or IPv6 only network connectivity. In the dual stack network case, single address family applications in the host sometime will communicate directly with other hosts using the different address family. In the case of IPv6 only network or IPv6 only destination, IPv4 originated communications have to be translated into IPv6. The BIH makes the IPv4 applications think they talk to IPv4 peers and hence hides the IPv6 from those applications. Acknowledgement of previous work This document is an update to and directly derivative from Kazuaki TSHUCHIYA, Hidemitsu HIGUCHI, and Yoshifumi ATARASHI [RFC2767] and from Seungyun Lee, Myung-Ki Shin, Yong-Jin Kim, Alain Durand, and Erik Nordmark's [RFC3338], which similarly provides a dual stack host means to communicate with other IPv6 host using existing IPv4 appliations. This document combines and updates both [RFC2767] and [RFC3338]. The changes in this document reflect five components 1. Supporting IPv6 only network connections 2. IPv4 address pool use private address instead of the unassigned IPv4 addresses (0.0.0.1 - 0.0.0.255) 3. Extending ENR and address mapper to operate differently 4. Adding an alternative way to implement the ENR 5. Going for standards track instead of experimental/ informational