From dromasca@avaya.com Sun Jan 1 03:22:49 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1483F21F847C; Sun, 1 Jan 2012 03:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.258 X-Spam-Level: X-Spam-Status: No, score=-103.258 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adz46mvchast; Sun, 1 Jan 2012 03:22:47 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 534DA21F8482; Sun, 1 Jan 2012 03:22:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAEBBAE/GmAcF/2dsb2JhbABCggWDCpsrixeBBIEFgXIBAQEBAxIRDQQ+EwYBCA0IBQIGBgwLAQICAwEfJQcBBgQBBAESCBqhCIlvkHaBL4lKM2MEmnGFAIdG X-IronPort-AV: E=Sophos;i="4.71,440,1320642000"; d="scan'208";a="284270913" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Jan 2012 06:22:39 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Jan 2012 06:18:50 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 1 Jan 2012 12:22:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the January 5, 2012 IESG Teleconference Thread-Index: AczGgq+j0FT9W6rdTy+pz+9lo3ISEQB9JbcQ From: "Romascanu, Dan (Dan)" To: , , "YANG Doctors" , , "IETF DNS Directorate" Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for the January 5, 2012 IESG Teleconference X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 11:22:49 -0000 UGxlYXNlIGZpbmQgYmVsb3cgdGhlIHByZWxpbWluYXJ5IGFnZW5kYSBvZiB0aGUgMS81IElFU0cg dGVsZWNoYXQuIFBsZWFzZSBzZW5kIHlvdXIgcXVlc3Rpb25zLCBjb21tZW50cyBhbmQgY29uY2Vy bnMgYWJvdXQgdGhlIGRvY3VtZW50IGFuZCBXRyBjaGFydGVycyBicm91Z2h0IHVwIGZvciB0aGUg YXBwcm92YWwgb2YgdGhlICBJRVNHIGJlZm9yZSAxLzQgQ09CLiANCg0KVGhhbmtzIGFuZCBSZWdh cmRzLA0KDQpEYW4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpZXNn LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppZXNnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBJRVNHIFNlY3JldGFyeQ0KDQoNCjIuIFByb3RvY29sIEFjdGlvbnMNCjIuMSBXRyBTdWJt aXNzaW9ucw0KMi4xLjEgTmV3IEl0ZW1zDQoNCiAgbyBkcmFmdC1pZXRmLXNpZXZlLWluY2x1ZGUt MTMNCiAgICBTaWV2ZSBFbWFpbCBGaWx0ZXJpbmc6IEluY2x1ZGUgRXh0ZW5zaW9uIChQcm9wb3Nl ZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBCYXJyeSBMZWliYSAoYmFycnlsZWliYUBjb21wdXRlci5v cmcpIGlzIHRoZSBkb2N1bWVudA0KICAgIHNoZXBoZXJkLg0KICAgIFRva2VuOiBQZXRlIFJlc25p Y2sNCg0KICBvIGRyYWZ0LWlldGYtc29mdHdpcmUtZ2F0ZXdheS1pbml0LWRzLWxpdGUtMDYNCiAg ICBHYXRld2F5IEluaXRpYXRlZCBEdWFsLVN0YWNrIExpdGUgRGVwbG95bWVudCAoUHJvcG9zZWQg U3RhbmRhcmQpDQogICAgTm90ZTogWW9uZyBDdWkgKGN1aXlvbmdAdHNpbmdodWEuZWR1LmNuKSBp cyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFJhbHBoIERyb21zDQoNCiAgbyBk cmFmdC1pZXRmLTZsb3dwYW4tbmQtMTgNCiAgICBOZWlnaGJvciBEaXNjb3ZlcnkgT3B0aW1pemF0 aW9uIGZvciBMb3cgUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzDQogICAgKDZMb1dQQU4pIChQcm9w b3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBDYXJzdGVuIEJvcm1hbm4gKGNhYm9AdHppLm9yZykg aXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBSYWxwaCBEcm9tcw0KDQogIG8g ZHJhZnQtaWV0Zi02bWFuLWV4dGhkci0wNQ0KICAgIEFuIHVuaWZvcm0gZm9ybWF0IGZvciBJUHY2 IGV4dGVuc2lvbiBoZWFkZXJzIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBCcmlhbiBI YWJlcm1hbiAoYnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0KSBpcyB0aGUgZG9jdW1lbnQNCiAgICBz aGVwaGVyZC4NCiAgICBUb2tlbjogSmFyaSBBcmtrbw0KDQogIG8gZHJhZnQtaWV0Zi1zdG9ybS1y ZGRwLXJlZ2lzdHJpZXMtMDENCiAgICBJQU5BIFJlZ2lzdHJpZXMgZm9yIHRoZSBSRERQIChSZW1v dGUgRGlyZWN0IERhdGEgUGxhY2VtZW50KQ0KICAgIFByb3RvY29scyAoUHJvcG9zZWQgU3RhbmRh cmQpDQogICAgTm90ZTogRGF2aWQgQmxhY2sgKGRhdmlkLmJsYWNrQGVtYy5jb20pIGlzIHRoZSBk b2N1bWVudCBzaGVwaGVyZC4NCiAgICBUb2tlbjogRGF2aWQgSGFycmluZ3Rvbg0KDQoyLjEuMiBS ZXR1cm5pbmcgSXRlbXMNCg0KICBvIGRyYWZ0LWlldGYtZGhjLXZwbi1vcHRpb24tMTQNCiAgICBW aXJ0dWFsIFN1Ym5ldCBTZWxlY3Rpb24gT3B0aW9ucyBmb3IgREhDUHY0IGFuZCBESENQdjYgKFBy b3Bvc2VkDQogICAgU3RhbmRhcmQpDQogICAgTm90ZTogSm9obiBKYXNvbiBCcnpvem93c2tpIChq b2huX2Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb20pIGlzDQogICAgdGhlIGRvY3VtZW50IHNo ZXBoZXJkLg0KICAgIFRva2VuOiBSYWxwaCBEcm9tcw0KDQogIG8gZHJhZnQtaWV0Zi1pcHBtLW1l dHJpY3Rlc3QtMDUNCiAgICBJUFBNIHN0YW5kYXJkIGFkdmFuY2VtZW50IHRlc3RpbmcgKEJDUCkN CiAgICBOb3RlOiBIZW5rIFVpanRlcndhYWwgKGhlbmtAdWlqdGVyd2FhbC5ubCkgaXMgdGhlIGRv Y3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBXZXNsZXkgRWRkeQ0KDQoyLjIgSW5kaXZpZHVh bCBTdWJtaXNzaW9ucw0KMi4yLjEgTmV3IEl0ZW1zDQoNCiAgbyBkcmFmdC1kYWJvby13ZWJkYXYt c3luYy0wNg0KICAgIENvbGxlY3Rpb24gU3luY2hyb25pemF0aW9uIGZvciBXZWJEQVYgKFByb3Bv c2VkIFN0YW5kYXJkKQ0KICAgIFRva2VuOiBQZXRlciBTYWludC1BbmRyZQ0KDQogIG8gZHJhZnQt Z3JlZ29yaW8tdXJpdGVtcGxhdGUtMDcNCiAgICBVUkkgVGVtcGxhdGUgKFByb3Bvc2VkIFN0YW5k YXJkKQ0KICAgIE5vdGU6IE11cnJheSBLdWNoZXJhd3kgPG1za0BjbG91ZG1hcmsuY29tPiBpcyB0 aGUgRG9jdW1lbnQNCiAgICBTaGVwaGVyZC4NCiAgICBUb2tlbjogUGV0ZXIgU2FpbnQtQW5kcmUN Cg0KMi4yLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAgTk9ORQ0KDQozLiBEb2N1bWVudCBBY3Rpb25z DQozLjEgV0cgU3VibWlzc2lvbnMNCjMuMS4xIE5ldyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi1z aXBjbGYtcHJvYmxlbS1zdGF0ZW1lbnQtMDkNCiAgICBUaGUgQ29tbW9uIExvZyBGb3JtYXQgKENM RikgZm9yIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wNCiAgICAoU0lQKTogRnJhbWV3 b3JrIGFuZCBEYXRhIE1vZGVsIChJbmZvcm1hdGlvbmFsKQ0KICAgIE5vdGU6IFBldGVyIE11c2dy YXZlIChtdXNncmF2ZXBqQGdtYWlsLmNvbSkgaXMgdGhlIGRvY3VtZW50DQogICAgc2hlcGhlcmQu DQogICAgVG9rZW46IFJvYmVydCBTcGFya3MNCg0KMy4xLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAg Tk9ORQ0KDQozLjEuMyBGb3IgQWN0aW9uDQoNCiAgbyBkcmFmdC1pZXRmLXJ0Z3dnLWxmYS1hcHBs aWNhYmlsaXR5LTA0DQogICAgTEZBIGFwcGxpY2FiaWxpdHkgaW4gU1AgbmV0d29ya3MgKEluZm9y bWF0aW9uYWwpDQogICAgTm90ZTogQWx2YXJvIFJldGFuYSAoYWx2YXJvLnJldGFuYUBocC5jb20p IGlzIHRoZSBkb2N1bWVudCBzaGVwaGVyZC4NCiAgICBUb2tlbjogU3Rld2FydCBCcnlhbnQNCg0K My4yIEluZGl2aWR1YWwgU3VibWlzc2lvbnMgVmlhIEFEDQozLjIuMSBOZXcgSXRlbXMNCg0KICBv IGRyYWZ0LWFya2tvLWlwdjYtb25seS1leHBlcmllbmNlLTA0DQogICAgRXhwZXJpZW5jZXMgZnJv bSBhbiBJUHY2LU9ubHkgTmV0d29yayAoSW5mb3JtYXRpb25hbCkNCiAgICBUb2tlbjogUm9uIEJv bmljYQ0KDQogIG8gZHJhZnQtb2h5ZS1jYW5vbmljYWwtbGluay1yZWxhdGlvbi0wNA0KICAgIFRo ZSBDYW5vbmljYWwgTGluayBSZWxhdGlvbiAoSW5mb3JtYXRpb25hbCkNCiAgICBUb2tlbjogUGV0 ZXIgU2FpbnQtQW5kcmUNCg0KICBvIGRyYWZ0LWt1Y2hlcmF3eS1ka2ltLWF0cHMtMTMNCiAgICBE S0lNIEF1dGhvcml6ZWQgVGhpcmQtUGFydHkgU2lnbmVycyAoRXhwZXJpbWVudGFsKQ0KICAgIE5v dGU6IEJhcnJ5IExlaWJhIChiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZykgaXMgdGhlIGRvY3VtZW50 DQogICAgc2hlcGhlcmQuDQogICAgVG9rZW46IFNlYW4gVHVybmVyDQoNCiAgbyBkcmFmdC1hbXVu ZHNlbi1pdGVtLWFuZC1jb2xsZWN0aW9uLWxpbmstcmVsYXRpb25zLTA0DQogICAgVGhlIEl0ZW0g YW5kIENvbGxlY3Rpb24gTGluayBSZWxhdGlvbnMgKEluZm9ybWF0aW9uYWwpDQogICAgVG9rZW46 IFBldGVyIFNhaW50LUFuZHJlDQoNCiAgbyBkcmFmdC15ZXZzdGlmZXlldi1kaXNjbG9zdXJlLXJl bGF0aW9uLTAwDQogICAgVGhlICdkaXNjbG9zdXJlJyBMaW5rIFJlbGF0aW9uIFR5cGUgKEluZm9y bWF0aW9uYWwpDQogICAgTm90ZTogVGhlIElFVEYgTGFzdCBDYWxsIGVuZHMgb24gSmFudWFyeSA2 Lg0KICAgIFRva2VuOiBQZXRlciBTYWludC1BbmRyZQ0KDQozLjIuMiBSZXR1cm5pbmcgSXRlbXMN Cg0KICBOT05FDQoNCjMuMyBJUlRGIGFuZCBJbmRlcGVuZGVudCBTdWJtaXNzaW9uIFN0cmVhbSBE b2N1bWVudHMNCjMuMy4xIE5ldyBJdGVtcw0KDQogIE5PTkUNCg0KMy4zLjIgUmV0dXJuaW5nIEl0 ZW1zDQoNCiAgTk9ORQ0KDQo0LiBXb3JraW5nIEdyb3VwIEFjdGlvbnMNCjQuMSBXRyBDcmVhdGlv bg0KNC4xLjEgUHJvcG9zZWQgZm9yIElFVEYgUmV2aWV3DQoNCiAgTk9ORQ0KDQo0LjEuMiBQcm9w b3NlZCBmb3IgQXBwcm92YWwNCg0KICBvIFNQRiBVcGRhdGUgKHNwZmJpcykNCiAgICBUb2tlbjog UGV0ZQ0KDQo0LjIgV0cgUmVjaGFydGVyaW5nDQo0LjIuMSBVbmRlciBFdmFsdWF0aW9uIGZvciBJ RVRGIFJldmlldw0KDQogIG8gRGlzdHJpYnV0ZWQgTW9iaWxpdHkgTWFuYWdlbWVudCAoZG1tKQ0K ICAgIFRva2VuOiBKYXJpDQoNCiAgbyBMb2NhdG9yL0lEIFNlcGFyYXRpb24gUHJvdG9jb2wgKGxp c3ApDQogICAgVG9rZW46IEphcmkNCg0KICBvIFJvdXRpbmcgQXJlYSBXb3JraW5nIEdyb3VwIChy dGd3ZykNCiAgICBUb2tlbjogU3Rld2FydA0KDQogIG8gRGlhbWV0ZXIgTWFpbnRlbmFuY2UgYW5k IEV4dGVuc2lvbnMgKGRpbWUpDQogICAgVG9rZW46IERhbg0KDQoNCg== From dromasca@avaya.com Tue Jan 10 12:03:25 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DAA21F882D; Tue, 10 Jan 2012 12:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.312 X-Spam-Level: X-Spam-Status: No, score=-103.312 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwuH449YB6MC; Tue, 10 Jan 2012 12:03:25 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 80ADF1F0C41; Tue, 10 Jan 2012 12:03:24 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPyYDE/GmAcF/2dsb2JhbAA5CqxagQWBcgEBAQEDAQEBDwoRAzcHCwwEAgEIDQQEAQEBCgYMDAYBJigIAQEEARIIGodgm0ibJQSIVoJaYwSIB5J2jEo X-IronPort-AV: E=Sophos;i="4.71,489,1320642000"; d="scan'208,217";a="285598778" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Jan 2012 15:03:22 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Jan 2012 14:59:02 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCCFD2.E67F2165" Date: Tue, 10 Jan 2012 21:03:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] RFC 6158 Reviews: how does it work in practice? Thread-Index: AczP0WVUyRyUfU8NT4GUZo2TzzLlNgAAK72m References: <4F0C96D1.4090609@deployingradius.com> From: "Romascanu, Dan (Dan)" To: "Alan DeKok" , "Bernard Aboba" Cc: aaa-doctors@ietf.org, radext@ietf.org Subject: Re: [AAA-DOCTORS] [radext] RFC 6158 Reviews: how does it work in practice? X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 20:03:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCCFD2.E67F2165 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes.=20 The AAA-Doctors team secretary should scan all documents that enter IETF = Last Call and identify those who have any trace of = RADIUS/Diameter/other_AAA content, and then dispatch them to the = AAA-Doctors team for review according to some algorithm of his own.=20 OPS-DIR use this method and it works pretty well for them.=20 It's still best-effort, as all volunteer work we do in the IETF.=20 Dan -----Original Message----- From: radext-bounces@ietf.org on behalf of Alan DeKok Sent: Tue 1/10/2012 9:51 PM To: Bernard Aboba Cc: radext@ietf.org Subject: Re: [radext] RFC 6158 Reviews: how does it work in practice? =20 Bernard Aboba wrote: > [BA] How do we ensure that these reviews are actually carried out? cron? $ rsync -avz --delete ftp.rfc-editor.org::internet-drafts . $ perl -ne 'next if !/^draft-ietf-/;next if /^draft-ietf-radext/;next if /^draft-ietf-dime/;chop;split;next if ($_[2] eq "RFC");next if ($_[2] eq "Expired");next if ! -f "$_[0].txt";print $_[0],".txt\n";' < all_id.txt > radius.txt $ for x in `cat radius.txt`; do \ egrep -l RADIUS $x >> radext-review.txt; \ done That gives us a list (below). We could post the list once a month to radext and aaa-doctors. That would at least ensure the documents get noted in IESG review, or IETF last call. draft-ietf-emu-eaptunnel-req-09.txt draft-ietf-mip4-generic-notification-message-16.txt draft-ietf-mip6-bootstrapping-integrated-dhc-06.txt draft-ietf-mip6-hiopt-17.txt draft-ietf-netconf-access-control-07.txt draft-ietf-netext-radius-pmip6-06.txt draft-ietf-softwire-dslite-radius-ext-07.txt draft-ietf-abfab-aaa-saml-02.txt draft-ietf-abfab-arch-00.txt draft-ietf-abfab-gss-eap-04.txt draft-ietf-abfab-gss-eap-naming-01.txt draft-ietf-emu-chbind-12.txt draft-ietf-emu-eap-tunnel-method-01.txt draft-ietf-geopriv-held-measurements-04.txt draft-ietf-hokey-rfc5296bis-06.txt draft-ietf-karp-ops-model-01.txt draft-ietf-nea-pt-tls-01.txt draft-ietf-opsawg-management-stds-03.txt draft-ietf-precis-framework-01.txt draft-ietf-softwire-6rd-radius-attrib-04.txt draft-ietf-softwire-dslite-deployment-01.txt draft-ietf-storm-iscsi-cons-04.txt Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext ------_=_NextPart_001_01CCCFD2.E67F2165 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [radext] RFC 6158 Reviews: how does it work in = practice?

