From dromasca@avaya.com Wed Apr 1 07:51:39 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 B2E993A68BC; Wed, 1 Apr 2009 07:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 3EHHL6GD-iJM; Wed, 1 Apr 2009 07:51:38 -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 1B4633A67DF; Wed, 1 Apr 2009 07:51:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,306,1235970000"; d="scan'208";a="141972335" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Apr 2009 10:52:36 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 01 Apr 2009 10:52:35 -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, 1 Apr 2009 16:52:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Last Call: draft-ietf-isms-transport-security-model (Transport Security Model for SNMP) to Proposed Standard Thread-Index: Acmy2A+xmZ7Ls6AwRDeWGZFrxJdboQAAVvEw From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , Subject: [AAA-DOCTORS] FW: [Isms] Last Call: draft-ietf-isms-transport-security-model (Transport Security Model for SNMP) 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, 01 Apr 2009 14:51:39 -0000 =20 -----Original Message----- From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of The IESG Sent: Wednesday, April 01, 2009 5:41 PM To: IETF-Announce Cc: isms@ietf.org Subject: [Isms] Last Call: draft-ietf-isms-transport-security-model (Transport Security Model for SNMP) to Proposed Standard The IESG has received a request from the Integrated Security Model for SNMP WG (isms) to consider the following document: - 'Transport Security Model for SNMP ' 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-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-m odel-12.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 15419&rfc_flag=3D0 The following IPR Declarations may be related to this I-D: _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From dromasca@avaya.com Wed Apr 1 07:51:39 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 E4E333A67DF for ; Wed, 1 Apr 2009 07:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 U8DG5EbrysP0 for ; Wed, 1 Apr 2009 07:51:39 -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 51B013A686E for ; Wed, 1 Apr 2009 07:51:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,306,1235970000"; d="scan'208";a="141972338" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Apr 2009 10:52:36 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 01 Apr 2009 10:52: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: Wed, 1 Apr 2009 16:52:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-isms-tmsm (Transport Subsystem for the Simple Network Management Protocol (SNMP)) to Proposed Standard Thread-Index: Acmy1/sOOLPH5mroSAKG4wA0jg1bewAAX5ZQ From: "Romascanu, Dan (Dan)" To: Subject: [AAA-DOCTORS] FW: Last Call: draft-ietf-isms-tmsm (Transport Subsystem for the Simple Network Management Protocol (SNMP)) 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, 01 Apr 2009 14:51:40 -0000 =20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Wednesday, April 01, 2009 5:40 PM To: IETF-Announce Cc: isms@ietf.org Subject: Last Call: draft-ietf-isms-tmsm (Transport Subsystem for the Simple Network Management Protocol (SNMP)) to Proposed Standard=20 The IESG has received a request from the Integrated Security Model for SNMP WG (isms) to consider the following document: - 'Transport Subsystem for the Simple Network Management Protocol (SNMP) ' 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-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-16.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 13828&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 From dromasca@avaya.com Thu Apr 2 01:33: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 419563A6982; Thu, 2 Apr 2009 01:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 Bt4pNSwJCX9d; Thu, 2 Apr 2009 01:33:31 -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 2CC1F3A6931; Thu, 2 Apr 2009 01:33:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,313,1235970000"; d="scan'208";a="157260837" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 02 Apr 2009 04:34:31 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Apr 2009 04:34:31 -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, 2 Apr 2009 10:34:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-tcpm-tcpsecure-11.txt to Proposed Standard Thread-Index: AcmzbC37CrLIo+XnQvO+yNvARB9p1QAAZF+w From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-tcpm-tcpsecure-11.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, 02 Apr 2009 08:33:32 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-11.txt Technical Summary: This document examines the fact that long term TCP connections that have well known source and destination addresses are vulnerable to attack by the injection of bogus RST, SYN or data packets by guessing sequence numbers that fall into the current window of the connection. It provides three mitigation strategies that can be used to reduce the chance that an attacker can be successful with these spoofed segments. Working Group Summary The working group saw that there was a fair amount of experience with these mitigation strategies; two of them are very simple, and one is a bit more involved. The WG felt that this document is a SHOULD for devices that are susceptible to these types of attacks, and a MAY for other implementations. These changes are not needed for correct TCP operation, but reduce the chance that a spoofed packet will be accepted as valid. Document Quality The document was reviewed for quality by a fair number of TCPM WG members. There already exist several implementations of these strategies, and there are not any known interoperability issues with TCP implementations that do not have these changes. Personnel David Borman (david.borman@windriver.com) is the document shepherd. Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG. From dromasca@avaya.com Thu Apr 2 01:35:05 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 B7FA23A6A05; Thu, 2 Apr 2009 01:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 5fcIR9iaQrn5; Thu, 2 Apr 2009 01:35:05 -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 F32BF3A68F9; Thu, 2 Apr 2009 01:34:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,313,1235970000"; d="scan'208";a="142047621" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Apr 2009 04:35:59 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Apr 2009 04:35:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 10:35:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-dccp-serv-codes-08.txt to Proposed Standard Thread-Index: Acmzba4XOTITjqtVTFmFe9w4oYWYXgAAEU6A From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-dccp-serv-codes-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, 02 Apr 2009 08:35:05 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dccp-serv-codes-08.txt Technical Summary This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of a Service Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g. network address translators and firewalls). This document updates the specification provided in RFC 4340. Working Group Summary The WG consensus process for this document was uneventful. Document Quality There are existing implementations of DCCP that utilise Service Codes. Some implementors were involved in the WG discussion. Compliance of the =20 implementation with the final Spec. has not been verified. No interops were performed. Personnel Lars Eggert (lars.eggert@nokia.com) reviewed this document for the IESG. From dromasca@avaya.com Fri Apr 3 02:04: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 CD94A3A6968; Fri, 3 Apr 2009 02:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 eGwB7aZWSH85; Fri, 3 Apr 2009 02:04:21 -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 9CAC23A69DB; Fri, 3 Apr 2009 02:04:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,318,1235970000"; d="scan'208";a="166838090" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Apr 2009 05:05:23 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 03 Apr 2009 05:05: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: Fri, 3 Apr 2009 11:05:20 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for April 9, 2009 Telechat Thread-Index: Acmz3y3SSoSLlC+ORC+4RbrHrPD4QwAW3lGw From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , , Cc: Ronald Bonica Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for April 9, 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, 03 Apr 2009 09:04:22 -0000 Please find below the preliminary agenda of the 4/9 telechat. Please send your comments and concerns until Wednesday 4/8 the latest. Also note that several Working Groups are on the agenda of the telechat for discussions and approval.=20 Please copy Ron on your mails. I will be missing this telechat because of a short vacation (4/7 to 4/12).=20 Dan 2.1 WG Submissions 2.1.1 New Item o draft-ietf-nsis-ntlp-19.txt GIST: General Internet Signalling Transport (Proposed Standard) - 1 of 9=20 Note: Please check your comment field so that it doesn't contain old text!=20 RE-evaluate your ABSTAIN positions. All that stays in ABSTAIN please indicate in the comment field that you have performed this re-evaluation.=20 Pleas also include some motivation behind your decision.=20 Token: Magnus Westerlund o draft-ietf-behave-turn-13.txt Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) (Proposed Standard) - 2 of 9=20 Token: Magnus Westerlund o draft-ietf-mpls-ldp-capabilities-03.txt LDP Capabilities (Proposed Standard) - 3 of 9=20 Token: Ross Callon o draft-ietf-kitten-gssapi-channel-bindings-06.txt Clarifications and Extensions to the GSS-API for the Use of Channel=20 Bindings (Proposed Standard) - 4 of 9=20 Note: proto writeup received...=20 Token: Tim Polk o draft-ietf-softwire-security-requirements-07.txt Softwire Security Analysis and Requirements (Proposed Standard) - 5 of 9=20 Token: ? o draft-ietf-ntp-ntpv4-proto-11.txt Network Time Protocol Version 4 Protocol And Algorithms Specification (Proposed Standard) - 6 of 9=20 Token: ? 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: ? o draft-ietf-ccamp-path-key-ero-04.txt RSVP Extensions for Path Key Support (Proposed Standard) - 8 of 9=20 Token: Ross Callon o draft-ietf-pce-global-concurrent-optimization-10.txt Path Computation Element Communication Protocol (PCEP) Requirements and=20 Protocol Extensions In Support of Global Concurrent Optimization (Proposed=20 Standard) - 9 of 9=20 Token: Ross Callon 2.1.2 Returning Item o draft-ietf-ippm-duplicate-07.txt A One-Way Packet Duplication Metric (Proposed Standard) - 1 of 1=20 Token: Lars Eggert 2.2 Individual Submissions 2.2.1 New Item NONE 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-lemonade-streaming-10.txt Streaming Internet Messaging Attachments (Informational) - 1 of 1=20 Note: Glenn Parsons is document shepherd=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 NONE 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 o draft-despres-6rd-02.txt IPv6 Rapid Deployment on IPv4 infrastructures (6rd) (Informational) - 1 of=20 1=20 Token: Jari Arkko 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Multiple Interfaces (mif) - 1 of 1 Token: Jari Arkko 4.1.2 Proposed for Approval o Locator/ID Separation Protocol (lisp) - 1 of 3 Token: Jari Arkko o Session Initiation Protocol Core (sipcore) - 2 of 3 Token: Cullen Jennings o Dispatch (dispatch) - 3 of 3 Token: Cullen Jennings From dromasca@avaya.com Sun Apr 5 08:05:20 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 D41643A6887; Sun, 5 Apr 2009 08:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=-0.209, 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 qfShY9tJmxZj; Sun, 5 Apr 2009 08:05:19 -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 2395A3A6A80; Sun, 5 Apr 2009 08:05:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,326,1235970000"; d="scan'208";a="157540896" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 05 Apr 2009 11:06:23 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Apr 2009 11:06: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: Sun, 5 Apr 2009 17:06:20 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-despres-6rd-02.txt to Informational RFC Thread-Index: Acm1tArk3D6wpho9S7Op3YPLk9p6iAAS90UQ From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-despres-6rd-02.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: Sun, 05 Apr 2009 15:05:20 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-despres-6rd-02.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. Working Group Summary This is an independent submission via the RFC Editor. Document Quality A French service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided quasi-native IPv6, under the only condition that they activate it. A large fraction of Google's IPv6 end users come from this ISP. The document has a number of issues that would have to be addressed if this were a standards track RFC. In particular, concerns have been raised about the implied large ISP allocation size. However, given that this is a documentation of a deployed mechanism it makes more sense to document the mechanism and its chosen tradeoffs; possible better designs should be addressed in future IETF work in the space. Personnel The responsible Area Director is Jari Arkko. RFC Editor Note The IESG finds response #2 from Section 3 of RFC 3932 appropriate, i.e. the IESG thinks that this work is related to IETF work done in a number of WGs, including V6OPS, SOFTWIRE, and BEHAVE, but this does not prevent publishing. In particular, we find that the relatively large deployment this mechanism has justifies documentation as an RFC. IESG Note Note #2 from Section 4 of RFC 3932 should be used. Or, if the new headers&boilerplates and rfc3932bis process is approved at the time of the publication of this RFC, no IESG note will be necessary. IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Sun Apr 5 08:53:52 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 470073A677D; Sun, 5 Apr 2009 08:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 55SyoSl2DZSl; Sun, 5 Apr 2009 08:53:51 -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 7F1143A6A11; Sun, 5 Apr 2009 08:53:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,326,1235970000"; d="scan'208";a="142295078" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Apr 2009 11:54:52 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 05 Apr 2009 11:54: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: Sun, 5 Apr 2009 17:54:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internal WG Review: Multiple InterFaces (mif) Thread-Index: Acmz1F1hFAnboVueQ+yBKi2Ssry2+gCMmUIg From: "Romascanu, Dan (Dan)" To: , , Subject: [AAA-DOCTORS] FW: Internal WG Review: Multiple InterFaces (mif) 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: Sun, 05 Apr 2009 15:53:52 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Thursday, April 02, 2009 11:47 PM To: iesg@ietf.org; iab@iab.org Subject: Internal WG Review: Multiple InterFaces (mif)=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 Multiple InterFaces (mif) ------------------------------------------------ Last Modified: 2009-04-02 Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: TBD Mailing Lists: General Discussion: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: Many hosts have the ability to connect to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host connected to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when multiple configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. A number of operating systems have implemented various techniques to deal with multiple interfaces. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues surrounding the use of multiple interfaces on hosts, document existing practice, and make recommendations about best current practice. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/weak models (RFC 1122), address selection (RFC 3484), DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Milestones: May 2009 WG chartered July 2009 Initial draft on problem statement adopted by the WG September 2009 Initial draft on existing practices adopted by the WG Jan 2010 Initial best current practices draft adopted by the WG March 2010 Problem statement draft submitted to the IESG for publication as an Informational RFC July 2010 Existing practices draft submitted to the IESG for publication as an Informational RFC September 2010 Best current practices draft submitted to the IESG for publication as a BCP October 2010 Recharter or close From dromasca@avaya.com Sun Apr 5 08:54:15 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 BC4DD3A6943; Sun, 5 Apr 2009 08:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 w9hwrzTg-cIg; Sun, 5 Apr 2009 08:54:14 -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 A497C3A677D; Sun, 5 Apr 2009 08:54:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,326,1235970000"; d="scan'208";a="166993029" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Apr 2009 11:55:19 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Apr 2009 11:55:18 -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: Sun, 5 Apr 2009 17:54:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internal WG Review: Network-Based Mobility Extensions (NETEXT) Thread-Index: Acm0b7XO21panpLQSTGLQHr/gU2npABlyLMg From: "Romascanu, Dan (Dan)" To: , , Subject: [AAA-DOCTORS] FW: Internal WG Review: Network-Based Mobility Extensions (NETEXT) 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: Sun, 05 Apr 2009 15:54:15 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Friday, April 03, 2009 6:18 PM To: iesg@ietf.org; iab@iab.org Subject: Internal WG Review: Network-Based Mobility Extensions (NETEXT)=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 Network-Based Mobility Extensions (NETEXT) --------------------------------------------- Last Modified: 2009-04-03 Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: TBD Mailing Lists: http://www.mobileip.jp/mailman/listinfo/netext Description of Working Group: Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable. Proxy Mobile IPv6 has been incorporated into a number of products and deployments are starting. Certain deployment considerations, including localized routing and bulk refresh of lifetime are already emerging. The working group will focus on the following topics relevant for network-based mobility: Localized Routing: a specification for routing traffic between the MAG(s) without involving the LMA. That is, allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. Applications such as voice can benefit from the reduced latency. Hosts are not affected, as they still send and receive their packets via the MAG. Bulk Refresh: a specification of improving the signaling load for binding lifetime refresh. The current specifications call for the handling of each mobility session independent of each other. When a large number of hosts are served by a single MAG, a periodic refresh of the binding lifetimes can lead to a signaling storm. The purpose of the Bulk Refresh feature is to construct a protocol feature that allows such refreshes to occur on a per-MAG basis. LMA Redirection: a specification for allowing an LMA to redirect a MAG to another LMA. This is primarily needed as a way to perform load balancing, and is complementary to the initial LMA discovery work in the NETLMM WG. The proposed activity will be complementary to the existing IETF Working Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will also act as the primary forum where new extensions on top of the Proxy Mobile IPv6 protocol can be developed. The addition of such new extensions to the working group involves addition of the extension to this charter through the normal rechartering process. Milestones May 2009 WG chartered July 2009 Initial WG draft on Bulk Refresh September 2009 Initial WG draft on LMA Redirection November 2009 Initial WG draft on Route Optimization December 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC January 2009 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC April 2010 Submit Route Optimization to IESG for publication as a Proposed Standard RFC From dromasca@avaya.com Mon Apr 6 08:46:54 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 A5EEE3A6CC3; Mon, 6 Apr 2009 08:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 eROKZVUpr1a0; Mon, 6 Apr 2009 08:46:49 -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 1B8A03A6CCA; Mon, 6 Apr 2009 08:46:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,331,1235970000"; d="scan'208";a="167081670" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Apr 2009 11:47:49 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Apr 2009 11:47:49 -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, 6 Apr 2009 17:47:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-pana-statemachine-10.txt to Informational RFC Thread-Index: Acm2uWqVZ00DuEumQW2fUzfg9ecixQAFYCqA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-pana-statemachine-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, 06 Apr 2009 15:46:54 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-statemachine-10.txt Technical Summary This document defines the state machines for Protocol Carrying Authentication for Network Access (PANA) [RFC5191]. There are state machines for the PANA client (PaC) and for the PANA Authentication Agent (PAA). Each state machine is specified through a set of variables, procedures and a state transition table. Working Group Summary The WG has reviewed this document at length. It has also been presented and discussed at several WG meetings. Two WG last calls have also been run on it. The WG is satisfied with the quality of the document and there is consensus on publishing it. Document Quality Implemenations of PANA protocol itself exist. This I-D is intended to be published as an Informational RFC. It captures the state machine of the PANA protocol. The document was revised per AD review comments in March 2009. Personnel The responsible Area Director is Jari Arkko. The document shepherd is Basavaraj Patil. 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 Apr 13 01:51:05 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 983293A67AE; Mon, 13 Apr 2009 01:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 ZbpY2zp4vbOu; Mon, 13 Apr 2009 01:51:04 -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 321E23A6D16; Mon, 13 Apr 2009 01:50:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,179,1238990400"; d="scan'208";a="167691405" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Apr 2009 04:52:06 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Apr 2009 04:52:06 -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, 13 Apr 2009 10:52:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-mipshop-rfc5268bis-01.txt to Proposed Standard Thread-index: Acm8EX8pZ3qU7QueSpKZfnH/Fx5w4gAA1HhA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-mipshop-rfc5268bis-01.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, 13 Apr 2009 08:51:05 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mipshop-rfc5268bis-01.txt Technical Summary This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care-of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP (VoIP). This documents updates the packet formats for the Handover Initiate (HI) and Handover Acknowledgement (HAck) messages to Mobility Header Type. Working Group Summary This is a quick re-issue of the RFC for FMIP, based on discussion in the WG that resulted in the desire to change the carrier protocol from ICMP to MH. The change was initiated by the 3GPP2 community who are the primary users of this protocol. It was viewed as a possible change given the current deployment situation; later this change might have been impossible. Document Quality There are multiple implementations of the FMIPv6 protocol. There are also some folks wanting to deploy this protocol for fast PMIPv6 handovers. Personnel Document shepherd: Vijay Devarapalli Responsible AD: 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) From dromasca@avaya.com Mon Apr 13 02:19: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 8CEBB3A6D1D; Mon, 13 Apr 2009 02:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 8J9Sl6ooldcH; Mon, 13 Apr 2009 02:19: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 A86563A6B6E; Mon, 13 Apr 2009 02:19:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,179,1238990400"; d="scan'208";a="167692638" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Apr 2009 05:20:11 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Apr 2009 05:20: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, 13 Apr 2009 11:20:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-mipshop-mos-dhcp-options-13.txt to Proposed Standard Thread-index: Acm8Fx3vbeK6iztDQE6qISO6XRTGkQAAbx2Q From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-mipshop-mos-dhcp-options-13.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, 13 Apr 2009 09:19:02 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mos-dhcp-options- 13.txt Technical Summary The document defines the necessary Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of domain name or IP addresses that can be mapped to servers providing IEEE 802.21 type of Mobility Services [MSFD]. These Mobility Services are used to assist an MN in handover preparation (network discovery) and handover decision (network selection). The services addressed in this document are the Media Independent Handover Services defined in [IEEE802.21]. Working Group Summary This is a product of the MIPSHOP WG. There has also been considerable discussion in the DHC WG about the way this draft used or uses options. The resulting document is not unanimously supported, but represents the rough consensus. Document Quality There are no known implementations or vendor plans to implement the specification. Personnel Document shepherd: Vijay Devarapalli Responsible AD: 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) From acmorton@att.com Mon Apr 13 05:56:18 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 DC9FA3A6D78; Mon, 13 Apr 2009 05:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.683 X-Spam-Level: X-Spam-Status: No, score=-105.683 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 M5uTG+9-ZCEQ; Mon, 13 Apr 2009 05:56:18 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id E9C103A6D76; Mon, 13 Apr 2009 05:56:17 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-13.tower-161.messagelabs.com!1239627447!16336628!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 8389 invoked from network); 13 Apr 2009 12:57:27 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-13.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Apr 2009 12:57:27 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3DCvQTk024549; Mon, 13 Apr 2009 08:57:27 -0400 Received: from alph001.aldc.att.com (alph001.aldc.att.com [135.53.7.26]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3DCvPUu024530; Mon, 13 Apr 2009 08:57:26 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id n3DCvPgG008848; Mon, 13 Apr 2009 08:57:25 -0400 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id n3DCvIuP008616; Mon, 13 Apr 2009 08:57:18 -0400 Message-Id: <200904131257.n3DCvIuP008616@alph001.aldc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090413125717gw1000u6a4e>; Mon, 13 Apr 2009 12:57:17 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Apr 2009 08:57:17 -0400 To: "Romascanu, Dan (Dan)" , , From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Mon, 13 Apr 2009 07:39:14 -0700 Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Evaluation: draft-ietf-mipshop-mos-dhcp-options-13.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, 13 Apr 2009 12:56:18 -0000 Dan, With: At 05:20 AM 4/13/2009, Romascanu, Dan (Dan) wrote: >... >Working Group Summary > > This is a product of the MIPSHOP WG. There has also been > considerable discussion in the DHC WG about the way this > draft used or uses options. The resulting document is > not unanimously supported, but represents the rough > consensus. > >Document Quality > > There are no known implementations or vendor plans to implement > the specification. If there will be no implementations, then there are no operational issues. But seriously, perhaps the status should be Experimental (or Historic, if appropriate). There must be a fairly interesting back-story on this that I'm not aware of. Editorial nits: The draft has margin problems, usually at the end of a section the text indent moves to zero spaces (should be 3). Al From dromasca@avaya.com Mon Apr 13 09:14:50 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 79D383A6E8F; Mon, 13 Apr 2009 09:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 ddNV8dUJGOSU; Mon, 13 Apr 2009 09:14:49 -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 75E693A6EBC; Mon, 13 Apr 2009 09:14:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,180,1238990400"; d="scan'208";a="167727824" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Apr 2009 12:16:00 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Apr 2009 12:15:59 -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, 13 Apr 2009 18:15:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-pce-monitoring (A set of monitoring tools for Path Computation Element based Architecture) to Proposed Standard Thread-index: Acm8T/bwOPRdVPpRT2+Hli/A4MIktQAAxi0g From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Last Call: draft-ietf-pce-monitoring (A set of monitoring tools for Path Computation Element based Architecture) 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, 13 Apr 2009 16:14:50 -0000 =20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Monday, April 13, 2009 6:51 PM To: IETF-Announce Cc: pce@ietf.org Subject: Last Call: draft-ietf-pce-monitoring (A set of monitoring tools for Path Computation Element based Architecture) to Proposed Standard=20 The IESG has received a request from the Path Computation Element WG (pce) to consider the following document: - 'A set of monitoring tools for Path Computation Element based=20 Architecture ' 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-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 16456&rfc_flag=3D0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From dromasca@avaya.com Tue Apr 14 03:29:25 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 F309C3A6D3E; Tue, 14 Apr 2009 03:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 dF7URTdsUy+7; Tue, 14 Apr 2009 03:29:24 -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 1D3333A69A2; Tue, 14 Apr 2009 03:29:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,183,1238990400"; d="scan'208";a="167809076" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Apr 2009 06:30:20 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Apr 2009 06:30: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, 14 Apr 2009 12:30:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-ipfix-exporting-type-03.txt to Proposed Standard Thread-index: Acm84+jmhrVOULfkTyW8hEljSws7ygACAhzg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-ipfix-exporting-type-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: Tue, 14 Apr 2009 10:29:25 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-exporting-type-02.t xt Technical Summary This document describes an extension to IPFIX to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise- specific Information Elements, facilitating interoperability and reusability among a wide variety of applications and tools. Working Group Summary This document started out as a section in the 'IPFIX File' draft; it was split out because it is useful in other contexts than files of IPFIX data. There was considerable mailing-list discussion on the best ways to do this, it took several months for all the issues to be resolved. Discussion ended late in June 08. The final version of this draft (July 08) resolved issues raised in discussion. The WG has reached a clear consensus on this draft. Document Quality This document has been reviwed by Paul Aitken and Gerhard Muenz; their reviews prompted discussion on the list. It has also been reviewed by the WG chairs. It describes a set of new IPFIX Information Elements, but does not make any changes to the IPFIX protocol. Personnel Nevil Brownlee is the Document Shepherd. Dan Romascanu is the Responsible Area Director. [TBD] is the IANA Expert Reviewer.=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 Tue Apr 14 03:31: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 3F5683A6D8B; Tue, 14 Apr 2009 03:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 ZBVHeSB4hBrg; Tue, 14 Apr 2009 03:31:37 -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 23B823A67AA; Tue, 14 Apr 2009 03:31:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,183,1238990400"; d="scan'208";a="143012765" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Apr 2009 06:32:43 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Apr 2009 06:32: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: Tue, 14 Apr 2009 12:32:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-ipfix-file-03.txt to Proposed Standard Thread-index: Acm84ld8F1SVV9zFRQOER6eXXQzMpAACe5Qg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-ipfix-file-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: Tue, 14 Apr 2009 10:31:38 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-file-03.txt Technical Summary This document describes a file format for the storage of flow data based upon the IPFIX Protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. Working Group Summary Work started on this document in 2006, and has gone through several revisions in response to mailing list discussion. Originally it included the material about 'exporting type information,' but the WG split it out into a seperate RFC to make it more easily accessible for other uses. The WG has reached a clear consensus on this draft. Document Quality This document has been reviwed by Benoit Claise, Paul Aitken, Andrew Johnson, and Gerhard Muenz, as well as by the WG chairs. Vijay K. Gurbani reviewed the document on behaf of GenART. It specifies a file format for IPFIX data, making the point that this is simply another data transport for IPFIX. It does not make any changes to the IPFIX protocol. Personnel Nevil Brownlee is the Protocol Shepherd, Dan Romascanu is the shepherding AD. 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 Tue Apr 14 03:33: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 B5D8E3A677C; Tue, 14 Apr 2009 03:33:10 -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 OvELCLi3bZc1; Tue, 14 Apr 2009 03:33:10 -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 D52BD3A6B09; Tue, 14 Apr 2009 03:33:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,183,1238990400"; d="scan'208";a="167809497" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Apr 2009 06:34:21 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Apr 2009 06:34:20 -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, 14 Apr 2009 12:33:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-dime-mip6-split-16.txt to Proposed Standard Thread-index: Acm84L+KOk0sLOUPTYOkj8buf0/A3QAC7aRQ From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-dime-mip6-split-16.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, 14 Apr 2009 10:33:10 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-16.txt Technical Summary This document specifies the interactions between the Mobile IP Home Agent and the Diameter server (AAA) in the case where the network access service and the mobility service is not in the same administrative domain. The purpose of the interactions is to bootstrap the mobile node from the MSP as part of the authentication and/or authorization process. The document defines new diameter applications to support IKEv2 and MIPv6 authentication protocol. It defines diameter messages, AVPs and command codes to carry the authentication, authorization and bootstrapping attributes. Working Group Summary There was consensus in the WG to publish the document. Document Quality The document has been sent for review to MEXT. This document is part of the solution for Mobile IPv6 bootstrapping problem defined in RFC 4640. It has received extensive reviews from DIME WG members. Personnel Victor Fajardo is the document shepherd, 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 Tue Apr 14 08:39: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 DC9F93A6931; Tue, 14 Apr 2009 08:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=1.087, BAYES_00=-2.599, GB_I_LETTER=-2] 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 Et4AjB47ywsX; Tue, 14 Apr 2009 08:39:06 -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 EE58D3A6E36; Tue, 14 Apr 2009 08:39:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,186,1238990400"; d="scan'208";a="167847821" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Apr 2009 11:40:15 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 14 Apr 2009 11:40:15 -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, 14 Apr 2009 17:39:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-geopriv-radius-lo-23.txt to Proposed Standard Thread-index: Acm9FYtXX5hm4NqvQNuu9D2Ix15NDgAAZeCg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-geopriv-radius-lo-23.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, 14 Apr 2009 15:39:07 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, April 14, 2009 6:26 PM To: Internet Engineering Steering Group Subject: Evaluation: draft-ietf-geopriv-radius-lo-23.txt to Proposed Standard=20 -------- Evaluation for draft-ietf-geopriv-radius-lo-23.txt can be found at https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=3Dview_id&dTag= =3D 12340&rfc_flag=3D0=20 Last Call to expire on: 2009-04-07 Please return the full line with your position. Yes No-Objection Discuss Abstain Jari Arkko [ X ] [ ] [ ] [ ] Ron Bonica [ ] [ ] [ ] [ ] Ross Callon [ ] [ X ] [ ] [ ] Ralph Droms [ ] [ ] [ ] [ ] Lisa Dusseault [ ] [ ] [ ] [ ] Lars Eggert [ ] [ ] [ X ] [ ] Pasi Eronen [ ] [ ] [ ] [ ] Adrian Farrel [ ] [ ] [ ] [ ] Russ Housley [ ] [ X ] [ . ] [ ] Cullen Jennings [ X ] [ ] [ ] [ ] Alexey Melnikov [ ] [ ] [ ] [ ] Tim Polk [ ] [ X ] [ . ] [ ] Dan Romascanu [ ] [ X ] [ . ] [ ] Robert Sparks [ ] [ ] [ ] [ ] Magnus Westerlund [ ] [ X ] [ ] [ ] "Yes" or "No-Objection" positions from 2/3 of non-recused ADs, with no "Discuss" positions, are needed for approval. DISCUSSES AND COMMENTS: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jari Arkko: Comment [2008-07-17]: I have reviewed the specification and the last call discussion, and I believe the document is ready to be approved. I think the authors have struck the right balance between keeping the location information opaque vs. allowing servers to make authorization decisions IF they need to do it. A few minor comments. Section 4.7: The numerical value representing FUTURE_REQUESTS indicates that the RADIUS client MUST provide future Access-Requests with the same information as returned in the initial Access-Request message. To avoid confusion, please change s/future Access-Requests/future Access-Requests for the same session/ Security Considerations say: Confidentiality protection is not only a property required by this document, it is also required for the transport of keying material in the context of EAP authentication and authorization. Hence, this requirement is, in many environments, already fulfilled. Heh. Or at least the requirement is already present for other reasons in many environments. Fulfillment is another question... I'm not asking for any change here. Lars Eggert: Discuss [2008-07-11]: Section 4.7., paragraph 8: > If the RADIUS server does not send a Requested-Location-Info > Attribute then the RADIUS client MUST NOT attach location information > to messages towards the RADIUS server, unless an out-of-band > agreement is in place. Discuss-discuss: I may be missing something here, but why is it useful to allow an out-of-band agreement to override protocol semantics? If there's an agreement that this information is to always be exchanged, the server should simply always send Requested-Location-Info and then the client should include it. Section 8.1., paragraph 6: > Requests to IANA for a new value for a Namespace ID will be approved > by Expert Review. The Designated Expert Reviewer team for these > requests is the current Operations Area Director and the RADEXT > working group chairs or the working group chairs of a designated > successor working group. Discuss: It is up to the IESG to appoint designated experts, not a published RFC. (The appointment may change over time.) The same issue exists for other registries, and some have a related issue where it's claimed that the OPS ADs appoint experts. Section 11.2., paragraph 5: > [I-D.ietf-radext-rfc3576bis] > Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. > Aboba, "Dynamic Authorization Extensions to Remote > Authentication Dial In User Service (RADIUS)", > draft-ietf-radext-rfc3576bis-13 (work in progress), > October 2007. Discuss: The way this (now published as RFC5176) is used in Section 3.3 and Section 8 makes me think this needs to be a normative reference. But it's an Informational RFC, which would make this a DOWNREF. Comment [2008-07-11]: Section 4.1., paragraph 17: > Example: anyisp.example.com Suggest to move this example down to the description of the REALM namespace, because it's specific to it. (It confused me on first reading to see the example and then read about namespaces where it isn't valis.) It might also be good to add one example to each of the other namespaces. Section 4.2., paragraph 2: > The Location-Information Attribute provides meta-data about the > location information, such as sighting time, time-to-live, location > determination method, etc. Implementations SHOULD treat this > attribute as undistinguished octets, like the Location-Data Attribute > to which it refers. Why is this a SHOULD and not a MUST? Under what conditions may implementations interpret the attribute? (The same comment applies to other attributes below.) Section 4.4., paragraph 19: > Note Well (variable): > This field contains a URI that points to human readable > privacy instructions. The data type of this field is string. The APP ADs should look at this. I'm not an i18n expert, but it seems pretty important to transport a URI here that points to something a user can understand. Section 4.4., paragraph 21: > retransmission-allowed: > When the value of this field is to zero (0), then the recipient of > this Location Object is not permitted to share the enclosed > location information, or the object as a whole, with other > parties. Are there any protocol or encoding mechanisms in place to prevent this sharing, or do we simply trust the other end to conform to our wishes? (Same issue applies to "retention-expires".) Section 4.6., paragraph 1: > A RADIUS server SHOULD NOT > challenge for location information unless the Location-Capable > Attribute has been sent to it. Why is this a SHOULD NOT? When is it permissible to challenge? Section 6., paragraph 2: > | | |SHLD| MUST| | s/SHLD/SHOULD/ (don't abbreviate RFC2119 terms) Section 8.1., paragraph 3: > | 0x31 | REALM | IETF O&M Area Directors | > | | | (ops-chairs@ietf.org) | The ADs are at ops-ads@ietf.org. Section 8.2., paragraph 6: > No mechanism to mark entries as "deprecated" is > envisioned. Based on expert approval it is possible to delete > entries from the registry. It's usually much safer to deprecate registry entries or to make them historic, compared to simply removing them. Is there a particular reason for this choice? (Same comment applies to other registries.) Section 9., paragraph 1: > We would like to thank Bernhard Aboba for the numerous contributions > to this document. It's a bit unusual to thank a co-author, but hey :-) Dan Romascanu: Comment [2008-11-07]: This COMMENT is based on the AAA-Doctor review by David Nelson.=20 I have cleared a previous DISCUSS that was raising a number of concerns. 1. One of them was mentioning that this document needs at the very least an IESG Note calling attention to the fact that certain of the RADIUS attributes fail to meet either the letter or spirit of the RADIUS Design Guidelines as to what may properly constitute an "opaque" attribute. Opaque attributes are those that are carried in RADIUS, but not parsed or directly acted upon by a RADIUS server. The revised text that addresses this issue is as follows: 4. Attributes It is important to note that the location specific parts of the attributes defined below are not meant to be processed by the RADIUS server. Instead, a location server specific component used in combination with the RADIUS server is responsible for receiving, processing and further distributing location information (in combination with proper access control and privacy protection). As such, from a RADIUS server point of view location information is treated as opaque data. This text does not reference the Design Guidelines, but rather simply declares that the attributes in question are to be considered opaque. I think this is a bit superficial, but probably suffices to address the issue. 2. A second issue is whether RADIUS servers are expected to be able to parse and act upon these various defined "string" data sets. In the IETF Last Call discussion, these seemed to be some confusion as to whether this document required RADIUS servers (at least those implementing these attributes) to be "location aware" i.e. to be able to parse and act intelligently upon the content of the location information. =20 The added text of Section 4 addresses this issue, too. While I have some lingering concerns that the attribute design style of this document may be viewed as a model for future work, as there is no explicit acknowledgement that it diverges from the Design Guidelines, I think that the added text is sufficient to close the DISCUSS. ^L ---- following is a DRAFT of message to be sent AFTER approval --- From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor ,=20 geopriv mailing list ,=20 geopriv chair Subject: Protocol Action: 'Carrying Location Objects in RADIUS=20 and Diameter' to Proposed Standard=20 The IESG has approved the following document: - 'Carrying Location Objects in RADIUS and Diameter ' as a Proposed Standard This document is the product of the Geographic Location/Privacy Working Group.=20 The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-23.txt Technical Summary This document specifies RADIUS attributes for conveying access network location information, in both civic and geospatial location formats, along with access network ownership. The distribution of location information is a privacy sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed throughout, for various scenarios of location information function within AAA. WG Summary The WG reached solid consensus to advance this document after a number of iterations. The WG had initial hesitation about taking on the work, because the RFC 4119 pidf_lo object could not be used within RADIUS attribute size constraints. The WG concerns were met with an eventual functional compromise, providing a mandated attribute with the pidf_lo policy markers, and opaque attributes pointing to the geopriv location formats developed for DHCP which had constraints similar to RADIUS. =20 This document is a Critical Requirement for 3GPP. Both the GSM Association and the ITU have specified Operator Namespace Tokens for use in this protocol. (The document has customers). Document Quality The protocol was reviewed in depth by both the GEOPRIV and RADEXT Working Groups. RADEXT's formal issues list was cleared. GEOPRIV and RADEXT had some overlapping issues, especially location information design, and scenario evaluation. The conclusion that location- aware AAA systems need to be able to implement the formats and processing found in the GEOPRIV documents was very useful, because it meant that GEOPRIV did not have to intercept or anticipate any enhancements of the RADIUS data model.=20 The document is especially careful in projecting GEOPRIV's paranoia towards exposing location information. Section 8.3 contains a detailed review against the previously defined requirements related to this, and the Security Considerations details the use of security services RADIUS provides as the using protocol to meet requirements. Note to RFC Editor =20 None IESG Note None =20 IANA Note None From dromasca@avaya.com Tue Apr 14 09:38: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 682A23A6AF6; Tue, 14 Apr 2009 09:38:34 -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 n2HR9fVepIM8; Tue, 14 Apr 2009 09:38:33 -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 815E53A6BAC; Tue, 14 Apr 2009 09:38:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,186,1238990400"; d="scan'208";a="167855430" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Apr 2009 12:39:44 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Apr 2009 12:39:44 -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, 14 Apr 2009 18:39:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-isms-radius-usage (Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models) to Proposed Standard Thread-index: Acm3kbQC9o4JRGVFSaWZZMQiSrxfegFjdqRQ From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Last Call: draft-ietf-isms-radius-usage (Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models) 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, 14 Apr 2009 16:38:34 -0000 =20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Tuesday, April 07, 2009 6:00 PM To: IETF-Announce Cc: isms@ietf.org Subject: Last Call: draft-ietf-isms-radius-usage (Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models) to Proposed Standard=20 The IESG has received a request from the Integrated Security Model for SNMP WG (isms) to consider the following document: - 'Remote Authentication Dial-In User Service (RADIUS) Usage for Simple=20 Network Management Protocol (SNMP) Transport Models ' 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-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usage-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 16427&rfc_flag=3D0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From dromasca@avaya.com Tue Apr 14 09:43:16 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 AD75A3A68E4; Tue, 14 Apr 2009 09:43:16 -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 qwuA6MvoWXDM; Tue, 14 Apr 2009 09:43:16 -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 5C6903A68A4; Tue, 14 Apr 2009 09:43:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,186,1238990400"; d="scan'208";a="143054642" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Apr 2009 12:44:25 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 14 Apr 2009 12:44:24 -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, 14 Apr 2009 18:44:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-openpgp-camellia-04.txt to Informational RFC Thread-index: Acm9IA/Km4iZS6FZT+2S7bIvagok9QAAB4gg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-openpgp-camellia-04.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: Tue, 14 Apr 2009 16:43:16 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-04.txt Technical Summary This document presents the necessary information to use the=20 Camellia symmetric block cipher in the OpenPGP protocol. Its main goal is the allocation of three cipher types from the OpenPGP number space. It provides guidelines for when to use the cipher within OpenPGP. The specification has a Normative downref to RFC 3713, which defines the Camellia cipher. Working Group Summary This document was part of the OpenPGP Working Group and was a Work Item of that group prior to the conclusion of the WG. The working group discussion mostly focused on the set of key sizes to support. Consensus was achieved for the set included in the document. However, the document was not Last Called before the wg concluded. Document Quality This document was reviewed by the chair of the concluded openpgp working group. Personnel The Document Shepherd is Derek Atkins. The Responsible Area Director is Tim Polk. 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 Thu Apr 16 01:38: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 7270A3A6845; Thu, 16 Apr 2009 01:38:45 -0700 (PDT) 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 O6FkrpSmjVOb; Thu, 16 Apr 2009 01:38: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 4E62F3A680A; Thu, 16 Apr 2009 01:38:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,197,1238990400"; d="scan'208";a="158565138" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 16 Apr 2009 04:39:56 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Apr 2009 04:39:55 -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, 16 Apr 2009 10:39:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-radext-design-07.txt to BCP Thread-index: Acm+bo54/aHwodV6SoGukf5dGUTSUwAADFcg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-radext-design-07.txt to BCP 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, 16 Apr 2009 08:38:45 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-07.txt authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). Technical Summary This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs).=20 Working Group Summary There have been 2 WGLCs on the document. Much of the discussion on the document has centered around the design guidelines=20 surrounding complex attributes, as well as the relationship of the RADIUS Vendor-Specific Attribute (VSA) and the Standard attribute space. There was also considerable discussion relating to the process for review of RADIUS attributes specified by SDOs. =20 Ultimately, a consensus developed behind a model similar to that described in [RFC4663]. Document Quality This is a BCP aiming to help authors and reviewers of future RADIUS =20 attribute specifications. The RADIUS protocol is widely implemented and deployed. The document was extensively discussed in the Working Group and underwent two IETF Last Calls. Gonzalo Camarillow reviewed the =20 document for GenART. =20 Personnel Bernard Aboba is the Document Shepherd, Dan Romascanu is the=20 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 Thu Apr 16 02:09:54 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 824743A6CBC; Thu, 16 Apr 2009 02:09:54 -0700 (PDT) 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 g6AaroOLCgvN; Thu, 16 Apr 2009 02:09:53 -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 690B628C184; Thu, 16 Apr 2009 02:09:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,197,1238990400"; d="scan'208";a="168055034" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Apr 2009 05:11:05 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 16 Apr 2009 05:11:05 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 11:10:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-isms-secshell-15.txt to Proposed Standard Thread-index: Acm+cvorKxEYO0H0RFu9Se9RX1pDhAAABvFA From: "Romascanu, Dan (Dan)" To: "MIB Doctors (E-mail)" , , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-isms-secshell-15.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, 16 Apr 2009 09:09:54 -0000 =20 I believe that this document requires special attention from MIB-Doctors and OPS-DIR.=20 Dan A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-15.txt Technical Summary The document defines a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell protocol (SSH). The document also defines a portion of the Management Information Base (MIB) for monitoring and managing the Secure Shell Transport Model for SNMP. Working Group Summary The document has mainly been updated recently to track clarifications and to improve the readability. There has been WG consensus on revision 15 of this document and there are no controversies on the technical solution. Document Quality There are two known implementations in progress of the Secure Shell Transport Model. There are no further vendor commitments at the moment to implement this specification. Personnel The document shepherd is Juergen Schoenwaelder, and the responsible area director is Pasi Eronen. RFC Editor Note Replace all occurrences of "SSHTM-MIB" with "SNMP-SSH-TM-MIB" (also in the MIB module in Section 7) Section 10: OLD: 1. two TCP registered port numbers in the http://www.iana.org/assignments/port-numbers registry which will be the default ports for SNMP over an SSH Transport Model (SSHTM) as defined in this document, and SNMP over an SSH Transport Model for notifications (SSHTM-TRAP) as defined in this document. It would be good if the assigned numbers were x161 and x162. NEW: 1. two TCP registered port numbers in the http://www.iana.org/assignments/port-numbers registry which will be the default ports for SNMP over an SSH Transport Model (snmpssh) as defined in this document, and SNMP over an SSH Transport Model for notifications (snmpssh-trap) as defined in this document. It would be good if the assigned numbers were x161 (snmpssh) and x162 (snmpssh-trap). From dromasca@avaya.com Thu Apr 16 02:10: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 6EE563A6CC1; Thu, 16 Apr 2009 02:10:24 -0700 (PDT) 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 htSfEKK4c8zH; Thu, 16 Apr 2009 02:10:23 -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 369CB3A6B59; Thu, 16 Apr 2009 02:10:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,197,1238990400"; d="scan'208";a="158567477" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 16 Apr 2009 05:11:35 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 16 Apr 2009 05:11:35 -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, 16 Apr 2009 11:11:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-isms-tmsm-16.txt to Proposed Standard Thread-index: Acm+cw7ftL4feU8YSX2+KfWzJkTCHAAADSlQ From: "Romascanu, Dan (Dan)" To: "MIB Doctors (E-mail)" , , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-isms-tmsm-16.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, 16 Apr 2009 09:10:24 -0000 =20 I believe that this document requires special attention from MIB-Doctors and OPS-DIR.=20 Dan A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-16.txt Technical Summary The document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. The subsystem can contain Transport Models comparable to other subsystems in the RFC 3411 architecture. The Transport Subsystem can be used to expand the transports to include secure transports such as SSH or TLS. Working Group Summary The working group went over several revisions of this document while developing a Transport Model for SSH. The document did stabilize several revisions ago and has mainly been kept back to track clarifications and to ensure the new subsystem works with the SSH transport defined in a companion document. There has been strong WG consensus on revision 16 of this document. Document Quality There are two known implementations in progress of secure transport models. A concrete SSH subsystem has been worked out by the ISMS working group and a DTLS subsystem is in progress as an individual draft and it seems the Transport Subsystem defined in this document is capable to supports both secure transports. Personnel The document shepherd is Juergen Schoenwaelder, and the responsible area director is Pasi Eronen. The IANA Expert for the registries in this document is David Harrington (ietfdbh@comcast.net). From dromasca@avaya.com Thu Apr 16 02:11:06 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 B87BC28C227; Thu, 16 Apr 2009 02:11:06 -0700 (PDT) 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 PeVByWbqMBfI; Thu, 16 Apr 2009 02:11:05 -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 E6E3E28C1FE; Thu, 16 Apr 2009 02:10:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,197,1238990400"; d="scan'208";a="158567503" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 16 Apr 2009 05:12:00 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Apr 2009 05:11:59 -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, 16 Apr 2009 11:11:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-isms-transport-security-model-12.txt to Proposed Standard Thread-index: Acm+cx756bzJiBzsSJmAgdmYpkhcAwAADrTA From: "Romascanu, Dan (Dan)" To: "MIB Doctors (E-mail)" , , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-isms-transport-security-model-12.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, 16 Apr 2009 09:11:06 -0000 =20 I believe that this document requires special attention from MIB-Doctors and OPS-DIR.=20 Dan A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-m odel-12.txt Technical Summary The document defines a Transport Security Model for the Simple Network Management Protocol (SNMP) for use with secure Transport Models in the Transport Subsystem. The document also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. Working Group Summary The document did stabilize several revisions ago and has mainly been updated recently to track clarifications. There has been WG consensus on revision 12 of this document and there were no controversies on the technical solution since the IETF meeting in Dublin. Document Quality There are two known implementations in progress of the Transport Security Model. A concrete SSH subsystem has been worked out by the ISMS working group and a DTLS subsystem is in progress as an individual draft and it seems the Transport Security Model defined in this document is capable to support both secure transports. Personnel The document shepherd is Juergen Schoenwaelder, and the responsible area director is Pasi Eronen. RFC Editor Note Replace all occurrences of "SNMP-TSM-MIB" with "SNMP-TRANSPORT-SM-MIB" (also in the MIB module in Section 7) From dromasca@avaya.com Thu Apr 16 04:01:06 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 3CFD03A6D16; Thu, 16 Apr 2009 04:01:06 -0700 (PDT) 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 V97FWThZg4Wt; Thu, 16 Apr 2009 04:01:05 -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 8537D3A6CF0; Thu, 16 Apr 2009 04:01:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,198,1238990400"; d="scan'208";a="158575083" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 16 Apr 2009 07:02:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 16 Apr 2009 07:02:12 -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, 16 Apr 2009 13:01:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Network-Based Mobility Extensions (netext) Thread-index: Acm9PDo8dIiyYJ8NQteaJdzaD0CtIQBRn6tg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: WG Review: Network-Based Mobility Extensions (netext) 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, 16 Apr 2009 11:01:06 -0000 =20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, April 14, 2009 11:00 PM To: ietf-announce@ietf.org Cc: netext@mail.mobileip.jp Subject: WG Review: Network-Based Mobility Extensions (netext)=20 A new IETF working group has been proposed in the Internet 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, April 21, 2009. Network-Based Mobility Extensions (netext) ------------------------------------------------------------- Last Modified: 2009-04-03 Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: TBD Mailing Lists: http://www.mobileip.jp/mailman/listinfo/netext Description of Working Group: Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable. Proxy Mobile IPv6 has been incorporated into a number of products and deployments are starting. Certain deployment considerations, including localized routing and bulk refresh of lifetime are already emerging. The working group will focus on the following topics relevant for network-based mobility: Localized Routing: a specification for routing traffic between the MAG(s) without involving the LMA. That is, allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. Applications such as voice can benefit from the reduced latency. Hosts are not affected, as they still send and receive their packets via the MAG. Bulk Refresh: a specification of improving the signaling load for binding lifetime refresh. The current specifications call for the handling of each mobility session independent of each other. When a large number of hosts are served by a single MAG, a periodic refresh of the binding lifetimes can lead to a signaling storm. The purpose of the Bulk Refresh feature is to construct a protocol feature that allows such refreshes to occur on a per-MAG basis. LMA Redirection: a specification for allowing an LMA to redirect a MAG to another LMA. This is primarily needed as a way to perform load balancing, and is complementary to the initial LMA discovery work in the NETLMM WG. The proposed activity will be complementary to the existing IETF Working Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will also act as the primary forum where new extensions on top of the Proxy Mobile IPv6 protocol can be developed. The addition of such new extensions to the working group involves addition of the extension to this charter through the normal rechartering process. Milestones May 2009 WG chartered July 2009 Initial WG draft on Bulk Refresh September 2009 Initial WG draft on LMA Redirection November 2009 Initial WG draft on Route Optimization December 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC January 2009 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC April 2010 Submit Route Optimization to IESG for publication as a Proposed Standard RFC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From dromasca@avaya.com Thu Apr 16 05:41:05 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 C21963A6CA7; Thu, 16 Apr 2009 05:41:05 -0700 (PDT) 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 trw0O5qL1usp; Thu, 16 Apr 2009 05:41:05 -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 CC5523A6359; Thu, 16 Apr 2009 05:40:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,198,1238990400"; d="scan'208";a="168072406" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Apr 2009 08:41:55 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Apr 2009 08:41:55 -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, 16 Apr 2009 14:41:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-lochter-pkix-brainpool-ecc-03.txt to Informational RFC Thread-index: Acm9+3N2olY/zpwpSr6D0fft0X62awAlSJ6Q From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-lochter-pkix-brainpool-ecc-03.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: Thu, 16 Apr 2009 12:41:05 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lochter-pkix-brainpool-ecc-03. txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary This document specifies a suite of elliptic curves with parameters=20 that were generated in a verifiably pseudo-random way. Working Group Summary This document is an independent submission. Document Quality The brainpool curves (v1.0) were published in October 2005. Personnel Tim Polk is the Responsible Area Director. RFC Editor Note The IESG has not found any conflict between this document and IETF work. IRTF Note (Insert IRTF Note here or remove section) IESG Note Please include the following IESG note immediately following the "Status of this Memo" section of the finished RFC: This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Thu Apr 16 05:42:01 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 CD1D43A683E; Thu, 16 Apr 2009 05:42:01 -0700 (PDT) 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 9XbRER5-wezj; Thu, 16 Apr 2009 05:42:01 -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 AC0613A6359; Thu, 16 Apr 2009 05:42:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,198,1238990400"; d="scan'208";a="158583988" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 16 Apr 2009 08:43:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Apr 2009 08:43:12 -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, 16 Apr 2009 14:43:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-pkix-3281update-04.txt to Proposed Standard Thread-index: Acm9+GW4FS1531dPTeCIU+molESOvwAmHGTg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-pkix-3281update-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: Thu, 16 Apr 2009 12:42:01 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-3281update-04.txt Technical Summary This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. Working Group Summary This ID was discussed on the mailing list and at multiple meetings. It is a simple update to address known errata posted to the RFC editor and to address an issue identified as a result of developing the draft-ietf-pkix-authorityclearanceconstraints ID. The clearance attribute object identifier didn't match the attribute's X.509 object identifier. Document Quality This document is an update of an existing draft and is comparable in quality to its predecessor. Note that most of the changes listed in Appendix C of the document are a result of the long lag time between updates (e.g., reference updates). Personnel Steve Kent is the document Shepherd. Tim Polk is the responsible Security Area AD. 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 Thu Apr 16 06:45: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 9754428C1ED; Thu, 16 Apr 2009 06:45:29 -0700 (PDT) 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 d-9sCEP5b4uP; Thu, 16 Apr 2009 06:45:28 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B150E28C1BD; Thu, 16 Apr 2009 06:45:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,198,1238990400"; d="scan'208";a="143256474" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Apr 2009 09:46:38 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Apr 2009 09:46:37 -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, 16 Apr 2009 15:46:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: RFC 3852 to Draft Standard Thread-index: Acm96fji0tPHiAwiSVichc7d0QugagAr7BBA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: RFC 3852 to Draft 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, 16 Apr 2009 13:45:29 -0000 =20 A URL of this RFC is: http://www.ietf.org/rfc/rfc3852.txt Technical Summary RFC3852 describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. Working Group Summary RFC 3852 is widely referenced, and is a key building block for specifications developed by the S/MIME, ltans, and keyprov working groups. Document Quality Two or more interoperable implementations have been identified for all features. The implementation report is available at: http://www.ietf.org/IESG/Implementations/CMS-Interoperability-Report.txt Note that the implementation report was prepared according to the guidelines in draft-dusseault-impl-reports-00 Personnel Tim Polk is the responsible Area Director 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 Fri Apr 17 00:34:20 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 47BFB3A6A4C; Fri, 17 Apr 2009 00:34:20 -0700 (PDT) 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 X5M7zI-rRqmx; Fri, 17 Apr 2009 00:34:19 -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 03F5C3A6A26; Fri, 17 Apr 2009 00:34:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,203,1238990400"; d="scan'208";a="168185022" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Apr 2009 03:35:31 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Apr 2009 03:35:31 -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, 17 Apr 2009 09:35:15 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for April 23, 2009 Telechat Thread-index: Acm+22A4Hv2nJ1qcToGAcYR2BmAbgQAUljkg From: "Romascanu, Dan (Dan)" To: , , "MIB Doctors (E-mail)" , Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for April 23, 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, 17 Apr 2009 07:34:20 -0000 Please find below the preliminary agenda of the 4/23 telechat. Please read and review the relevant documents, as well as the charters of the WGs that are being brought for approval by the IESG. Comments, concerns and questions should be sent before 4/22 COB.=20 Thanks and Regards, Dan =20 2.1 WG Submissions 2.1.1 New Item o draft-ietf-tcpm-tcpsecure-11.txt Improving TCP's Robustness to Blind In-Window Attacks (Proposed Standard) -=20 1 of 10=20 Note: IESG: Please read the Document Shepherd Writeup, we need to discuss=20 the "Updates: 793" issue.=20 Token: Lars Eggert o draft-ietf-radext-design-07.txt RADIUS Design Guidelines (BCP) - 2 of 10=20 Token: Dan Romascanu o draft-ietf-ipfix-exporting-type-03.txt Exporting Type Information for IPFIX Information Elements (Proposed=20 Standard) - 3 of 10=20 Token: Dan Romascanu o draft-ietf-ipfix-file-03.txt Specification of the IPFIX File Format (Proposed Standard) - 4 of 10 Token: Dan Romascanu o draft-ietf-dime-mip6-split-16.txt Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction=20 (Proposed Standard) - 5 of 10=20 Token: Dan Romascanu o draft-ietf-netlmm-grekey-option-06.txt GRE Key Option for Proxy Mobile IPv6 (Proposed Standard) - 6 of 10=20 Token: Jari Arkko o draft-ietf-dhc-container-opt-05.txt Container Option for Server Configuration (Proposed Standard) - 7 of 10=20 Token: Jari Arkko o draft-ietf-pkix-3281update-04.txt An Internet Attribute Certificate Profile for Authorization (Proposed Standard) - 8 of 10=20 Token: Tim Polk o draft-ietf-dccp-serv-codes-08.txt The DCCP Service Code (Proposed Standard) - 9 of 10=20 Token: Lars Eggert o rfc3852.txt Cryptographic Message Syntax (CMS) (Draft Standard) - 10 of 10=20 Token: Tim Polk 2.1.2 Returning Item o draft-ietf-geopriv-radius-lo-23.txt Carrying Location Objects in RADIUS and Diameter (Proposed Standard) - 1 of=20 1=20 Note: Did new LC because previous one did not mention DOWNREF.=20 Token: Cullen Jennings 2.2 Individual Submissions 2.2.1 New Item o draft-atlas-icmp-unnumbered-06.txt Extending ICMP for Interface and Next-hop Identification (Proposed=20 Standard) - 1 of 1=20 Token: Jari Arkko 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-tcpm-ecnsyn-08.txt Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK=20 Packets (Experimental) - 1 of 3=20 Token: Lars Eggert o draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt OSPFv2 Routing Protocols Extensions for ASON Routing (Experimental) - 2 of=20 3=20 Token: Adrian Farrel o draft-ietf-pana-statemachine-10.txt State Machines for Protocol for Carrying Authentication for Network Access=20 (PANA) (Informational) - 3 of 3=20 Token: Jari Arkko 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 NONE 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-lochter-pkix-brainpool-ecc-03.txt ECC Brainpool Standard Curves and Curve Generation (Informational) - 1 of 2=20 Note: waiting for confirmation that no IPR disclosure is needed.=20 Token: Tim Polk o draft-bberry-rfc4938bis-00.txt PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics (Informational) - 2 of 2=20 Token: Jari Arkko 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Open Web authentication (oauth) - 1 of 1 Token: Lisa Dusseault 4.1.2 Proposed for Approval o Multiple Interfaces (mif) - 1 of 3 Token: Jari Arkko o Locator/ID Separation Protocol (lisp) - 2 of 3 Token: Jari Arkko o Network-Based Mobility Extensions (netext) - 3 of 3 Token: Jari Arkko 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE From dromasca@avaya.com Mon Apr 20 05:54:18 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 775883A6880; Mon, 20 Apr 2009 05:54:18 -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.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxtVBZ1x7Fhx; Mon, 20 Apr 2009 05:54:17 -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 107553A6A03; Mon, 20 Apr 2009 05:54:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,217,1238990400"; d="scan'208";a="143539042" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Apr 2009 08:55:30 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Apr 2009 08:55: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: Mon, 20 Apr 2009 14:55:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-rmt-bb-lct-revised-09.txt to Proposed Standard Thread-Index: Acm/cpSZ2U1RoZ/IR6+Deyp53h5seQCRHYIA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-rmt-bb-lct-revised-09.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, 20 Apr 2009 12:54:18 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lct-revised-09.txt Technical Summary This document is an RMT Building Block that specifies protocol headers and procedures useful for building a reliable multicast transport protocol that can employ packet-level forward error correction (FEC) coding to enable massively- scalable, reliable, unidirectional network data transport without requiring receiver feedback. Layered Coding Transport is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. =20 Layered Coding Transport is compatible with congestion control that provides multiple rate delivery to receivers. Working Group Summary There is consensus in the WG to publish this documents. Document Quality The document is of high quality and has been subject to extensive review in its Internet Draft and Experimental RFC forms. The revised draft represents a small number of changes from the original Experimental RFC 3451. =20 Open source implementations of the LCT protocol are available and considerable experience in using this protocol has been accumulated. The protocol has been adopted by the Digital Video Broadcasting (DVB) industry consortium for content delivery. The content of this document was already reviewed and approved for publication as experimental RFC 3451. This document contains minor technical modifications. Personnel Brian Adamson is the Document Shepherd. Magnus Westerlund is the Responsible Area Director. Note to RFC Editor =20 (Insert note to RFC Editor here) IESG Note (Insert IESG Note here) IANA Note (Insert IANA Note here) From dromasca@avaya.com Mon Apr 20 06:36: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 E3A593A67D1; Mon, 20 Apr 2009 06:36: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.083, 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 tGAs11UiMUJy; Mon, 20 Apr 2009 06:36:49 -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 991E13A63EC; Mon, 20 Apr 2009 06:36:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,217,1238990400"; d="scan'208";a="143544431" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Apr 2009 09:38:02 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 20 Apr 2009 09:38:02 -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, 20 Apr 2009 15:37:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-iana-special-ipv4-registry-01.txt to Informational RFC Thread-Index: Acm+u3F7mB4nFbrUQmG8tOCvHRFDfwDAbkFA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-iana-special-ipv4-registry-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: Mon, 20 Apr 2009 13:36:50 -0000 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iana-special-ipv4-registry-01. txt Technical Summary This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry. Working Group Summary This document is not the product of any IETF WG. Protocol Quality The document was reviewed by Russ Housley for the IESG. RFC Editor Note Please publish this document at the same time as draft-iana-rfc3330bis. From dromasca@avaya.com Mon Apr 20 09:34: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 4A7FE3A6FA2; Mon, 20 Apr 2009 09:34:42 -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.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3IWKYMJeJcG; Mon, 20 Apr 2009 09:34:41 -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 46C9C3A6F7E; Mon, 20 Apr 2009 09:34:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,218,1238990400"; d="scan'208";a="158928925" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 20 Apr 2009 12:35:56 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 20 Apr 2009 12:35:56 -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, 20 Apr 2009 18:35:34 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ietf-mpls-p2mp-te-mib-09.txt to Proposed Standard Thread-Index: AcnB1SrZeHDtTBgHQOKUXwkCzKAUhgAAK0Hw From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ietf-mpls-p2mp-te-mib-09.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, 20 Apr 2009 16:34:42 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-te-mib-08.txt Technical Summary This memo describes managed objects for point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The MIB module defined in this document is applicable to P2MP MPLS-TE by extensions to the MPLS-TE MIB module defined in RFC 3812. It is equally applicable to P2MP Generalized MPLS (GMPLS) in association with the GMPLS TE MIB module defined in RFC 4802. Working Group Summary No dissent reported (see PROTO writeup by Loa Andersson in the tracker).=20 Document Quality No existing implementations of this MIB. The document has been updated based on early MIB doctor review by Joan Cucchiara as well as WG and IETF Last call comments. Several key reviewers work at companies where implementation of such a MIB module is=20 on the roadmap. Personnel Loa Andersson is the Document Shepherd for this document. =20 Ross Callon is the Responsible Area Director. Adrian=20 Farrel is document editor.=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 Hannes.Tschofenig@gmx.net Thu Apr 23 04:01: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 A243E3A6F33 for ; Thu, 23 Apr 2009 04:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.076 X-Spam-Level: X-Spam-Status: No, score=-1.076 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_50=0.001, 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 q1GI4pqE0hN8 for ; Thu, 23 Apr 2009 04:01:38 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B4BB428C6AD for ; Thu, 23 Apr 2009 04:00:54 -0700 (PDT) Received: (qmail invoked by alias); 23 Apr 2009 10:55:29 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp038) with SMTP; 23 Apr 2009 12:55:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+5JNEhNBi5mGL6jntsOfk9R8Kve6K6jKlPvSJYwp SuTA0ibiTvj+I5 From: "Hannes Tschofenig" To: Date: Thu, 23 Apr 2009 13:57:01 +0300 Message-ID: <007b01c9c402$3b1a7c60$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C9C41B.6067B460" X-Mailer: Microsoft Office Outlook 11 thread-index: AcnEAYdifNJlwhLOSCqdDJRjw+7HWA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75,-0.07000000000000001 Subject: [AAA-DOCTORS] Your Contact Details 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, 23 Apr 2009 11:01:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_007C_01C9C41B.6067B460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I have had problems getting a timely response from you when assigning reviews. Please send me your contact info (phone number and IM address) so that I can get in touch with you using non-email means as well. Thanks. Ciao Hannes ------=_NextPart_000_007C_01C9C41B.6067B460 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Your Contact Details

