From dromasca@avaya.com Mon Mar 2 01:53:34 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A16B28C164 for ; Mon, 2 Mar 2009 01:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 OM3H4v+P+qKg for ; Mon, 2 Mar 2009 01:53:33 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id D4EA63A68C7 for ; Mon, 2 Mar 2009 01:52:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,288,1233550800"; d="scan'208";a="138939527" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Mar 2009 04:53:14 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Mar 2009 04:53:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2009 10:52:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thursday AAA-Doctors work Lunch in San Francisco Thread-Index: AcmbHKlBLao6+V7fSoS+gqV9kw5kqA== From: "Romascanu, Dan (Dan)" To: Subject: [AAA-DOCTORS] Thursday AAA-Doctors work Lunch in San Francisco X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 09:53:34 -0000 AAA-Doctors team members who will attend the San Francisco IETF meeting - please book the Thursday lunch slot for a work lunch. We shall use the same format as in Minneapolis - get individually some food and get together in a to-be-announced room by 11:45AM. Thanks and Regards, Ron and Dan From dromasca@avaya.com Wed Mar 4 04:35:32 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9CB28C2DA; Wed, 4 Mar 2009 04:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 qccIueBb9w3o; Wed, 4 Mar 2009 04:35:32 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 5FEFB28C173; Wed, 4 Mar 2009 04:35:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,300,1233550800"; d="scan'208";a="139205321" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Mar 2009 07:35:57 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Mar 2009 07:35:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 13:35:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-jones-dime-3gpp-eps-command-codes-01.txt to Informational RFC Thread-Index: AcmcuMC/ytBhHSQFTZyIKkla5jO//QADN4vA From: "Romascanu, Dan (Dan)" To: , , Subject: [AAA-DOCTORS] FW: Evaluation: draft-jones-dime-3gpp-eps-command-codes-01.txt to Informational RFC X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 12:35:33 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jones-dime-3gpp-eps-command-co des-01.txt Technical Summary This document registers a set of IANA Diameter Command Codes to be used in new vendor-specific Diameter applications defined for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). These new Diameter applications are defined for MME and SGSN related interfaces in the Release 8 architecture. Working Group Summary This document is not a DIME working group document but has received review from DIME WG members Document Quality The document has been reviewed by Hannes Tschofenig, Victor Fajardo and Glen Zorn from the DIME working group. The main work this document is based on has been developed in the 3GPP and has received a fair amount of review. Personnel Hannes Tschofenig is the document shepherd. Dan Romascanu is the responsible Area Director.=20 RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Wed Mar 4 04:40:00 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9053A6C80; Wed, 4 Mar 2009 04:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 F+Ht7KGCJiKe; Wed, 4 Mar 2009 04:39:59 -0800 (PST) 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 AFB013A6C7A; Wed, 4 Mar 2009 04:39:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,300,1233550800"; d="scan'208";a="154172642" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 04 Mar 2009 07:40:26 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 04 Mar 2009 07:40:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 13:39:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-netconf-tls-07.txt to Proposed Standard Thread-Index: AcmctE6PJ+XXJxdqS+eRZAX3IY0LqwAEeJog From: "Romascanu, Dan (Dan)" To: , , "Netconf" Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-netconf-tls-07.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 12:40:00 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-07.txt Technical Summary The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to provide a secure connection for the transport of NETCONF messages. The mechanisms defined in this document include the support for certificate-based mutual authentication and key derivation, utilizing the protected ciphersuite negotiation, mutual authentication and key management capabilities of the TLS (Transport Layer Security) protocol. Working Group Summary Many WG member were thinking that password-based authentication is already handled well enough by the existing NETCONF transports (SSH and BEEP), and the NETCONF-over- TLS specification does not need to handle passwords. It has been recommended to scope the document to certificate- based authentication.=20 There was also some controversy on the use of pre-shared keys (PSKs) derived from passwords. Based on this dicussion the Working Group decided to remove the text related to PSK based- authentication. See http://www.ietf.org/mail-archive/web/netconf/current/msg03856.html =20 There was some controversal discussion about the Connection Closure. The consensus was that the document adopts the closure mechanism from draft-ietf-syslog-transport-tls-, Section 4.4.=20 =20 There was also some controversy about the use of a dedicated port of NETCONF over TLS. The consensus was that a dedicated port should be requested.=20 =20 The summary of the last changes can be found in: http://www.ietf.org/mail-archive/web/netconf/current/msg03873.html http://www.ietf.org/mail-archive/web/netconf/current/msg03882.html=20 There were many WG members who did not strongly support or object to the document. Nobody objected to the document during or after the WGLC. The level of review in the WG was adequate , with several=20 independent reviews by WG members. There is WG consensus to publish =20 the document.=20 Document Quality No vendors have announced that they will utilize this protocol.=20 Two implementations with independent code-base and initiated by the document author are available as open source. The author ensures that the two implementations have been tested as interoperable. Personnel The document was reviewed by Eric Rescorla, Juergen Schoenwaelder, David Harrington, the WG security advisor Charlie Kaufman, and the security ADs Pasi Eronen and Tim Polk.=20 Mehmet Ersue is the document shepherd, and Dan Romascanu the shepherding AD.=20 RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Wed Mar 4 06:28:32 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD4C43A6898; Wed, 4 Mar 2009 06:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 AJHSKj1-Nsfg; Wed, 4 Mar 2009 06:28:32 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 724693A6822; Wed, 4 Mar 2009 06:28:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,301,1233550800"; d="scan'208";a="139218663" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Mar 2009 09:28:57 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 04 Mar 2009 09:28:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 15:28:56 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internal WG Review: Dispatch (dispatch) Thread-Index: AcmcXkvs3kE8Nc02SIKLJR0gWWaCugAdxjPQ From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Internal WG Review: Dispatch (dispatch) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 14:28:33 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Wednesday, March 04, 2009 2:15 AM To: iesg@ietf.org; iab@iab.org Subject: Internal WG Review: Dispatch (dispatch)=20 A new IETF working group is being considered in the Real-time Applications and Infrastructure Area. The draft charter for this working group is provided below for your review and comment. Review time is one week. The IETF Secretariat Dispatch (dispatch) -------------------------------------------------- Current Status: Proposed Working Group Last Modified: 2009-02-27 Group Description:=20 The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work. Options for handling new work include: - Assigning the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter and establishing consensus for a new WG or Exploratory Group. This option will primarily be used with fairly mature and well-defined efforts. A major objective of the DISPATCH WG is to provide timely, clear dispositions of new efforts. Where there is consensus to take on new work, the WG will strive to quickly find a home for it. Reconsideration of proposal which have failed to gather consensus will be prioritized behind proposals for new work which have not yet been considered. In general, requests for reconsideration should only be made once a proposal has been significantly revised. The DISPATCH WG will also operate as an area wide WG where ideas can be discussed that do not currently have a logical venue for the work to be done. As part of this function, the WG will evaluate SIP Event Packages that were not developed inside some other area working group. Guiding principles will include: 1. Providing a clear problem statement for proposed new work. 2. Prioritizing new efforts so that RAI does not take on more work than it can effectively complete. 3. Looking for commonalities among ongoing development efforts. Such commonalities may indicate the need to develop more general, reusable components. 4. Protecting the architectural integrity of RAI protocols and ensuring that work has general applicability. The WG may take on some of the previous work items from the SIPPING working group to allow a smooth transition From dromasca@avaya.com Wed Mar 4 07:49:31 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39BF128C312; Wed, 4 Mar 2009 07:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 6Q+lkZ5d9IWJ; Wed, 4 Mar 2009 07:49:30 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 480F13A6898; Wed, 4 Mar 2009 07:49:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,301,1233550800"; d="scan'208";a="139230699" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Mar 2009 10:49:55 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 04 Mar 2009 10:49:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 16:49:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Routing Over Low power and Lossy networks (roll) Thread-Index: Acmc37S4wZkAFU/FSP+TRjc77XBEZQAARavg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 15:49:31 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Wednesday, March 04, 2009 5:41 PM To: new-work@ietf.org Subject: WG Review: Recharter of Routing Over Low power and Lossy networks (roll)=20 A modified charter has been submitted for the Routing Over Low power and Lossy networks working group in the Routing Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. Routing Over Low power and Lossy networks (roll) =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= Last Modified: 2009-02-04 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/roll=20 Chair(s): JP Vasseur David Culler =20 Routing Area Director(s): Ross Callon David Ward =20 Routing Area Advisor: David Ward =20 Mailing Lists: General Discussion: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ Description of Working Group: Low power and Lossy networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies.=20 Generally speaking, LLNs have at least five distinguishing characteristics:=20 - LLNs operate with a hard, very small bound on state. - In most cases, LLN optimize for saving energy. - Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). - In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers.=20 - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements.=20 As shown in a protocol survey existing routing protocols (in their current =20 form) such as OSPF, IS-IS, AODV, and OLSR, do not meet these specific routing requirements. The Working Group is focused on routing issues for LLN. There is a wide scope of application areas for LLNs, including industrial =20 monitoring, building automation (HVAC, lighting, access control, fire), connected homes, healthcare, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: industrial, connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents will be used for protocol design. The Working Group focuses only on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with =20 very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes.=20 The Working Group will pay particular attention to routing security and manageability (e.g., self routing configuration) issues. It will also need to consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that establish some degree of fairness between concurrent communication sessions are out of scope of the Working Group. It is expected that upper-layer applications utilizing LLNs define appropriate mechanisms. Work Items: - Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs. - Provide an architectural framework for routing and path selection at Layer 3 (Routing for LLN Architecture) that addresses such issues as whether LLN routing require a distributed and/or centralized path computation models, whether additional hierarchy is necessary and how it is applied. =20 Manageability will be considered with each approach, along with various trade-offs for maintaining low power operation, including the presence of non-trivial loss and networks with a very large number of nodes. - Produce a routing security framework for routing in LLNs. - Protocol work: In light of the application specific routing requirements, the Working Group will either specify a new protocol and/or will select an existing routing protocol (with the appropriate extensions in cooperation with the relevant Working Group). - Documentation of applicability statement of ROLL routing protocols. Goals and Milestones: Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. Feb 2010 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. March 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. April 2010 Evaluate WG progress, recharter or close. From dromasca@avaya.com Wed Mar 4 07:49:32 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DAA528C396; Wed, 4 Mar 2009 07:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 od-rd07mf1EF; Wed, 4 Mar 2009 07:49:31 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 72C1D28C1EC; Wed, 4 Mar 2009 07:49:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,301,1233550800"; d="scan'208";a="139230704" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Mar 2009 10:49:56 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 04 Mar 2009 10:49:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 16:49:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Routing Over Low power and Lossy networks (roll) Thread-Index: Acmc33nV+/p5hzxkSx6FriwO2Vq8kQAAVmdA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 15:49:32 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Wednesday, March 04, 2009 5:39 PM To: IETF Announcement list Cc: roll@ietf.org; jpv@cisco.com; culler@eecs.berkeley.edu Subject: WG Review: Recharter of Routing Over Low power and Lossy networks (roll)=20 A modified charter has been submitted for the Routing Over Low power and Lossy networks working group in the Routing Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. Routing Over Low power and Lossy networks (roll) =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= Last Modified: 2009-02-04 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/roll=20 Chair(s): JP Vasseur David Culler =20 Routing Area Director(s): Ross Callon David Ward =20 Routing Area Advisor: David Ward =20 Mailing Lists: General Discussion: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ Description of Working Group: Low power and Lossy networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies.=20 Generally speaking, LLNs have at least five distinguishing characteristics:=20 - LLNs operate with a hard, very small bound on state. - In most cases, LLN optimize for saving energy. - Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). - In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers.=20 - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements.=20 As shown in a protocol survey existing routing protocols (in their current =20 form) such as OSPF, IS-IS, AODV, and OLSR, do not meet these specific routing requirements. The Working Group is focused on routing issues for LLN. There is a wide scope of application areas for LLNs, including industrial =20 monitoring, building automation (HVAC, lighting, access control, fire), connected homes, healthcare, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: industrial, connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents will be used for protocol design. The Working Group focuses only on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with =20 very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes.=20 The Working Group will pay particular attention to routing security and manageability (e.g., self routing configuration) issues. It will also need to consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that establish some degree of fairness between concurrent communication sessions are out of scope of the Working Group. It is expected that upper-layer applications utilizing LLNs define appropriate mechanisms. Work Items: - Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs. - Provide an architectural framework for routing and path selection at Layer 3 (Routing for LLN Architecture) that addresses such issues as whether LLN routing require a distributed and/or centralized path computation models, whether additional hierarchy is necessary and how it is applied. =20 Manageability will be considered with each approach, along with various trade-offs for maintaining low power operation, including the presence of non-trivial loss and networks with a very large number of nodes. - Produce a routing security framework for routing in LLNs. - Protocol work: In light of the application specific routing requirements, the Working Group will either specify a new protocol and/or will select an existing routing protocol (with the appropriate extensions in cooperation with the relevant Working Group). - Documentation of applicability statement of ROLL routing protocols. Goals and Milestones: Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. Feb 2010 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. March 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. April 2010 Evaluate WG progress, recharter or close. From dromasca@avaya.com Thu Mar 5 07:46:41 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21AC3A6899; Thu, 5 Mar 2009 07:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 i5U0776jsOyR; Thu, 5 Mar 2009 07:46:40 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 2683D28C10E; Thu, 5 Mar 2009 07:46:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,307,1233550800"; d="scan'208";a="139349251" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Mar 2009 10:47:08 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 05 Mar 2009 10:47:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Mar 2009 16:46:13 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Network File System Version 4 (nfsv4) Thread-Index: AcmdDZo5hsNaWGFARsu9o4KGnWpFGQAm+QiA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: WG Review: Recharter of Network File System Version 4 (nfsv4) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 15:46:41 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Wednesday, March 04, 2009 11:10 PM To: IETF Announcement list Cc: spencer.shepler@sun.com; beepy@netapp.com; nfsv4@ietf.org Subject: WG Review: Recharter of Network File System Version 4 (nfsv4)=20 A modified charter has been submitted for the Network File System Version 4 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 Wednesday, March 11, 2009. Network File System Version 4 (nfsv4) =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 Last Modified: 2009-02-10 Current Status: Active Working Group Chair(s): Brian Pawlowski Spencer Shepler =20 Transport Area Director(s): Magnus Westerlund Lars Eggert =20 Transport Area Advisor: Lars Eggert =20 Technical Advisor(s): Leif Johansson =20 Mailing Lists: General Discussion: nfsv4@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/nfsv4 Archive: http://www.ietf.org/mail-archive/web/nfsv4/index.html Description of Working Group: NFS Version 4 is the IETF standard for file sharing. To maintain NFS Version 4's utility and currency, the working group is chartered to (1) maintain the existing NFSv4, NFSv4.1 and related specifications, such as RPC and XDR, (2) progress these specifications along the standards track, (3) develop a protocol to create a federated namespace using NFSv4's existing referral mechanisms. (1) NFS version 4.0 maintenance Under this charter item, the WG correct errors and ambiguities in the protocol currently specified in RFC 3530 and advances it along the standards track. Extensions of any other kind are out of scope under this charter item. (2) NFS Version 4.1 Maintenance As with NFSv4.0, the WG will address errors or ambiguities in the NFSv4.1 protocol and related specifications in support of progressing implementations. (3) RPC and XDR protocol maintenance The NFSv4 protocol depends on two related specifications: ONC RPC and XDR. Similar to charter item (1), the WG may correct errors and ambiguities in the ONC RPC and XDR protocols currently specified by RFCs 1831, 1833 and 2203. In conjunction with the advancement of the NFSv4 specification along the standards track, the WG will also work on the advancements of its ONC RPC and XDR dependencies. The WG will also update the ONC RPC specification for compatibility with IPv6. Additionally, it will create an IANA registry for RPC program numbers and seed it with a registry Sun has been maintaining. (4) Federated Namespace The NFSv4 protocol provides a referral mechanism that allows a server to redirect a client to another server. The working group will produce documents describing a mechanism for creating a federated namespace (single global name space for a set of NFSv4 servers) using the NFSv4 protocol's referral capabilities. The file system federation protocol will enable file access and namespace traversal across collections of independently administered fileservers. No modifications will be made to the NFS client to server protocol. Milestones: DONE WG Last Call for RPC and NFS RDMA drafts DONE WG Last Call for rfc1831bis (RPC version 2)=20 DONE WG Last Call for NFSv4 minor version 1=20 DONE WG Last Call for NFSv4.1 block/volume layout=20 DONE WG Last Call for NFSv4.1 Object-based layout=20 DONE Submit NFS Minor Version 1 to IESG for publication as a Propoased Standard=20 DONE Submit pNFS Block/Volume Layout to IESG for publication as a Propoased Standard=20 DONE Submit Object-based pNFS Operations to IESG for publication as a Proposed Standard=20 Sep 2009 WG Last Call for rfc3530bis (NFS version 4) May 2009 WG Last Call for "Requirements for Federated File Systems" draft-ietf-nfsv4-federated-fs-reqts-01 Oct 2009 WG Last Call for "Administration Protocol for Federated Filesystems" draft-ietf-nfsv4-federated-fs-admin-00.txt Oct 2009 WG Last Call for "NSDB Protocol for Federated Filesystems" draft-ietf-nfsv4-federated-fs-protocol-00.txt From dromasca@avaya.com Thu Mar 5 10:44:58 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F88128C20C; Thu, 5 Mar 2009 10:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKoLbIYx6Zyv; Thu, 5 Mar 2009 10:44:57 -0800 (PST) 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 1661F28C10E; Thu, 5 Mar 2009 10:44:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,308,1233550800"; d="scan'208";a="154355578" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 05 Mar 2009 13:45:25 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Mar 2009 13:45:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Mar 2009 19:45:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internal WG Review: Locator/ID Separation Protocol (lisp) Thread-Index: AcmduhE4wtJ4+odBTC2bo6zrmEOsagACHGCQ From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Internal WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 18:44:58 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Thursday, March 05, 2009 7:44 PM To: iesg@ietf.org; iab@iab.org Subject: Internal WG Review: Locator/ID Separation Protocol (lisp)=20 A new IETF working group is being considered in the Internet Area. The draft charter for this working group is provided below for your review and comment. Review time is one week. The IETF Secretariat Locator/ID Separation Protocol (lisp) -------------------------------------------------- Last Modified: 2009-03-05 Current status: Proposed Working Group Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Secretary: TBD Mailing Lists: General Discussion: lisp@ietf.org Description of Working Group: The IAB's October 2006 workshop on Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "Locator/Identifier separation" (frequently referred to as Loc/ID split). The basic idea behind the Loc/ID split that the Internet architecture combines two functions, Routing Locators, or RLOCs (where you are attached to the network) and Endpoint Identifiers, or EIDs (who you are) in one number space: The IP address. Proponents of the Loc/ID split postulate that splitting these functions apart with yield several advantages, including improved scalability for the routing system. The Loc/ID split aims to decouple location and identity, thus allowing for efficient aggregation of the RLOC space and providing persistent identity in the EID space. The LISP protocol is an instantiation of the separation of Internet address space into Endpoint Identifiers and Routing Locators designed by means of a network-based map-and-encap scheme. A number of other instantiations of the same general concept are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are generally NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the EID-to-RLOC mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to be able to develop concrete protocol specifications and build equipment that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the design on the LISP base protocol [1], the LISP+ALT mapping system [2], LISP Interworking [4], LISP Map Server [8], and LISP multicast [6] for these purposes, with the given references a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its documents are Experimental and labeled with the suitable disclaimers about their limitations and not fully understood implications for Internet traffic. Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG for Experimental. Mar 2010 Submit base ALT specification to the IESG for Experimental. Mar 2010 Submit the LISP Interworking specification to the IESG for Experimental. June 2010 Submit the LISP Map Server specification to the IESG for Experimental. June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG for Experimental. Jul 2010 Submit LISP for Multicast Environments to the IESG for Experimental. Jul 2010 Submit a preliminary analysis of how the LISP protocols (LISP base protocol, LISP+ALT mapping system, and LISP multicast) address the Design Goals for Scalable Internet Routing [7]. Aug 2010 Re-charter or close. Internet-Drafts: draft-farinacci-lisp-12.txt draft-farinacci-lisp-multicast-01.txt draft-fuller-lisp-alt-05.txt draft-fuller-lisp-ms-00.txt draft-lewis-lisp-interworking-02.txt Request For Comments: None References ---------- [1] Farinacci, D. et. al., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-12.txt. [2] Fuller, V., et. al., "LISP Alternative Topology (LISP-ALT)", draft-fuller-lisp-alt-05.txt [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-01.txt. [4] Lewis, D., et. al., "Interworking LISP with IPv4 and IPv6", draft-lewis-lisp-interworking-02.txt. [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map identifiers onto locators", draft-mathy-lisp-dht-00.txt. [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt. [7] T. Li, Ed., "Design Goals for Scalable Internet Routing", draft-irtf-rrg-design-goals-01, IRTF, July 2007. [8] Farinacci, D. and V. Fuller, "LISP Map Server", draft-fuller-lisp-ms-00.txt. From dromasca@avaya.com Thu Mar 5 11:54:12 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755D928C14F; Thu, 5 Mar 2009 11:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 6PpofHi5mPrn; Thu, 5 Mar 2009 11:54:11 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 8A1BF28C4FD; Thu, 5 Mar 2009 11:54:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,308,1233550800"; d="scan'208";a="163693183" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Mar 2009 14:54:40 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 05 Mar 2009 14:54:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Mar 2009 20:54:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-farrel-rtg-common-bnf-08.txt to Proposed Standard Thread-Index: AcmbaZgPIBMFAW0iQCGZHRGM/Zb6PwCYpHbA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-farrel-rtg-common-bnf-08.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 19:54:12 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-07.txt Technical Summary Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF. This document provides a formal definition of the variant of BNF that has been used (that we call Reduced BNF), and makes it available for use by new protocols. Working Group Summary This is an individual submission with AD sponsorship. It was =20 presented to the routing area open meeting. A couple of people questioned whether this was needed at all, but no one objected to the content. The IETF last call was flagged to the CCAMP,=20 MPLS, PCE and TSVWG WGs, and to the routing-discussion email list.=20 Document Quality Multiple existing routing area specifications use the subset of BNF defined in this document.=20 Personnel Ross Callon is the sponsoring AD. Adrian Farrel is the author,=20 and has been shepherding this document through the various reviews.=20 RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From joelja@bogus.com Thu Mar 5 12:37:29 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5479A3A6BAE; Thu, 5 Mar 2009 12:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 UqD+FjcALqAS; Thu, 5 Mar 2009 12:37:28 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 522D328C195; Thu, 5 Mar 2009 12:37:28 -0800 (PST) Received: from [192.103.16.237] ([192.103.16.237]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n25Kbp12071230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Mar 2009 20:37:52 GMT (envelope-from joelja@bogus.com) Message-ID: <49B0380E.6060506@bogus.com> Date: Thu, 05 Mar 2009 12:37:34 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9075/Thu Mar 5 19:37:10 2009 on nagasaki.bogus.com X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 05 Mar 2009 12:38:43 -0800 Cc: aaa-doctors@ietf.org, ops-dir@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Evaluation: draft-farrel-rtg-common-bnf-08.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 20:37:29 -0000 08 was uploaded this morning... and makes substantial changes that improve the clarify of section 2.2.4 including a change in requirements in note 2 Romascanu, Dan (Dan) wrote: > > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-07.txt > > Technical Summary > > Several protocols have been specified in the Routing Area of the IETF > using a common variant of the Backus-Naur Form (BNF) of representing > message syntax. However, there is no formal definition of this > version of BNF. > > This document provides a formal definition of the variant of BNF that > has been used (that we call Reduced BNF), and makes it available for > use by new protocols. > > Working Group Summary > > This is an individual submission with AD sponsorship. It was > presented to the routing area open meeting. A couple of people > questioned whether this was needed at all, but no one objected > to the content. The IETF last call was flagged to the CCAMP, > MPLS, PCE and TSVWG WGs, and to the routing-discussion email list. > > Document Quality > > Multiple existing routing area specifications use the subset > of BNF defined in this document. > > Personnel > > Ross Callon is the sponsoring AD. Adrian Farrel is the author, > and has been shepherding this document through the various reviews. > > RFC Editor Note > > (Insert RFC Editor Note here or remove section) > > IRTF Note > > (Insert IRTF Note here or remove section) > > IESG Note > > (Insert IESG Note here or remove section) > > IANA Note > > (Insert IANA Note here or remove section) > > > > > > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir > From dromasca@avaya.com Thu Mar 5 12:39:34 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D153A6B73; Thu, 5 Mar 2009 12:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 MqUU1zi6Dc+7; Thu, 5 Mar 2009 12:39:33 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B33B03A690A; Thu, 5 Mar 2009 12:39:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,308,1233550800"; d="scan'208";a="139387440" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Mar 2009 15:40:00 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Mar 2009 15:39:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Mar 2009 21:39:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Evaluation: draft-farrel-rtg-common-bnf-08.txt to Proposed Standard Thread-Index: Acmd0kSXgJugsShqRSORL8wNcmOV4QAADhcg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: [OPS-DIR] FW: Evaluation: draft-farrel-rtg-common-bnf-08.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 20:39:34 -0000 =20 -----Original Message----- From: Joel Jaeggli [mailto:joelja@bogus.com]=20 Sent: Thursday, March 05, 2009 10:38 PM To: Romascanu, Dan (Dan) Cc: aaa-doctors@ietf.org; ops-dir@ietf.org Subject: Re: [OPS-DIR] FW: Evaluation: draft-farrel-rtg-common-bnf-08.txt to Proposed Standard 08 was uploaded this morning... and makes substantial changes that improve the clarify of section 2.2.4 including a change in requirements in note 2 Romascanu, Dan (Dan) wrote: > =20 >=20 > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-07.txt >=20 > Technical Summary >=20 > Several protocols have been specified in the Routing Area of the IETF > using a common variant of the Backus-Naur Form (BNF) of representing > message syntax. However, there is no formal definition of this > version of BNF. >=20 > This document provides a formal definition of the variant of BNF that > has been used (that we call Reduced BNF), and makes it available for > use by new protocols. >=20 > Working Group Summary >=20 > This is an individual submission with AD sponsorship. It was =20 > presented to the routing area open meeting. A couple of people > questioned whether this was needed at all, but no one objected > to the content. The IETF last call was flagged to the CCAMP,=20 > MPLS, PCE and TSVWG WGs, and to the routing-discussion email list.=20 >=20 > Document Quality >=20 > Multiple existing routing area specifications use the subset > of BNF defined in this document.=20 >=20 > Personnel >=20 > Ross Callon is the sponsoring AD. Adrian Farrel is the author,=20 > and has been shepherding this document through the various reviews. >=20 > RFC Editor Note >=20 > (Insert RFC Editor Note here or remove section) >=20 > IRTF Note >=20 > (Insert IRTF Note here or remove section) >=20 > IESG Note >=20 > (Insert IESG Note here or remove section) >=20 > IANA Note >=20 > (Insert IANA Note here or remove section) >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir >=20 From dromasca@avaya.com Thu Mar 5 23:23:11 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C0F3A68A4; Thu, 5 Mar 2009 23:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 FxohhMJsu3YP; Thu, 5 Mar 2009 23:23:10 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E2C723A67E4; Thu, 5 Mar 2009 23:23:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,313,1233550800"; d="scan'208";a="163743746" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Mar 2009 02:23:39 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 06 Mar 2009 02:23:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Mar 2009 08:23:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for March 12, 2009 Telechat Thread-Index: Acmd8mGTQWWyMd/1QJmsvKzvIy+zuwAOajcg From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , "IETF DNS Directorate" Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for March 12, 2009 Telechat X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 07:23:11 -0000 Please find below the preliminary agenda of the 3/12 IESG telechat. Please send me you comments and concerns before 3/11 COB.=20 Thanks and Regards, Dan =20 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-behave-turn-13.txt Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) (Proposed Standard) - 1 of 9=20 Token: Magnus Westerlund o draft-ietf-avt-rtp-uemclip-04.txt RTP payload format for mU-law EMbedded Codec for Low-delay IP communication=20 (UEMCLIP) speech codec (Proposed Standard) - 2 of 9=20 Note: The document shepherd is Roni Even.=20 Token: Cullen Jennings o draft-ietf-btns-connection-latching-08.txt IPsec Channels: Connection Latching (Proposed Standard) - 3 of 9=20 Token: Tim Polk o draft-ietf-softwire-security-requirements-06.txt Softwire Security Analysis and Requirements (Proposed Standard) - 4 of 9=20 Token: Mark Townsley o draft-ietf-netconf-tls-07.txt NETCONF Over Transport Layer Security (TLS) (Proposed Standard) - 5 of 9=20 Note: Mehmet Ersue is the PROTO-shepherd=20 Token: Dan Romascanu o draft-ietf-ntp-ntpv4-proto-11.txt Network Time Protocol Version 4 Protocol And Algorithms Specification (Proposed Standard) - 6 of 9=20 Token: Mark Townsley o draft-ietf-ntp-ntpv4-mib-05.txt Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)=20 (Proposed Standard) - 7 of 9=20 Token: Mark Townsley o draft-ietf-lemonade-profile-bis-12.txt The Lemonade Profile (Proposed Standard) - 8 of 9=20 Note: Glenn Parsons is the Document Shepherd=20 Token: Chris Newman o draft-ietf-netlmm-pmipv6-heartbeat-05.txt Heartbeat Mechanism for Proxy Mobile IPv6 (Proposed Standard) - 9 of 9 =20 Token: Jari Arkko 2.1.2 Returning Item o draft-ietf-usefor-usepro-14.txt Netnews Architecture and Protocols (Proposed Standard) - 1 of 1=20 Token: Lisa Dusseault 2.2 Individual Submissions 2.2.1 New Item o draft-farrel-rtg-common-bnf-08.txt Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol=20 Specifications (Proposed Standard) - 1 of 2=20 Token: Ross Callon o draft-gulbrandsen-imap-response-codes-07.txt IMAP Response Codes (Proposed Standard) - 2 of 2=20 Note: Alexey Melnikov is document shepherd=20 Token: Chris Newman 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item NONE 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-jones-dime-3gpp-eps-command-codes-01.txt Diameter Command Code Registration for Third Generation Partnership Project=20 (3GPP) Evolved Packet System (EPS) (Informational) - 1 of 1=20 Note: IETF LC ends on 3/5. A new revised I-D will be available immediatly=20 after the Last Call.=20 Token: Dan Romascanu 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 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Locator/ID Separation Protocol (lisp) - 1 of 3 Token: Jari Arkko o Session Initiation Protocol Core (sipcore) - 2 of 3 Token: Cullen Jennings=20 o Dispatch (dispatch) - 3 of 3 Token: Cullen Jennings 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 o Network File System Version 4 (nfsv4) - 1 of 3 Token: Lars Eggert o Ad-Hoc Network Autoconfiguration (autoconf) - 2 of 3 Token: Jari Arkko o Routing Over Low power and Lossy networks (roll) - 3 of 3 Token: David Ward From dromasca@avaya.com Mon Mar 9 12:07:56 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D083A6A15; Mon, 9 Mar 2009 12:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 bGcUhof-LQUs; Mon, 9 Mar 2009 12:07:55 -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 F0A833A6BFC; Mon, 9 Mar 2009 12:07:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,330,1233550800"; d="scan'208";a="154718236" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 09 Mar 2009 15:08:10 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 09 Mar 2009 15:08: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: Mon, 9 Mar 2009 20:07:48 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-kitten-gssapi-channel-bindings-06.txt to Proposed Standard Thread-Index: AcmgvrGyvnli1WtzRxiyHUywnwHn3AAK5g9Q From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-kitten-gssapi-channel-bindings-06.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 19:07:56 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-channel-bin dings-05.txt Technical Summary This document clarifies and generalizes the Generic Security Services Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. Working Group Summary This document is a product of the kitten working group. The working group discussions were uneventful. Document Quality There are no current implementations that we are aware of. However, with the recent publication on channel binding usage, RFC5056, it is expected that this guidance will help foster such interest with vendors. Personnel Shawn M. Emery is the document shepherd for this document. Tim Polk has reviewed this document for the IESG. RFC Editor Note (Insert RFC Editor Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Mon Mar 9 12:42:12 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3074C3A6843; Mon, 9 Mar 2009 12:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 AAQY6eE3yMoJ; Mon, 9 Mar 2009 12:42:11 -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 AF9E13A6A91; Mon, 9 Mar 2009 12:42:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,330,1233550800"; d="scan'208";a="139705671" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Mar 2009 15:42:42 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 09 Mar 2009 15:42:42 -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: Mon, 9 Mar 2009 20:42:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-ccamp-path-key-ero-04.txt to Proposed Standard Thread-Index: AcmgXFKxABJtfNiWQlCHNt+J6q04kwAksyIg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-ccamp-path-key-ero-04.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 19:42:12 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-path-key-ero-03.txt Technical Summary The paths taken by Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) and embedding this subobject within the result of its path computation. This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Object (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. Working Group Summary Good consensus reported (see PROTO writeup by Deborah Brungard).=20 The draft was reviewed in last call by the CCAMP and PCE working groups, as well as IETF last call.=20 A last-minute question was raised on the number of bits assigned to the path key ID (should 16 be extended to 32). This was resolved in discussions on the PCE mailing list, and it was decided to leave it at 16 consistent with draft-ietf-pce-path-key-05.txt. Document Quality There are several interoperable implementations of=20 draft-ietf-pce-path-key-05.txt. These implementations are of=20 no value without the extensions defined in this draft (since a computed path is of no value if you can't signal it). There is one known experimental implementation of the extensions defined in this draft. Personnel Deborah Brungard is the Document Shepherd. Ross Callon is the responsible AD.=20 RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Mon Mar 9 12:45:35 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98793A6C3C; Mon, 9 Mar 2009 12:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 TRitXWzXDPd1; Mon, 9 Mar 2009 12:45:35 -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 9854F3A6AD1; Mon, 9 Mar 2009 12:45:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,330,1233550800"; d="scan'208";a="154723248" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 09 Mar 2009 15:46:08 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 09 Mar 2009 15:46:08 -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: Mon, 9 Mar 2009 20:45:46 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-atlas-icmp-unnumbered-06.txt to Proposed Standard Thread-Index: AcmgJV85nDzjfQdbQvu0Z3Gt4RbIbwAyi0kA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-atlas-icmp-unnumbered-06.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 19:45:35 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-atlas-icmp-unnumbered-04.txt Technical Summary This draft extends ICMP to provide additional diagnostic information regarding incoming and outgoing interfaces. Working Group Summary This draft has been discussed in the Internet Area mailing list and meetings; considerable discussion happened on the topic of including next-hop information. The document is an AD sponsored submission, however.=20 In January 2009, a late IPR declaration forced the draft to go back to the WG. It has now returned after no one objected in the new WGLC (after the new IPR license declaration was posted). Document Quality The document has been extensively reviewed and discussed. Personnel There is no document shepherd. The responsible AD is Jari Arkko. RFC Editor Note (Insert RFC Editor Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Wed Mar 11 11:48:24 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1653A684C; Wed, 11 Mar 2009 11:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 GYSOcdsuJ1d9; Wed, 11 Mar 2009 11:48:24 -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 7A9F53A6358; Wed, 11 Mar 2009 11:48:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,345,1233550800"; d="scan'208";a="139969633" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Mar 2009 14:48:58 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 11 Mar 2009 14:48:57 -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, 11 Mar 2009 19:48:35 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-gulbrandsen-imap-response-codes-07.txt to Proposed Standard Thread-Index: AcmieRKoVc2TojbqTUGrdF7ksHL9iAAAN1qA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-gulbrandsen-imap-response-codes-07.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 18:48:24 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gulbrandsen-imap-response-code s-07.txt' Technical Summary IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code and a human-readable text. This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting. Working Group Summary This is not a WG document. Nothing worth reporting. Document Quality The document was extensively reviewed by both IMAP client and server implementors. There are already several implementations of this document. At least 10 people have reviewed the document. Majority of posted comments were addressed in the latest revision. Personnel Alexey Melnikov is the document shepherd for this document. Chris Newman has reviewed this document for the IESG. Note to RFC Editor [pending text for secdir review, possibly for IANA question] From joelja@bogus.com Wed Mar 11 13:21:26 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7FD828C1C7; Wed, 11 Mar 2009 13:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 nYZXr-7dC4Hv; Wed, 11 Mar 2009 13:21:25 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 48C6F28C18E; Wed, 11 Mar 2009 13:21:25 -0700 (PDT) Received: from [192.103.16.144] ([192.103.16.144]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n2BKLuAJ034644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2009 20:21:56 GMT (envelope-from joelja@bogus.com) Message-ID: <49B81D55.7030009@bogus.com> Date: Wed, 11 Mar 2009 13:21:41 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94.2/9093/Wed Mar 11 15:32:37 2009 on nagasaki.bogus.com X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 12 Mar 2009 03:59:40 -0700 Cc: aaa-doctors@ietf.org, ops-dir@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Evaluation: draft-gulbrandsen-imap-response-codes-07.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 20:21:26 -0000 The security considerations note: Revealing information about a passphrase to unauthenticated IMAP clients has bad karma. I'd say it's worse than that, notably: AUTHENTICATIONFAILED doesn't reveal that much that can't already be concluded. AUTHENTICATIONFAILED Authentication failed for some reason which the server is not willing to elaborate. Typically this includes "unknown user" and "bad password". This is the same as not sending any response code, except that when a client sees AUTHENTICATIONFAILED, it knows that the problem wasn't e.g. UNAVAILABLE, so there's no point in trying the same login/password again later. C: b LOGIN "fred" "foo" S: b NO [AUTHENTICATIONFAILED] Authentication failed AUTHORIZATIONFAILED reveals that the identity is valid. The results can be used to reduce the search space for the currently in vogue brute force attempts considerably. Assuming some kind of congruence between username and email address it can also be used as a brute force address harvesting mechanism, or to generate more information about the users on a potential target. AUTHORIZATIONFAILED Authentication succeeded, but authorization failed. This is only applicable when the authentication and authorization identities are different. C: c AUTHENTICATE PLAIN [...] S: c NO [AUTHORIZATIONFAILED] No such auth-ID Expired on the other hand only reveals information to possessors of valid credentials. EXPIRED Authentication succeeded or the server didn't have the necessary data any more, but access is no longer permitted using that passphrase. The client or user should get a new passphrase. C: d login "fred" "foo" S: d NO [EXPIRED] That password isn't valid any more Romascanu, Dan (Dan) wrote: > > > > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-gulbrandsen-imap-response-code > s-07.txt' > > Technical Summary > > IMAP responses consist of a response type (OK, NO, BAD), an optional > machine-readable response code and a human-readable text. > > This document collects and documents a variety of machine-readable > response codes, for better interoperation and error reporting. > > Working Group Summary > > This is not a WG document. > Nothing worth reporting. > > Document Quality > > The document was extensively reviewed by both IMAP client and > server implementors. There are already several implementations > of this document. > > At least 10 people have reviewed the document. Majority of posted > comments were addressed in the latest revision. > > Personnel > > Alexey Melnikov is the document shepherd > for this document. Chris Newman has reviewed this document for the > IESG. > > Note to RFC Editor > > [pending text for secdir review, possibly for IANA question] > > > > > > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir > From dromasca@avaya.com Wed Mar 18 04:24:07 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483DC3A67D8; Wed, 18 Mar 2009 04:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkkLUsM0iMeG; Wed, 18 Mar 2009 04:24:06 -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 5B71C3A6A10; Wed, 18 Mar 2009 04:24:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,384,1233550800"; d="scan'208";a="140592820" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Mar 2009 07:24:46 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Mar 2009 07:24:45 -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, 18 Mar 2009 12:24:19 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [New-work] WG Review: Locator/ID Separation Protocol (lisp) Thread-Index: AcmnYffdL5f00RS9QKCVpCvU688yewAWgGnQ From: "Romascanu, Dan (Dan)" To: , , , "MIB Doctors (E-mail)" Subject: [AAA-DOCTORS] FW: [New-work] WG Review: Locator/ID Separation Protocol (lisp) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 11:24:07 -0000 =20 -----Original Message----- From: new-work-bounces@ietf.org [mailto:new-work-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Wednesday, March 18, 2009 2:38 AM To: new-work@ietf.org Subject: [New-work] WG Review: Locator/ID Separation Protocol (lisp) A new IETF working group has been proposed in the Routing Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, March 24, 2009. Locator/ID Separation Protocol (lisp) -------------------------------------------------- Last Modified: 2009-03-12 Current status: Proposed Working Group Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Mailing Lists: General Discussion: https://www.ietf.org/mailman/listinfo/lisp Description of Working Group: The IAB's October 2006 workshop on Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "Locator/Identifier separation". The basic idea behind the separation that the Internet architecture combines two functions, Routing Locators, or RLOCs (where you are attached to the network) and Endpoint Identifiers, or EIDs (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple location and identity, thus allowing for efficient aggregation of the RLOC space and providing persistent identity in the EID space. LISP supports the separation of the Internet address space into Endpoint Identifiers and Routing Locators following a network-based map-and-encap scheme (RFC 1955). It employs EIDs that represent a mixture of locators and identifiers; it could also be classified as a multi-level locator scheme. A number of other approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the EID-to-RLOC mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications). Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG as Experimental Mar 2010 Submit base ALT specification to the IESG as Experimental Mar 2010 Submit the LISP Interworking specification to the IESG as Experimental June 2010 Submit the LISP Map Server specification to the IESG as Experimental June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG as Experimental Jul 2010 Submit LISP for Multicast Environments to the IESG as Experimental Dec 2010 Submit a preliminary analysis as Informational Dec 2010 Re-charter or close. _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From dromasca@avaya.com Wed Mar 18 09:30:44 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143153A69CA; Wed, 18 Mar 2009 09:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 OzepQA2safGQ; Wed, 18 Mar 2009 09:30:43 -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 4AF923A6967; Wed, 18 Mar 2009 09:30:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,385,1233550800"; d="scan'208";a="140631222" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Mar 2009 12:31:24 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Mar 2009 12:31:22 -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, 18 Mar 2009 17:31:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Dispatch (dispatch) Thread-Index: Acmn1ywV6Rh54NU2QLC8jZ9M8PENIQAD7Zdw From: "Romascanu, Dan (Dan)" To: , , , "MIB Doctors (E-mail)" Subject: [AAA-DOCTORS] FW: WG Review: Dispatch (dispatch) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 16:30:44 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Wednesday, March 18, 2009 4:37 PM To: new-work@ietf.org Subject: WG Review: Dispatch (dispatch)=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 Wednesday, March 25, 2009. Dispatch (dispatch) -------------------------------------------------- Last Modified: 2009-03-12 Current Status: Proposed Working Group Group Description:=20 The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work. Options for handling new work include: - Assigning the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter and establishing consensus for a new WG or Exploratory Group. This option will primarily be used with fairly mature and well-defined efforts. - Rejecting and deferring work. A major objective of the DISPATCH WG is to provide timely, clear dispositions of new efforts. Where there is consensus to take on new work, the WG will strive to quickly find a home for it. Reconsideration of proposals which have failed to gather consensus will be prioritized behind proposals for new work which have not yet been considered. In general, requests for reconsideration should only be made once a proposal has been significantly revised. The DISPATCH WG will also operate as an area wide WG where ideas can be discussed that do not currently have a logical venue for the work to be done. As part of this function, the WG will evaluate SIP Event Packages that were not developed inside some other area working group. Guiding principles will include: 1. Providing a clear problem statement for proposed new work. 2. Prioritizing new efforts so that RAI does not take on more work than it can effectively complete. 3. Looking for commonalities among ongoing development efforts. Such commonalities may indicate the need to develop more general, reusable components. 4. Protecting the architectural integrity of RAI protocols and ensuring that work has general applicability. The WG may take on some of the previous work items from the SIPPING working group to allow a smooth transition. If the group decides that a particular topic needs to be addressed by a new or existing WG, this is still followed by the usual IETF chartering process, including, for instance, IETF-wide review of the proposed changes. Proposal for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. Milestones: TBD From dromasca@avaya.com Wed Mar 18 09:31:09 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510883A6A79; Wed, 18 Mar 2009 09:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 C8u8zKUsXami; Wed, 18 Mar 2009 09:31:08 -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 0DD3F3A6A6B; Wed, 18 Mar 2009 09:31:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,385,1233550800"; d="scan'208";a="165095791" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Mar 2009 12:31:51 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 18 Mar 2009 12:31:51 -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, 18 Mar 2009 17:31:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Session Initiation Protocol Core (SIPCore) Thread-Index: Acmn5t+A82ctUMGuTzqKzt5AZpBWkwAABldg From: "Romascanu, Dan (Dan)" To: , , , "MIB Doctors (E-mail)" Subject: [AAA-DOCTORS] FW: WG Review: Session Initiation Protocol Core (SIPCore) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 16:31:09 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Wednesday, March 18, 2009 6:29 PM To: new-work@ietf.org Subject: WG Review: Session Initiation Protocol Core (SIPCore)=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 Wednesday, March 25, 2009. Session Initiation Protocol Core (SIPCore) -------------------------------------------------- Current Status: Proposed Working Group Last Modified: 2009-03-12 Group Description: The Session Initiation Protocol Core (SIPCore) working group is chartered to maintain and continue the development of the core SIP specifications, currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and 3265. The SIPCore working group will concentrate on specifications that update or replace the core SIP specifications. In this context, "update" means replacing or modifying protocol elements in the above listed RFCs in ways that would affect most or all implementations of those RFCs alone. Extensions to SIP that add new functionality that would not be required of all implementations will be done outside of this WG. The process and requirements for such extensions are documented in RFC 3427bis, "Change Process for the Session Initiation Protocol". Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular: 1. Services and features are provided end-to-end whenever possible. 2. Reuse of existing Internet protocols and architectures and integrating with other Internet applications is crucial. The primary source of change requirements will be a) interoperability problems that stem from ambiguous or under-defined specification, and b) requirements from other working groups in the RAI Area. Although in general the WG will not work on extensions to SIP, it may take on some previous work items from the SIP working group to allow for a smooth transition. The adoption of new items requires explicit agreement from the AD or rechartering. Goals and Milestones: Mar 2009 Identify requirements for test matrix to move 3261 to Draft Standard Mar 2009 Essential corrections to RFC 3261 (1st batch) to IESG (PS) May 2009 Delivering request-URI and parameters to UAS via proxy to IESG (PS) May 2009 INFO package framework to IESG (PS) From dromasca@avaya.com Tue Mar 24 09:35:26 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096193A6B04 for ; Tue, 24 Mar 2009 09:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9MQ0oai0-jS for ; Tue, 24 Mar 2009 09:35:25 -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 370483A6A3C for ; Tue, 24 Mar 2009 09:35:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,413,1233550800"; d="scan'208,217";a="156300812" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 24 Mar 2009 12:36:15 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 24 Mar 2009 12:36:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AC9E.9CED15E0" Date: Tue, 24 Mar 2009 17:35:59 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reminder: AAA-Doctors Lunch Thread-Index: AcmsnpzoI6Q48Ez1TBS3yjsIWVQtUA== From: "Romascanu, Dan (Dan)" To: Subject: [AAA-DOCTORS] Reminder: AAA-Doctors Lunch X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:35:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AC9E.9CED15E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The AAA-Doctors work lunch will take place Thursday 3/26 between 11:45 = and 13:00 in Continental 7&8. Please get some quick lunch and bring it = to that room.=20 Dan ------_=_NextPart_001_01C9AC9E.9CED15E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reminder: AAA-Doctors Lunch