Yes.

The AAA-Doctors team secretary should scan all documents that enter IETF = Last Call and identify those who have any trace of = RADIUS/Diameter/other_AAA content, and then dispatch them to the = AAA-Doctors team for review according to some algorithm of his own.

OPS-DIR use this method and it works pretty well for them.

It's still best-effort, as all volunteer work we do in the IETF.

Dan


-----Original Message-----
From: radext-bounces@ietf.org on behalf of Alan DeKok
Sent: Tue 1/10/2012 9:51 PM
To: Bernard Aboba
Cc: radext@ietf.org
Subject: Re: [radext] RFC 6158 Reviews:  how does it work in = practice?

Bernard Aboba wrote:
> [BA]  How do we ensure that these reviews are actually carried = out?

  cron?

$ rsync -avz --delete ftp.rfc-editor.org::internet-drafts .

$ perl -ne 'next if !/^draft-ietf-/;next if /^draft-ietf-radext/;next = if
/^draft-ietf-dime/;chop;split;next if ($_[2] eq "RFC");next if = ($_[2] eq
"Expired");next if ! -f "$_[0].txt";print = $_[0],".txt\n";' < all_id.txt
> radius.txt

$ for x in `cat radius.txt`; do \
            egrep -l = RADIUS $x >> radext-review.txt; \
  done

  That gives us a list (below).  We could post the list once a = month to
radext and aaa-doctors.  That would at least ensure the documents = get
noted in IESG review, or IETF last call.

draft-ietf-emu-eaptunnel-req-09.txt
draft-ietf-mip4-generic-notification-message-16.txt
draft-ietf-mip6-bootstrapping-integrated-dhc-06.txt
draft-ietf-mip6-hiopt-17.txt
draft-ietf-netconf-access-control-07.txt
draft-ietf-netext-radius-pmip6-06.txt
draft-ietf-softwire-dslite-radius-ext-07.txt
draft-ietf-abfab-aaa-saml-02.txt
draft-ietf-abfab-arch-00.txt
draft-ietf-abfab-gss-eap-04.txt
draft-ietf-abfab-gss-eap-naming-01.txt
draft-ietf-emu-chbind-12.txt
draft-ietf-emu-eap-tunnel-method-01.txt
draft-ietf-geopriv-held-measurements-04.txt
draft-ietf-hokey-rfc5296bis-06.txt
draft-ietf-karp-ops-model-01.txt
draft-ietf-nea-pt-tls-01.txt
draft-ietf-opsawg-management-stds-03.txt
draft-ietf-precis-framework-01.txt
draft-ietf-softwire-6rd-radius-attrib-04.txt
draft-ietf-softwire-dslite-deployment-01.txt
draft-ietf-storm-iscsi-cons-04.txt

  Alan DeKok.
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.or= g/mailman/listinfo/radext

