From dromasca@avaya.com Fri Sep 4 01:07: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 4504E3A699C; Fri, 4 Sep 2009 01:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxsn5rTHV2vv; Fri, 4 Sep 2009 01:07:56 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id AFAD53A696F; Fri, 4 Sep 2009 01:07:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,330,1249272000"; d="scan'208";a="182259055" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Sep 2009 04:04:28 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 04 Sep 2009 04:04:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Sep 2009 10:04:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for September 10, 2009 Telechat thread-index: Acos2JL3tiXjifHhRu+pDxAR6CzQmwAXTzJQ From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for September 10, 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, 04 Sep 2009 08:07:58 -0000 Please find below the preliminary agenda for the 9/10 IESG telechat. Please send me your comments, questions and concerns about the documents in review and the proposed WG charters before 9/9 COB.=20 Thanks and Regards, Dan =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2.1 WG Submissions 2.1.1 New Item o draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-10.txt Transmission of IP over Ethernet over IEEE 802.16 Networks (Proposed Standard) - 1 of 9=20 Note: Gabriel Montenegro is the Document Shepherd for this document.=20 Token: Ralph Droms o draft-ietf-mpls-3209-patherr-05.txt Node behavior upon originating and receiving Resource ReserVation Protocol=20 (RSVP) Path Error message (BCP) - 2 of 9=20 Note: This document should be processed in a batch with=20 draft-ietf-mpls-gmpls-lsp-reroute and draft-ietf-mpls-soft-preemption..=20 draft-ietf-mpls-soft-preemption should be read as the last of the batch.=20 Token: Adrian Farrel o draft-ietf-mpls-soft-preemption-18.txt MPLS Traffic Engineering Soft Preemption (Proposed Standard) - 3 of 9 Note: This document should be processed in a batch with=20 draft-ietf-mpls-gmpls-lsp-reroute and draft-ietf-mpls-3209-patherr.. draft-ietf-mpls-soft-preemption should be read as the last of the batch.=20 Token: Adrian Farrel o draft-ietf-mpls-gmpls-lsp-reroute-04.txt PathErr Message Triggered MPLS and GMPLS LSP Reroute (Proposed Standard) -=20 4 of 9=20 Note: This document should be processed in a batch with=20 draft-ietf-mpls-soft-preemption and draft-ietf-mpls-3209-patherr..=20 draft-ietf-mpls-soft-preemption should be read as the last of the batch.=20 Token: Adrian Farrel o draft-ietf-dime-pmip6-03.txt Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor=20 Interaction with Diameter Server (Proposed Standard) - 5 of 9=20 Token: Dan Romascanu o draft-ietf-dime-nai-routing-03.txt Diameter User-Name and Realm Based Request Routing Clarifications (Proposed=20 Standard) - 6 of 9=20 Token: Dan Romascanu o draft-ietf-mip4-generic-notification-message-09.txt Generic Notification Message for Mobile IPv4 (Proposed Standard) - 7 of 9=20 Note: Pete McCann (pete.mccann@motorola.com) is the document shepherd. =20 Token: Jari Arkko o draft-ietf-pcn-baseline-encoding-05.txt Baseline Encoding and Transport of Pre-Congestion Information (Proposed=20 Standard) - 8 of 9=20 Note: Steven Blake (sblake@petri-meat.com) is the document shepherd. Token: Lars Eggert o draft-ietf-pwe3-segmented-pw-13.txt Segmented Pseudowire (Proposed Standard) - 9 of 9=20 Note: Stewart Bryant (stbryant@cisco.com) is the document shepherd.=20 Token: Ralph Droms 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-rosenberg-sip-app-media-tag-03.txt A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application=20 Sub-Types (Proposed Standard) - 1 of 1=20 Token: Robert Sparks 2.2.2 Returning Item o draft-housley-iesg-rfc3932bis-08.txt IESG Procedures for Handling of Independent and IRTF Stream Submissions=20 (BCP) - 1 of 1=20 Note: There is no document shepherd=20 Token: Jari Arkko 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-sipping-service-identification-03.txt Identification of Communications Services in the Session Initiation=20 Protocol (SIP) (Informational) - 1 of 3=20 Token: Robert Sparks o draft-ietf-hip-nat-traversal-08.txt Basic HIP Extensions for Traversal of Network Address Translators=20 (Experimental) - 2 of 3=20 Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document=20 shepherd.=20 Token: Ralph Droms o draft-ietf-eai-imap-utf8-07.txt IMAP Support for UTF-8 (Experimental) - 3 of 3=20 Note: Harald Alvestrand has agreed to shepherd=20 the document.. Please note that SecDir and GenArt review comments are addressed via RFC Editor notes.. Also note that the reference to obsolete=20 RFC 1341 is intentional. The name parameter was defined in RFC 1341 across=20 all media types. The subsequent version of MIME (2045/2046) deprecated it.=20 Token: Alexey Melnikov 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-drage-sipping-service-identification-03.txt A Session Initiation Protocol (SIP) Extension for the Identification of=20 Services (Informational) - 1 of 1=20 Token: Robert Sparks 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item NONE 3.3.2 Returning Item o draft-ford-behave-top-07.txt Unintended Consequence of two NAT deployments with Overlapping Address =20 Space (Informational) - 1 of 1=20 Token: Magnus Westerlund 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Virtual World Region Agent Protocol (vwrap) - 1 of 1 Token: Alexey Melnikov 4.1.2 Proposed for Approval o SIP Common Log Format (sipclf) - 1 of 1 Token: Robert Sparks 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o IP Flow Information Export (ipfix) - 1 of 3 Token: Dan Romascanu o Security Issues in Network Event Logging (syslog) - 2 of 3 Token: Pasi Eronen o Network Endpoint Assessment (nea) - 3 of 3 Token: Tim Polk 4.2.2 Proposed for Approval o DNS Extensions (dnsext) - 1 of 1 Token: Ralph Droms From dromasca@avaya.com Tue Sep 15 11:27:45 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 5A94F3A6812; Tue, 15 Sep 2009 11:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKg3jGUlg6ex; Tue, 15 Sep 2009 11:27:44 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 8EDB43A679F; Tue, 15 Sep 2009 11:27:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,391,1249272000"; d="scan'208";a="173448901" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 15 Sep 2009 14:28:29 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Sep 2009 14:28:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Sep 2009 20:28:24 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Network Endpoint Assessment (nea) thread-index: Aco2LpgSKBPWUx0uQu28bH95F1+CDgAA7HOw From: "Romascanu, Dan (Dan)" To: , , Subject: [AAA-DOCTORS] FW: WG Review: Recharter of Network Endpoint Assessment (nea) 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, 15 Sep 2009 18:27:45 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, September 15, 2009 9:00 PM To: new-work@ietf.org Subject: WG Review: Recharter of Network Endpoint Assessment (nea)=20 A modified charter has been submitted for the Network Endpoint Assessment (nea) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, September 22, 2009. Network Endpoint Assessment (nea) ------------------------------------------------------------ Last Modified: 2009-08-24 Additional information is available at tools.ietf.org/wg/nea Chair(s): * Stephen Hanna (shanna@juniper.net) * Susan Thomson (sethomso@cisco.com) Security Area Director(s): * Tim Polk (tim.polk@nist.gov) * Pasi Eronen (pasi.eronen@nokia.com) Security Area Advisor: * Tim Polk (tim.polk@nist.gov) Mailing Lists: General Discussion: nea@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/nea Archive: http://www.ietf.org/mail-archive/web/nea Description of Working Group: Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring compliance to an organization's posture policy and optionally restricting access until the endpoint has been updated to satisfy the posture requirements. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. Note that an endpoint that is deemed compliant may still be vulnerable to threats that may exist on the network. The network may thus continue to be exposed to such threats as well as the range of other threats not addressed by maintaining endpoint compliance. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge that software installed to protect the machine (e.g. patch management software, anti-virus software, host firewall software, host intrusion protection software or any custom software) is enabled and up-to-date. An endpoint supporting NEA protocols can be queried for posture information. An organization may make a range of policy decisions based on the posture of an endpoint. NEA is not intended to be prescriptive in this regard. Supported deployment scenarios will include, but are not limited to, providing normal access regardless of compliance result along with any recommendations for remediation ("advisory mode"), as well as providing restricted access sufficient for remediation purposes and any essential services until an endpoint is in compliance ("mandatory mode"). Specifying mechanisms for providing restricted access is outside the scope of the NEA WG. Since NEA involves many different components from different vendors, interoperability is important. The NEA working group will develop standard protocols at the following three layers in the architecture: the Posture Attribute protocol (PA), the Posture Broker protocol (PB), and the Posture Transport protocol (PT). PA and PB will be designed to support a variety of PT protocols. Together, PA, PB and the mandatory to implement PT protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another. Since there are already several non-standard protocols at these layers, the NEA working group will consider these existing protocols as candidates for the standard protocols. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed. The NEA Requirements document will include a problem statement, definition of terms, requirements for the PA and PB protocols, and an overall security analysis. It will also include generic requirements for the protocol transporting PA, PB: the Posture Transport protocol (PT). The PA (Posture Attribute) protocol consists of posture attributes that are carried between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. A base set of standard posture attributes will be specified that are expected to address many common posture policies. Vendor-specific attributes will also be supported; vendor-specific attributes will be identified by a private enterprise number and a vendor assigned value. Vendors are strongly encouraged to document vendor-specific attributes in an RFC. The NEA WG will investigate the use of a standard syntax for all attributes. The PB (Posture Broker) protocol aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. The PT (Posture Transport) protocol carries the PB protocol. The expectation is that the PT protocol is a shim protocol that defines an encapsulation of PB within an existing standard transport protocol.=20 Existing standard transport protocols will be leveraged to the extent possible. The NEA WG may specify more than one PT to meet the requirements of different deployment scenarios. The NEA WG will specify at least one mandatory to implement PT protocol. PT protocol specifications must describe any limitations that they impose on PB and PA (e.g. half duplex). One commonly discussed issue with NEA systems is how to handle compromised endpoints, whose reports of their own posture may not be accurate. Detecting or handling such endpoints is out of scope of the NEA WG. Work on PA will focus on attributes useful for assessing posture of those endpoints reporting accurate information. However, the protocols developed by the NEA WG must be designed to accommodate emerging technologies for identifying and dealing with lying endpoints. Note that NEA is not chartered to develop standard protocols for remediation. NEA is intended to be used with new or existing tools that can be used in the absence of NEA. NEA is applicable to computing enterprise environments, where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. NEA applicability and security considerations will be described in the appropriate NEA documents. Further work in the NEA WG will be considered via the rechartering process after the completion of these milestones. Milestones Done At IETF 67, discuss issues with NEA Requirements I-D Done Submit first draft of NEA Requirements I-D Done At IETF 68, resolve any open issues with requirements I-D Done Submit revised NEA requirements I-D Done Discuss NEA Requirements I-D Done Submit revised NEA requirements I-D Done WGLC on NEA requirements I-D Done At IETF 69, resolve any remaining issues raised at Last Call Done Submit revised NEA requirements I-D Done Submit NEA Requirements I-D to the IESG for IETF Last Call as=20 Informational RFC Done Submit revised NEA requirements I-D Done Proposals for PA and PB due Done Review and resolve proposals at IETF 71 Done Post first WG version of PA and PB Done Post second version of PA and PB Done Resolve issues at IETF 72 Done Post third version of PA and PB Done WGLC on PA and PB Done Resolve WGLC comments at IETF 73 Done Post fourth version of PA and PB Done IETF LC for PA and PB Done IESG considers PA and PB for Proposed Standard Sep 2009 Call for proposals for the PT protocol(s) Oct 2009 Proposals due Nov 2009 Review PT protocol proposals at IETF 76 Decide how to resolve differences and issues Dec 2009 Post first WG version of PT protocol(s) Jan 2010 Review and resolve issues Feb 2010 Post second WG version of PT protocol(s) Mar 2010 WG Last Call on PT protocol(s) Resolve issues from WG Last Call at IETF 77 Apr 2010 Post third WG version of PT protocol(s) May 2010 Submit PT protocol(s) to IESG From dromasca@avaya.com Thu Sep 17 01:38:38 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 EC9653A67E3; Thu, 17 Sep 2009 01:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Frjxq+VyaOWV; Thu, 17 Sep 2009 01:38:38 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id AC59928C12F; Thu, 17 Sep 2009 01:38:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,402,1249272000"; d="scan'208";a="183607540" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Sep 2009 04:39:28 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Sep 2009 04:39:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Sep 2009 10:39:04 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom 2009-10: FINAL Call for Nominations, Local Office hours, Nominee Questionnaires thread-index: Aco3RBVohLPLHLLKTMmfTZpXjGQXMAALh7lA From: "Romascanu, Dan (Dan)" To: , , "MIB Doctors (E-mail)" , , Subject: [AAA-DOCTORS] FW: Nomcom 2009-10: FINAL Call for Nominations, Local Office hours, Nominee Questionnaires 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, 17 Sep 2009 08:38:39 -0000 =20 -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, September 17, 2009 6:07 AM To: IETF Announcement list Cc: ietf@ietf.org Subject: Nomcom 2009-10: FINAL Call for Nominations, Local Office hours, Nominee Questionnaires=20 Hi all, This is the Final Call for Nominations - the nominations period ends in two days on Sept 18, 2009. =20 We do not have a sufficient number of nominations for the following AD positions: APP, OPS, RAI and SEC In addition, we have not received responses from almost half of the nominees. I will be sending reminders for all the outstanding nominations. =20 We need Community input and participation!!! We cannot properly execute the task of selecting the best candidates for these positions with so few accepted nominations. So, please consider making nominations for the open positions, in particular those for which we have so few nominations - it takes just a few minutes of your time. Right now, we just need the names/email addresses - we'll be soliciting feedback later.=20 Also, please note that although draft-dawkins-nomcom-openlist-06 has been approved, the 2009-10 Nomcom is NOT operating under these new guidelines. As well as the reminder for the call for nominations, this email also serves as a reminder for: 2) Local Office Hours through Sept. 25, 2009.=20 3) Questionnaires due from Nominees on Sept. 25, 2009. Best Regards, Mary Barnes nomcom-chair@ietf.org mary.h.barnes@gmail.com mary.barnes@nortel.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D 1) Call for Nominations ------------------------ The nomination period ends in less than 2 days on Sept. 18th, 2009. We appreciate the folks that have taken the time to make nominations thus far. But, we do need more nominations. Please use the online tool to nominate - it's fast, easy and secure: https://wiki.tools.ietf.org/group/nomcom/09/nominate Details on the open positions, as well as other details and options for making nominations are available on the Nomcom homepage: https://wiki.tools.ietf.org/group/nomcom/09/ You will have the opportunity to provide additional feedback later and it's important to consider that not all nominees will be able to accept the nomination.=20 2) Local office hours ----------------------- In order facilitate additional feedback, the Nomcom has decided to make themselves available for office areas at various geographic locations from September 8th through Sept. 25th.=20 Below please find the list of locations where Nomcom members will be available for these f2f meetings . Unless dates are identified below, the Nomcom member is generally available for part of the day during the weeks of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than English in which the Nomcom member is fluent are identfied. =20 Please contact a Nomcom member in a specific geographic location to arrange a convenient meeting time and place. Most Nomcom members are flexible as to meeting locations - i.e., we can travel to your office, meet at our offices or somewhere in between. =20 As a reminder folks can always contact any Nomcom member to provide feedback at anytime - i.e., you don't need to participate in these f2f sessions to provide feedback.=20 Belgium:=20 Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 21-25) (Languages: French)=20 Boston, Mass, USA: =20 Stephen Kent - kent@bbn.com (Sept 16-18)=20 Boulder, CO, USA:=20 Wassim Haddad - wmhaddad@gmail.com (Sept 14-18) Dallas/Ft. Worth, TX, USA: =20 Mary Barnes - mary.h.barnes@gmail.com=20 Lucy Yong - lucyyong@huawei.com (Languages: Chinese)=20 Helsinki, Finland:=20 Simo Veikkolainen - simo.veikkolainen@nokia.com (Languages: Finnish) =20 Ithaca, NY, USA:=20 Scott Brim - scott.brim@gmail.com Montevideo, Uruguay:=20 Roque Gagliano - roque@lacnic.net (Sept 14-18, 21-25) (Languages: Spanish, Portuguese)=20 Montreal, Quebec, Canada=20 Wassim Haddad - wmhaddad@gmail.com (Sept 8-11) -- Can also be available in Ottawa if folks are interested=20 Paris, France:=20 Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 15-18) (Languages: French) San Diego, CA, USA:=20 Randall Gellens - rg+ietf@qualcomm.com =20 Dave Crocker - dcrocker@bbiw.net (Sept 16-18) Silicon Valley/SF Bay, CA, USA:=20 Dave Crocker - dcrocker@bbiw.net (Sept 8-11, Sept 14-15, Sept 21-25) =20 Dorothy Gellert - Dorothy.gellert@gmail.com 3) Questionnaires available for nominees:=20 For folks that have been notified that they have been nominated for any of the positions, the questionnaires are available on the Nomcom09 tools website: https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire The questionnaires are due no later than Sept. 25th, 2009. If you have any questions or concerns with meeting the deadline, please let me know. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From dromasca@avaya.com Fri Sep 18 01:29:42 2009 Return-Path: X-Original-To: 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 F0CC63A67A6; Fri, 18 Sep 2009 01:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLDjXpJ6jq8q; Fri, 18 Sep 2009 01:29:41 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id B0C163A6839; Fri, 18 Sep 2009 01:29:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,408,1249272000"; d="scan'208";a="183750642" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Sep 2009 04:30:34 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Sep 2009 04:30:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Sep 2009 10:30:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for September 24, 2009 Telechat thread-index: Aco35edZ6VsRglumS6Oh+LfzONcXcwAU/Ckw From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for September 24, 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, 18 Sep 2009 08:29:43 -0000 Please find below the preliminary agenda of the 9/24 IESG telechat. Please let me know if there are any comments, questions or concerns before 9/23 COB.=20 Thanks and Regards, Dan ............................... 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-calsify-2446bis-09.txt iCalendar Transport-Independent Interoperability Protocol (iTIP) (Proposed=20 Standard) - 1 of 6=20 Token: Lisa Dusseault o draft-ietf-dnsext-dnssec-rsasha256-14.txt Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for=20 DNSSEC (Proposed Standard) - 2 of 6=20 Note: Andrew Sullivan (ajs@shinkuro.com) is the document shepherd.=20 Token: Ralph Droms o draft-ietf-tls-extractor-07.txt Keying Material Exporters for Transport Layer Security (TLS) (Proposed =20 Standard) - 3 of 6=20 Token: Pasi Eronen o draft-ietf-dime-pmip6-03.txt Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor=20 Interaction with Diameter Server (Proposed Standard) - 4 of 6=20 Token: Dan Romascanu o draft-ietf-pkix-ta-format-03.txt Trust Anchor Format (Proposed Standard) - 5 of 6=20 Token: Tim Polk o draft-ietf-pmol-sip-perf-metrics-04.txt SIP End-to-End Performance Metrics (Proposed Standard) - 6 of 6=20 Note: Vijay Gurbani is the PROTO-shepherd=20 Token: Dan Romascanu 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-peterson-rai-rfc3427bis-03.txt Change Process for the Session Initiation Protocol (SIP) (Proposed=20 Standard) - 1 of 1=20 Token: Russ Housley 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-simple-interdomain-scaling-analysis-08.txt Presence Interdomain Scaling Analysis for SIP/SIMPLE (Informational) - 1 of=20 4=20 Note: Ben Campbell is document shepherd=20 Token: Robert Sparks o draft-ietf-roll-building-routing-reqs-07.txt Building Automation Routing Requirements in Low Power and Lossy Networks=20 (Informational) - 2 of 4=20 Note: JP Vasseur (jvasseur@cisco.com) is the document shepherd=20 Token: Adrian Farrel o draft-ietf-opsawg-operations-and-management-09.txt Guidelines for Considering Operations and Management of New Protocols and=20 Protocol Extensions (Informational) - 3 of 4=20 Token: Dan Romascanu o draft-ietf-pkix-other-certs-05.txt Other Certificates Extension (Experimental) - 4 of 4=20 Token: Tim Polk 3.1.2 Returning Item o draft-ietf-sipcore-presence-scaling-requirements-02.txt Scaling Requirements for Presence in SIP/SIMPLE (Informational) - 1 of 1=20 Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document=20 shepherd.=20 Token: Robert Sparks 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-seokung-msec-mikey-seed-03.txt Addition of the new values to use the SEED Cipher Algorithm in the=20 Multimedia Internet KEYing (MIKEY) (Informational) - 1 of 3=20 Note: Brian Weis (bew@cisco.com) is the document shepherd.=20 Token: Tim Polk o draft-harkins-emu-eap-pwd-06.txt EAP Authentication Using Only A Password (Informational) - 2 of 3=20 Token: Russ Housley o draft-solinas-rfc4753bis-00.txt ECP Groups for IKE and IKEv2 (Informational) - 3 of 3=20 Token: Tim Polk 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item NONE 3.3.2 Returning Item NONE 3.3.3 For Action o draft-templin-ranger-07.txt Routing and Addressing in Next-Generation EnteRprises (RANGER)=20 (Informational) - 1 of 3=20 Token: Jari Arkko o draft-levy-sip-diversion-10.txt Diversion Indication in SIP (Historic) - 2 of 3=20 Token: Robert Sparks o draft-irtf-mobopts-mmcastv6-ps-08.txt Multicast Mobility in MIPv6: Problem Statement and Brief Survey=20 (Informational) - 3 of 3=20 Note: Rajeev Koodli (rajeev.koodli@gmail.com) is the document shepherd.=20 Token: Russ Housley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Multipath TCP (mptcp) - 1 of 1 Token: Magnus Westerlund 4.1.2 Proposed for Approval o Virtual World Region Agent Protocol (vwrap) - 1 of 1 Token: Alexey Melnikov 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o Behavior Engineering for Hindrance Avoidance (behave) - 1 of 2 Token: Magnus Westerlund o Access Node Control Protocol (ancp) - 2 of 2 Token: Ralph Droms 4.2.2 Proposed for Approval o IP Flow Information Export (ipfix) - 1 of 2 Token: Dan Romascanu o Network Endpoint Assessment (nea) - 2 of 2 Token: Tim Polk From dromasca@avaya.com Tue Sep 29 09:32:59 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 F0B693A6AF9; Tue, 29 Sep 2009 09:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzGK6zl9Qn17; Tue, 29 Sep 2009 09:32:58 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 392A83A6AF5; Tue, 29 Sep 2009 09:32:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,474,1249272000"; d="scan'208";a="175036969" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 29 Sep 2009 12:34:18 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 29 Sep 2009 12:34:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Sep 2009 18:33:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) thread-index: AcpBIlaYkEgMSq1dST+bC93f3ZD0hwAADTwQ From: "Romascanu, Dan (Dan)" To: , , "MIB Doctors (E-mail)" , Subject: [AAA-DOCTORS] FW: WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) 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, 29 Sep 2009 16:33:00 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, September 29, 2009 6:30 PM To: ietf-announce@ietf.org Cc: behave@ietf.org; dthaler@microsoft.com; dwing@cisco.com Subject: WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave)=20 A modified charter has been submitted for the Behavior Engineering for Hindrance Avoidance (behave) working group in the Transport Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, October 6, 2009. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- Current Status: Active Working Group Last Modified: 2009-09-09 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/behave Chair(s): * Dan Wing * Dave Thaler Transport Area Director(s): * Magnus Westerlund * Lars Eggert Transport Area Advisor: * Magnus Westerlund Mailing Lists: General Discussion: behave@ietf.org To Subscribe: behave-request@ietf.org In Body: In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group: The behavior of NATs varies from one implementation to another. As a result it is very difficult for applications to predict or discover the behavior of these devices. Predicting and/or discovering the behavior of NATs is important for designing application protocols and NAT traversal techniques that work reliably in existing networks. This situation is especially problematic for end-to-end applications where one or both end-points are behind a NAT, such as multiuser games, interactive multimedia and P2P download. The working group documents best current practices to enable NATs to function in as deterministic a fashion as possible. The NAT behavior practices will be application independent. This has already completed for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any additional protocol deemed necessary to handle. The WG has documented approaches for characterizing and testing NAT devices. BEHAVE will develop protocol-independent toolkits usable by application protocols for NAT traversal. The WG has already produced an update of the binding discovery protocol STUN. It will now produce a relay protocol that focuses on security and is usable with both IPv4 and IPv6, and capable of relaying between the two IP versions. Due to the WG's experience with translators and their behavior it has been given the following tasks to help encourage migration to IPv6. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. The BEHAVE WG will design solutions for the following six translation scenarios; other scenarios are out of scope: 1. An IPv6 network to IPv4 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv6 network of arbitary size. Port translation is necessary on the IPv4 side for efficient IPv4 address usage. 2. IPv6 Internet to an IPv4 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv4 network using either private or public IPv4 addresses. This scenario has different constraints compared to (1), e.g. the IPv4 hosts that are to be reachable over IPv6 can be enumerated. Therefore, the WG should attempt to design a simpler solution with less impact on applications. 3. An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. 4. IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. 5. An IPv6 network to an IPv4 network, i.e., perform translation between IPv6 and IPv4 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). 6. An IPv4 network to an IPv6 network, i.e., perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The parts of ICMP that can be translated are also required to work across a translation solution. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation. The translators should support multicast traffic and its control traffic (IGMP and MLD) across them, both Single Source Multicast (SSM) and Any Source Multicast (ASM). However, the WG may determine that it becomes too complex or too difficult to realize with maintained functionality, for some or all cases of multicast functionality. Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications. DNS is a crucial part in making a large number of applications work across a translator. Thus the solution to the above translation cases shall include recommendations for DNS. If additional DNS functionality is needed, it may be developed. Any DNS extensions must be developed together with the DNSEXT WG, including issuing a joint WG last call for any documents. The WG needs to determine the best method for providing address space to a translator in the different deployment cases and documenting the pros and cons of the suggested approaches. The WG is to seek input from the Routing, Operations and Internet areas. Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution. Goals and Milestones: Done Submit BCP that defines unicast UDP behavioral requirements=20 for NATs to IESG Done Submit a BCP that defines TCP behavioral requireents for NATs=20 to IESG Done Submit a BCP that defines ICMP behavioral requirements for=20 NATs to IESG Done Submit informational that discusses current NAT traversal=20 techniques used by applications Done Submit BCP that defines multicast UDP Done Submit revision of RFC 3489 to IESG behavioral requirements for=20 NATs to IESG Done Submit informational document for rfc3489bis test vectors Done Submit experimental document that describes how an application can determine the type of NAT it is behind Done Submit BCP document for DCCP NAT behavior Dec 2009 Submit to IESG: SCTP NAT behavior (BCP) Done Submit to IESG: relay protocol (std) Done Determine relative prioritization of the four translation=20 cases. Documented in IETF74 minutes. Sep 2009 Submit to IESG: relaying of a TCP bytestream (std) Dec 2009 Submit to IESG: IPv6 relay protocol (std) Done Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components. Documented in IETF74 minutes. Done Submit to IESG: TURN-URI document (std) Dec 2009 Submit to IESG: framework for IPv6/IPv4 translation (info) Dec 2009 Submit to IESG: stateless IPv6/IPv4 translation (std) Dec 2009 Submit to IESG: stateful IPv6/IPv4 translation (std) Dec 2009 Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) Jan 2010 Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) Jan 2010 Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) Mar 2010 Submit to IESG: large scale NAT requirements (BCP) From dromasca@avaya.com Tue Sep 29 09:47:02 2009 Return-Path: X-Original-To: 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 4724128C18C; Tue, 29 Sep 2009 09:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBXqC9s2y3VP; Tue, 29 Sep 2009 09:47:01 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 10E3728C18B; Tue, 29 Sep 2009 09:47:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,474,1249272000"; d="scan'208";a="185019141" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 29 Sep 2009 12:48:20 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 29 Sep 2009 12:48:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Sep 2009 18:47:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Access Node Control Protocol (ancp) thread-index: AcpBJGUUmmNRPf6ZSoKlwYDd3d6rLwAAA06g From: "Romascanu, Dan (Dan)" To: , , "MIB Doctors (E-mail)" , Subject: [AAA-DOCTORS] FW: WG Review: Recharter of Access Node Control Protocol (ancp) 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, 29 Sep 2009 16:47:02 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, September 29, 2009 6:45 PM To: ietf-announce@ietf.org Cc: matthew.bocci@alcatel-lucent.com; wdec@cisco.com; ancp@ietf.org Subject: WG Review: Recharter of Access Node Control Protocol (ancp)=20 A modified charter has been submitted for the Access Node Control Protocol (ancp) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, October 6, 2009. Access Node Control Protocol (ancp) ----------------------------------- Current Status: Active Working Group Chair(s): Wojciech Dec Matthew Bocci Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Technical Advisor(s): Dan Romascanu Mailing Lists: General Discussion: ancp@ietf.org To Subscribe: ancp-request@ietf.org In Body: In Body: subscribe your_email_address Archive: =20 http://www.ietf.org/mail-archive/web/ancp/current/maillist.html Description of Working Group:=20 Purpose:=20 The purpose of the ANCP WG is to standardize an IP-based Access Node Control Protocol (ANCP) for use in service provider Digital Subscriber Line (DSL) and Passive Optical Network (PON) access and aggregation networks. ANCP operates between an Access Node (AN) and Network Access Server (NAS). Necessary Terminology:=20 Access Node (AN) - Network device, usually located at a service provider central office or street cabinet, that terminates access loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is usually comprised of an Optical Network Termination (ONT) / Optical Network Unit (ONU) and an Optical Line Termination (OLT). Network Access Server (NAS) - Network device which aggregates multiplexed Subscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subscriber policy enforcement and QoS. This is often referred to as a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A detailed definition of the NAS is given in RFC2881. Goals:=20 ANCP is intended to address the requirement for a bidirectional, IP- based, control protocol that operates across multiple types (i.e., Ethernet, ATM) of DSL and PON access and aggregation networks. The goal of an ANCP message exchange is to convey status and control information between one or more ANs and one or more NASs without going through intermediate element managers. The ANCP WG will address the following four use-cases:=20 1. Dynamic Access Loop Attributes Various queuing and scheduling mechanisms are used in access networks to avoid congestion while dealing with multiple flows and distinct QoS profiles. Communicating the access-loop status, attributes and current DSL synchronization rate between the AN and Subscriber up to the NAS is desirable, particularly when the NAS is providing QoS for individual flows and subscribers. ANCP will provide a mechanism to communicate dynamic access-loop attributes from the AN to the NAS. 2. Access Loop Configuration In additional to reporting Access Loop characteristics from the AN to the NAS, ANCP will allow a NAS to send loop-specific configuration information to an AN based on the results of subscriber authentication and authorization (e.g., after AAA responses have been received at the NAS). 3. Remote Connectivity Test Traditional DSL access and aggregation networks employ point-to-point ATM circuits between the AN and NAS for each subscriber, allowing troubleshooting of the local loop from the NAS via ATM OAM tools. With the increasing deployment of Ethernet in the access and aggregation network, operators require consistent methods to test and troubleshoot connectivity for mixed Ethernet and ATM access networks (including the local loop). ANCP will allow a remote procedure for a local loop connectivity test to be triggered from the NAS with results communicated back to the NAS. 4. Multicast When multicast replication for subscriber-bound traffic is performed at the AN, it offloads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership. Non-Goals:=20 ANCP is an IP-based protocol that operates between the AN and NAS. It will not address setup or configuration of circuits or connections in the access and aggregation network itself. The focus of this WG is on one very specific application space. While the design of the protocol must be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of service provider broadband (such as xDSL, xPON) access and aggregation networks. Security:=20 The ANCP working group will provide a threat analysis and address the associated security aspects of the control protocol. Resiliency and Scalability:=20 A graceful restart mechanism will be defined to enable the protocol to be resilient to network failures between the AN and NAS. Scalability at the NAS is of primary concern, as it may be aggregating traffic from a large number of ANs, which in turn may be serving a large number of Subscribers. ANCP traffic should not become a denial of service attack on the NAS control plane. Format of messages, pacing, transport over UDP or TCP, etc. will be considered with this in mind. For reasons of aggregation network scalability, some use cases require that aspects of NAS or AN functionality may be distributed in nodes in the aggregation network. In these cases, ANCP can run between these nodes. Deliverables:=20 The working group will define a basic framework and requirements document intended for Informational publication, focusing on the four use-cases outlined in this charter. This document will include a security threat analysis and associated requirements. The WG will then investigate and define a solution for an IP based control protocol meeting these requirements. There are early interoperable implementations of an ANCP-like protocol which are based on an extended subset of the GSMPv3 protocol. This running code will be the the starting point for the working group solution, and will be abandoned only if the WG determines it is not adequate to meet requirements going forward. Coordination with other Working Groups or Organizations:=20 The working group will coordinate with the ADSL MIB working group so the management framework and MIB modules are consistent for DSL access environments. The working group will re-use, as far as possible, standard MIB modules that have already been defined. The remote connectivity test use case may require coordination with ITU-T Ethernet OAM and PON work and with IEEE 802.1ag. Goals and Milestones:=20 Done Accept WG I-D for ANCP Framework and Requirements=20 Done Accept WG I-D for Access Node Control Protocol (ANCP)=20 Done Accept WG ID for Security Threats analysis=20 Done Accept WG I-D for ANCP MIB=20 Done Security Threats Analysis last call=20 Done Framework and Requirements last call=20 Done Accept WG I-D for ANCP Multicast Extensions Nov 2009 Accept WG I-D for ANCP applicability to PON=20 Jan 2010 Access Node Control Protocol (ANCP) Last Call=20 Jan 2010 ANCP Multicast Extensions last call Jan 2010 ANCP MIB Last Call=20 Apr 2010 ANCP applicability to PON last call Jul 2010 Re-charter or conclude Working Group From dromasca@avaya.com Tue Sep 29 10:07:11 2009 Return-Path: X-Original-To: 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 8FBD83A698B; Tue, 29 Sep 2009 10:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogrKgVtm-nXi; Tue, 29 Sep 2009 10:07:10 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 5E6AD3A68DB; Tue, 29 Sep 2009 10:07:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,474,1249272000"; d="scan'208";a="158325423" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 Sep 2009 13:08:27 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Sep 2009 13:08:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Sep 2009 19:08:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Multipath TCP (mptcp) thread-index: AcpBJnt923x603VCRr+L1+2J0hJkWQAAOBzw From: "Romascanu, Dan (Dan)" To: , , "MIB Doctors (E-mail)" , Subject: [AAA-DOCTORS] FW: WG Review: Multipath TCP (mptcp) 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, 29 Sep 2009 17:07:11 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, September 29, 2009 7:00 PM To: ietf-announce@ietf.org Cc: multipathtcp@ietf.org Subject: WG Review: Multipath TCP (mptcp)=20 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, October 6, 2009. Multipath TCP (mptcp) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Current Status: Proposed Working Group Last updated: 2009-09-28 Chair(s): =20 * To be decided Transport Area Director(s): * Magnus Westerlund * Lars Eggert Transport Area Advisor: * Magnus Westerlund Mailing List: To subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp Archive: http://www.ietf.org/mail-archive/web/multipathtcp/ Description of Working Group: The Multipath TCP (MPTCP) working group develops mechanisms that add the capability of simultaneously using multiple paths to a regular TCP session. The primary output of the group will be the protocol extensions needed to deploy MPTCP, and adaptations to congestion control to safely support multipath resource sharing. Initially the WG will only produce documents that are experimental or informational.=20 Key goals for MPTCP are: to be deployable and usable without significant changes to existing Internet infrastructure; to be usable by unmodified applications; and to be stable and congestion-safe over the wide range of existing Internet paths. That will include handling MTU discovery on a per path basis and NAT interactions. The design's success in meeting the goals should be determined through experiments.=20 However, it is expected that some results from large scale experiments can only be achievable after the publication of the initial design.=20 The working group will provide a modular architecture that is designed to be easily extensible and adaptable. In particular, the congestion control mechanism is separated from the mechanisms for identifying and using multiple paths. The working group will focus on a solution requiring modification of both peers. One or both peers are expected to have multiple addresses, which often results in different network paths that are at least partially divergent. However, multiple addresses, even on different network interfaces, are no guarantee that the paths are divergent at all. The design needs to address the issues associated with fully or partially joint paths and shared bottlenecks. The design should allow for future extensions to handle cases where path diversity is attempted through other means than using different addresses. The design must also consider what happens when end-point pairs become unavailable during an ongoing session, especially pairs used to establish connections between additional end-point pairs.=20 Whilst MPTCP will require modifications to the TCP stack at both the peers, all existing applications should be able to use the new MPTCP stack without modification and gain benefits from multipath usage. The impact on different classes of applications will be considered and documented. An extended API will be defined to allow applications to express particular preferences for how MPTCP operates, and to get additional information about MPTCP-specific run-time events.=20 The WG will carefully analyze and address in the appropriate protocol documents all new security threats introduced by MPTCP. The following items will be worked on: a. An architectural framework for congestion-dependent multipath transport protocols. This is an overview document which tracks the technical documents, describing how the modular components fit together, and will describe the motivations and the general approach that should be followed to enable congestion-dependent multipath transport. It will also analyze how MPTCP interacts with existing infrastructure elements and other address agility mechanisms, such as Mobile IP, HIP and SHIM6. The results of any experiment performed during the development should also be included or referenced in this document.=20 b. A security threat analysis for multipath TCP. The ability to change the addresses used during a TCP session opens up new types of vulnerabilities and attacks. These and their mitigations will be documented.=20 c. A coupled multipath-aware congestion control algorithm. This algorithm is the multipath equivalent of SACK/NewReno congestion control. As experience is gathered from implementations of various congestion control algorithms, it is expected that the working group will be rechartered to pursue additional work in these areas.=20 d. Extensions to current TCP to support multi-addressed multipath TCP.=20 This covers all on-the-wire changes required to create a two-ended MPTCP solution using multiple addresses at one or both ends. It will be designed in a modular fashion to allow alternative address management schemes to be explored in future. This document will also include a basic security model. e. An application considerations document, presenting the impacts that MPTCP may have on applications, such as performance changes, and including an extended API describing how applications can exploit additional features of multipath transport. While MPTCP needs to be usable without any application changes, this API should be an optional extension that provides access to multipath information and enables control over the usage of multipath.=20 Where appropriate, this group is expected to coordinate with, and will use input from, the MIF working group to support the use of multiple interfaces. Goals and Milestones: Mar 2010 - Established WG consensus on the Architecture Aug 2010 - Submit to IESG architectural guidelines and security threat analysis as informational RFC(s) Mar 2011 - Submit to IESG basic coupled congestion control as an=20 experimental RFC Mar 2011 - Submit to IESG protocol specification for MPTCP extensions=20 as an experimental RFC Mar 2011 - Submit to IESG application considerations and API as an=20 informational RFC Mar 2011 - Recharter or close WG