The AAA-Doctors work lunch will take place Thursday = 3/26 between 11:45 and 13:00 in Continental 7&8. Please get some = quick lunch and bring it to that room.

Dan

------_=_NextPart_001_01C9AC9E.9CED15E0-- From dromasca@avaya.com Tue Mar 24 16:09:49 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87443A6CEA for ; Tue, 24 Mar 2009 16:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guai7iMVLYGQ for ; Tue, 24 Mar 2009 16:09:48 -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 A0E9A3A6821 for ; Tue, 24 Mar 2009 16:09:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,415,1233550800"; d="scan'208,217";a="156340100" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 24 Mar 2009 19:10:39 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Mar 2009 19:10:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9ACD5.BB9B1BF4" Date: Wed, 25 Mar 2009 00:09:41 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Proposed Standard Thread-Index: Acms0pRpRa1xxHeuRY2dhf/n08bFhQAAwhT4 References: <20090324224634.E90A83A68D3@core3.amsl.com> From: "Romascanu, Dan (Dan)" To: Subject: [AAA-DOCTORS] FW: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:09:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ACD5.BB9B1BF4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: ietf-announce-bounces@ietf.org on behalf of The IESG Sent: Wed 3/25/2009 12:46 AM To: IETF-Announce Cc: geopriv@ietf.org Subject: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location = Objects in RADIUS and Diameter) to Proposed Standard=20 =20 The IESG has received a request from the Geographic Location/Privacy WG=20 (geopriv) to consider the following document: - 'Carrying Location Objects in RADIUS and Diameter ' as a Proposed Standard 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-04-07. Exceptionally,=20 comments may be sent to iesg@ietf.org instead. In either case, please=20 retain the beginning of the Subject line to allow automated sorting. This additional last call is being done because the previous last call failed to mention this draft contains a DOWNREF to RFC RFC 5176. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-23.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D12340&rfc_flag=3D0 The following IPR Declarations may be related to this I-D: _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ------_=_NextPart_001_01C9ACD5.BB9B1BF4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location = Objects in RADIUS and Diameter) to Proposed Standard


-----Original Message-----
From: ietf-announce-bounces@ietf.org on behalf of The IESG
Sent: Wed 3/25/2009 12:46 AM
To: IETF-Announce
Cc: geopriv@ietf.org
Subject: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location = Objects in RADIUS and Diameter) to Proposed Standard

The IESG has received a request from the Geographic Location/Privacy = WG
(geopriv) to consider the following document:

- 'Carrying Location Objects in RADIUS and Diameter '
   <draft-ietf-geopriv-radius-lo-23.txt> as a Proposed = Standard

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-04-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.

This additional last call is being done because the previous last = call
failed to mention this draft contains a DOWNREF to RFC RFC 5176.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-= 23.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtra= cker.cgi?command=3Dview_id&dTag=3D12340&rfc_flag=3D0

The following IPR Declarations may be related to this I-D:



_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.= ietf.org/mailman/listinfo/ietf-announce

------_=_NextPart_001_01C9ACD5.BB9B1BF4-- From dromasca@avaya.com Mon Mar 30 05:28:43 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79F53A69DC; Mon, 30 Mar 2009 05:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 6A+NeKL4prwC; Mon, 30 Mar 2009 05:28:43 -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 7BCC53A6A84; Mon, 30 Mar 2009 05:28:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,446,1233550800"; d="scan'208";a="141706532" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Mar 2009 08:29:37 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Mar 2009 08:29:36 -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: Mon, 30 Mar 2009 14:29:22 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-pce-global-concurrent-optimization-10.txt to Proposed Standard Thread-Index: Acmw7UH2Shw8XQq0R6uZDZn6tBVKjAARalqw From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-pce-global-concurrent-optimization-10.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 12:28:44 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-global-concurrent-opt imization-10.txt Technical Summary The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). When computing or re-optimizing the routes of a set of TE LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. Working Group Summary The WG has good consensus with no disputes or disagreements. Concerns over the impact of this work on network stability (as a result of "churn") have been addressed with suitable text=20 added to describe the concerns and advise the operator about the associated risk (see PROTO writeup by Adrian Farrel). Document Quality There are two known implementations of the protocol extensions=20 described in this document. The document has been updated in response to comments from WG discussions and IETF last call, as=20 well as Gen-Art review and in response to IANA questions.=20 Personnel Adrian Farrel is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. =20 RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Mon Mar 30 06:21:10 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5973A6D04; Mon, 30 Mar 2009 06:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 vK2UutZ0Gjbr; Mon, 30 Mar 2009 06:21:09 -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 BCE143A6D03; Mon, 30 Mar 2009 06:21:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,446,1233550800"; d="scan'208";a="141712979" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Mar 2009 09:22:04 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 30 Mar 2009 09:22:04 -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: Mon, 30 Mar 2009 15:22:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-mpls-ldp-capabilities-03.txt to Proposed Standard Thread-Index: AcmwBT+B5W2COJluTHiaeK8AeB7jpQBNTprQ From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-mpls-ldp-capabilities-03.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 13:21:10 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-capabilities-03. txt Technical Summary A number of enhancements to the Label Distribution Protocol (LDP)=20 have been proposed. Some have been implemented, and some are=20 advancing toward standardization. It is likely that additional=20 enhancements will be proposed in the future. At present, LDP has no mechanism for advertising such enhancements at LDP session=20 initialization time. There is also no mechanism to enable and=20 disable enhancements after the session is established. This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements after LDP session establishment.=20 Working Group Summary This document represents the WG consensus as a whole: the WG as=20 a whole understands and agrees with it. The document has been=20 through wg last call with good and constructive comments, it has also been reviewed by subject-matter experts who are WG members. No controvery reported (see PROTO writeup by Loa Andersson in=20 the tracker) Document Quality There is at least one known implementation. The document has been=20 well reviewed in the WG and updated based on Gen-Art comments.=20 Personnel Loa Andersson is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. RFC Editor Note (Insert RFC Editor Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Mon Mar 30 08:15:22 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC3B3A6C67; Mon, 30 Mar 2009 08:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 khtkyMcWeSX8; Mon, 30 Mar 2009 08:15:19 -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 57D6E3A6C61; Mon, 30 Mar 2009 08:15:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,446,1233550800"; d="scan'208";a="141729619" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Mar 2009 11:16:14 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 30 Mar 2009 11:16:14 -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: Mon, 30 Mar 2009 17:15:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-lemonade-streaming-10.txt to Informational RFC Thread-Index: Acmu8ufDC9AWOK2OS5qeqJjoY4mUhQCV3Evw From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-lemonade-streaming-10.txt to Informational RFC X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 15:15:22 -0000 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-09.txt Technical Summary This document describes a method for streaming multimedia attachments received by a resource constrained and/or mobile device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio e-mail content. The document describes a profile for making use of the IMAP URLAUTH extension (RFC 4467), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022). Working Group Summary There is consensus in the WG to publish this document. Document Quality Virtually all members of the Lemonade WG have reviewed the document, as well as specialized review from the SIPPING work group. The document has been checked manually and using idnits 2.11.04, and passed both checks.=20 Glenn Parsons shepherds this document, has reviewed this document, and believes that this version is ready for forwarding to the IESG for publication. Alexey Melnikov and Chris Newman have reviewed this document for the IESG. From dromasca@avaya.com Tue Mar 31 07:23:33 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080233A6A07; Tue, 31 Mar 2009 07:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 sLLStSmrH+CC; Tue, 31 Mar 2009 07:23:32 -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 14E063A69F8; Tue, 31 Mar 2009 07:23:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,453,1233550800"; d="scan'208";a="166474941" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 Mar 2009 10:24:26 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 Mar 2009 10:24: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, 31 Mar 2009 16:24:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-dhc-container-opt-05.txt to Proposed Standard Thread-Index: AcmxtSQKV6Ao2HR8Q7+Q5QGcYjUingAVyuzw From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-dhc-container-opt-05.txt to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 14:23:33 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-container-opt-05.txt Technical Summary In some DHCP service deployments, it is desirable for a DHCP server in one administrative domain to pass configuration options to a DHCP server in a different administrative domain. This DHCP option carries a set of DHCP options that can be passed from one DHCP server to another DHCP server to pass configuration information to clients served by that second DHCP server. Working Group Summary There has been consensus in the dhc WG to support the development of this document throughout the WG review process. The WG last call showed consensus to advance the document to the IESG, http://www.ietf.org/mail-archive/web/dhcwg/current/msg08858.html Issues raised during the WG last call have been addressed in the most recent revision of the document. Document Quality A version of this option was developed as part of the CableLabs eRouter DHCP Container vendor-identifying vendor-specific option, and defined in "CableLabs' DHCP Options Registry". There is wider applicability of this option beyond cable service provider deployments, so the dhc WG was asked to develop an Internet Standard specification of the option. Personnel Document Shepherd is John Brozowski. Responsible Area Director is Jari Arkko. RFC Editor Note (Insert RFC Editor Note here or remove section) IRTF Note (Insert IRTF Note here or remove section) IESG Note (Insert IESG Note here or remove section) IANA Note (Insert IANA Note here or remove section)