------_=_NextPart_001_01CCCFD2.E67F2165-- From aland@deployingradius.com Tue Jan 10 13:17:19 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5383C11E8076 for ; Tue, 10 Jan 2012 13:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99sY9kXPKmrI for ; Tue, 10 Jan 2012 13:17:19 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 130EB11E8071 for ; Tue, 10 Jan 2012 13:17:19 -0800 (PST) Received: by liberty.deployingradius.com (Postfix, from userid 1000) id 91DC912344FC; Tue, 10 Jan 2012 22:16:52 +0100 (CET) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 1.1) Message-Id: <20120110211652.91DC912344FC@liberty.deployingradius.com> Date: Tue, 10 Jan 2012 22:16:52 +0100 (CET) Subject: [AAA-DOCTORS] RADIUS Documents in Last Call for Tue Jan 10 22:16:52 CET 2012 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 21:17:19 -0000 From: Alan DeKok This is an automatically generated email. It lists the IETF internet-drafts which are WG items; in IETF Last Call, and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-netext-radius-pmip6-06.txt http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6-06/ From aland@freeradius.org Tue Jan 10 13:19:29 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838F121F84EC for ; Tue, 10 Jan 2012 13:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.152 X-Spam-Level: **** X-Spam-Status: No, score=4.152 tagged_above=-999 required=5 tests=[AWL=6.752, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnoU4kPiT2-1 for ; Tue, 10 Jan 2012 13:19:29 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DB99721F84E7 for ; Tue, 10 Jan 2012 13:19:28 -0800 (PST) Message-ID: <4F0CAB4B.8010807@freeradius.org> Date: Tue, 10 Jan 2012 22:19:07 +0100 From: Alan T DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: aaa-doctors@ietf.org References: <20120110211652.91DC912344FC@liberty.deployingradius.com> In-Reply-To: <20120110211652.91DC912344FC@liberty.deployingradius.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [AAA-DOCTORS] RADIUS Documents in Last Call for Tue Jan 10 22:16:52 CET 2012 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: aland@freeradius.org List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 21:19:29 -0000 Well, that seemed to work. I'll poke it to get the correct URL, and have cron send an email once a week. aland@freeradius.org wrote: > From: Alan DeKok > > This is an automatically generated email. It lists the IETF internet-drafts > which are WG items; in IETF Last Call, and which reference RADIUS. Drafts > from the RADEXT and DIME working groups are not included. > > -- > draft-ietf-netext-radius-pmip6-06.txt http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6-06/ > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors > > From aland@freeradius.org Tue Jan 10 13:28:19 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40F721F85DA for ; Tue, 10 Jan 2012 13:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.777 X-Spam-Level: X-Spam-Status: No, score=0.777 tagged_above=-999 required=5 tests=[AWL=3.376, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iy+MBlHz4Smu for ; Tue, 10 Jan 2012 13:28:19 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id ECF3521F85D6 for ; Tue, 10 Jan 2012 13:28:18 -0800 (PST) Message-ID: <4F0CAD5D.8060002@freeradius.org> Date: Tue, 10 Jan 2012 22:27:57 +0100 From: Alan T DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: aaa-doctors@ietf.org References: <20120110211652.91DC912344FC@liberty.deployingradius.com> In-Reply-To: <20120110211652.91DC912344FC@liberty.deployingradius.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------010605050100070000070100" Subject: Re: [AAA-DOCTORS] RADIUS Documents in Last Call for Tue Jan 10 22:16:52 CET 2012 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: aland@freeradius.org List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 21:28:20 -0000 This is a multi-part message in MIME format. --------------010605050100070000070100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit For reference, the Makefile is attached. Alan DeKok. --------------010605050100070000070100 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="Makefile" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Makefile" all: mail.txt .PHONY: sync sync: @rsync -q -avz --delete ftp.rfc-editor.org::internet-drafts internet-drafts/ internet-drafts/all_id.txt: sync last-call.txt: internet-drafts/all_id.txt @perl -ne 'next if !/^draft-ietf-/;next if /^draft-ietf-radext/;next if /^draft-ietf-dime/;next unless /In Last Call/;chop;split;next if ! -f "internet-drafts/$$_[0].txt";print "internet-drafts/",$$_[0],".txt\n";' < $< > $@ radius.txt: last-call.txt @grep -l RADIUS `cat $<` | sed 's,internet-drafts/,,' > $@ mail.txt: top.txt radius.txt @cp top.txt $@ @cat radius.txt | while read file; do \ y=`echo $$file | sed 's/-..\.txt//'`; \ echo "$$file http://datatracker.ietf.org/doc/$$y/" >> $@; \ done .PHONY: send send: @mail -aFrom:aland@freeradius.org -s "RADIUS Documents in Last Call for `date`" aaa-doctors@ietf.org < mail.txt --------------010605050100070000070100-- From dromasca@avaya.com Fri Jan 13 02:57:43 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691FD21F8608; Fri, 13 Jan 2012 02:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.27 X-Spam-Level: X-Spam-Status: No, score=-103.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5dvGifsDtjt; Fri, 13 Jan 2012 02:57:42 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5F19A21F85F1; Fri, 13 Jan 2012 02:57:36 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOwNEE+HCzI1/2dsb2JhbABChRCnDXuBBYFyAQEBAQMSEQ0EPhMGAQgNCAUCBgYMCwECAgMBRAcBBgQBBAESCBqjZYlykTgEgS+JWDNjBJsFjE0 X-IronPort-AV: E=Sophos;i="4.71,503,1320642000"; d="scan'208";a="286058423" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Jan 2012 05:57:33 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Jan 2012 05:44:17 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 13 Jan 2012 11:57:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the January 19, 2012 IESG Teleconference Thread-Index: AczRfyPKxMIpSIkRRyG8ppVDEejZswAYbF3A From: "Romascanu, Dan (Dan)" To: , , "YANG Doctors" , , "IETF DNS Directorate" Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for the January 19, 2012 IESG Teleconference X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 10:57:43 -0000 UGxlYXNlIGZpbmQgYmVsb3cgdGhlIHByZWxpbWluYXJ5IGFnZW5kYSBvZiB0aGUgMS8xOSBJRVNH IHRlbGVjaGF0LiBQbGVhc2Ugc2VuZCB5b3VyIHF1ZXN0aW9ucywgY29tbWVudHMgYW5kIGNvbmNl cm5zIGFib3V0IHRoZSBkb2N1bWVudHMgYW5kIGNoYXJ0ZXIgYnJvdWdodCB1cCBmb3IgV0cgYXBw cm92YWwgYmVmb3JlIFdlZG5lc2RheSAxLzE4IENPQi4gDQoNClRoYW5rcyBhbmQgUmVnYXJkcywN Cg0KRGFuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWVzZy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86aWVzZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg SUVTRyBTZWNyZXRhcnkNCg0KDQoyLiBQcm90b2NvbCBBY3Rpb25zDQoyLjEgV0cgU3VibWlzc2lv bnMNCjIuMS4xIE5ldyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi1tYXJmLXJlZGFjdGlvbi0wNA0K ICAgIFJlZGFjdGlvbiBvZiBQb3RlbnRpYWxseSBTZW5zaXRpdmUgRGF0YSBmcm9tIE1haWwgQWJ1 c2UgUmVwb3J0cw0KICAgIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBUb2tlbjogUGV0ZSBSZXNu aWNrDQoNCiAgbyBkcmFmdC1pZXRmLW1hcmYtYXV0aGZhaWx1cmUtcmVwb3J0LTA5DQogICAgQXV0 aGVudGljYXRpb24gRmFpbHVyZSBSZXBvcnRpbmcgdXNpbmcgdGhlIEFidXNlIFJlcG9ydCBGb3Jt YXQNCiAgICAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgVG9rZW46IFBldGUgUmVzbmljaw0KDQog IG8gZHJhZnQtaWV0Zi1uZXRleHQtcmFkaXVzLXBtaXA2LTA2DQogICAgUkFESVVTIFN1cHBvcnQg Zm9yIFByb3h5IE1vYmlsZSBJUHY2IChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBCYXNh dmFyYWogUGF0aWwgKEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20pIGlzIHRoZSBkb2N1bWVudA0K ICAgIHNoZXBoZXJkLg0KICAgIFRva2VuOiBKYXJpIEFya2tvDQoNCiAgbyBkcmFmdC1pZXRmLW5l dGV4dC1idWxrLXJlLXJlZ2lzdHJhdGlvbi0xMA0KICAgIEJ1bGsgQmluZGluZyBVcGRhdGUgU3Vw cG9ydCBmb3IgUHJveHkgTW9iaWxlIElQdjYgKFByb3Bvc2VkDQogICAgU3RhbmRhcmQpDQogICAg Tm90ZTogQmFzYXZhcmFqIFBhdGlsIChCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tKSBpcyB0aGUg ZG9jdW1lbnQNCiAgICBzaGVwaGVyZC4NCiAgICBUb2tlbjogSmFyaSBBcmtrbw0KDQogIG8gZHJh ZnQtaWV0Zi1vc3BmLW11bHRpLWluc3RhbmNlLTA3DQogICAgT1NQRiBNdWx0aS1JbnN0YW5jZSBF eHRlbnNpb25zIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBNYW5hdiBCaGF0aWEgKG1h bmF2LmJoYXRpYUBhbGNhdGVsLWx1Y2VudC5jb20pIGlzIHRoZSBkb2N1bWVudA0KICAgIHNoZXBo ZXJkLg0KICAgIFRva2VuOiBTdGV3YXJ0IEJyeWFudA0KDQogIG8gZHJhZnQtaWV0Zi1raXR0ZW4t c2FzbC1zYW1sLTA4DQogICAgQSBTQVNMIGFuZCBHU1MtQVBJIE1lY2hhbmlzbSBmb3IgU0FNTCAo UHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogVGhlIGRvY3VtZW50IHNoZXBoZXJkIGZvciB0 aGlzIGRvY3VtZW50IGlzIFNoYXduIEVtZXJ5DQogICAgKHNoYXduLmVtZXJ5QG9yYWNsZS5jb20p Lg0KICAgIFRva2VuOiBTdGVwaGVuIEZhcnJlbGwNCg0KICBvIGRyYWZ0LWlldGYtaWRyLWZzbS1z dWJjb2RlLTAyDQogICAgU3ViY29kZXMgZm9yIEJHUCBGaW5pdGUgU3RhdGUgTWFjaGluZSBFcnJv ciAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogU3VzYW4gSGFyZXMgaXMgdGhlIGRvY3Vt ZW50IHNoZXBoZXJkDQogICAgKFN1c2FuLkhhcmVzQGh1YXdlaS5jb20gb3Igc2hhcmVzQG5kemgu Y29tKS4NCiAgICBUb2tlbjogU3Rld2FydCBCcnlhbnQNCg0KICBvIGRyYWZ0LWlldGYtbWlsZS1y ZmM2MDQ2LWJpcy0wNQ0KICAgIFRyYW5zcG9ydCBvZiBSZWFsLXRpbWUgSW50ZXItbmV0d29yayBE ZWZlbnNlIChSSUQpIE1lc3NhZ2VzIG92ZXINCiAgICBIVFRQLyBUTFMgKFByb3Bvc2VkIFN0YW5k YXJkKQ0KICAgIE5vdGU6IEthdGhsZWVuIE1vcmlhcnR5IChrYXRobGVlbi5tb3JpYXJ0eUBlbWMu Y29tKSBpcyB0aGUgZG9jdW1lbnQNCiAgICBzaGVwaGVyZC4NCiAgICBUb2tlbjogU2VhbiBUdXJu ZXINCg0KICBvIGRyYWZ0LWlldGYtbWlsZS1yZmM2MDQ1LWJpcy0wNQ0KICAgIFJlYWwtdGltZSBJ bnRlci1uZXR3b3JrIERlZmVuc2UgKFJJRCkgKFByb3Bvc2VkIFN0YW5kYXJkKQ0KICAgIE5vdGU6 IEJyaWFuIFRyYW1tZWxsICh0cmFtbWVsbEB0aWsuZWUuZXRoei5jaCkgaXMgdGhlIGRvY3VtZW50 DQogICAgc2hlcGhlcmQuDQogICAgVG9rZW46IFNlYW4gVHVybmVyDQoNCjIuMS4yIFJldHVybmlu ZyBJdGVtcw0KDQogIE5PTkUNCg0KMi4yIEluZGl2aWR1YWwgU3VibWlzc2lvbnMNCjIuMi4xIE5l dyBJdGVtcw0KDQogIE5PTkUNCg0KMi4yLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAgTk9ORQ0KDQoz LiBEb2N1bWVudCBBY3Rpb25zDQozLjEgV0cgU3VibWlzc2lvbnMNCjMuMS4xIE5ldyBJdGVtcw0K DQogIG8gZHJhZnQtaWV0Zi1saXNwLW1hcC12ZXJzaW9uaW5nLTA2DQogICAgTElTUCBNYXAtVmVy c2lvbmluZyAoRXhwZXJpbWVudGFsKQ0KICAgIE5vdGU6IFRlcnJ5IE1hbmRlcnNvbiAodGVycnku bWFuZGVyc29uQGljYW5uLm9yZykgaXMgdGhlIGRvY3VtZW50DQogICAgc2hlcGhlcmQuDQogICAg VG9rZW46IEphcmkgQXJra28NCiAgICBXYXMgZGVmZXJyZWQgYnkgQWRyaWFuIEZhcnJlbCBvbiAy MDExLTA5LTIxDQoNCjMuMS4yIFJldHVybmluZyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi1saXNw LTE5DQogICAgTG9jYXRvci9JRCBTZXBhcmF0aW9uIFByb3RvY29sIChMSVNQKSAoRXhwZXJpbWVu dGFsKQ0KICAgIE5vdGU6IEpvZWwgSGFscGVybiAoam1oQGpvZWxoYWxwZXJuLmNvbSkgaXMgdGhl IGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBKYXJpIEFya2tvDQoNCiAgbyBkcmFmdC1p ZXRmLWxpc3AtbXVsdGljYXN0LTEyDQogICAgTElTUCBmb3IgTXVsdGljYXN0IEVudmlyb25tZW50 cyAoRXhwZXJpbWVudGFsKQ0KICAgIE5vdGU6IFdhc3NpbSBIYWRkYWQgPHdhc3NpbS5oYWRkYWRA ZXJpY3Nzb24uY29tPiBpcyB0aGUNCiAgICBkb2N1bWVudCBzaGVwaGVyZC4NCiAgICBUb2tlbjog SmFyaSBBcmtrbw0KDQozLjIgSW5kaXZpZHVhbCBTdWJtaXNzaW9ucyBWaWEgQUQNCjMuMi4xIE5l dyBJdGVtcw0KDQogIG8gZHJhZnQta29tcGVsbGEtbDJ2cG4tbDJ2cG4tMDgNCiAgICBMYXllciAy IFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrcyBVc2luZyBCR1AgZm9yIEF1dG8tZGlzY292ZXJ5IGFu ZA0KICAgIFNpZ25hbGluZyAoSW5mb3JtYXRpb25hbCkNCiAgICBOb3RlOiBSb3NzIENhbGxvbiAo cmNhbGxvbkBqdW5pcGVyLm5ldCkgaXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2Vu OiBTdGV3YXJ0IEJyeWFudA0KDQogIG8gZHJhZnQtYXNoLWdjYWMtYWxnb3JpdGhtLXNwZWMtMDMN CiAgICBHZW5lcmljIENvbm5lY3Rpb24gQWRtaXNzaW9uIENvbnRyb2wgKEdDQUMpIEFsZ29yaXRo bSBTcGVjaWZpY2F0aW9uDQogICAgZm9yIElQL01QTFMgTmV0d29ya3MgKEV4cGVyaW1lbnRhbCkN CiAgICBOb3RlOiBZb3VuZyBMZWUgKGxlZXlvdW5nQGh1YXdlaS5jb20pIGlzIHRoZSBkb2N1bWVu dCBzaGVwaGVyZC4NCiAgICBUb2tlbjogQWRyaWFuIEZhcnJlbA0KDQogIG8gZHJhZnQtamlhbmct YTYtdG8taGlzdG9yaWMtMDANCiAgICBNb3ZpbmcgQTYgdG8gSGlzdG9yaWMgU3RhdHVzIChJbmZv cm1hdGlvbmFsKQ0KICAgIE5vdGU6IFJhbHBoIERyb21zIChyZHJvbXNAY2lzY28uY29tKSBpcyB0 aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFJhbHBoIERyb21zDQoNCiAgbyBkcmFm dC15ZXZzdGlmZXlldi1kaXNjbG9zdXJlLXJlbGF0aW9uLTAyDQogICAgVGhlICdkaXNjbG9zdXJl JyBMaW5rIFJlbGF0aW9uIFR5cGUgKEluZm9ybWF0aW9uYWwpDQogICAgTm90ZTogVGhlIElFVEYg TGFzdCBDYWxsIGVuZHMgb24gSmFudWFyeSA2Lg0KICAgIFRva2VuOiBQZXRlciBTYWludC1BbmRy ZQ0KICAgIFdhcyBkZWZlcnJlZCBieSBQZXRlciBTYWludC1BbmRyZSBvbiAyMDEyLTAxLTAzDQoN CjMuMi4yIFJldHVybmluZyBJdGVtcw0KDQogIE5PTkUNCg0KMy4zIElSVEYgYW5kIEluZGVwZW5k ZW50IFN1Ym1pc3Npb24gU3RyZWFtIERvY3VtZW50cw0KMy4zLjEgTmV3IEl0ZW1zDQoNCiAgTk9O RQ0KDQozLjMuMiBSZXR1cm5pbmcgSXRlbXMNCg0KICBOT05FDQoNCjQuIFdvcmtpbmcgR3JvdXAg QWN0aW9ucw0KNC4xIFdHIENyZWF0aW9uDQo0LjEuMSBQcm9wb3NlZCBmb3IgSUVURiBSZXZpZXcN Cg0KICBOT05FDQoNCjQuMS4yIFByb3Bvc2VkIGZvciBBcHByb3ZhbA0KDQogIE5PTkUNCg0KNC4y IFdHIFJlY2hhcnRlcmluZw0KNC4yLjEgVW5kZXIgRXZhbHVhdGlvbiBmb3IgSUVURiBSZXZpZXcN Cg0KICBOT05FDQoNCjQuMi4yIFByb3Bvc2VkIGZvciBBcHByb3ZhbA0KDQogIG8gTG9jYXRvci9J RCBTZXBhcmF0aW9uIFByb3RvY29sIChsaXNwKQ0KICAgIFRva2VuOiBKYXJpDQoNCiAgbyBEaWFt ZXRlciBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucyAoZGltZSkNCiAgICBUb2tlbjogRGFuDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KKiBQ bGVhc2Ugc2VlIHRoZSBJRCBUcmFja2VyIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy8pIGZvcg0KZGV0YWlscyBvbiBkb2N1bWVudHMgdGhhdCBhcmUgdW5kZXIgZGlzY3Vzc2lvbiBi eSB0aGUgSUVTRy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0K From aland@deployingradius.com Sat Jan 14 16:22:30 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE8621F84D7 for ; Sat, 14 Jan 2012 16:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.349 X-Spam-Level: X-Spam-Status: No, score=-100.349 tagged_above=-999 required=5 tests=[AWL=2.251, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY7+WwRoKpTT for ; Sat, 14 Jan 2012 16:22:29 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEAC21F84D5 for ; Sat, 14 Jan 2012 16:22:29 -0800 (PST) Received: by liberty.deployingradius.com (Postfix, from userid 1000) id 18FCD12344FC; Sun, 15 Jan 2012 01:22:02 +0100 (CET) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 1.1) Message-Id: <20120115002202.18FCD12344FC@liberty.deployingradius.com> Date: Sun, 15 Jan 2012 01:22:02 +0100 (CET) Subject: [AAA-DOCTORS] RADIUS Documents in Last Call for Sun Jan 15 01:22:01 CET 2012 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 00:22:30 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items; in IETF Last Call, and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-netext-radius-pmip6-06.txt http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6/ From glenzorn@gmail.com Sat Jan 14 20:44:09 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5D621F848B for ; Sat, 14 Jan 2012 20:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.953 X-Spam-Level: X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50eFJeeryogw for ; Sat, 14 Jan 2012 20:44:09 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 10FEF21F847D for ; Sat, 14 Jan 2012 20:44:08 -0800 (PST) Received: by qadz32 with SMTP id z32so353462qad.10 for ; Sat, 14 Jan 2012 20:44:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Rryu1Q1+ClsMzJn8eOTGdJmT8ibPpDQP1tdJ+4E1ySo=; b=F01DhRblFdcZ/EUNPxhb5PttiBmpllrT1euVzD4t47WEzREWvJiEZM/LEiymkq28AS J4Ju46PkCWeZXWJwySn6TrZfsJsI0xWX3NefOrCqWD8Vkgt9VpSl9Yel88Y2MoFIC37Y VssB9aCR8e+WVgFr2MQnZEPMp/Qs/UmNEhaqE= Received: by 10.224.186.76 with SMTP id cr12mr8769089qab.25.1326602647098; Sat, 14 Jan 2012 20:44:07 -0800 (PST) Received: from [192.168.1.98] (ppp-58-11-144-103.revip2.asianet.co.th. [58.11.144.103]) by mx.google.com with ESMTPS id hv20sm27860402qab.22.2012.01.14.20.44.04 (version=SSLv3 cipher=OTHER); Sat, 14 Jan 2012 20:44:05 -0800 (PST) Message-ID: <4F125992.9050901@gmail.com> Date: Sun, 15 Jan 2012 11:44:02 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 CC: aaa-doctors@ietf.org References: <20120115002202.18FCD12344FC@liberty.deployingradius.com> In-Reply-To: <20120115002202.18FCD12344FC@liberty.deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [AAA-DOCTORS] RADIUS Documents in Last Call for Sun Jan 15 01:22:01 CET 2012 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 04:44:09 -0000 On 1/15/2012 7:22 AM, aland@freeradius.org wrote: > This is an automatically generated email. It lists the IETF internet-drafts > which are WG items; in IETF Last Call, and which reference RADIUS. Drafts > from the RADEXT and DIME working groups are not included. > > -- > draft-ietf-netext-radius-pmip6-06.txt http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6/ I've reviewed (& commented upon) this draft 3 or 4 times already, to little effect; I'll let somebody else give it a shot... > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors From bernard_aboba@hotmail.com Sat Jan 14 20:53:12 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F3B21F848B for ; Sat, 14 Jan 2012 20:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.628 X-Spam-Level: X-Spam-Status: No, score=-101.628 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22PPaF-Ewj-m for ; Sat, 14 Jan 2012 20:53:12 -0800 (PST) Received: from blu0-omc2-s17.blu0.hotmail.com (blu0-omc2-s17.blu0.hotmail.com [65.55.111.92]) by ietfa.amsl.com (Postfix) with ESMTP id E9A1721F847B for ; Sat, 14 Jan 2012 20:53:11 -0800 (PST) Received: from BLU0-P1-EAS123 ([65.55.111.71]) by blu0-omc2-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 Jan 2012 20:53:11 -0800 X-Originating-IP: [24.17.217.162] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <20120115002202.18FCD12344FC@liberty.deployingradius.com> <4F125992.9050901@gmail.com> Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: <4F125992.9050901@gmail.com> Date: Sat, 14 Jan 2012 20:54:28 -0800 To: Glen Zorn MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 15 Jan 2012 04:53:11.0373 (UTC) FILETIME=[950A7FD0:01CCD341] Cc: "aaa-doctors@ietf.org" Subject: Re: [AAA-DOCTORS] RADIUS Documents in Last Call for Sun Jan 15 01:22:01 CET 2012 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 04:53:13 -0000 Can you send a link to your last review? On Jan 14, 2012, at 20:44, "Glen Zorn" wrote: > On 1/15/2012 7:22 AM, aland@freeradius.org wrote: >=20 >> This is an automatically generated email. It lists the IETF internet-dr= afts >> which are WG items; in IETF Last Call, and which reference RADIUS. Draft= s >> from the RADEXT and DIME working groups are not included. >>=20 >> -- >> draft-ietf-netext-radius-pmip6-06.txt http://datatracker.ietf.org/doc/dr= aft-ietf-netext-radius-pmip6/ >=20 > I've reviewed (& commented upon) this draft 3 or 4 times already, to > little effect; I'll let somebody else give it a shot... >=20 >> _______________________________________________ >> AAA-DOCTORS mailing list >> AAA-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/aaa-doctors >=20 > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors From glenzorn@gmail.com Sun Jan 15 00:00:42 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF6521F8497 for ; Sun, 15 Jan 2012 00:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.276 X-Spam-Level: X-Spam-Status: No, score=-3.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sghe6Hxx1byI for ; Sun, 15 Jan 2012 00:00:41 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAFA21F847B for ; Sun, 15 Jan 2012 00:00:41 -0800 (PST) Received: by iaae16 with SMTP id e16so7337620iaa.31 for ; Sun, 15 Jan 2012 00:00:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=S4BZBSKuZ6u+Cb9HtllXi6jb9jVbh1hCIVh5q5JBGhY=; b=PRZrn5jSjiXYrCVKVc9jz68HPNB/la2008U1HBdaVeziZalEURhaye049Wt9N0+6ug NURkxM2R3EgclW1baO+NsWP9w717niufRDRhGtBYEv3/8NDWRxpT5sQVMQ3/RhTxSceo 1SJMylnK7NvKyW2ng7INCoXRonZAKgW3h2s9U= Received: by 10.50.180.138 with SMTP id do10mr7787599igc.20.1326614441089; Sun, 15 Jan 2012 00:00:41 -0800 (PST) Received: from [192.168.1.98] (ppp-58-11-144-103.revip2.asianet.co.th. [58.11.144.103]) by mx.google.com with ESMTPS id l35sm50726207ibj.0.2012.01.15.00.00.38 (version=SSLv3 cipher=OTHER); Sun, 15 Jan 2012 00:00:40 -0800 (PST) Message-ID: <4F1287A4.4090709@gmail.com> Date: Sun, 15 Jan 2012 15:00:36 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Bernard Aboba References: <20120115002202.18FCD12344FC@liberty.deployingradius.com> <4F125992.9050901@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "aaa-doctors@ietf.org" Subject: Re: [AAA-DOCTORS] RADIUS Documents in Last Call for Sun Jan 15 01:22:01 CET 2012 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 08:00:42 -0000 On 1/15/2012 11:54 AM, Bernard Aboba wrote: > Can you send a link to your last review? Nope, Outlook ate all my email archives awhile back... > > > > On Jan 14, 2012, at 20:44, "Glen Zorn" wrote: > >> On 1/15/2012 7:22 AM, aland@freeradius.org wrote: >> >>> This is an automatically generated email. It lists the IETF internet-drafts >>> which are WG items; in IETF Last Call, and which reference RADIUS. Drafts >>> from the RADEXT and DIME working groups are not included. >>> >>> -- >>> draft-ietf-netext-radius-pmip6-06.txt http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6/ >> >> I've reviewed (& commented upon) this draft 3 or 4 times already, to >> little effect; I'll let somebody else give it a shot... >> >>> _______________________________________________ >>> 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 jouni.nospam@gmail.com Sun Jan 15 00:53:30 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D40B21F849C for ; Sun, 15 Jan 2012 00:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaaiLsMN4LEX for ; Sun, 15 Jan 2012 00:53:29 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51CCD21F8489 for ; Sun, 15 Jan 2012 00:53:29 -0800 (PST) Received: by lagv3 with SMTP id v3so1223787lag.31 for ; Sun, 15 Jan 2012 00:53:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cX8hZaNHnvxUFXdZrXqY+mpnid2gbROezy7VF9Y64s4=; b=TJeTRujRcIJ1WEmo2fTQuf10Q7CKvHXSkBiyrCpeRvcoVQysB2F1SLBFXJVs1KvAo1 OpUmCBhRSuQp5G704NC0mfIj/JXKsD2ZDEfNY3jMPSu0QM+GCoK+/2j/FUIRCRkrZzad h+oQu3UitZWXVg/rvEMsuG4zBBaMlj1kSVvXk= Received: by 10.112.103.167 with SMTP id fx7mr1820835lbb.48.1326617607430; Sun, 15 Jan 2012 00:53:27 -0800 (PST) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id lz18sm4638603lab.17.2012.01.15.00.53.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Jan 2012 00:53:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <4F125992.9050901@gmail.com> Date: Sun, 15 Jan 2012 10:53:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <73F7171F-99D5-42A2-B363-47F5752B5823@gmail.com> References: <20120115002202.18FCD12344FC@liberty.deployingradius.com> <4F125992.9050901@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1251.1) Cc: aaa-doctors@ietf.org Subject: Re: [AAA-DOCTORS] RADIUS Documents in Last Call for Sun Jan 15 01:22:01 CET 2012 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 08:53:30 -0000 Glen, I don't recall seeing any recently.. I saw Bernerd's. Where did you send = them? - Jouni On Jan 15, 2012, at 6:44 AM, Glen Zorn wrote: > On 1/15/2012 7:22 AM, aland@freeradius.org wrote: >=20 >> This is an automatically generated email. It lists the IETF = internet-drafts >> which are WG items; in IETF Last Call, and which reference RADIUS. = Drafts >> from the RADEXT and DIME working groups are not included. >>=20 >> -- >> draft-ietf-netext-radius-pmip6-06.txt = http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6/ >=20 > I've reviewed (& commented upon) this draft 3 or 4 times already, to > little effect; I'll let somebody else give it a shot... >=20 >> _______________________________________________ >> AAA-DOCTORS mailing list >> AAA-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/aaa-doctors >=20 > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors From bernard_aboba@hotmail.com Thu Jan 19 08:16:21 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0841F21F8691 for ; Thu, 19 Jan 2012 08:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.294 X-Spam-Level: X-Spam-Status: No, score=-102.294 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUnDiDI5SDuY for ; Thu, 19 Jan 2012 08:16:19 -0800 (PST) Received: from blu0-omc2-s1.blu0.hotmail.com (blu0-omc2-s1.blu0.hotmail.com [65.55.111.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2D921F868A for ; Thu, 19 Jan 2012 08:16:19 -0800 (PST) Received: from BLU152-W13 ([65.55.111.73]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 08:16:19 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_75ce2aee-23fe-45a0-9629-e8455f2cec62_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Thu, 19 Jan 2012 08:16:18 -0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2012 16:16:19.0121 (UTC) FILETIME=[AD4B8210:01CCD6C5] Subject: [AAA-DOCTORS] Review of draft-ietf-radext-radsec X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:16:21 -0000 --_75ce2aee-23fe-45a0-9629-e8455f2cec62_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a review of "TLS Encryption for RADIUS" draft-ietf-radext-radsec.=20 Overall=2C this draft was a pleasant to read=2C and it is clear that a lot = of thought as well as implementation experience has gone into it.=20 Kudos to the authors.=20 General Issues There is a considerable amount of text relating to dynamic discovery in thi= s document=2C yet there is only an informational reference to it.=20 Since inserting a normative reference to dynamic discovery could delay the = publication of this document unnecessarily=2C my recommendation is to consolidate some of = the dynamic discovery material into a single section in which you can discuss the impli= cations=2C while clearly indicating the status of the dynamic discovery work (e.g. still und= er development=2C optional to implement along with RADSEC=2C etc.).=20 For example=2C you might consider consolidating the following text from Sec= tions 3.1 and 6=20 and placing it prior to the current Section 3.1: Section 3.X: Implications of Dynamic Peer Discovery One mechanism to discover RADIUS over TLS peers dynamically via DNS=20 is specified in [I-D.ietf-radext-dynamic-discovery]. While this mechani= sm is still under development and therefore is not a normative dependency o= f RADIUS/TLS=2C the use of dynamic discovery has potential future implicat= ions that are important to understand.=20 If dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery] is used=2C peer authentication alone is not sufficient=3B the peer must also be authorised to perform user authentications. In these cases=2C the trust fabric cannot depend on peer authentication methods like DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be properly authorised. Typically=2C this can be achieved by adding appropriate authorisation fields into a X.509 certificate. Such fields include SRV authority [RFC4985]=2C subjectAltNames=2C or a defined list of certificate fingerprints. Operators of a RADIUS/TLS infrastructure should define their own authorisation trust model and apply this model to the certificates. The checks enumerated in Section 2.3 provide sufficient flexibility for the implementation of authorisation trust models. [BA] I think you need to be more prescriptive here. Are there specific fields that a RADSEC TLS certificate should contain? Having individual implementations/deployments defining their own authorization schemes seems like a bad idea. =20 In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C a RADIUS/TLS node needs to be able to accept connections from a large=2C not previously known=2C group of hosts=2C possibly the whole internet. In this case=2C the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer=2C i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks=2C just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs=2C checking critical extensions=2C checking subjectAltNames etc.) to prevent unauthorised connections. Other comments Section 1 One mechanism to discover RADIUS over TLS peers with DNS is specified in [I-D.ietf-radext-dynamic-discovery]. [BA] Recommend moving this to a section devoted to dynamic discovery.=20 Section 2.1 See section Section 3.3 (4) and (5) for considerations regarding separation of authentication=2C accounting and dynauth traffic. [BA] Recommend changing to: "See Section 3.3 for considerations regarding separation of authentication=2C accounting and dynamic authorisation traffic." Section 2.3 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The shared secret to compute the (obsolete) MD5 integrity checks and attribute encryption MUST be "radsec" (see Section 3.3 (2) ). Section 3.1 (3) If dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery] is used=2C peer authentication alone is not sufficient=3B the peer must also be authorised to perform user authentications. In these cases=2C the trust fabric cannot depend on peer authentication methods like DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be properly authorised. Typically=2C this can be achieved by adding appropriate authorisation fields into a X.509 certificate. Such fields include SRV authority [RFC4985]=2C subjectAltNames=2C or a defined list of certificate fingerprints. Operators of a RADIUS/TLS infrastructure should define their own authorisation trust model and apply this model to the certificates. The checks enumerated in Section 2.3 provide sufficient flexibility for the implementation of authorisation trust models. As noted above=2C I'd suggest removing this material from Section 3.1 and=20 consolidating it with other dynamic-discovery material. =20 Section 3.3 Note well: it is not required for an implementation to actually process these packet types. It is sufficient that upon receiving such a packet=2C an unconditional NAK is sent back to indicate that the action is not supported. [BA] What Error-Cause attribute value should be included within the NAK to = make it clear that the action is not supported? Error 406 "Unsupported Extension"? That is what RFC 5176 Section 3.5 seems to indicate.=20 There is no RADIUS datagram to signal an Accounting NAK. Clients may be misconfigured to send Accounting packets to a RADIUS/TLS server which does not wish to process their Accounting packet. The server will need to silently drop the packet. The client will need to deduce from the absence of replies that it is misconfigured=3B no negative ICMP response will reveal this. [BA] This seems like a bad idea. How about requiring implementations not supporting Accounting to respond with an Accounting-Response containing Error-Cause attribute value 406? Implementations receiving an Accounting-R= esponse with this Error-Cause can be required to treat this like an ICMP response.= =20 Section 4 As a consequence=2C the selection of transports to communicate from a client to a server is a manual administrative action. An automatic fallback to RADIUS/UDP is NOT RECOMMENDED=2C as it may lead to down- bidding attacks on the peer communication. [BA] If a fixed shared secret "radsec" is used alongside fallback to RADIUS= /UDP=2C that seems more like a MUST NOT!! Section 6 In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C a RADIUS/TLS node needs to be able to accept connections from a large=2C not previously known=2C group of hosts=2C possibly the whole internet. In this case=2C the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer=2C i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks=2C just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs=2C checking critical extensions=2C checking subjectAltNames etc.) to prevent unauthorised connections. [BA] I'd recommend collecting this and other dynamic-discovery related mate= rial into a separate section prior to 3.1.=20 Appendix C. Assessment of Crypto-Agility Requirements The RADIUS Crypto-Agility Requirements (link to RFC once issued here) defines numerous classification criteria for protocols that strive to enhance the security of RADIUS. It contains mandatory (M) and recommended (R) criteria which crypto-agile protocols have to fulfill. The authors believe that the following assessment about the crypto-agility properties of RADIUS/TLS are true. [BA] The Crypto-Agility RFC is now published so you should reference that. = = --_75ce2aee-23fe-45a0-9629-e8455f2cec62_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This is a review of "TLS Encryptio= n for RADIUS" draft-ietf-radext-radsec.

Overall=2C= this draft was a pleasant to read=2C and it is clear that a lot of thought= as well as implementation experience has gone into it.

Kudos to th= e authors.

General Issues

There is= a considerable amount of text relating to dynamic discovery in this docume= nt=2C yet
there is only an informational reference to it.

Since = inserting a normative reference to dynamic discovery could delay the public= ation of
this document unnecessarily=2C my recommendation is to consolid= ate some of the dynamic
discovery material into a single section in whic= h you can discuss the implications=2C while
clearly indicating the statu= s of the dynamic discovery work (e.g. still under development=2C optional t= o
implement along with RADSEC=2C etc.).

For example=2C you might= consider consolidating the following text from Sections 3.1 and 6
and = placing it prior to the current Section 3.1:

Section 3.X: =3B Im= plications of Dynamic Peer Discovery

 =3B =3B One mechanism to discover RADIUS over TLS peers dynamicall= y via DNS
 =3B =3B is specified in [I-D.ietf-radext-dynamic-discovery]. = =3B While this mechanism
 =3B =3B is still under development and therefore is not a normativ= e dependency of
 =3B =3B RADIUS/TLS=2C the use of dynamic discovery has potential f= uture implications that are
 =3B =3B important to understand.

 =3B =3B If dynam= ic peer discovery as per
 =3B =3B [I-D.ietf-radext-dynamic-disco= very] is used=2C peer authentication
 =3B =3B alone is not suffi= cient=3B the peer must also be authorised to perform
 =3B =3B us= er authentications. =3B In these cases=2C the trust fabric cannot depen= d
 =3B =3B on peer authentication methods like DNSSEC to identif= y RADIUS/TLS
 =3B =3B nodes. =3B The nodes also need to be p= roperly authorised. =3B Typically=2C
 =3B =3B this can be ac= hieved by adding appropriate authorisation fields into
 =3B =3B = a X.509 certificate. =3B Such fields include SRV authority [RFC4985]=2C=
 =3B =3B subjectAltNames=2C or a defined list of certificate fi= ngerprints.
 =3B =3B Operators of a RADIUS/TLS infrastructure sh= ould define their own
 =3B =3B authorisation trust model and app= ly this model to the certificates.
 =3B =3B The checks enumerate= d in Section 2.3 provide sufficient flexibility
 =3B =3B for the= implementation of authorisation trust models.

[BA] I think you need= to be more prescriptive here. =3B Are there specific
fields that a = RADSEC TLS certificate should contain? =3B Having individual
impleme= ntations/deployments defining their own authorization schemes seems
like= a bad idea. =3B

 =3B =3B In the case of dynamic peer d= iscovery as per
 =3B =3B [I-D.ietf-radext-dynamic-discovery]=2C = a RADIUS/TLS node needs to be
 =3B =3B able to accept connection= s from a large=2C not previously known=2C group
 =3B =3B of host= s=2C possibly the whole internet. =3B In this case=2C the server's
&= nbsp=3B =3B RADIUS/TLS port can not be protected from unauthorised conn= ection
 =3B =3B attempts with measures on the network layer=2C i= .e. access lists and
 =3B =3B firewalls. =3B This opens more= attack vectors for Distributed Denial of
 =3B =3B Service attac= ks=2C just like any other service that is supposed to
 =3B =3B s= erve arbitrary clients (like for example web servers).

 =3B = =3B In the case of dynamic peer discovery as per
 =3B =3B [I-D.i= etf-radext-dynamic-discovery]=2C X.509 certificates are the only
 = =3B =3B proof of authorisation for a connecting RADIUS/TLS nodes. = =3B Special
 =3B =3B care needs to be taken that certificates ge= t verified properly
 =3B =3B according to the chosen trust model= (particularly: consulting CRLs=2C
 =3B =3B checking critical ex= tensions=2C checking subjectAltNames etc.) to
 =3B =3B prevent u= nauthorised connections.

Other comments

Section 1

&nbs= p=3B =3B One mechanism to discover RADIUS over TLS peers with DNS is sp= ecified in
 =3B =3B [I-D.ietf-radext-dynamic-discovery].

= [BA] Recommend moving this to a section devoted to dynamic discovery.
<= br>Section 2.1

 =3B =3B See
 =3B =3B section Sect= ion 3.3 (4) and (5) for considerations regarding
 =3B =3B separa= tion of authentication=2C accounting and dynauth traffic.

[BA] Recom= mend changing to:

 =3B =3B "See Section 3.3 for consideratio= ns regarding separation of
 =3B =3B =3B authentication=2C ac= counting and dynamic authorisation traffic."

Section 2.3

&nbs= p=3B =3B 4. =3B start exchanging RADIUS datagrams. =3B Note Sec= tion 3.3 (1) ). =3B The
 =3B =3B =3B =3B =3B&nbs= p=3B shared secret to compute the (obsolete) MD5 integrity checks and
&n= bsp=3B =3B =3B =3B =3B =3B attribute encryption MUST be= "radsec" (see Section 3.3 (2) ).

Section 3.1

 =3B = =3B (3) If dynamic peer discovery as per
 =3B =3B [I-D.ietf-rade= xt-dynamic-discovery] is used=2C peer authentication
 =3B =3B al= one is not sufficient=3B the peer must also be authorised to perform
&nb= sp=3B =3B user authentications. =3B In these cases=2C the trust fab= ric cannot depend
 =3B =3B on peer authentication methods like D= NSSEC to identify RADIUS/TLS
 =3B =3B nodes. =3B The nodes a= lso need to be properly authorised. =3B Typically=2C
 =3B = =3B this can be achieved by adding appropriate authorisation fields into =3B =3B a X.509 certificate. =3B Such fields include SRV auth= ority [RFC4985]=2C
 =3B =3B subjectAltNames=2C or a defined list= of certificate fingerprints.
 =3B =3B Operators of a RADIUS/TLS= infrastructure should define their own
 =3B =3B authorisation t= rust model and apply this model to the certificates.
 =3B =3B Th= e checks enumerated in Section 2.3 provide sufficient flexibility
 = =3B =3B for the implementation of authorisation trust models.

As= noted above=2C I'd suggest removing this material from Section 3.1 and consolidating it with other dynamic-discovery material.  =3B

Se= ction 3.3

 =3B =3B Note well: it is not required for an impl= ementation
 =3B =3B to actually process these packet types. = =3B It is sufficient that upon
 =3B =3B receiving such a packet= =2C an unconditional NAK is sent back to
 =3B =3B indicate that = the action is not supported.

[BA] What Error-Cause attribute value s= hould be included within the NAK to make it
clear that the action is not= supported? =3B Error 406 "Unsupported Extension"?
That is what RFC = 5176 Section 3.5 seems to indicate.

 =3B =3B There
 = =3B =3B is no RADIUS datagram to signal an Accounting NAK. =3B Clie= nts may be
 =3B =3B misconfigured to send Accounting packets to = a RADIUS/TLS server which
 =3B =3B does not wish to process thei= r Accounting packet. =3B The server will
 =3B =3B need to si= lently drop the packet. =3B The client will need to deduce
 =3B&= nbsp=3B from the absence of replies that it is misconfigured=3B no negative=
 =3B =3B ICMP response will reveal this.

[BA] This seems= like a bad idea. =3B How about requiring implementations not
suppor= ting Accounting to respond with an Accounting-Response containing
Error-= Cause attribute value 406? =3B Implementations receiving an Accounting-= Response
with this Error-Cause can be required to treat this like an ICM= P response.

Section 4

 =3B =3B As a consequence=2C t= he selection of transports to communicate from a
 =3B =3B client= to a server is a manual administrative action. =3B An automatic
&nb= sp=3B =3B fallback to RADIUS/UDP is NOT RECOMMENDED=2C as it may lead t= o down-
 =3B =3B bidding attacks on the peer communication.
<= br>[BA] If a fixed shared secret "radsec" is used alongside fallback to RAD= IUS/UDP=2C
that seems more like a MUST NOT!!

Section 6

&nb= sp=3B =3B In the case of dynamic peer discovery as per
 =3B = =3B [I-D.ietf-radext-dynamic-discovery]=2C a RADIUS/TLS node needs to be =3B =3B able to accept connections from a large=2C not previously= known=2C group
 =3B =3B of hosts=2C possibly the whole internet= . =3B In this case=2C the server's
 =3B =3B RADIUS/TLS port = can not be protected from unauthorised connection
 =3B =3B attem= pts with measures on the network layer=2C i.e. access lists and
 =3B=  =3B firewalls. =3B This opens more attack vectors for Distributed = Denial of
 =3B =3B Service attacks=2C just like any other servic= e that is supposed to
 =3B =3B serve arbitrary clients (like for= example web servers).

 =3B =3B In the case of dynamic peer = discovery as per
 =3B =3B [I-D.ietf-radext-dynamic-discovery]=2C= X.509 certificates are the only
 =3B =3B proof of authorisation= for a connecting RADIUS/TLS nodes. =3B Special
 =3B =3B car= e needs to be taken that certificates get verified properly
 =3B&nbs= p=3B according to the chosen trust model (particularly: consulting CRLs=2C<= br> =3B =3B checking critical extensions=2C checking subjectAltName= s etc.) to
 =3B =3B prevent unauthorised connections.

[BA] I'd recommend collecting this and other dynamic-discovery related mat= erial
into a separate section prior to 3.1.

Appendix C. Assessme= nt of Crypto-Agility Requirements


 =3B =3B The RADIUS Cr= ypto-Agility Requirements (link to RFC once issued here)
 =3B = =3B defines numerous classification criteria for protocols that strive to =3B =3B enhance the security of RADIUS. =3B It contains mand= atory (M) and
 =3B =3B recommended (R) criteria which crypto-agi= le protocols have to
 =3B =3B fulfill. =3B The authors belie= ve that the following assessment about the
 =3B =3B crypto-agili= ty properties of RADIUS/TLS are true.

[BA] The Crypto-Agility RFC is= now published so you should reference that.
=
= --_75ce2aee-23fe-45a0-9629-e8455f2cec62_-- From aland@deployingradius.com Sat Jan 21 16:22:30 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9A921F8493 for ; Sat, 21 Jan 2012 16:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.704 X-Spam-Level: X-Spam-Status: No, score=-99.704 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9UWAugam6WK for ; Sat, 21 Jan 2012 16:22:30 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 221DE21F848C for ; Sat, 21 Jan 2012 16:22:30 -0800 (PST) Received: by liberty.deployingradius.com (Postfix, from userid 1000) id A4AA01234351; Sun, 22 Jan 2012 01:22:01 +0100 (CET) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 1.1) Message-Id: <20120122002201.A4AA01234351@liberty.deployingradius.com> Date: Sun, 22 Jan 2012 01:22:01 +0100 (CET) Subject: [AAA-DOCTORS] RADIUS Documents in Last Call for Sun Jan 22 01:22:01 CET 2012 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 00:22:30 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items; in IETF Last Call, and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-netext-radius-pmip6-06.txt http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6/ From dromasca@avaya.com Fri Jan 27 10:31:56 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511B521F8670; Fri, 27 Jan 2012 10:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.084 X-Spam-Level: X-Spam-Status: No, score=-103.084 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+1mWPFXjXFK; Fri, 27 Jan 2012 10:31:55 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 770FC21F863F; Fri, 27 Jan 2012 10:31:55 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAInsIk/GmAcF/2dsb2JhbABEhQuoTXqBBYFyAQEBAQMSEQ0EUQYBCA0IAQQCBgYMCwECAgMBRAcBBgQBBAESCBqkIolykV+BL4diASQGNReCbhMOgSgMFYIYM2MEmxOMVQ X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="326899254" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Jan 2012 13:31:54 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jan 2012 13:26:38 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 27 Jan 2012 19:31:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the February 2, 2012 IESG Teleconference Thread-Index: AczcgOtnocb/4tTnShaVT1QxqpbivQAoLXfg From: "Romascanu, Dan (Dan)" To: , , "IETF DNS Directorate" , "YANG Doctors" , Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for the February 2, 2012 IESG Teleconference X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 18:31:56 -0000 UGxlYXNlIGZpbmQgYmVsb3cgdGhlIHByZWxpbWluYXJ5IGFnZW5kYSBvZiB0aGUgSUVTRyB0ZWxl Y2hhdCBvbiAyLzIuIFBsZWFzZSBzZW5kIG1lIHlvdXIgcXVlc3Rpb25zLCBjb21tZW50cyBvciBj b25jZXJucyBhYm91dCB0aGUgaXRlbXMgb24gdGhlIGFnZW5kYSBiZWZvcmUgV2VkbmVzZGF5IDIv MSBDT0IuIA0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQoNCkRhbg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpZXNnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppZXNnLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJRVNHIFNlY3JldGFyeQ0KU2VudDogRnJpZGF5 LCBKYW51YXJ5IDI3LCAyMDEyIDE6MTkgQU0NCi4uLg0KDQoyLiBQcm90b2NvbCBBY3Rpb25zDQoy LjEgV0cgU3VibWlzc2lvbnMNCjIuMS4xIE5ldyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi1zaWRy LXJwa2ktcnRyLTI0DQogICAgVGhlIFJQS0kvUm91dGVyIFByb3RvY29sIChQcm9wb3NlZCBTdGFu ZGFyZCkNCiAgICBOb3RlOiBEb2N1bWVudCBzaGVwaGVyZCBpcyBDaHJpcyBNb3Jyb3cgKG1vcnJv d2NAb3BzLW5ldG1hbi5uZXQpLg0KICAgIFRva2VuOiBTdGV3YXJ0IEJyeWFudA0KDQoyLjEuMiBS ZXR1cm5pbmcgSXRlbXMNCg0KICBvIGRyYWZ0LWlldGYtcm10LXNpbXBsZS1hdXRoLWZvci1hbGMt bm9ybS0wNg0KICAgIFNpbXBsZSBBdXRoZW50aWNhdGlvbiBTY2hlbWVzIGZvciB0aGUgQUxDIGFu ZCBOT1JNIFByb3RvY29scw0KICAgIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBCcmlh biBBZGFtc29uIChhZGFtc29uQGl0ZC5ucmwubmF2eS5taWwpIGlzIHRoZSBkb2N1bWVudA0KICAg IHNoZXBoZXJkLg0KICAgIFRva2VuOiBEYXZpZCBIYXJyaW5ndG9uDQoNCjIuMiBJbmRpdmlkdWFs IFN1Ym1pc3Npb25zDQoyLjIuMSBOZXcgSXRlbXMNCg0KICBvIGRyYWZ0LW5vdHRpbmdoYW0taHR0 cC1uZXctc3RhdHVzLTAzDQogICAgQWRkaXRpb25hbCBIVFRQIFN0YXR1cyBDb2RlcyAoUHJvcG9z ZWQgU3RhbmRhcmQpDQogICAgVG9rZW46IFBldGVyIFNhaW50LUFuZHJlDQoNCjIuMi4yIFJldHVy bmluZyBJdGVtcw0KDQogIE5PTkUNCg0KMy4gRG9jdW1lbnQgQWN0aW9ucw0KMy4xIFdHIFN1Ym1p c3Npb25zDQozLjEuMSBOZXcgSXRlbXMNCg0KICBvIGRyYWZ0LWlldGYtdjZvcHMtaXB2Ni1kaXNj YXJkLXByZWZpeC0wMg0KICAgIEEgRGlzY2FyZCBQcmVmaXggZm9yIElQdjYgKEluZm9ybWF0aW9u YWwpDQogICAgTm90ZTogSm9lbCBKYWVnZ2xpLCAoam9lbGphQGJvZ3VzLmNvbSkgdjZvcHMgY28t Y2hhaXIsIGlzIHRoZQ0KICAgIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBSb24gQm9u aWNhDQoNCiAgbyBkcmFmdC1pZXRmLTZtYW4tMzYyNy1oaXN0b3JpYy0wMQ0KICAgIFJGQzM2Mjcg dG8gSGlzdG9yaWMgc3RhdHVzIChJbmZvcm1hdGlvbmFsKQ0KICAgIE5vdGU6IEJyaWFuIEhhYmVy bWFuIChicmlhbkBpbm5vdmF0aW9uc2xhYi5uZXQpIGlzIHRoZSBkb2N1bWVudA0KICAgIHNoZXBo ZXJkLg0KICAgIFRva2VuOiBKYXJpIEFya2tvDQoNCiAgbyBkcmFmdC1pZXRmLXJhZGV4dC1yYWRz ZWMtMTANCiAgICBUTFMgZW5jcnlwdGlvbiBmb3IgUkFESVVTIChFeHBlcmltZW50YWwpDQogICAg Tm90ZTogSm91bmkgS29yaG9uZW4gKGpvdW5pLmtvcmhvbmVuQG5zbi5jb20pIGlzIHRoZSBEb2N1 bWVudA0KICAgIFNoZXBoZXJkLg0KICAgIFRva2VuOiBEYW4gUm9tYXNjYW51DQoNCjMuMS4yIFJl dHVybmluZyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi12Nm9wcy12Ni1hYWFhLXdoaXRlbGlzdGlu Zy1pbXBsaWNhdGlvbnMtMDgNCiAgICBDb25zaWRlcmF0aW9ucyBmb3IgVHJhbnNpdGlvbmluZyBD b250ZW50IHRvIElQdjYgKEluZm9ybWF0aW9uYWwpDQogICAgTm90ZTogSm9lbCBKYWVnZ2xpIChq b2VsamFAYm9ndXMuY29tKSBpcyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFJv biBCb25pY2ENCg0KMy4yIEluZGl2aWR1YWwgU3VibWlzc2lvbnMgVmlhIEFEDQozLjIuMSBOZXcg SXRlbXMNCg0KICBOT05FDQoNCjMuMi4yIFJldHVybmluZyBJdGVtcw0KDQogIE5PTkUNCg0KMy4z IElSVEYgYW5kIEluZGVwZW5kZW50IFN1Ym1pc3Npb24gU3RyZWFtIERvY3VtZW50cw0KMy4zLjEg TmV3IEl0ZW1zDQoNCiAgTk9ORQ0KDQozLjMuMiBSZXR1cm5pbmcgSXRlbXMNCg0KICBOT05FDQoN CjQuIFdvcmtpbmcgR3JvdXAgQWN0aW9ucw0KNC4xIFdHIENyZWF0aW9uDQo0LjEuMSBQcm9wb3Nl ZCBmb3IgSUVURiBSZXZpZXcNCg0KICBOT05FDQoNCjQuMS4yIFByb3Bvc2VkIGZvciBBcHByb3Zh bA0KDQogIE5PTkUNCg0KNC4yIFdHIFJlY2hhcnRlcmluZw0KNC4yLjEgVW5kZXIgRXZhbHVhdGlv biBmb3IgSUVURiBSZXZpZXcNCg0KICBvIE5FVENPTkYgRGF0YSBNb2RlbGluZyBMYW5ndWFnZSAo bmV0bW9kKQ0KICAgIFRva2VuOiBEYW4NCg0KICBvIEJhc2ljIExldmVsIG9mIEludGVyb3BlcmFi aWxpdHkgZm9yIFNJUCBTZXJ2aWNlcyAoYmxpc3MpDQogICAgVG9rZW46IFJvYmVydA0KDQogIG8g QmlEaXJlY3Rpb25hbCBvciBTZXJ2ZXItSW5pdGlhdGVkIEhUVFAgKGh5YmkpDQogICAgVG9rZW46 IFBldGVyDQoNCjQuMi4yIFByb3Bvc2VkIGZvciBBcHByb3ZhbA0KDQogIG8gTG9jYXRvci9JRCBT ZXBhcmF0aW9uIFByb3RvY29sIChsaXNwKQ0KICAgIFRva2VuOiBKYXJpDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQoNCg== From aland@deployingradius.com Sat Jan 28 16:22:31 2012 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E086F21F84AA for ; Sat, 28 Jan 2012 16:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.007 X-Spam-Level: X-Spam-Status: No, score=-101.007 tagged_above=-999 required=5 tests=[AWL=1.592, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAR+o83mMOUW for ; Sat, 28 Jan 2012 16:22:30 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8BB21F84A6 for ; Sat, 28 Jan 2012 16:22:30 -0800 (PST) Received: by liberty.deployingradius.com (Postfix, from userid 1000) id 1B38B12344FB; Sun, 29 Jan 2012 01:22:02 +0100 (CET) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 1.1) Message-Id: <20120129002202.1B38B12344FB@liberty.deployingradius.com> Date: Sun, 29 Jan 2012 01:22:02 +0100 (CET) Subject: [AAA-DOCTORS] RADIUS Documents in Last Call for Sun Jan 29 01:22:01 CET 2012 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 00:22:31 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items; in IETF Last Call, and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-netext-radius-pmip6-06.txt http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6/