From aaa-doctors-bounces@ietf.org Fri Aug 8 09:55:13 2008 Return-Path: X-Original-To: aaa-doctors-archive@optimus.ietf.org Delivered-To: ietfarch-aaa-doctors-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2836D3A6CEE; Fri, 8 Aug 2008 09:55:13 -0700 (PDT) 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 DEE333A6CE4; Fri, 8 Aug 2008 09:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.503, 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 sY0daKOpxuqk; Fri, 8 Aug 2008 09:55:11 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 147D23A6C62; Fri, 8 Aug 2008 09:55:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,328,1215403200"; d="scan'208";a="117643055" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Aug 2008 12:55:05 -0400 X-IronPort-AV: E=Sophos;i="4.31,328,1215403200"; d="scan'208";a="253909702" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Aug 2008 12:55:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 18:55:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Preliminary agenda for the 8/14 IESG Telechat Thread-Index: Acj5d4AyHa7zj9wVSOWIM7diqUPwCg== From: "Romascanu, Dan (Dan)" To: , "MIB Doctors (E-mail)" , "IETF DNS Directorate" , Subject: [AAA-DOCTORS] Preliminary agenda for the 8/14 IESG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: aaa-doctors-bounces@ietf.org Errors-To: aaa-doctors-bounces@ietf.org Please find below the preliminary agenda of the 8/14 IESG telechat. Please send me your questions, concerns and comments until 8/13 COB the latest. Thanks and Regards, Dan 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 - Information Model and XML Data Model for Traceroute Measurements (Proposed Standard) - draft-ietf-ippm-storetraceroutes-10.txt - Transport Mapping for Syslog (Proposed Standard) - draft-ietf-syslog-transport-tls-13.txt - Definitions of Textual Conventions for Pseudowires (PW) Management (Proposed Standard) - draft-ietf-pwe3-pw-tc-mib-14.txt - Guidelines for Application Designers on Using Unicast UDP (BCP) - draft-ietf-tsvwg-udp-guidelines-09.txt - Simple Network Management Protocol (SNMP) Context EngineID Discovery (Proposed Standard) - draft-ietf-opsawg-snmp-engineid-discovery-03.txt - Internet Message Store Events (Proposed Standard) - draft-ietf-lemonade-msgevent-06.txt 2.1.2 Returning Item - A Two-way Active Measurement Protocol (TWAMP) (Proposed Standard) - draft-ietf-ippm-twamp-09.txt 2.2 Individual Submissions 2.2.1 New Item - IANA Considerations for the IPv4 and IPv6 Router Alert Option (Proposed Standard) - draft-manner-router-alert-iana-03.txt - Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, and Other Crimeware (Proposed Standard) - draft-cain-post-inch-phishingextns-05.txt 3. Document Actions 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 - Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational) - draft-zhou-emu-fast-gtc-04.txt - Dynamic Provisioning using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational) - draft-cam-winget-eap-fast-provisioning-09.txt - Media Gateway Control Protocol Fax Package (Informational) - draft-andreasen-mgcp-fax-08.txt _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Sun Aug 10 05:18:04 2008 Return-Path: X-Original-To: aaa-doctors-archive@optimus.ietf.org Delivered-To: ietfarch-aaa-doctors-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782253A6B49; Sun, 10 Aug 2008 05:18:04 -0700 (PDT) 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 87FB43A680E for ; Sun, 10 Aug 2008 05:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNbgiLEBDJJX for ; Sun, 10 Aug 2008 05:18:01 -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 549AD3A6B83 for ; Sun, 10 Aug 2008 05:18:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,337,1215403200"; d="scan'208";a="117770690" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Aug 2008 08:17:56 -0400 X-IronPort-AV: E=Sophos;i="4.31,337,1215403200"; d="scan'208";a="254978392" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Aug 2008 08:17:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 10 Aug 2008 14:17:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lunch Meeting in Dublin Thread-Index: Acj64x0X7J/6wrbmTQmfpusk2Ke9cA== From: "Romascanu, Dan (Dan)" To: Subject: [AAA-DOCTORS] Lunch Meeting in Dublin 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: aaa-doctors-bounces@ietf.org Errors-To: aaa-doctors-bounces@ietf.org I apologize for the delay, due to a slower pace week after Dublin. The AAA-Doctors team met for a working lunch on Thursday 7/31 in Dublin. Thanks to all participants for attending. We discussed procedures, mode of operation and tools for the AAA-Doctors team. Here are the main points: - Hannes Tschofenig accepted to be the secretary and coordinator of the AAA-Doctors team. His tasks include scanning all Internet-Drafts sent to review for AAA content, and send them the AAA Doctors according to an algorithm that tries to keep fairness in loading and also takes into account specific expertise of the AAA Doctors - David Kessens will help Hannes and the team with tools assistance for scanning I-D content - The documents will be scanned and distributed by Hannes at IETF Last Call stage and the doctors will make best effort to provide reviews until the end of the IETF Last Call comments, so that document editors and shepherds can take them into account together with other IETF Last Call comments and expert reviews. The ADs may use the reviews comments for DISCUSSes and COMMENTs at IESG review phase if the AAA-Doctors comments were not addressed in a satisfactory manner. - A wiki page will be created to help following up the documents under review and their status Please keep me honest in case I mis-represented or forgot anything. Regards, Dan _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Sat Aug 23 23:53:37 2008 Return-Path: X-Original-To: aaa-doctors-archive@optimus.ietf.org Delivered-To: ietfarch-aaa-doctors-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543D83A6B6E; Sat, 23 Aug 2008 23:53:37 -0700 (PDT) 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 A143F3A689B; Sat, 23 Aug 2008 23:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbitRfgnudZZ; Sat, 23 Aug 2008 23:53:34 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 0E6BC3A67FD; Sat, 23 Aug 2008 23:53:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,262,1217822400"; d="scan'208";a="132267476" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 24 Aug 2008 02:53:13 -0400 X-IronPort-AV: E=Sophos;i="4.32,262,1217822400"; d="scan'208";a="258529058" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 24 Aug 2008 02:53:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 24 Aug 2008 08:53:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for August 28, 2008 Telechat Thread-Index: AckD3eLBpz8FqVY6SVquGK+vCm6bxAB158Og From: "Romascanu, Dan (Dan)" To: , "IETF DNS Directorate" , "MIB Doctors (E-mail)" , Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for August 28, 2008 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: aaa-doctors-bounces@ietf.org Errors-To: aaa-doctors-bounces@ietf.org Please see below the preliminary agenda of the 8/28 IESG telechat. Please send me comments and concerns related to the documents and WG charters brought up for approval until 8/27 COB the latest. Thanks and Regards, Dan 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-mpls-number-0-bw-te-lsps-11.txt A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switched Paths signalled with zero reserved bandwidth across a link (Proposed Standard) - 1 of 1 Token: Ross Callon 2.1.2 Returning Item NONE 2.1.3 For Action o draft-ietf-opsawg-snmp-engineid-discovery-03.txt Simple Network Management Protocol (SNMP) Context EngineID Discovery (Proposed Standard) - 1 of 1 Token: Dan Romascanu 2.2 Individual Submissions 2.2.1 New Item o draft-cain-post-inch-phishingextns-05.txt Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, and Other Crimeware (Proposed Standard) - 1 of 1 Token: Tim Polk 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-mip6-whyauthdataoption-06.txt Why Authentication Data suboption is needed for MIP6 (Informational) - 1 of 1 Note: No document shepherd -- old MIP6 document 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 o draft-cam-winget-eap-fast-provisioning-09.txt Dynamic Provisioning using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational) - 1 of 2 Token: Tim Polk o draft-sun-dime-itu-t-rw-01.txt Diameter ITU-T Rw Policy Enforcement Interface Application (Informational) - 2 of 2 Token: Dan Romascanu 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item o draft-irtf-nmrg-snmp-measure-05.txt SNMP Traffic Measurements and Trace Exchange Formats (Informational) - 1 of 1 Note: Proposed IESG Note: . . The IESG thinks that this work is related to IETF work done in the Operations and Management Area related to SNMP, but this does not prevent publishing.. . 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 notes that the decision to publish is not based on. IETF review apart from the IETF Last Call on the allocation of an URI by IANA and the IESG review for conflict with IETF work.. The RFC Editor has chosen to publish this document at its. discretion. See RFC 3932 for more information.. . Token: Dan Romascanu 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o Operational Security Capabilities for IP Network Infrastructure (opsec) - 1 of 1 Token: Ron Bonica 4.2.2 Proposed for Approval o Sieve Mail Filtering Language (sieve) - 1 of 1 Token: Lisa Dusseault _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Sun Aug 24 10:39:33 2008 Return-Path: X-Original-To: aaa-doctors-archive@optimus.ietf.org Delivered-To: ietfarch-aaa-doctors-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27AA3A6A8A; Sun, 24 Aug 2008 10:39:33 -0700 (PDT) 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 6D6DE3A6982 for ; Sun, 24 Aug 2008 10:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.126 X-Spam-Level: X-Spam-Status: No, score=0.126 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlMscwoLeJlr for ; Sun, 24 Aug 2008 10:39:31 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 29CF83A6A8A for ; Sun, 24 Aug 2008 10:39:30 -0700 (PDT) Received: (qmail invoked by alias); 24 Aug 2008 17:39:29 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp032) with SMTP; 24 Aug 2008 19:39:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ONd1ApIPOjYDMAjVJtbYVIwW5IFstYPtvStnD90 Xs6Ic/+CSF+yyZ Message-ID: <48B19CD1.50207@gmx.net> Date: Sun, 24 Aug 2008 20:39:29 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: aaa-doctors@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 Subject: [AAA-DOCTORS] Wiki and Review Assignments 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: aaa-doctors-bounces@ietf.org Errors-To: aaa-doctors-bounces@ietf.org Hi all, I have created a first version of the Wiki page: http://tools.ietf.org/wg/dime/trac/wiki/AaaDoctors I couldn't find a suitable place to put it and hence I have temporarily placed it at the DIME Wiki. Maybe someone can tell me how to find the Operations and Management Area Wiki. I have already put two review assignments to the Wiki. The first item reflects our discussion in Dublin regarding previous reviews of MBONED drafts relating to AAA. Maybe a few of us should review the drafts again to refresh our memory and then we think about the next steps. Maybe the drafts are great in the meanwhile and there is no further help needed. The second item is about the review of draft-sun-dime-itu-t-rw-01.txt. Since I know the history behind this work I will review the draft. Additionally, I am assigned review as part of my Security Area Directorate responsibilities anyway. If you have further thoughts about early reviews we should be doing please let us know. Please also let us know if you spot a document in IETF LC (or so) that may have AAA related content. Ciao Hannes _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Mon Aug 25 01:18:04 2008 Return-Path: X-Original-To: aaa-doctors-archive@optimus.ietf.org Delivered-To: ietfarch-aaa-doctors-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A584C3A6CAA; Mon, 25 Aug 2008 01:18:04 -0700 (PDT) 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 C76FC3A6C2E for ; Mon, 25 Aug 2008 01:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=0.843, 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 Zu1AVCEcQHsS for ; Mon, 25 Aug 2008 01:18:03 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id C00773A6C1D for ; Mon, 25 Aug 2008 01:18:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,264,1217822400"; d="scan'208";a="132324553" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 25 Aug 2008 04:17:36 -0400 X-IronPort-AV: E=Sophos;i="4.32,264,1217822400"; d="scan'208";a="258994051" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 25 Aug 2008 04:17:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 10:17:33 +0200 Message-ID: In-Reply-To: <48B19CD1.50207@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] Wiki and Review Assignments Thread-Index: AckGEGCT3LjRuvGVTEOFS5ZPj/LBtAAemYKA References: <48B19CD1.50207@gmx.net> From: "Romascanu, Dan (Dan)" To: "Hannes Tschofenig" , Subject: Re: [AAA-DOCTORS] Wiki and Review Assignments 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: aaa-doctors-bounces@ietf.org Errors-To: aaa-doctors-bounces@ietf.org Thanks, Hannes for creating the wiki. Concerning draft-sun-dime-itu-t-rw-01.txt - please note that it is on the agenda of the IESG telechat for this Thursday, so any last minutes comments are welcome until 8/27 COB the latest. Regards, Dan > -----Original Message----- > From: aaa-doctors-bounces@ietf.org > [mailto:aaa-doctors-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Sunday, August 24, 2008 8:39 PM > To: aaa-doctors@ietf.org > Subject: [AAA-DOCTORS] Wiki and Review Assignments > > Hi all, > > I have created a first version of the Wiki page: > http://tools.ietf.org/wg/dime/trac/wiki/AaaDoctors > I couldn't find a suitable place to put it and hence I have > temporarily placed it at the DIME Wiki. Maybe someone can > tell me how to find the Operations and Management Area Wiki. > > I have already put two review assignments to the Wiki. > > The first item reflects our discussion in Dublin regarding > previous reviews of MBONED drafts relating to AAA. Maybe a > few of us should review the drafts again to refresh our > memory and then we think about the next steps. Maybe the > drafts are great in the meanwhile and there is no further help needed. > > The second item is about the review of > draft-sun-dime-itu-t-rw-01.txt. > Since I know the history behind this work I will review the draft. > Additionally, I am assigned review as part of my Security > Area Directorate responsibilities anyway. > > If you have further thoughts about early reviews we should be > doing please let us know. Please also let us know if you spot > a document in IETF LC (or so) that may have AAA related content. > > Ciao > Hannes > > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors > _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Thu Aug 28 06:00:33 2008 Return-Path: X-Original-To: aaa-doctors-archive@optimus.ietf.org Delivered-To: ietfarch-aaa-doctors-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944AC28C2B4; Thu, 28 Aug 2008 06:00:33 -0700 (PDT) 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 CACC928C2B4; Thu, 28 Aug 2008 06:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq0c3G8ZsZRu; Thu, 28 Aug 2008 06:00:31 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 3AF903A686B; Thu, 28 Aug 2008 06:00:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,286,1217822400"; d="scan'208";a="141422827" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 28 Aug 2008 09:00:31 -0400 X-IronPort-AV: E=Sophos;i="4.32,286,1217822400"; d="scan'208";a="261245641" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 28 Aug 2008 09:00:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 15:00:29 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD Review of dime-qos-parameters-06.txt Thread-Index: AckJDgxBVJdeRKJ7SQSyCrp45My3Kw== From: "Romascanu, Dan (Dan)" To: Cc: aaa-doctors@ietf.org Subject: [AAA-DOCTORS] AD Review of dime-qos-parameters-06.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: aaa-doctors-bounces@ietf.org Errors-To: aaa-doctors-bounces@ietf.org Hi, This is the AD review of dime-qos-parameters-06.txt. I believe that the document needs more work before it can be sent to IETF Last Call. I am placing it in Revised ID Needed. 1. Although it is the work of the DIME Working Group, the document includes in its scope according to the Introduction section the definition of parameters that can be reused for conveying QoS information within RADIUS and Diameter. I believe that there is a need to add text that shows how specifically these parameters will be used in each of the two protocols. Is there a need for any supplementary documents to describe protocol specific mapping and IANA allocations? 2. Was the document reviewed by the RADIUS WG? 3. This document will trigger again the issue of exceeding the AAA scope of DIAMETER as described by RFC 3588, raised in a number of previous occasions, last by Brian Carpenter in his GenART review for draft-sun-dime-itu-t-rw. I suggest to put text in the Introduction section mentioning the issue of scope and referring to rfc3588bis as an Informational Reference. 4. There are several places in the document where the authors seem to write requirements about the behavior and mode of provisioning of a QoS enabled network. I do not think that an AAA parameters document is a good place for such requirements. I would strongly prefer that the document focuses on describing the QoS parameters carried by AAA protocols, and if examples of usage are left, they be marked clearly as examples. 5. Section 3.2 - Path PLR and Path PER are defined on packet basis, so the claim that they describe the desired bit error rate seems odd. 6. Same -'where the PLR is defined to be the PLR added by each such node' and 'the PER is defined to be the PER added by each such node' seem to be broken as definitions - maybe that was intended to be define is 'the Path PLR' and 'the Path PER' respectively. 7. Section 3.3 - See comment #4 - certainly RFC 2119 keywords usage seems unjustified here. 8. Section 4.1 and following - it would be good to mention that Length all over this document is expressed in 32-bit words. 9. It is not clear why there is a need to defined both TMOD-1 and TMOD-2. I suggest to add an explanation. 10. Section 4.2 - I suggest to add a normative reference to IEEE 754 when referring the first time to single-precision IEEE floating point format. It's a good moment, as the IEEE standard was updated in June 2008, after more than two decades of usage of the precedent version (but this does not affect the way it is used here as far as I can tell) 11. The first phrase in 4.3 should appear also in 4.2 as the two TMOD parameters have similar semantics. 12. Section 4.5 - there is no reference for the semantic of the Path Jitter parameter value - probably section 3.4 in RFC2215 13. I do not understand what is the reason to include Path Jitter STAT4 (Reserved). 14. Section 4.6 - I do not believe that a AAA document should include statements like 'The total PLR added across all QoS aware nodes can range as high as 10^-1.' 15. Section 4.7 - in the first phrase s/PLR/PER/ 16. Section 4.7 - I do not believe that a AAA document should include statements like 'The total PER added across all QoS aware nodes can range as high as 10^-1.' 17. Section 4.8 - I see no reason to refer here to [RFC2212] 18. Section 4.8 - s/Path PLR/Slack Term/ 19. Section 4.11 - I am not sure that quoting RFC4412 as a reference for the semantic of the parameter value is fully accurate. It may be good at most to say that what is referred here is the resource-priority policy element 20. Section 4.11 - This I-D defines similarly ALRP parameter as draft-ietf-tswg-emergency-rsvp and the two documents quote each other with the apparent intent to keep the definitions in sync. However draft-ietf-tswg-emergency-rsvp defines a policy object which is a list of ALRPs, while here there is only one instance. Why the difference? 21. Section 4.11 - if the intent is to keep the definitions here and in draft-ietf-tswg-emergency-rsvp as close as possible what are the ALRP Priority and Reserved octets positions inversed in the two definitions? 22. Section 4.12 should have a reference to the IANA registry required to be defined for this parameter in Section 6.3. 23. Section 4.12 - what is 'the QoS Desired' object defined here? 24. Section 4.12 includes text about the behavior of the network that looks mis-placed in an AAA document. 25. Section 4.13 could use a reorganization of the description. The 16-bits in the payload have different structure according to the PHB class type - they would better get one generic name and specific descriptions for the three cases covered by the object. 26. Section 4.14 - the semantic described in this section is not identical with the one in RFC 4124 which is provided as reference. 4124 says 0 is a reserved value - what semantics does it have here? It is also not clear why this parameter was defined to have an 8-bit representation 27. Section 4.15 - I strongly advice against presenting the usages of the QoS Class parameters here especially in such firm terms as here. Actually ITU-T Y.1541 Tables 2 and 3 make clear that these class usages are only guidance (classes 1 to 5) and provisional (classes 6,7). This is completely lost here. I would prefer to just provide a pointer to the ITU-T document and take out all the classes descriptions, or move them in an Appendix, with all necessary description of their guidance and provisional status. 28. Section 5 should provide a reference to the IANA registry for Enterprise Numbers 29. Section 6.4 - It is not clear why there is a need to create a registry for DSTE Class Type Parameters. If IETF WGs or individuals writing RFCs and running them through the IETF process will be allowed to add or modify values by Standards Actions, this would modify the semantics defined in Section 4.14, which does not include any mention of extensibility for these parameters. 30. Section 6.5 - It is not clear why there is a need to create a registry for Y.1541 Class Parameters. Who would take the responsibility of running the Standard Action to modify or add Object class values? In what conditions? When Y.1541 changes? In any case, this would modify the semantics defined in Section 4.14, which does not include any mention of extensibility for these parameters. 31. Section 7 - I disagree that this document does not raise any security concerns. Actually the modification or mis-configuration of the QoS parameters carries security threats similar with the configuration operations that would be performed for example in case the objects would be configured by using a protocol like SNMP. QoS degradation may lead to degradation of service that can make access to the network resources difficult or impossible, or running real-time applications impossible. We need text that explains what are the sensitive parameters, and the recommended operational and deployment measures to protect against security threats. 32. The description of the [Y.1541] and [Y/1571] references are incomplete. Thanks and Regards, Dan _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/aaa-doctors From aaa-doctors-bounces@ietf.org Thu Aug 28 06:52:38 2008 Return-Path: X-Original-To: aaa-doctors-archive@optimus.ietf.org Delivered-To: ietfarch-aaa-doctors-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45E628C246; Thu, 28 Aug 2008 06:52:38 -0700 (PDT) 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 D831B28C246 for ; Thu, 28 Aug 2008 06:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 9BWXfKghAwOO for ; Thu, 28 Aug 2008 06:52:37 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4A6BF28C20D for ; Thu, 28 Aug 2008 06:52:37 -0700 (PDT) Received: (qmail 442 invoked by uid 0); 28 Aug 2008 13:52:39 -0000 Received: from 192.100.124.218 by www170.gmx.net with HTTP; Thu, 28 Aug 2008 15:52:39 +0200 (CEST) Date: Thu, 28 Aug 2008 15:52:39 +0200 From: "Hannes Tschofenig" Message-ID: <20080828135239.62230@gmx.net> MIME-Version: 1.0 To: aaa-doctors@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18+trNN8pI+gtUxyeOH+Vrncha+i/onzB30BVcvVY p0zJq3R5ScePREqgnPkTkencfC4jyJGtcBLA== X-GMX-UID: lp+QYGa/Li50BttHqGpp6NdrZml1ZBgF Cc: dime@ietf.org Subject: [AAA-DOCTORS] Review of draft-sun-dime-itu-t-rw-01 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: aaa-doctors-bounces@ietf.org Errors-To: aaa-doctors-bounces@ietf.org I reviewed draft-sun-dime-itu-t-rw-01 the normative reference: [Q.3303.3] ITU-T Recommendation Q.3303.3, "Resource control protocol no. 3 (rcp3): Protocol at the Rw interface between the Policy Decision Physical Entity (PD-PE) and the Policy Enforcement Physical Entity (PE-PE): Diameter", 2008. I think it is the right decision to define two new command codes (PIR / PIA) as it is done in [Q.3303.3]. HOWEVER, more command codes must be specified as the ABNF of existing Diameter Base Protocol and Diameter Credit Control Commands has been modified. I therefore request that [Q.3303.3] be changed in the following way since they would cause interoperability problems with existing Diameter Base Protocol and Diameter Credit Control implementations. * CCR Command The ABNF of the original CCR command is modified by removing the required Service-Context-ID AVP. * CCA Command The ABNF of the original CCA command is modified by turning the required Result-Code AVP into an optional one. * RAA Command The ABNF of the original RAA command is modified by turning the required Result-Code AVP into an optional one. * ASR Command The ABNF of the original ASR command is modified by adding the required Abort-Cause AVP. * ASA Command The ABNF of the original ASA command is modified by turning the required Result-Code AVP into an optional one. The simplest way to solve these issues is to register new command codes. Alternatively you could think about why you actually need to modify the ABNF of these commands. Another remark: A couple of tables are listed with AVP flag settings. I got the impression that these flag settings got copied from other documents. This could be a problem since the M-bit (and other flags) meaning is specific for the specific application and command. A new Diameter application/Command may require a different flag setting. I hope that the ITU-T checked this aspect since otherwise they will experience a lot of interop issues. Table 2 is missing indications about the M bit usage. Table 3 is missing indications about the P bit usage. Table 4 is missing indications about the P bit usage. A minor issue: The description about soft-state vs. hard-state was confusing since there is no Reservation-Lifetime AVP specified. Furthermore the text refers to NASREQ and the specification does not use NASREQ. Ciao Hannes _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/aaa-doctors