Hi all,

I have had problems getting a timely = response from you when assigning reviews.

Please send me your contact info (phone = number and IM address) so that I can get in touch with you using = non-email means as well.

Thanks.

Ciao
Hannes

------=_NextPart_000_007C_01C9C41B.6067B460-- From dromasca@avaya.com Mon Apr 27 02:31:25 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 445EF3A699D; Mon, 27 Apr 2009 02:31:25 -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 O8recPoHWEJB; Mon, 27 Apr 2009 02:31:24 -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 C70D23A6B86; Mon, 27 Apr 2009 02:30:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,253,1238990400"; d="scan'208";a="159575679" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 27 Apr 2009 05:32:17 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Apr 2009 05:32:16 -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, 27 Apr 2009 11:32:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-thomson-beep-async-02.txt to Proposed Standard Thread-Index: AcnHFqLCVujhgKtmRBaqBathBFTbowABE7bw From: "Romascanu, Dan (Dan)" To: , , Subject: [AAA-DOCTORS] FW: Evaluation: draft-thomson-beep-async-02.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, 27 Apr 2009 09:31:25 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thomson-beep-async-02.txt-02.t xt Technical Summary The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes a BEEP feature that enables asynchrony for individual channels. Working Group Summary This is an individual submission. Document Quality This was reviewed on the mailing list for the concluded BEEP WG. There was moderate controversy about whether this extension was needed as it is possible to work-around the lack of this feature in BEEP at the next layer up. No other technical objections were raised and there was explicit support from several parties. At least one open source BEEP library implementation has agreed to implement this extension. Personnel Chris Newman is the document shepherd. This has been reviewed for the IESG by Alexey Melnikov. Marshall Rose and other participants of the BEEP WG mailing list reviewed this proposal. RFC Editor Note (Insert RFC Editor Note here or remove section) IANA Note (Insert IANA Note here or remove section) From dromasca@avaya.com Mon Apr 27 02:32:06 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 456B33A6B86; Mon, 27 Apr 2009 02:32:06 -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.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6AIKBUhK2P3; Mon, 27 Apr 2009 02:32:05 -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 550EA3A6983; Mon, 27 Apr 2009 02:32:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,253,1238990400"; d="scan'208";a="144164031" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Apr 2009 05:33:22 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 27 Apr 2009 05:33:21 -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, 27 Apr 2009 11:32:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-ncook-urlauth-accessid-02.txt to Proposed Standard Thread-Index: AcnHFmzmJ5t2Vgh6T+ef0oGvmya2awABLNgg From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-ncook-urlauth-accessid-02.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, 27 Apr 2009 09:32:06 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ncook-urlauth-accessid-02.txt Technical Summary The existing IMAP URL specification (RFC 5092) lists several identifiers and identifier prefixes, that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new identifiers as well as an IANA mechanism to register new identifiers for future applications. This document updates RFC 5092. Working Group Summary Nothing out of the ordinary happened in the WG to note. Document Quality This document received LEMONADE work group review and expert review. Personnel Eric Burger is the document shepherd. Alexey Melnikov 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 Apr 27 10:56:25 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 5D6393A6FC1; Mon, 27 Apr 2009 10:56:25 -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.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B1BTNbyVB47; Mon, 27 Apr 2009 10:56:23 -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 134353A6B13; Mon, 27 Apr 2009 10:55:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,255,1238990400"; d="scan'208";a="169149633" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Apr 2009 13:56:59 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 27 Apr 2009 13:56: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: Mon, 27 Apr 2009 19:57:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnHYUgZTGRgn4EdSua5xFDGQMLP/gAADcrw From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Internal WG Review: STORage Maintenance (storm) 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, 27 Apr 2009 17:56:25 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Monday, April 27, 2009 8:54 PM To: iesg@ietf.org; iab@iab.org Cc: black_david@emc.com Subject: Internal WG Review: STORage Maintenance (storm)=20 A new IETF working group is being considered in the Transport Area. The draft charter for this working group is provided below for your review and comment. Review time is one week. The IETF Secretariat STORage Maintenance (storm) ---------------------------------- Last Modified: 2009-04-25 Current Status: Proposed Working Group Chairs: - David L. Black - tbd Transport Area Director(s): - Magnus Westerlund - Lars Eggert Transport Area Advisor: - Lars Eggert Mailing Lists: General Discussion: storm@ietf.org To Subscribe: storm-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/storm/index.html Description of Working Group: The IETF IPS (IP Storage) and RDDP (Remote Direct Data Placement) working groups have produced a significant number of storage protocols (e.g., iSCSI, iSER and FCIP) for which there is significant usage. The time has come to reflect feedback from implementation and usage into updated RFCs; this work may include: - Implementation-driven revisions and updates to existing protocols (i.e., updated RFCs that match the "running code"). - Interoperability reports as needed for the resulting revised protocols that are appropriate for Draft Standard RFC status. - Minor protocol changes or additions. Backwards compatibility is required. Significant changes to the existing protocol standards are out of scope, including any work on version 2 of any of these protocols. Stability is critical to the usage of these protocols, so backwards compatibility with existing implementations will be a requirement imposed on for all protocol changes and additions. Note that this is a requirement for implementation compatibility - if it is the case that all implementations of a protocol have done something different than what the RFC specifies, it is appropriate for a new RFC to document what the "running code" actually does and deprecate the unused original behavior. Initial list of work items: (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node architecture key) and 5048 (corrections/clarifications) into one draft (3720bis), removing features that are not implemented in practice. This draft should be prepared so that it could become a Draft Standard RFC, but it is up to the to decide whether to advance it to Draft Standard. (2) iSCSI: Add features to support SAM-4 (4th version of the SCSI architecture) in a backwards-compatible fashion, as iSCSI is currently based on SAM-2. This will be a separate draft from the iSCSI update in the previous bullet. The Working group may add additional minor useful iSCSI features to this draft. (3) FCIP: IP Protocol number 133 was allocated to a precursor of the FCIP protocol in 2000, but this allocated number is not used by FCIP. The working group will consider whether this allocated number should be returned to IANA for future reallocation. (4) iFCP: The Address Translation mode of iFCP needs to be deprecated (SHOULD NOT implement or use), as there are significant technical problems with its specification, and moreover, only the Address Transparent mode of iFCP is in use. This will be done via a short draft that updates RFC 4172, and not via a complete rewrite of RFC 4172. A combined draft is expected that encompasses items (3) and (4). (5) RDDP MPA: Good support for MPI applications requires a small update to the startup functionality to allow either end of the connection to initiate. (6) iSER: Experience with Infiniband implementations suggest a few minor updates to reflect what has been done in practice. The working group is expected to maintain good working relationships with INCITS Technical Committee T10 (SCSI standards) and INCITS Technical Committee T11 (Fibre Channel standards) via overlaps in membership as opposed to appointment of formal liaisons. The liaison process (including IAB appointment of a liaison or liaisons) remains available for use if needed. Goals and Milestones: June 2009 First version of FCIP protocol number and iFCP Address Translation mode draft July 2009 First version of iSCSI SAM-4 (and other) new features draft. Aug 2009 First version of RDDP MPA startup change draft Sep 2009 Working Group Last Call on FCIP protocol number and iFCP address change draft Sep 2009 First version of combined iSCSI draft (3720bis) Oct 2009 First version of iSER update draft Oct 2009 Working Group Last Call on RDDP MPA startup change draft. Dec 2009 Functionally complete iSCSI SAM-4 (and other) new features draft. Feb 2010 Working Group Last Call on iSER update draft March 2010 Working Group Last Call on iSCSI SAM-4 (and other) new features draft. April 2010 Working Group decision on whether to seek Draft Standard RFC status for the combined iSCSI draft (3720bis). [Note: decision may be made significantly before this date.] Sep 2010 Working Group Last Call on combined iSCSI draft (3720bis) From dromasca@avaya.com Mon Apr 27 12:59:57 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 CFD0928C1A9; Mon, 27 Apr 2009 12:59:57 -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.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kt0p5qZ8jFuz; Mon, 27 Apr 2009 12:59:57 -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 CDF0628C179; Mon, 27 Apr 2009 12:59:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,256,1238990400"; d="scan'208";a="159646532" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 27 Apr 2009 16:01:16 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Apr 2009 16:01:16 -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, 27 Apr 2009 22:01:14 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-groves-megaco-pkgereg-03.txt to BCP Thread-Index: AcnE/XGJqTqTt4n0Tbutj9+wCSxwmACdWImQ From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-groves-megaco-pkgereg-03.txt to BCP 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, 27 Apr 2009 19:59:57 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-groves-megaco-pkgereg-02.txt Technical Summary This document updates the H.248/MEGACO IANA Package Registration=20 procedures in order to better describe the Package registration=20 process and to provide a more formal review and feedback process.=20 Working Group Summary Not a product of a WG.=20 Document Quality Was reviewed by ITU-T Study Group 16 Personnel The IANA Expert(s) for the registries in this document is Christian Groves=20 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 Apr 27 13:26:18 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 515613A6E0A; Mon, 27 Apr 2009 13:26:18 -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.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95MqpRuX8kfC; Mon, 27 Apr 2009 13:26:17 -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 061483A6BA1; Mon, 27 Apr 2009 13:26:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,256,1238990400"; d="scan'208";a="159649165" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 27 Apr 2009 16:27:37 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 27 Apr 2009 16:27:37 -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, 27 Apr 2009 22:27:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-saleem-msml-08.txt to Informational RFC Thread-Index: AcnE8stWaw0XhxWiS0iNI2AJI3q84gCg7vtQ From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-saleem-msml-08.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, 27 Apr 2009 20:26:18 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saleem-msml-05.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary =20 This specification describes the Media Server Markup Language (MSML), a language used to control and invoke a variety of services on media servers used to support real-time communications. Common examples would be conference services for audio and/or video bridges and interactive voice response (IVR) systems. =20 Working Group Summary =20 This document is not a product of an IETF working group; it is an individual submission via the RFC-Editor. =20 Protocol Quality =20 Jon Peterson and Robert Sparks have performed the RFC3932 reviews of this document in conjunction with the chairs of the MEDIACTRL working group. IESG Note: =20 Please use the following standard IESG note: This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. Note to the RFC Editor: The IESG recommends the following: 3. The IESG thinks that publication is harmful to the IETF work done in the MEDIACTRL WG and recommends not publishing the document at=20 this time. The MEDIACTRL chairs feel that this work directly competes with ongoing work in their group. This work can be published after these drafts are published: * draft-ietf-mediactrl-sipcontrol-framework * draft-ietf-mediactrl-ivr-control-package * draft-ietf-mediactrl-mixer-control-package From ietfdbh@comcast.net Mon Apr 27 19:09: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 8AF783A67A7 for ; Mon, 27 Apr 2009 19:09:09 -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 csk6IIFkvoUc for ; Mon, 27 Apr 2009 19:09:08 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 3F0D83A68E7 for ; Mon, 27 Apr 2009 19:09:08 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA01.westchester.pa.mail.comcast.net with comcast id kaLh1b00616LCl051qAVyf; Tue, 28 Apr 2009 02:10:29 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA06.westchester.pa.mail.comcast.net with comcast id kqAV1b00N0UQ6dC3SqAVe0; Tue, 28 Apr 2009 02:10:29 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , , References: Date: Mon, 27 Apr 2009 22:10:28 -0400 Message-ID: <027a01c9c7a6$80495d40$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnHYUgZTGRgn4EdSua5xFDGQMLP/gAADcrwABE3XjA= X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 28 Apr 2009 02:09:09 -0000 Will the storm BOF address updating the MIB modules or address managing the protocols in other ways? dbh > -----Original Message----- > From: ops-dir-bounces@ietf.org > [mailto:ops-dir-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Monday, April 27, 2009 1:57 PM > To: aaa-doctors@ietf.org; ops-dir@ietf.org > Subject: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) > > > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > Behalf Of > IESG Secretary > Sent: Monday, April 27, 2009 8:54 PM > To: iesg@ietf.org; iab@iab.org > Cc: black_david@emc.com > Subject: Internal WG Review: STORage Maintenance (storm) > > A new IETF working group is being considered in the Transport > Area. The > draft charter for this working group is provided below for your review > and comment. > > Review time is one week. > > The IETF Secretariat > > STORage Maintenance (storm) > ---------------------------------- > > Last Modified: 2009-04-25 > > Current Status: Proposed Working Group > > Chairs: > - David L. Black > - tbd > > Transport Area Director(s): > - Magnus Westerlund > - Lars Eggert > > Transport Area Advisor: > - Lars Eggert > > Mailing Lists: > General Discussion: storm@ietf.org > To Subscribe: storm-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/storm/index.html > > Description of Working Group: > > The IETF IPS (IP Storage) and RDDP (Remote Direct Data Placement) > working groups have produced a significant number of storage protocols > (e.g., iSCSI, iSER and FCIP) for which there is significant usage. The > time has come to reflect feedback from implementation and usage into > updated RFCs; this work may include: > > - Implementation-driven revisions and updates to existing protocols > (i.e., updated RFCs that match the "running code"). > > - Interoperability reports as needed for the resulting > revised protocols > that are appropriate for Draft Standard RFC status. > > - Minor protocol changes or additions. Backwards compatibility is > required. > > Significant changes to the existing protocol standards are > out of scope, > including any work on version 2 of any of these protocols. > > Stability is critical to the usage of these protocols, so backwards > compatibility with existing implementations will be a requirement > imposed on for all protocol changes and additions. Note that this is a > requirement for implementation compatibility - if it is the case that > all implementations of a protocol have done something different than > what the RFC specifies, it is appropriate for a new RFC to > document what > the "running code" actually does and deprecate the unused original > behavior. > > Initial list of work items: > > (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node > architecture key) and 5048 (corrections/clarifications) into one draft > (3720bis), removing features that are not implemented in > practice. This > draft should be prepared so that it could become a Draft Standard RFC, > but it is up to the to decide whether to advance it to Draft Standard. > > (2) iSCSI: Add features to support SAM-4 (4th version of the SCSI > architecture) in a backwards-compatible fashion, as iSCSI is currently > based on SAM-2. This will be a separate draft from the iSCSI update in > the previous bullet. The Working group may add additional minor useful > iSCSI features to this draft. > > (3) FCIP: IP Protocol number 133 was allocated to a precursor of the > FCIP protocol in 2000, but this allocated number is not used by FCIP. > The working group will consider whether this allocated number > should be > returned to IANA for future reallocation. > > (4) iFCP: The Address Translation mode of iFCP needs to be deprecated > (SHOULD NOT implement or use), as there are significant technical > problems with its specification, and moreover, only the Address > Transparent mode of iFCP is in use. This will be done via a > short draft > that updates RFC 4172, and not via a complete rewrite of RFC 4172. A > combined draft is expected that encompasses items (3) and (4). > > (5) RDDP MPA: Good support for MPI applications requires a > small update > to the startup functionality to allow either end of the connection to > initiate. > > (6) iSER: Experience with Infiniband implementations suggest > a few minor > updates to reflect what has been done in practice. > > The working group is expected to maintain good working relationships > with INCITS Technical Committee T10 (SCSI standards) and INCITS > Technical Committee T11 (Fibre Channel standards) via overlaps in > membership as opposed to appointment of formal liaisons. The liaison > process (including IAB appointment of a liaison or > liaisons) remains available for use if needed. > > Goals and Milestones: > > June 2009 First version of FCIP protocol number and iFCP Address > Translation mode draft > > July 2009 First version of iSCSI SAM-4 (and other) new features draft. > > Aug 2009 First version of RDDP MPA startup change draft > > Sep 2009 Working Group Last Call on FCIP protocol number and iFCP > address change draft > > Sep 2009 First version of combined iSCSI draft (3720bis) > > Oct 2009 First version of iSER update draft > > Oct 2009 Working Group Last Call on RDDP MPA startup change draft. > > Dec 2009 Functionally complete iSCSI SAM-4 (and other) new features > draft. > > Feb 2010 Working Group Last Call on iSER update draft > > March 2010 Working Group Last Call on iSCSI SAM-4 (and other) new > features draft. > > April 2010 Working Group decision on whether to seek Draft > Standard RFC > status for the combined iSCSI draft (3720bis). [Note: > decision may be made significantly before this date.] > > Sep 2010 Working Group Last Call on combined iSCSI draft (3720bis) > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir > From dromasca@avaya.com Tue Apr 28 02:23:17 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 052F23A6B10; Tue, 28 Apr 2009 02:23:17 -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 jOGGlNltCfr4; Tue, 28 Apr 2009 02:23:16 -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 AB7833A67FF; Tue, 28 Apr 2009 02:23:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,259,1238990400"; d="scan'208";a="144283842" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Apr 2009 05:24:35 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 28 Apr 2009 05:24: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: Tue, 28 Apr 2009 11:24:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-p2pi-cooper-workshop-report-01.txt to InformationalRFC Thread-Index: AcnHiv2WP+TLs7NnRSqw3oZYHjnYyAAWAnTw From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-p2pi-cooper-workshop-report-01.txt to InformationalRFC 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, 28 Apr 2009 09:23:17 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-p2pi-cooper-workshop-report-01 .txt Technical Summary =20 This document reports the outcome of a workshop organized by the Real-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased P2P traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the workshop were twofold: to understand the technical problems ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Working Group Summary This is not the product of a WG.=20 Document Quality The document is a thing of beauty.=20 Personnel Cullen Jennings is responsible AD.=20 RFC Editor Note Please ensure this document is "Informational" not "Standards Track". (it is correct in the tracker but wrong on the front page of the draft.=20 On page 4, please adjust spellings as appropriate for s/properietary/proprietary/ s/seperate/separate/ On Page 8, Replace AQM with AQM (Adaptive Queue Management The reference with anchor [RFC2474] points to RFC2475. Please fix it to read RFC2474. IRTF Note none IESG Note none IANA Note none From ietfdbh@comcast.net Tue Apr 28 06:18:15 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 360E23A6CC5 for ; Tue, 28 Apr 2009 06:18:15 -0700 (PDT) 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 0XSHGzg2b++h for ; Tue, 28 Apr 2009 06:18:15 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id DA9CE3A6CB4 for ; Tue, 28 Apr 2009 06:18:14 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA11.westchester.pa.mail.comcast.net with comcast id kyZt1b0060ldTLk5B1Jc1r; Tue, 28 Apr 2009 13:18:36 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA04.westchester.pa.mail.comcast.net with comcast id l1Jb1b00c0UQ6dC3Q1Jb3o; Tue, 28 Apr 2009 13:18:36 +0000 From: "David Harrington" To: , , , References: <027a01c9c7a6$80495d40$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028905F1@CORPUSMX80A.corp.emc.com> Date: Tue, 28 Apr 2009 09:18:34 -0400 Message-ID: <02cb01c9c803$d5a0c4b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnHYUgZTGRgn4EdSua5xFDGQMLP/gAADcrwABE3XjAAFUBm4AAAL7Xg X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <9FA859626025B64FBC2AF149D97C944A028905F1@CORPUSMX80A.corp.emc.com> Cc: 'IAB' , iesg@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 28 Apr 2009 13:18:15 -0000 Hi David, Are the existing storage MIB modules used widely in the industry? Are the existing storage MIB modules used at all in the industry? If not, should the WG ask that they be declared historic? If not, what management is actually used for the IETF storage protocols? Does this require standardization to improve interoperability? What management is used for the underlying T10/T11 standards? Should the Internet versions of these protocols use the same management? If so, are there any specific changes to our storage protocols that need to be made to do so? The IETF has standardized syslog and netconf and ipfix and capwap since the original versions of the IETF storage standards were developed. Would any of these new IETF management standards be more appropriate for addressing specific needs of storage management? The storage industry has been developing rapidly since the IETF storage protocols were developed. Virtualization, cloud computing, online backup, data deduplication, federated filesystems, power consumption issues have all become important considerations in data center operations and management. Do the management strategies for operating IETF storage protocols need to be updated to support emerging trends in the storage industry? The proposed charter does not seem to address operability and manageability of the IETF storage protocols in the current Internet environment and current storage environments. Shouldn't that be part of the work of this WG? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Tuesday, April 28, 2009 8:20 AM > To: ietfdbh@comcast.net; dromasca@avaya.com; > aaa-doctors@ietf.org; ops-dir@ietf.org > Cc: Black_David@emc.com > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > Maintenance (storm) > > I think it would be reasonable for the proposed storm WG to do MIB > work, but I am not aware of current interest in this activity. If > you're interested and volunteering to do this, please let me know ... > > Thanks, > --David > > > > -----Original Message----- > > From: ops-dir-bounces@ietf.org > > [mailto:ops-dir-bounces@ietf.org] On Behalf Of David Harrington > > Sent: Monday, April 27, 2009 10:10 PM > > To: 'Romascanu, Dan (Dan)'; aaa-doctors@ietf.org; ops-dir@ietf.org > > Subject: Re: [OPS-DIR] FW: Internal WG Review: STORage > > Maintenance (storm) > > > > Will the storm BOF address updating the MIB modules or address > > managing the protocols in other ways? > > > > dbh > > > > > -----Original Message----- > > > From: ops-dir-bounces@ietf.org > > > [mailto:ops-dir-bounces@ietf.org] On Behalf Of Romascanu, > Dan (Dan) > > > Sent: Monday, April 27, 2009 1:57 PM > > > To: aaa-doctors@ietf.org; ops-dir@ietf.org > > > Subject: [OPS-DIR] FW: Internal WG Review: STORage Maintenance > > (storm) > > > > > > > > > > > > -----Original Message----- > > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > > > Behalf Of > > > IESG Secretary > > > Sent: Monday, April 27, 2009 8:54 PM > > > To: iesg@ietf.org; iab@iab.org > > > Cc: black_david@emc.com > > > Subject: Internal WG Review: STORage Maintenance (storm) > > > > > > A new IETF working group is being considered in the Transport > > > Area. The > > > draft charter for this working group is provided below for your > > review > > > and comment. > > > > > > Review time is one week. > > > > > > The IETF Secretariat > > > > > > STORage Maintenance (storm) > > > ---------------------------------- > > > > > > Last Modified: 2009-04-25 > > > > > > Current Status: Proposed Working Group > > > > > > Chairs: > > > - David L. Black > > > - tbd > > > > > > Transport Area Director(s): > > > - Magnus Westerlund > > > - Lars Eggert > > > > > > Transport Area Advisor: > > > - Lars Eggert > > > > > > Mailing Lists: > > > General Discussion: storm@ietf.org > > > To Subscribe: storm-request@ietf.org > > > In Body: (un)subscribe > > > Archive: http://www.ietf.org/mail-archive/web/storm/index.html > > > > > > Description of Working Group: > > > > > > The IETF IPS (IP Storage) and RDDP (Remote Direct Data Placement) > > > working groups have produced a significant number of storage > > protocols > > > (e.g., iSCSI, iSER and FCIP) for which there is significant usage. > > The > > > time has come to reflect feedback from implementation and > usage into > > > updated RFCs; this work may include: > > > > > > - Implementation-driven revisions and updates to existing > protocols > > > (i.e., updated RFCs that match the "running code"). > > > > > > - Interoperability reports as needed for the resulting > > > revised protocols > > > that are appropriate for Draft Standard RFC status. > > > > > > - Minor protocol changes or additions. Backwards compatibility is > > > required. > > > > > > Significant changes to the existing protocol standards are > > > out of scope, > > > including any work on version 2 of any of these protocols. > > > > > > Stability is critical to the usage of these protocols, so > backwards > > > compatibility with existing implementations will be a requirement > > > imposed on for all protocol changes and additions. Note > that this is > > a > > > requirement for implementation compatibility - if it is the case > > that > > > all implementations of a protocol have done something > different than > > > what the RFC specifies, it is appropriate for a new RFC to > > > document what > > > the "running code" actually does and deprecate the unused original > > > behavior. > > > > > > Initial list of work items: > > > > > > (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node > > > architecture key) and 5048 (corrections/clarifications) into one > > draft > > > (3720bis), removing features that are not implemented in > > > practice. This > > > draft should be prepared so that it could become a Draft Standard > > RFC, > > > but it is up to the to decide whether to advance it to Draft > > Standard. > > > > > > (2) iSCSI: Add features to support SAM-4 (4th version of the SCSI > > > architecture) in a backwards-compatible fashion, as iSCSI is > > currently > > > based on SAM-2. This will be a separate draft from the > iSCSI update > > in > > > the previous bullet. The Working group may add additional minor > > useful > > > iSCSI features to this draft. > > > > > > (3) FCIP: IP Protocol number 133 was allocated to a > precursor of the > > > FCIP protocol in 2000, but this allocated number is not used by > > FCIP. > > > The working group will consider whether this allocated number > > > should be > > > returned to IANA for future reallocation. > > > > > > (4) iFCP: The Address Translation mode of iFCP needs to be > > deprecated > > > (SHOULD NOT implement or use), as there are significant technical > > > problems with its specification, and moreover, only the Address > > > Transparent mode of iFCP is in use. This will be done via a > > > short draft > > > that updates RFC 4172, and not via a complete rewrite of > RFC 4172. A > > > combined draft is expected that encompasses items (3) and (4). > > > > > > (5) RDDP MPA: Good support for MPI applications requires a > > > small update > > > to the startup functionality to allow either end of the connection > > to > > > initiate. > > > > > > (6) iSER: Experience with Infiniband implementations suggest > > > a few minor > > > updates to reflect what has been done in practice. > > > > > > The working group is expected to maintain good working > relationships > > > with INCITS Technical Committee T10 (SCSI standards) and INCITS > > > Technical Committee T11 (Fibre Channel standards) via overlaps in > > > membership as opposed to appointment of formal liaisons. > The liaison > > > process (including IAB appointment of a liaison or > > > liaisons) remains available for use if needed. > > > > > > Goals and Milestones: > > > > > > June 2009 First version of FCIP protocol number and iFCP Address > > > Translation mode draft > > > > > > July 2009 First version of iSCSI SAM-4 (and other) new features > > draft. > > > > > > Aug 2009 First version of RDDP MPA startup change draft > > > > > > Sep 2009 Working Group Last Call on FCIP protocol number and iFCP > > > address change draft > > > > > > Sep 2009 First version of combined iSCSI draft (3720bis) > > > > > > Oct 2009 First version of iSER update draft > > > > > > Oct 2009 Working Group Last Call on RDDP MPA startup change draft. > > > > > > Dec 2009 Functionally complete iSCSI SAM-4 (and other) > new features > > > draft. > > > > > > Feb 2010 Working Group Last Call on iSER update draft > > > > > > March 2010 Working Group Last Call on iSCSI SAM-4 (and other) new > > > features draft. > > > > > > April 2010 Working Group decision on whether to seek Draft > > > Standard RFC > > > status for the combined iSCSI draft (3720bis). [Note: > > > decision may be made significantly before this date.] > > > > > > Sep 2010 Working Group Last Call on combined iSCSI draft (3720bis) > > > _______________________________________________ > > > OPS-DIR mailing list > > > OPS-DIR@ietf.org > > > https://www.ietf.org/mailman/listinfo/ops-dir > > > > > > > _______________________________________________ > > OPS-DIR mailing list > > OPS-DIR@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-dir > > > > > From Black_David@emc.com Tue Apr 28 05:19:23 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 46C3E28C1F2; Tue, 28 Apr 2009 05:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGGSQ+S5P55t; Tue, 28 Apr 2009 05:19:22 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 0345328C20B; Tue, 28 Apr 2009 05:19:21 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n3SCKZHJ014316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2009 08:20:35 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si04.isus.emc.com (Tablus Interceptor); Tue, 28 Apr 2009 08:20:25 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n3SCKOdt013701; Tue, 28 Apr 2009 08:20:24 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 08:20:24 -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, 28 Apr 2009 08:20:23 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A028905F1@CORPUSMX80A.corp.emc.com> In-Reply-To: <027a01c9c7a6$80495d40$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnHYUgZTGRgn4EdSua5xFDGQMLP/gAADcrwABE3XjAAFUBm4A== References: <027a01c9c7a6$80495d40$0600a8c0@china.huawei.com> To: , , , X-OriginalArrivalTime: 28 Apr 2009 12:20:24.0397 (UTC) FILETIME=[B4FD07D0:01C9C7FB] X-EMM-EM: Active X-Mailman-Approved-At: Wed, 29 Apr 2009 10:34:02 -0700 Cc: Black_David@emc.com Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 28 Apr 2009 12:19:23 -0000 I think it would be reasonable for the proposed storm WG to do MIB work, but I am not aware of current interest in this activity. If you're interested and volunteering to do this, please let me know ... Thanks, --David =20 > -----Original Message----- > From: ops-dir-bounces@ietf.org=20 > [mailto:ops-dir-bounces@ietf.org] On Behalf Of David Harrington > Sent: Monday, April 27, 2009 10:10 PM > To: 'Romascanu, Dan (Dan)'; aaa-doctors@ietf.org; ops-dir@ietf.org > Subject: Re: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance (storm) >=20 > Will the storm BOF address updating the MIB modules or address > managing the protocols in other ways? >=20 > dbh=20 >=20 > > -----Original Message----- > > From: ops-dir-bounces@ietf.org=20 > > [mailto:ops-dir-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > > Sent: Monday, April 27, 2009 1:57 PM > > To: aaa-doctors@ietf.org; ops-dir@ietf.org > > Subject: [OPS-DIR] FW: Internal WG Review: STORage Maintenance > (storm) > >=20 > > =20 > >=20 > > -----Original Message----- > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > > Behalf Of > > IESG Secretary > > Sent: Monday, April 27, 2009 8:54 PM > > To: iesg@ietf.org; iab@iab.org > > Cc: black_david@emc.com > > Subject: Internal WG Review: STORage Maintenance (storm)=20 > >=20 > > A new IETF working group is being considered in the Transport=20 > > Area. The > > draft charter for this working group is provided below for your > review > > and comment. > >=20 > > Review time is one week. > >=20 > > The IETF Secretariat > >=20 > > STORage Maintenance (storm) > > ---------------------------------- > >=20 > > Last Modified: 2009-04-25 > >=20 > > Current Status: Proposed Working Group > >=20 > > Chairs: > > - David L. Black > > - tbd > >=20 > > Transport Area Director(s): > > - Magnus Westerlund > > - Lars Eggert > >=20 > > Transport Area Advisor: > > - Lars Eggert > >=20 > > Mailing Lists: > > General Discussion: storm@ietf.org > > To Subscribe: storm-request@ietf.org > > In Body: (un)subscribe > > Archive: http://www.ietf.org/mail-archive/web/storm/index.html > >=20 > > Description of Working Group: > >=20 > > The IETF IPS (IP Storage) and RDDP (Remote Direct Data Placement) > > working groups have produced a significant number of storage > protocols > > (e.g., iSCSI, iSER and FCIP) for which there is significant usage. > The > > time has come to reflect feedback from implementation and usage into > > updated RFCs; this work may include: > >=20 > > - Implementation-driven revisions and updates to existing protocols > > (i.e., updated RFCs that match the "running code"). > >=20 > > - Interoperability reports as needed for the resulting=20 > > revised protocols > > that are appropriate for Draft Standard RFC status. > >=20 > > - Minor protocol changes or additions. Backwards compatibility is > > required. > >=20 > > Significant changes to the existing protocol standards are=20 > > out of scope, > > including any work on version 2 of any of these protocols. > >=20 > > Stability is critical to the usage of these protocols, so backwards > > compatibility with existing implementations will be a requirement > > imposed on for all protocol changes and additions. Note that this is > a > > requirement for implementation compatibility - if it is the case > that > > all implementations of a protocol have done something different than > > what the RFC specifies, it is appropriate for a new RFC to=20 > > document what > > the "running code" actually does and deprecate the unused original > > behavior. > >=20 > > Initial list of work items: > >=20 > > (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node > > architecture key) and 5048 (corrections/clarifications) into one > draft > > (3720bis), removing features that are not implemented in=20 > > practice. This > > draft should be prepared so that it could become a Draft Standard > RFC, > > but it is up to the to decide whether to advance it to Draft > Standard. > >=20 > > (2) iSCSI: Add features to support SAM-4 (4th version of the SCSI > > architecture) in a backwards-compatible fashion, as iSCSI is > currently > > based on SAM-2. This will be a separate draft from the iSCSI update > in > > the previous bullet. The Working group may add additional minor > useful > > iSCSI features to this draft. > >=20 > > (3) FCIP: IP Protocol number 133 was allocated to a precursor of the > > FCIP protocol in 2000, but this allocated number is not used by > FCIP. > > The working group will consider whether this allocated number=20 > > should be > > returned to IANA for future reallocation. > >=20 > > (4) iFCP: The Address Translation mode of iFCP needs to be > deprecated > > (SHOULD NOT implement or use), as there are significant technical > > problems with its specification, and moreover, only the Address > > Transparent mode of iFCP is in use. This will be done via a=20 > > short draft > > that updates RFC 4172, and not via a complete rewrite of RFC 4172. A > > combined draft is expected that encompasses items (3) and (4). > >=20 > > (5) RDDP MPA: Good support for MPI applications requires a=20 > > small update > > to the startup functionality to allow either end of the connection > to > > initiate. > >=20 > > (6) iSER: Experience with Infiniband implementations suggest=20 > > a few minor > > updates to reflect what has been done in practice. > >=20 > > The working group is expected to maintain good working relationships > > with INCITS Technical Committee T10 (SCSI standards) and INCITS > > Technical Committee T11 (Fibre Channel standards) via overlaps in > > membership as opposed to appointment of formal liaisons. The liaison > > process (including IAB appointment of a liaison or > > liaisons) remains available for use if needed. > >=20 > > Goals and Milestones: > >=20 > > June 2009 First version of FCIP protocol number and iFCP Address > > Translation mode draft > >=20 > > July 2009 First version of iSCSI SAM-4 (and other) new features > draft. > >=20 > > Aug 2009 First version of RDDP MPA startup change draft > >=20 > > Sep 2009 Working Group Last Call on FCIP protocol number and iFCP > > address change draft > >=20 > > Sep 2009 First version of combined iSCSI draft (3720bis) > >=20 > > Oct 2009 First version of iSER update draft > >=20 > > Oct 2009 Working Group Last Call on RDDP MPA startup change draft. > >=20 > > Dec 2009 Functionally complete iSCSI SAM-4 (and other) new features > > draft. > >=20 > > Feb 2010 Working Group Last Call on iSER update draft > >=20 > > March 2010 Working Group Last Call on iSCSI SAM-4 (and other) new > > features draft. > >=20 > > April 2010 Working Group decision on whether to seek Draft=20 > > Standard RFC > > status for the combined iSCSI draft (3720bis). [Note: > > decision may be made significantly before this date.] > >=20 > > Sep 2010 Working Group Last Call on combined iSCSI draft (3720bis) > > _______________________________________________ > > OPS-DIR mailing list > > OPS-DIR@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-dir > >=20 >=20 > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir >=20 >=20 From mehmet.ersue@nsn.com Tue Apr 28 09:29: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 CF7CF3A6BA3; Tue, 28 Apr 2009 09:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.518 X-Spam-Level: X-Spam-Status: No, score=-5.518 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUmUeuclfrjN; Tue, 28 Apr 2009 09:29:21 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E57073A6A21; Tue, 28 Apr 2009 09:29:20 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3SGUXae031206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Apr 2009 18:30:33 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3SGUX0J019106; Tue, 28 Apr 2009 18:30:33 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 18:30:33 +0200 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, 28 Apr 2009 18:30:32 +0200 Message-ID: In-Reply-To: <02cb01c9c803$d5a0c4b0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) thread-index: AcnHYUgZTGRgn4EdSua5xFDGQMLP/gAADcrwABE3XjAAFUBm4AAAL7XgAAf0loA= References: <027a01c9c7a6$80495d40$0600a8c0@china.huawei.com><9FA859626025B64FBC2AF149D97C944A028905F1@CORPUSMX80A.corp.emc.com> <02cb01c9c803$d5a0c4b0$0600a8c0@china.huawei.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext David Harrington" , , , , X-OriginalArrivalTime: 28 Apr 2009 16:30:33.0179 (UTC) FILETIME=[A6EB6AB0:01C9C81E] X-Mailman-Approved-At: Wed, 29 Apr 2009 10:34:02 -0700 Cc: IAB , iesg@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 28 Apr 2009 16:29:22 -0000 David Harrington wrote: > Hi David, >=20 > Are the existing storage MIB modules used widely in the industry?=20 > Are the existing storage MIB modules used at all in the industry?=20 > If not, should the WG ask that they be declared historic? > If not, what management is actually used for the IETF storage > protocols? > Does this require standardization to improve interoperability? >=20 > What management is used for the underlying T10/T11 standards? > Should the Internet versions of these protocols use the same > management? > If so, are there any specific changes to our storage protocols that > need to be made to do so? >=20 > The IETF has standardized syslog and netconf and ipfix and capwap > since the original versions of the IETF storage standards were > developed. Would any of these new IETF management standards be more > appropriate for addressing specific needs of storage management?=20 This is an important consideration. It should be analyzed and noted why=20 'new IETF management standards' are not appropriate for addressing=20 specific needs of storage management. IETF is interested to use existing protocols as much as possible. Regards, Mehmet =20 > The storage industry has been developing rapidly since the IETF > storage protocols were developed. Virtualization, cloud computing, > online backup, data deduplication, federated filesystems, power > consumption issues have all become important considerations in data > center operations and management. Do the management strategies for > operating IETF storage protocols need to be updated to support > emerging trends in the storage industry?=20 >=20 > The proposed charter does not seem to address operability and > manageability of the IETF storage protocols in the current Internet > environment and current storage environments. >=20 > Shouldn't that be part of the work of this WG? >=20 > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com >=20 > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > > Sent: Tuesday, April 28, 2009 8:20 AM > > To: ietfdbh@comcast.net; dromasca@avaya.com;=20 > > aaa-doctors@ietf.org; ops-dir@ietf.org > > Cc: Black_David@emc.com > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > > Maintenance (storm) > >=20 > > I think it would be reasonable for the proposed storm WG to do MIB > > work, but I am not aware of current interest in this activity. If > > you're interested and volunteering to do this, please let me know > ... > >=20 > > Thanks, > > --David > > =20 > >=20 > > > -----Original Message----- > > > From: ops-dir-bounces@ietf.org=20 > > > [mailto:ops-dir-bounces@ietf.org] On Behalf Of David Harrington > > > Sent: Monday, April 27, 2009 10:10 PM > > > To: 'Romascanu, Dan (Dan)'; aaa-doctors@ietf.org; ops-dir@ietf.org > > > Subject: Re: [OPS-DIR] FW: Internal WG Review: STORage=20 > > > Maintenance (storm) > > >=20 > > > Will the storm BOF address updating the MIB modules or address > > > managing the protocols in other ways? > > >=20 > > > dbh=20 > > >=20 > > > > -----Original Message----- > > > > From: ops-dir-bounces@ietf.org=20 > > > > [mailto:ops-dir-bounces@ietf.org] On Behalf Of Romascanu,=20 > > Dan (Dan) > > > > Sent: Monday, April 27, 2009 1:57 PM > > > > To: aaa-doctors@ietf.org; ops-dir@ietf.org > > > > Subject: [OPS-DIR] FW: Internal WG Review: STORage Maintenance > > > (storm) > > > >=20 > > > > =20 > > > >=20 > > > > -----Original Message----- > > > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > > > > Behalf Of > > > > IESG Secretary > > > > Sent: Monday, April 27, 2009 8:54 PM > > > > To: iesg@ietf.org; iab@iab.org > > > > Cc: black_david@emc.com > > > > Subject: Internal WG Review: STORage Maintenance (storm)=20 > > > >=20 > > > > A new IETF working group is being considered in the Transport=20 > > > > Area. The > > > > draft charter for this working group is provided below for your > > > review > > > > and comment. > > > >=20 > > > > Review time is one week. > > > >=20 > > > > The IETF Secretariat > > > >=20 > > > > STORage Maintenance (storm) > > > > ---------------------------------- > > > >=20 > > > > Last Modified: 2009-04-25 > > > >=20 > > > > Current Status: Proposed Working Group > > > >=20 > > > > Chairs: > > > > - David L. Black > > > > - tbd > > > >=20 > > > > Transport Area Director(s): > > > > - Magnus Westerlund > > > > - Lars Eggert > > > >=20 > > > > Transport Area Advisor: > > > > - Lars Eggert > > > >=20 > > > > Mailing Lists: > > > > General Discussion: storm@ietf.org > > > > To Subscribe: storm-request@ietf.org > > > > In Body: (un)subscribe > > > > Archive: http://www.ietf.org/mail-archive/web/storm/index.html > > > >=20 > > > > Description of Working Group: > > > >=20 > > > > The IETF IPS (IP Storage) and RDDP (Remote Direct Data > Placement) > > > > working groups have produced a significant number of storage > > > protocols > > > > (e.g., iSCSI, iSER and FCIP) for which there is significant > usage. > > > The > > > > time has come to reflect feedback from implementation and=20 > > usage into > > > > updated RFCs; this work may include: > > > >=20 > > > > - Implementation-driven revisions and updates to existing=20 > > protocols > > > > (i.e., updated RFCs that match the "running code"). > > > >=20 > > > > - Interoperability reports as needed for the resulting=20 > > > > revised protocols > > > > that are appropriate for Draft Standard RFC status. > > > >=20 > > > > - Minor protocol changes or additions. Backwards compatibility > is > > > > required. > > > >=20 > > > > Significant changes to the existing protocol standards are=20 > > > > out of scope, > > > > including any work on version 2 of any of these protocols. > > > >=20 > > > > Stability is critical to the usage of these protocols, so=20 > > backwards > > > > compatibility with existing implementations will be a > requirement > > > > imposed on for all protocol changes and additions. Note=20 > > that this is > > > a > > > > requirement for implementation compatibility - if it is the case > > > that > > > > all implementations of a protocol have done something=20 > > different than > > > > what the RFC specifies, it is appropriate for a new RFC to=20 > > > > document what > > > > the "running code" actually does and deprecate the unused > original > > > > behavior. > > > >=20 > > > > Initial list of work items: > > > >=20 > > > > (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 > (node > > > > architecture key) and 5048 (corrections/clarifications) into one > > > draft > > > > (3720bis), removing features that are not implemented in=20 > > > > practice. This > > > > draft should be prepared so that it could become a Draft > Standard > > > RFC, > > > > but it is up to the to decide whether to advance it to Draft > > > Standard. > > > >=20 > > > > (2) iSCSI: Add features to support SAM-4 (4th version of the > SCSI > > > > architecture) in a backwards-compatible fashion, as iSCSI is > > > currently > > > > based on SAM-2. This will be a separate draft from the=20 > > iSCSI update > > > in > > > > the previous bullet. The Working group may add additional minor > > > useful > > > > iSCSI features to this draft. > > > >=20 > > > > (3) FCIP: IP Protocol number 133 was allocated to a=20 > > precursor of the > > > > FCIP protocol in 2000, but this allocated number is not used by > > > FCIP. > > > > The working group will consider whether this allocated number=20 > > > > should be > > > > returned to IANA for future reallocation. > > > >=20 > > > > (4) iFCP: The Address Translation mode of iFCP needs to be > > > deprecated > > > > (SHOULD NOT implement or use), as there are significant > technical > > > > problems with its specification, and moreover, only the Address > > > > Transparent mode of iFCP is in use. This will be done via a=20 > > > > short draft > > > > that updates RFC 4172, and not via a complete rewrite of=20 > > RFC 4172. A > > > > combined draft is expected that encompasses items (3) and (4). > > > >=20 > > > > (5) RDDP MPA: Good support for MPI applications requires a=20 > > > > small update > > > > to the startup functionality to allow either end of the > connection > > > to > > > > initiate. > > > >=20 > > > > (6) iSER: Experience with Infiniband implementations suggest=20 > > > > a few minor > > > > updates to reflect what has been done in practice. > > > >=20 > > > > The working group is expected to maintain good working=20 > > relationships > > > > with INCITS Technical Committee T10 (SCSI standards) and INCITS > > > > Technical Committee T11 (Fibre Channel standards) via overlaps > in > > > > membership as opposed to appointment of formal liaisons.=20 > > The liaison > > > > process (including IAB appointment of a liaison or > > > > liaisons) remains available for use if needed. > > > >=20 > > > > Goals and Milestones: > > > >=20 > > > > June 2009 First version of FCIP protocol number and iFCP Address > > > > Translation mode draft > > > >=20 > > > > July 2009 First version of iSCSI SAM-4 (and other) new features > > > draft. > > > >=20 > > > > Aug 2009 First version of RDDP MPA startup change draft > > > >=20 > > > > Sep 2009 Working Group Last Call on FCIP protocol number and > iFCP > > > > address change draft > > > >=20 > > > > Sep 2009 First version of combined iSCSI draft (3720bis) > > > >=20 > > > > Oct 2009 First version of iSER update draft > > > >=20 > > > > Oct 2009 Working Group Last Call on RDDP MPA startup change > draft. > > > >=20 > > > > Dec 2009 Functionally complete iSCSI SAM-4 (and other)=20 > > new features > > > > draft. > > > >=20 > > > > Feb 2010 Working Group Last Call on iSER update draft > > > >=20 > > > > March 2010 Working Group Last Call on iSCSI SAM-4 (and other) > new > > > > features draft. > > > >=20 > > > > April 2010 Working Group decision on whether to seek Draft=20 > > > > Standard RFC > > > > status for the combined iSCSI draft (3720bis). [Note: > > > > decision may be made significantly before this date.] > > > >=20 > > > > Sep 2010 Working Group Last Call on combined iSCSI draft > (3720bis) > > > > _______________________________________________ > > > > OPS-DIR mailing list > > > > OPS-DIR@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ops-dir > > > >=20 > > >=20 > > > _______________________________________________ > > > OPS-DIR mailing list > > > OPS-DIR@ietf.org > > > https://www.ietf.org/mailman/listinfo/ops-dir > > >=20 > > >=20 > >=20 >=20 > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir >=20 From lars.eggert@nokia.com Tue Apr 28 09:43:27 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 24F9A3A6AE0; Tue, 28 Apr 2009 09:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 hQCgNNL7Ucho; Tue, 28 Apr 2009 09:43:25 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 67BB23A6A2B; Tue, 28 Apr 2009 09:43:24 -0700 (PDT) Received: from lars-2.vzbi.com (lars-2.vzbi.com [166.58.67.119]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3SGiY2L023617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Apr 2009 19:44:35 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com> From: Lars Eggert To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 12:44:28 -0400 References: X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [195.148.124.194]); Tue, 28 Apr 2009 19:44:37 +0300 (EEST) X-Mailman-Approved-At: Wed, 29 Apr 2009 10:34:02 -0700 Cc: "aaa-doctors@ietf.org" , "ops-dir@ietf.org" , "Black_David@emc.com" , "iesg@ietf.org" Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 28 Apr 2009 16:43:27 -0000 Hi, On 2009-4-28, at 12:29, Ersue, Mehmet (NSN - DE/Munich) wrote: > unfortunately I missed the Storm BoF in SF. I also was not aware of > the discussion on the maillists you mention. > > I made the experience that announcing a BoF maillist to IETF and > forcing some discussion on this maillist with IETF member > participation > is a good way to show IESG that there is measurable IETF community > interest. as David said below, there was discussion on the still-existing RDDP, IPS and IMSS lists, and the BOF went - in my opinion - very well. I believe community interest has been demonstrated, which is why we're going forward with a charter proposal. > The huge amount of people in the session, which are sometimes > occasionally in the room and vote, usually disappear when it comes to > maillist discussion. Also for our regular WG work the decisions have > to be confirmed on the maillist. > > As I said I believe this is an important and necessary consolidation > work but should be discussed and accepted first in the IETF community. I don't quite know what to do with you comment. Are you saying there hasn't been sufficient discussion to go forward with the chartering? Or am I misunderstanding? I'll also note that the community obviously still has time to comment - the charter is in internal I* review at this time, after which it will go for public review. Lars > > Cheers, > Mehmet > > >> -----Original Message----- >> From: ext Black_David@emc.com [mailto:Black_David@emc.com] >> Sent: Tuesday, April 28, 2009 2:32 PM >> To: Ersue, Mehmet (NSN - DE/Munich) >> Cc: dromasca@avaya.com; Black_David@emc.com >> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage >> Maintenance (storm) >> >> Mehmet, >> >> The storm list is completely new (it was only opened for people >> to subscribe within the past few days). The storm BOF in San >> Francisco was organized using the existing IPS, RDDP and IMSS >> mailing lists. I suggest consulting the archives for those >> lists, particularly for the IPS list, where you should find a >> reasonable level of community interest. >> >> There is definite community interest in this work, and I have >> author commitments for drafts for all six work items listed >> in the charter - each of the "First version of" milestone >> dates in the proposed charter is based on discussion with an >> author or authors who believe that a first version of the draft >> will be ready by that date. >> >> Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer >> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> black_david@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >> >>> -----Original Message----- >>> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >>> Sent: Tuesday, April 28, 2009 6:33 AM >>> To: Ersue, Mehmet (NSN - DE/Munich) >>> Cc: Black, David >>> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage >>> Maintenance (storm) >>> >>> Mehmet, >>> >>> David Black ran the BOF in San Francisco. He should be able >> to provide >>> you information about the preparation work, level of support and >>> interest from the community and initial drafts. >>> >>> Thanks for looking into this and for asking the questions. >>> >>> Dan >>> >>> >>>> -----Original Message----- >>>> From: Ersue, Mehmet (NSN - DE/Munich) >> [mailto:mehmet.ersue@nsn.com] >>>> Sent: Tuesday, April 28, 2009 1:29 PM >>>> To: Romascanu, Dan (Dan) >>>> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage >>>> Maintenance (storm) >>>> >>>> >>>> Hi Dan, >>>> >>>> I believe this is an important and necessary consolidation work. >>>> >>>> I might have missed the discussion on another maillist but >>>> the storm maillist is pretty much new and I would have a >>>> better feeling if there were some mail traffic showing the >>>> interest of the community and/or an initial draft with an >>>> issues list for the justification of a new WG. >>>> >>>> Cheers, >>>> Mehmet >>>> >>>> >>>>> -----Original Message----- >>>>> From: ops-dir-bounces@ietf.org >>>>> [mailto:ops-dir-bounces@ietf.org] On Behalf Of ext Romascanu, >>>>> Dan (Dan) >>>>> Sent: Monday, April 27, 2009 7:57 PM >>>>> To: aaa-doctors@ietf.org; ops-dir@ietf.org >>>>> Subject: [OPS-DIR] FW: Internal WG Review: STORage >>>> Maintenance (storm) >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On >>>>> Behalf Of >>>>> IESG Secretary >>>>> Sent: Monday, April 27, 2009 8:54 PM >>>>> To: iesg@ietf.org; iab@iab.org >>>>> Cc: black_david@emc.com >>>>> Subject: Internal WG Review: STORage Maintenance (storm) >>>>> >>>>> A new IETF working group is being considered in the Transport >>>>> Area. The >>>>> draft charter for this working group is provided below for >>>> your review >>>>> and comment. >>>>> >>>>> Review time is one week. >>>>> >>>>> The IETF Secretariat >>>>> >>>>> STORage Maintenance (storm) >>>>> ---------------------------------- >>>>> >>>>> Last Modified: 2009-04-25 >>>>> >>>>> Current Status: Proposed Working Group >>>>> >>>>> Chairs: >>>>> - David L. Black >>>>> - tbd >>>>> >>>>> Transport Area Director(s): >>>>> - Magnus Westerlund >>>>> - Lars Eggert >>>>> >>>>> Transport Area Advisor: >>>>> - Lars Eggert >>>>> >>>>> Mailing Lists: >>>>> General Discussion: storm@ietf.org >>>>> To Subscribe: storm-request@ietf.org >>>>> In Body: (un)subscribe >>>>> Archive: http://www.ietf.org/mail-archive/web/storm/index.html >>>>> >>>>> Description of Working Group: >>>>> >>>>> The IETF IPS (IP Storage) and RDDP (Remote Direct Data >> Placement) >>>>> working groups have produced a significant number of >>>> storage protocols >>>>> (e.g., iSCSI, iSER and FCIP) for which there is significant >>>> usage. The >>>>> time has come to reflect feedback from implementation and >>> usage into >>>>> updated RFCs; this work may include: >>>>> >>>>> - Implementation-driven revisions and updates to existing >>> protocols >>>>> (i.e., updated RFCs that match the "running code"). >>>>> >>>>> - Interoperability reports as needed for the resulting >>>>> revised protocols >>>>> that are appropriate for Draft Standard RFC status. >>>>> >>>>> - Minor protocol changes or additions. Backwards >> compatibility is >>>>> required. >>>>> >>>>> Significant changes to the existing protocol standards are >>>>> out of scope, >>>>> including any work on version 2 of any of these protocols. >>>>> >>>>> Stability is critical to the usage of these protocols, so >>> backwards >>>>> compatibility with existing implementations will be a >> requirement >>>>> imposed on for all protocol changes and additions. Note >>>> that this is a >>>>> requirement for implementation compatibility - if it is the >>>> case that >>>>> all implementations of a protocol have done something >>> different than >>>>> what the RFC specifies, it is appropriate for a new RFC to >>>>> document what >>>>> the "running code" actually does and deprecate the >> unused original >>>>> behavior. >>>>> >>>>> Initial list of work items: >>>>> >>>>> (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), >> 4850 (node >>>>> architecture key) and 5048 (corrections/clarifications) >>>> into one draft >>>>> (3720bis), removing features that are not implemented in >>>>> practice. This >>>>> draft should be prepared so that it could become a Draft >>>> Standard RFC, >>>>> but it is up to the to decide whether to advance it to >>>> Draft Standard. >>>>> >>>>> (2) iSCSI: Add features to support SAM-4 (4th version >> of the SCSI >>>>> architecture) in a backwards-compatible fashion, as iSCSI >>>> is currently >>>>> based on SAM-2. This will be a separate draft from the >>>> iSCSI update in >>>>> the previous bullet. The Working group may add additional >>>> minor useful >>>>> iSCSI features to this draft. >>>>> >>>>> (3) FCIP: IP Protocol number 133 was allocated to a >>> precursor of the >>>>> FCIP protocol in 2000, but this allocated number is not >>>> used by FCIP. >>>>> The working group will consider whether this allocated number >>>>> should be >>>>> returned to IANA for future reallocation. >>>>> >>>>> (4) iFCP: The Address Translation mode of iFCP needs to be >>>> deprecated >>>>> (SHOULD NOT implement or use), as there are significant >> technical >>>>> problems with its specification, and moreover, only the Address >>>>> Transparent mode of iFCP is in use. This will be done via a >>>>> short draft >>>>> that updates RFC 4172, and not via a complete rewrite of >>> RFC 4172. A >>>>> combined draft is expected that encompasses items (3) and (4). >>>>> >>>>> (5) RDDP MPA: Good support for MPI applications requires a >>>>> small update >>>>> to the startup functionality to allow either end of the >>>> connection to >>>>> initiate. >>>>> >>>>> (6) iSER: Experience with Infiniband implementations suggest >>>>> a few minor >>>>> updates to reflect what has been done in practice. >>>>> >>>>> The working group is expected to maintain good working >>> relationships >>>>> with INCITS Technical Committee T10 (SCSI standards) and INCITS >>>>> Technical Committee T11 (Fibre Channel standards) via >> overlaps in >>>>> membership as opposed to appointment of formal liaisons. >>> The liaison >>>>> process (including IAB appointment of a liaison or >>>>> liaisons) remains available for use if needed. >>>>> >>>>> Goals and Milestones: >>>>> >>>>> June 2009 First version of FCIP protocol number and iFCP Address >>>>> Translation mode draft >>>>> >>>>> July 2009 First version of iSCSI SAM-4 (and other) new >>>> features draft. >>>>> >>>>> Aug 2009 First version of RDDP MPA startup change draft >>>>> >>>>> Sep 2009 Working Group Last Call on FCIP protocol >> number and iFCP >>>>> address change draft >>>>> >>>>> Sep 2009 First version of combined iSCSI draft (3720bis) >>>>> >>>>> Oct 2009 First version of iSER update draft >>>>> >>>>> Oct 2009 Working Group Last Call on RDDP MPA startup >> change draft. >>>>> >>>>> Dec 2009 Functionally complete iSCSI SAM-4 (and other) >>> new features >>>>> draft. >>>>> >>>>> Feb 2010 Working Group Last Call on iSER update draft >>>>> >>>>> March 2010 Working Group Last Call on iSCSI SAM-4 (and >> other) new >>>>> features draft. >>>>> >>>>> April 2010 Working Group decision on whether to seek Draft >>>>> Standard RFC >>>>> status for the combined iSCSI draft (3720bis). [Note: >>>>> decision may be made significantly before this date.] >>>>> >>>>> Sep 2010 Working Group Last Call on combined iSCSI >> draft (3720bis) >>>>> _______________________________________________ >>>>> OPS-DIR mailing list >>>>> OPS-DIR@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ops-dir >>>>> >>>> >>> >>> >> From mehmet.ersue@nsn.com Tue Apr 28 10:32: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 0EDA128C115; Tue, 28 Apr 2009 10:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 tEr+Y0r8U3Bu; Tue, 28 Apr 2009 10:32:30 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id C7A1E3A710B; Tue, 28 Apr 2009 10:32:29 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3SHXjlQ031286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Apr 2009 19:33:45 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3SHXjSn031781; Tue, 28 Apr 2009 19:33:45 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 19:33:44 +0200 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, 28 Apr 2009 19:33:43 +0200 Message-ID: In-Reply-To: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) thread-index: AcnIIKWGCnCLmph2T2uIh2d+fMjKowAAXDow References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Lars Eggert" X-OriginalArrivalTime: 28 Apr 2009 17:33:44.0705 (UTC) FILETIME=[7AD85F10:01C9C827] X-Mailman-Approved-At: Wed, 29 Apr 2009 10:34:02 -0700 Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, Black_David@emc.com, iesg@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 28 Apr 2009 17:32:32 -0000 Lars Eggert wrote: > Hi, >=20 > On 2009-4-28, at 12:29, Ersue, Mehmet (NSN - DE/Munich) wrote: > > unfortunately I missed the Storm BoF in SF. I also was not aware of > > the discussion on the maillists you mention. > > > > I made the experience that announcing a BoF maillist to IETF and > > forcing some discussion on this maillist with IETF member =20 > > participation > > is a good way to show IESG that there is measurable IETF community > > interest. >=20 > as David said below, there was discussion on the=20 > still-existing RDDP, =20 > IPS and IMSS lists, and the BOF went - in my opinion - very well. I =20 > believe community interest has been demonstrated, which is why we're =20 > going forward with a charter proposal. I can imagine core members of imss, rddp and ips always support=20 storage related topics.=20 I was wondering whether there was any invitation to the ietf-discussion=20 prior to the BoF to motivate people to reactivate their subscription for RDDP, IPS and IMSS lists to discuss Storm issues? A separate maillist=20 would be probably more effective. I'm not against a WG, I'm just saying that there is not sufficient positive=20 feedback from the IETF community _on a maillist_ yet. IMO IESG should measure the acceptance of Storm based on the feedback=20 of the broader IETF community based on a maillist discussion. The count of Storm-related mails I can see on the official BoF list (ips)=20 before the BoF session is not overwhelming. =20 > > The huge amount of people in the session, which are sometimes > > occasionally in the room and vote, usually disappear when=20 > it comes to > > maillist discussion. Also for our regular WG work the decisions have > > to be confirmed on the maillist. > > > > As I said I believe this is an important and necessary consolidation > > work but should be discussed and accepted first in the IETF=20 > community. >=20 > I don't quite know what to do with you comment. Are you saying there =20 > hasn't been sufficient discussion to go forward with the chartering? =20 > Or am I misunderstanding? >=20 > I'll also note that the community obviously still has time to=20 > comment =20 > - the charter is in internal I* review at this time, after which it =20 > will go for public review. >=20 > Lars >=20 > > > > Cheers, > > Mehmet > > > > > >> -----Original Message----- > >> From: ext Black_David@emc.com [mailto:Black_David@emc.com] > >> Sent: Tuesday, April 28, 2009 2:32 PM > >> To: Ersue, Mehmet (NSN - DE/Munich) > >> Cc: dromasca@avaya.com; Black_David@emc.com > >> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > >> Maintenance (storm) > >> > >> Mehmet, > >> > >> The storm list is completely new (it was only opened for people > >> to subscribe within the past few days). The storm BOF in San > >> Francisco was organized using the existing IPS, RDDP and IMSS > >> mailing lists. I suggest consulting the archives for those > >> lists, particularly for the IPS list, where you should find a > >> reasonable level of community interest. > >> > >> There is definite community interest in this work, and I have > >> author commitments for drafts for all six work items listed > >> in the charter - each of the "First version of" milestone > >> dates in the proposed charter is based on discussion with an > >> author or authors who believe that a first version of the draft > >> will be ready by that date. > >> > >> Thanks, > >> --David > >> ---------------------------------------------------- > >> David L. Black, Distinguished Engineer > >> EMC Corporation, 176 South St., Hopkinton, MA 01748 > >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > >> black_david@emc.com Mobile: +1 (978) 394-7754 > >> ---------------------------------------------------- > >> > >>> -----Original Message----- > >>> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > >>> Sent: Tuesday, April 28, 2009 6:33 AM > >>> To: Ersue, Mehmet (NSN - DE/Munich) > >>> Cc: Black, David > >>> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > >>> Maintenance (storm) > >>> > >>> Mehmet, > >>> > >>> David Black ran the BOF in San Francisco. He should be able > >> to provide > >>> you information about the preparation work, level of support and > >>> interest from the community and initial drafts. > >>> > >>> Thanks for looking into this and for asking the questions. > >>> > >>> Dan > >>> > >>> > >>>> -----Original Message----- > >>>> From: Ersue, Mehmet (NSN - DE/Munich) > >> [mailto:mehmet.ersue@nsn.com] > >>>> Sent: Tuesday, April 28, 2009 1:29 PM > >>>> To: Romascanu, Dan (Dan) > >>>> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > >>>> Maintenance (storm) > >>>> > >>>> > >>>> Hi Dan, > >>>> > >>>> I believe this is an important and necessary consolidation work. > >>>> > >>>> I might have missed the discussion on another maillist but > >>>> the storm maillist is pretty much new and I would have a > >>>> better feeling if there were some mail traffic showing the > >>>> interest of the community and/or an initial draft with an > >>>> issues list for the justification of a new WG. > >>>> > >>>> Cheers, > >>>> Mehmet > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ops-dir-bounces@ietf.org > >>>>> [mailto:ops-dir-bounces@ietf.org] On Behalf Of ext Romascanu, > >>>>> Dan (Dan) > >>>>> Sent: Monday, April 27, 2009 7:57 PM > >>>>> To: aaa-doctors@ietf.org; ops-dir@ietf.org > >>>>> Subject: [OPS-DIR] FW: Internal WG Review: STORage > >>>> Maintenance (storm) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > >>>>> Behalf Of > >>>>> IESG Secretary > >>>>> Sent: Monday, April 27, 2009 8:54 PM > >>>>> To: iesg@ietf.org; iab@iab.org > >>>>> Cc: black_david@emc.com > >>>>> Subject: Internal WG Review: STORage Maintenance (storm) > >>>>> > >>>>> A new IETF working group is being considered in the Transport > >>>>> Area. The > >>>>> draft charter for this working group is provided below for > >>>> your review > >>>>> and comment. > >>>>> > >>>>> Review time is one week. > >>>>> > >>>>> The IETF Secretariat > >>>>> > >>>>> STORage Maintenance (storm) > >>>>> ---------------------------------- > >>>>> > >>>>> Last Modified: 2009-04-25 > >>>>> > >>>>> Current Status: Proposed Working Group > >>>>> > >>>>> Chairs: > >>>>> - David L. Black > >>>>> - tbd > >>>>> > >>>>> Transport Area Director(s): > >>>>> - Magnus Westerlund > >>>>> - Lars Eggert > >>>>> > >>>>> Transport Area Advisor: > >>>>> - Lars Eggert > >>>>> > >>>>> Mailing Lists: > >>>>> General Discussion: storm@ietf.org > >>>>> To Subscribe: storm-request@ietf.org > >>>>> In Body: (un)subscribe > >>>>> Archive: http://www.ietf.org/mail-archive/web/storm/index.html > >>>>> > >>>>> Description of Working Group: > >>>>> > >>>>> The IETF IPS (IP Storage) and RDDP (Remote Direct Data > >> Placement) > >>>>> working groups have produced a significant number of > >>>> storage protocols > >>>>> (e.g., iSCSI, iSER and FCIP) for which there is significant > >>>> usage. The > >>>>> time has come to reflect feedback from implementation and > >>> usage into > >>>>> updated RFCs; this work may include: > >>>>> > >>>>> - Implementation-driven revisions and updates to existing > >>> protocols > >>>>> (i.e., updated RFCs that match the "running code"). > >>>>> > >>>>> - Interoperability reports as needed for the resulting > >>>>> revised protocols > >>>>> that are appropriate for Draft Standard RFC status. > >>>>> > >>>>> - Minor protocol changes or additions. Backwards > >> compatibility is > >>>>> required. > >>>>> > >>>>> Significant changes to the existing protocol standards are > >>>>> out of scope, > >>>>> including any work on version 2 of any of these protocols. > >>>>> > >>>>> Stability is critical to the usage of these protocols, so > >>> backwards > >>>>> compatibility with existing implementations will be a > >> requirement > >>>>> imposed on for all protocol changes and additions. Note > >>>> that this is a > >>>>> requirement for implementation compatibility - if it is the > >>>> case that > >>>>> all implementations of a protocol have done something > >>> different than > >>>>> what the RFC specifies, it is appropriate for a new RFC to > >>>>> document what > >>>>> the "running code" actually does and deprecate the > >> unused original > >>>>> behavior. > >>>>> > >>>>> Initial list of work items: > >>>>> > >>>>> (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), > >> 4850 (node > >>>>> architecture key) and 5048 (corrections/clarifications) > >>>> into one draft > >>>>> (3720bis), removing features that are not implemented in > >>>>> practice. This > >>>>> draft should be prepared so that it could become a Draft > >>>> Standard RFC, > >>>>> but it is up to the to decide whether to advance it to > >>>> Draft Standard. > >>>>> > >>>>> (2) iSCSI: Add features to support SAM-4 (4th version > >> of the SCSI > >>>>> architecture) in a backwards-compatible fashion, as iSCSI > >>>> is currently > >>>>> based on SAM-2. This will be a separate draft from the > >>>> iSCSI update in > >>>>> the previous bullet. The Working group may add additional > >>>> minor useful > >>>>> iSCSI features to this draft. > >>>>> > >>>>> (3) FCIP: IP Protocol number 133 was allocated to a > >>> precursor of the > >>>>> FCIP protocol in 2000, but this allocated number is not > >>>> used by FCIP. > >>>>> The working group will consider whether this allocated number > >>>>> should be > >>>>> returned to IANA for future reallocation. > >>>>> > >>>>> (4) iFCP: The Address Translation mode of iFCP needs to be > >>>> deprecated > >>>>> (SHOULD NOT implement or use), as there are significant > >> technical > >>>>> problems with its specification, and moreover, only the Address > >>>>> Transparent mode of iFCP is in use. This will be done via a > >>>>> short draft > >>>>> that updates RFC 4172, and not via a complete rewrite of > >>> RFC 4172. A > >>>>> combined draft is expected that encompasses items (3) and (4). > >>>>> > >>>>> (5) RDDP MPA: Good support for MPI applications requires a > >>>>> small update > >>>>> to the startup functionality to allow either end of the > >>>> connection to > >>>>> initiate. > >>>>> > >>>>> (6) iSER: Experience with Infiniband implementations suggest > >>>>> a few minor > >>>>> updates to reflect what has been done in practice. > >>>>> > >>>>> The working group is expected to maintain good working > >>> relationships > >>>>> with INCITS Technical Committee T10 (SCSI standards) and INCITS > >>>>> Technical Committee T11 (Fibre Channel standards) via > >> overlaps in > >>>>> membership as opposed to appointment of formal liaisons. > >>> The liaison > >>>>> process (including IAB appointment of a liaison or > >>>>> liaisons) remains available for use if needed. > >>>>> > >>>>> Goals and Milestones: > >>>>> > >>>>> June 2009 First version of FCIP protocol number and iFCP Address > >>>>> Translation mode draft > >>>>> > >>>>> July 2009 First version of iSCSI SAM-4 (and other) new > >>>> features draft. > >>>>> > >>>>> Aug 2009 First version of RDDP MPA startup change draft > >>>>> > >>>>> Sep 2009 Working Group Last Call on FCIP protocol > >> number and iFCP > >>>>> address change draft > >>>>> > >>>>> Sep 2009 First version of combined iSCSI draft (3720bis) > >>>>> > >>>>> Oct 2009 First version of iSER update draft > >>>>> > >>>>> Oct 2009 Working Group Last Call on RDDP MPA startup > >> change draft. > >>>>> > >>>>> Dec 2009 Functionally complete iSCSI SAM-4 (and other) > >>> new features > >>>>> draft. > >>>>> > >>>>> Feb 2010 Working Group Last Call on iSER update draft > >>>>> > >>>>> March 2010 Working Group Last Call on iSCSI SAM-4 (and > >> other) new > >>>>> features draft. > >>>>> > >>>>> April 2010 Working Group decision on whether to seek Draft > >>>>> Standard RFC > >>>>> status for the combined iSCSI draft (3720bis). [Note: > >>>>> decision may be made significantly before this date.] > >>>>> > >>>>> Sep 2010 Working Group Last Call on combined iSCSI > >> draft (3720bis) > >>>>> _______________________________________________ > >>>>> OPS-DIR mailing list > >>>>> OPS-DIR@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ops-dir > >>>>> > >>>> > >>> > >>> > >> >=20 >=20 From lars.eggert@nokia.com Tue Apr 28 10:47:46 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 ECE4A3A6CE5; Tue, 28 Apr 2009 10:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=1.209, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 c5hyP9JIavsm; Tue, 28 Apr 2009 10:47:46 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 080D93A6CD6; Tue, 28 Apr 2009 10:47:45 -0700 (PDT) Received: from lars-2.vzbi.com (lars-2.vzbi.com [166.58.67.119]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3SHmsIQ024283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Apr 2009 20:48:55 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <784B21B3-0BA4-4780-9D4D-C6BA251A4E39@nokia.com> From: Lars Eggert To: "Ersue, Mehmet (NSN - DE/Munich)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 13:48:49 -0400 References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Tue, 28 Apr 2009 20:48:56 +0300 (EEST) X-Mailman-Approved-At: Wed, 29 Apr 2009 10:34:02 -0700 Cc: "aaa-doctors@ietf.org" , "ops-dir@ietf.org" , "Black_David@emc.com" , "iesg@ietf.org" Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 28 Apr 2009 17:47:47 -0000 Hi, On 2009-4-28, at 13:33, Ersue, Mehmet (NSN - DE/Munich) wrote: > I was wondering whether there was any invitation to the ietf- > discussion > prior to the BoF to motivate people to reactivate their subscription > for > RDDP, IPS and IMSS lists to discuss Storm issues? A separate maillist > would be probably more effective. I don't know if the BOF was announced on the main IETF discussion list, but I note that there is no requirement to do this. The BOF was announced to all the storage-related lists. > I'm not against a WG, I'm just saying that there is not sufficient > positive feedback from the IETF community _on a maillist_ yet. I'm going to disagree here. I saw sufficient positive feedback both on the existing storage lists, in private email and at the BOF itself to initiate the chartering process, esp. considering that STORM is intended as a maintenance WG for a set of existing IETF protocols - those WGs are important, but don't usually draw a huge crowd of excited new contributors. > IMO IESG should measure the acceptance of Storm based on the feedback > of the broader IETF community based on a maillist discussion. > The count of Storm-related mails I can see on the official BoF list > (ips) before the BoF session is not overwhelming. If the broader IETF community speaks up during the upcoming external review and feels that the STORM proposal is problematic in some form, I will certainly listen carefully to any concerns. For now, for a maintenance WG like STORM, I wanted to see that the expert community surrounding these protocols has the energy for continued maintenance, which I saw. Lars From Black_David@emc.com Tue Apr 28 13:47: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 810AF28C1F9; Tue, 28 Apr 2009 13:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q460OH9UsCen; Tue, 28 Apr 2009 13:47:09 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 45ADC3A67AF; Tue, 28 Apr 2009 13:47:09 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n3SKmPEv016698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2009 16:48:27 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Tue, 28 Apr 2009 16:48:24 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n3SKmNFb009523; Tue, 28 Apr 2009 16:48:23 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 16:48: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: Tue, 28 Apr 2009 16:48:22 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A02890B25@CORPUSMX80A.corp.emc.com> In-Reply-To: <02cb01c9c803$d5a0c4b0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnHYUgZTGRgn4EdSua5xFDGQMLP/gAADcrwABE3XjAAFUBm4AAAL7XgAAlduoA= References: <027a01c9c7a6$80495d40$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028905F1@CORPUSMX80A.corp.emc.com> <02cb01c9c803$d5a0c4b0$0600a8c0@china.huawei.com> To: , , , X-OriginalArrivalTime: 28 Apr 2009 20:48:22.0836 (UTC) FILETIME=[AB8DBF40:01C9C842] X-EMM-EM: Active X-Mailman-Approved-At: Wed, 29 Apr 2009 10:34:02 -0700 Cc: iab@ietf.org, iesg@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 28 Apr 2009 20:47:10 -0000 David, > Are the existing storage MIB modules used widely in the industry?=20 > Are the existing storage MIB modules used at all in the industry?=20 > If not, should the WG ask that they be declared historic? > If not, what management is actually used for the IETF storage > protocols? > Does this require standardization to improve interoperability? >=20 > What management is used for the underlying T10/T11 standards? > Should the Internet versions of these protocols use the same > management? > If so, are there any specific changes to our storage protocols that > need to be made to do so? The MIB modules are used to varying degrees. As for other storage management standards, start with these three: [SNIA SMI-S] http://www.snia.org/forums/smi/tech_programs/smis_home/ [SNIA iSCSI HBA API] http://www.snia.org/tech_activities/standards/curr_standards/ima/ [INCITS T11 FC HBA API] = http://www.nssn.org/search/DetailResults.aspx?docid=3D338714&selnode=3D > The IETF has standardized syslog and netconf and ipfix and capwap > since the original versions of the IETF storage standards were > developed. Would any of these new IETF management standards be more > appropriate for addressing specific needs of storage management?=20 I would suggest that a familiarity with storage management standards, starting with the above three, would be a useful step towards answering that question. > The storage industry has been developing rapidly since the IETF > storage protocols were developed. Virtualization, cloud computing, > online backup, data deduplication, federated filesystems, power > consumption issues have all become important considerations in data > center operations and management. Do the management strategies for > operating IETF storage protocols need to be updated to support > emerging trends in the storage industry?=20 >=20 > The proposed charter does not seem to address operability and > manageability of the IETF storage protocols in the current Internet > environment and current storage environments. >=20 > Shouldn't that be part of the work of this WG? Sure, assuming that there's interest in that work - are you volunteering to work on this? Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From ietfdbh@comcast.net Thu Apr 30 05:01:47 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 6ED443A6D0E for ; Thu, 30 Apr 2009 05:01:47 -0700 (PDT) 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 OwA9jZfqEDsR for ; Thu, 30 Apr 2009 05:01:47 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 3A80628C295 for ; Thu, 30 Apr 2009 05:01:44 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA07.westchester.pa.mail.comcast.net with comcast id lmM31b0030cZkys57o23cv; Thu, 30 Apr 2009 12:02:03 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA10.westchester.pa.mail.comcast.net with comcast id lo261b0010UQ6dC3Wo26WD; Thu, 30 Apr 2009 12:02:07 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , , References: Date: Thu, 30 Apr 2009 08:02:04 -0400 Message-ID: <03bb01c9c98b$7aaff9c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnHYUgZTGRgn4EdSua5xFDGQMLP/gAADcrwADAT9bA= X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Cc: 'IAB' , iesg@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 30 Apr 2009 12:01:47 -0000 Hi, SAM-4 compatibility is an explicit goal of the charter. The T10 website says "Only T10 members are permitted to access this document" Will the SAM-4 documents be made freely available to members/participants of the STORM WG? dbh > -----Original Message----- > From: ops-dir-bounces@ietf.org > [mailto:ops-dir-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Monday, April 27, 2009 1:57 PM > To: aaa-doctors@ietf.org; ops-dir@ietf.org > Subject: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) > > > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > Behalf Of > IESG Secretary > Sent: Monday, April 27, 2009 8:54 PM > To: iesg@ietf.org; iab@iab.org > Cc: black_david@emc.com > Subject: Internal WG Review: STORage Maintenance (storm) > > A new IETF working group is being considered in the Transport > Area. The > draft charter for this working group is provided below for your review > and comment. > > Review time is one week. > > The IETF Secretariat > > STORage Maintenance (storm) > ---------------------------------- > > Last Modified: 2009-04-25 > > Current Status: Proposed Working Group > > Chairs: > - David L. Black > - tbd > > Transport Area Director(s): > - Magnus Westerlund > - Lars Eggert > > Transport Area Advisor: > - Lars Eggert > > Mailing Lists: > General Discussion: storm@ietf.org > To Subscribe: storm-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/storm/index.html > > Description of Working Group: > > The IETF IPS (IP Storage) and RDDP (Remote Direct Data Placement) > working groups have produced a significant number of storage protocols > (e.g., iSCSI, iSER and FCIP) for which there is significant usage. The > time has come to reflect feedback from implementation and usage into > updated RFCs; this work may include: > > - Implementation-driven revisions and updates to existing protocols > (i.e., updated RFCs that match the "running code"). > > - Interoperability reports as needed for the resulting > revised protocols > that are appropriate for Draft Standard RFC status. > > - Minor protocol changes or additions. Backwards compatibility is > required. > > Significant changes to the existing protocol standards are > out of scope, > including any work on version 2 of any of these protocols. > > Stability is critical to the usage of these protocols, so backwards > compatibility with existing implementations will be a requirement > imposed on for all protocol changes and additions. Note that this is a > requirement for implementation compatibility - if it is the case that > all implementations of a protocol have done something different than > what the RFC specifies, it is appropriate for a new RFC to > document what > the "running code" actually does and deprecate the unused original > behavior. > > Initial list of work items: > > (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node > architecture key) and 5048 (corrections/clarifications) into one draft > (3720bis), removing features that are not implemented in > practice. This > draft should be prepared so that it could become a Draft Standard RFC, > but it is up to the to decide whether to advance it to Draft Standard. > > (2) iSCSI: Add features to support SAM-4 (4th version of the SCSI > architecture) in a backwards-compatible fashion, as iSCSI is currently > based on SAM-2. This will be a separate draft from the iSCSI update in > the previous bullet. The Working group may add additional minor useful > iSCSI features to this draft. > > (3) FCIP: IP Protocol number 133 was allocated to a precursor of the > FCIP protocol in 2000, but this allocated number is not used by FCIP. > The working group will consider whether this allocated number > should be > returned to IANA for future reallocation. > > (4) iFCP: The Address Translation mode of iFCP needs to be deprecated > (SHOULD NOT implement or use), as there are significant technical > problems with its specification, and moreover, only the Address > Transparent mode of iFCP is in use. This will be done via a > short draft > that updates RFC 4172, and not via a complete rewrite of RFC 4172. A > combined draft is expected that encompasses items (3) and (4). > > (5) RDDP MPA: Good support for MPI applications requires a > small update > to the startup functionality to allow either end of the connection to > initiate. > > (6) iSER: Experience with Infiniband implementations suggest > a few minor > updates to reflect what has been done in practice. > > The working group is expected to maintain good working relationships > with INCITS Technical Committee T10 (SCSI standards) and INCITS > Technical Committee T11 (Fibre Channel standards) via overlaps in > membership as opposed to appointment of formal liaisons. The liaison > process (including IAB appointment of a liaison or > liaisons) remains available for use if needed. > > Goals and Milestones: > > June 2009 First version of FCIP protocol number and iFCP Address > Translation mode draft > > July 2009 First version of iSCSI SAM-4 (and other) new features draft. > > Aug 2009 First version of RDDP MPA startup change draft > > Sep 2009 Working Group Last Call on FCIP protocol number and iFCP > address change draft > > Sep 2009 First version of combined iSCSI draft (3720bis) > > Oct 2009 First version of iSER update draft > > Oct 2009 Working Group Last Call on RDDP MPA startup change draft. > > Dec 2009 Functionally complete iSCSI SAM-4 (and other) new features > draft. > > Feb 2010 Working Group Last Call on iSER update draft > > March 2010 Working Group Last Call on iSCSI SAM-4 (and other) new > features draft. > > April 2010 Working Group decision on whether to seek Draft > Standard RFC > status for the combined iSCSI draft (3720bis). [Note: > decision may be made significantly before this date.] > > Sep 2010 Working Group Last Call on combined iSCSI draft (3720bis) > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir > From Black_David@emc.com Thu Apr 30 05:15: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 F253928C0E6; Thu, 30 Apr 2009 05:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrV+L8KSAWeL; Thu, 30 Apr 2009 05:14:58 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id A0FA53A68DF; Thu, 30 Apr 2009 05:14:58 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n3UCGGKx014448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2009 08:16:16 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si03.isus.emc.com (Tablus Interceptor); Thu, 30 Apr 2009 08:16:13 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n3UCG8hx008107; Thu, 30 Apr 2009 08:16:12 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 08:16:11 -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, 30 Apr 2009 08:16:10 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A028EAA65@CORPUSMX80A.corp.emc.com> In-Reply-To: <03bb01c9c98b$7aaff9c0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnHYUgZTGRgn4EdSua5xFDGQMLP/gAADcrwADAT9bAAWqvBoA== References: <03bb01c9c98b$7aaff9c0$0600a8c0@china.huawei.com> To: , , , X-OriginalArrivalTime: 30 Apr 2009 12:16:11.0039 (UTC) FILETIME=[72CD2AF0:01C9C98D] X-EMM-EM: Active Cc: iab@ietf.org, iesg@ietf.org, Black_David@emc.com Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 30 Apr 2009 12:15:00 -0000 David, Yes, something needs to be done to make this happen, thanks for the reminder. T10 meets next week - I'll need to talk to the responsible people next week in order to figure out how to go about this, as the rules that cause this inaccessibility were imposed on T10 from above by INCITS. I will have a solution to this problem before the IESG is asked to approve the storm WG charter. Thanks, --David =20 > -----Original Message----- > From: ops-dir-bounces@ietf.org=20 > [mailto:ops-dir-bounces@ietf.org] On Behalf Of David Harrington > Sent: Thursday, April 30, 2009 8:02 AM > To: 'Romascanu, Dan (Dan)'; aaa-doctors@ietf.org; ops-dir@ietf.org > Cc: 'IAB'; iesg@ietf.org > Subject: Re: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance (storm) >=20 >=20 > Hi, >=20 > SAM-4 compatibility is an explicit goal of the charter. > The T10 website says "Only T10 members are permitted to access this > document" >=20 > Will the SAM-4 documents be made freely available to > members/participants of the STORM WG? >=20 > dbh >=20 > > -----Original Message----- > > From: ops-dir-bounces@ietf.org=20 > > [mailto:ops-dir-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > > Sent: Monday, April 27, 2009 1:57 PM > > To: aaa-doctors@ietf.org; ops-dir@ietf.org > > Subject: [OPS-DIR] FW: Internal WG Review: STORage Maintenance > (storm) > >=20 > > =20 > >=20 > > -----Original Message----- > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > > Behalf Of > > IESG Secretary > > Sent: Monday, April 27, 2009 8:54 PM > > To: iesg@ietf.org; iab@iab.org > > Cc: black_david@emc.com > > Subject: Internal WG Review: STORage Maintenance (storm)=20 > >=20 > > A new IETF working group is being considered in the Transport=20 > > Area. The > > draft charter for this working group is provided below for your > review > > and comment. > >=20 > > Review time is one week. > >=20 > > The IETF Secretariat > >=20 > > STORage Maintenance (storm) > > ---------------------------------- > >=20 > > Last Modified: 2009-04-25 > >=20 > > Current Status: Proposed Working Group > >=20 > > Chairs: > > - David L. Black > > - tbd > >=20 > > Transport Area Director(s): > > - Magnus Westerlund > > - Lars Eggert > >=20 > > Transport Area Advisor: > > - Lars Eggert > >=20 > > Mailing Lists: > > General Discussion: storm@ietf.org > > To Subscribe: storm-request@ietf.org > > In Body: (un)subscribe > > Archive: http://www.ietf.org/mail-archive/web/storm/index.html > >=20 > > Description of Working Group: > >=20 > > The IETF IPS (IP Storage) and RDDP (Remote Direct Data Placement) > > working groups have produced a significant number of storage > protocols > > (e.g., iSCSI, iSER and FCIP) for which there is significant usage. > The > > time has come to reflect feedback from implementation and usage into > > updated RFCs; this work may include: > >=20 > > - Implementation-driven revisions and updates to existing protocols > > (i.e., updated RFCs that match the "running code"). > >=20 > > - Interoperability reports as needed for the resulting=20 > > revised protocols > > that are appropriate for Draft Standard RFC status. > >=20 > > - Minor protocol changes or additions. Backwards compatibility is > > required. > >=20 > > Significant changes to the existing protocol standards are=20 > > out of scope, > > including any work on version 2 of any of these protocols. > >=20 > > Stability is critical to the usage of these protocols, so backwards > > compatibility with existing implementations will be a requirement > > imposed on for all protocol changes and additions. Note that this is > a > > requirement for implementation compatibility - if it is the case > that > > all implementations of a protocol have done something different than > > what the RFC specifies, it is appropriate for a new RFC to=20 > > document what > > the "running code" actually does and deprecate the unused original > > behavior. > >=20 > > Initial list of work items: > >=20 > > (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node > > architecture key) and 5048 (corrections/clarifications) into one > draft > > (3720bis), removing features that are not implemented in=20 > > practice. This > > draft should be prepared so that it could become a Draft Standard > RFC, > > but it is up to the to decide whether to advance it to Draft > Standard. > >=20 > > (2) iSCSI: Add features to support SAM-4 (4th version of the SCSI > > architecture) in a backwards-compatible fashion, as iSCSI is > currently > > based on SAM-2. This will be a separate draft from the iSCSI update > in > > the previous bullet. The Working group may add additional minor > useful > > iSCSI features to this draft. > >=20 > > (3) FCIP: IP Protocol number 133 was allocated to a precursor of the > > FCIP protocol in 2000, but this allocated number is not used by > FCIP. > > The working group will consider whether this allocated number=20 > > should be > > returned to IANA for future reallocation. > >=20 > > (4) iFCP: The Address Translation mode of iFCP needs to be > deprecated > > (SHOULD NOT implement or use), as there are significant technical > > problems with its specification, and moreover, only the Address > > Transparent mode of iFCP is in use. This will be done via a=20 > > short draft > > that updates RFC 4172, and not via a complete rewrite of RFC 4172. A > > combined draft is expected that encompasses items (3) and (4). > >=20 > > (5) RDDP MPA: Good support for MPI applications requires a=20 > > small update > > to the startup functionality to allow either end of the connection > to > > initiate. > >=20 > > (6) iSER: Experience with Infiniband implementations suggest=20 > > a few minor > > updates to reflect what has been done in practice. > >=20 > > The working group is expected to maintain good working relationships > > with INCITS Technical Committee T10 (SCSI standards) and INCITS > > Technical Committee T11 (Fibre Channel standards) via overlaps in > > membership as opposed to appointment of formal liaisons. The liaison > > process (including IAB appointment of a liaison or > > liaisons) remains available for use if needed. > >=20 > > Goals and Milestones: > >=20 > > June 2009 First version of FCIP protocol number and iFCP Address > > Translation mode draft > >=20 > > July 2009 First version of iSCSI SAM-4 (and other) new features > draft. > >=20 > > Aug 2009 First version of RDDP MPA startup change draft > >=20 > > Sep 2009 Working Group Last Call on FCIP protocol number and iFCP > > address change draft > >=20 > > Sep 2009 First version of combined iSCSI draft (3720bis) > >=20 > > Oct 2009 First version of iSER update draft > >=20 > > Oct 2009 Working Group Last Call on RDDP MPA startup change draft. > >=20 > > Dec 2009 Functionally complete iSCSI SAM-4 (and other) new features > > draft. > >=20 > > Feb 2010 Working Group Last Call on iSER update draft > >=20 > > March 2010 Working Group Last Call on iSCSI SAM-4 (and other) new > > features draft. > >=20 > > April 2010 Working Group decision on whether to seek Draft=20 > > Standard RFC > > status for the combined iSCSI draft (3720bis). [Note: > > decision may be made significantly before this date.] > >=20 > > Sep 2010 Working Group Last Call on combined iSCSI draft (3720bis) > > _______________________________________________ > > OPS-DIR mailing list > > OPS-DIR@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-dir > >=20 >=20 > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir >=20 >=20 From dromasca@avaya.com Thu Apr 30 05:45:06 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 03B5A3A694D; Thu, 30 Apr 2009 05:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=1.086, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 YlP5LDIfVCCU; Thu, 30 Apr 2009 05:45:05 -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 EA2333A68FF; Thu, 30 Apr 2009 05:45:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,273,1238990400"; d="scan'208";a="169494533" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 30 Apr 2009 08:46:27 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 30 Apr 2009 08:46: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: Thu, 30 Apr 2009 14:45:49 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnIIKWGCnCLmph2T2uIh2d+fMjKowAAXDowAFvI75A= References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com> From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Munich)" , "ext Lars Eggert" Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, Black_David@emc.com, iesg@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 30 Apr 2009 12:45:06 -0000 =20 > -----Original Message----- > From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com]=20 > Sent: Tuesday, April 28, 2009 8:34 PM > To: ext Lars Eggert > Cc: Black_David@emc.com; Romascanu, Dan (Dan);=20 > ops-dir@ietf.org; aaa-doctors@ietf.org; iesg@ietf.org > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance (storm) >=20 >=20 > Lars Eggert wrote: > > Hi, > >=20 > > On 2009-4-28, at 12:29, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > unfortunately I missed the Storm BoF in SF. I also was=20 > not aware of=20 > > > the discussion on the maillists you mention. > > > > > > I made the experience that announcing a BoF maillist to IETF and=20 > > > forcing some discussion on this maillist with IETF member=20 > > > participation is a good way to show IESG that there is measurable=20 > > > IETF community interest. > >=20 > > as David said below, there was discussion on the=20 > still-existing RDDP,=20 > > IPS and IMSS lists, and the BOF went - in my opinion - very well. I=20 > > believe community interest has been demonstrated, which is=20 > why we're=20 > > going forward with a charter proposal. >=20 > I can imagine core members of imss, rddp and ips always=20 > support storage related topics.=20 > I was wondering whether there was any invitation to the=20 > ietf-discussion prior to the BoF to motivate people to=20 > reactivate their subscription for >=20 > RDDP, IPS and IMSS lists to discuss Storm issues? A separate=20 > maillist would be probably more effective. >=20 > I'm not against a WG, I'm just saying that there is not=20 > sufficient positive feedback from the IETF community _on a=20 > maillist_ yet. >=20 > IMO IESG should measure the acceptance of Storm based on the=20 > feedback of the broader IETF community based on a maillist discussion. > The count of Storm-related mails I can see on the official BoF list > (ips) > before the BoF session is not overwhelming. > =20 I believe that the level of interest will be judged (also) when the charter will go out for broad IETF external review.=20 Until then can we get a feeling about the number of people who attended the BOF, how many people expressed support for formation of a WG, how many raised their hands (in the room and virtually on the mail lists) volunteering to contribute? Dan =20 From dromasca@avaya.com Thu Apr 30 05:49:54 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 A99A828C2C0; Thu, 30 Apr 2009 05:49:54 -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 zqoohfy+X1xs; Thu, 30 Apr 2009 05:49:53 -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 A39413A720B; Thu, 30 Apr 2009 05:49:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,273,1238990400"; d="scan'208";a="144534277" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Apr 2009 08:51:13 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 30 Apr 2009 08:51:12 -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, 30 Apr 2009 14:51:10 +0200 Message-ID: In-Reply-To: <9FA859626025B64FBC2AF149D97C944A02890B25@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnHYUgZTGRgn4EdSua5xFDGQMLP/gAADcrwABE3XjAAFUBm4AAAL7XgAAlduoAAXAxhcA== References: <027a01c9c7a6$80495d40$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A028905F1@CORPUSMX80A.corp.emc.com> <02cb01c9c803$d5a0c4b0$0600a8c0@china.huawei.com> <9FA859626025B64FBC2AF149D97C944A02890B25@CORPUSMX80A.corp.emc.com> From: "Romascanu, Dan (Dan)" To: , , , Cc: iab@ietf.org, iesg@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 30 Apr 2009 12:49:54 -0000 =20 > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > Sent: Tuesday, April 28, 2009 11:48 PM > To: ietfdbh@comcast.net; Romascanu, Dan (Dan);=20 > aaa-doctors@ietf.org; ops-dir@ietf.org > Cc: iab@ietf.org; iesg@ietf.org > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance (storm) >=20 > David, >=20 > > Are the existing storage MIB modules used widely in the industry?=20 > > Are the existing storage MIB modules used at all in the industry?=20 > > If not, should the WG ask that they be declared historic? > > If not, what management is actually used for the IETF storage=20 > > protocols? > > Does this require standardization to improve interoperability? > >=20 > > What management is used for the underlying T10/T11 standards? > > Should the Internet versions of these protocols use the same=20 > > management? > > If so, are there any specific changes to our storage protocols that=20 > > need to be made to do so? >=20 > The MIB modules are used to varying degrees. As for other=20 > storage management standards, start with these three: >=20 > [SNIA SMI-S] > http://www.snia.org/forums/smi/tech_programs/smis_home/ > [SNIA iSCSI HBA API] > http://www.snia.org/tech_activities/standards/curr_standards/ima/ > [INCITS T11 FC HBA API] > = http://www.nssn.org/search/DetailResults.aspx?docid=3D338714&selnode=3D >=20 > > The IETF has standardized syslog and netconf and ipfix and capwap=20 > > since the original versions of the IETF storage standards were=20 > > developed. Would any of these new IETF management standards be more=20 > > appropriate for addressing specific needs of storage management? >=20 > I would suggest that a familiarity with storage management=20 > standards, starting with the above three, would be a useful=20 > step towards answering that question. >=20 > > The storage industry has been developing rapidly since the IETF=20 > > storage protocols were developed. Virtualization, cloud computing,=20 > > online backup, data deduplication, federated filesystems, power=20 > > consumption issues have all become important considerations in data=20 > > center operations and management. Do the management strategies for=20 > > operating IETF storage protocols need to be updated to support=20 > > emerging trends in the storage industry? > >=20 > > The proposed charter does not seem to address operability and=20 > > manageability of the IETF storage protocols in the current Internet=20 > > environment and current storage environments. > >=20 > > Shouldn't that be part of the work of this WG? >=20 > Sure, assuming that there's interest in that work - are you=20 > volunteering to work on this? >=20 It is not that simple :-) David Harrington is asking I believe the right questions concerning the operations aspects manageability of the technology - these questions need to be asked any time a new technology or extensions of existing technologies are being proposed for standardization over the Internet. These questions need to be answered before a working group can be chartered - it is up to the folks proposing a new charter to explain how the operational aspects and the manageability of the IETF storage protocols will be dealt with by the new WG.=20 Dan From dromasca@avaya.com Thu Apr 30 06:11: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 BD49E3A720D; Thu, 30 Apr 2009 06:11:41 -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 O47kogKyWzAO; Thu, 30 Apr 2009 06:11:40 -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 0A35928C0FA; Thu, 30 Apr 2009 06:11:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,273,1238990400"; d="scan'208";a="169498480" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 30 Apr 2009 09:12:39 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Apr 2009 09:12:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 15:11:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internal WG Review: Yet Another Mail (yam) Thread-Index: AcnJDetrfruj7kVpStqJA6Pv7W/AZQAh0tWw From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Internal WG Review: Yet Another Mail (yam) 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, 30 Apr 2009 13:11:41 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Thursday, April 30, 2009 12:01 AM To: iesg@ietf.org; iab@iab.org Subject: Internal WG Review: Yet Another Mail (yam)=20 A new IETF working group is being considered in the Applications Area.=20 The draft charter for this working group is provided below for your review and comment. Review time is one week. The IETF Secretariat Yet Another Mail (yam) ---------------------------------- Last Modified: 2009-04-29 Current Status: Proposed Working Group Chair(s): Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Mailing Lists: http://mipassoc.org/mailman/listinfo/ietf-yam Description of Working Group: The Yet Another Mail (YAM) WG will revise existing Internet Mail specifications currently at Draft Standard to advance them to Full Standard. YAM will focus strictly on advancing email-related specifications for which the community already has some years of experience with deployment and interoperability. Its function is not to reopen or reconsider protocols - if a specification is found to need significant technical work, YAM will remove it from the WG's agenda. This charter's scope of work is the set of email-related RFCs that are currently at Draft Standard. Each document will be examined, along with its errata, and a recommendation made as to whether it is suitable for advancement to Full Standard. If it is not, the WG may recommend whether it should be republished at Draft Standard, moved to Historic, or recycled to Proposed Standard. However, any actual work to facilitate publication of a document at other than Full Standard is outside the WG's scope. If the WG cannot quickly reach consensus about further work on a document, it will drop the documents from its agenda without further comment or effort. The purpose of this working group is to work on protocols that are already recognized as effectively full standards, improving their written specifications to align with that status. The working group does not intend to revise the actual protocols in any way and will avoid document changes that might even accidentally introduce protocol changes, destabilize a protocol, or introduce semantic or syntactic changes. In particular, it will avoid adding new document sections that were not previously required and making gratuitous BNF grammar changes. If an existing protocol implementation is conforming to the Draft Standard version of the protocol specification, it must also be conforming to the resulting Full Standard version. Hence, specification changes that create a violation of this requirement are out of scope of the working group charter. On a case by case basis, substantive changes may be considered, if they will modify text to match existing conforming implementations -- that is, implementations that are already deployed with significant use. Specifically, such changes will be permitted to relax requirements (such as changing a MUST to a MAY) or to fix BNF bugs where the intent is and has been clear. In any event, agreement will be reached with the IESG about the changes to be made to a given document before work starts on it After the tasks of this charter are completed, the WG will consider rechartering to move selected mature specifications that are still at Proposed Standard to higher maturity levels, or to work on those documents previously identified as needing to be republished at Draft Standard or Proposed Standard. The underpinnings of this WG effort are: (1) Wide deployment and use of interoperable implementations of an existing standards-track protocol creates a presumption that the existing specification is adequate. The burden of demonstrating the contrary lies with those who believe that they see significant technical or documentation defects. (2) It is generally in the best interest of the IETF and the Internet community to see specifications of mature protocols advance on the standards track, eliminating any uncertainty as to whether the protocols have been adequately understood and tested. To that end, YAM will avoid modification of documents simply to adjust them to match contemporary IETF procedural, section list, notational or linguistic norms. Obviously, updating of references, boilerplate, and the equivalent are exceptions to this, but success in the WG requires that there be a good-faith commitment by both its participants and the IESG to avoid seeking changes that (a) do not contribute in a substantial and substantive way to the quality and comprehensibility of the specification, or that (b) force a change to the existing protocol. ------------------- Benchmarks (dates to be determined) Compile a list of potentially-relevant documents. The list of documents that are now at Draft Standard that appear to be email related is as follows. Per the next benchmark, some of these are not likely to be considered by the WG, nor does order of publication imply order of importance. The steps to be followed are, approximately: o Review the document list, removing any that have significant technical defects or whose advancement may be controversial under the advancement criteria specified in RFC 2026. o Form review and editing teams for each document to be advanced. o Formulate a list of proposed changes (stated in general terms, rather than specific wording). o Obtain WG consensus and IESG agreement on these changes. o Post I-Ds for WG consideration and consensus formation. o Recommend resulting documents to IESG for publication processing. o Rinse and repeat. From ietfdbh@comcast.net Thu Apr 30 09:28:39 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 9109B3A7222 for ; Thu, 30 Apr 2009 09:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 CIDDI77eGbib for ; Thu, 30 Apr 2009 09:28:37 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 5FCCF3A722A for ; Thu, 30 Apr 2009 09:28:36 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA06.westchester.pa.mail.comcast.net with comcast id lpQV1b0041GhbT856sVwHw; Thu, 30 Apr 2009 16:29:56 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA07.westchester.pa.mail.comcast.net with comcast id lsVz1b0040UQ6dC3TsVzoJ; Thu, 30 Apr 2009 16:30:00 +0000 From: "David Harrington" To: "'Lars Eggert'" , "'Ersue, Mehmet \(NSN - DE/Munich\)'" References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com> Date: Thu, 30 Apr 2009 12:29:57 -0400 Message-ID: <03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnIIsLVYL2tgvRISvuD66VyOWuZ3wBiB/uw X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com> Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, 'IAB' , Black_David@emc.com, iesg@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 30 Apr 2009 16:28:39 -0000 Hi, I found that having the discussion for the STORM BOF on the mailing lists for (three) concluded WGs made it a bit obscure. As far as I can tell by looking at those archives, there wasn't much discussion. I will also note that the announcement of the craetion of the storm list seems to be have been only announced to the lists of the three concluded WGs. So if you weren't involved in the three earlier WGs, you might not have seen the announcement. I do think Mehmet has a point that many IETF people may not have been aware the discussion was happening. As an OPSDIR member and MIB Doctor, I have already expressed concerns that operations and management is not being addressed in the charter. The chair helpfully responded with a short list of management standards (SNIA SMI-S, SNIA SCSI HBA, INCITS FC HBA) that might help answer my questions. Unfortunately, I cannot access some of the documents referenced because they are not freely available. If I read through a number of large standards I might be able to determine for myself what changes might need to be made to utilize the existing non-IETF standards to manage the updated IETF storage standards. I think I would rather see the WG consdier this and document it, rather than me (and any other user of the IETF technologies) having to research this personally to know the answers. I would nto say my concerns have been addressed. As a SECDIR member, I have concerns that security may not be gettng addressed either, but it is hard for me to say that for sure since I cannot freely access the T10 and T11 documents that are the basis of the updates. I do not know whether the updated IETF storage standards will utilize IETF standards for security or non-IETF stndards for security, or whether the WG is simply not going to address security issues since it is not mentioned in the charter. I note that the charter calls for updating to SAM-4 level, and that T10 is starting new work on SAM-5, explicitly to address security. So does that mean security will not be addressed in the STORM WG? I have not seen these discussions elsewhere. And Mehmet's concerns seem to be relevant to that point. Before the WG is created, I think the charter should be explicit about the what the WG will do to address how these Internet protocols should be operated and managed and secured. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: ops-dir-bounces@ietf.org > [mailto:ops-dir-bounces@ietf.org] On Behalf Of Lars Eggert > Sent: Tuesday, April 28, 2009 12:44 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; > Black_David@emc.com; iesg@ietf.org > Subject: Re: [OPS-DIR] FW: Internal WG Review: STORage > Maintenance (storm) > > Hi, > > On 2009-4-28, at 12:29, Ersue, Mehmet (NSN - DE/Munich) wrote: > > unfortunately I missed the Storm BoF in SF. I also was not aware of > > the discussion on the maillists you mention. > > > > I made the experience that announcing a BoF maillist to IETF and > > forcing some discussion on this maillist with IETF member > > participation > > is a good way to show IESG that there is measurable IETF community > > interest. > > as David said below, there was discussion on the > still-existing RDDP, > IPS and IMSS lists, and the BOF went - in my opinion - very well. I > believe community interest has been demonstrated, which is why we're > going forward with a charter proposal. > > > The huge amount of people in the session, which are sometimes > > occasionally in the room and vote, usually disappear when > it comes to > > maillist discussion. Also for our regular WG work the decisions have > > to be confirmed on the maillist. > > > > As I said I believe this is an important and necessary consolidation > > work but should be discussed and accepted first in the IETF > community. > > I don't quite know what to do with you comment. Are you saying there > hasn't been sufficient discussion to go forward with the chartering? > Or am I misunderstanding? > > I'll also note that the community obviously still has time to > comment > - the charter is in internal I* review at this time, after which it > will go for public review. > > Lars > > > > > Cheers, > > Mehmet > > > > > >> -----Original Message----- > >> From: ext Black_David@emc.com [mailto:Black_David@emc.com] > >> Sent: Tuesday, April 28, 2009 2:32 PM > >> To: Ersue, Mehmet (NSN - DE/Munich) > >> Cc: dromasca@avaya.com; Black_David@emc.com > >> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > >> Maintenance (storm) > >> > >> Mehmet, > >> > >> The storm list is completely new (it was only opened for people > >> to subscribe within the past few days). The storm BOF in San > >> Francisco was organized using the existing IPS, RDDP and IMSS > >> mailing lists. I suggest consulting the archives for those > >> lists, particularly for the IPS list, where you should find a > >> reasonable level of community interest. > >> > >> There is definite community interest in this work, and I have > >> author commitments for drafts for all six work items listed > >> in the charter - each of the "First version of" milestone > >> dates in the proposed charter is based on discussion with an > >> author or authors who believe that a first version of the draft > >> will be ready by that date. > >> > >> Thanks, > >> --David > >> ---------------------------------------------------- > >> David L. Black, Distinguished Engineer > >> EMC Corporation, 176 South St., Hopkinton, MA 01748 > >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > >> black_david@emc.com Mobile: +1 (978) 394-7754 > >> ---------------------------------------------------- > >> > >>> -----Original Message----- > >>> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > >>> Sent: Tuesday, April 28, 2009 6:33 AM > >>> To: Ersue, Mehmet (NSN - DE/Munich) > >>> Cc: Black, David > >>> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > >>> Maintenance (storm) > >>> > >>> Mehmet, > >>> > >>> David Black ran the BOF in San Francisco. He should be able > >> to provide > >>> you information about the preparation work, level of support and > >>> interest from the community and initial drafts. > >>> > >>> Thanks for looking into this and for asking the questions. > >>> > >>> Dan > >>> > >>> > >>>> -----Original Message----- > >>>> From: Ersue, Mehmet (NSN - DE/Munich) > >> [mailto:mehmet.ersue@nsn.com] > >>>> Sent: Tuesday, April 28, 2009 1:29 PM > >>>> To: Romascanu, Dan (Dan) > >>>> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > >>>> Maintenance (storm) > >>>> > >>>> > >>>> Hi Dan, > >>>> > >>>> I believe this is an important and necessary consolidation work. > >>>> > >>>> I might have missed the discussion on another maillist but > >>>> the storm maillist is pretty much new and I would have a > >>>> better feeling if there were some mail traffic showing the > >>>> interest of the community and/or an initial draft with an > >>>> issues list for the justification of a new WG. > >>>> > >>>> Cheers, > >>>> Mehmet > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ops-dir-bounces@ietf.org > >>>>> [mailto:ops-dir-bounces@ietf.org] On Behalf Of ext Romascanu, > >>>>> Dan (Dan) > >>>>> Sent: Monday, April 27, 2009 7:57 PM > >>>>> To: aaa-doctors@ietf.org; ops-dir@ietf.org > >>>>> Subject: [OPS-DIR] FW: Internal WG Review: STORage > >>>> Maintenance (storm) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > >>>>> Behalf Of > >>>>> IESG Secretary > >>>>> Sent: Monday, April 27, 2009 8:54 PM > >>>>> To: iesg@ietf.org; iab@iab.org > >>>>> Cc: black_david@emc.com > >>>>> Subject: Internal WG Review: STORage Maintenance (storm) > >>>>> > >>>>> A new IETF working group is being considered in the Transport > >>>>> Area. The > >>>>> draft charter for this working group is provided below for > >>>> your review > >>>>> and comment. > >>>>> > >>>>> Review time is one week. > >>>>> > >>>>> The IETF Secretariat > >>>>> > >>>>> STORage Maintenance (storm) > >>>>> ---------------------------------- > >>>>> > >>>>> Last Modified: 2009-04-25 > >>>>> > >>>>> Current Status: Proposed Working Group > >>>>> > >>>>> Chairs: > >>>>> - David L. Black > >>>>> - tbd > >>>>> > >>>>> Transport Area Director(s): > >>>>> - Magnus Westerlund > >>>>> - Lars Eggert > >>>>> > >>>>> Transport Area Advisor: > >>>>> - Lars Eggert > >>>>> > >>>>> Mailing Lists: > >>>>> General Discussion: storm@ietf.org > >>>>> To Subscribe: storm-request@ietf.org > >>>>> In Body: (un)subscribe > >>>>> Archive: http://www.ietf.org/mail-archive/web/storm/index.html > >>>>> > >>>>> Description of Working Group: > >>>>> > >>>>> The IETF IPS (IP Storage) and RDDP (Remote Direct Data > >> Placement) > >>>>> working groups have produced a significant number of > >>>> storage protocols > >>>>> (e.g., iSCSI, iSER and FCIP) for which there is significant > >>>> usage. The > >>>>> time has come to reflect feedback from implementation and > >>> usage into > >>>>> updated RFCs; this work may include: > >>>>> > >>>>> - Implementation-driven revisions and updates to existing > >>> protocols > >>>>> (i.e., updated RFCs that match the "running code"). > >>>>> > >>>>> - Interoperability reports as needed for the resulting > >>>>> revised protocols > >>>>> that are appropriate for Draft Standard RFC status. > >>>>> > >>>>> - Minor protocol changes or additions. Backwards > >> compatibility is > >>>>> required. > >>>>> > >>>>> Significant changes to the existing protocol standards are > >>>>> out of scope, > >>>>> including any work on version 2 of any of these protocols. > >>>>> > >>>>> Stability is critical to the usage of these protocols, so > >>> backwards > >>>>> compatibility with existing implementations will be a > >> requirement > >>>>> imposed on for all protocol changes and additions. Note > >>>> that this is a > >>>>> requirement for implementation compatibility - if it is the > >>>> case that > >>>>> all implementations of a protocol have done something > >>> different than > >>>>> what the RFC specifies, it is appropriate for a new RFC to > >>>>> document what > >>>>> the "running code" actually does and deprecate the > >> unused original > >>>>> behavior. > >>>>> > >>>>> Initial list of work items: > >>>>> > >>>>> (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), > >> 4850 (node > >>>>> architecture key) and 5048 (corrections/clarifications) > >>>> into one draft > >>>>> (3720bis), removing features that are not implemented in > >>>>> practice. This > >>>>> draft should be prepared so that it could become a Draft > >>>> Standard RFC, > >>>>> but it is up to the to decide whether to advance it to > >>>> Draft Standard. > >>>>> > >>>>> (2) iSCSI: Add features to support SAM-4 (4th version > >> of the SCSI > >>>>> architecture) in a backwards-compatible fashion, as iSCSI > >>>> is currently > >>>>> based on SAM-2. This will be a separate draft from the > >>>> iSCSI update in > >>>>> the previous bullet. The Working group may add additional > >>>> minor useful > >>>>> iSCSI features to this draft. > >>>>> > >>>>> (3) FCIP: IP Protocol number 133 was allocated to a > >>> precursor of the > >>>>> FCIP protocol in 2000, but this allocated number is not > >>>> used by FCIP. > >>>>> The working group will consider whether this allocated number > >>>>> should be > >>>>> returned to IANA for future reallocation. > >>>>> > >>>>> (4) iFCP: The Address Translation mode of iFCP needs to be > >>>> deprecated > >>>>> (SHOULD NOT implement or use), as there are significant > >> technical > >>>>> problems with its specification, and moreover, only the Address > >>>>> Transparent mode of iFCP is in use. This will be done via a > >>>>> short draft > >>>>> that updates RFC 4172, and not via a complete rewrite of > >>> RFC 4172. A > >>>>> combined draft is expected that encompasses items (3) and (4). > >>>>> > >>>>> (5) RDDP MPA: Good support for MPI applications requires a > >>>>> small update > >>>>> to the startup functionality to allow either end of the > >>>> connection to > >>>>> initiate. > >>>>> > >>>>> (6) iSER: Experience with Infiniband implementations suggest > >>>>> a few minor > >>>>> updates to reflect what has been done in practice. > >>>>> > >>>>> The working group is expected to maintain good working > >>> relationships > >>>>> with INCITS Technical Committee T10 (SCSI standards) and INCITS > >>>>> Technical Committee T11 (Fibre Channel standards) via > >> overlaps in > >>>>> membership as opposed to appointment of formal liaisons. > >>> The liaison > >>>>> process (including IAB appointment of a liaison or > >>>>> liaisons) remains available for use if needed. > >>>>> > >>>>> Goals and Milestones: > >>>>> > >>>>> June 2009 First version of FCIP protocol number and iFCP Address > >>>>> Translation mode draft > >>>>> > >>>>> July 2009 First version of iSCSI SAM-4 (and other) new > >>>> features draft. > >>>>> > >>>>> Aug 2009 First version of RDDP MPA startup change draft > >>>>> > >>>>> Sep 2009 Working Group Last Call on FCIP protocol > >> number and iFCP > >>>>> address change draft > >>>>> > >>>>> Sep 2009 First version of combined iSCSI draft (3720bis) > >>>>> > >>>>> Oct 2009 First version of iSER update draft > >>>>> > >>>>> Oct 2009 Working Group Last Call on RDDP MPA startup > >> change draft. > >>>>> > >>>>> Dec 2009 Functionally complete iSCSI SAM-4 (and other) > >>> new features > >>>>> draft. > >>>>> > >>>>> Feb 2010 Working Group Last Call on iSER update draft > >>>>> > >>>>> March 2010 Working Group Last Call on iSCSI SAM-4 (and > >> other) new > >>>>> features draft. > >>>>> > >>>>> April 2010 Working Group decision on whether to seek Draft > >>>>> Standard RFC > >>>>> status for the combined iSCSI draft (3720bis). [Note: > >>>>> decision may be made significantly before this date.] > >>>>> > >>>>> Sep 2010 Working Group Last Call on combined iSCSI > >> draft (3720bis) > >>>>> _______________________________________________ > >>>>> OPS-DIR mailing list > >>>>> OPS-DIR@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ops-dir > >>>>> > >>>> > >>> > >>> > >> > > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir > From Black_David@emc.com Thu Apr 30 16:01: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 6B74128C17F; Thu, 30 Apr 2009 16:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYAvMD--Ca41; Thu, 30 Apr 2009 16:01:40 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id F00C528C181; Thu, 30 Apr 2009 16:01:07 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n3UN2RR6012920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2009 19:02:28 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Thu, 30 Apr 2009 19:02:26 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n3UN2P8Y001929; Thu, 30 Apr 2009 19:02:25 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 19:02:25 -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, 30 Apr 2009 19:02:24 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A028EB013@CORPUSMX80A.corp.emc.com> In-Reply-To: <03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnIIsLVYL2tgvRISvuD66VyOWuZ3wBiB/uwAAq7BwA= References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com> <03fd01c9c9b0$e74bc760$0600a8c0@china.huawei.com> To: , , X-OriginalArrivalTime: 30 Apr 2009 23:02:25.0126 (UTC) FILETIME=[B9F55060:01C9C9E7] X-EMM-EM: Active Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, iab@ietf.org, iesg@ietf.org, Black_David@emc.com Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 30 Apr 2009 23:01:42 -0000 Let me start by acknowledging that David Harrington is right about the absence of operations and management in the charter. At a minimum, the new iSCSI features strongly suggest an updated version of the iSCSI MIB (RFC 4544), and I need to revise the draft charter to include that. If David Harrington is willing to serve as a technical advisor to facilitate this update, that would be helpful. OTOH, I disagree with the suggestion that the WG "consider and document" ... "what changes might need to be made to utilize the existing non-IETF standards to manage the updated IETF storage standards". IMHO, it is usually better to communicate the functional changes that the IETF is making in its protocols to other standards organizations that are responsible for related (e.g., management) standards. That enables those organizations to make any changes that they deem appropriate based on their expertise - in contrast, issuing explicit instructions to another standards organization has the potential to go over badly (IMHO). The draft charter already contains references to working relationships with T10 and T11 - it looks like it needs corresponding text for SNIA around the iSCSI HBA API and SMI-S support for iSCSI. Not announcing the BoF on the IETF list was my oversight; that clearly should have been done prior to San Francisco. I'll work with Lars on ensuring that there is sufficiently broad IETF exposure and review of the proposed storm charter. For the security concerns, please see RFC 3723 (Securing Block Storage Protocols over IP). I expect that RFC to remain applicable to all of the revised protocols, with the overall approach being that security issues in technology that is standardized by another standards body are the responsibility of that standards body; would a statement to that effect (RFC 3723 expected to remain applicable, security issues in standards from other organizations remain the responsibility of those organizations) in the charter be helpful? =20 That said, I am surprised by what appears to be an inference that lack of mention of security in the charter implies that security may not be addressed at all. All RFCs have to address security considerations, making security something that every IETF WG has to address, independent of whether security is explicitly mentioned in the WG charter. If every WG charter now has to have a "Security Considerations" section, there are number of WG charters on the IETF web site that need updates ... surely the IESG has better things to do ;-). Regarding SAM-5, the draft storm WG charter references SAM-4 and not SAM-5 for a reason; SAM-5 is an out-of-scope moving target. FWIW, most SCSI (T10) security is not in the SAM standards, but rather in the SPC-4 standard (under development). For Fibre Channel (T11) security, see the FC-SP standard and the FC-SP-2 standard (under development). That brings me to the T10 and T11 standards access concerns, which are real and something I need to work on. INCITS, the parent organization of T10 and T11, imposed new document access restrictions within the past year. I need to work with T10 and T11 on how to go about making the necessary standards documents available to IETF participants, starting with T10 (which meets next week). I do not intend to ask the IESG for approval of the storm WG charter until the document access concerns are resolved. Thanks, --David =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, April 30, 2009 12:30 PM > To: 'Lars Eggert'; 'Ersue, Mehmet (NSN - DE/Munich)' > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org; Black, David;=20 > iesg@ietf.org; iesg@ietf.org; 'IAB' > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance (storm) >=20 > Hi, >=20 > I found that having the discussion for the STORM BOF on the mailing > lists for (three) concluded WGs made it a bit obscure. > As far as I can tell by looking at those archives, there wasn't much > discussion. > I will also note that the announcement of the craetion of the storm > list seems to be have been only announced to the lists of the three > concluded WGs. So if you weren't involved in the three earlier WGs, > you might not have seen the announcement.=20 >=20 > I do think Mehmet has a point that many IETF people may not have been > aware the discussion was happening. >=20 > As an OPSDIR member and MIB Doctor, I have already expressed concerns > that operations and management is not being addressed in the charter. > The chair helpfully responded with a short list of management > standards (SNIA SMI-S, SNIA SCSI HBA, INCITS FC HBA) that might help > answer my questions. Unfortunately, I cannot access some of the > documents referenced because they are not freely available. If I read > through a number of large standards I might be able to determine for > myself what changes might need to be made to utilize the existing > non-IETF standards to manage the updated IETF storage standards. I > think I would rather see the WG consdier this and document it, rather > than me (and any other user of the IETF technologies) having to > research this personally to know the answers. I would nto say my > concerns have been addressed. >=20 > As a SECDIR member, I have concerns that security may not be gettng > addressed either, but it is hard for me to say that for sure since I > cannot freely access the T10 and T11 documents that are the basis of > the updates. I do not know whether the updated IETF storage standards > will utilize IETF standards for security or non-IETF stndards for > security, or whether the WG is simply not going to address security > issues since it is not mentioned in the charter. I note that the > charter calls for updating to SAM-4 level, and that T10 is starting > new work on SAM-5, explicitly to address security. So does that mean > security will not be addressed in the STORM WG? >=20 > I have not seen these discussions elsewhere. And Mehmet's concerns > seem to be relevant to that point. >=20 > Before the WG is created, I think the charter should be explicit about > the what the WG will do to address how these Internet protocols should > be operated and managed and secured. > =20 > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com >=20 > > -----Original Message----- > > From: ops-dir-bounces@ietf.org=20 > > [mailto:ops-dir-bounces@ietf.org] On Behalf Of Lars Eggert > > Sent: Tuesday, April 28, 2009 12:44 PM > > To: Ersue, Mehmet (NSN - DE/Munich) > > Cc: aaa-doctors@ietf.org; ops-dir@ietf.org;=20 > > Black_David@emc.com; iesg@ietf.org > > Subject: Re: [OPS-DIR] FW: Internal WG Review: STORage=20 > > Maintenance (storm) > >=20 > > Hi, > >=20 > > On 2009-4-28, at 12:29, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > unfortunately I missed the Storm BoF in SF. I also was not aware > of > > > the discussion on the maillists you mention. > > > > > > I made the experience that announcing a BoF maillist to IETF and > > > forcing some discussion on this maillist with IETF member =20 > > > participation > > > is a good way to show IESG that there is measurable IETF community > > > interest. > >=20 > > as David said below, there was discussion on the=20 > > still-existing RDDP, =20 > > IPS and IMSS lists, and the BOF went - in my opinion - very well. I >=20 > > believe community interest has been demonstrated, which is why we're >=20 > > going forward with a charter proposal. > >=20 > > > The huge amount of people in the session, which are sometimes > > > occasionally in the room and vote, usually disappear when=20 > > it comes to > > > maillist discussion. Also for our regular WG work the decisions > have > > > to be confirmed on the maillist. > > > > > > As I said I believe this is an important and necessary > consolidation > > > work but should be discussed and accepted first in the IETF=20 > > community. > >=20 > > I don't quite know what to do with you comment. Are you saying there >=20 > > hasn't been sufficient discussion to go forward with the chartering? >=20 > > Or am I misunderstanding? > >=20 > > I'll also note that the community obviously still has time to=20 > > comment =20 > > - the charter is in internal I* review at this time, after which it >=20 > > will go for public review. > >=20 > > Lars > >=20 > > > > > > Cheers, > > > Mehmet > > > > > > > > >> -----Original Message----- > > >> From: ext Black_David@emc.com [mailto:Black_David@emc.com] > > >> Sent: Tuesday, April 28, 2009 2:32 PM > > >> To: Ersue, Mehmet (NSN - DE/Munich) > > >> Cc: dromasca@avaya.com; Black_David@emc.com > > >> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > > >> Maintenance (storm) > > >> > > >> Mehmet, > > >> > > >> The storm list is completely new (it was only opened for people > > >> to subscribe within the past few days). The storm BOF in San > > >> Francisco was organized using the existing IPS, RDDP and IMSS > > >> mailing lists. I suggest consulting the archives for those > > >> lists, particularly for the IPS list, where you should find a > > >> reasonable level of community interest. > > >> > > >> There is definite community interest in this work, and I have > > >> author commitments for drafts for all six work items listed > > >> in the charter - each of the "First version of" milestone > > >> dates in the proposed charter is based on discussion with an > > >> author or authors who believe that a first version of the draft > > >> will be ready by that date. > > >> > > >> Thanks, > > >> --David > > >> ---------------------------------------------------- > > >> David L. Black, Distinguished Engineer > > >> EMC Corporation, 176 South St., Hopkinton, MA 01748 > > >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > >> black_david@emc.com Mobile: +1 (978) 394-7754 > > >> ---------------------------------------------------- > > >> > > >>> -----Original Message----- > > >>> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > >>> Sent: Tuesday, April 28, 2009 6:33 AM > > >>> To: Ersue, Mehmet (NSN - DE/Munich) > > >>> Cc: Black, David > > >>> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > > >>> Maintenance (storm) > > >>> > > >>> Mehmet, > > >>> > > >>> David Black ran the BOF in San Francisco. He should be able > > >> to provide > > >>> you information about the preparation work, level of support and > > >>> interest from the community and initial drafts. > > >>> > > >>> Thanks for looking into this and for asking the questions. > > >>> > > >>> Dan > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Ersue, Mehmet (NSN - DE/Munich) > > >> [mailto:mehmet.ersue@nsn.com] > > >>>> Sent: Tuesday, April 28, 2009 1:29 PM > > >>>> To: Romascanu, Dan (Dan) > > >>>> Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage > > >>>> Maintenance (storm) > > >>>> > > >>>> > > >>>> Hi Dan, > > >>>> > > >>>> I believe this is an important and necessary consolidation > work. > > >>>> > > >>>> I might have missed the discussion on another maillist but > > >>>> the storm maillist is pretty much new and I would have a > > >>>> better feeling if there were some mail traffic showing the > > >>>> interest of the community and/or an initial draft with an > > >>>> issues list for the justification of a new WG. > > >>>> > > >>>> Cheers, > > >>>> Mehmet > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: ops-dir-bounces@ietf.org > > >>>>> [mailto:ops-dir-bounces@ietf.org] On Behalf Of ext Romascanu, > > >>>>> Dan (Dan) > > >>>>> Sent: Monday, April 27, 2009 7:57 PM > > >>>>> To: aaa-doctors@ietf.org; ops-dir@ietf.org > > >>>>> Subject: [OPS-DIR] FW: Internal WG Review: STORage > > >>>> Maintenance (storm) > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > > >>>>> Behalf Of > > >>>>> IESG Secretary > > >>>>> Sent: Monday, April 27, 2009 8:54 PM > > >>>>> To: iesg@ietf.org; iab@iab.org > > >>>>> Cc: black_david@emc.com > > >>>>> Subject: Internal WG Review: STORage Maintenance (storm) > > >>>>> > > >>>>> A new IETF working group is being considered in the Transport > > >>>>> Area. The > > >>>>> draft charter for this working group is provided below for > > >>>> your review > > >>>>> and comment. > > >>>>> > > >>>>> Review time is one week. > > >>>>> > > >>>>> The IETF Secretariat > > >>>>> > > >>>>> STORage Maintenance (storm) > > >>>>> ---------------------------------- > > >>>>> > > >>>>> Last Modified: 2009-04-25 > > >>>>> > > >>>>> Current Status: Proposed Working Group > > >>>>> > > >>>>> Chairs: > > >>>>> - David L. Black > > >>>>> - tbd > > >>>>> > > >>>>> Transport Area Director(s): > > >>>>> - Magnus Westerlund > > >>>>> - Lars Eggert > > >>>>> > > >>>>> Transport Area Advisor: > > >>>>> - Lars Eggert > > >>>>> > > >>>>> Mailing Lists: > > >>>>> General Discussion: storm@ietf.org > > >>>>> To Subscribe: storm-request@ietf.org > > >>>>> In Body: (un)subscribe > > >>>>> Archive: http://www.ietf.org/mail-archive/web/storm/index.html > > >>>>> > > >>>>> Description of Working Group: > > >>>>> > > >>>>> The IETF IPS (IP Storage) and RDDP (Remote Direct Data > > >> Placement) > > >>>>> working groups have produced a significant number of > > >>>> storage protocols > > >>>>> (e.g., iSCSI, iSER and FCIP) for which there is significant > > >>>> usage. The > > >>>>> time has come to reflect feedback from implementation and > > >>> usage into > > >>>>> updated RFCs; this work may include: > > >>>>> > > >>>>> - Implementation-driven revisions and updates to existing > > >>> protocols > > >>>>> (i.e., updated RFCs that match the "running code"). > > >>>>> > > >>>>> - Interoperability reports as needed for the resulting > > >>>>> revised protocols > > >>>>> that are appropriate for Draft Standard RFC status. > > >>>>> > > >>>>> - Minor protocol changes or additions. Backwards > > >> compatibility is > > >>>>> required. > > >>>>> > > >>>>> Significant changes to the existing protocol standards are > > >>>>> out of scope, > > >>>>> including any work on version 2 of any of these protocols. > > >>>>> > > >>>>> Stability is critical to the usage of these protocols, so > > >>> backwards > > >>>>> compatibility with existing implementations will be a > > >> requirement > > >>>>> imposed on for all protocol changes and additions. Note > > >>>> that this is a > > >>>>> requirement for implementation compatibility - if it is the > > >>>> case that > > >>>>> all implementations of a protocol have done something > > >>> different than > > >>>>> what the RFC specifies, it is appropriate for a new RFC to > > >>>>> document what > > >>>>> the "running code" actually does and deprecate the > > >> unused original > > >>>>> behavior. > > >>>>> > > >>>>> Initial list of work items: > > >>>>> > > >>>>> (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), > > >> 4850 (node > > >>>>> architecture key) and 5048 (corrections/clarifications) > > >>>> into one draft > > >>>>> (3720bis), removing features that are not implemented in > > >>>>> practice. This > > >>>>> draft should be prepared so that it could become a Draft > > >>>> Standard RFC, > > >>>>> but it is up to the to decide whether to advance it to > > >>>> Draft Standard. > > >>>>> > > >>>>> (2) iSCSI: Add features to support SAM-4 (4th version > > >> of the SCSI > > >>>>> architecture) in a backwards-compatible fashion, as iSCSI > > >>>> is currently > > >>>>> based on SAM-2. This will be a separate draft from the > > >>>> iSCSI update in > > >>>>> the previous bullet. The Working group may add additional > > >>>> minor useful > > >>>>> iSCSI features to this draft. > > >>>>> > > >>>>> (3) FCIP: IP Protocol number 133 was allocated to a > > >>> precursor of the > > >>>>> FCIP protocol in 2000, but this allocated number is not > > >>>> used by FCIP. > > >>>>> The working group will consider whether this allocated number > > >>>>> should be > > >>>>> returned to IANA for future reallocation. > > >>>>> > > >>>>> (4) iFCP: The Address Translation mode of iFCP needs to be > > >>>> deprecated > > >>>>> (SHOULD NOT implement or use), as there are significant > > >> technical > > >>>>> problems with its specification, and moreover, only the > Address > > >>>>> Transparent mode of iFCP is in use. This will be done via a > > >>>>> short draft > > >>>>> that updates RFC 4172, and not via a complete rewrite of > > >>> RFC 4172. A > > >>>>> combined draft is expected that encompasses items (3) and (4). > > >>>>> > > >>>>> (5) RDDP MPA: Good support for MPI applications requires a > > >>>>> small update > > >>>>> to the startup functionality to allow either end of the > > >>>> connection to > > >>>>> initiate. > > >>>>> > > >>>>> (6) iSER: Experience with Infiniband implementations suggest > > >>>>> a few minor > > >>>>> updates to reflect what has been done in practice. > > >>>>> > > >>>>> The working group is expected to maintain good working > > >>> relationships > > >>>>> with INCITS Technical Committee T10 (SCSI standards) and > INCITS > > >>>>> Technical Committee T11 (Fibre Channel standards) via > > >> overlaps in > > >>>>> membership as opposed to appointment of formal liaisons. > > >>> The liaison > > >>>>> process (including IAB appointment of a liaison or > > >>>>> liaisons) remains available for use if needed. > > >>>>> > > >>>>> Goals and Milestones: > > >>>>> > > >>>>> June 2009 First version of FCIP protocol number and iFCP > Address > > >>>>> Translation mode draft > > >>>>> > > >>>>> July 2009 First version of iSCSI SAM-4 (and other) new > > >>>> features draft. > > >>>>> > > >>>>> Aug 2009 First version of RDDP MPA startup change draft > > >>>>> > > >>>>> Sep 2009 Working Group Last Call on FCIP protocol > > >> number and iFCP > > >>>>> address change draft > > >>>>> > > >>>>> Sep 2009 First version of combined iSCSI draft (3720bis) > > >>>>> > > >>>>> Oct 2009 First version of iSER update draft > > >>>>> > > >>>>> Oct 2009 Working Group Last Call on RDDP MPA startup > > >> change draft. > > >>>>> > > >>>>> Dec 2009 Functionally complete iSCSI SAM-4 (and other) > > >>> new features > > >>>>> draft. > > >>>>> > > >>>>> Feb 2010 Working Group Last Call on iSER update draft > > >>>>> > > >>>>> March 2010 Working Group Last Call on iSCSI SAM-4 (and > > >> other) new > > >>>>> features draft. > > >>>>> > > >>>>> April 2010 Working Group decision on whether to seek Draft > > >>>>> Standard RFC > > >>>>> status for the combined iSCSI draft (3720bis). [Note: > > >>>>> decision may be made significantly before this date.] > > >>>>> > > >>>>> Sep 2010 Working Group Last Call on combined iSCSI > > >> draft (3720bis) > > >>>>> _______________________________________________ > > >>>>> OPS-DIR mailing list > > >>>>> OPS-DIR@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/ops-dir > > >>>>> > > >>>> > > >>> > > >>> > > >> > >=20 > > _______________________________________________ > > OPS-DIR mailing list > > OPS-DIR@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-dir > >=20 >=20 >=20 >=20 From Black_David@emc.com Thu Apr 30 19:09:52 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 5FF383A6E22; Thu, 30 Apr 2009 19:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.482 X-Spam-Level: X-Spam-Status: No, score=-7.482 tagged_above=-999 required=5 tests=[AWL=1.117, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAFjwbwRsNpg; Thu, 30 Apr 2009 19:09:51 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 4F5C63A67E6; Thu, 30 Apr 2009 19:09:51 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n412BAIM022018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2009 22:11:10 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Thu, 30 Apr 2009 22:10:58 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n412Astj026411; Thu, 30 Apr 2009 22:10:56 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Apr 2009 22:10:54 -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, 30 Apr 2009 22:10:53 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A028EB04E@CORPUSMX80A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) Thread-Index: AcnIIKWGCnCLmph2T2uIh2d+fMjKowAAXDowAFvI75AAG+inYA== References: <82E73251-D113-46CB-9798-C28A1C4C3AE3@nokia.com> To: , , X-OriginalArrivalTime: 01 May 2009 02:10:54.0095 (UTC) FILETIME=[0EA109F0:01C9CA02] X-EMM-EM: Active Cc: aaa-doctors@ietf.org, ops-dir@ietf.org, iesg@ietf.org, Black_David@emc.com Subject: Re: [AAA-DOCTORS] [OPS-DIR] FW: Internal WG Review: STORage Maintenance (storm) 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, 01 May 2009 02:09:52 -0000 Dan, > I believe that the level of interest will be judged (also) when the > charter will go out for broad IETF external review.=20 > > Until then can we get a feeling about the number of people who attended > the BOF, how many people expressed support for formation of a WG, how > many raised their hands (in the room and virtually on the mail lists) > volunteering to contribute? This was not a highly attended meeting. The minutes say: Attendance: 14 names on blue sheet, approximately 8 additional jabber room participants. There isn't a recorded count of raised hands. The minutes say: Clear interest in forming a WG, with a desire to limit travel. Work item discussion took a bit longer. Different people are interested in different work items. A discussion of whether any work items should be deleted from the initial list in the charter did not identify any to be deleted, but acknowledged the BOF chair's preference to not have the charter commit up front to taking iSCSI to Draft Standard status. With that change, the "rough consensus" of the meeting (supported by some comments in the jabber room and emails sent to the list) is that a WG should be formed to take on essentially the plan of work in the draft charter. As noted previously, I have author commitments for all of the work items listed on the charter, many from people who were unable to attend the BOF. In at least one case (MPA changes for MPI), a multi-author team has been formed. Thanks, --David > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: Thursday, April 30, 2009 8:46 AM > To: Ersue, Mehmet (NSN - DE/Munich); ext Lars Eggert > Cc: Black, David; ops-dir@ietf.org; aaa-doctors@ietf.org;=20 > iesg@ietf.org > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > Maintenance (storm) >=20 > =20 >=20 > > -----Original Message----- > > From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com]=20 > > Sent: Tuesday, April 28, 2009 8:34 PM > > To: ext Lars Eggert > > Cc: Black_David@emc.com; Romascanu, Dan (Dan);=20 > > ops-dir@ietf.org; aaa-doctors@ietf.org; iesg@ietf.org > > Subject: RE: [OPS-DIR] FW: Internal WG Review: STORage=20 > > Maintenance (storm) > >=20 > >=20 > > Lars Eggert wrote: > > > Hi, > > >=20 > > > On 2009-4-28, at 12:29, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > > unfortunately I missed the Storm BoF in SF. I also was=20 > > not aware of=20 > > > > the discussion on the maillists you mention. > > > > > > > > I made the experience that announcing a BoF maillist to=20 > IETF and=20 > > > > forcing some discussion on this maillist with IETF member=20 > > > > participation is a good way to show IESG that there is=20 > measurable=20 > > > > IETF community interest. > > >=20 > > > as David said below, there was discussion on the=20 > > still-existing RDDP,=20 > > > IPS and IMSS lists, and the BOF went - in my opinion -=20 > very well. I=20 > > > believe community interest has been demonstrated, which is=20 > > why we're=20 > > > going forward with a charter proposal. > >=20 > > I can imagine core members of imss, rddp and ips always=20 > > support storage related topics.=20 > > I was wondering whether there was any invitation to the=20 > > ietf-discussion prior to the BoF to motivate people to=20 > > reactivate their subscription for > >=20 > > RDDP, IPS and IMSS lists to discuss Storm issues? A separate=20 > > maillist would be probably more effective. > >=20 > > I'm not against a WG, I'm just saying that there is not=20 > > sufficient positive feedback from the IETF community _on a=20 > > maillist_ yet. > >=20 > > IMO IESG should measure the acceptance of Storm based on the=20 > > feedback of the broader IETF community based on a maillist=20 > discussion. > > The count of Storm-related mails I can see on the official BoF list > > (ips) > > before the BoF session is not overwhelming. > > =20 >=20 > I believe that the level of interest will be judged (also) when the > charter will go out for broad IETF external review.=20 >=20 > Until then can we get a feeling about the number of people=20 > who attended > the BOF, how many people expressed support for formation of a WG, how > many raised their hands (in the room and virtually on the mail lists) > volunteering to contribute? >=20 > Dan > =20 >=20 >=20 From jari.arkko@piuha.net Thu Apr 30 22:32: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 A0C823A688A; Thu, 30 Apr 2009 22:32:29 -0700 (PDT) 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 IckbBphF-3R7; Thu, 30 Apr 2009 22:32:28 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D9E333A6808; Thu, 30 Apr 2009 22:32:27 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 9330E19878A; Fri, 1 May 2009 08:33:50 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 2945D198660; Fri, 1 May 2009 08:33:50 +0300 (EEST) Message-ID: <49FA89A3.4050407@piuha.net> Date: Fri, 01 May 2009 08:33:23 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: aaa-doctors@ietf.org, ops-dir@ietf.org Subject: Re: [AAA-DOCTORS] FW: Internal WG Review: Yet Another Mail (yam) 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, 01 May 2009 05:32:29 -0000 I am very much in favor of this, and its about time we do it. I like the wording and scoping of the charter. I would like to see the TBD list of documents filled out, however. If we believe this WG is needed we should already know what the tentative list of documents is. And in any case its easy to write up. Jari Romascanu, Dan (Dan) wrote: > > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > IESG Secretary > Sent: Thursday, April 30, 2009 12:01 AM > To: iesg@ietf.org; iab@iab.org > Subject: Internal WG Review: Yet Another Mail (yam) > > A new IETF working group is being considered in the Applications Area. > The draft charter for this working group is provided below for your > review and comment. > > Review time is one week. > > The IETF Secretariat > > > Yet Another Mail (yam) > ---------------------------------- > Last Modified: 2009-04-29 > > Current Status: Proposed Working Group > > Chair(s): > > > > Applications Area Director(s): > > Lisa Dusseault > Alexey Melnikov > > Applications Area Advisor: > > > > Mailing Lists: > > http://mipassoc.org/mailman/listinfo/ietf-yam > > Description of Working Group: > > The Yet Another Mail (YAM) WG will revise existing Internet Mail > specifications currently at Draft Standard to advance them to Full > Standard. YAM will focus strictly on advancing email-related > specifications for which the community already has some years of > experience with deployment and interoperability. Its function is not to > reopen or reconsider protocols - if a specification is found to need > significant technical work, YAM will remove it from the WG's agenda. > > This charter's scope of work is the set of email-related RFCs that are > currently at Draft Standard. Each document will be examined, along with > its errata, and a recommendation made as to whether it is suitable for > advancement to Full Standard. If it is not, the WG may recommend whether > it should be republished at Draft Standard, moved to Historic, or > recycled to Proposed Standard. However, any actual work to facilitate > publication of a document at other than Full Standard is outside the > WG's scope. If the WG cannot quickly reach consensus about further work > on a document, it will drop the documents from its agenda without > further comment or effort. > > The purpose of this working group is to work on protocols that are > already recognized as effectively full standards, improving their > written specifications to align with that status. The working group does > not intend to revise the actual protocols in any way and will avoid > document changes that might even accidentally introduce protocol > changes, destabilize a protocol, or introduce semantic or syntactic > changes. > > In particular, it will avoid adding new document sections that were not > previously required and making gratuitous BNF grammar changes. If an > existing protocol implementation is conforming to the Draft Standard > version of the protocol specification, it must also be conforming to the > resulting Full Standard version. Hence, specification changes that > create a violation of this requirement are out of scope of the working > group charter. > > On a case by case basis, substantive changes may be considered, if they > will modify text to match existing conforming implementations -- that > is, implementations that are already deployed with significant use. > Specifically, such changes will be permitted to relax requirements (such > as changing a MUST to a MAY) or to fix BNF bugs where the intent is and > has been clear. In any event, agreement will be reached with the IESG > about the changes to be made to a given document before work starts on > it > > After the tasks of this charter are completed, the WG will consider > rechartering to move selected mature specifications that are still at > Proposed Standard to higher maturity levels, or to work on those > documents previously identified as needing to be republished at Draft > Standard or Proposed Standard. > > The underpinnings of this WG effort are: > > (1) Wide deployment and use of interoperable implementations of an > existing standards-track protocol creates a presumption that the > existing specification is adequate. The burden of demonstrating the > contrary lies with those who believe that they see significant technical > or documentation defects. > > (2) It is generally in the best interest of the IETF and the Internet > community to see specifications of mature protocols advance on the > standards track, eliminating any uncertainty as to whether the protocols > have been adequately understood and tested. To that end, YAM will avoid > modification of documents simply to adjust them to match contemporary > IETF procedural, section list, notational or linguistic norms. > Obviously, updating of references, boilerplate, and the equivalent are > exceptions to this, but success in the WG requires that there be a > good-faith commitment by both its participants and the IESG to avoid > seeking changes that (a) do not contribute in a substantial and > substantive way to the quality and comprehensibility of the > specification, or that (b) force a change to the existing protocol. > > ------------------- > > Benchmarks (dates to be determined) > > Compile a list of potentially-relevant documents. The list of documents > that are now at Draft Standard that appear to be email related is as > follows. Per the next benchmark, some of these are not likely to be > considered by the WG, nor does order of publication imply order of > importance. > > > > The steps to be followed are, approximately: > > o Review the document list, removing any that have significant technical > defects or whose advancement may be controversial under the advancement > criteria specified in RFC 2026. > > o Form review and editing teams for each document to be advanced. > > o Formulate a list of proposed changes (stated in general terms, rather > than specific wording). > > o Obtain WG consensus and IESG agreement on these changes. > > o Post I-Ds for WG consideration and consensus formation. > > o Recommend resulting documents to IESG for publication processing. > > o Rinse and repeat. > > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors > > >