From owner-radiusext@ops.ietf.org Mon Jun 2 19:29:00 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D743A682B for ; Mon, 2 Jun 2008 19:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.339 X-Spam-Level: X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 i3LxDgB3WAZY for ; Mon, 2 Jun 2008 19:28:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 96C7A3A67E1 for ; Mon, 2 Jun 2008 19:28:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3MBP-0006QU-Uk for radiusext-data@psg.com; Tue, 03 Jun 2008 02:23:31 +0000 Received: from [65.55.116.17] (helo=blu0-omc1-s6.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3MAx-0006OR-Ih for radiusext@ops.ietf.org; Tue, 03 Jun 2008 02:23:18 +0000 Received: from BLU137-W37 ([65.55.116.8]) by blu0-omc1-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 19:22:45 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_b917c35e-6cb0-4b74-9ff7-0566e3b32d75_" X-Originating-IP: [131.107.0.73] From: Bernard Aboba To: Subject: Consensus Call Summary: Changes to Extended Attributes Document Date: Mon, 2 Jun 2008 19:22:45 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2008 02:22:45.0604 (UTC) FILETIME=[B593B240:01C8C520] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-List-ID: radiusext@psg.com --_b917c35e-6cb0-4b74-9ff7-0566e3b32d75_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wednesday, May 7, a Consensus call was issued to the WG mailing list, in= order to confirm acceptance of the consensus call done at IETF 71, with re= spect to the changes made in the Extended Attributes Document version -01.= =20 =20 That Consensus call has now concluded. Based on the minimal mailing list r= esponse (1 response, in favor of the IETF 71 consensus), the consensus take= n at IETF 71 is judged to be AFFIRMED. =20 =20 That is:=20 =20 1. The change to the Ext-Type field (2 octets rather than 1) is APPROVED. 2= . The change to the RADIUS Extended Attribute format in (applied to existin= g standard RADIUS attributes, not just extended ones) is REJECTED. =20 Instructions to the Editor: Please submit a new document reflecting the RA= DEXT WG Consensus ASAP.=20 From: bernard_aboba@hotmail.comTo: radiusext@ops.ietf.orgSubject: Consensus= call: Changes to Extended Attributes documentDate: Wed, 7 May 2008 18:48:0= 5 -0700At IETF 71, a consensus call was taken regarding changes made in the= -01 version of theExtended Attributes document, as compared with -00. Th= e changes made were as follows:1. Ext-Type field was changed to 2 octets ra= ther than 1. 2. The RADIUS Extended Attribute format in -01 applied to exis= ting standard RADIUS attributes, not just extended ones. In the RADEXT WG = meeting at IETF 71, the consensus call was as follows: Change #1 was ADOPTE= D by a margin of 7-1. Change #2 was REJECTED by a margin of 6-2. We are no= w issuing a Consensus Call on the RADEXT WG mailing list in order to verify= the consensus of the room at IETF 71. This Consensus Call will last until= May 21, 2008. Please send email to the list, explicitly stating your pos= ition on changes #1 and #2, indicating whether you desire to ADOPT or REJEC= T each change. For reference, -00 is available here:http://www.waterspring= s.org/pub/id/draft-ietf-radext-extended-attributes-00.txt -01 is available = here:http://www.waterspring.org/pub/id/draft-ietf-radext-extended-attribute= s-01.txt ______________________ EMAILING FOR THE GREATER GOOD= --_b917c35e-6cb0-4b74-9ff7-0566e3b32d75_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wednesday, May 7, a Consensus call was issued to the WG mailing list, in= order to confirm acceptance of the consensus call done at IETF 71, with re= spect to the changes made in the Extended Attributes Document version = -01.
 
That Consensus call has now concluded.  Based on the minimal mailing l= ist response (1 response, in favor of the IETF 71 consensus), the consensus= taken at IETF 71 is judged to be AFFIRMED. 
 
That is:
 
1. The change to the Ext-Type field (2 octets rather than 1) is APPROVED.&n= bsp;
2. The change to the RADIUS Extended Attribute format in (applied t= o existing standard RADIUS attributes,  not just extended ones) is REJ= ECTED.
 
Instructions to the Editor:  Please submit a new document reflecting t= he RADEXT WG Consensus ASAP.

From: bernard_aboba@hotmail.com
To: radiusext@ops.ietf.org
Subject: C= onsensus call: Changes to Extended Attributes document
Date: Wed, 7 May = 2008 18:48:05 -0700

At IETF 71, a consensus call was taken regarding= changes made in the -01 version of the
Extended Attributes document, as= compared with -00. 
 
The changes made were as follows:1. Ext-Type field was changed to 2 octets rather than 1.
2. The RADIU= S Extended Attribute format in -01 applied to existing standard RADIUS attr= ibutes,  not just extended ones.
 
In the RADEXT WG meeting= at IETF 71, the consensus call was as follows:
 
Change #1 was = ADOPTED by a margin of 7-1.
Change #2 was REJECTED by a margin of 6-2. =
 
We are now issuing a Consensus Call on the RADEXT WG mailing = list in order to verify the consensus of the room at IETF 71.
 This Consensus Call will last until  May 21, 2008.  Please send = email to the list, explicitly stating your position on changes #1 and #2, i= ndicating whether you desire to ADOPT or REJECT each change.
 
= For reference, -00 is available here:
http://www.watersprings.org/pub/id/d= raft-ietf-radext-extended-attributes-00.txt
 
-01= is available here:
http://www.waterspring.org/pub/id/draft-ietf-radext-ext= ended-attributes-01.txt

 
 


_= _____________________
3D"i'm" EMAILING FOR TH= E GREATER GOOD
= --_b917c35e-6cb0-4b74-9ff7-0566e3b32d75_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 2 19:31:34 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC64D3A682B for ; Mon, 2 Jun 2008 19:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 ZgtdEhllIPrr for ; Mon, 2 Jun 2008 19:31:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A0BE3A6925 for ; Mon, 2 Jun 2008 19:30:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3MEu-0006mW-M9 for radiusext-data@psg.com; Tue, 03 Jun 2008 02:27:08 +0000 Received: from [65.55.116.27] (helo=blu0-omc1-s16.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3MEV-0006k0-EP for radiusext@ops.ietf.org; Tue, 03 Jun 2008 02:26:54 +0000 Received: from BLU137-W10 ([65.55.116.8]) by blu0-omc1-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 19:26:38 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_0fdf7771-f4b0-408d-a1ef-27b1c5c3f1ac_" X-Originating-IP: [131.107.0.73] From: Bernard Aboba To: Subject: Approval of revised RADEXT WG Charter Date: Mon, 2 Jun 2008 19:26:38 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2008 02:26:38.0851 (UTC) FILETIME=[409A5D30:01C8C521] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-List-ID: radiusext@psg.com --_0fdf7771-f4b0-408d-a1ef-27b1c5c3f1ac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The updated RADEXT WG charter has been approved by the IESG, and is now pos= ted on the WG web page: http://www.ietf.org/html.charters/radext-charter.html =20 = --_0fdf7771-f4b0-408d-a1ef-27b1c5c3f1ac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The updated RADEXT WG charter has been approved by the IESG, and is now pos= ted on the WG web page:
http://ww= w.ietf.org/html.charters/radext-charter.html
 
 
= --_0fdf7771-f4b0-408d-a1ef-27b1c5c3f1ac_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 2 19:41:42 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FD0C3A6B3E for ; Mon, 2 Jun 2008 19:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 emK9o0P8J+PF for ; Mon, 2 Jun 2008 19:41:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AECB43A6860 for ; Mon, 2 Jun 2008 19:40:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3MN2-0007sG-Fs for radiusext-data@psg.com; Tue, 03 Jun 2008 02:35:32 +0000 Received: from [65.55.116.19] (helo=blu0-omc1-s8.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3MMa-0007p9-Nu for radiusext@ops.ietf.org; Tue, 03 Jun 2008 02:35:18 +0000 Received: from BLU137-W49 ([65.55.116.7]) by blu0-omc1-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 19:35:04 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f17b4ab8-15d7-41ad-85b7-a67d836a4a7b_" X-Originating-IP: [131.107.0.73] From: Bernard Aboba To: Subject: Request for Review: Status Server Document Date: Mon, 2 Jun 2008 19:35:04 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2008 02:35:04.0442 (UTC) FILETIME=[6DF56DA0:01C8C522] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-List-ID: radiusext@psg.com --_f17b4ab8-15d7-41ad-85b7-a67d836a4a7b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a request for review of the Status Server document for the purposes= of considering it for adoption as a RADEXT WG work item. The document is = available for inspection here:http://www.ietf.org/internet-drafts/draft-dek= ok-radius-status-server-02.txt Please respond to the mailing list, indicati= ng whether your are IN FAVOR or AGAINST adoption of the document as a RADEX= T WG work item. If you have comments on the document, please post these to= the mailing list as well, in the format described in the RADEXT WG Issues = page: http://www.drizzle.com/~aboba/RADEXT/ This request for review will co= nclude on June 16, 2008. = --_f17b4ab8-15d7-41ad-85b7-a67d836a4a7b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is a request for review of the Status Server document for = the purposes of considering it for adoption as a RADEXT WG work item.
&= nbsp;
The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-dekok-radius-status-= server-02.txt
 
Please respond to the mailing list, indicati= ng whether your are IN FAVOR or AGAINST adoption of the document as a RADEX= T WG work item.  If you have comments on the document, please post the= se to the mailing list as well, in the format described in the RADEXT WG Is= sues page:
http://www.drizzle.com/~aboba/RADEXT/
 
This request f= or review will conclude on June 16, 2008.
= --_f17b4ab8-15d7-41ad-85b7-a67d836a4a7b_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 2 19:41:43 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE9223A687E for ; Mon, 2 Jun 2008 19:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 8gt6UBPZXWtO for ; Mon, 2 Jun 2008 19:41:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 188833A6905 for ; Mon, 2 Jun 2008 19:40:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3MNg-0007xq-Kb for radiusext-data@psg.com; Tue, 03 Jun 2008 02:36:12 +0000 Received: from [65.55.116.23] (helo=blu0-omc1-s12.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3MNE-0007ub-SD for radiusext@ops.ietf.org; Tue, 03 Jun 2008 02:35:58 +0000 Received: from BLU137-W41 ([65.55.116.9]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 19:35:44 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_cadb739c-bcc2-49b8-b525-dea31c397de5_" X-Originating-IP: [131.107.0.73] From: Bernard Aboba To: Subject: Request for Review: RADSEC Specification Date: Mon, 2 Jun 2008 19:35:44 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2008 02:35:44.0458 (UTC) FILETIME=[85CF62A0:01C8C522] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-List-ID: radiusext@psg.com --_cadb739c-bcc2-49b8-b525-dea31c397de5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a request for review of the RADSEC specification for the purposes o= f considering it for adoption as a RADEXT WG work item. The document is av= ailable for inspection here:http://www.ietf.org/internet-drafts/draft-winte= r-radsec-01.txt Please respond to the mailing list, indicating whether your= are IN FAVOR or AGAINST adoption of the document as a RADEXT WG work item.= If you have comments on the document, please post these to the mailing li= st as well, in the format described in the RADEXT WG Issues page: http://ww= w.drizzle.com/~aboba/RADEXT/ This request for review will conclude on June = 16, 2008. = --_cadb739c-bcc2-49b8-b525-dea31c397de5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is a request for review of the RADSEC specification f= or the purposes of considering it for adoption as a RADEXT WG work item.  
The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-winter= -radsec-01.txt
 
Ple= ase respond to the mailing list, indicating whether your are IN FAVOR or AG= AINST adoption of the document as a RADEXT WG work item.  If you have = comments on the document, please post these to the mailing list as well, in= the format described in the RADEXT WG Issues page:
http://www.drizzle.com/~abob= a/RADEXT/
 
This request for review will conclude on June 16= , 2008.
= --_cadb739c-bcc2-49b8-b525-dea31c397de5_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 2 20:59:59 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3566B3A69EB for ; Mon, 2 Jun 2008 20:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] 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 1X8Jg3xz5mm2 for ; Mon, 2 Jun 2008 20:59:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA6563A68F9 for ; Mon, 2 Jun 2008 20:59:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3NcJ-000H5E-5A for radiusext-data@psg.com; Tue, 03 Jun 2008 03:55:23 +0000 Received: from [218.214.125.86] (helo=zulu.open.com.au) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3Nbp-000H20-6G for radiusext@ops.ietf.org; Tue, 03 Jun 2008 03:55:09 +0000 Received: from localhost (localhost [IPv6:::1]) by zulu.open.com.au (Postfix) with ESMTP id 6C70D9F957; Tue, 3 Jun 2008 13:54:51 +1000 (EST) From: Mike McCauley To: Bernard Aboba Subject: Re: Request for Review: RADSEC Specification Date: Tue, 3 Jun 2008 13:54:50 +1000 User-Agent: KMail/1.8.2 Cc: radiusext@ops.ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806031354.51138.mikem@open.com.au> Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-List-ID: radiusext@psg.com IN FAVOR On Tuesday 03 June 2008 12:35, Bernard Aboba wrote: > This is a request for review of the RADSEC specification for the purposes > of considering it for adoption as a RADEXT WG work item. The document is > available for inspection > here:http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt Please > respond to the mailing list, indicating whether your are IN FAVOR or > AGAINST adoption of the document as a RADEXT WG work item. If you have > comments on the document, please post these to the mailing list as well, in > the format described in the RADEXT WG Issues page: > http://www.drizzle.com/~aboba/RADEXT/ This request for review will conclude > on June 16, 2008. -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX etc on Unix, Windows, MacOS, NetWare etc. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 2 21:58:18 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A758D3A6834 for ; Mon, 2 Jun 2008 21:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 1DUXJQgHLZE4 for ; Mon, 2 Jun 2008 21:58:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6B9733A6B55 for ; Mon, 2 Jun 2008 21:56:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3OUY-000NSC-NW for radiusext-data@psg.com; Tue, 03 Jun 2008 04:51:26 +0000 Received: from [72.14.220.153] (helo=fg-out-1718.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3OU3-000NOs-Av for radiusext@ops.ietf.org; Tue, 03 Jun 2008 04:51:12 +0000 Received: by fg-out-1718.google.com with SMTP id l27so1037294fgb.11 for ; Mon, 02 Jun 2008 21:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wOuuJiKMWrLuug6CHHHFjxumcfoqKA0U2rYXUazNMZU=; b=mPQx4Y7VGFQy9z1nrHWnbFTvIvZA1ijjBQLr99xU/Tugv9mnE5IDfUGbopy3W0LT2uMm4nXvynCbTCm4rEvkvCE/zz+jj3Pwjxvko/5pc+MbOiD7r9W+PSz3Ouw8BomEWnoHz3nF5ss9/cMO+cNpBQDVSZ93oCOuElV8g0EbGxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=a9DJmnQtX2pGU2JPvmL1vDu+CELeeecNwa/Y2RaC4zgqasJjSzjLigaqPOulXxTqL9rCQ02JwB3Yx+cJEoywCgbGAoSzCrFBJRcVU0Mra7QHCyshQ7sqfBpho301vEBQzjNP8P20XUw8Du1wpM8WP5cJQpFuGg3wL6bXCjQqDRQ= Received: by 10.78.199.8 with SMTP id w8mr385883huf.106.1212468652022; Mon, 02 Jun 2008 21:50:52 -0700 (PDT) Received: by 10.78.134.3 with HTTP; Mon, 2 Jun 2008 21:50:51 -0700 (PDT) Message-ID: Date: Tue, 3 Jun 2008 01:50:51 -0300 From: "Claudio Lapidus" To: "Bernard Aboba" Subject: Re: Request for Review: RADSEC Specification Cc: radiusext@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-List-ID: radiusext@psg.com In favor. -- On Mon, Jun 2, 2008 at 11:35 PM, Bernard Aboba wrote: > > This is a request for review of the RADSEC specification for the purposes of considering it for adoption as a RADEXT WG work item. > > The document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt > > Please respond to the mailing list, indicating whether your are IN FAVOR or AGAINST adoption of the document as a RADEXT WG work item. If you have comments on the document, please post these to the mailing list as well, in the format described in the RADEXT WG Issues page: > http://www.drizzle.com/~aboba/RADEXT/ > > This request for review will conclude on June 16, 2008. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 2 23:38:22 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3724C3A6951 for ; Mon, 2 Jun 2008 23:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 Q+cD7nTS6Xjh for ; Mon, 2 Jun 2008 23:38:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 19A933A6825 for ; Mon, 2 Jun 2008 23:38:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3Q3c-0007fy-Ee for radiusext-data@psg.com; Tue, 03 Jun 2008 06:31:44 +0000 Received: from [158.64.1.34] (helo=smtp.restena.lu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3Q3B-0007ds-1Y for radiusext@ops.ietf.org; Tue, 03 Jun 2008 06:31:30 +0000 Received: from smtp.restena.lu (localhost [127.0.0.1]) by smtp.restena.lu (Postfix) with ESMTP id 989CF30276E5; Tue, 3 Jun 2008 08:31:15 +0200 (CEST) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by smtp.restena.lu (Postfix) with ESMTP id 8984530276DA; Tue, 3 Jun 2008 08:31:15 +0200 (CEST) Message-ID: <4844E533.30808@restena.lu> Date: Tue, 03 Jun 2008 08:31:15 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Request for Review: RADSEC Specification References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-List-ID: radiusext@psg.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, in favor of taking it as a start. Parts of it will need to be taken out to form the basis of the "Reliable Transport Profile for RADIUS". | This is a request for review of the RADSEC specification for the | purposes of considering it for adoption as a RADEXT WG work item. | | The document is available for inspection here: | http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt | | | Please respond to the mailing list, indicating whether your are IN | FAVOR or AGAINST adoption of the document as a RADEXT WG work item. | If you have comments on the document, please post these to the | mailing list as well, in the format described in the RADEXT WG | Issues page: | http://www.drizzle.com/~aboba/RADEXT/ | | This request for review will conclude on June 16, 2008. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIROUz+jm90f8eFWYRAmvgAJ0bYOrW0t2gdn3W0bL7HGi9mIof0QCeI5Vi KRmrIapopqbXZ53mP3On20M= =rGqv -----END PGP SIGNATURE----- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jun 3 02:38:02 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97583A6A4C for ; Tue, 3 Jun 2008 02:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 etbwmKJz55q5 for ; Tue, 3 Jun 2008 02:38:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E6ABB3A6C0E for ; Tue, 3 Jun 2008 02:36:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3Sor-0001DH-Kb for radiusext-data@psg.com; Tue, 03 Jun 2008 09:28:41 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3Sog-0001C3-W2 for radiusext@ops.ietf.org; Tue, 03 Jun 2008 09:28:36 +0000 Received: from [10.38.4.65] (oag1.duwifi.ae [91.73.204.10]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 459631234279 for ; Tue, 3 Jun 2008 11:28:28 +0200 (CEST) Message-ID: <48450DA7.4070608@deployingradius.com> Date: Tue, 03 Jun 2008 11:23:51 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: Request for Review: RADSEC Specification References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > This is a request for review of the RADSEC specification for the > purposes of considering it for adoption as a RADEXT WG work item. I am in favor of adopting it as a WG work item. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jun 3 02:46:48 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97BE93A6834 for ; Tue, 3 Jun 2008 02:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 1EqqS55BRwyv for ; Tue, 3 Jun 2008 02:46:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9970C3A6882 for ; Tue, 3 Jun 2008 02:46:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3T0H-0002ij-SH for radiusext-data@psg.com; Tue, 03 Jun 2008 09:40:29 +0000 Received: from [76.96.30.40] (helo=QMTA04.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3Szs-0002fl-SH for radiusext@ops.ietf.org; Tue, 03 Jun 2008 09:40:20 +0000 Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id ZMam1Z0021HpZEsA400J00; Tue, 03 Jun 2008 09:40:04 +0000 Received: from gwzPC ([124.120.219.75]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id ZMe31Z0031eC0gU8a00000; Tue, 03 Jun 2008 09:40:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=3YJ9PegE8-kA:10 a=48vgC7mUAAAA:8 a=Cv6e0pkHAAAA:8 a=H4QH8w9ZZLF3GzukuZEA:9 a=hW-LSSfG6pJuCo8dSMMA:7 a=trGh6ifhHc_lJ8YaGUHE2q_k5vEA:4 a=EfJqPEOeqlMA:10 a=zoKOyUDlhksA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=obi0SIxLJRmfEr3qXhUA:9 a=ykprvmH_5eHMBoiERb8A:7 a=zTWlTs0tC6xojvf-XeIbxIeKVPsA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Bernard Aboba'" , References: In-Reply-To: Subject: RE: Request for Review: RADSEC Specification Date: Tue, 3 Jun 2008 16:37:53 +0700 Message-ID: <001e01c8c55d$870fd010$952f7030$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C8C598.336EA810" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcjFIxXHK04VnmjJTEuODWVFnfs6+AAOZVqg Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. ------=_NextPart_000_001F_01C8C598.336EA810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes: This is a request for review of the RADSEC specification for the purposes of considering it for adoption as a RADEXT WG work item. I'm a little confused: since the recently approved charter lists RadSec as a work item (even calling it out by name: '.specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS'), I'm not sure what the point of this is or what the alternatives might be. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt Please respond to the mailing list, indicating whether your are IN FAVOR or AGAINST adoption of the document as a RADEXT WG work item. If you have comments on the document, please post these to the mailing list as well, in the format described in the RADEXT WG Issues page: http://www.drizzle.com/~aboba/RADEXT/ This request for review will conclude on June 16, 2008. ------=_NextPart_000_001F_01C8C598.336EA810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bernard Aboba  [mailto:bernard_aboba@hotmail.com] = writes:

 <= /o:p>

This is a request for review of the RADSEC specification for the = purposes of considering it for adoption as a RADEXT WG work item.

 

I'm a little confused: since the recently approved = charter lists RadSec as a work item (even calling it out by name: = '…specifications for
Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS'), I'm not = sure what the point of this is or what the alternatives might be… =


 
The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-winter-radsec= -01.txt
 
Please respond to the mailing list, indicating whether your are IN FAVOR = or AGAINST adoption of the document as a RADEXT WG work item.  If you = have comments on the document, please post these to the mailing list as well, = in the format described in the RADEXT WG Issues page:
http://www.drizzle.com/~aboba/RADEXT/
 
This request for review will conclude on June 16, 2008. =

------=_NextPart_000_001F_01C8C598.336EA810-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jun 3 04:14:09 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1473A68D7 for ; Tue, 3 Jun 2008 04:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 qo6akm1ykKRS for ; Tue, 3 Jun 2008 04:14:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D241B3A67DB for ; Tue, 3 Jun 2008 04:14:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3UNg-000Des-IY for radiusext-data@psg.com; Tue, 03 Jun 2008 11:08:44 +0000 Received: from [76.96.30.40] (helo=QMTA04.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K3UNV-000DdU-V0 for radiusext@ops.ietf.org; Tue, 03 Jun 2008 11:08:39 +0000 Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id ZNri1Z00B0EPchoA401K00; Tue, 03 Jun 2008 11:08:33 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id ZP8X1Z00E24Kx1C8M00000; Tue, 03 Jun 2008 11:08:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=3YJ9PegE8-kA:10 a=MAy5h4bbvMI1oqD9Za8A:9 a=6xNCE_pxSrD6dl5RygJJAdvr5zsA:4 a=tqucuuI3bnEA:10 From: "David B. Nelson" To: References: <001e01c8c55d$870fd010$952f7030$@net> Subject: RE: Request for Review: RADSEC Specification Date: Tue, 3 Jun 2008 07:08:35 -0400 Message-ID: <014e01c8c56a$2bc93130$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <001e01c8c55d$870fd010$952f7030$@net> Thread-Index: AcjFIxXHK04VnmjJTEuODWVFnfs6+AAOZVqgAAMw6SA= Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn writes... > I'm a little confused: since the recently approved charter lists > RadSec as a work item (even calling it out by name: '.specifications > for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS'), > I'm not sure what the point of this is or what the alternatives > might be. The question is whether the subject individual draft is sufficiently complete and well written to become a WG work item. As you may recall, we expect WG -00 drafts to be reasonably mature. That alternative is that it could stay as an individual draft for more polishing, or some alternative draft fulfilling the same WG charter milestone could be presented for consideration. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Jun 5 01:15:49 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C10F3A6BE4 for ; Thu, 5 Jun 2008 01:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 sICSRhxqIwf8 for ; Thu, 5 Jun 2008 01:15:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 132243A68E0 for ; Thu, 5 Jun 2008 01:15:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4AXx-000F8Z-Cv for radiusext-data@psg.com; Thu, 05 Jun 2008 08:10:09 +0000 Received: from [76.96.62.80] (helo=QMTA08.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4AXt-000F5S-QN for radiusext@ops.ietf.org; Thu, 05 Jun 2008 08:10:07 +0000 Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA08.westchester.pa.mail.comcast.net with comcast id a89l1Z0010EZKEL5800100; Thu, 05 Jun 2008 08:10:05 +0000 Received: from gwzPC ([124.120.222.145]) by OMTA01.westchester.pa.mail.comcast.net with comcast id a89d1Z00338pyvw3M00000; Thu, 05 Jun 2008 08:10:03 +0000 X-Authority-Analysis: v=1.0 c=1 a=3YJ9PegE8-kA:10 a=Gvuo4qYs_D86cmu-cE8A:9 a=94_t6zik1LptVXCF4pVjYXK3F1YA:4 a=si9q_4b84H0A:10 a=oltf0pfCdT4A:10 From: "Glen Zorn" To: "'David B. Nelson'" , References: <001e01c8c55d$870fd010$952f7030$@net> <014e01c8c56a$2bc93130$6401a8c0@NEWTON603> In-Reply-To: <014e01c8c56a$2bc93130$6401a8c0@NEWTON603> Subject: RE: Request for Review: RADSEC Specification Date: Thu, 5 Jun 2008 15:09:17 +0700 Message-ID: <009801c8c6e3$7b2187d0$71649770$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjFIxXHK04VnmjJTEuODWVFnfs6+AAOZVqgAAMw6SAAXjdw4A== Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: David B. Nelson [mailto://d.b.nelson@comcast.net] writes: > Glen Zorn writes... > > > I'm a little confused: since the recently approved charter lists > > RadSec as a work item (even calling it out by name: '.specifications > > for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS'), > > I'm not sure what the point of this is or what the alternatives > > might be. > > The question is whether the subject individual draft is sufficiently > complete and well written to become a WG work item. As you may recall, > we > expect WG -00 drafts to be reasonably mature. Hmm, yes, a policy that has worked wonders in speeding up progress... > > That alternative is that it could stay as an individual draft for more > polishing, or some alternative draft fulfilling the same WG charter > milestone could be presented for consideration. OK, so I thought that the lengthy discussion of whether or not to add RadSec as a work item was about the protocol as described in the existing draft; we even talked about some of the changes necessary to this document. Am I to understand that those debates were actually about adopting some theoretical concept of RADIUSoTLS/TCP as a work item? ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Jun 5 05:29:41 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F8EB3A6BD9 for ; Thu, 5 Jun 2008 05:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 eJoTicvoNxGp for ; Thu, 5 Jun 2008 05:29:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F8D028C1D0 for ; Thu, 5 Jun 2008 05:27:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4EMF-000O0I-Em for radiusext-data@psg.com; Thu, 05 Jun 2008 12:14:19 +0000 Received: from [76.96.30.17] (helo=QMTA10.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K4EMC-000Nzk-2r for radiusext@ops.ietf.org; Thu, 05 Jun 2008 12:14:17 +0000 Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id aAXU1Z00D0b6N64AA0GN00; Thu, 05 Jun 2008 12:14:14 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id aCEC1Z00624Kx1C8P00000; Thu, 05 Jun 2008 12:14:14 +0000 X-Authority-Analysis: v=1.0 c=1 a=3YJ9PegE8-kA:10 a=zv_bpsU2jTwGduUv-OkA:9 a=XtTCBkKOIvVJf4N12gw-Y6O6I54A:4 a=tqucuuI3bnEA:10 From: "David B. Nelson" To: References: <001e01c8c55d$870fd010$952f7030$@net> <014e01c8c56a$2bc93130$6401a8c0@NEWTON603> <009801c8c6e3$7b2187d0$71649770$@net> Subject: RE: Request for Review: RADSEC Specification Date: Thu, 5 Jun 2008 08:14:17 -0400 Message-ID: <042501c8c705$aed779a0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <009801c8c6e3$7b2187d0$71649770$@net> Thread-Index: AcjFIxXHK04VnmjJTEuODWVFnfs6+AAOZVqgAAMw6SAAXjdw4AAIfU1w Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn writes... > Hmm, yes, a policy that has worked wonders in speeding up progress... RADEXT has been slow in making progress at times, but I think this particular policy has no direct bearing on that. It has neither speeded up nor slowed down the rate of progress. The root cause of the "rate of progress" issue lies elsewhere. > OK, so I thought that the lengthy discussion of whether or not to add > RadSec as a work item was about the protocol as described in the existing > draft; we even talked about some of the changes necessary to this > document. Am I to understand that those debates were actually about > adopting some theoretical concept of RADIUSoTLS/TCP as a work item? There is a procedural separation of concerns between adding a work item to a WG charter and adopting a specific individual draft as the WG's chosen vehicle to complete that work item. As a WG chair yourself, I suspect that you understand that distinction. I'm not saying that I expect a competing document to be offered up. I'm simply answering your process question. There are separate process steps; we are following them. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 9 22:35:11 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ADB53A67A2 for ; Mon, 9 Jun 2008 22:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 BinR+Vs+xSPK for ; Mon, 9 Jun 2008 22:35:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EAA573A676A for ; Mon, 9 Jun 2008 22:35:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5wQB-0001Wr-OH for radiusext-data@psg.com; Tue, 10 Jun 2008 05:29:27 +0000 Received: from [158.64.1.34] (helo=smtp.restena.lu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K5wQ8-0001W8-58 for radiusext@ops.ietf.org; Tue, 10 Jun 2008 05:29:26 +0000 Received: from smtp.restena.lu (localhost [127.0.0.1]) by smtp.restena.lu (Postfix) with ESMTP id 3471730284BA; Tue, 10 Jun 2008 07:29:22 +0200 (CEST) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by smtp.restena.lu (Postfix) with ESMTP id 24CFF3027879; Tue, 10 Jun 2008 07:29:22 +0200 (CEST) Message-ID: <484E1130.8050105@restena.lu> Date: Tue, 10 Jun 2008 07:29:20 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, | This is a request for review of the Status Server document for the | purposes of considering it for adoption as a RADEXT WG work item. I'm in favour of adoption. Stefan Winter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIThEv+jm90f8eFWYRAorWAJ48jk1VlAvwqMuFeehiij2xAdg0EQCfeezv vIUvmGv/tsmwEI4102vml8Q= =viA9 -----END PGP SIGNATURE----- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jun 10 10:16:35 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5041D3A691B for ; Tue, 10 Jun 2008 10:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=-1.902, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 RGHBAF2daoHD for ; Tue, 10 Jun 2008 10:16:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 39A833A67E2 for ; Tue, 10 Jun 2008 10:16:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K67Ij-0003AZ-BQ for radiusext-data@psg.com; Tue, 10 Jun 2008 17:06:29 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K67Ib-00038Y-Eo for radiusext@ops.ietf.org; Tue, 10 Jun 2008 17:06:23 +0000 Received: (qmail 19784 invoked from network); 10 Jun 2008 13:06:17 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 10 Jun 2008 13:06:17 -0400 From: "David B. Nelson" To: Subject: RADEXT Issue 253 (NAS management Authorization) Date: Tue, 10 Jun 2008 13:06:13 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjLHElvSttDqdaBT++kmr6A4WroWA== Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > throughout: > "Note that" is usually unnecessary. Don't we want readers to note > everything in the document, or we wouldn't have said it? Accepted, except for the occurrence within the standard boilerplate text. :-) > section 14: > this mentions accounting, but accounting is explicitly out of scope > for this document. I propose to reject this comment. Nothing in this draft says that accounting is out of scope. It is common practice to allow service provisioning attributes to appear in Accounting-Request messages for the purpose of session logging and auditing. The commenter may be thinking of the RADIUS Usage for SNMP Transport Models document, in which accounting is out of scope. All other Issue 253 comments are accepted, and will be reflected in the -03 version. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jun 10 10:16:35 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648AA3A67E2 for ; Tue, 10 Jun 2008 10:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czyXu5IWvZD2 for ; Tue, 10 Jun 2008 10:16:34 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 717903A67F3 for ; Tue, 10 Jun 2008 10:16:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K67KE-0003Kw-S2 for radiusext-data@psg.com; Tue, 10 Jun 2008 17:08:02 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K67KB-0003KL-43 for radiusext@ops.ietf.org; Tue, 10 Jun 2008 17:08:00 +0000 Received: (qmail 19811 invoked from network); 10 Jun 2008 13:07:58 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 10 Jun 2008 13:07:58 -0400 From: "David B. Nelson" To: Subject: RADEXT Issue 254 (NAS Management Authorization) Date: Tue, 10 Jun 2008 13:07:54 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjLHIWZ1UmIv2vIT1GAl0dTSfdXqg== Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: All Issue 254 comments are accepted and will appear in the -03 version. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jun 10 10:59:48 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446863A6946 for ; Tue, 10 Jun 2008 10:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 XIKcNtkLFhzu for ; Tue, 10 Jun 2008 10:59:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D4A93A68E1 for ; Tue, 10 Jun 2008 10:59:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K683A-0008gh-6o for radiusext-data@psg.com; Tue, 10 Jun 2008 17:54:28 +0000 Received: from [209.85.146.181] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6831-0008fm-OW for radiusext@ops.ietf.org; Tue, 10 Jun 2008 17:54:25 +0000 Received: by wa-out-1112.google.com with SMTP id j37so2227382waf.23 for ; Tue, 10 Jun 2008 10:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=T8NGMvD3jKyZWQnw4aCOD3Pbqag3gUZpyQ6VraBAN14=; b=QdRRmtjqnPSCxeRXtFpc22rOVQiSDe3PQRykZsLxMOAS1i8a42Nem2KbX0+SBknEQ8 RnkpJja7E1N54f1sdk+F30F10KO/XiFcDYzqvYt6x4ysUnjqQt7V8oaiILdrmgFmjVXi 9UuUcqUyW0qw0dkRwJ4Ws662ZV/SajLBXicxs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=sL39U70UV/u+0gzdnSHcwfV+9SO3bnjBbNBiU5shA/UAqWrigQ13nHqyNL9lhQi1PT ulYWdMHFB+d+Rrdce2Jm1ZaCplQIGhvYLd/3VAhYlH4u9A7JzyIuK5KqY5XABg3QCsC/ pO47JsrpKnGhrU8p99MVW7oOkcZYk2h+C8NQs= Received: by 10.115.46.9 with SMTP id y9mr5364143waj.23.1213120457331; Tue, 10 Jun 2008 10:54:17 -0700 (PDT) Received: by 10.114.79.8 with HTTP; Tue, 10 Jun 2008 10:54:17 -0700 (PDT) Message-ID: Date: Tue, 10 Jun 2008 13:54:17 -0400 From: "Greg Weber" To: radiusext@ops.ietf.org Subject: [Issue 255]: NAS mgmt author MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: I have a comment on this subissue from #255 on RADIUS author. This is from the issue list: "section 8.4 I don't understand why we need a special Management-Privilege-Level attribute. This should be able to specified as a named policy in the Management-Policy-ID, such as "Level 1" and "Level 2", or even "1" and "2" and "3". Implementations simply need to map between the policy name and their privilege-level policy implementation. Different implementations might handle priivilege levels differently - some might use integers internally, others might use a different range of values (0-15 vs 1-16). Using Management-Policy-ID makes this simply a mapping exercise. This is a great opportunity to suggest standard names for privilege levels, and then vendors can map those standard names to the internal routines. If vendors provide an API, operators could name the policies as they wanted and map them to the vendors' APIs for invoking different privilege levels." -- Actually, I think this is likely to lead to problems. Conceptually, i agree, but this privilege level concept is quite entrenched. And having a language- specific 'textization' of this is likely to lead to more incompatibility going fwd. I also don't think RADEXT is the correct place to "suggest standard names for privilege levels". -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jun 10 11:20:37 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18883A696B for ; Tue, 10 Jun 2008 11:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=-1.268, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 qNb-IDDEgxnD for ; Tue, 10 Jun 2008 11:20:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A4863A692E for ; Tue, 10 Jun 2008 11:20:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K68P9-000BHl-F1 for radiusext-data@psg.com; Tue, 10 Jun 2008 18:17:11 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K68P3-000BGf-PA for radiusext@ops.ietf.org; Tue, 10 Jun 2008 18:17:09 +0000 Received: (qmail 21865 invoked from network); 10 Jun 2008 14:17:04 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 10 Jun 2008 14:17:04 -0400 From: "David B. Nelson" To: Cc: "'David Harrington'" Subject: RADEXT Issue 255 (NAS Management Authorization) Date: Tue, 10 Jun 2008 14:17:00 -0400 Organization: Elbrys Networks, Inc. Message-ID: <5FF9CBDF54F34CDAAE42532D4E1544AE@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjLJiyZ7GBA+PiHS3yKNe2aQJRrJQ== Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > 8.1 (and elsewhere) > Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or > HTML/HTTP? The attribute in question, Framed-Management-Protocol, is used to describe a management *application-layer* protocol. SNMP clearly qualifies. An integrated web server, providing management via web pages, also qualifies, although a web server is by no means limited to management applications -- all sorts of applications can be implemented using a web services model. When we get to options such as FTP, which means to describe provisioning of management information by "file copy", the distinction is even less clear. File copy operations are used for all sorts of things besides network device management. This attribute is not attempting to describe a transport protocol. We had one of those in a prior version and it was eliminated based on comments received. Attempting to provision the transport protocol was causing confusion without adding any offsetting value. The value (2) of the Framed-Management-Protocol means a web-services based management interface. Yes, it uses HTTP, but the meaning that is intended here is restricted to a web server application for the purpose of device management. > Should we develop acronyms NETCONFS and SNMPS and CLIS so we can just > lump the non-secure and secure versions into Configuration-based, and > Polling-based names and so on? I don't think that this document is the right vehicle to define new nomenclature for existing management services and protocols. I'm open to devising some clarifying text here, but I think we need to keep the scope of semantics for this attribute narrow, i.e. limited to indication of the management application-layer protocol. > section 8.2 > "The same "No Protection" semantics are conveyed by omitting this > attribute from an Access-Accept packet." > Why is this the default behavior? Wouldn't it be better to default > to full security if the attribute is not present? I believe that would violate the RADEXT Charter restriction on maintaining backwards compatibility / interoperability with existing RADIUS standards and fielded implementations. I propose to reject this comment. > Section 8.3 > Paragraph 3 says what to do if one is received; and paragraph talks > about receiving more than one. What if zero are received? RADIUS clients and servers must always be prepared to *not* receive any optional attribute in any message. There can be no implicit semantics of a "missing" attribute other than to "do nothing" as regards the semantics of that particular attribute. In the case of Management-Policy-Id, the absence of an attribute means that the NAS applies no management access control/filtering policy. This basic to the operation of the RADIUS protocol, and it is assumed that readers are familiar with that behavior. Do you think it needs to be reiterated here? Paragraph 3 says what to do if one is received; and paragraph talks about receiving more than one. What if zero are received? > Paragraph 3 says if "the policy rules are incorrectly > formatted, the NAS MUST treat the packet as if it had been an > Access-Reject." > > Doesn't this potentially override what the management protocol says > should be done if the rules are incorrectly formatted? If the underlying management protocol has default rules, in the absence of any additional provisioning by RADIUS, then these would still apply. > If the mgmt protocol defines an error condition for incorrectly > formatted rules, that error won't be sent because the session is > rejected, right? Yes. However, I don't think we ought to go down the path of inserting RADIUS in the middle of a client-server (or peer-peer) applications layer protocols, management or otherwise. The standard RAIUS behavior (it has always been so) is that if the client receives an attribute that it can interpret, i.e. that it supports, and it cannot decipher or correctly act upon the value of the attribute, it must "punt" the session, rather than risk misunderstanding the intent of the system administrator and allowing more service access than was originally desired. This is almost always a case of misconfiguration, and it is assumed that human intervention by the system administrator will be required to resolve it. > What happens if it is considered incorrect formatting to have an empty > table of rules, but the operator is trying to gain mgmt access to set > the policy rules into the table? Would RADIUS even know whether the > rules were incorrectly formatted? The RADIUS client itself would likely not know, but another portion of the NAS software that is responsible for making the rules take effect would very likely know, and would be able to return an error code to the RADIUS client. This is simply a case of making sure that the security configuration is valid before you enable security checking. One more case of "locking the keys in the car" if you are not careful. Make sure you have the key before you push down the lock button. :-) I think we could add some sort if "Implementation Note" warning users of the potential issue. I don't think we want to dilute the security by requiring that the RADIUS client attempt to "second guess" configuration errors in favor of granting [greater] access. > section 8.4 > I don't understand why we need a special Management-Privilege-Level > attribute. This should be able to specified as a named policy in the > Management-Policy-ID, such as "Level 1" and "Level 2", or even "1" and > "2" and "3". Implementations simply need to map between the policy > name and their privilege-level policy implementation. This attribute was added to support legacy access level mechanisms that are integer-value based, without conflating them with the newer text-string-valued, policy-named based mechanism. In the "green fields" case, i.e. in the absence of a fairly wide deployment of the legacy mechanism, I would fully agree with you. What you suggest *could* be made to work. I think it has greater risk because of its interaction with legacy mechanisms. I would propose to retain the separate attributes, unless there is WG consensus to combine them. > section 9: > I have a concern about protocol versions. What if I want SSHv2 > because I don't think SSHv1 is adequate? Should I be able to make the > distinction? or is that simply an operator-provisioning task to > disallow SSHv1 to the device? I would argue it ought to be the latter. It is not always clear where to draw the line as to how granular AAA-based provisioning ought to be. AAA-based provisioning is not intended to supplant all operator provisioning requirements. I've been attempting to apply the "less is more" philosophy in the absence of a clear use-case that dictates "more is more". :-) > Section 9: > Example #5 mentions SNMPv3, but the attribute says only SNMP. Ooops. Editorial cruft. Will fix in -03. > Section 9: > I would change the paragraph in example #5: > OLD: Note that there is currently no standardized way of > implementing this management policy mapping within SNMPv3. Such > mechanisms are implementation specific. > NEW: "A standardized way of mapping from Management-Policy-ID to a > particular access control policy in SNMP is under research." OK. Will fix in -03. > Section 9: > Example #6 talks about using the Secure Shell Transport Model, > but most existing SNMP implementations do not support this yet. >The "transport model" approach supports a binding between the SSH > authenticated identity and the SNMP database access controls. Some > SNMP implementations support running SNMP (any version) over an > SSH tunnel, but they provide no such binding. I think it is an > SNMP internal matter for SNMP access controls to say "they must > use transport model to get database access". So I would remove > the mention of the Secure Shell Transport Model from the example: > OLD: 6. SNMP secure Transport Model access, using the Secure Shell > Transport Model: > NEW: 6. SNMP access, via a fully-protected secure tunnel of SSH, > to an undefined management access level: OK. Will fix in -03. > Section 9: > Example#8 doesn't mention which transport protocol should be > used to provide security services. Should it, or is it intentional > to allow any transport protocol be used that can provide > Confidentiality-Protection? We've previously decided to not provision the specific transport protocol, but rather to only provision the security properties of the protocol. This is another of those "less is more" arguments. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jun 10 11:32:27 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAC883A6A77 for ; Tue, 10 Jun 2008 11:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 3JRYFGW9a+qi for ; Tue, 10 Jun 2008 11:32:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0042D3A692E for ; Tue, 10 Jun 2008 11:32:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K68Ye-000CUV-KF for radiusext-data@psg.com; Tue, 10 Jun 2008 18:27:00 +0000 Received: from [64.233.166.179] (helo=py-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K68Ya-000CTw-HI for radiusext@ops.ietf.org; Tue, 10 Jun 2008 18:26:58 +0000 Received: by py-out-1112.google.com with SMTP id d32so1135808pye.19 for ; Tue, 10 Jun 2008 11:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=6CdLSnrJCQNHmPUgsNpT8vgHLgf09K3ep9cIOaatS2Y=; b=uM1GO0MekFmzQkwkVcIhX9PV+wBvF+HLW8v/sRME5yI3X/1eunJFeZdnDA8OiJPuNh 4lngjfNiIByLiIAp+/dqGFVezK1EBiERCYjzVBVAAOoHWBQEt+n4ROds8ddRo9o9o82W QOb6AzIwpRcL0SHWDJrh3tOD/EQsvdV/A25K0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=iUXLtwhxVfkU9h63tcYDNEwa+9WenGgcs6bn0a6/QFrPJs5AJ48u9hN5s18MEvS5c6 iWPcFgqR+Wi+Ax9zpQ72C5DMeKU/Zt6SJmknQiyXfcgwoHDBVdmN9UTyYtnaUzbi6Sft lTd8U2c/S+AfSjTv7A5pvf4D5wZ+kLMGGNtjE= Received: by 10.114.159.5 with SMTP id h5mr5346340wae.222.1213122415445; Tue, 10 Jun 2008 11:26:55 -0700 (PDT) Received: by 10.114.79.8 with HTTP; Tue, 10 Jun 2008 11:26:55 -0700 (PDT) Message-ID: Date: Tue, 10 Jun 2008 14:26:55 -0400 From: "Greg Weber" To: "David B. Nelson" Subject: Re: RADEXT Issue 255 (NAS Management Authorization) Cc: radiusext@ops.ietf.org, "David Harrington" In-Reply-To: <5FF9CBDF54F34CDAAE42532D4E1544AE@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5FF9CBDF54F34CDAAE42532D4E1544AE@xpsuperdvd2> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: >> Should we develop acronyms NETCONFS and SNMPS and CLIS so we can just >> lump the non-secure and secure versions into Configuration-based, and >> Polling-based names and so on? > > I don't think that this document is the right vehicle to define new > nomenclature for existing management services and protocols. > > I'm open to devising some clarifying text here, but I think we need to keep > the scope of semantics for this attribute narrow, i.e. limited to indication > of the management application-layer protocol. Slightly less diplomatically, RADEXT is having trouble tying its own shoestrings. We don't need to worry about the shoes of others... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jun 10 13:33:12 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5413A6ABB for ; Tue, 10 Jun 2008 13:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 YhbIJB9c2Fu4 for ; Tue, 10 Jun 2008 13:33:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D82423A6A56 for ; Tue, 10 Jun 2008 13:33:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6AOn-0002bf-4D for radiusext-data@psg.com; Tue, 10 Jun 2008 20:24:57 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6AOg-0002as-P6 for radiusext@ops.ietf.org; Tue, 10 Jun 2008 20:24:55 +0000 Received: (qmail 24843 invoked from network); 10 Jun 2008 16:24:49 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 10 Jun 2008 16:24:49 -0400 From: "David B. Nelson" To: Cc: "'Bernard Aboba'" Subject: RADEXT Issue 256 (NAS management Authorization) Date: Tue, 10 Jun 2008 16:24:44 -0400 Organization: Elbrys Networks, Inc. Message-ID: <3F78A531608E4E46B5AA90F8B92EF385@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjLOAUO9iNIu5F7SDe+sKZWp0fiFw== Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > Abstract > > The current text is a bit wordy. How about this? > > This document describes Remote Authentication Dial-In User > Service (RADIUS) attributes for the authorization and service > provisioning of Network Access Servers (NASes). Both local and > remote management are supported, with granular access rights > and management privileges. Specific provisions are made for > remote management via framed management protocols, and for > specification of a protected transport protocol. Sounds good to me. Will fix on -03. > Section 7.1 > > I don't think you need to repeat much of Section 5.6 of RFC 2865. > Why not just reference it instead? Here is some recommended text > for this section: > > 7.1. Service-Type > > The Service-Type attribute is defined in Section 5.6 of RFC 2865 > [RFC2865]. This document defines a new value of the Service-Type > Attribute: > > (TBA) Framed-Management > > The semantics of the Framed-Management service are as follows: > > Framed-Management A framed management protocol session should > be started on the NAS. OK. Will revise on -03. > Section 8.1 > > The Framed-Management-Protocol attribute indicates the application- > layer management protocol to be used for framed management access. > It MAY be used in both Access-Request and Access-Accept packets. > > Please add a sentence explaining the semantics in this usage. For > example, in the Access-Request I assume that this Attribute describes > the protocol that the client is using for remote administration. Yes. > What does it mean in an Access-Accept? The same thing that any other service provisioning attribute means -- start the described service for the user's connection. Typically these things are decided by the RADIUS Server based on the user's account profile information and any relevant hint attributes. > For example, what does the NAS do if the value in the Access- > Accept is different from the protocol that is being used? Does > it disconnect? Yes. It would also disconnect if the provisioned service is not supported in the NAS. How about the following for clarifying text? It is RECOMMENDED that the NAS include an appropriately valued Framed-Management-Protocol attribute in Access-Request packet, indicating the type of access being requested, when the user requests a form of remote management via a framed management application protocol. It is further RECOMMENDED that the NAS include a Service-Type attribute with the value Framed-Management (TBA) in the same Access-Request packet. The RADIUS Server MAY use these hint attributes in making its authorization decision. The RADIUS Server MAY include a Framed-Management-Protocol attribute in an Access-Accept packet that also includes a Service-Type attribute with a value of Framed-Management, when the RADIUS Server chooses to enforce an management access policy for the authenticated user, that dictates one form of management access in preference to others. When a NAS receives a Framed-Management-Protocol attribute in an Access-Accept packet, it MUST deliver that specified form of management access or disconnect the session. If the NAS does not support the provisioned management application-layer protocol, or the management access protocol requested by the user does not match that of the Framed-Management-Protocol attribute in the Access-Accept packet, the NAS must treat the response packet as if it had been an Access-Reject. > Section 8.2 > What packets can this attribute be included in? Access-Request & > Access-Accept? Yes. Also Accounting-Request for session logging purposes. > What are the semantics in each case? For example, in an > Access-Request is this the level of protection that is being used? Yes. This will be communicated to the RADIUS Client from the respective management application, to the extent that application is aware of the protection level of its underlying transport. > What if the value in an Access-Accept is different (e.g. higher) > than that in use? For example, if confidentiality & integrity is > being requested, but the session is protected with TLS and an > integrity-only ciphersuite? Is the session dropped? Yes. Do we need clarifying text, such as I proposed for the Framed-Management-Protocol attribute (see above)? Such clarifying text might read as follows: It is RECOMMENDED that the NAS include an appropriately valued Management-Transport-Protection attribute in Access-Request packet, indicating the level of transport protection for the management access being requested, when that information is available to the RADIUS Client. The RADIUS Server MAY use this hint attribute in making its authorization decision. The RADIUS Server MAY include a Management-Transport-Protection attribute in an Access-Accept packet that also includes a Service-Type attribute with a value of Framed-Management, when the RADIUS Server chooses to enforce an management access security policy for the authenticated user, that dictates a minimum level of transport security. When a NAS receives a Management-Transport-Protection attribute in an Access-Accept packet, it MUST deliver the management access over a transport with equal or better protection characteristics or disconnect the session. If the NAS does not support protected management transport protocols, or the level of protection available does not match that of the Management-Transport-Protection attribute in the Access-Accept packet, the NAS must treat the response packet as if it had been an Access-Reject. > o Confidentiality-Protection: The management session requires > protection in a secure or protected transport, that is supported > by the management access protocol and implementation. The secure > transport MUST provide Confidentiality Protection. > > Does this option really make sense? When would you want Confidentiality > but not integrity? Isn't this dangerous? This was discussed at IETF-71 and the proposal was to remove the Confidentiality (only) option. I propose to do that in the -03 version. > Section 9 > > The examples use the Transport-Protocol Attribute, which is not > defined in this document any more. Editorial cruft. Will fix in -03. > Also, please include the value of NAS-Port-Type in the examples. OK. > Section 11 > > I'd recommend moving this to a sub-section under Security > Considerations. Hmmm. Much of this discussion has impact on security, on the other hand, I think that Proxy Considerations is a separate topic that justifies treatment in a separate section, for emphasis. I don't have a strong opinion on this, but my initial reaction is to suggest that we leave it in a separate section. > Section 13 > > This section needs to be rewritten to list the new attribute for which > numbers being requested, as well as the new value for Service-Type. So, you're suggesting that I not expect IANA to search through the document for all the (TBA) placeholders, but rather enumerate all the requests here? OK, I can do that in version -03. All other comments in Issue 256, not otherwise discussed here are accepted and will appear in the -03 version. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 11 01:04:12 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3226B3A68DB for ; Wed, 11 Jun 2008 01:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 5JMdnmefkdkf for ; Wed, 11 Jun 2008 01:04:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2EC643A6879 for ; Wed, 11 Jun 2008 01:04:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6LEc-000Fwj-Vt for radiusext-data@psg.com; Wed, 11 Jun 2008 07:59:10 +0000 Received: from [76.96.30.48] (helo=QMTA05.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6LEZ-000FwD-Fu for radiusext@ops.ietf.org; Wed, 11 Jun 2008 07:59:09 +0000 Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id cXwK1Z00F0x6nqcA500c00; Wed, 11 Jun 2008 07:59:07 +0000 Received: from gwzPC ([124.120.229.58]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id cXyY1Z0021GEcyc8YXysZS; Wed, 11 Jun 2008 07:59:05 +0000 X-Authority-Analysis: v=1.0 c=1 a=cxqNUEo8pucA:10 a=baqD8T6xIGQA:10 a=WGXE6d_RvVrMeRC9hx0A:9 a=GT1trB5KIgm5bYt1kpApvcek9cEA:4 a=-utQw5L2n1AA:10 a=oltf0pfCdT4A:10 From: "Glen Zorn" To: "'David B. Nelson'" Cc: "'David Harrington'" , , References: <5FF9CBDF54F34CDAAE42532D4E1544AE@xpsuperdvd2> In-Reply-To: <5FF9CBDF54F34CDAAE42532D4E1544AE@xpsuperdvd2> Subject: RE: RADEXT Issue 255 (NAS Management Authorization) Date: Wed, 11 Jun 2008 14:58:21 +0700 Message-ID: <000901c8cb98$f557ab10$e0070130$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjLJiyZ7GBA+PiHS3yKNe2aQJRrJQAcRMqg Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: David B. Nelson writes: > > 8.1 (and elsewhere) > > Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or > > HTML/HTTP? > > The attribute in question, Framed-Management-Protocol, is used to > describe a > management *application-layer* protocol. SNMP clearly qualifies. An > integrated web server, providing management via web pages, also > qualifies, It's not at all clear to me that "Web services" qualifies as any type of protocol at all. W3C defines a "Web service" as ""a software system designed to support interoperable Machine to Machine interaction over a network." Certainly, this definition requires the operation of one or more network protocols but there is no requirement that HTTP be one of them. I think that the Attribute needs to be renamed -- maybe "Framed-Management-Method"? ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 11 01:12:07 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532123A69FC for ; Wed, 11 Jun 2008 01:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.637 X-Spam-Level: X-Spam-Status: No, score=-0.637 tagged_above=-999 required=5 tests=[AWL=-1.387, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] 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 k+Cxl+-7MWcP for ; Wed, 11 Jun 2008 01:12:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D49B3A69E5 for ; Wed, 11 Jun 2008 01:12:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6LNE-000HEJ-LM for radiusext-data@psg.com; Wed, 11 Jun 2008 08:08:04 +0000 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6LN3-000HCS-99 for radiusext@ops.ietf.org; Wed, 11 Jun 2008 08:08:02 +0000 Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 78AB3C004A; Wed, 11 Jun 2008 10:07:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nSWE8gHcbDh2; Wed, 11 Jun 2008 10:07:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B289AC0046; Wed, 11 Jun 2008 10:07:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 76C3E5B47EB; Wed, 11 Jun 2008 10:07:45 +0200 (CEST) Date: Wed, 11 Jun 2008 10:07:45 +0200 From: Juergen Schoenwaelder To: Glen Zorn Cc: "'David B. Nelson'" , 'David Harrington' , radiusext@ops.ietf.org Subject: Re: RADEXT Issue 255 (NAS Management Authorization) Message-ID: <20080611080745.GB817@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: Glen Zorn , "'David B. Nelson'" , 'David Harrington' , radiusext@ops.ietf.org References: <5FF9CBDF54F34CDAAE42532D4E1544AE@xpsuperdvd2> <000901c8cb98$f557ab10$e0070130$@net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000901c8cb98$f557ab10$e0070130$@net> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 11, 2008 at 02:58:21PM +0700, Glen Zorn wrote: > David B. Nelson writes: > > > > 8.1 (and elsewhere) > > > Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or > > > HTML/HTTP? > > > > The attribute in question, Framed-Management-Protocol, is used to > > describe a > > management *application-layer* protocol. SNMP clearly qualifies. An > > integrated web server, providing management via web pages, also > > qualifies, > > It's not at all clear to me that "Web services" qualifies as any type of > protocol at all. W3C defines a "Web service" as ""a software system > designed to support interoperable Machine to Machine interaction over a > network." Certainly, this definition requires the operation of one or more > network protocols but there is no requirement that HTTP be one of them. I > think that the Attribute needs to be renamed -- maybe > "Framed-Management-Method"? I had the same reaction but then I read the text that is contained in the ID and found that rather clear. And yes, it helps to avoid the phrase "web services". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 11 05:02:54 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6363A6838 for ; Wed, 11 Jun 2008 05:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 MPm6Np54zihq for ; Wed, 11 Jun 2008 05:02:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 318663A67ED for ; Wed, 11 Jun 2008 05:02:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6OvH-000KAI-2C for radiusext-data@psg.com; Wed, 11 Jun 2008 11:55:27 +0000 Received: from [76.96.30.40] (helo=QMTA04.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6OvD-000K9a-DA for radiusext@ops.ietf.org; Wed, 11 Jun 2008 11:55:25 +0000 Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id cbV31Z00o0b6N64A402900; Wed, 11 Jun 2008 11:55:22 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id cbvK1Z00824Kx1C8PbvLEd; Wed, 11 Jun 2008 11:55:21 +0000 X-Authority-Analysis: v=1.0 c=1 a=cxqNUEo8pucA:10 a=baqD8T6xIGQA:10 a=NfDuHvPo4QyexjW6zgoA:9 a=nEr9_t2RwZBQRL-9U2nD9jAzNMQA:4 a=tqucuuI3bnEA:10 From: "David B. Nelson" To: Cc: "'David Harrington'" References: <5FF9CBDF54F34CDAAE42532D4E1544AE@xpsuperdvd2> <000901c8cb98$f557ab10$e0070130$@net> Subject: RE: RADEXT Issue 255 (NAS Management Authorization) Date: Wed, 11 Jun 2008 07:55:24 -0400 Message-ID: <004501c8cbba$09f66f40$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <000901c8cb98$f557ab10$e0070130$@net> thread-index: AcjLJiyZ7GBA+PiHS3yKNe2aQJRrJQAcRMqgAAgOVmA= Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn writes... > It's not at all clear to me that "Web services" qualifies as any type > of protocol at all. I wasn't proposing that we formally characterize embedded web management, as it's deployed in many NASes today, as "web services". There is something of a nomenclature issue here, though, specifically how best to "name" the form of management that uses an embedded web server to serve up web pages (HTML content) over the HTTP application-layer protocol to a web browser application? The issue is not that HTML/HTTP fails describe the protocol, but rather that other things besides management can be served in this fashion. It's my understanding that lots of things are "tunneled" in HTTP these days, firewall avoidance being but one reason. What's important, at the end of the day, is that there be an unambiguous binding between the values of this attribute and the framed (i.e. non-textual) management mechanisms they represent. > I think that the Attribute needs to be renamed -- maybe > "Framed-Management-Method"? I have no objection to that choice of attribute name, but I'm wondering if it really addresses the underlying issue. The issue is to pick one identifying characteristic of framed management to serve as the "name". The application layer protocol seemed a logical choice. Does anyone else have thoughts to share on this, one way or another? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 11 09:26:06 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BC973A68E3 for ; Wed, 11 Jun 2008 09:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.864 X-Spam-Level: X-Spam-Status: No, score=-0.864 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 xq9tkPuBsRQv for ; Wed, 11 Jun 2008 09:26:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 11E0E3A68DB for ; Wed, 11 Jun 2008 09:26:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6T24-0005zw-4A for radiusext-data@psg.com; Wed, 11 Jun 2008 16:18:44 +0000 Received: from [65.55.111.99] (helo=blu0-omc2-s24.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6T1z-0005zG-N6 for radiusext@ops.ietf.org; Wed, 11 Jun 2008 16:18:42 +0000 Received: from BLU137-W45 ([65.55.111.73]) by blu0-omc2-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 09:18:38 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_101a4be9-71a3-45e1-8ee8-03d2e0a95a1a_" X-Originating-IP: [74.233.153.78] From: Bernard Aboba To: "David B. Nelson" , Subject: RE: RADEXT Issue 256 (NAS management Authorization) Date: Wed, 11 Jun 2008 09:18:39 -0700 Importance: Normal In-Reply-To: <3F78A531608E4E46B5AA90F8B92EF385@xpsuperdvd2> References: <3F78A531608E4E46B5AA90F8B92EF385@xpsuperdvd2> MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jun 2008 16:18:38.0909 (UTC) FILETIME=[CE94B6D0:01C8CBDE] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_101a4be9-71a3-45e1-8ee8-03d2e0a95a1a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > When a NAS receives a Framed-Management-Protocol attribute in an > Access-Accept packet, it MUST deliver that specified form of management > access or disconnect the session. If the NAS does not support the > provisioned management application-layer protocol, or the management acce= ss > protocol requested by the user does not match that of the > Framed-Management-Protocol attribute in the Access-Accept packet, the NAS > must treat the response packet as if it had been an Access-Reject. [BA] Should this be "MUST"? Presumably if the NAS supports the new Service= -Type, then it is also required to understand the Framed-Management-Protocol attri= bute and take the above action in response to an unsupportable value. =20 > It is RECOMMENDED that the NAS include an appropriately valued > Management-Transport-Protection attribute in Access-Request packet, ^an > indicating the level of transport protection for the management access be= ing > requested, when that information is available to the RADIUS Client. The > RADIUS Server MAY use this hint attribute in making its authorization > decision. >=20 > The RADIUS Server MAY include a Management-Transport-Protection attribute= in > an Access-Accept packet that also includes a Service-Type attribute with = a > value of Framed-Management, when the RADIUS Server chooses to enforce an > management access security policy for the authenticated user, that dictat= es > a minimum level of transport security. >=20 > When a NAS receives a Management-Transport-Protection attribute in an > Access-Accept packet, it MUST deliver the management access over a transp= ort > with equal or better protection characteristics or disconnect the session= . > If the NAS does not support protected management transport protocols, or = the > level of protection available does not match that of the > Management-Transport-Protection attribute in the Access-Accept packet, th= e > NAS must treat the response packet as if it had been an Access-Reject. "must" -> "MUST" as above.=20 Also, I'd suggest capitalizing the word "Attribute" when referring to a spe= cific attribute, as was the custom in RFC 2865.=20 > So, you're suggesting that I not expect IANA to search through the docume= nt > for all the (TBA) placeholders, but rather enumerate all the requests her= e? > OK, I can do that in version -03. Yes. This makes it easier for them.=20 --_101a4be9-71a3-45e1-8ee8-03d2e0a95a1a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> When a NAS receives a Framed-Management-Protocol attribute in an> Access-Accept packet, it MUST deliver that specified form of managem= ent
> access or disconnect the session. If the NAS does not support = the
> provisioned management application-layer protocol, or the manag= ement access
> protocol requested by the user does not match that of = the
> Framed-Management-Protocol attribute in the Access-Accept packe= t, the NAS
> must treat the response packet as if it had been an Acce= ss-Reject.

[BA] Should this be "MUST"?  Presumably if the NAS s= upports the new Service-Type,
then it is also required to understand the= Framed-Management-Protocol attribute
and take the above action in respo= nse to an unsupportable value. 

> It is RECOMMENDED that th= e NAS include an appropriately valued
> Management-Transport-Protecti= on attribute in Access-Request packet,
     &nb= sp;            =             &nb= sp;            =             &nb= sp;            = ^an

> indicating the level of transport protection for the manag= ement access being
> requested, when that information is available to= the RADIUS Client. The
> RADIUS Server MAY use this hint attribute = in making its authorization
> decision.
>
> The RADIUS S= erver MAY include a Management-Transport-Protection attribute in
> an= Access-Accept packet that also includes a Service-Type attribute with a> value of Framed-Management, when the RADIUS Server chooses to enforce= an
> management access security policy for the authenticated user, t= hat dictates
> a minimum level of transport security.
>
>= ; When a NAS receives a Management-Transport-Protection attribute in an
= > Access-Accept packet, it MUST deliver the management access over a tra= nsport
> with equal or better protection characteristics or disconnec= t the session.
> If the NAS does not support protected management tra= nsport protocols, or the
> level of protection available does not mat= ch that of the
> Management-Transport-Protection attribute in the Acc= ess-Accept packet, the
> NAS must treat the response packet as if it = had been an Access-Reject.

"must" -> "MUST" as above.

Als= o, I'd suggest capitalizing the word "Attribute" when referring to a specif= ic
attribute, as was the custom in RFC 2865.


> So, you're= suggesting that I not expect IANA to search through the document
> f= or all the (TBA) placeholders, but rather enumerate all the requests here?<= br>> OK, I can do that in version -03.

Yes.  This makes it e= asier for them.
= --_101a4be9-71a3-45e1-8ee8-03d2e0a95a1a_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 11 17:39:42 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82A13A67A6 for ; Wed, 11 Jun 2008 17:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 SrPogylWC4-2 for ; Wed, 11 Jun 2008 17:39:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9FF4F3A67A4 for ; Wed, 11 Jun 2008 17:39:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6aln-000OXZ-PM for radiusext-data@psg.com; Thu, 12 Jun 2008 00:34:27 +0000 Received: from [76.96.30.16] (helo=QMTA01.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6ali-000OWt-AD for radiusext@ops.ietf.org; Thu, 12 Jun 2008 00:34:25 +0000 Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id cdZo1Z00X16AWCUA10d400; Thu, 12 Jun 2008 00:34:21 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id coaJ1Z00B24Kx1C8SoaKGP; Thu, 12 Jun 2008 00:34:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=FUJ3UmcymmYA:10 a=mE0ztZEDHRkA:10 a=48vgC7mUAAAA:8 a=4HyZKhiD7ucwt9HJrjAA:9 a=9wNFjcuSx3Yl_cNFiOkR0ni_m44A:4 a=LY0hPdMaydYA:10 From: "David B. Nelson" To: Cc: "'Bernard Aboba'" References: <3F78A531608E4E46B5AA90F8B92EF385@xpsuperdvd2> Subject: RE: RADEXT Issue 256 (NAS management Authorization) Date: Wed, 11 Jun 2008 20:34:23 -0400 Message-ID: <010c01c8cc24$11205640$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: thread-index: AcjL36U2arTmS5tUSDGUWXJpwz7AOQAQy87w Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: One of the comments in Issue 256 was to add references for all of the management protocols (methods?) enumerated for the Framed-Management-Protocol Attribute in Section 8.1 In researching stable references, I discovered two issues: (1) Some of these don't have good, stable references, such as standards documents, but seem to be documented by UNIX "man pages". (2) Some of these have supposedly been largely replaced in common usage. The straw-man text that I now have looks like this: o SNMP: Simple Network Management Protocol. [RFC3411], [RFC3412], [RFC3413], [RFC3414], [RFC3415], [RFC3416], [RFC3417], [RFC3418] o Web-based: Use of an embedded web server in the NAS for management via a generic web browser client. The interface presented to the administrator may be graphical, tabular or textual. The protocol is HTML over HTTP. The protocol may optionally be HTML over HTTPS, i.e. using HTTP over TLS. o NETCONF: Management via the NETCONF protocol using XML over supported transports (e.g. SSH, BEEP, SOAP). As secure transport profiles are defined for NETCONF, the list of transport options may expand. [RFC4741], [RFC4742], [RFC4743], [RFC4744] o FTP: File Transfer Protocol, used to transfer configuration files to and from the NAS. [RFC0959] o TFTP: Trivial File Transfer Protocol, used to transfer configuration files to and from the NAS. [RFC1350] o SFTP: SSH File Transfer Protocol, used to securely transfer configuration files to and from the NAS. SFTP uses the services of SSH. (http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13) o RCP: Remote CoPy file copy utility (Unix-based), used to transfer configuration files to and from the NAS. RCP has bee largely replaced by SFTP. o SCP: Secure CoPy file copy utility (Unix-based), used to transfer configuration files to and from the NAS. SCP has been largely replaced by SFTP. IIRC, RCP and TFTP were added to a previous draft version to resolve previous review comments. It is reported (e.g. Wikipedia) that SFTP is now preferred to both RCP and SCP. I would like to get some feedback from the WG prior to submitting the -03 version, as to whether: (1) Are all of these methods of copying configuration files to a NAS in current use? (2) Are the cited references (or lack thereof) sufficient to our needs? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 11 21:27:35 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858A73A67CF for ; Wed, 11 Jun 2008 21:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.483 X-Spam-Level: X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] 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 15gDN6CIxQnu for ; Wed, 11 Jun 2008 21:27:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB1133A6774 for ; Wed, 11 Jun 2008 21:27:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6eM2-000Pw1-0L for radiusext-data@psg.com; Thu, 12 Jun 2008 04:24:06 +0000 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6eLx-000PuI-4U for radiusext@ops.ietf.org; Thu, 12 Jun 2008 04:24:03 +0000 Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB18CC0021; Thu, 12 Jun 2008 06:23:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id X214BOgwNHyy; Thu, 12 Jun 2008 06:23:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8097C0008; Thu, 12 Jun 2008 06:23:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 51DC15B588E; Thu, 12 Jun 2008 06:23:53 +0200 (CEST) Date: Thu, 12 Jun 2008 06:23:53 +0200 From: Juergen Schoenwaelder To: "David B. Nelson" Cc: radiusext@ops.ietf.org, 'Bernard Aboba' Subject: Re: RADEXT Issue 256 (NAS management Authorization) Message-ID: <20080612042353.GA2297@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: "David B. Nelson" , radiusext@ops.ietf.org, 'Bernard Aboba' References: <3F78A531608E4E46B5AA90F8B92EF385@xpsuperdvd2> <010c01c8cc24$11205640$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010c01c8cc24$11205640$011716ac@NEWTON603> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 11, 2008 at 08:34:23PM -0400, David B. Nelson wrote: > o SCP: Secure CoPy file copy utility (Unix-based), used to transfer > configuration files to and from the NAS. SCP has been largely > replaced by SFTP. I am not sure there is evidence that scp has been largely replaced by sftp. I suggest to simply remove the last sentence. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Jun 12 04:06:01 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9420F3A6A63 for ; Thu, 12 Jun 2008 04:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 y3jDgctGYHxw for ; Thu, 12 Jun 2008 04:06:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B12F23A694A for ; Thu, 12 Jun 2008 04:06:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6kY5-000NZp-2z for radiusext-data@psg.com; Thu, 12 Jun 2008 11:00:57 +0000 Received: from [76.96.30.48] (helo=QMTA05.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6kXy-000NYx-AD for radiusext@ops.ietf.org; Thu, 12 Jun 2008 11:00:52 +0000 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id cyi81Z0031GXsucA501800; Thu, 12 Jun 2008 11:00:49 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id cz0m1Z00324Kx1C8Tz0mZK; Thu, 12 Jun 2008 11:00:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=FUJ3UmcymmYA:10 a=mE0ztZEDHRkA:10 a=Aq_AN9N0fZ_9xfezWIgA:9 a=YrtWZodE1lE5vxzgwpCSVZdRwbEA:4 a=MxZ3bB5I4kYA:10 From: "David B. Nelson" To: Cc: , "'Bernard Aboba'" References: <3F78A531608E4E46B5AA90F8B92EF385@xpsuperdvd2> <010c01c8cc24$11205640$011716ac@NEWTON603> <20080612042353.GA2297@elstar.local> Subject: RE: RADEXT Issue 256 (NAS management Authorization) Date: Thu, 12 Jun 2008 07:00:51 -0400 Message-ID: <015501c8cc7b$9594a690$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080612042353.GA2297@elstar.local> thread-index: AcjMRJwr5xfIA5vxTFuB/Ld71A1jFwANr4ow Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > I am not sure there is evidence that scp has been largely replaced by > sftp. I suggest to simply remove the last sentence. What about RCP? It is still in use, or has it been [somewhat | largely] replaced by {SCP | SFTP}? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Jun 12 04:38:55 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8765B3A698E for ; Thu, 12 Jun 2008 04:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 5Pr2qr6F58aM for ; Thu, 12 Jun 2008 04:38:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 15F6F3A694D for ; Thu, 12 Jun 2008 04:38:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6l3f-0001oJ-Vw for radiusext-data@psg.com; Thu, 12 Jun 2008 11:33:35 +0000 Received: from [76.96.30.16] (helo=QMTA01.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6l3N-0001k1-3o for radiusext@ops.ietf.org; Thu, 12 Jun 2008 11:33:26 +0000 Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id cz7d1Z0021HpZEsA101900; Thu, 12 Jun 2008 11:33:16 +0000 Received: from gwzPC ([124.120.222.188]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id czYg1Z00144VtTQ8azZ1r0; Thu, 12 Jun 2008 11:33:14 +0000 X-Authority-Analysis: v=1.0 c=1 a=FUJ3UmcymmYA:10 a=mE0ztZEDHRkA:10 a=No5EcEP4AAAA:8 a=0MyJX-iI7GiDXdEteMEA:9 a=iF-dlTP_00v3G9WWiy8A:7 a=pCn1dnE5EVmb6hBdZFjt06MS8n0A:4 a=si9q_4b84H0A:10 a=oltf0pfCdT4A:10 From: "Glen Zorn" To: "'David B. Nelson'" , Cc: , "'Bernard Aboba'" References: <3F78A531608E4E46B5AA90F8B92EF385@xpsuperdvd2> <010c01c8cc24$11205640$011716ac@NEWTON603> <20080612042353.GA2297@elstar.local> <015501c8cc7b$9594a690$011716ac@NEWTON603> In-Reply-To: <015501c8cc7b$9594a690$011716ac@NEWTON603> Subject: RE: RADEXT Issue 256 (NAS management Authorization) Date: Thu, 12 Jun 2008 18:32:23 +0700 Message-ID: <00aa01c8cc80$06ecedd0$14c6c970$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcjMRJwr5xfIA5vxTFuB/Ld71A1jFwANr4owAABg/sA= Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: David B. Nelson writes: > > I am not sure there is evidence that scp has been largely replaced by > > sftp. I suggest to simply remove the last sentence. > > What about RCP? It is still in use, or has it been [somewhat | > largely] > replaced by {SCP | SFTP}? Does it really matter? If they will be included in the list, just include them w/o editorial comment (especially based upon a source like Wikipedia ;-). > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Jun 12 04:52:19 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4CC3A6897 for ; Thu, 12 Jun 2008 04:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 383Q8r1ndOZw for ; Thu, 12 Jun 2008 04:52:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B8BB3A67B7 for ; Thu, 12 Jun 2008 04:52:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6lGc-0003iu-Fw for radiusext-data@psg.com; Thu, 12 Jun 2008 11:46:58 +0000 Received: from [76.96.30.24] (helo=QMTA02.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6lGS-0003hD-Ps for radiusext@ops.ietf.org; Thu, 12 Jun 2008 11:46:53 +0000 Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id cySv1Z0050FhH24A206T00; Thu, 12 Jun 2008 11:46:47 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id czmk1Z00624Kx1C8UzmleZ; Thu, 12 Jun 2008 11:46:46 +0000 X-Authority-Analysis: v=1.0 c=1 a=FUJ3UmcymmYA:10 a=mE0ztZEDHRkA:10 a=H2zULSuLxCdca7dMqbIA:9 a=U7SfuL5pEt5_Fs5Sv7Fp0qLUgoMA:4 a=MxZ3bB5I4kYA:10 From: "David B. Nelson" To: "'Glen Zorn'" Cc: References: <3F78A531608E4E46B5AA90F8B92EF385@xpsuperdvd2> <010c01c8cc24$11205640$011716ac@NEWTON603> <20080612042353.GA2297@elstar.local> <015501c8cc7b$9594a690$011716ac@NEWTON603> <00aa01c8cc80$06ecedd0$14c6c970$@net> Subject: RE: RADEXT Issue 256 (NAS management Authorization) Date: Thu, 12 Jun 2008 07:46:49 -0400 Message-ID: <015f01c8cc82$017a0d90$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <00aa01c8cc80$06ecedd0$14c6c970$@net> thread-index: AcjMRJwr5xfIA5vxTFuB/Ld71A1jFwANr4owAABg/sAAATV2IA== Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > Does it really matter? If a protocol is no longer used, why bother include it in the list? > If they will be included in the list, just include them w/o editorial > comment... Yeah, that sounds like good advice. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Jun 12 05:00:54 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69D83A69CA for ; Thu, 12 Jun 2008 05:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 EaAyGtcvbsBd for ; Thu, 12 Jun 2008 05:00:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EA2353A67D9 for ; Thu, 12 Jun 2008 05:00:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6lQi-0005BZ-PL for radiusext-data@psg.com; Thu, 12 Jun 2008 11:57:24 +0000 Received: from [76.96.30.40] (helo=QMTA04.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6lQe-0005AL-Cd for radiusext@ops.ietf.org; Thu, 12 Jun 2008 11:57:22 +0000 Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id cyxp1Z0070b6N64A403Z00; Thu, 12 Jun 2008 11:57:18 +0000 Received: from gwzPC ([124.120.222.188]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id czws1Z00244VtTQ8Pzx86Y; Thu, 12 Jun 2008 11:57:16 +0000 X-Authority-Analysis: v=1.0 c=1 a=FUJ3UmcymmYA:10 a=mE0ztZEDHRkA:10 a=jlwfMlEu32od1ujbs4AA:9 a=ZJagg-XoeALijZaK5ysV8VzcC34A:4 a=si9q_4b84H0A:10 a=oltf0pfCdT4A:10 From: "Glen Zorn" To: "'David B. Nelson'" Cc: References: <3F78A531608E4E46B5AA90F8B92EF385@xpsuperdvd2> <010c01c8cc24$11205640$011716ac@NEWTON603> <20080612042353.GA2297@elstar.local> <015501c8cc7b$9594a690$011716ac@NEWTON603> <00aa01c8cc80$06ecedd0$14c6c970$@net> <015f01c8cc82$017a0d90$011716ac@NEWTON603> In-Reply-To: <015f01c8cc82$017a0d90$011716ac@NEWTON603> Subject: RE: RADEXT Issue 256 (NAS management Authorization) Date: Thu, 12 Jun 2008 18:56:35 +0700 Message-ID: <00ae01c8cc83$6524ed00$2f6ec700$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcjMRJwr5xfIA5vxTFuB/Ld71A1jFwANr4owAABg/sAAATV2IAAAUj4A Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: David B. Nelson [mailto:d.b.nelson@comcast.net] writes: > > Does it really matter? > > If a protocol is no longer used, why bother include it in the list? I'm sure somebody somewhere is using rcp (possibly even Kerberized) for example, esp. if their NAS is *nix-based. Why not? > > > If they will be included in the list, just include them w/o editorial > > comment... > > Yeah, that sounds like good advice. > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Jun 12 05:35:19 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276823A6A46 for ; Thu, 12 Jun 2008 05:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 lTPFyPAzv1zN for ; Thu, 12 Jun 2008 05:35:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E83553A6A04 for ; Thu, 12 Jun 2008 05:35:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6lxj-000AMU-2k for radiusext-data@psg.com; Thu, 12 Jun 2008 12:31:31 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6lxM-000AJh-SP for radiusext@ops.ietf.org; Thu, 12 Jun 2008 12:31:20 +0000 X-IronPort-AV: E=Sophos;i="4.27,631,1204498800"; d="scan'208";a="11508573" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2008 14:30:55 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5CCUopq007760; Thu, 12 Jun 2008 14:30:50 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5CCUoqR021565; Thu, 12 Jun 2008 12:30:50 GMT Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 14:30:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: draft-lourdelet-radext-ipv6-dhcp-00 published Date: Thu, 12 Jun 2008 14:31:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-lourdelet-radext-ipv6-dhcp-00 published Thread-Index: AcjMiDIFvS34EaIwTtaapCJ0oDmg4Q== From: "Benoit Lourdelet (blourdel)" To: , X-OriginalArrivalTime: 12 Jun 2008 12:30:50.0295 (UTC) FILETIME=[25DD7C70:01C8CC88] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1049; t=1213273850; x=1214137850; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20 |Subject:=20draft-lourdelet-radext-ipv6-dhcp-00=20published |Sender:=20; bh=jKyR5AUN4QatFAkwDOeFyvUb00SQ2CDqsfnIG56Fpds=; b=TIJJ+cCufGgP/V4gSZBJrVzUEwJuKE2EJuH2AfBLbuy4OFdlzAxYQ4W5xa INiHk7dg7+KJzlDkgxs/QpNhVMdrRhUW35visL0ctZgAqdXKtxprNbWFPIn6 pzv0bYbD7s; Authentication-Results: ams-dkim-2; header.From=blourdel@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hello, I published a document specifying new RADIUS attributes supporting IPv6 network access to complement [RFC3162] in DHCP environments. It addresses the need to dynamically advertise DNS Server addresses and one or multiple IPv6 addresses via DHCPv6. It is available here : http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-00. txt Comments are welcome. Regards Benoit Lourdelet A new version of I-D, draft-lourdelet-radext-ipv6-dhcp-00.txt has been successfuly submitted by Benoit Lourdelet and posted to the IETF repository. Filename: draft-lourdelet-radext-ipv6-dhcp Revision: 00 Title: IPv6 RADIUS attributes for DHCP based networks Creation_date: 2008-06-12 WG ID: Independent Submission Number_of_pages: 8 Abstract: This document specifies RADIUS [RFC2865] attributes supporting IPv6 network access to complement [RFC3162] in DHCP environments. It addresses the need to dynamically advertise DNS Server addresses and one or multiple IPv6 addresses via DHCPv6. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Jun 12 19:23:35 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8A1C3A69ED for ; Thu, 12 Jun 2008 19:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0PFo1LAQxYX for ; Thu, 12 Jun 2008 19:23:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 10F0E3A6B0B for ; Thu, 12 Jun 2008 19:23:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6ypG-000Pk8-Sc for radiusext-data@psg.com; Fri, 13 Jun 2008 02:15:38 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K6ypB-000PjF-GH for radiusext@ops.ietf.org; Fri, 13 Jun 2008 02:15:36 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id F228E3A69ED; Thu, 12 Jun 2008 19:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-management-authorization-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080613021501.F228E3A69ED@core3.amsl.com> Date: Thu, 12 Jun 2008 19:15:01 -0700 (PDT) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management Author(s) : D. Nelson, G. Weber Filename : draft-ietf-radext-management-authorization-03.txt Pages : 24 Date : 2008-06-12 This document describes Remote Authentication Dial-In User Service (RADIUS) attributes for the authorization and service provisioning of Network Access Servers (NASes). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via framed management protocols, and for specification of a protected transport protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-management-authorization-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-12191431.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Jun 13 14:49:11 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE8C03A6806 for ; Fri, 13 Jun 2008 14:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.256 X-Spam-Level: X-Spam-Status: No, score=-1.256 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 h30yKmyl7BkH for ; Fri, 13 Jun 2008 14:49:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D4773A67A7 for ; Fri, 13 Jun 2008 14:49:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7H4T-0004tc-No for radiusext-data@psg.com; Fri, 13 Jun 2008 21:44:33 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7H4P-0004t6-BK for radiusext@ops.ietf.org; Fri, 13 Jun 2008 21:44:31 +0000 Received: (qmail 18250 invoked from network); 13 Jun 2008 17:44:24 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 13 Jun 2008 17:44:24 -0400 From: "David B. Nelson" To: References: Subject: RE: Request for Review: Status Server Document Date: Fri, 13 Jun 2008 17:44:19 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjFIxb4UokZVUeIQY20g6mdhMf0ZAIehPBg In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: I have a "big picture" question to ask before I delve into further levels of detailed review and questions. Why is the Server-Status "query" packet responded to by an Access-Accept "reply" packet? It seems to me that were over-loading the semantics of Access-Accept by using it in this way. Maybe that's not particularly harmful -- I don't know for sure -- but over-loading always seems like a Bad Idea (tm) to me. Wouldn't it have been possible to use the same Command Code (Server-Status) for *both* the query and response, with the context coming from who's doing the receiving? I think that would be preferable, in a number of ways. I did see the not-so-subtle hint that this document is describing *existing* implementations, much as we did in the original RADIUS WG. The inference I draw is that redesign (i.e. helpful suggestions for alternate choices, such as the one my question raises) is not solicited or welcomed. Of course, maybe I'm simply reading too much into that wording. Anyway, why couldn't Server-Status be the RADIUS Command Code used for both queries and replies? Regards, Dave Nelson -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Jun 13 15:34:16 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881323A68A9 for ; Fri, 13 Jun 2008 15:34:16 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 qiEVB95ip0Vg for ; Fri, 13 Jun 2008 15:34:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8061B3A68AA for ; Fri, 13 Jun 2008 15:34:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7Hmr-000Auv-16 for radiusext-data@psg.com; Fri, 13 Jun 2008 22:30:25 +0000 Received: from [65.54.246.162] (helo=bay0-omc2-s26.bay0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7Hmn-000Au5-5P for radiusext@ops.ietf.org; Fri, 13 Jun 2008 22:30:23 +0000 Received: from hotmail.com ([10.4.31.18]) by bay0-omc2-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jun 2008 15:30:17 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 13 Jun 2008 15:30:16 -0700 Message-ID: Received: from 131.107.0.102 by BLU137-DAV8.phx.gbl with DAV; Fri, 13 Jun 2008 22:30:12 +0000 X-Originating-IP: [131.107.0.102] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: "'David B. Nelson'" , References: In-Reply-To: Subject: RE: Request for Review: Status Server Document Date: Fri, 13 Jun 2008 15:30:01 -0700 Message-ID: <000e01c8cda5$04934f40$0db9edc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjFIxb4UokZVUeIQY20g6mdhMf0ZAIehPBgAAHZHiA= Content-Language: en-us X-OriginalArrivalTime: 13 Jun 2008 22:30:16.0409 (UTC) FILETIME=[0DC0B490:01C8CDA5] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: >I did see the not-so-subtle hint that this document is describing *existing* >implementations, much as we did in the original RADIUS WG. The goal of the Status-Server specification is to document an existing protocol, much as RFC 5176 documented an existing protocol for dynamic authorization. That said, if there are improvements that can be made within the protocol while maintaining backward compatibility, then they should be considered. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Jun 14 01:37:08 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B183A69B2 for ; Sat, 14 Jun 2008 01:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 QH6CJjD81pPd for ; Sat, 14 Jun 2008 01:37:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31BF93A6991 for ; Sat, 14 Jun 2008 01:37:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7RAz-0004uZ-HY for radiusext-data@psg.com; Sat, 14 Jun 2008 08:31:57 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7RAw-0004u2-11 for radiusext@ops.ietf.org; Sat, 14 Jun 2008 08:31:55 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 78668123428C; Sat, 14 Jun 2008 10:31:52 +0200 (CEST) Message-ID: <485380D3.9060900@deployingradius.com> Date: Sat, 14 Jun 2008 10:26:59 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: David B. Nelson wrote: > Why is the Server-Status "query" packet responded to by an Access-Accept > "reply" packet? It seems to me that were over-loading the semantics of > Access-Accept by using it in this way. Maybe that's not particularly > harmful -- I don't know for sure -- but over-loading always seems like a Bad > Idea (tm) to me. Yes it's not ideal. It's a historical practice. > Wouldn't it have been possible to use the same Command Code (Server-Status) > for *both* the query and response, with the context coming from who's doing > the receiving? I think that would be preferable, in a number of ways. RADIUS has traditionally used separate status codes for requests and replies. Using the same code for both is about as bad (IMHO) as overloading Access-Accept. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Jun 14 07:05:53 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16293A68FF for ; Sat, 14 Jun 2008 07:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[AWL=-0.634, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 G5JnFHXzMG2F for ; Sat, 14 Jun 2008 07:05:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D52063A680A for ; Sat, 14 Jun 2008 07:05:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7WFU-000Kat-AS for radiusext-data@psg.com; Sat, 14 Jun 2008 13:56:56 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7WFJ-000KXk-3O for radiusext@ops.ietf.org; Sat, 14 Jun 2008 13:56:50 +0000 Received: (qmail 2700 invoked from network); 14 Jun 2008 09:56:41 -0400 Received: from unknown (HELO ?127.0.0.1?) (172.22.23.1) by gumby.elbrysnetworks.com with SMTP; 14 Jun 2008 09:56:41 -0400 Message-ID: <4853CE18.30108@elbrysnetworks.com> Date: Sat, 14 Jun 2008 09:56:40 -0400 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alan DeKok CC: radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document References: <485380D3.9060900@deployingradius.com> In-Reply-To: <485380D3.9060900@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok writes... >> Why is the Server-Status "query" packet responded to by an Access-Accept >> "reply" packet? It seems to me that were over-loading the semantics of >> Access-Accept by using it in this way. Maybe that's not particularly >> harmful -- I don't know for sure -- but over-loading always seems like a Bad >> Idea (tm) to me. > > Yes it's not ideal. It's a historical practice. Yes, so Bernard has explained. That makes review of this document in RADEXT a little bit challenging. We can, of course, polish the prose and make sure that the descriptions are self-consistent and clear and that the organization is logical. I guess only those who have access to the "historical implementation" can discern whether the descriptions are accurate and correct. The IESG, and the IETF at large, hold the WG, in general, and the WG Chairs and/or Document Shepherd, in particular, accountable to assert that the submitted draft meets certain protocol quality standards. Now, I suppose that the quality of protocols is somewhat subjective. Nonetheless, its uncomfortable to be held accountable for the quality of a design that you are not able to affect in any way. Bernard raises the example of RFC 5176, which was a "bis" revision of RFC 3576. The former was not the product of any working group, AFAICT, and was not labeled as such when it was published. The RADIUS WG had closed and the RADEXT WG had not yet been conceived. I'm not sure that's an appropriate analogy. I think that we need to be clear in publishing this draft and an RFC that the *protocol* it documents was *not* the work product of the RADEXT WG, but rather of various historic implementors. Truth in advertising. There are some hints at that already. I'll propose some more explicit text as a formal RADEXT Issue. >> Wouldn't it have been possible to use the same Command Code (Server-Status) >> for *both* the query and response, with the context coming from who's doing >> the receiving? I think that would be preferable, in a number of ways. > > RADIUS has traditionally used separate status codes for requests and > replies. Using the same code for both is about as bad (IMHO) as > overloading Access-Accept. I think you're probably right. Sigh. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Jun 14 08:01:46 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4493B3A67F5 for ; Sat, 14 Jun 2008 08:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 glgupshAXzFr for ; Sat, 14 Jun 2008 08:01:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9AD333A685A for ; Sat, 14 Jun 2008 08:01:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7X94-0001uM-KC for radiusext-data@psg.com; Sat, 14 Jun 2008 14:54:22 +0000 Received: from [76.96.30.64] (helo=QMTA07.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7X8e-0001r4-Py for radiusext@ops.ietf.org; Sat, 14 Jun 2008 14:54:07 +0000 Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id do2f1Z0020x6nqcA70Br00; Sat, 14 Jun 2008 14:53:54 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id dqtn1Z00E24Kx1C8Yqto7v; Sat, 14 Jun 2008 14:53:50 +0000 X-Authority-Analysis: v=1.0 c=1 a=yfMLmoq_cvQA:10 a=48vgC7mUAAAA:8 a=0vgF6bZj1rvN9dyvQiYA:9 a=RQHErzDTNkmkmZgdXkaL49PqAH8A:4 a=XF7b4UCPwd8A:10 From: "David B. Nelson" To: Cc: "'Bernard Aboba'" Subject: RADEXT WG meeting at IETF-72 in Dublin Date: Sat, 14 Jun 2008 10:53:47 -0400 Message-ID: <000001c8ce2e$751fe0a0$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjOLnLOw6vZAxwtSX2n8UgCWuHrqA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: The current *draft* schedule for the upcoming IETF-72 meeting is online at: https://datatracker.ietf.org/meeting/72/agenda.html As of today, a 2.5 hour slot has been scheduled for RADEXT to meet on Wednesday morning (0900-1130), July 30, 2008. Please note that the meeting agenda is not yet final and is subject to change. It's not too early to request agenda items for the RADEXT WG meeting. Please send your request to the chairs, indicating the subject, the I-D (if any) and the amount of time requested. Thanks! -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Jun 14 08:41:37 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB6AE3A6A35 for ; Sat, 14 Jun 2008 08:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 HxCON5tzdSGB for ; Sat, 14 Jun 2008 08:41:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A938F3A6A80 for ; Sat, 14 Jun 2008 08:41:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7Xn9-0008Fr-6y for radiusext-data@psg.com; Sat, 14 Jun 2008 15:35:47 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7Xmw-0008CP-FD for radiusext@ops.ietf.org; Sat, 14 Jun 2008 15:35:44 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 103E1123428C; Sat, 14 Jun 2008 17:35:32 +0200 (CEST) Message-ID: <4853E422.9090305@deployingradius.com> Date: Sat, 14 Jun 2008 17:30:42 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document References: <485380D3.9060900@deployingradius.com> <4853CE18.30108@elbrysnetworks.com> In-Reply-To: <4853CE18.30108@elbrysnetworks.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: David B. Nelson wrote: > That makes review of this document in RADEXT a little bit challenging. > We can, of course, polish the prose and make sure that the descriptions > are self-consistent and clear and that the organization is logical. I > guess only those who have access to the "historical implementation" can > discern whether the descriptions are accurate and correct. See ftp://ftp.cistron.nl/pub/radius. Open Source == full access. Version 1.6.5 has the first public implementation of Status-Server. CVS indicates that the change was January 21, by Miquel Van Smoorenburg. FreeRADIUS added support for Status-Server on Oct 17, 2002, "stolen shamelessly from Cistron", according to the commit message. I believe that Radiator also added it around the same time. I don't know which was first, because I don't have access to the Radiator CVS tree. The intent of the document is most definitely *not* to document historical implementations... and leave it at that. The original implementation in Cistron did NOT validate Status-Server packets, so they could be trivially forged. As a result, the document is rather longer than I had originally intended. I expected that simply documenting the practice would be 3-4 pages, at most. Upon writing it, there were a number of loose ends that had to be cleared up, such as security. Hence the additional text. > The IESG, and the IETF at large, hold the WG, in general, and the WG > Chairs and/or Document Shepherd, in particular, accountable to assert > that the submitted draft meets certain protocol quality standards. Now, > I suppose that the quality of protocols is somewhat subjective. > Nonetheless, its uncomfortable to be held accountable for the quality of > a design that you are not able to affect in any way. I expect the WG to complain loudly if there are any problems. This seems to be historical practice in RADEXT. :) Much of the text in the document discusses security issues around the use of Status-Server, and recommended practices. I expect full review of both the security implications and recommended practices. The document is partly about historical implementations. But if those implementations are wrong, the standard should reflect that, and should standardize the correct behavior. e.g. It recommends adding Message-Authenticator to Status-Server, which Cistron did not enforce in 2001, and which FreeRADIUS did not enforce until a few years ago. > I think that we need to be clear in publishing this draft and an RFC > that the *protocol* it documents was *not* the work product of the > RADEXT WG, but rather of various historic implementors. Truth in > advertising. There are some hints at that already. I'll propose some > more explicit text as a formal RADEXT Issue. Thanks. The choice of (some) contents, response packet codes, and use of Status-Server as a "ping" are historical. Much of the rest of the document is discussion surrounding the topic. >> RADIUS has traditionally used separate status codes for requests and >> replies. Using the same code for both is about as bad (IMHO) as >> overloading Access-Accept. > > I think you're probably right. Sigh. I'll add some test to the document to this effect. "Overloading Access-Accept is horrible. RADIUS would normally use something like Ping-Check and Ping-Ack, but implementations exist..." And the charter prevents us from creating more RADIUS codes, so it would have been problematic to create Ping-Check and Ping-Ack now. Overloading Access-Accept seems to make the best of a bad situation. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Jun 14 08:55:37 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD873A6856 for ; Sat, 14 Jun 2008 08:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 ccnIxm7v7unU for ; Sat, 14 Jun 2008 08:55:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 39CA73A67D1 for ; Sat, 14 Jun 2008 08:55:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7Y1L-000ABu-He for radiusext-data@psg.com; Sat, 14 Jun 2008 15:50:27 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7Y12-000AA3-OU for radiusext@ops.ietf.org; Sat, 14 Jun 2008 15:50:14 +0000 Received: (qmail 4484 invoked from network); 14 Jun 2008 11:50:07 -0400 Received: from unknown (HELO ?127.0.0.1?) (172.22.23.1) by gumby.elbrysnetworks.com with SMTP; 14 Jun 2008 11:50:07 -0400 Message-ID: <4853E8AE.4030609@elbrysnetworks.com> Date: Sat, 14 Jun 2008 11:50:06 -0400 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alan DeKok CC: radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document References: <485380D3.9060900@deployingradius.com> <4853CE18.30108@elbrysnetworks.com> <4853E422.9090305@deployingradius.com> In-Reply-To: <4853E422.9090305@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok wrote: > I'll add some text to the document to this effect. "Overloading > Access-Accept is horrible. RADIUS would normally use something like > Ping-Check and Ping-Ack, but implementations exist..." That would help to put the base protocol around Server-Status into historical perspective. > And the charter prevents us from creating more RADIUS codes... Not anymore! :-) Here are the only restrictions in the *revised* charter: In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176. Transport profiles should, if possible, be compatible with RFC 3539. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Jun 14 10:33:04 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A6B3A6A0D for ; Sat, 14 Jun 2008 10:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 Nawa6JzZE3GL for ; Sat, 14 Jun 2008 10:33:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 704D03A6946 for ; Sat, 14 Jun 2008 10:33:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7ZYm-000Npq-Cp for radiusext-data@psg.com; Sat, 14 Jun 2008 17:29:04 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7ZYi-000NpR-UX for radiusext@ops.ietf.org; Sat, 14 Jun 2008 17:29:02 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 85CFB1234298; Sat, 14 Jun 2008 19:28:58 +0200 (CEST) Message-ID: <4853FEB7.3060305@deployingradius.com> Date: Sat, 14 Jun 2008 19:24:07 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document References: <485380D3.9060900@deployingradius.com> <4853CE18.30108@elbrysnetworks.com> <4853E422.9090305@deployingradius.com> <4853E8AE.4030609@elbrysnetworks.com> In-Reply-To: <4853E8AE.4030609@elbrysnetworks.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: David B. Nelson wrote: >> And the charter prevents us from creating more RADIUS codes... > > Not anymore! :-) Here are the only restrictions in the *revised* charter: Temptation... Adding Ping-Check and Ping-Ack would be nice in theory. But given existing implementations, I'm not sure there's any benefit in doing so. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Jun 14 16:11:24 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3893A6AD6 for ; Sat, 14 Jun 2008 16:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1] 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 Be7rNvGokrgR for ; Sat, 14 Jun 2008 16:11:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A24A3A6A8B for ; Sat, 14 Jun 2008 16:11:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7eog-000D4d-Sq for radiusext-data@psg.com; Sat, 14 Jun 2008 23:05:50 +0000 Received: from [218.214.125.86] (helo=zulu.open.com.au) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7eoc-000D47-IC for radiusext@ops.ietf.org; Sat, 14 Jun 2008 23:05:48 +0000 Received: from localhost (localhost [IPv6:::1]) by zulu.open.com.au (Postfix) with ESMTP id 54999A061B; Sun, 15 Jun 2008 09:05:44 +1000 (EST) From: Mike McCauley To: Alan DeKok Subject: Re: Request for Review: Status Server Document Date: Sun, 15 Jun 2008 09:05:43 +1000 User-Agent: KMail/1.8.2 Cc: "David B. Nelson" , radiusext@ops.ietf.org References: <4853CE18.30108@elbrysnetworks.com> <4853E422.9090305@deployingradius.com> In-Reply-To: <4853E422.9090305@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806150905.44022.mikem@open.com.au> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: On Sunday 15 June 2008 01:30, Alan DeKok wrote: > David B. Nelson wrote: > > That makes review of this document in RADEXT a little bit challenging. > > We can, of course, polish the prose and make sure that the descriptions > > are self-consistent and clear and that the organization is logical. I > > guess only those who have access to the "historical implementation" can > > discern whether the descriptions are accurate and correct. > > See ftp://ftp.cistron.nl/pub/radius. Open Source == full access. > > Version 1.6.5 has the first public implementation of Status-Server. > CVS indicates that the change was January 21, by Miquel Van Smoorenburg. > FreeRADIUS added support for Status-Server on Oct 17, 2002, "stolen > shamelessly from Cistron", according to the commit message. > > I believe that Radiator also added it around the same time. I don't > know which was first, because I don't have access to the Radiator CVS tree. Radiator had support for Status-Server from version 1.9 on 20/1/98. -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX etc on Unix, Windows, MacOS, NetWare etc. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Jun 15 00:45:26 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE8E3A68FC for ; Sun, 15 Jun 2008 00:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 EoL8btHYjwGi for ; Sun, 15 Jun 2008 00:45:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0B5203A63C9 for ; Sun, 15 Jun 2008 00:45:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7mq3-000J4t-L5 for radiusext-data@psg.com; Sun, 15 Jun 2008 07:39:47 +0000 Received: from [76.96.30.32] (helo=QMTA03.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7mpz-000J48-B2 for radiusext@ops.ietf.org; Sun, 15 Jun 2008 07:39:45 +0000 Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id e7eB1Z0030FhH24A300H00; Sun, 15 Jun 2008 07:39:41 +0000 Received: from gwzPC ([124.121.211.187]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id e7f91Z001438swU8U7fVyB; Sun, 15 Jun 2008 07:39:39 +0000 X-Authority-Analysis: v=1.0 c=1 a=AwOZdq6U8AYA:10 a=03lizdgfoA4A:10 a=ff9kFAYCkbVVtdfJbXoA:9 a=aelH3kXvWa4_2ynsx9CbI070Q-wA:4 a=r5QHxzKXScQA:10 a=v47ZLdibA2YA:10 From: "Glen Zorn" To: "'Alan DeKok'" Cc: , "'David B. Nelson'" References: <485380D3.9060900@deployingradius.com> <4853CE18.30108@elbrysnetworks.com> <4853E422.9090305@deployingradius.com> <4853E8AE.4030609@elbrysnetworks.com> <4853FEB7.3060305@deployingradius.com> In-Reply-To: <4853FEB7.3060305@deployingradius.com> Subject: RE: Request for Review: Status Server Document Date: Sun, 15 Jun 2008 14:38:34 +0700 Message-ID: <001501c8ceba$db05d2d0$91117870$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcjORLUCxGUYP/aBSEq/Jkajt8aXSQAdaJFA Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok [mailto://aland@deployingradius.com] writes: > David B. Nelson wrote: > >> And the charter prevents us from creating more RADIUS codes... > > > > Not anymore! :-) Here are the only restrictions in the *revised* > charter: > > Temptation... > > Adding Ping-Check and Ping-Ack would be nice in theory. But given > existing implementations, I'm not sure there's any benefit in doing so. Existing implementations or not, RADIUS "ping" is just as wasteful of processing power & bandwidth as it was 10 years ago. A far better idea IMHO is to have the server tell its clients when it recovers from a failure/admin reboot/etc. ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Jun 15 00:55:00 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6638D3A689C for ; Sun, 15 Jun 2008 00:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 mfGTVKzNOU4X for ; Sun, 15 Jun 2008 00:54:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7858F3A687F for ; Sun, 15 Jun 2008 00:54:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7n21-000L1d-12 for radiusext-data@psg.com; Sun, 15 Jun 2008 07:52:09 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7n1x-000L1A-7u for radiusext@ops.ietf.org; Sun, 15 Jun 2008 07:52:07 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id D4A0D1234249; Sun, 15 Jun 2008 09:52:03 +0200 (CEST) Message-ID: <4854C8FF.8030803@deployingradius.com> Date: Sun, 15 Jun 2008 09:47:11 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org, "'David B. Nelson'" Subject: Re: Request for Review: Status Server Document References: <485380D3.9060900@deployingradius.com> <4853CE18.30108@elbrysnetworks.com> <4853E422.9090305@deployingradius.com> <4853E8AE.4030609@elbrysnetworks.com> <4853FEB7.3060305@deployingradius.com> <001501c8ceba$db05d2d0$91117870$@net> In-Reply-To: <001501c8ceba$db05d2d0$91117870$@net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote: > Existing implementations or not, RADIUS "ping" is just as wasteful of > processing power & bandwidth as it was 10 years ago. It's not a "keep-alive". That's bad. It is the watchdog timer recommended in RFC 3539. The draft discusses why using existing RADIUS codes such as Access-Request is not a good idea. It also discusses why it's useful, and why it's not a "keep-alive". > A far better idea IMHO > is to have the server tell its clients when it recovers from a failure/admin > reboot/etc. I agree, mostly. Some complications: - clients don't historically listen on a port for unsolicited RADIUS packets (RFC 5176 is not widely deployed) - clients may be behind NATs or firewalls. The forward path is well tested, deployed, with firewall traversal rules. The backwards path is not. - this would involve defining a new port (maybe), new packet codes (could we re-use Status-Server?), and new behavior. The existing practice has multiple implementations, is widely used, and meets most of the needs for client to server status checking. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Jun 15 02:32:55 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77273A68FC for ; Sun, 15 Jun 2008 02:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=-1.071, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 KI21dIQ9I5WD for ; Sun, 15 Jun 2008 02:32:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6C9E93A687F for ; Sun, 15 Jun 2008 02:32:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7oXi-0006nE-0L for radiusext-data@psg.com; Sun, 15 Jun 2008 09:28:58 +0000 Received: from [198.152.71.100] (helo=de307622-de-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7oXT-0006k9-4M for radiusext@ops.ietf.org; Sun, 15 Jun 2008 09:28:52 +0000 X-IronPort-AV: E=Sophos;i="4.27,647,1204520400"; d="scan'208";a="111312255" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Jun 2008 05:28:39 -0400 X-IronPort-AV: E=Sophos;i="4.27,647,1204520400"; d="scan'208";a="218679782" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Jun 2008 05:28:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Request for Review: Status Server Document Date: Sun, 15 Jun 2008 11:28:36 +0200 Message-ID: In-Reply-To: <4853E422.9090305@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for Review: Status Server Document Thread-Index: AcjONKB44MDqFmiKTKirxjFV1SoB7AAlSHgA References: <485380D3.9060900@deployingradius.com> <4853CE18.30108@elbrysnetworks.com> <4853E422.9090305@deployingradius.com> From: "Romascanu, Dan (Dan)" To: "Alan DeKok" , "David B. Nelson" Cc: Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan, I have a different view.=20 This is what the charter says about this work item:=20 - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. My understanding from the discussions that preceded the rechartering approval was that we are indeed documenting current practices based on implementations and deployment without defining anything new. It's OK (actually more than OK - required) to put text that makes this crystal-clear.=20 If the working group believes that the implementations are wrong it needs to say it clearly in this document. If the WG believes that there need to be fixes in the protocol, it needs to recharter this work item. Actually we can create new RADIUS codes according to the new charter, but not for this work item.=20 Dan > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok > Sent: Saturday, June 14, 2008 6:31 PM > To: David B. Nelson > Cc: radiusext@ops.ietf.org > Subject: Re: Request for Review: Status Server Document >=20 > David B. Nelson wrote: > > That makes review of this document in RADEXT a little bit=20 > challenging. > > We can, of course, polish the prose and make sure that the=20 > > descriptions are self-consistent and clear and that the=20 > organization=20 > > is logical. I guess only those who have access to the "historical=20 > > implementation" can discern whether the descriptions are=20 > accurate and correct. >=20 > See ftp://ftp.cistron.nl/pub/radius. Open Source =3D=3D full = access. >=20 > Version 1.6.5 has the first public implementation of Status-Server. > CVS indicates that the change was January 21, by Miquel Van=20 > Smoorenburg. > FreeRADIUS added support for Status-Server on Oct 17, 2002,=20 > "stolen shamelessly from Cistron", according to the commit message. >=20 > I believe that Radiator also added it around the same time.=20 > I don't know which was first, because I don't have access to=20 > the Radiator CVS tree. >=20 > The intent of the document is most definitely *not* to=20 > document historical implementations... and leave it at that. =20 > The original implementation in Cistron did NOT validate=20 > Status-Server packets, so they could be trivially forged. >=20 > As a result, the document is rather longer than I had=20 > originally intended. I expected that simply documenting the=20 > practice would be 3-4 pages, at most. Upon writing it, there=20 > were a number of loose ends that had to be cleared up, such=20 > as security. Hence the additional text. >=20 > > The IESG, and the IETF at large, hold the WG, in general,=20 > and the WG=20 > > Chairs and/or Document Shepherd, in particular, accountable=20 > to assert=20 > > that the submitted draft meets certain protocol quality standards. =20 > > Now, I suppose that the quality of protocols is somewhat subjective. > > Nonetheless, its uncomfortable to be held accountable for=20 > the quality=20 > > of a design that you are not able to affect in any way. >=20 > I expect the WG to complain loudly if there are any=20 > problems. This seems to be historical practice in RADEXT. :) >=20 > Much of the text in the document discusses security issues=20 > around the use of Status-Server, and recommended practices. =20 > I expect full review of both the security implications and=20 > recommended practices. >=20 > The document is partly about historical implementations. =20 > But if those implementations are wrong, the standard should=20 > reflect that, and should standardize the correct behavior. =20 > e.g. It recommends adding Message-Authenticator to=20 > Status-Server, which Cistron did not enforce in 2001, and=20 > which FreeRADIUS did not enforce until a few years ago. >=20 > > I think that we need to be clear in publishing this draft=20 > and an RFC=20 > > that the *protocol* it documents was *not* the work product of the=20 > > RADEXT WG, but rather of various historic implementors. Truth in=20 > > advertising. There are some hints at that already. I'll=20 > propose some=20 > > more explicit text as a formal RADEXT Issue. >=20 > Thanks. The choice of (some) contents, response packet=20 > codes, and use of Status-Server as a "ping" are historical. =20 > Much of the rest of the document is discussion surrounding the topic. >=20 > >> RADIUS has traditionally used separate status codes for requests=20 > >> and replies. Using the same code for both is about as bad=20 > (IMHO) as=20 > >> overloading Access-Accept. > >=20 > > I think you're probably right. Sigh. >=20 > I'll add some test to the document to this effect. =20 > "Overloading Access-Accept is horrible. RADIUS would=20 > normally use something like Ping-Check and Ping-Ack, but=20 > implementations exist..." >=20 > And the charter prevents us from creating more RADIUS=20 > codes, so it would have been problematic to create Ping-Check=20 > and Ping-Ack now. > Overloading Access-Accept seems to make the best of a bad situation. >=20 > Alan DeKok. >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Jun 15 12:49:37 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3403A67EA for ; Sun, 15 Jun 2008 12:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 tISFlkLg9WfD for ; Sun, 15 Jun 2008 12:49:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8FAAD3A682C for ; Sun, 15 Jun 2008 12:49:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7y99-0003YQ-Ry for radiusext-data@psg.com; Sun, 15 Jun 2008 19:44:15 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K7y95-0003Xi-31 for radiusext@ops.ietf.org; Sun, 15 Jun 2008 19:44:13 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 17DD81234282; Sun, 15 Jun 2008 21:44:09 +0200 (CEST) Message-ID: <48556FE7.9010109@deployingradius.com> Date: Sun, 15 Jun 2008 21:39:19 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document References: <485380D3.9060900@deployingradius.com> <4853CE18.30108@elbrysnetworks.com> <4853E422.9090305@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Romascanu, Dan (Dan) wrote: > My understanding from the discussions that preceded the rechartering > approval was that we are indeed documenting current practices based on > implementations and deployment without defining anything new. It's OK > (actually more than OK - required) to put text that makes this > crystal-clear. The only part of the Status-Server behavior that does not go back to 2001 is the suggestion that it contain a Message-Authenticator attribute. That requirement was added to FreeRADIUS in Feb 2007, before the RADEXT WG discussion on re-chartering. This appears to fall with the "documenting current practices" guidelines. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Jun 15 18:16:49 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57CF53A685C for ; Sun, 15 Jun 2008 18:16:49 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 pJf65BZFN02f for ; Sun, 15 Jun 2008 18:16:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5DE833A67F9 for ; Sun, 15 Jun 2008 18:16:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K83B9-0008ez-LK for radiusext-data@psg.com; Mon, 16 Jun 2008 01:06:39 +0000 Received: from [65.54.246.202] (helo=bay0-omc3-s2.bay0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K83B5-0008eQ-Pl for radiusext@ops.ietf.org; Mon, 16 Jun 2008 01:06:37 +0000 Received: from hotmail.com ([10.4.31.20]) by bay0-omc3-s2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Jun 2008 18:06:31 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 15 Jun 2008 18:06:31 -0700 Message-ID: Received: from 131.107.0.102 by BLU137-DAV10.phx.gbl with DAV; Mon, 16 Jun 2008 01:06:30 +0000 X-Originating-IP: [131.107.0.102] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: "'Alan DeKok'" Cc: References: <485380D3.9060900@deployingradius.com> <4853CE18.30108@elbrysnetworks.com> <4853E422.9090305@deployingradius.com> <48556FE7.9010109@deployingradius.com> In-Reply-To: <48556FE7.9010109@deployingradius.com> Subject: RE: Request for Review: Status Server Document Date: Sun, 15 Jun 2008 18:06:28 -0700 Message-ID: <001d01c8cf4d$34fbd590$9ef380b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjPIPljHhjompzOTriON6OR8Wk57gAKw5rw Content-Language: en-us X-OriginalArrivalTime: 16 Jun 2008 01:06:31.0273 (UTC) FILETIME=[366EED90:01C8CF4D] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok said: " The only part of the Status-Server behavior that does not go back to 2001 is the suggestion that it contain a Message-Authenticator attribute. That requirement was added to FreeRADIUS in Feb 2007, before the RADEXT WG discussion on re-chartering." Wasn't Status-Server first implemented by Ascend Communications in the mid-1990s? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Jun 15 22:18:38 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 159AC3A67FC for ; Sun, 15 Jun 2008 22:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 SKBu4RBtquWq for ; Sun, 15 Jun 2008 22:18:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 110803A67CF for ; Sun, 15 Jun 2008 22:18:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8729-0007FF-2o for radiusext-data@psg.com; Mon, 16 Jun 2008 05:13:37 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8725-0007Et-LY for radiusext@ops.ietf.org; Mon, 16 Jun 2008 05:13:35 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id D5A4212342A2; Mon, 16 Jun 2008 07:13:27 +0200 (CEST) Message-ID: <4855F554.1020206@deployingradius.com> Date: Mon, 16 Jun 2008 07:08:36 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document References: <485380D3.9060900@deployingradius.com> <4853CE18.30108@elbrysnetworks.com> <4853E422.9090305@deployingradius.com> <48556FE7.9010109@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > Wasn't Status-Server first implemented by Ascend Communications in the > mid-1990s? It's certainly possible. I don't recall, and I don't have access to a source tree to check. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 16 08:08:19 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13523A683F for ; Mon, 16 Jun 2008 08:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.97 X-Spam-Level: X-Spam-Status: No, score=-0.97 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 uMCi3HU3k4Ik for ; Mon, 16 Jun 2008 08:08:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D92CF3A682A for ; Mon, 16 Jun 2008 08:08:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8GEF-000PPR-9V for radiusext-data@psg.com; Mon, 16 Jun 2008 15:02:43 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8GDq-000PMQ-Bg for radiusext@ops.ietf.org; Mon, 16 Jun 2008 15:02:32 +0000 Received: (qmail 18252 invoked from network); 16 Jun 2008 11:02:14 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 16 Jun 2008 11:02:14 -0400 From: "David B. Nelson" To: Cc: "'David Harrington'" , "'Bernard Aboba'" References: <20080613021501.F228E3A69ED@core3.amsl.com> Subject: RE: I-D Action:draft-ietf-radext-management-authorization-03.txt Date: Mon, 16 Jun 2008 11:02:14 -0400 Organization: Elbrys Networks, Inc. Message-ID: <2CC84668FF754256BF8B344763BBC412@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080613021501.F228E3A69ED@core3.amsl.com> Thread-Index: AcjM/HXJa+rVnKQxSOiWb39rs4zW1gCwsnfg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-radext-management- > authorization-03.txt I would like to call the WG's attention to this recently posted draft revision. This version addresses WGLC Issues 253-256, as discussed in recent mailing list threads. A summary of the technical (non-editorial) changes is as follows: Section 8.1: Added text describing the use of the Framed-Management-Protocol Attribute by the NAS in Access-Request packets as a "hint", by the server in Access-Accept packets as an expression of the server's policy and by the NAS in Access-Accept packets in the case when the value does not match with the requested access or the NAS's supported protocols. Clarified that "CP" means "RCP" and added "SCP" and "SFTP". Section 8.2: Added text describing the use the Management-Transport-Protection Attribute similar to that described above. Section 9: Fixed some inconsistencies in the examples. Please take a moment to review all of the changes in this revision. Bernard, were you planning to initiate a second WGLC on this draft prior to IETF-72? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 16 13:38:19 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD26E28C150 for ; Mon, 16 Jun 2008 13:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.981 X-Spam-Level: X-Spam-Status: No, score=-0.981 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 lNPALBYq53Vs for ; Mon, 16 Jun 2008 13:38:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF0C128C14A for ; Mon, 16 Jun 2008 13:38:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8LOI-000ANJ-38 for radiusext-data@psg.com; Mon, 16 Jun 2008 20:33:26 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8LNw-000AKq-UA for radiusext@ops.ietf.org; Mon, 16 Jun 2008 20:33:15 +0000 Received: (qmail 25808 invoked from network); 16 Jun 2008 16:33:00 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 16 Jun 2008 16:33:00 -0400 From: "David B. Nelson" To: Subject: RADEXT WG Last Call on "RADIUS Authorization for NAS Management" Date: Mon, 16 Jun 2008 16:32:59 -0400 Organization: Elbrys Networks, Inc. Message-ID: <9B9F3669FCE44E24AFEEC3F456870385@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjP7oMtbwAqQuoxRMaIGZvyuOFXPgAASCaw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Forwarding on behalf of Bernard... (transient e-mail issues) From: bernard_aboba@hotmail.com To: radiusext@ops.ietf.org Subject: RADEXT WG Last Call on "RADIUS Authorization for NAS = Management" Date: Mon, 16 Jun 2008 13:03:40 -0700 This is an announcement of RADEXT WG Last Call on "RADIUS Authorization = for NAS Management" prior to sending it on to the IESG for consideration as = a Proposed Standard. =A0 The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authoriz= ati on-03.txt =A0 WG Last Call will last until June 30, 2008.=A0=A0 Please review the = document and post your comments to the RADEXT WG mailing list = (radiusext@ops.ietf.org) in the format described on the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT/).=A0=A0=20 =A0 If you have read the document and approve of its publication, but have = no comments, please also post this to the list.=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jun 17 15:22:52 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA4E3A6B68 for ; Tue, 17 Jun 2008 15:22:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 b7ZULrqaZCR9 for ; Tue, 17 Jun 2008 15:22:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8613A3A6B72 for ; Tue, 17 Jun 2008 15:22:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8jVN-000Kb4-Pc for radiusext-data@psg.com; Tue, 17 Jun 2008 22:18:21 +0000 Received: from [65.54.246.205] (helo=bay0-omc3-s5.bay0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8jVB-000KZT-Gy for radiusext@ops.ietf.org; Tue, 17 Jun 2008 22:18:19 +0000 Received: from hotmail.com ([10.4.31.13]) by bay0-omc3-s5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Jun 2008 15:18:06 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 17 Jun 2008 15:18:06 -0700 Message-ID: Received: from 131.107.0.102 by BLU137-DAV3.phx.gbl with DAV; Tue, 17 Jun 2008 22:18:04 +0000 X-Originating-IP: [131.107.0.102] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: "'Sanchez, Mauricio \(ProCurve\)'" , References: In-Reply-To: Subject: RE: Request for review of RADIUS Attributes for IEEE 802 Networks Date: Tue, 17 Jun 2008 15:18:03 -0700 Message-ID: <005f01c8d0c8$029efe70$07dcfb50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgmODLyeeG1TRSFS16Yc4EGw4p4CgQuU01gAAAEyGAmdZn3wA== Content-Language: en-us X-OriginalArrivalTime: 17 Jun 2008 22:18:06.0034 (UTC) FILETIME=[04115320:01C8D0C8] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: I also support this document as a RADEXT WG item. -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, Mauricio (ProCurve) Sent: Tuesday, December 04, 2007 7:48 PM To: radiusext@ops.ietf.org Subject: Request for review of RADIUS Attributes for IEEE 802 Networks I support this document as a RADEXT WG item. Cheers, MS > -----Original Message----- > From: owner-radiusext@ops.ietf.org [mailto:owner- > radiusext@ops.ietf.org] On Behalf Of David B. Nelson > Sent: Tuesday, November 13, 2007 1:00 PM > To: radiusext@ops.ietf.org > Subject: Request for review of RADIUS Attributes for IEEE 802 Networks > > The Internet-Draft "RADIUS Attributes for IEEE 802 Networks" was > revised on > July 30, 2007, after incorporating review from the IEEE 802.11 WG. > This > document appears on the RADEXT WG charter as a June 2006 milestone > "WLAN > Attributes draft submitted as a Proposed Standard RFC". It would be > good to > make additional progress on this document. It appears that all the > required > external (i.e. IEEE) review has been completed. > > Please review this draft to determine if it is ready to be taken on as > a > RADEXT WG work item. The draft is to be found at: > > http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-06.txt > > In light of the upcoming IETF-70 meeting, this request for review will > last > until December 7, 2007, i.e. approximately four weeks, including the > IETF > week. > > Please indicate whether you would like this document to be taken on as > a WG > work item. Please respond even if you have no issues with the document. > If > you have comments, please send the issues to the RADEXT WG mailing list > in > the format provided here: > > http://www.drizzle.com/~aboba/RADEXT/ > > Thanks! > > Regards, > > Dave Nelson > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jun 17 15:51:16 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53E53A6B45 for ; Tue, 17 Jun 2008 15:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32dZ10kgNKsC for ; Tue, 17 Jun 2008 15:51:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DC80E3A6B87 for ; Tue, 17 Jun 2008 15:51:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8jwI-000NhZ-Rk for radiusext-data@psg.com; Tue, 17 Jun 2008 22:46:10 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K8jvx-000NfW-Je for radiusext@ops.ietf.org; Tue, 17 Jun 2008 22:45:59 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 8BEDC3A6B45; Tue, 17 Jun 2008 15:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-radsec-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080617224502.8BEDC3A6B45@core3.amsl.com> Date: Tue, 17 Jun 2008 15:45:02 -0700 (PDT) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : TLS encryption for RADIUS over TCP (RadSec) Author(s) : S. Winter, et al. Filename : draft-ietf-radext-radsec-00.txt Pages : 14 Date : 2008-06-17 This document specifies security on the transport layer (TLS) for the RADIUS protocol [2] when transmitted over TCP [9]. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-radsec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-17154328.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 18 10:07:16 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC133A6AF3 for ; Wed, 18 Jun 2008 10:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIkT+n+I+hrr for ; Wed, 18 Jun 2008 10:07:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E58E63A69E8 for ; Wed, 18 Jun 2008 10:07:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K912F-000LRc-3h for radiusext-data@psg.com; Wed, 18 Jun 2008 17:01:27 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K911f-000LOD-Fq for radiusext@ops.ietf.org; Wed, 18 Jun 2008 17:01:11 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 2B31A3A6AF3; Wed, 18 Jun 2008 10:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D ACTION:draft-ietf-radext-status-server-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080618170002.2B31A3A6AF3@core3.amsl.com> Date: Wed, 18 Jun 2008 10:00:02 -0700 (PDT) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol Author(s) : A. DeKok Filename : draft-ietf-radext-status-server-00.txt Pages : 27 Date : 2008-6-17 RFC 2865 defines a Status-Server code for use in RADIUS, but labels it as "Experimental" without further discussion. This document describes a practical use for the Status-Server packet code, which is to let clients query the status of a RADIUS server. These queries, and responses (if any) enable the client to make more informed decisions. The result is a more stable, and more robust RADIUS architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-status-server-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-18095827.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 18 11:09:47 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22BA928C1D7 for ; Wed, 18 Jun 2008 11:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 MK7XftrpeCuV for ; Wed, 18 Jun 2008 11:09:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2248A28C1D3 for ; Wed, 18 Jun 2008 11:09:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K922U-0003au-OB for radiusext-data@psg.com; Wed, 18 Jun 2008 18:05:46 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K922N-0003XS-4U for radiusext@ops.ietf.org; Wed, 18 Jun 2008 18:05:44 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id F401A12342AB for ; Wed, 18 Jun 2008 20:05:35 +0200 (CEST) Message-ID: <48594D46.2050808@deployingradius.com> Date: Wed, 18 Jun 2008 20:00:38 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-radext-status-server-00.txt References: <20080618170002.2B31A3A6AF3@core3.amsl.com> In-Reply-To: <20080618170002.2B31A3A6AF3@core3.amsl.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the RADIUS EXTensions Working Group of the IETF. > > Title : Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol > Author(s) : A. DeKok > Filename : draft-ietf-radext-status-server-00.txt FYI: The only change between this document and draft-dekok-radext-status-server-02.txt is the name, submission date, and expiration date. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 18 13:33:35 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100653A68A5 for ; Wed, 18 Jun 2008 13:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 5JjRHJizeVRT for ; Wed, 18 Jun 2008 13:33:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2733F3A6897 for ; Wed, 18 Jun 2008 13:33:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K94H3-000Ldi-0X for radiusext-data@psg.com; Wed, 18 Jun 2008 20:28:57 +0000 Received: from [158.64.1.34] (helo=legolas.restena.lu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1K94Gy-000Lcw-8q for radiusext@ops.ietf.org; Wed, 18 Jun 2008 20:28:54 +0000 Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 9B11F3027249 for ; Wed, 18 Jun 2008 22:28:50 +0200 (CEST) Received: from [158.64.15.131] (unknown [158.64.15.131]) by legolas.restena.lu (Postfix) with ESMTP id 498C93027235 for ; Wed, 18 Jun 2008 22:28:50 +0200 (CEST) Message-ID: <48597046.1090402@restena.lu> Date: Wed, 18 Jun 2008 22:29:58 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: I-D Action:draft-ietf-radext-radsec-00.txt References: <20080617224502.8BEDC3A6B45@core3.amsl.com> In-Reply-To: <20080617224502.8BEDC3A6B45@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Internet-Drafts@ietf.org schrieb: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the RADIUS EXTensions Working Group of the IETF. > > > Title : TLS encryption for RADIUS over TCP (RadSec) > Author(s) : S. Winter, et al. > Filename : draft-ietf-radext-radsec-00.txt > Pages : 14 > Date : 2008-06-17 > > This document specifies security on the transport layer (TLS) for the > RADIUS protocol [2] when transmitted over TCP [9]. This enables > dynamic trust relationships between RADIUS servers. > > This document has the TCP transport part chopped out, as that part goes into a separate document. The according reference [9] will come into existence in the coming weeks. Apart from that, the title, abstract, some sections in the main body were updated to reflect the splitting. No real content changes in it. Greetings, Stefan Winter -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Jun 21 09:53:57 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB4303A6986 for ; Sat, 21 Jun 2008 09:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.802 X-Spam-Level: X-Spam-Status: No, score=-99.802 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcEut-7p-CoI for ; Sat, 21 Jun 2008 09:53:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB23B3A6980 for ; Sat, 21 Jun 2008 09:53:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KA6Fj-000Mjp-2s for radiusext-data@psg.com; Sat, 21 Jun 2008 16:47:51 +0000 Received: from [202.99.23.227] (helo=people.com.cn) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KA6FW-000Mgw-3e for radiusext@ops.ietf.org; Sat, 21 Jun 2008 16:47:40 +0000 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm109485d7932; Sun, 22 Jun 2008 01:02:33 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm6948589bcc; Wed, 18 Jun 2008 07:01:52 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 18 Jun 2008 07:01:52 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5383028C1BE; Tue, 17 Jun 2008 15:45:21 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8BEDC3A6B45; Tue, 17 Jun 2008 15:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-radext-radsec-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080617224502.8BEDC3A6B45@core3.amsl.com> Date: Tue, 17 Jun 2008 15:45:02 -0700 (PDT) Cc: radiusext@ops.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : TLS encryption for RADIUS over TCP (RadSec) Author(s) : S. Winter, et al. Filename : draft-ietf-radext-radsec-00.txt Pages : 14 Date : 2008-06-17 This document specifies security on the transport layer (TLS) for the RADIUS protocol [2] when transmitted over TCP [9]. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-radsec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-17154328.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 23 22:08:47 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D6D028C0D0 for ; Mon, 23 Jun 2008 22:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 3jMEwOW1Z6uE for ; Mon, 23 Jun 2008 22:08:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 182E828C0CE for ; Mon, 23 Jun 2008 22:08:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KB0gt-000Bd8-Dn for radiusext-data@psg.com; Tue, 24 Jun 2008 05:03:39 +0000 Received: from [63.208.196.178] (helo=mho-01-bos.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KB0gh-000BbW-Ct for radiusext@ops.ietf.org; Tue, 24 Jun 2008 05:03:37 +0000 Received: from c-24-16-124-122.hsd1.mn.comcast.net ([24.16.124.122] helo=internaut.com) by mho-01-bos.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1KB0gg-000A90-EJ for radiusext@ops.ietf.org; Tue, 24 Jun 2008 05:03:26 +0000 Received: by internaut.com (Postfix, from userid 1001) id 86FD570C83; Mon, 23 Jun 2008 22:03:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 7969770B40 for ; Mon, 23 Jun 2008 22:03:25 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.124.122 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+4hakLWgO4IUvb9Wpa53Zy Date: Mon, 23 Jun 2008 22:03:25 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: REMINDER: WG Last call in progress: RADIUS Authorization for NAS Management Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a reminder of RADEXT WG Last Call on "RADIUS Authorization for NAS Management" prior to sending it on to the IESG for consideration as a Proposed Standard. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-03.txt WG Last Call will last until June 30, 2008. Please review the document and post your comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format described on the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT/). If you have read the document and approve of its publication, but have no comments, please also post this to the list. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 23 22:08:49 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2A03A6883 for ; Mon, 23 Jun 2008 22:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.518 X-Spam-Level: X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=3.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yd4SPt9xHvN7 for ; Mon, 23 Jun 2008 22:08:48 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 5605F3A6836 for ; Mon, 23 Jun 2008 22:08:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KB0f3-000BR6-3Y for radiusext-data@psg.com; Tue, 24 Jun 2008 05:01:45 +0000 Received: from [63.208.196.179] (helo=mho-02-bos.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KB0ez-000BQQ-LO for radiusext@ops.ietf.org; Tue, 24 Jun 2008 05:01:43 +0000 Received: from c-24-16-124-122.hsd1.wa.comcast.net ([24.16.124.122] helo=internaut.com) by mho-02-bos.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1KB0ey-000Hsf-LF for radiusext@ops.ietf.org; Tue, 24 Jun 2008 05:01:40 +0000 Received: by internaut.com (Postfix, from userid 1001) id 23C8E70C83; Mon, 23 Jun 2008 22:01:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 1968070B40 for ; Mon, 23 Jun 2008 22:01:39 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.124.122 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18hkgUZkBo2HvD62fE33joT Date: Mon, 23 Jun 2008 22:01:39 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Call for Agenda Items for IETF 72 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a call for agenda items for the RADEXT WG meeting at IETF 72 in Dublin. The meeting is tentatively scheduled for Wednesday, July 30, 2008 from 9 AM - 11:30 AM. If you have an item you'd like to put on the agenda, please contact myself (Bernard_Aboba@hotmail.com) or Dave. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jun 24 07:39:10 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15203A69FA for ; Tue, 24 Jun 2008 07:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 fmnXNyo89itV for ; Tue, 24 Jun 2008 07:39:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 73D3A3A68E8 for ; Tue, 24 Jun 2008 07:39:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KB9YJ-000I4U-N4 for radiusext-data@psg.com; Tue, 24 Jun 2008 14:31:23 +0000 Received: from [63.208.196.179] (helo=mho-02-bos.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KB9YB-000I3I-Rl for radiusext@ops.ietf.org; Tue, 24 Jun 2008 14:31:21 +0000 Received: from c-24-16-124-122.hsd1.wa.comcast.net ([24.16.124.122] helo=internaut.com) by mho-02-bos.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1KB9Y9-0000En-Qw for radiusext@ops.ietf.org; Tue, 24 Jun 2008 14:31:14 +0000 Received: by internaut.com (Postfix, from userid 1001) id D03B870C83; Tue, 24 Jun 2008 07:31:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id C566A70B5C for ; Tue, 24 Jun 2008 07:31:11 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.124.122 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+oq3S6rFQgVMpi625b1zuG Date: Tue, 24 Jun 2008 07:31:11 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Editorial review of draft-ietf-radext-management-authorization-03.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Abstract This document describes Remote Authentication Dial-In User Service (RADIUS) attributes for the authorization and service provisioning of Network Access Servers (NASes). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via framed management protocols, and for specification of a protected transport protocol. [BA] This document is about NAS management authorization, not authorization of NASes. Suggest the following: This document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for Network Access Server (NAS) management. Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via framed management protocols, which may run over a secure transport protocol. 2. Introduction and Rationale [BA] How about combining Sections 2, part of 3 and 6 into a Section 1 that reads as follows? The Terminology section can then be Section 1.1. 1. Introduction RFC 2865 [RFC 2865] defines the NAS-Prompt and Administrative values of the Service-Type Attribute. Both of these values provide access to the interactive, text-based Command Line Interface (CLI) of the NAS, and were originally developed to control access to the physical console port of the NAS, most often a serial port. Remote access to the CLI of the NAS has been available in NAS implementations for many years, using protocols such as Telnet, Rlogin and the remote terminal service of SSH. In order to distinguish local, physical, console access from remote access, the NAS-Port-Type Attribute is generally included in Access-Request and Access-Accept messages, along with the Service-Type Attribute, to indicate the form of access. A NAS-Port-Type of Async (0) is used to signify a local serial port connection, while a value of Virtual (5) is used to signify a remote connection, via a remote terminal protocol. This usage provides no selectivity among the various available remote terminal protocols (e.g. Telnet, Rlogin, SSH, etc.). Today, it is common for network devices to support more than two privilege levels for management access than just NAS-Prompt (non-privileged) and Administrative (privileged). Also, other management mechanisms may be used, such as Web-based management, Simple Network Management Protocol (SNMP) and NETCONF. To provide support for these additional features, this specification defines attributes for framed management protocols, management protocol security, and management access privilege levels. Remote management via the command line is carried over protocols such as Telnet, Rlogin and the remote terminal service of SSH. Since these protocols are primarily for the delivery of terminal or pseudo-TTY services, the term "Framed Management" is used to describe management protocols supporting techniques other than the command-line. Typically these mechanisms format management information in a binary or textual encoding such as HTML, XML or ASN.1/BER. Examples include web-based management (HTML over HTTP or HTTPS), NETCONF (XML over SSH/BEEP/SOAP) and SNMP (SMI over ASN.1/BER). Command line interface, menu interface or other text-based (e.g. ASCII or UTF-8) terminal emulation services are not considered to be Framed Management protocols. [BA] How about combining part of Section 3, as well as 4, 5 and 6 into a Section 2 that reads as follows? 2. Overview To support the authorization and provisioning of Framed Management access to managed entities, this document introduces a new value for the Service-Type Attribute [RFC2865], and one new attribute. The new value for the Service-Type Attribute is Framed-Management, used for remote device management via a Framed Management Protocol. The new attribute is Framed-Management-Protocol, the value of which specifies a particular protocol for use in the remote management session. Two new attributes are introduced in this document in support of granular management access rights or command privilege levels. The Management-Policy-Id Attribute provides a text string specifying a policy name of local scope, that is assumed to have been pre-provisioned on the NAS. This use of an attribute to specify use of a pre-provisioned policy is similar to the Filter-Id Attribute defined in [RFC2865] Section 5.11. The local application of the Management-Policy-Id within the managed entity may take the form of (a) one of an enumeration of command privilege levels, (b) a mapping into an SNMP Access Control Model, such as the View Based Access Control Model (VACM) [RFC3415], or (c) some other set of management access policy rules that is mutually understood by the managed entity and the remote management application. Examples are given in Section X. The Management-Privilege-Level Attribute contains an integer-valued management privilege level indication. This attribute serves to modify or augment the management permissions provided by the NAS-Prompt value of the Service-Type Attribute, and thus applies to CLI management. To enable management security requirements to be specified, the Management-Transport-Protection Attribute is introduced. The value of this attribute indicates the minimum level of secure transport protocol protection required for the provisioning of NAS-Prompt, Administrative or Framed-Management service. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jun 24 08:14:48 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6B8C3A6A1E for ; Tue, 24 Jun 2008 08:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 nMfpKEcThdc8 for ; Tue, 24 Jun 2008 08:14:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 72F383A6A2C for ; Tue, 24 Jun 2008 08:14:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBA8D-000MKO-B0 for radiusext-data@psg.com; Tue, 24 Jun 2008 15:08:29 +0000 Received: from [63.208.196.179] (helo=mho-02-bos.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBA81-000MJ6-MC for radiusext@ops.ietf.org; Tue, 24 Jun 2008 15:08:19 +0000 Received: from c-24-16-124-122.hsd1.mn.comcast.net ([24.16.124.122] helo=internaut.com) by mho-02-bos.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1KBA7z-000B41-Ur for radiusext@ops.ietf.org; Tue, 24 Jun 2008 15:08:16 +0000 Received: by internaut.com (Postfix, from userid 1001) id 85AEF70C83; Tue, 24 Jun 2008 08:08:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 7A75E70B40 for ; Tue, 24 Jun 2008 08:08:14 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.124.122 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/5UiH1a9auwEkWKpyqRmaO Date: Tue, 24 Jun 2008 08:08:14 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Additional comments on draft-ietf-radext-management-authorization-03.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Section 8.1 "Service-Type of Framed-Management" -> "Service-Type Attribute with the value Framed-Management" "in Access-Request packet" -> "in an Access-Request packet" "MAY use these hint attributes" -> "may use these attributes as a hint" "MUST treat the response" -> "MUST treat the Access-Accept" "http://www.w3.org/TR/html": Please add this to the reference section, and refer to it in Section 8.1. "(http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13)" Please add this in the reference section. RCP: Can you add a reference? SCP: Please add a reference (doesn't this also use the services of SSH?) Section 8.2 The Management-Transport-Protection Attribute specifies whether a secure transport protocol (e.g. SSH, TLS, DTLS, etc.) is required for use with the associated framed or non-framed management access session. The value of this attribute specifies the minimum level of protection that is required from the protected transport. The protected transport MAY provide a greater level of protection than is called for by the value of Management-Transport-Protection. [BA] The second sentence is more on target. How about this? The Management-Transport-Protection Attribute specifies the minimum level of protection that is required for a protected transport used with the framed or non-framed management access session. The protected transport used by the NAS MAY provide a greater level of protection, but MUST NOT provide a lower level of protection. "in Access-Request packet" -> "in an Access-Request packet" "RADIUS Client" -> "RADIUS clent" "RADIUS Server" -> "RADIUS server" "MAY use this hint attribute" -> "may use this attribute as a hint" Section 8.3 "application to SMNP services" -> "SNMP" "NAS behavior in such cases is not predictable." -> "The behavior of the NAS in this case is undefined." "a single service provisioning message, such as" -> "an Access-Accept or CoA-Request". ", within a flat namespace of significance to the NAS" [BA] Are you saying that "." can't be used? Can this be deleted? "Overloading or subdividing this flat name with" -> "Overloading or subdividing this attribute with" "If a simple flat policy name" -> "If a simple policy name" "sufficient to the anticipated use case" -> "sufficient" Section 12 Within the document, the CoA-Request is mentioned, but the table does not describe which attributes can be included in CoA or Disconnect Request, ACK or NAK packets. Is it accurate to assume that none of the attributes defined in this document can be contained in a CoA or Disconnect packet? Section 14 Any of the attributes described in this memo, with the exception of Service-Type, may not be understood by the NAS which receives it. A legacy NAS not compliant with this specification may silently discard these attributes while permitting the user to access the management interface(s) of the NAS. This can lead to users improperly receiving unauthorized management access to the NAS, or access with greater levels of access rights than were intended. RADIUS servers SHOULD attempt to ascertain whether or not the NAS supports these attributes before sending them in an Access-Accept. [BA] This paragraph could be more clear. There are really two cases. When a Service-Type value of Framed-Management is used, I'd assume that a NAS implementing this specification would be required to behave as specified (e.g. treat the Access-Accept as an Access-Reject if the attribute or value wasn't supported). I think that an issue could occur when a legacy Service-Type value is used though, since then the NAS might ignore the new attributes instead of treating the Access-Accept like an Access-Reject. I don't think you need to talk about the potential behavior of an implementation that claims to conform to the spec, but doesn't do what it says. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jun 24 11:32:57 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48923A68D3 for ; Tue, 24 Jun 2008 11:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 knOxNvzBOhDw for ; Tue, 24 Jun 2008 11:32:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF05F3A6986 for ; Tue, 24 Jun 2008 11:32:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBDFe-000JLu-W6 for radiusext-data@psg.com; Tue, 24 Jun 2008 18:28:22 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBDFW-000JLF-Ad for radiusext@ops.ietf.org; Tue, 24 Jun 2008 18:28:16 +0000 Received: (qmail 954 invoked from network); 24 Jun 2008 14:28:10 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 24 Jun 2008 14:28:10 -0400 From: "David B. Nelson" To: Cc: "'Bernard Aboba'" References: Subject: RE: Additional comments on draft-ietf-radext-management-authorization-03.txt Date: Tue, 24 Jun 2008 14:28:05 -0400 Organization: Elbrys Networks, Inc. Message-ID: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjWDNpFBM9lW8yqTripxrKpZlc0EgAGgyiA In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Skipping over most of the editorial issues for now, I'll highlight the items for which I need assistance from the list members. > "http://www.w3.org/TR/html": Please add this to the reference > section, and refer to it in Section 8.1. I'll have to figure out how to manually craft reference anchors in xml2rfc, but I think this can be done. > "(http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13)" > Please add this in the reference section. Ditto. > RCP: Can you add a reference? I'd have to find a suitable one. :-) Can someone help me out here? All I can find is UNIX/LINUX man pages references. Can someone point me to a suitable, stable reference that can be included in an I-D / RFC? > SCP: Please add a reference... Ditto. Need assistance here, too. > ...(doesn't this also use the services of SSH?) AFAIK, it does not. You may be thinking of SFTP, (SSH File Transfer Protocol, which does.) Can anyone clarify this? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 25 02:50:38 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F2428C0EF for ; Wed, 25 Jun 2008 02:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[AWL=-1.440, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] 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 Hlo8NxjLdHO6 for ; Wed, 25 Jun 2008 02:50:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A80093A6876 for ; Wed, 25 Jun 2008 02:50:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBRYa-0002nn-Hv for radiusext-data@psg.com; Wed, 25 Jun 2008 09:44:52 +0000 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBRYS-0002mO-QY for radiusext@ops.ietf.org; Wed, 25 Jun 2008 09:44:50 +0000 Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 497A1C004B; Wed, 25 Jun 2008 11:44:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ISgDD-hj1Wme; Wed, 25 Jun 2008 11:44:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 75FC9C003D; Wed, 25 Jun 2008 11:44:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DD9225DE46F; Wed, 25 Jun 2008 11:44:33 +0200 (CEST) Date: Wed, 25 Jun 2008 11:44:33 +0200 From: Juergen Schoenwaelder To: "David B. Nelson" Cc: radiusext@ops.ietf.org, 'Bernard Aboba' Subject: Re: Additional comments on draft-ietf-radext-management-authorization-03.txt Message-ID: <20080625094433.GA28919@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: "David B. Nelson" , radiusext@ops.ietf.org, 'Bernard Aboba' References: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: On Tue, Jun 24, 2008 at 02:28:05PM -0400, David B. Nelson wrote: > > RCP: Can you add a reference? > > I'd have to find a suitable one. :-) Can someone help me out here? All I > can find is UNIX/LINUX man pages references. Can someone point me to a > suitable, stable reference that can be included in an I-D / RFC? You probably have to reference some 4.2BSD software documentation. There might be something suitable in the classic BSD daemon books, I unfortunately do not have access to these classics anymore. > > SCP: Please add a reference... > > Ditto. Need assistance here, too. > > > ...(doesn't this also use the services of SSH?) > > AFAIK, it does not. You may be thinking of SFTP, (SSH File Transfer > Protocol, which does.) Can anyone clarify this? The scp program is a simple wrapper around ssh. The first comment in the scp.c source file (openssh) says: * scp - secure remote copy. This is basically patched BSD rcp which * uses ssh to do the data transfer (instead of using rcmd). Finding official stable documentation for this will be difficult I assume. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 25 03:05:53 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C630928C0EF for ; Wed, 25 Jun 2008 03:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxKICkUJehHZ for ; Wed, 25 Jun 2008 03:05:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D8C673A69FF for ; Wed, 25 Jun 2008 03:05:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBRnX-0004MR-F4 for radiusext-data@psg.com; Wed, 25 Jun 2008 10:00:19 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBRnJ-0004Ku-28 for radiusext@ops.ietf.org; Wed, 25 Jun 2008 10:00:13 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 0E9FA28C106; Wed, 25 Jun 2008 03:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-design-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080625100002.0E9FA28C106@core3.amsl.com> Date: Wed, 25 Jun 2008 03:00:02 -0700 (PDT) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Design Guidelines Author(s) : G. Weber, et al. Filename : draft-ietf-radext-design-03.txt Pages : 31 Date : 2008-06-25 This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-design-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-25025633.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 25 06:52:01 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115183A69EC for ; Wed, 25 Jun 2008 06:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 MLjs+Gznivzj for ; Wed, 25 Jun 2008 06:51:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C43C3A6848 for ; Wed, 25 Jun 2008 06:51:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBVK5-000305-U5 for radiusext-data@psg.com; Wed, 25 Jun 2008 13:46:09 +0000 Received: from [76.96.30.40] (helo=QMTA04.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBVJt-0002yZ-MZ for radiusext@ops.ietf.org; Wed, 25 Jun 2008 13:46:00 +0000 Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id iDjZ1Z0010cQ2SLA401200; Wed, 25 Jun 2008 13:45:56 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id iDlm1Z00r24Kx1C8WDlnWY; Wed, 25 Jun 2008 13:45:49 +0000 X-Authority-Analysis: v=1.0 c=1 a=HWwVVMiTGj4A:10 a=m4smBwC4wFAA:10 a=lzrO2PTS8S_xfVoD5m0A:9 a=pHlWDivioNLn_WpnHwEOtNb-iS4A:4 a=MxZ3bB5I4kYA:10 From: "David B. Nelson" To: Cc: References: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2> <20080625094433.GA28919@elstar.local> Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt Date: Wed, 25 Jun 2008 09:45:48 -0400 Message-ID: <015101c8d6c9$c8272bc0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080625094433.GA28919@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjWqMniqm/ACsB6TFezWcamBUG+dAAIHRUg Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > You probably have to reference some 4.2BSD software documentation. > There might be something suitable in the classic BSD daemon books, I > unfortunately do not have access to these classics anymore. Nor do I, but that's an idea for me to pursue. Thanks. > The scp program is a simple wrapper around ssh. So, that leads me to ask what's the difference between SCP and SFTP? > Finding official stable documentation for this will be difficult I > assume. That's what I was afraid of... :-( -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 25 08:56:53 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0E7328C0E8 for ; Wed, 25 Jun 2008 08:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.492 X-Spam-Level: X-Spam-Status: No, score=-0.492 tagged_above=-999 required=5 tests=[AWL=-1.242, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RDNS_NONE=0.1] 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 WBmjbcEEeAQ2 for ; Wed, 25 Jun 2008 08:56:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9F1FC28C0E5 for ; Wed, 25 Jun 2008 08:56:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBXGp-000Gla-6a for radiusext-data@psg.com; Wed, 25 Jun 2008 15:50:55 +0000 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBXGa-000Gjm-IS for radiusext@ops.ietf.org; Wed, 25 Jun 2008 15:50:49 +0000 Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8693C0058; Wed, 25 Jun 2008 17:50:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4g3arbtl-vXZ; Wed, 25 Jun 2008 17:50:28 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD143C0031; Wed, 25 Jun 2008 17:50:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 246DD5DEFEA; Wed, 25 Jun 2008 17:50:27 +0200 (CEST) Date: Wed, 25 Jun 2008 17:50:27 +0200 From: Juergen Schoenwaelder To: "David B. Nelson" Cc: radiusext@ops.ietf.org Subject: Re: Additional comments ondraft-ietf-radext-management-authorization-03.txt Message-ID: <20080625155027.GA29447@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: "David B. Nelson" , radiusext@ops.ietf.org References: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2> <20080625094433.GA28919@elstar.local> <015101c8d6c9$c8272bc0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015101c8d6c9$c8272bc0$6401a8c0@NEWTON603> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: On Wed, Jun 25, 2008 at 09:45:48AM -0400, David B. Nelson wrote: > So, that leads me to ask what's the difference between SCP and SFTP? SFTP is really pretty much like FTP in the sense that it provides a protocol allowing you to send commands from a rather rich set of primitives to an SFTP server that are then executed by the server. Scp is much simpler and usually does just one thing, namely transferring files. With SFTP, you can implement a filesystem that allows to mount an SFTP server. This won't really work with scp since you lack primitives to read directories, to create, modify or delete directories, to handle symbolic links, to play with file attributes and so on. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 25 12:03:03 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042AF3A6ADC for ; Wed, 25 Jun 2008 12:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 FMj65P7rixZU for ; Wed, 25 Jun 2008 12:03:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B3C33A6A9A for ; Wed, 25 Jun 2008 12:02:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBaAp-0009rC-3r for radiusext-data@psg.com; Wed, 25 Jun 2008 18:56:55 +0000 Received: from [63.208.196.179] (helo=mho-02-bos.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBaAc-0009pA-S3 for radiusext@ops.ietf.org; Wed, 25 Jun 2008 18:56:44 +0000 Received: from c-24-16-124-122.hsd1.mn.comcast.net ([24.16.124.122] helo=internaut.com) by mho-02-bos.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1KBaAb-000CVI-41 for radiusext@ops.ietf.org; Wed, 25 Jun 2008 18:56:41 +0000 Received: by internaut.com (Postfix, from userid 1001) id 5DDAA70C61; Wed, 25 Jun 2008 11:56:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 53E6470B37 for ; Wed, 25 Jun 2008 11:56:40 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.124.122 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+BVyp7sOW2WLljK9oEiIER Date: Wed, 25 Jun 2008 11:56:40 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT WG Last Call on RADIUS Design Guidelines Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is an announcement of RADEXT WG Last Call on "RADIUS Design Guidelines" prior to requesting that the IESG publish it as a Best Current Practice RFC. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-03.txt WG Last Call will last until July 10, 2008. Please review the document and post your comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format described on the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT/). If you have read the document and approve of its publication, but have no comments, please also post this to the list. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jun 25 12:23:41 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C89253A6817 for ; Wed, 25 Jun 2008 12:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.053 X-Spam-Level: X-Spam-Status: No, score=-1.053 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] 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 AHC-D2-izMQP for ; Wed, 25 Jun 2008 12:23:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B4EF73A6A32 for ; Wed, 25 Jun 2008 12:23:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBaWJ-000CVA-RY for radiusext-data@psg.com; Wed, 25 Jun 2008 19:19:07 +0000 Received: from [63.208.196.179] (helo=mho-02-bos.mailhop.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBaVx-000CST-SY for radiusext@ops.ietf.org; Wed, 25 Jun 2008 19:18:57 +0000 Received: from c-24-16-124-122.hsd1.wa.comcast.net ([24.16.124.122] helo=internaut.com) by mho-02-bos.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1KBaVw-000Jq5-77 for radiusext@ops.ietf.org; Wed, 25 Jun 2008 19:18:44 +0000 Received: by internaut.com (Postfix, from userid 1001) id 7EC7C70C61; Wed, 25 Jun 2008 12:18:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 73AB570B37 for ; Wed, 25 Jun 2008 12:18:43 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.124.122 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX182XjakARWq+q1zy4GrpbJw Date: Wed, 25 Jun 2008 12:18:43 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 259: Extended Type Field Length Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Issue 259: Extended Type Field Length Submitter name: Bernard Aboba Submitter email address: Bernard_Aboba@hotmail.com Date first submitted: June 25, 2008 Reference: http://ops.ietf.org/lists/radiusext/2008/msg00321.html Document: http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-03.txt Comment type: Technical Priority: S Section: 5 Rationale/Explanation of issue: The -03 version of this document contains the following TLV format: 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Type | Ext-Len | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ However, the RADEXT WG Consensus from IETF 71, and as confirmed on the RADEXT WG mailing list, was that the Ext-Type field should be 2 octets in length, not 1. Also, the Consensus of the WG was that Extended Attributes would not be applied to existing RADIUS standard attributes. Here is the summary of the Consensus Call Determination: http://ops.ietf.org/lists/radiusext/2008/msg00321.html -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Jun 26 14:39:54 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F5B3A6801 for ; Thu, 26 Jun 2008 14:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 DdUDiaCCLWPL for ; Thu, 26 Jun 2008 14:39:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EA7753A67D0 for ; Thu, 26 Jun 2008 14:39:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBz6E-000O2g-Jk for radiusext-data@psg.com; Thu, 26 Jun 2008 21:33:50 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KBz6B-000O24-1H for radiusext@ops.ietf.org; Thu, 26 Jun 2008 21:33:48 +0000 Received: (qmail 3474 invoked from network); 26 Jun 2008 17:33:43 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 26 Jun 2008 17:33:43 -0400 From: "David B. Nelson" To: References: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2> <20080625094433.GA28919@elstar.local> Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt Date: Thu, 26 Jun 2008 17:33:30 -0400 Organization: Elbrys Networks, Inc. Message-ID: <926FE7320FEE492E820F30E7D053C36E@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjWqBjcX9Y3RWDZQwe1oKjYZIXyNgBKopew In-Reply-To: <20080625094433.GA28919@elstar.local> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > You probably have to reference some 4.2BSD software documentation. > There might be something suitable in the classic BSD daemon books, I > unfortunately do not have access to these classics anymore. I've been searching for a stable reference that discusses rcp, scp and sftp. Certainly, the man pages of many UNIX-style systems, but I don't think that qualifies as a "stable reference" for RFC purposes. I've "found" one book in my web searches that seems to cover the material (although I don't actually have a copy). It is as follows: Section 3.7 SSH and File Transfers in SSH, the Secure Shell: The Definitive Guide, Second Edition D. Barrett, R. Silverman, R. Byrnes O'Reilly and Associates, May 2005 If anyone has a better reference to cite, to close the issue raised by Barnard, please let me know. Thanks! If I don't "get a better offer" I propose to use this reference for RCP, SCP and SFTP. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Jun 28 21:07:08 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199FB3A6875 for ; Sat, 28 Jun 2008 21:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.357 X-Spam-Level: X-Spam-Status: No, score=-99.357 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRWKd0UMI+QF for ; Sat, 28 Jun 2008 21:07:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 161823A67EA for ; Sat, 28 Jun 2008 21:07:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCo6y-000JWR-2N for radiusext-data@psg.com; Sun, 29 Jun 2008 04:02:00 +0000 Received: from [202.99.23.227] (helo=people.com.cn) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KCo6l-000JV5-3E for radiusext@ops.ietf.org; Sun, 29 Jun 2008 04:01:58 +0000 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm448670dec; Sun, 29 Jun 2008 12:16:48 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm048629874; Wed, 25 Jun 2008 18:16:23 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 25 Jun 2008 18:16:21 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4731828C120; Wed, 25 Jun 2008 03:00:04 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0E9FA28C106; Wed, 25 Jun 2008 03:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-radext-design-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080625100002.0E9FA28C106@core3.amsl.com> Date: Wed, 25 Jun 2008 03:00:02 -0700 (PDT) Cc: radiusext@ops.ietf.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Design Guidelines Author(s) : G. Weber, et al. Filename : draft-ietf-radext-design-03.txt Pages : 31 Date : 2008-06-25 This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-design-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-25025633.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 30 02:07:38 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E753A6A9A for ; Mon, 30 Jun 2008 02:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] 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 ItM0EKM4AkCV for ; Mon, 30 Jun 2008 02:07:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0CE983A6A89 for ; Mon, 30 Jun 2008 02:07:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDFFk-0001QL-7D for radiusext-data@psg.com; Mon, 30 Jun 2008 09:00:52 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDFFd-0001PO-2b for radiusext@ops.ietf.org; Mon, 30 Jun 2008 09:00:47 +0000 X-IronPort-AV: E=Sophos;i="4.27,726,1204498800"; d="scan'208";a="13007760" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jun 2008 11:00:41 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5U90eYj012814; Mon, 30 Jun 2008 11:00:40 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5U90e4I008526; Mon, 30 Jun 2008 09:00:40 GMT Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 11:00:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Call for Agenda Items for IETF 72 Date: Mon, 30 Jun 2008 10:58:10 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for Agenda Items for IETF 72 Thread-Index: AcjVt6BR+cXCkG4pS+m03+ehrMl8lQE1mw4A References: From: "Benoit Lourdelet (blourdel)" To: "Bernard Aboba" , , Cc: "Richard Gayraud (rgayraud)" X-OriginalArrivalTime: 30 Jun 2008 09:00:40.0848 (UTC) FILETIME=[C57C1100:01C8DA8F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1039; t=1214816440; x=1215680440; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20 |Subject:=20RE=3A=20Call=20for=20Agenda=20Items=20for=20IET F=2072 |Sender:=20; bh=XyrWvjc/OU5zIKIniBq6gDYfXjBEuGccjA+Lfu0UsWY=; b=Fa4I2a2ep3oLy4G6oQDpfdRfkhbMGfrc5hbYkIh+Fihxd/mR+m/5yvOeik r2mcEhlX4ZTW/0k53xfkc+q1OLn1fWUxepGaf7yIpTKT89ioyuhiGMM4mLbf 8RumwG1Mmk; Authentication-Results: ams-dkim-2; header.From=blourdel@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hello, I'd like a 10 min slot to discuss the following draft :=20 http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-00. txt As it includes RADIUS and DHCP concepts, It would request a slots in DHC and RADEXT groups if that is the commonly accepted procedure. Regards Benoit -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, June 24, 2008 7:02 AM To: radiusext@ops.ietf.org Subject: Call for Agenda Items for IETF 72 This is a call for agenda items for the RADEXT WG meeting at IETF 72 in Dublin. The meeting is tentatively scheduled for Wednesday, July 30, 2008 from 9 AM - 11:30 AM. =20 If you have an item you'd like to put on the agenda, please contact myself (Bernard_Aboba@hotmail.com) or Dave.=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 30 03:25:04 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10CA3A6ABC for ; Mon, 30 Jun 2008 03:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 JOEcLkyrckbG for ; Mon, 30 Jun 2008 03:25:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D9DAC3A68F0 for ; Mon, 30 Jun 2008 03:25:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDGTv-000Fab-UE for radiusext-data@psg.com; Mon, 30 Jun 2008 10:19:35 +0000 Received: from [76.96.30.96] (helo=QMTA09.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDGTr-000FWo-PV for radiusext@ops.ietf.org; Mon, 30 Jun 2008 10:19:33 +0000 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id kABt1Z0071GXsucA900e00; Mon, 30 Jun 2008 10:19:31 +0000 Received: from gwzPC ([124.120.218.23]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id kAJo1Z0020WskuL8TAK7dk; Mon, 30 Jun 2008 10:19:15 +0000 X-Authority-Analysis: v=1.0 c=1 a=HWwVVMiTGj4A:10 a=m4smBwC4wFAA:10 a=f4fYoBWSf2rJ2KZ-qHsA:9 a=2w8wgkqs4jUBoTf1DGtn1GudIfUA:4 a=-utQw5L2n1AA:10 a=oltf0pfCdT4A:10 From: "Glen Zorn" To: "'David B. Nelson'" Cc: References: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2> <20080625094433.GA28919@elstar.local> <926FE7320FEE492E820F30E7D053C36E@xpsuperdvd2> In-Reply-To: <926FE7320FEE492E820F30E7D053C36E@xpsuperdvd2> Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt Date: Mon, 30 Jun 2008 17:18:38 +0700 Message-ID: <000601c8da9a$b1bc8540$15358fc0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjWqBjcX9Y3RWDZQwe1oKjYZIXyNgBKopewALHr3XA= Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: David B. Nelson [dnelson@elbrysnetworks.com] writes: > > You probably have to reference some 4.2BSD software documentation. > > There might be something suitable in the classic BSD daemon books, I > > unfortunately do not have access to these classics anymore. > > I've been searching for a stable reference that discusses rcp, scp and > sftp. > Certainly, the man pages of many UNIX-style systems, but I don't think > that > qualifies as a "stable reference" for RFC purposes. It would if you copied them into appendices... ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 30 11:48:53 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292083A6986 for ; Mon, 30 Jun 2008 11:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 oLG5ylrsNe7J for ; Mon, 30 Jun 2008 11:48:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E05713A679C for ; Mon, 30 Jun 2008 11:48:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDOKm-000Ojx-1a for radiusext-data@psg.com; Mon, 30 Jun 2008 18:42:40 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDOKg-000OiA-81 for radiusext@ops.ietf.org; Mon, 30 Jun 2008 18:42:37 +0000 Received: (qmail 4213 invoked from network); 30 Jun 2008 14:42:24 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 30 Jun 2008 14:42:24 -0400 From: "David B. Nelson" To: References: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2> <20080625094433.GA28919@elstar.local> <926FE7320FEE492E820F30E7D053C36E@xpsuperdvd2> <000601c8da9a$b1bc8540$15358fc0$@net> Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt Date: Mon, 30 Jun 2008 14:42:22 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjWqBjcX9Y3RWDZQwe1oKjYZIXyNgBKopewALHr3XAAEX7N4A== In-Reply-To: <000601c8da9a$b1bc8540$15358fc0$@net> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn writes... > > I've been searching for a stable reference that discusses rcp, > > scp and sftp. Certainly, the man pages of many UNIX-style > > systems, but I don't think that qualifies as a "stable > > reference" for RFC purposes. > > It would if you copied them into appendices... Well, yes. I suppose there is no copyright issue with cut and paste of UNIX "man" pages into an RFC. OTOH, that verges on defining the underlying service that we are attempting to authorize/provision using RADIUS in the RADIUS document itself. That's a practice I've often advised authors to avoid. Does anyone else on the list think that including "man" pages in appendices is the best way to go? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 30 22:13:46 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CD53A68A8 for ; Mon, 30 Jun 2008 22:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.158 X-Spam-Level: X-Spam-Status: No, score=-1.158 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 UtZH12-+cdFr for ; Mon, 30 Jun 2008 22:13:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CBB0A3A682A for ; Mon, 30 Jun 2008 22:13:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDY6M-000EdE-RH for radiusext-data@psg.com; Tue, 01 Jul 2008 05:08:26 +0000 Received: from [76.96.62.16] (helo=QMTA01.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDY6B-000Ebl-JZ for radiusext@ops.ietf.org; Tue, 01 Jul 2008 05:08:25 +0000 Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA01.westchester.pa.mail.comcast.net with comcast id kNDG1Z00J0vyq2s510Lf00; Tue, 01 Jul 2008 05:08:14 +0000 Received: from gwzPC ([124.120.228.197]) by OMTA05.westchester.pa.mail.comcast.net with comcast id kV7k1Z00D4GAljQ3RV84EW; Tue, 01 Jul 2008 05:08:12 +0000 X-Authority-Analysis: v=1.0 c=1 a=HWwVVMiTGj4A:10 a=m4smBwC4wFAA:10 a=No5EcEP4AAAA:8 a=AgM9v1fOW18tR2VRbqkA:9 a=dfT-EoPMhYtyFMQKyRYA:7 a=H30IXf2Nbdp6x6fcY4MXICJctQAA:4 a=-utQw5L2n1AA:10 a=oltf0pfCdT4A:10 From: "Glen Zorn" To: "'David B. Nelson'" Cc: References: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2> <20080625094433.GA28919@elstar.local> <926FE7320FEE492E820F30E7D053C36E@xpsuperdvd2> <000601c8da9a$b1bc8540$15358fc0$@net> In-Reply-To: Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt Date: Tue, 1 Jul 2008 12:07:24 +0700 Message-ID: <002301c8db38$63d40530$2b7c0f90$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjWqBjcX9Y3RWDZQwe1oKjYZIXyNgBKopewALHr3XAAEX7N4AAVzF1A Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: David B. Nelson [dnelson@elbrysnetworks.com] writes: ... > Does anyone else on the list think that including "man" pages in > appendices is the best way to go? Slight clarification: I don't think that it's necessarily the _best_ way, but it is _a_ way & in the absence of another...BTW, if you're going to include rsh at all, you should mention Kerberos. Unfortunately, Kerberos is not transport security, so it kind of messes up your structure. > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 30 22:39:18 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4DE3A691D for ; Mon, 30 Jun 2008 22:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 AmDzjuRqrjFq for ; Mon, 30 Jun 2008 22:39:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9ECF93A67D7 for ; Mon, 30 Jun 2008 22:39:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDYWc-000IHo-DS for radiusext-data@psg.com; Tue, 01 Jul 2008 05:35:34 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDYWY-000IHG-VL for radiusext@ops.ietf.org; Tue, 01 Jul 2008 05:35:32 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id D2CFA12342A7; Tue, 1 Jul 2008 07:35:29 +0200 (CEST) Message-ID: <4869C21A.20502@deployingradius.com> Date: Tue, 01 Jul 2008 07:35:22 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Additional comments ondraft-ietf-radext-management-authorization-03.txt References: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2> <20080625094433.GA28919@elstar.local> <926FE7320FEE492E820F30E7D053C36E@xpsuperdvd2> <000601c8da9a$b1bc8540$15358fc0$@net> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: David B. Nelson wrote: > Well, yes. I suppose there is no copyright issue with cut and paste of UNIX > "man" pages into an RFC. s/copyright/license/ Everything is copyrighted by someone, unless explicitly place in the public domain. > Does anyone else on the list think that including "man" pages in appendices > is the best way to go? No. I would suggest referring to a specific version of the "man" page as a stable reference. e.g.: "foo", as described in MyOS Release 1.2 "man" page. Other systems may have similar definitions. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 30 23:05:36 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7519F3A6B23 for ; Mon, 30 Jun 2008 23:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 XPLFWuqGZ7sg for ; Mon, 30 Jun 2008 23:05:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 69F583A6B00 for ; Mon, 30 Jun 2008 23:05:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDYvR-000MC6-2a for radiusext-data@psg.com; Tue, 01 Jul 2008 06:01:13 +0000 Received: from [76.96.30.96] (helo=QMTA09.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDYvG-000MAp-1w for radiusext@ops.ietf.org; Tue, 01 Jul 2008 06:01:11 +0000 Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id kVfL1Z0010S2fkCA901300; Tue, 01 Jul 2008 06:01:01 +0000 Received: from gwzPC ([124.120.228.197]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id kW0L1Z0014GAljQ8VW0pLc; Tue, 01 Jul 2008 06:00:59 +0000 X-Authority-Analysis: v=1.0 c=1 a=HWwVVMiTGj4A:10 a=m4smBwC4wFAA:10 a=No5EcEP4AAAA:8 a=X5SW_knb3-iTPT2uluAA:9 a=1VI_MS1eGpuNZlZg8S0A:7 a=mrE_uzfrwQs2Z8UU_XtQZyaYa_8A:4 a=r5QHxzKXScQA:10 a=v47ZLdibA2YA:10 From: "Glen Zorn" To: "'Alan DeKok'" , "'David B. Nelson'" Cc: References: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2> <20080625094433.GA28919@elstar.local> <926FE7320FEE492E820F30E7D053C36E@xpsuperdvd2> <000601c8da9a$b1bc8540$15358fc0$@net> <4869C21A.20502@deployingradius.com> In-Reply-To: <4869C21A.20502@deployingradius.com> Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt Date: Tue, 1 Jul 2008 13:00:00 +0700 Message-ID: <002c01c8db3f$c1f2da40$45d88ec0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjbPMKilZXLKDrySwe2xdAeQuCwVgAAbn3w Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok [aland@deployingradius.com] writes: > David B. Nelson wrote: > > Well, yes. I suppose there is no copyright issue with cut and paste > of UNIX > > "man" pages into an RFC. > > s/copyright/license/ > > Everything is copyrighted by someone, unless explicitly place in the > public domain. Uh-huh...what's your point? Everything that is copyrighted is also subject to "fair use", at least in the US, & this would certainly constitute fair use. > > > Does anyone else on the list think that including "man" pages in > appendices > > is the best way to go? > > No. > > I would suggest referring to a specific version of the "man" page as > a > stable reference. e.g.: > > "foo", as described in MyOS Release 1.2 "man" page. Other systems > may have similar definitions. OK, the problem is that while the reference may be stable, it may not necessarily be readily available after some period of time: i.e., stable but useless. > > Alan DeKok. > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 30 23:33:01 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98B43A6AA9 for ; Mon, 30 Jun 2008 23:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 SxD-9XUfxAZy for ; Mon, 30 Jun 2008 23:33:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E38EC3A6B00 for ; Mon, 30 Jun 2008 23:33:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDZN8-0000mz-FY for radiusext-data@psg.com; Tue, 01 Jul 2008 06:29:50 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDZN4-0000mM-Nx for radiusext@ops.ietf.org; Tue, 01 Jul 2008 06:29:48 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 5013012342A7; Tue, 1 Jul 2008 08:29:45 +0200 (CEST) Message-ID: <4869CED5.70001@deployingradius.com> Date: Tue, 01 Jul 2008 08:29:41 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: Glen Zorn CC: "'David B. Nelson'" , radiusext@ops.ietf.org Subject: Re: Additional comments ondraft-ietf-radext-management-authorization-03.txt References: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2> <20080625094433.GA28919@elstar.local> <926FE7320FEE492E820F30E7D053C36E@xpsuperdvd2> <000601c8da9a$b1bc8540$15358fc0$@net> <4869C21A.20502@deployingradius.com> <002c01c8db3f$c1f2da40$45d88ec0$@net> In-Reply-To: <002c01c8db3f$c1f2da40$45d88ec0$@net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote: > Uh-huh...what's your point? Everything that is copyrighted is also subject > to "fair use", at least in the US, & this would certainly constitute fair > use. "cut and paste" of the pages is fair use only if *quotes* are included. Including the pages verbatim would likely not fall under fair use guidelines. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jun 30 23:53:08 2008 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3C23A685F for ; Mon, 30 Jun 2008 23:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 ccJFkQqYsGMj for ; Mon, 30 Jun 2008 23:53:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 778283A6981 for ; Mon, 30 Jun 2008 23:53:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDZei-0003Xw-JZ for radiusext-data@psg.com; Tue, 01 Jul 2008 06:48:00 +0000 Received: from [76.96.62.40] (helo=QMTA04.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KDZef-0003XE-0L for radiusext@ops.ietf.org; Tue, 01 Jul 2008 06:47:58 +0000 Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA04.westchester.pa.mail.comcast.net with comcast id kWjL1Z0040EZKEL5400C00; Tue, 01 Jul 2008 06:47:56 +0000 Received: from gwzPC ([124.120.228.197]) by OMTA01.westchester.pa.mail.comcast.net with comcast id kWnN1Z0014GAljQ3MWnirl; Tue, 01 Jul 2008 06:47:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=HWwVVMiTGj4A:10 a=m4smBwC4wFAA:10 a=6I5d2MoRAAAA:8 a=TgjAikVWi4FhEwES0cIA:9 a=92Wb8syMt-7a6_fQr-DcqgukmigA:4 a=r5QHxzKXScQA:10 a=v47ZLdibA2YA:10 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'David B. Nelson'" , References: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2> <20080625094433.GA28919@elstar.local> <926FE7320FEE492E820F30E7D053C36E@xpsuperdvd2> <000601c8da9a$b1bc8540$15358fc0$@net> <4869C21A.20502@deployingradius.com> <002c01c8db3f$c1f2da40$45d88ec0$@net> <4869CED5.70001@deployingradius.com> In-Reply-To: <4869CED5.70001@deployingradius.com> Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt Date: Tue, 1 Jul 2008 13:47:02 +0700 Message-ID: <002d01c8db46$4e5f4800$eb1dd800$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjbQ+C/o5AkRFYUTrWdWx2hNMdJRwAAT3dQ Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > > Uh-huh...what's your point? Everything that is copyrighted is also > subject > > to "fair use", at least in the US, & this would certainly constitute > fair > > use. > > "cut and paste" of the pages is fair use only if *quotes* are > included. > Including the pages verbatim would likely not fall under fair use > guidelines. First, man pages are portions of a larger document (the manual) and as such reproducing one is by definition a quotation from the full document. Be that as it may, however, see http://www.freebsd.org/copyright/freebsd-doc-license.html & http://www.freebsd.org/copyright/freebsd-license.html for the ability to reproduce BSD man pages (the most likely candidate for rcp, anyway). > > Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 30 Jun 2008 18:43:59 +0000 From: "David B. Nelson" To: Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt Date: Mon, 30 Jun 2008 14:42:22 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjWqBjcX9Y3RWDZQwe1oKjYZIXyNgBKopewALHr3XAAEX7N4A== Glen Zorn writes... > > I've been searching for a stable reference that discusses rcp, > > scp and sftp. Certainly, the man pages of many UNIX-style > > systems, but I don't think that qualifies as a "stable > > reference" for RFC purposes. > > It would if you copied them into appendices... Well, yes. I suppose there is no copyright issue with cut and paste of UNIX "man" pages into an RFC. OTOH, that verges on defining the underlying service that we are attempting to authorize/provision using RADIUS in the RADIUS document itself. That's a practice I've often advised authors to avoid. Does anyone else on the list think that including "man" pages in appendices is the best way to go? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 30 Jun 2008 10:20:49 +0000 From: "Glen Zorn" To: "'David B. Nelson'" Cc: Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt Date: Mon, 30 Jun 2008 17:18:38 +0700 Message-ID: <000601c8da9a$b1bc8540$15358fc0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjWqBjcX9Y3RWDZQwe1oKjYZIXyNgBKopewALHr3XA= Content-Language: en-us David B. Nelson [dnelson@elbrysnetworks.com] writes: > > You probably have to reference some 4.2BSD software documentation. > > There might be something suitable in the classic BSD daemon books, I > > unfortunately do not have access to these classics anymore. > > I've been searching for a stable reference that discusses rcp, scp and > sftp. > Certainly, the man pages of many UNIX-style systems, but I don't think > that > qualifies as a "stable reference" for RFC purposes. It would if you copied them into appendices... ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 30 Jun 2008 09:02:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Call for Agenda Items for IETF 72 Date: Mon, 30 Jun 2008 10:58:10 +0200 Message-ID: Thread-Topic: Call for Agenda Items for IETF 72 Thread-Index: AcjVt6BR+cXCkG4pS+m03+ehrMl8lQE1mw4A From: "Benoit Lourdelet (blourdel)" To: "Bernard Aboba" , , Cc: "Richard Gayraud (rgayraud)" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1039; t=1214816440; x=1215680440; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20 |Subject:=20RE=3A=20Call=20for=20Agenda=20Items=20for=20IET F=2072 |Sender:=20; bh=XyrWvjc/OU5zIKIniBq6gDYfXjBEuGccjA+Lfu0UsWY=; b=Fa4I2a2ep3oLy4G6oQDpfdRfkhbMGfrc5hbYkIh+Fihxd/mR+m/5yvOeik r2mcEhlX4ZTW/0k53xfkc+q1OLn1fWUxepGaf7yIpTKT89ioyuhiGMM4mLbf 8RumwG1Mmk; Authentication-Results: ams-dkim-2; header.From=blourdel@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Hello, I'd like a 10 min slot to discuss the following draft :=20 http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-00. txt As it includes RADIUS and DHCP concepts, It would request a slots in DHC and RADEXT groups if that is the commonly accepted procedure. Regards Benoit -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, June 24, 2008 7:02 AM To: radiusext@ops.ietf.org Subject: Call for Agenda Items for IETF 72 This is a call for agenda items for the RADEXT WG meeting at IETF 72 in Dublin. The meeting is tentatively scheduled for Wednesday, July 30, 2008 from 9 AM - 11:30 AM. =20 If you have an item you'd like to put on the agenda, please contact myself (Bernard_Aboba@hotmail.com) or Dave.=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 29 Jun 2008 04:03:31 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-radext-design-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080625100002.0E9FA28C106@core3.amsl.com> Date: Wed, 25 Jun 2008 03:00:02 -0700 (PDT) Cc: radiusext@ops.ietf.org Reply-To: internet-drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Design Guidelines Author(s) : G. Weber, et al. Filename : draft-ietf-radext-design-03.txt Pages : 31 Date : 2008-06-25 This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-design-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-25025633.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 26 Jun 2008 21:35:19 +0000 From: "David B. Nelson" To: Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt Date: Thu, 26 Jun 2008 17:33:30 -0400 Organization: Elbrys Networks, Inc. Message-ID: <926FE7320FEE492E820F30E7D053C36E@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjWqBjcX9Y3RWDZQwe1oKjYZIXyNgBKopew > You probably have to reference some 4.2BSD software documentation. > There might be something suitable in the classic BSD daemon books, I > unfortunately do not have access to these classics anymore. I've been searching for a stable reference that discusses rcp, scp and sftp. Certainly, the man pages of many UNIX-style systems, but I don't think that qualifies as a "stable reference" for RFC purposes. I've "found" one book in my web searches that seems to cover the material (although I don't actually have a copy). It is as follows: Section 3.7 SSH and File Transfers in SSH, the Secure Shell: The Definitive Guide, Second Edition D. Barrett, R. Silverman, R. Byrnes O'Reilly and Associates, May 2005 If anyone has a better reference to cite, to close the issue raised by Barnard, please let me know. Thanks! If I don't "get a better offer" I propose to use this reference for RCP, SCP and SFTP. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 25 Jun 2008 19:19:59 +0000 Date: Wed, 25 Jun 2008 12:18:43 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 259: Extended Type Field Length Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 259: Extended Type Field Length Submitter name: Bernard Aboba Submitter email address: Bernard_Aboba@hotmail.com Date first submitted: June 25, 2008 Reference: http://ops.ietf.org/lists/radiusext/2008/msg00321.html Document: http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-03.txt Comment type: Technical Priority: S Section: 5 Rationale/Explanation of issue: The -03 version of this document contains the following TLV format: 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ext-Type | Ext-Len | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ However, the RADEXT WG Consensus from IETF 71, and as confirmed on the RADEXT WG mailing list, was that the Ext-Type field should be 2 octets in length, not 1. Also, the Consensus of the WG was that Extended Attributes would not be applied to existing RADIUS standard attributes. Here is the summary of the Consensus Call Determination: http://ops.ietf.org/lists/radiusext/2008/msg00321.html -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 25 Jun 2008 18:58:20 +0000 Date: Wed, 25 Jun 2008 11:56:40 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT WG Last Call on RADIUS Design Guidelines Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is an announcement of RADEXT WG Last Call on "RADIUS Design Guidelines" prior to requesting that the IESG publish it as a Best Current Practice RFC. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-03.txt WG Last Call will last until July 10, 2008. Please review the document and post your comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format described on the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT/). If you have read the document and approve of its publication, but have no comments, please also post this to the list. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 25 Jun 2008 15:52:20 +0000 Date: Wed, 25 Jun 2008 17:50:27 +0200 From: Juergen Schoenwaelder To: "David B. Nelson" Cc: radiusext@ops.ietf.org Subject: Re: Additional comments ondraft-ietf-radext-management-authorization-03.txt Message-ID: <20080625155027.GA29447@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: "David B. Nelson" , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) On Wed, Jun 25, 2008 at 09:45:48AM -0400, David B. Nelson wrote: > So, that leads me to ask what's the difference between SCP and SFTP? SFTP is really pretty much like FTP in the sense that it provides a protocol allowing you to send commands from a rather rich set of primitives to an SFTP server that are then executed by the server. Scp is much simpler and usually does just one thing, namely transferring files. With SFTP, you can implement a filesystem that allows to mount an SFTP server. This won't really work with scp since you lack primitives to read directories, to create, modify or delete directories, to handle symbolic links, to play with file attributes and so on. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 25 Jun 2008 13:47:13 +0000 From: "David B. Nelson" To: Cc: Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt Date: Wed, 25 Jun 2008 09:45:48 -0400 Message-ID: <015101c8d6c9$c8272bc0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjWqMniqm/ACsB6TFezWcamBUG+dAAIHRUg > You probably have to reference some 4.2BSD software documentation. > There might be something suitable in the classic BSD daemon books, I > unfortunately do not have access to these classics anymore. Nor do I, but that's an idea for me to pursue. Thanks. > The scp program is a simple wrapper around ssh. So, that leads me to ask what's the difference between SCP and SFTP? > Finding official stable documentation for this will be difficult I > assume. That's what I was afraid of... :-( -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 25 Jun 2008 10:01:13 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-design-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080625100002.0E9FA28C106@core3.amsl.com> Date: Wed, 25 Jun 2008 03:00:02 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Design Guidelines Author(s) : G. Weber, et al. Filename : draft-ietf-radext-design-03.txt Pages : 31 Date : 2008-06-25 This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-design-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-25025633.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 25 Jun 2008 09:46:11 +0000 Date: Wed, 25 Jun 2008 11:44:33 +0200 From: Juergen Schoenwaelder To: "David B. Nelson" Cc: radiusext@ops.ietf.org, 'Bernard Aboba' Subject: Re: Additional comments on draft-ietf-radext-management-authorization-03.txt Message-ID: <20080625094433.GA28919@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: "David B. Nelson" , radiusext@ops.ietf.org, 'Bernard Aboba' MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) On Tue, Jun 24, 2008 at 02:28:05PM -0400, David B. Nelson wrote: > > RCP: Can you add a reference? > > I'd have to find a suitable one. :-) Can someone help me out here? All I > can find is UNIX/LINUX man pages references. Can someone point me to a > suitable, stable reference that can be included in an I-D / RFC? You probably have to reference some 4.2BSD software documentation. There might be something suitable in the classic BSD daemon books, I unfortunately do not have access to these classics anymore. > > SCP: Please add a reference... > > Ditto. Need assistance here, too. > > > ...(doesn't this also use the services of SSH?) > > AFAIK, it does not. You may be thinking of SFTP, (SSH File Transfer > Protocol, which does.) Can anyone clarify this? The scp program is a simple wrapper around ssh. The first comment in the scp.c source file (openssh) says: * scp - secure remote copy. This is basically patched BSD rcp which * uses ssh to do the data transfer (instead of using rcmd). Finding official stable documentation for this will be difficult I assume. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 24 Jun 2008 18:29:35 +0000 From: "David B. Nelson" To: Cc: "'Bernard Aboba'" Subject: RE: Additional comments on draft-ietf-radext-management-authorization-03.txt Date: Tue, 24 Jun 2008 14:28:05 -0400 Organization: Elbrys Networks, Inc. Message-ID: <8C7782618CE147DAACD82FC947DF77FB@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjWDNpFBM9lW8yqTripxrKpZlc0EgAGgyiA Skipping over most of the editorial issues for now, I'll highlight the items for which I need assistance from the list members. > "http://www.w3.org/TR/html": Please add this to the reference > section, and refer to it in Section 8.1. I'll have to figure out how to manually craft reference anchors in xml2rfc, but I think this can be done. > "(http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13)" > Please add this in the reference section. Ditto. > RCP: Can you add a reference? I'd have to find a suitable one. :-) Can someone help me out here? All I can find is UNIX/LINUX man pages references. Can someone point me to a suitable, stable reference that can be included in an I-D / RFC? > SCP: Please add a reference... Ditto. Need assistance here, too. > ...(doesn't this also use the services of SSH?) AFAIK, it does not. You may be thinking of SFTP, (SSH File Transfer Protocol, which does.) Can anyone clarify this? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 24 Jun 2008 15:10:49 +0000 Date: Tue, 24 Jun 2008 08:08:14 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Additional comments on draft-ietf-radext-management-authorization-03.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Section 8.1 "Service-Type of Framed-Management" -> "Service-Type Attribute with the value Framed-Management" "in Access-Request packet" -> "in an Access-Request packet" "MAY use these hint attributes" -> "may use these attributes as a hint" "MUST treat the response" -> "MUST treat the Access-Accept" "http://www.w3.org/TR/html": Please add this to the reference section, and refer to it in Section 8.1. "(http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13)" Please add this in the reference section. RCP: Can you add a reference? SCP: Please add a reference (doesn't this also use the services of SSH?) Section 8.2 The Management-Transport-Protection Attribute specifies whether a secure transport protocol (e.g. SSH, TLS, DTLS, etc.) is required for use with the associated framed or non-framed management access session. The value of this attribute specifies the minimum level of protection that is required from the protected transport. The protected transport MAY provide a greater level of protection than is called for by the value of Management-Transport-Protection. [BA] The second sentence is more on target. How about this? The Management-Transport-Protection Attribute specifies the minimum level of protection that is required for a protected transport used with the framed or non-framed management access session. The protected transport used by the NAS MAY provide a greater level of protection, but MUST NOT provide a lower level of protection. "in Access-Request packet" -> "in an Access-Request packet" "RADIUS Client" -> "RADIUS clent" "RADIUS Server" -> "RADIUS server" "MAY use this hint attribute" -> "may use this attribute as a hint" Section 8.3 "application to SMNP services" -> "SNMP" "NAS behavior in such cases is not predictable." -> "The behavior of the NAS in this case is undefined." "a single service provisioning message, such as" -> "an Access-Accept or CoA-Request". ", within a flat namespace of significance to the NAS" [BA] Are you saying that "." can't be used? Can this be deleted? "Overloading or subdividing this flat name with" -> "Overloading or subdividing this attribute with" "If a simple flat policy name" -> "If a simple policy name" "sufficient to the anticipated use case" -> "sufficient" Section 12 Within the document, the CoA-Request is mentioned, but the table does not describe which attributes can be included in CoA or Disconnect Request, ACK or NAK packets. Is it accurate to assume that none of the attributes defined in this document can be contained in a CoA or Disconnect packet? Section 14 Any of the attributes described in this memo, with the exception of Service-Type, may not be understood by the NAS which receives it. A legacy NAS not compliant with this specification may silently discard these attributes while permitting the user to access the management interface(s) of the NAS. This can lead to users improperly receiving unauthorized management access to the NAS, or access with greater levels of access rights than were intended. RADIUS servers SHOULD attempt to ascertain whether or not the NAS supports these attributes before sending them in an Access-Accept. [BA] This paragraph could be more clear. There are really two cases. When a Service-Type value of Framed-Management is used, I'd assume that a NAS implementing this specification would be required to behave as specified (e.g. treat the Access-Accept as an Access-Reject if the attribute or value wasn't supported). I think that an issue could occur when a legacy Service-Type value is used though, since then the NAS might ignore the new attributes instead of treating the Access-Accept like an Access-Reject. I don't think you need to talk about the potential behavior of an implementation that claims to conform to the spec, but doesn't do what it says. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 24 Jun 2008 14:34:11 +0000 Date: Tue, 24 Jun 2008 07:31:11 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Editorial review of draft-ietf-radext-management-authorization-03.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Abstract This document describes Remote Authentication Dial-In User Service (RADIUS) attributes for the authorization and service provisioning of Network Access Servers (NASes). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via framed management protocols, and for specification of a protected transport protocol. [BA] This document is about NAS management authorization, not authorization of NASes. Suggest the following: This document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for Network Access Server (NAS) management. Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via framed management protocols, which may run over a secure transport protocol. 2. Introduction and Rationale [BA] How about combining Sections 2, part of 3 and 6 into a Section 1 that reads as follows? The Terminology section can then be Section 1.1. 1. Introduction RFC 2865 [RFC 2865] defines the NAS-Prompt and Administrative values of the Service-Type Attribute. Both of these values provide access to the interactive, text-based Command Line Interface (CLI) of the NAS, and were originally developed to control access to the physical console port of the NAS, most often a serial port. Remote access to the CLI of the NAS has been available in NAS implementations for many years, using protocols such as Telnet, Rlogin and the remote terminal service of SSH. In order to distinguish local, physical, console access from remote access, the NAS-Port-Type Attribute is generally included in Access-Request and Access-Accept messages, along with the Service-Type Attribute, to indicate the form of access. A NAS-Port-Type of Async (0) is used to signify a local serial port connection, while a value of Virtual (5) is used to signify a remote connection, via a remote terminal protocol. This usage provides no selectivity among the various available remote terminal protocols (e.g. Telnet, Rlogin, SSH, etc.). Today, it is common for network devices to support more than two privilege levels for management access than just NAS-Prompt (non-privileged) and Administrative (privileged). Also, other management mechanisms may be used, such as Web-based management, Simple Network Management Protocol (SNMP) and NETCONF. To provide support for these additional features, this specification defines attributes for framed management protocols, management protocol security, and management access privilege levels. Remote management via the command line is carried over protocols such as Telnet, Rlogin and the remote terminal service of SSH. Since these protocols are primarily for the delivery of terminal or pseudo-TTY services, the term "Framed Management" is used to describe management protocols supporting techniques other than the command-line. Typically these mechanisms format management information in a binary or textual encoding such as HTML, XML or ASN.1/BER. Examples include web-based management (HTML over HTTP or HTTPS), NETCONF (XML over SSH/BEEP/SOAP) and SNMP (SMI over ASN.1/BER). Command line interface, menu interface or other text-based (e.g. ASCII or UTF-8) terminal emulation services are not considered to be Framed Management protocols. [BA] How about combining part of Section 3, as well as 4, 5 and 6 into a Section 2 that reads as follows? 2. Overview To support the authorization and provisioning of Framed Management access to managed entities, this document introduces a new value for the Service-Type Attribute [RFC2865], and one new attribute. The new value for the Service-Type Attribute is Framed-Management, used for remote device management via a Framed Management Protocol. The new attribute is Framed-Management-Protocol, the value of which specifies a particular protocol for use in the remote management session. Two new attributes are introduced in this document in support of granular management access rights or command privilege levels. The Management-Policy-Id Attribute provides a text string specifying a policy name of local scope, that is assumed to have been pre-provisioned on the NAS. This use of an attribute to specify use of a pre-provisioned policy is similar to the Filter-Id Attribute defined in [RFC2865] Section 5.11. The local application of the Management-Policy-Id within the managed entity may take the form of (a) one of an enumeration of command privilege levels, (b) a mapping into an SNMP Access Control Model, such as the View Based Access Control Model (VACM) [RFC3415], or (c) some other set of management access policy rules that is mutually understood by the managed entity and the remote management application. Examples are given in Section X. The Management-Privilege-Level Attribute contains an integer-valued management privilege level indication. This attribute serves to modify or augment the management permissions provided by the NAS-Prompt value of the Service-Type Attribute, and thus applies to CLI management. To enable management security requirements to be specified, the Management-Transport-Protection Attribute is introduced. The value of this attribute indicates the minimum level of secure transport protocol protection required for the provisioning of NAS-Prompt, Administrative or Framed-Management service. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 24 Jun 2008 05:04:14 +0000 Date: Mon, 23 Jun 2008 22:03:25 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: REMINDER: WG Last call in progress: RADIUS Authorization for NAS Management Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a reminder of RADEXT WG Last Call on "RADIUS Authorization for NAS Management" prior to sending it on to the IESG for consideration as a Proposed Standard. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-03.txt WG Last Call will last until June 30, 2008. Please review the document and post your comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format described on the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT/). If you have read the document and approve of its publication, but have no comments, please also post this to the list. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 24 Jun 2008 05:03:04 +0000 Date: Mon, 23 Jun 2008 22:01:39 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Call for Agenda Items for IETF 72 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a call for agenda items for the RADEXT WG meeting at IETF 72 in Dublin. The meeting is tentatively scheduled for Wednesday, July 30, 2008 from 9 AM - 11:30 AM. If you have an item you'd like to put on the agenda, please contact myself (Bernard_Aboba@hotmail.com) or Dave. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 21 Jun 2008 16:49:25 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-radext-radsec-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080617224502.8BEDC3A6B45@core3.amsl.com> Date: Tue, 17 Jun 2008 15:45:02 -0700 (PDT) Cc: radiusext@ops.ietf.org Reply-To: internet-drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : TLS encryption for RADIUS over TCP (RadSec) Author(s) : S. Winter, et al. Filename : draft-ietf-radext-radsec-00.txt Pages : 14 Date : 2008-06-17 This document specifies security on the transport layer (TLS) for the RADIUS protocol [2] when transmitted over TCP [9]. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-radsec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-17154328.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Jun 2008 20:30:42 +0000 Message-ID: <48597046.1090402@restena.lu> Date: Wed, 18 Jun 2008 22:29:58 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: I-D Action:draft-ietf-radext-radsec-00.txt Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org schrieb: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the RADIUS EXTensions Working Group of the IETF. > > > Title : TLS encryption for RADIUS over TCP (RadSec) > Author(s) : S. Winter, et al. > Filename : draft-ietf-radext-radsec-00.txt > Pages : 14 > Date : 2008-06-17 > > This document specifies security on the transport layer (TLS) for the > RADIUS protocol [2] when transmitted over TCP [9]. This enables > dynamic trust relationships between RADIUS servers. > > This document has the TCP transport part chopped out, as that part goes into a separate document. The according reference [9] will come into existence in the coming weeks. Apart from that, the title, abstract, some sections in the main body were updated to reflect the splitting. No real content changes in it. Greetings, Stefan Winter -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Jun 2008 18:07:03 +0000 Message-ID: <48594D46.2050808@deployingradius.com> Date: Wed, 18 Jun 2008 20:00:38 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-radext-status-server-00.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the RADIUS EXTensions Working Group of the IETF. > > Title : Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol > Author(s) : A. DeKok > Filename : draft-ietf-radext-status-server-00.txt FYI: The only change between this document and draft-dekok-radext-status-server-02.txt is the name, submission date, and expiration date. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Jun 2008 17:02:43 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D ACTION:draft-ietf-radext-status-server-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080618170002.2B31A3A6AF3@core3.amsl.com> Date: Wed, 18 Jun 2008 10:00:02 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol Author(s) : A. DeKok Filename : draft-ietf-radext-status-server-00.txt Pages : 27 Date : 2008-6-17 RFC 2865 defines a Status-Server code for use in RADIUS, but labels it as "Experimental" without further discussion. This document describes a practical use for the Status-Server packet code, which is to let clients query the status of a RADIUS server. These queries, and responses (if any) enable the client to make more informed decisions. The result is a more stable, and more robust RADIUS architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-status-server-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-6-18095827.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Jun 2008 22:47:03 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-radsec-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080617224502.8BEDC3A6B45@core3.amsl.com> Date: Tue, 17 Jun 2008 15:45:02 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : TLS encryption for RADIUS over TCP (RadSec) Author(s) : S. Winter, et al. Filename : draft-ietf-radext-radsec-00.txt Pages : 14 Date : 2008-06-17 This document specifies security on the transport layer (TLS) for the RADIUS protocol [2] when transmitted over TCP [9]. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-radsec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-17154328.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Jun 2008 22:19:35 +0000 Message-ID: From: "Bernard Aboba" To: "'Sanchez, Mauricio \(ProCurve\)'" , Subject: RE: Request for review of RADIUS Attributes for IEEE 802 Networks Date: Tue, 17 Jun 2008 15:18:03 -0700 Message-ID: <005f01c8d0c8$029efe70$07dcfb50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcgmODLyeeG1TRSFS16Yc4EGw4p4CgQuU01gAAAEyGAmdZn3wA== Content-Language: en-us I also support this document as a RADEXT WG item. -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, Mauricio (ProCurve) Sent: Tuesday, December 04, 2007 7:48 PM To: radiusext@ops.ietf.org Subject: Request for review of RADIUS Attributes for IEEE 802 Networks I support this document as a RADEXT WG item. Cheers, MS > -----Original Message----- > From: owner-radiusext@ops.ietf.org [mailto:owner- > radiusext@ops.ietf.org] On Behalf Of David B. Nelson > Sent: Tuesday, November 13, 2007 1:00 PM > To: radiusext@ops.ietf.org > Subject: Request for review of RADIUS Attributes for IEEE 802 Networks > > The Internet-Draft "RADIUS Attributes for IEEE 802 Networks" was > revised on > July 30, 2007, after incorporating review from the IEEE 802.11 WG. > This > document appears on the RADEXT WG charter as a June 2006 milestone > "WLAN > Attributes draft submitted as a Proposed Standard RFC". It would be > good to > make additional progress on this document. It appears that all the > required > external (i.e. IEEE) review has been completed. > > Please review this draft to determine if it is ready to be taken on as > a > RADEXT WG work item. The draft is to be found at: > > http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-06.txt > > In light of the upcoming IETF-70 meeting, this request for review will > last > until December 7, 2007, i.e. approximately four weeks, including the > IETF > week. > > Please indicate whether you would like this document to be taken on as > a WG > work item. Please respond even if you have no issues with the document. > If > you have comments, please send the issues to the RADEXT WG mailing list > in > the format provided here: > > http://www.drizzle.com/~aboba/RADEXT/ > > Thanks! > > Regards, > > Dave Nelson > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Jun 2008 20:34:35 +0000 From: "David B. Nelson" To: Subject: RADEXT WG Last Call on "RADIUS Authorization for NAS Management" Date: Mon, 16 Jun 2008 16:32:59 -0400 Organization: Elbrys Networks, Inc. Message-ID: <9B9F3669FCE44E24AFEEC3F456870385@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Index: AcjP7oMtbwAqQuoxRMaIGZvyuOFXPgAASCaw Forwarding on behalf of Bernard... (transient e-mail issues) From: bernard_aboba@hotmail.com To: radiusext@ops.ietf.org Subject: RADEXT WG Last Call on "RADIUS Authorization for NAS = Management" Date: Mon, 16 Jun 2008 13:03:40 -0700 This is an announcement of RADEXT WG Last Call on "RADIUS Authorization = for NAS Management" prior to sending it on to the IESG for consideration as = a Proposed Standard. =A0 The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authoriz= ati on-03.txt =A0 WG Last Call will last until June 30, 2008.=A0=A0 Please review the = document and post your comments to the RADEXT WG mailing list = (radiusext@ops.ietf.org) in the format described on the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT/).=A0=A0=20 =A0 If you have read the document and approve of its publication, but have = no comments, please also post this to the list.=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Jun 2008 15:04:13 +0000 From: "David B. Nelson" To: Cc: "'David Harrington'" , "'Bernard Aboba'" Subject: RE: I-D Action:draft-ietf-radext-management-authorization-03.txt Date: Mon, 16 Jun 2008 11:02:14 -0400 Organization: Elbrys Networks, Inc. Message-ID: <2CC84668FF754256BF8B344763BBC412@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjM/HXJa+rVnKQxSOiWb39rs4zW1gCwsnfg > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-radext-management- > authorization-03.txt I would like to call the WG's attention to this recently posted draft revision. This version addresses WGLC Issues 253-256, as discussed in recent mailing list threads. A summary of the technical (non-editorial) changes is as follows: Section 8.1: Added text describing the use of the Framed-Management-Protocol Attribute by the NAS in Access-Request packets as a "hint", by the server in Access-Accept packets as an expression of the server's policy and by the NAS in Access-Accept packets in the case when the value does not match with the requested access or the NAS's supported protocols. Clarified that "CP" means "RCP" and added "SCP" and "SFTP". Section 8.2: Added text describing the use the Management-Transport-Protection Attribute similar to that described above. Section 9: Fixed some inconsistencies in the examples. Please take a moment to review all of the changes in this revision. Bernard, were you planning to initiate a second WGLC on this draft prior to IETF-72? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Jun 2008 05:14:52 +0000 Message-ID: <4855F554.1020206@deployingradius.com> Date: Mon, 16 Jun 2008 07:08:36 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Wasn't Status-Server first implemented by Ascend Communications in the > mid-1990s? It's certainly possible. I don't recall, and I don't have access to a source tree to check. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Jun 2008 01:08:09 +0000 Message-ID: From: "Bernard Aboba" To: "'Alan DeKok'" Cc: Subject: RE: Request for Review: Status Server Document Date: Sun, 15 Jun 2008 18:06:28 -0700 Message-ID: <001d01c8cf4d$34fbd590$9ef380b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjPIPljHhjompzOTriON6OR8Wk57gAKw5rw Content-Language: en-us Alan DeKok said: " The only part of the Status-Server behavior that does not go back to 2001 is the suggestion that it contain a Message-Authenticator attribute. That requirement was added to FreeRADIUS in Feb 2007, before the RADEXT WG discussion on re-chartering." Wasn't Status-Server first implemented by Ascend Communications in the mid-1990s? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 15 Jun 2008 19:45:48 +0000 Message-ID: <48556FE7.9010109@deployingradius.com> Date: Sun, 15 Jun 2008 21:39:19 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Romascanu, Dan (Dan) wrote: > My understanding from the discussions that preceded the rechartering > approval was that we are indeed documenting current practices based on > implementations and deployment without defining anything new. It's OK > (actually more than OK - required) to put text that makes this > crystal-clear. The only part of the Status-Server behavior that does not go back to 2001 is the suggestion that it contain a Message-Authenticator attribute. That requirement was added to FreeRADIUS in Feb 2007, before the RADEXT WG discussion on re-chartering. This appears to fall with the "documenting current practices" guidelines. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 15 Jun 2008 09:30:07 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Request for Review: Status Server Document Date: Sun, 15 Jun 2008 11:28:36 +0200 Message-ID: Thread-Topic: Request for Review: Status Server Document Thread-Index: AcjONKB44MDqFmiKTKirxjFV1SoB7AAlSHgA From: "Romascanu, Dan (Dan)" To: "Alan DeKok" , "David B. Nelson" Cc: Alan, I have a different view.=20 This is what the charter says about this work item:=20 - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. My understanding from the discussions that preceded the rechartering approval was that we are indeed documenting current practices based on implementations and deployment without defining anything new. It's OK (actually more than OK - required) to put text that makes this crystal-clear.=20 If the working group believes that the implementations are wrong it needs to say it clearly in this document. If the WG believes that there need to be fixes in the protocol, it needs to recharter this work item. Actually we can create new RADIUS codes according to the new charter, but not for this work item.=20 Dan > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok > Sent: Saturday, June 14, 2008 6:31 PM > To: David B. Nelson > Cc: radiusext@ops.ietf.org > Subject: Re: Request for Review: Status Server Document >=20 > David B. Nelson wrote: > > That makes review of this document in RADEXT a little bit=20 > challenging. > > We can, of course, polish the prose and make sure that the=20 > > descriptions are self-consistent and clear and that the=20 > organization=20 > > is logical. I guess only those who have access to the "historical=20 > > implementation" can discern whether the descriptions are=20 > accurate and correct. >=20 > See ftp://ftp.cistron.nl/pub/radius. Open Source =3D=3D full = access. >=20 > Version 1.6.5 has the first public implementation of Status-Server. > CVS indicates that the change was January 21, by Miquel Van=20 > Smoorenburg. > FreeRADIUS added support for Status-Server on Oct 17, 2002,=20 > "stolen shamelessly from Cistron", according to the commit message. >=20 > I believe that Radiator also added it around the same time.=20 > I don't know which was first, because I don't have access to=20 > the Radiator CVS tree. >=20 > The intent of the document is most definitely *not* to=20 > document historical implementations... and leave it at that. =20 > The original implementation in Cistron did NOT validate=20 > Status-Server packets, so they could be trivially forged. >=20 > As a result, the document is rather longer than I had=20 > originally intended. I expected that simply documenting the=20 > practice would be 3-4 pages, at most. Upon writing it, there=20 > were a number of loose ends that had to be cleared up, such=20 > as security. Hence the additional text. >=20 > > The IESG, and the IETF at large, hold the WG, in general,=20 > and the WG=20 > > Chairs and/or Document Shepherd, in particular, accountable=20 > to assert=20 > > that the submitted draft meets certain protocol quality standards. =20 > > Now, I suppose that the quality of protocols is somewhat subjective. > > Nonetheless, its uncomfortable to be held accountable for=20 > the quality=20 > > of a design that you are not able to affect in any way. >=20 > I expect the WG to complain loudly if there are any=20 > problems. This seems to be historical practice in RADEXT. :) >=20 > Much of the text in the document discusses security issues=20 > around the use of Status-Server, and recommended practices. =20 > I expect full review of both the security implications and=20 > recommended practices. >=20 > The document is partly about historical implementations. =20 > But if those implementations are wrong, the standard should=20 > reflect that, and should standardize the correct behavior. =20 > e.g. It recommends adding Message-Authenticator to=20 > Status-Server, which Cistron did not enforce in 2001, and=20 > which FreeRADIUS did not enforce until a few years ago. >=20 > > I think that we need to be clear in publishing this draft=20 > and an RFC=20 > > that the *protocol* it documents was *not* the work product of the=20 > > RADEXT WG, but rather of various historic implementors. Truth in=20 > > advertising. There are some hints at that already. I'll=20 > propose some=20 > > more explicit text as a formal RADEXT Issue. >=20 > Thanks. The choice of (some) contents, response packet=20 > codes, and use of Status-Server as a "ping" are historical. =20 > Much of the rest of the document is discussion surrounding the topic. >=20 > >> RADIUS has traditionally used separate status codes for requests=20 > >> and replies. Using the same code for both is about as bad=20 > (IMHO) as=20 > >> overloading Access-Accept. > >=20 > > I think you're probably right. Sigh. >=20 > I'll add some test to the document to this effect. =20 > "Overloading Access-Accept is horrible. RADIUS would=20 > normally use something like Ping-Check and Ping-Ack, but=20 > implementations exist..." >=20 > And the charter prevents us from creating more RADIUS=20 > codes, so it would have been problematic to create Ping-Check=20 > and Ping-Ack now. > Overloading Access-Accept seems to make the best of a bad situation. >=20 > Alan DeKok. >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 15 Jun 2008 07:53:01 +0000 Message-ID: <4854C8FF.8030803@deployingradius.com> Date: Sun, 15 Jun 2008 09:47:11 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org, "'David B. Nelson'" Subject: Re: Request for Review: Status Server Document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > Existing implementations or not, RADIUS "ping" is just as wasteful of > processing power & bandwidth as it was 10 years ago. It's not a "keep-alive". That's bad. It is the watchdog timer recommended in RFC 3539. The draft discusses why using existing RADIUS codes such as Access-Request is not a good idea. It also discusses why it's useful, and why it's not a "keep-alive". > A far better idea IMHO > is to have the server tell its clients when it recovers from a failure/admin > reboot/etc. I agree, mostly. Some complications: - clients don't historically listen on a port for unsolicited RADIUS packets (RFC 5176 is not widely deployed) - clients may be behind NATs or firewalls. The forward path is well tested, deployed, with firewall traversal rules. The backwards path is not. - this would involve defining a new port (maybe), new packet codes (could we re-use Status-Server?), and new behavior. The existing practice has multiple implementations, is widely used, and meets most of the needs for client to server status checking. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 15 Jun 2008 07:41:19 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: , "'David B. Nelson'" Subject: RE: Request for Review: Status Server Document Date: Sun, 15 Jun 2008 14:38:34 +0700 Message-ID: <001501c8ceba$db05d2d0$91117870$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AcjORLUCxGUYP/aBSEq/Jkajt8aXSQAdaJFA Content-Language: en-us Alan DeKok [mailto://aland@deployingradius.com] writes: > David B. Nelson wrote: > >> And the charter prevents us from creating more RADIUS codes... > > > > Not anymore! :-) Here are the only restrictions in the *revised* > charter: > > Temptation... > > Adding Ping-Check and Ping-Ack would be nice in theory. But given > existing implementations, I'm not sure there's any benefit in doing so. Existing implementations or not, RADIUS "ping" is just as wasteful of processing power & bandwidth as it was 10 years ago. A far better idea IMHO is to have the server tell its clients when it recovers from a failure/admin reboot/etc. ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Jun 2008 23:07:26 +0000 From: Mike McCauley To: Alan DeKok Subject: Re: Request for Review: Status Server Document Date: Sun, 15 Jun 2008 09:05:43 +1000 User-Agent: KMail/1.8.2 Cc: "David B. Nelson" , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806150905.44022.mikem@open.com.au> On Sunday 15 June 2008 01:30, Alan DeKok wrote: > David B. Nelson wrote: > > That makes review of this document in RADEXT a little bit challenging. > > We can, of course, polish the prose and make sure that the descriptions > > are self-consistent and clear and that the organization is logical. I > > guess only those who have access to the "historical implementation" can > > discern whether the descriptions are accurate and correct. > > See ftp://ftp.cistron.nl/pub/radius. Open Source == full access. > > Version 1.6.5 has the first public implementation of Status-Server. > CVS indicates that the change was January 21, by Miquel Van Smoorenburg. > FreeRADIUS added support for Status-Server on Oct 17, 2002, "stolen > shamelessly from Cistron", according to the commit message. > > I believe that Radiator also added it around the same time. I don't > know which was first, because I don't have access to the Radiator CVS tree. Radiator had support for Status-Server from version 1.9 on 20/1/98. -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX etc on Unix, Windows, MacOS, NetWare etc. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Jun 2008 17:30:11 +0000 Message-ID: <4853FEB7.3060305@deployingradius.com> Date: Sat, 14 Jun 2008 19:24:07 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: >> And the charter prevents us from creating more RADIUS codes... > > Not anymore! :-) Here are the only restrictions in the *revised* charter: Temptation... Adding Ping-Check and Ping-Ack would be nice in theory. But given existing implementations, I'm not sure there's any benefit in doing so. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Jun 2008 15:51:18 +0000 Message-ID: <4853E8AE.4030609@elbrysnetworks.com> Date: Sat, 14 Jun 2008 11:50:06 -0400 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alan DeKok CC: radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alan DeKok wrote: > I'll add some text to the document to this effect. "Overloading > Access-Accept is horrible. RADIUS would normally use something like > Ping-Check and Ping-Ack, but implementations exist..." That would help to put the base protocol around Server-Status into historical perspective. > And the charter prevents us from creating more RADIUS codes... Not anymore! :-) Here are the only restrictions in the *revised* charter: In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176. Transport profiles should, if possible, be compatible with RFC 3539. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Jun 2008 15:36:57 +0000 Message-ID: <4853E422.9090305@deployingradius.com> Date: Sat, 14 Jun 2008 17:30:42 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > That makes review of this document in RADEXT a little bit challenging. > We can, of course, polish the prose and make sure that the descriptions > are self-consistent and clear and that the organization is logical. I > guess only those who have access to the "historical implementation" can > discern whether the descriptions are accurate and correct. See ftp://ftp.cistron.nl/pub/radius. Open Source == full access. Version 1.6.5 has the first public implementation of Status-Server. CVS indicates that the change was January 21, by Miquel Van Smoorenburg. FreeRADIUS added support for Status-Server on Oct 17, 2002, "stolen shamelessly from Cistron", according to the commit message. I believe that Radiator also added it around the same time. I don't know which was first, because I don't have access to the Radiator CVS tree. The intent of the document is most definitely *not* to document historical implementations... and leave it at that. The original implementation in Cistron did NOT validate Status-Server packets, so they could be trivially forged. As a result, the document is rather longer than I had originally intended. I expected that simply documenting the practice would be 3-4 pages, at most. Upon writing it, there were a number of loose ends that had to be cleared up, such as security. Hence the additional text. > The IESG, and the IETF at large, hold the WG, in general, and the WG > Chairs and/or Document Shepherd, in particular, accountable to assert > that the submitted draft meets certain protocol quality standards. Now, > I suppose that the quality of protocols is somewhat subjective. > Nonetheless, its uncomfortable to be held accountable for the quality of > a design that you are not able to affect in any way. I expect the WG to complain loudly if there are any problems. This seems to be historical practice in RADEXT. :) Much of the text in the document discusses security issues around the use of Status-Server, and recommended practices. I expect full review of both the security implications and recommended practices. The document is partly about historical implementations. But if those implementations are wrong, the standard should reflect that, and should standardize the correct behavior. e.g. It recommends adding Message-Authenticator to Status-Server, which Cistron did not enforce in 2001, and which FreeRADIUS did not enforce until a few years ago. > I think that we need to be clear in publishing this draft and an RFC > that the *protocol* it documents was *not* the work product of the > RADEXT WG, but rather of various historic implementors. Truth in > advertising. There are some hints at that already. I'll propose some > more explicit text as a formal RADEXT Issue. Thanks. The choice of (some) contents, response packet codes, and use of Status-Server as a "ping" are historical. Much of the rest of the document is discussion surrounding the topic. >> RADIUS has traditionally used separate status codes for requests and >> replies. Using the same code for both is about as bad (IMHO) as >> overloading Access-Accept. > > I think you're probably right. Sigh. I'll add some test to the document to this effect. "Overloading Access-Accept is horrible. RADIUS would normally use something like Ping-Check and Ping-Ack, but implementations exist..." And the charter prevents us from creating more RADIUS codes, so it would have been problematic to create Ping-Check and Ping-Ack now. Overloading Access-Accept seems to make the best of a bad situation. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Jun 2008 14:55:16 +0000 From: "David B. Nelson" To: Cc: "'Bernard Aboba'" Subject: RADEXT WG meeting at IETF-72 in Dublin Date: Sat, 14 Jun 2008 10:53:47 -0400 Message-ID: <000001c8ce2e$751fe0a0$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjOLnLOw6vZAxwtSX2n8UgCWuHrqA== The current *draft* schedule for the upcoming IETF-72 meeting is online at: https://datatracker.ietf.org/meeting/72/agenda.html As of today, a 2.5 hour slot has been scheduled for RADEXT to meet on Wednesday morning (0900-1130), July 30, 2008. Please note that the meeting agenda is not yet final and is subject to change. It's not too early to request agenda items for the RADEXT WG meeting. Please send your request to the chairs, indicating the subject, the I-D (if any) and the amount of time requested. Thanks! -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Jun 2008 13:58:24 +0000 Message-ID: <4853CE18.30108@elbrysnetworks.com> Date: Sat, 14 Jun 2008 09:56:40 -0400 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alan DeKok CC: radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alan DeKok writes... >> Why is the Server-Status "query" packet responded to by an Access-Accept >> "reply" packet? It seems to me that were over-loading the semantics of >> Access-Accept by using it in this way. Maybe that's not particularly >> harmful -- I don't know for sure -- but over-loading always seems like a Bad >> Idea (tm) to me. > > Yes it's not ideal. It's a historical practice. Yes, so Bernard has explained. That makes review of this document in RADEXT a little bit challenging. We can, of course, polish the prose and make sure that the descriptions are self-consistent and clear and that the organization is logical. I guess only those who have access to the "historical implementation" can discern whether the descriptions are accurate and correct. The IESG, and the IETF at large, hold the WG, in general, and the WG Chairs and/or Document Shepherd, in particular, accountable to assert that the submitted draft meets certain protocol quality standards. Now, I suppose that the quality of protocols is somewhat subjective. Nonetheless, its uncomfortable to be held accountable for the quality of a design that you are not able to affect in any way. Bernard raises the example of RFC 5176, which was a "bis" revision of RFC 3576. The former was not the product of any working group, AFAICT, and was not labeled as such when it was published. The RADIUS WG had closed and the RADEXT WG had not yet been conceived. I'm not sure that's an appropriate analogy. I think that we need to be clear in publishing this draft and an RFC that the *protocol* it documents was *not* the work product of the RADEXT WG, but rather of various historic implementors. Truth in advertising. There are some hints at that already. I'll propose some more explicit text as a formal RADEXT Issue. >> Wouldn't it have been possible to use the same Command Code (Server-Status) >> for *both* the query and response, with the context coming from who's doing >> the receiving? I think that would be preferable, in a number of ways. > > RADIUS has traditionally used separate status codes for requests and > replies. Using the same code for both is about as bad (IMHO) as > overloading Access-Accept. I think you're probably right. Sigh. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Jun 2008 08:33:25 +0000 Message-ID: <485380D3.9060900@deployingradius.com> Date: Sat, 14 Jun 2008 10:26:59 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > Why is the Server-Status "query" packet responded to by an Access-Accept > "reply" packet? It seems to me that were over-loading the semantics of > Access-Accept by using it in this way. Maybe that's not particularly > harmful -- I don't know for sure -- but over-loading always seems like a Bad > Idea (tm) to me. Yes it's not ideal. It's a historical practice. > Wouldn't it have been possible to use the same Command Code (Server-Status) > for *both* the query and response, with the context coming from who's doing > the receiving? I think that would be preferable, in a number of ways. RADIUS has traditionally used separate status codes for requests and replies. Using the same code for both is about as bad (IMHO) as overloading Access-Accept. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Jun 2008 22:31:15 +0000 Message-ID: From: "Bernard Aboba" To: "'David B. Nelson'" , Subject: RE: Request for Review: Status Server Document Date: Fri, 13 Jun 2008 15:30:01 -0700 Message-ID: <000e01c8cda5$04934f40$0db9edc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjFIxb4UokZVUeIQY20g6mdhMf0ZAIehPBgAAHZHiA= Content-Language: en-us >I did see the not-so-subtle hint that this document is describing *existing* >implementations, much as we did in the original RADIUS WG. The goal of the Status-Server specification is to document an existing protocol, much as RFC 5176 documented an existing protocol for dynamic authorization. That said, if there are improvements that can be made within the protocol while maintaining backward compatibility, then they should be considered. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Jun 2008 21:46:07 +0000 From: "David B. Nelson" To: Subject: RE: Request for Review: Status Server Document Date: Fri, 13 Jun 2008 17:44:19 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjFIxb4UokZVUeIQY20g6mdhMf0ZAIehPBg I have a "big picture" question to ask before I delve into further levels of detailed review and questions. Why is the Server-Status "query" packet responded to by an Access-Accept "reply" packet? It seems to me that were over-loading the semantics of Access-Accept by using it in this way. Maybe that's not particularly harmful -- I don't know for sure -- but over-loading always seems like a Bad Idea (tm) to me. Wouldn't it have been possible to use the same Command Code (Server-Status) for *both* the query and response, with the context coming from who's doing the receiving? I think that would be preferable, in a number of ways. I did see the not-so-subtle hint that this document is describing *existing* implementations, much as we did in the original RADIUS WG. The inference I draw is that redesign (i.e. helpful suggestions for alternate choices, such as the one my question raises) is not solicited or welcomed. Of course, maybe I'm simply reading too much into that wording. Anyway, why couldn't Server-Status be the RADIUS Command Code used for both queries and replies? Regards, Dave Nelson -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Jun 2008 02:17:03 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-management-authorization-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080613021501.F228E3A69ED@core3.amsl.com> Date: Thu, 12 Jun 2008 19:15:01 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management Author(s) : D. Nelson, G. Weber Filename : draft-ietf-radext-management-authorization-03.txt Pages : 24 Date : 2008-06-12 This document describes Remote Authentication Dial-In User Service (RADIUS) attributes for the authorization and service provisioning of Network Access Servers (NASes). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via framed management protocols, and for specification of a protected transport protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-management-authorization-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-12191431.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Jun 2008 12:32:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: draft-lourdelet-radext-ipv6-dhcp-00 published Date: Thu, 12 Jun 2008 14:31:10 +0200 Message-ID: Thread-Topic: draft-lourdelet-radext-ipv6-dhcp-00 published Thread-Index: AcjMiDIFvS34EaIwTtaapCJ0oDmg4Q== From: "Benoit Lourdelet (blourdel)" To: , DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1049; t=1213273850; x=1214137850; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20 |Subject:=20draft-lourdelet-radext-ipv6-dhcp-00=20published |Sender:=20; bh=jKyR5AUN4QatFAkwDOeFyvUb00SQ2CDqsfnIG56Fpds=; b=TIJJ+cCufGgP/V4gSZBJrVzUEwJuKE2EJuH2AfBLbuy4OFdlzAxYQ4W5xa INiHk7dg7+KJzlDkgxs/QpNhVMdrRhUW35visL0ctZgAqdXKtxprNbWFPIn6 pzv0bYbD7s; Authentication-Results: ams-dkim-2; header.From=blourdel@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Hello, I published a document specifying new RADIUS attributes supporting IPv6 network access to complement [RFC3162] in DHCP environments. It addresses the need to dynamically advertise DNS Server addresses and one or multiple IPv6 addresses via DHCPv6. It is available here : http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-00. txt Comments are welcome. Regards Benoit Lourdelet A new version of I-D, draft-lourdelet-radext-ipv6-dhcp-00.txt has been successfuly submitted by Benoit Lourdelet and posted to the IETF repository. Filename: draft-lourdelet-radext-ipv6-dhcp Revision: 00 Title: IPv6 RADIUS attributes for DHCP based networks Creation_date: 2008-06-12 WG ID: Independent Submission Number_of_pages: 8 Abstract: This document specifies RADIUS [RFC2865] attributes supporting IPv6 network access to complement [RFC3162] in DHCP environments. It addresses the need to dynamically advertise DNS Server addresses and one or multiple IPv6 addresses via DHCPv6. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Jun 2008 11:58:07 +0000 From: "Glen Zorn" To: "'David B. Nelson'" Cc: Subject: RE: RADEXT Issue 256 (NAS management Authorization) Date: Thu, 12 Jun 2008 18:56:35 +0700 Message-ID: <00ae01c8cc83$6524ed00$2f6ec700$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit thread-index: AcjMRJwr5xfIA5vxTFuB/Ld71A1jFwANr4owAABg/sAAATV2IAAAUj4A Content-Language: en-us David B. Nelson [mailto:d.b.nelson@comcast.net] writes: > > Does it really matter? > > If a protocol is no longer used, why bother include it in the list? I'm sure somebody somewhere is using rcp (possibly even Kerberized) for example, esp. if their NAS is *nix-based. Why not? > > > If they will be included in the list, just include them w/o editorial > > comment... > > Yeah, that sounds like good advice. > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Jun 2008 11:47:38 +0000 From: "David B. Nelson" To: "'Glen Zorn'" Cc: Subject: RE: RADEXT Issue 256 (NAS management Authorization) Date: Thu, 12 Jun 2008 07:46:49 -0400 Message-ID: <015f01c8cc82$017a0d90$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcjMRJwr5xfIA5vxTFuB/Ld71A1jFwANr4owAABg/sAAATV2IA== > Does it really matter? If a protocol is no longer used, why bother include it in the list? > If they will be included in the list, just include them w/o editorial > comment... Yeah, that sounds like good advice. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Jun 2008 11:34:22 +0000 From: "Glen Zorn" To: "'David B. Nelson'" , Cc: , "'Bernard Aboba'" Subject: RE: RADEXT Issue 256 (NAS management Authorization) Date: Thu, 12 Jun 2008 18:32:23 +0700 Message-ID: <00aa01c8cc80$06ecedd0$14c6c970$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit thread-index: AcjMRJwr5xfIA5vxTFuB/Ld71A1jFwANr4owAABg/sA= Content-Language: en-us David B. Nelson writes: > > I am not sure there is evidence that scp has been largely replaced by > > sftp. I suggest to simply remove the last sentence. > > What about RCP? It is still in use, or has it been [somewhat | > largely] > replaced by {SCP | SFTP}? Does it really matter? If they will be included in the list, just include them w/o editorial comment (especially based upon a source like Wikipedia ;-). > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Jun 2008 11:02:13 +0000 From: "David B. Nelson" To: Cc: , "'Bernard Aboba'" Subject: RE: RADEXT Issue 256 (NAS management Authorization) Date: Thu, 12 Jun 2008 07:00:51 -0400 Message-ID: <015501c8cc7b$9594a690$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcjMRJwr5xfIA5vxTFuB/Ld71A1jFwANr4ow > I am not sure there is evidence that scp has been largely replaced by > sftp. I suggest to simply remove the last sentence. What about RCP? It is still in use, or has it been [somewhat | largely] replaced by {SCP | SFTP}? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Jun 2008 04:25:11 +0000 Date: Thu, 12 Jun 2008 06:23:53 +0200 From: Juergen Schoenwaelder To: "David B. Nelson" Cc: radiusext@ops.ietf.org, 'Bernard Aboba' Subject: Re: RADEXT Issue 256 (NAS management Authorization) Message-ID: <20080612042353.GA2297@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: "David B. Nelson" , radiusext@ops.ietf.org, 'Bernard Aboba' MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) On Wed, Jun 11, 2008 at 08:34:23PM -0400, David B. Nelson wrote: > o SCP: Secure CoPy file copy utility (Unix-based), used to transfer > configuration files to and from the NAS. SCP has been largely > replaced by SFTP. I am not sure there is evidence that scp has been largely replaced by sftp. I suggest to simply remove the last sentence. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Jun 2008 00:35:50 +0000 From: "David B. Nelson" To: Cc: "'Bernard Aboba'" Subject: RE: RADEXT Issue 256 (NAS management Authorization) Date: Wed, 11 Jun 2008 20:34:23 -0400 Message-ID: <010c01c8cc24$11205640$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcjL36U2arTmS5tUSDGUWXJpwz7AOQAQy87w One of the comments in Issue 256 was to add references for all of the management protocols (methods?) enumerated for the Framed-Management-Protocol Attribute in Section 8.1 In researching stable references, I discovered two issues: (1) Some of these don't have good, stable references, such as standards documents, but seem to be documented by UNIX "man pages". (2) Some of these have supposedly been largely replaced in common usage. The straw-man text that I now have looks like this: o SNMP: Simple Network Management Protocol. [RFC3411], [RFC3412], [RFC3413], [RFC3414], [RFC3415], [RFC3416], [RFC3417], [RFC3418] o Web-based: Use of an embedded web server in the NAS for management via a generic web browser client. The interface presented to the administrator may be graphical, tabular or textual. The protocol is HTML over HTTP. The protocol may optionally be HTML over HTTPS, i.e. using HTTP over TLS. o NETCONF: Management via the NETCONF protocol using XML over supported transports (e.g. SSH, BEEP, SOAP). As secure transport profiles are defined for NETCONF, the list of transport options may expand. [RFC4741], [RFC4742], [RFC4743], [RFC4744] o FTP: File Transfer Protocol, used to transfer configuration files to and from the NAS. [RFC0959] o TFTP: Trivial File Transfer Protocol, used to transfer configuration files to and from the NAS. [RFC1350] o SFTP: SSH File Transfer Protocol, used to securely transfer configuration files to and from the NAS. SFTP uses the services of SSH. (http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13) o RCP: Remote CoPy file copy utility (Unix-based), used to transfer configuration files to and from the NAS. RCP has bee largely replaced by SFTP. o SCP: Secure CoPy file copy utility (Unix-based), used to transfer configuration files to and from the NAS. SCP has been largely replaced by SFTP. IIRC, RCP and TFTP were added to a previous draft version to resolve previous review comments. It is reported (e.g. Wikipedia) that SFTP is now preferred to both RCP and SCP. I would like to get some feedback from the WG prior to submitting the -03 version, as to whether: (1) Are all of these methods of copying configuration files to a NAS in current use? (2) Are the cited references (or lack thereof) sufficient to our needs? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 Jun 2008 16:20:07 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_101a4be9-71a3-45e1-8ee8-03d2e0a95a1a_" From: Bernard Aboba To: "David B. Nelson" , Subject: RE: RADEXT Issue 256 (NAS management Authorization) Date: Wed, 11 Jun 2008 09:18:39 -0700 MIME-Version: 1.0 --_101a4be9-71a3-45e1-8ee8-03d2e0a95a1a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > When a NAS receives a Framed-Management-Protocol attribute in an > Access-Accept packet, it MUST deliver that specified form of management > access or disconnect the session. If the NAS does not support the > provisioned management application-layer protocol, or the management acce= ss > protocol requested by the user does not match that of the > Framed-Management-Protocol attribute in the Access-Accept packet, the NAS > must treat the response packet as if it had been an Access-Reject. [BA] Should this be "MUST"? Presumably if the NAS supports the new Service= -Type, then it is also required to understand the Framed-Management-Protocol attri= bute and take the above action in response to an unsupportable value. =20 > It is RECOMMENDED that the NAS include an appropriately valued > Management-Transport-Protection attribute in Access-Request packet, ^an > indicating the level of transport protection for the management access be= ing > requested, when that information is available to the RADIUS Client. The > RADIUS Server MAY use this hint attribute in making its authorization > decision. >=20 > The RADIUS Server MAY include a Management-Transport-Protection attribute= in > an Access-Accept packet that also includes a Service-Type attribute with = a > value of Framed-Management, when the RADIUS Server chooses to enforce an > management access security policy for the authenticated user, that dictat= es > a minimum level of transport security. >=20 > When a NAS receives a Management-Transport-Protection attribute in an > Access-Accept packet, it MUST deliver the management access over a transp= ort > with equal or better protection characteristics or disconnect the session= . > If the NAS does not support protected management transport protocols, or = the > level of protection available does not match that of the > Management-Transport-Protection attribute in the Access-Accept packet, th= e > NAS must treat the response packet as if it had been an Access-Reject. "must" -> "MUST" as above.=20 Also, I'd suggest capitalizing the word "Attribute" when referring to a spe= cific attribute, as was the custom in RFC 2865.=20 > So, you're suggesting that I not expect IANA to search through the docume= nt > for all the (TBA) placeholders, but rather enumerate all the requests her= e? > OK, I can do that in version -03. Yes. This makes it easier for them.=20 --_101a4be9-71a3-45e1-8ee8-03d2e0a95a1a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> When a NAS receives a Framed-Management-Protocol attribute in an> Access-Accept packet, it MUST deliver that specified form of managem= ent
> access or disconnect the session. If the NAS does not support = the
> provisioned management application-layer protocol, or the manag= ement access
> protocol requested by the user does not match that of = the
> Framed-Management-Protocol attribute in the Access-Accept packe= t, the NAS
> must treat the response packet as if it had been an Acce= ss-Reject.

[BA] Should this be "MUST"?  Presumably if the NAS s= upports the new Service-Type,
then it is also required to understand the= Framed-Management-Protocol attribute
and take the above action in respo= nse to an unsupportable value. 

> It is RECOMMENDED that th= e NAS include an appropriately valued
> Management-Transport-Protecti= on attribute in Access-Request packet,
     &nb= sp;            =             &nb= sp;            =             &nb= sp;            = ^an

> indicating the level of transport protection for the manag= ement access being
> requested, when that information is available to= the RADIUS Client. The
> RADIUS Server MAY use this hint attribute = in making its authorization
> decision.
>
> The RADIUS S= erver MAY include a Management-Transport-Protection attribute in
> an= Access-Accept packet that also includes a Service-Type attribute with a> value of Framed-Management, when the RADIUS Server chooses to enforce= an
> management access security policy for the authenticated user, t= hat dictates
> a minimum level of transport security.
>
>= ; When a NAS receives a Management-Transport-Protection attribute in an
= > Access-Accept packet, it MUST deliver the management access over a tra= nsport
> with equal or better protection characteristics or disconnec= t the session.
> If the NAS does not support protected management tra= nsport protocols, or the
> level of protection available does not mat= ch that of the
> Management-Transport-Protection attribute in the Acc= ess-Accept packet, the
> NAS must treat the response packet as if it = had been an Access-Reject.

"must" -> "MUST" as above.

Als= o, I'd suggest capitalizing the word "Attribute" when referring to a specif= ic
attribute, as was the custom in RFC 2865.


> So, you're= suggesting that I not expect IANA to search through the document
> f= or all the (TBA) placeholders, but rather enumerate all the requests here?<= br>> OK, I can do that in version -03.

Yes.  This makes it e= asier for them.
= --_101a4be9-71a3-45e1-8ee8-03d2e0a95a1a_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 Jun 2008 11:56:40 +0000 From: "David B. Nelson" To: Cc: "'David Harrington'" Subject: RE: RADEXT Issue 255 (NAS Management Authorization) Date: Wed, 11 Jun 2008 07:55:24 -0400 Message-ID: <004501c8cbba$09f66f40$011716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcjLJiyZ7GBA+PiHS3yKNe2aQJRrJQAcRMqgAAgOVmA= Glen Zorn writes... > It's not at all clear to me that "Web services" qualifies as any type > of protocol at all. I wasn't proposing that we formally characterize embedded web management, as it's deployed in many NASes today, as "web services". There is something of a nomenclature issue here, though, specifically how best to "name" the form of management that uses an embedded web server to serve up web pages (HTML content) over the HTTP application-layer protocol to a web browser application? The issue is not that HTML/HTTP fails describe the protocol, but rather that other things besides management can be served in this fashion. It's my understanding that lots of things are "tunneled" in HTTP these days, firewall avoidance being but one reason. What's important, at the end of the day, is that there be an unambiguous binding between the values of this attribute and the framed (i.e. non-textual) management mechanisms they represent. > I think that the Attribute needs to be renamed -- maybe > "Framed-Management-Method"? I have no objection to that choice of attribute name, but I'm wondering if it really addresses the underlying issue. The issue is to pick one identifying characteristic of framed management to serve as the "name". The application layer protocol seemed a logical choice. Does anyone else have thoughts to share on this, one way or another? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 Jun 2008 08:08:44 +0000 Date: Wed, 11 Jun 2008 10:07:45 +0200 From: Juergen Schoenwaelder To: Glen Zorn Cc: "'David B. Nelson'" , 'David Harrington' , radiusext@ops.ietf.org Subject: Re: RADEXT Issue 255 (NAS Management Authorization) Message-ID: <20080611080745.GB817@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: Glen Zorn , "'David B. Nelson'" , 'David Harrington' , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) On Wed, Jun 11, 2008 at 02:58:21PM +0700, Glen Zorn wrote: > David B. Nelson writes: > > > > 8.1 (and elsewhere) > > > Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or > > > HTML/HTTP? > > > > The attribute in question, Framed-Management-Protocol, is used to > > describe a > > management *application-layer* protocol. SNMP clearly qualifies. An > > integrated web server, providing management via web pages, also > > qualifies, > > It's not at all clear to me that "Web services" qualifies as any type of > protocol at all. W3C defines a "Web service" as ""a software system > designed to support interoperable Machine to Machine interaction over a > network." Certainly, this definition requires the operation of one or more > network protocols but there is no requirement that HTTP be one of them. I > think that the Attribute needs to be renamed -- maybe > "Framed-Management-Method"? I had the same reaction but then I read the text that is contained in the ID and found that rather clear. And yes, it helps to avoid the phrase "web services". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 Jun 2008 08:00:51 +0000 From: "Glen Zorn" To: "'David B. Nelson'" Cc: "'David Harrington'" , , Subject: RE: RADEXT Issue 255 (NAS Management Authorization) Date: Wed, 11 Jun 2008 14:58:21 +0700 Message-ID: <000901c8cb98$f557ab10$e0070130$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjLJiyZ7GBA+PiHS3yKNe2aQJRrJQAcRMqg Content-Language: en-us David B. Nelson writes: > > 8.1 (and elsewhere) > > Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or > > HTML/HTTP? > > The attribute in question, Framed-Management-Protocol, is used to > describe a > management *application-layer* protocol. SNMP clearly qualifies. An > integrated web server, providing management via web pages, also > qualifies, It's not at all clear to me that "Web services" qualifies as any type of protocol at all. W3C defines a "Web service" as ""a software system designed to support interoperable Machine to Machine interaction over a network." Certainly, this definition requires the operation of one or more network protocols but there is no requirement that HTTP be one of them. I think that the Attribute needs to be renamed -- maybe "Framed-Management-Method"? ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Jun 2008 20:26:13 +0000 From: "David B. Nelson" To: Cc: "'Bernard Aboba'" Subject: RADEXT Issue 256 (NAS management Authorization) Date: Tue, 10 Jun 2008 16:24:44 -0400 Organization: Elbrys Networks, Inc. Message-ID: <3F78A531608E4E46B5AA90F8B92EF385@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjLOAUO9iNIu5F7SDe+sKZWp0fiFw== > Abstract > > The current text is a bit wordy. How about this? > > This document describes Remote Authentication Dial-In User > Service (RADIUS) attributes for the authorization and service > provisioning of Network Access Servers (NASes). Both local and > remote management are supported, with granular access rights > and management privileges. Specific provisions are made for > remote management via framed management protocols, and for > specification of a protected transport protocol. Sounds good to me. Will fix on -03. > Section 7.1 > > I don't think you need to repeat much of Section 5.6 of RFC 2865. > Why not just reference it instead? Here is some recommended text > for this section: > > 7.1. Service-Type > > The Service-Type attribute is defined in Section 5.6 of RFC 2865 > [RFC2865]. This document defines a new value of the Service-Type > Attribute: > > (TBA) Framed-Management > > The semantics of the Framed-Management service are as follows: > > Framed-Management A framed management protocol session should > be started on the NAS. OK. Will revise on -03. > Section 8.1 > > The Framed-Management-Protocol attribute indicates the application- > layer management protocol to be used for framed management access. > It MAY be used in both Access-Request and Access-Accept packets. > > Please add a sentence explaining the semantics in this usage. For > example, in the Access-Request I assume that this Attribute describes > the protocol that the client is using for remote administration. Yes. > What does it mean in an Access-Accept? The same thing that any other service provisioning attribute means -- start the described service for the user's connection. Typically these things are decided by the RADIUS Server based on the user's account profile information and any relevant hint attributes. > For example, what does the NAS do if the value in the Access- > Accept is different from the protocol that is being used? Does > it disconnect? Yes. It would also disconnect if the provisioned service is not supported in the NAS. How about the following for clarifying text? It is RECOMMENDED that the NAS include an appropriately valued Framed-Management-Protocol attribute in Access-Request packet, indicating the type of access being requested, when the user requests a form of remote management via a framed management application protocol. It is further RECOMMENDED that the NAS include a Service-Type attribute with the value Framed-Management (TBA) in the same Access-Request packet. The RADIUS Server MAY use these hint attributes in making its authorization decision. The RADIUS Server MAY include a Framed-Management-Protocol attribute in an Access-Accept packet that also includes a Service-Type attribute with a value of Framed-Management, when the RADIUS Server chooses to enforce an management access policy for the authenticated user, that dictates one form of management access in preference to others. When a NAS receives a Framed-Management-Protocol attribute in an Access-Accept packet, it MUST deliver that specified form of management access or disconnect the session. If the NAS does not support the provisioned management application-layer protocol, or the management access protocol requested by the user does not match that of the Framed-Management-Protocol attribute in the Access-Accept packet, the NAS must treat the response packet as if it had been an Access-Reject. > Section 8.2 > What packets can this attribute be included in? Access-Request & > Access-Accept? Yes. Also Accounting-Request for session logging purposes. > What are the semantics in each case? For example, in an > Access-Request is this the level of protection that is being used? Yes. This will be communicated to the RADIUS Client from the respective management application, to the extent that application is aware of the protection level of its underlying transport. > What if the value in an Access-Accept is different (e.g. higher) > than that in use? For example, if confidentiality & integrity is > being requested, but the session is protected with TLS and an > integrity-only ciphersuite? Is the session dropped? Yes. Do we need clarifying text, such as I proposed for the Framed-Management-Protocol attribute (see above)? Such clarifying text might read as follows: It is RECOMMENDED that the NAS include an appropriately valued Management-Transport-Protection attribute in Access-Request packet, indicating the level of transport protection for the management access being requested, when that information is available to the RADIUS Client. The RADIUS Server MAY use this hint attribute in making its authorization decision. The RADIUS Server MAY include a Management-Transport-Protection attribute in an Access-Accept packet that also includes a Service-Type attribute with a value of Framed-Management, when the RADIUS Server chooses to enforce an management access security policy for the authenticated user, that dictates a minimum level of transport security. When a NAS receives a Management-Transport-Protection attribute in an Access-Accept packet, it MUST deliver the management access over a transport with equal or better protection characteristics or disconnect the session. If the NAS does not support protected management transport protocols, or the level of protection available does not match that of the Management-Transport-Protection attribute in the Access-Accept packet, the NAS must treat the response packet as if it had been an Access-Reject. > o Confidentiality-Protection: The management session requires > protection in a secure or protected transport, that is supported > by the management access protocol and implementation. The secure > transport MUST provide Confidentiality Protection. > > Does this option really make sense? When would you want Confidentiality > but not integrity? Isn't this dangerous? This was discussed at IETF-71 and the proposal was to remove the Confidentiality (only) option. I propose to do that in the -03 version. > Section 9 > > The examples use the Transport-Protocol Attribute, which is not > defined in this document any more. Editorial cruft. Will fix in -03. > Also, please include the value of NAS-Port-Type in the examples. OK. > Section 11 > > I'd recommend moving this to a sub-section under Security > Considerations. Hmmm. Much of this discussion has impact on security, on the other hand, I think that Proxy Considerations is a separate topic that justifies treatment in a separate section, for emphasis. I don't have a strong opinion on this, but my initial reaction is to suggest that we leave it in a separate section. > Section 13 > > This section needs to be rewritten to list the new attribute for which > numbers being requested, as well as the new value for Service-Type. So, you're suggesting that I not expect IANA to search through the document for all the (TBA) placeholders, but rather enumerate all the requests here? OK, I can do that in version -03. All other comments in Issue 256, not otherwise discussed here are accepted and will appear in the -03 version. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Jun 2008 18:27:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=6CdLSnrJCQNHmPUgsNpT8vgHLgf09K3ep9cIOaatS2Y=; b=uM1GO0MekFmzQkwkVcIhX9PV+wBvF+HLW8v/sRME5yI3X/1eunJFeZdnDA8OiJPuNh 4lngjfNiIByLiIAp+/dqGFVezK1EBiERCYjzVBVAAOoHWBQEt+n4ROds8ddRo9o9o82W QOb6AzIwpRcL0SHWDJrh3tOD/EQsvdV/A25K0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=iUXLtwhxVfkU9h63tcYDNEwa+9WenGgcs6bn0a6/QFrPJs5AJ48u9hN5s18MEvS5c6 iWPcFgqR+Wi+Ax9zpQ72C5DMeKU/Zt6SJmknQiyXfcgwoHDBVdmN9UTyYtnaUzbi6Sft lTd8U2c/S+AfSjTv7A5pvf4D5wZ+kLMGGNtjE= Message-ID: Date: Tue, 10 Jun 2008 14:26:55 -0400 From: "Greg Weber" To: "David B. Nelson" Subject: Re: RADEXT Issue 255 (NAS Management Authorization) Cc: radiusext@ops.ietf.org, "David Harrington" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> Should we develop acronyms NETCONFS and SNMPS and CLIS so we can just >> lump the non-secure and secure versions into Configuration-based, and >> Polling-based names and so on? > > I don't think that this document is the right vehicle to define new > nomenclature for existing management services and protocols. > > I'm open to devising some clarifying text here, but I think we need to keep > the scope of semantics for this attribute narrow, i.e. limited to indication > of the management application-layer protocol. Slightly less diplomatically, RADEXT is having trouble tying its own shoestrings. We don't need to worry about the shoes of others... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Jun 2008 18:18:21 +0000 From: "David B. Nelson" To: Cc: "'David Harrington'" Subject: RADEXT Issue 255 (NAS Management Authorization) Date: Tue, 10 Jun 2008 14:17:00 -0400 Organization: Elbrys Networks, Inc. Message-ID: <5FF9CBDF54F34CDAAE42532D4E1544AE@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjLJiyZ7GBA+PiHS3yKNe2aQJRrJQ== > 8.1 (and elsewhere) > Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or > HTML/HTTP? The attribute in question, Framed-Management-Protocol, is used to describe a management *application-layer* protocol. SNMP clearly qualifies. An integrated web server, providing management via web pages, also qualifies, although a web server is by no means limited to management applications -- all sorts of applications can be implemented using a web services model. When we get to options such as FTP, which means to describe provisioning of management information by "file copy", the distinction is even less clear. File copy operations are used for all sorts of things besides network device management. This attribute is not attempting to describe a transport protocol. We had one of those in a prior version and it was eliminated based on comments received. Attempting to provision the transport protocol was causing confusion without adding any offsetting value. The value (2) of the Framed-Management-Protocol means a web-services based management interface. Yes, it uses HTTP, but the meaning that is intended here is restricted to a web server application for the purpose of device management. > Should we develop acronyms NETCONFS and SNMPS and CLIS so we can just > lump the non-secure and secure versions into Configuration-based, and > Polling-based names and so on? I don't think that this document is the right vehicle to define new nomenclature for existing management services and protocols. I'm open to devising some clarifying text here, but I think we need to keep the scope of semantics for this attribute narrow, i.e. limited to indication of the management application-layer protocol. > section 8.2 > "The same "No Protection" semantics are conveyed by omitting this > attribute from an Access-Accept packet." > Why is this the default behavior? Wouldn't it be better to default > to full security if the attribute is not present? I believe that would violate the RADEXT Charter restriction on maintaining backwards compatibility / interoperability with existing RADIUS standards and fielded implementations. I propose to reject this comment. > Section 8.3 > Paragraph 3 says what to do if one is received; and paragraph talks > about receiving more than one. What if zero are received? RADIUS clients and servers must always be prepared to *not* receive any optional attribute in any message. There can be no implicit semantics of a "missing" attribute other than to "do nothing" as regards the semantics of that particular attribute. In the case of Management-Policy-Id, the absence of an attribute means that the NAS applies no management access control/filtering policy. This basic to the operation of the RADIUS protocol, and it is assumed that readers are familiar with that behavior. Do you think it needs to be reiterated here? Paragraph 3 says what to do if one is received; and paragraph talks about receiving more than one. What if zero are received? > Paragraph 3 says if "the policy rules are incorrectly > formatted, the NAS MUST treat the packet as if it had been an > Access-Reject." > > Doesn't this potentially override what the management protocol says > should be done if the rules are incorrectly formatted? If the underlying management protocol has default rules, in the absence of any additional provisioning by RADIUS, then these would still apply. > If the mgmt protocol defines an error condition for incorrectly > formatted rules, that error won't be sent because the session is > rejected, right? Yes. However, I don't think we ought to go down the path of inserting RADIUS in the middle of a client-server (or peer-peer) applications layer protocols, management or otherwise. The standard RAIUS behavior (it has always been so) is that if the client receives an attribute that it can interpret, i.e. that it supports, and it cannot decipher or correctly act upon the value of the attribute, it must "punt" the session, rather than risk misunderstanding the intent of the system administrator and allowing more service access than was originally desired. This is almost always a case of misconfiguration, and it is assumed that human intervention by the system administrator will be required to resolve it. > What happens if it is considered incorrect formatting to have an empty > table of rules, but the operator is trying to gain mgmt access to set > the policy rules into the table? Would RADIUS even know whether the > rules were incorrectly formatted? The RADIUS client itself would likely not know, but another portion of the NAS software that is responsible for making the rules take effect would very likely know, and would be able to return an error code to the RADIUS client. This is simply a case of making sure that the security configuration is valid before you enable security checking. One more case of "locking the keys in the car" if you are not careful. Make sure you have the key before you push down the lock button. :-) I think we could add some sort if "Implementation Note" warning users of the potential issue. I don't think we want to dilute the security by requiring that the RADIUS client attempt to "second guess" configuration errors in favor of granting [greater] access. > section 8.4 > I don't understand why we need a special Management-Privilege-Level > attribute. This should be able to specified as a named policy in the > Management-Policy-ID, such as "Level 1" and "Level 2", or even "1" and > "2" and "3". Implementations simply need to map between the policy > name and their privilege-level policy implementation. This attribute was added to support legacy access level mechanisms that are integer-value based, without conflating them with the newer text-string-valued, policy-named based mechanism. In the "green fields" case, i.e. in the absence of a fairly wide deployment of the legacy mechanism, I would fully agree with you. What you suggest *could* be made to work. I think it has greater risk because of its interaction with legacy mechanisms. I would propose to retain the separate attributes, unless there is WG consensus to combine them. > section 9: > I have a concern about protocol versions. What if I want SSHv2 > because I don't think SSHv1 is adequate? Should I be able to make the > distinction? or is that simply an operator-provisioning task to > disallow SSHv1 to the device? I would argue it ought to be the latter. It is not always clear where to draw the line as to how granular AAA-based provisioning ought to be. AAA-based provisioning is not intended to supplant all operator provisioning requirements. I've been attempting to apply the "less is more" philosophy in the absence of a clear use-case that dictates "more is more". :-) > Section 9: > Example #5 mentions SNMPv3, but the attribute says only SNMP. Ooops. Editorial cruft. Will fix in -03. > Section 9: > I would change the paragraph in example #5: > OLD: Note that there is currently no standardized way of > implementing this management policy mapping within SNMPv3. Such > mechanisms are implementation specific. > NEW: "A standardized way of mapping from Management-Policy-ID to a > particular access control policy in SNMP is under research." OK. Will fix in -03. > Section 9: > Example #6 talks about using the Secure Shell Transport Model, > but most existing SNMP implementations do not support this yet. >The "transport model" approach supports a binding between the SSH > authenticated identity and the SNMP database access controls. Some > SNMP implementations support running SNMP (any version) over an > SSH tunnel, but they provide no such binding. I think it is an > SNMP internal matter for SNMP access controls to say "they must > use transport model to get database access". So I would remove > the mention of the Secure Shell Transport Model from the example: > OLD: 6. SNMP secure Transport Model access, using the Secure Shell > Transport Model: > NEW: 6. SNMP access, via a fully-protected secure tunnel of SSH, > to an undefined management access level: OK. Will fix in -03. > Section 9: > Example#8 doesn't mention which transport protocol should be > used to provide security services. Should it, or is it intentional > to allow any transport protocol be used that can provide > Confidentiality-Protection? We've previously decided to not provision the specific transport protocol, but rather to only provision the security properties of the protocol. This is another of those "less is more" arguments. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Jun 2008 17:55:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=T8NGMvD3jKyZWQnw4aCOD3Pbqag3gUZpyQ6VraBAN14=; b=QdRRmtjqnPSCxeRXtFpc22rOVQiSDe3PQRykZsLxMOAS1i8a42Nem2KbX0+SBknEQ8 RnkpJja7E1N54f1sdk+F30F10KO/XiFcDYzqvYt6x4ysUnjqQt7V8oaiILdrmgFmjVXi 9UuUcqUyW0qw0dkRwJ4Ws662ZV/SajLBXicxs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=sL39U70UV/u+0gzdnSHcwfV+9SO3bnjBbNBiU5shA/UAqWrigQ13nHqyNL9lhQi1PT ulYWdMHFB+d+Rrdce2Jm1ZaCplQIGhvYLd/3VAhYlH4u9A7JzyIuK5KqY5XABg3QCsC/ pO47JsrpKnGhrU8p99MVW7oOkcZYk2h+C8NQs= Message-ID: Date: Tue, 10 Jun 2008 13:54:17 -0400 From: "Greg Weber" To: radiusext@ops.ietf.org Subject: [Issue 255]: NAS mgmt author MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I have a comment on this subissue from #255 on RADIUS author. This is from the issue list: "section 8.4 I don't understand why we need a special Management-Privilege-Level attribute. This should be able to specified as a named policy in the Management-Policy-ID, such as "Level 1" and "Level 2", or even "1" and "2" and "3". Implementations simply need to map between the policy name and their privilege-level policy implementation. Different implementations might handle priivilege levels differently - some might use integers internally, others might use a different range of values (0-15 vs 1-16). Using Management-Policy-ID makes this simply a mapping exercise. This is a great opportunity to suggest standard names for privilege levels, and then vendors can map those standard names to the internal routines. If vendors provide an API, operators could name the policies as they wanted and map them to the vendors' APIs for invoking different privilege levels." -- Actually, I think this is likely to lead to problems. Conceptually, i agree, but this privilege level concept is quite entrenched. And having a language- specific 'textization' of this is likely to lead to more incompatibility going fwd. I also don't think RADEXT is the correct place to "suggest standard names for privilege levels". -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Jun 2008 17:08:47 +0000 From: "David B. Nelson" To: Subject: RADEXT Issue 254 (NAS Management Authorization) Date: Tue, 10 Jun 2008 13:07:54 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjLHIWZ1UmIv2vIT1GAl0dTSfdXqg== All Issue 254 comments are accepted and will appear in the -03 version. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Jun 2008 17:07:48 +0000 From: "David B. Nelson" To: Subject: RADEXT Issue 253 (NAS management Authorization) Date: Tue, 10 Jun 2008 13:06:13 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjLHElvSttDqdaBT++kmr6A4WroWA== > throughout: > "Note that" is usually unnecessary. Don't we want readers to note > everything in the document, or we wouldn't have said it? Accepted, except for the occurrence within the standard boilerplate text. :-) > section 14: > this mentions accounting, but accounting is explicitly out of scope > for this document. I propose to reject this comment. Nothing in this draft says that accounting is out of scope. It is common practice to allow service provisioning attributes to appear in Accounting-Request messages for the purpose of session logging and auditing. The commenter may be thinking of the RADIUS Usage for SNMP Transport Models document, in which accounting is out of scope. All other Issue 253 comments are accepted, and will be reflected in the -03 version. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Jun 2008 05:31:09 +0000 Message-ID: <484E1130.8050105@restena.lu> Date: Tue, 10 Jun 2008 07:29:20 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Request for Review: Status Server Document Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, | This is a request for review of the Status Server document for the | purposes of considering it for adoption as a RADEXT WG work item. I'm in favour of adoption. Stefan Winter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIThEv+jm90f8eFWYRAorWAJ48jk1VlAvwqMuFeehiij2xAdg0EQCfeezv vIUvmGv/tsmwEI4102vml8Q= =viA9 -----END PGP SIGNATURE----- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 05 Jun 2008 12:15:42 +0000 From: "David B. Nelson" To: Subject: RE: Request for Review: RADSEC Specification Date: Thu, 5 Jun 2008 08:14:17 -0400 Message-ID: <042501c8c705$aed779a0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjFIxXHK04VnmjJTEuODWVFnfs6+AAOZVqgAAMw6SAAXjdw4AAIfU1w Glen Zorn writes... > Hmm, yes, a policy that has worked wonders in speeding up progress... RADEXT has been slow in making progress at times, but I think this particular policy has no direct bearing on that. It has neither speeded up nor slowed down the rate of progress. The root cause of the "rate of progress" issue lies elsewhere. > OK, so I thought that the lengthy discussion of whether or not to add > RadSec as a work item was about the protocol as described in the existing > draft; we even talked about some of the changes necessary to this > document. Am I to understand that those debates were actually about > adopting some theoretical concept of RADIUSoTLS/TCP as a work item? There is a procedural separation of concerns between adding a work item to a WG charter and adopting a specific individual draft as the WG's chosen vehicle to complete that work item. As a WG chair yourself, I suspect that you understand that distinction. I'm not saying that I expect a competing document to be offered up. I'm simply answering your process question. There are separate process steps; we are following them. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 05 Jun 2008 08:11:11 +0000 From: "Glen Zorn" To: "'David B. Nelson'" , Subject: RE: Request for Review: RADSEC Specification Date: Thu, 5 Jun 2008 15:09:17 +0700 Message-ID: <009801c8c6e3$7b2187d0$71649770$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjFIxXHK04VnmjJTEuODWVFnfs6+AAOZVqgAAMw6SAAXjdw4A== Content-Language: en-us David B. Nelson [mailto://d.b.nelson@comcast.net] writes: > Glen Zorn writes... > > > I'm a little confused: since the recently approved charter lists > > RadSec as a work item (even calling it out by name: '.specifications > > for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS'), > > I'm not sure what the point of this is or what the alternatives > > might be. > > The question is whether the subject individual draft is sufficiently > complete and well written to become a WG work item. As you may recall, > we > expect WG -00 drafts to be reasonably mature. Hmm, yes, a policy that has worked wonders in speeding up progress... > > That alternative is that it could stay as an individual draft for more > polishing, or some alternative draft fulfilling the same WG charter > milestone could be presented for consideration. OK, so I thought that the lengthy discussion of whether or not to add RadSec as a work item was about the protocol as described in the existing draft; we even talked about some of the changes necessary to this document. Am I to understand that those debates were actually about adopting some theoretical concept of RADIUSoTLS/TCP as a work item? ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 03 Jun 2008 11:10:06 +0000 From: "David B. Nelson" To: Subject: RE: Request for Review: RADSEC Specification Date: Tue, 3 Jun 2008 07:08:35 -0400 Message-ID: <014e01c8c56a$2bc93130$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcjFIxXHK04VnmjJTEuODWVFnfs6+AAOZVqgAAMw6SA= Glen Zorn writes... > I'm a little confused: since the recently approved charter lists > RadSec as a work item (even calling it out by name: '.specifications > for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS'), > I'm not sure what the point of this is or what the alternatives > might be. The question is whether the subject individual draft is sufficiently complete and well written to become a WG work item. As you may recall, we expect WG -00 drafts to be reasonably mature. That alternative is that it could stay as an individual draft for more polishing, or some alternative draft fulfilling the same WG charter milestone could be presented for consideration. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 03 Jun 2008 09:41:30 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , Subject: RE: Request for Review: RADSEC Specification Date: Tue, 3 Jun 2008 16:37:53 +0700 Message-ID: <001e01c8c55d$870fd010$952f7030$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C8C598.336EA810" thread-index: AcjFIxXHK04VnmjJTEuODWVFnfs6+AAOZVqg Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_001F_01C8C598.336EA810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes: This is a request for review of the RADSEC specification for the purposes of considering it for adoption as a RADEXT WG work item. I'm a little confused: since the recently approved charter lists RadSec as a work item (even calling it out by name: '.specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS'), I'm not sure what the point of this is or what the alternatives might be. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt Please respond to the mailing list, indicating whether your are IN FAVOR or AGAINST adoption of the document as a RADEXT WG work item. If you have comments on the document, please post these to the mailing list as well, in the format described in the RADEXT WG Issues page: http://www.drizzle.com/~aboba/RADEXT/ This request for review will conclude on June 16, 2008. ------=_NextPart_000_001F_01C8C598.336EA810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bernard Aboba  [mailto:bernard_aboba@hotmail.com] = writes:

 <= /o:p>

This is a request for review of the RADSEC specification for the = purposes of considering it for adoption as a RADEXT WG work item.

 

I'm a little confused: since the recently approved = charter lists RadSec as a work item (even calling it out by name: = '…specifications for
Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS'), I'm not = sure what the point of this is or what the alternatives might be… =


 
The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-winter-radsec= -01.txt
 
Please respond to the mailing list, indicating whether your are IN FAVOR = or AGAINST adoption of the document as a RADEXT WG work item.  If you = have comments on the document, please post these to the mailing list as well, = in the format described in the RADEXT WG Issues page:
http://www.drizzle.com/~aboba/RADEXT/
 
This request for review will conclude on June 16, 2008. =

------=_NextPart_000_001F_01C8C598.336EA810-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 03 Jun 2008 09:30:08 +0000 Message-ID: <48450DA7.4070608@deployingradius.com> Date: Tue, 03 Jun 2008 11:23:51 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: Request for Review: RADSEC Specification Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > This is a request for review of the RADSEC specification for the > purposes of considering it for adoption as a RADEXT WG work item. I am in favor of adopting it as a WG work item. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 03 Jun 2008 06:33:27 +0000 Message-ID: <4844E533.30808@restena.lu> Date: Tue, 03 Jun 2008 08:31:15 +0200 From: Stefan Winter User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Request for Review: RADSEC Specification Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, in favor of taking it as a start. Parts of it will need to be taken out to form the basis of the "Reliable Transport Profile for RADIUS". | This is a request for review of the RADSEC specification for the | purposes of considering it for adoption as a RADEXT WG work item. | | The document is available for inspection here: | http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt | | | Please respond to the mailing list, indicating whether your are IN | FAVOR or AGAINST adoption of the document as a RADEXT WG work item. | If you have comments on the document, please post these to the | mailing list as well, in the format described in the RADEXT WG | Issues page: | http://www.drizzle.com/~aboba/RADEXT/ | | This request for review will conclude on June 16, 2008. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIROUz+jm90f8eFWYRAmvgAJ0bYOrW0t2gdn3W0bL7HGi9mIof0QCeI5Vi KRmrIapopqbXZ53mP3On20M= =rGqv -----END PGP SIGNATURE----- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 03 Jun 2008 04:52:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wOuuJiKMWrLuug6CHHHFjxumcfoqKA0U2rYXUazNMZU=; b=mPQx4Y7VGFQy9z1nrHWnbFTvIvZA1ijjBQLr99xU/Tugv9mnE5IDfUGbopy3W0LT2uMm4nXvynCbTCm4rEvkvCE/zz+jj3Pwjxvko/5pc+MbOiD7r9W+PSz3Ouw8BomEWnoHz3nF5ss9/cMO+cNpBQDVSZ93oCOuElV8g0EbGxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=a9DJmnQtX2pGU2JPvmL1vDu+CELeeecNwa/Y2RaC4zgqasJjSzjLigaqPOulXxTqL9rCQ02JwB3Yx+cJEoywCgbGAoSzCrFBJRcVU0Mra7QHCyshQ7sqfBpho301vEBQzjNP8P20XUw8Du1wpM8WP5cJQpFuGg3wL6bXCjQqDRQ= Message-ID: Date: Tue, 3 Jun 2008 01:50:51 -0300 From: "Claudio Lapidus" To: "Bernard Aboba" Subject: Re: Request for Review: RADSEC Specification Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline In favor. -- On Mon, Jun 2, 2008 at 11:35 PM, Bernard Aboba wrote: > > This is a request for review of the RADSEC specification for the purposes of considering it for adoption as a RADEXT WG work item. > > The document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt > > Please respond to the mailing list, indicating whether your are IN FAVOR or AGAINST adoption of the document as a RADEXT WG work item. If you have comments on the document, please post these to the mailing list as well, in the format described in the RADEXT WG Issues page: > http://www.drizzle.com/~aboba/RADEXT/ > > This request for review will conclude on June 16, 2008. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 03 Jun 2008 03:56:40 +0000 From: Mike McCauley To: Bernard Aboba Subject: Re: Request for Review: RADSEC Specification Date: Tue, 3 Jun 2008 13:54:50 +1000 User-Agent: KMail/1.8.2 Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806031354.51138.mikem@open.com.au> IN FAVOR On Tuesday 03 June 2008 12:35, Bernard Aboba wrote: > This is a request for review of the RADSEC specification for the purposes > of considering it for adoption as a RADEXT WG work item. The document is > available for inspection > here:http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt Please > respond to the mailing list, indicating whether your are IN FAVOR or > AGAINST adoption of the document as a RADEXT WG work item. If you have > comments on the document, please post these to the mailing list as well, in > the format described in the RADEXT WG Issues page: > http://www.drizzle.com/~aboba/RADEXT/ This request for review will conclude > on June 16, 2008. -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX etc on Unix, Windows, MacOS, NetWare etc. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 03 Jun 2008 02:36:58 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_cadb739c-bcc2-49b8-b525-dea31c397de5_" From: Bernard Aboba To: Subject: Request for Review: RADSEC Specification Date: Mon, 2 Jun 2008 19:35:44 -0700 MIME-Version: 1.0 --_cadb739c-bcc2-49b8-b525-dea31c397de5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a request for review of the RADSEC specification for the purposes o= f considering it for adoption as a RADEXT WG work item. The document is av= ailable for inspection here:http://www.ietf.org/internet-drafts/draft-winte= r-radsec-01.txt Please respond to the mailing list, indicating whether your= are IN FAVOR or AGAINST adoption of the document as a RADEXT WG work item.= If you have comments on the document, please post these to the mailing li= st as well, in the format described in the RADEXT WG Issues page: http://ww= w.drizzle.com/~aboba/RADEXT/ This request for review will conclude on June = 16, 2008. = --_cadb739c-bcc2-49b8-b525-dea31c397de5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is a request for review of the RADSEC specification f= or the purposes of considering it for adoption as a RADEXT WG work item.  
The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-winter= -radsec-01.txt
 
Ple= ase respond to the mailing list, indicating whether your are IN FAVOR or AG= AINST adoption of the document as a RADEXT WG work item.  If you have = comments on the document, please post these to the mailing list as well, in= the format described in the RADEXT WG Issues page:
http://www.drizzle.com/~abob= a/RADEXT/
 
This request for review will conclude on June 16= , 2008.
= --_cadb739c-bcc2-49b8-b525-dea31c397de5_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 03 Jun 2008 02:36:20 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_f17b4ab8-15d7-41ad-85b7-a67d836a4a7b_" From: Bernard Aboba To: Subject: Request for Review: Status Server Document Date: Mon, 2 Jun 2008 19:35:04 -0700 MIME-Version: 1.0 --_f17b4ab8-15d7-41ad-85b7-a67d836a4a7b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a request for review of the Status Server document for the purposes= of considering it for adoption as a RADEXT WG work item. The document is = available for inspection here:http://www.ietf.org/internet-drafts/draft-dek= ok-radius-status-server-02.txt Please respond to the mailing list, indicati= ng whether your are IN FAVOR or AGAINST adoption of the document as a RADEX= T WG work item. If you have comments on the document, please post these to= the mailing list as well, in the format described in the RADEXT WG Issues = page: http://www.drizzle.com/~aboba/RADEXT/ This request for review will co= nclude on June 16, 2008. = --_f17b4ab8-15d7-41ad-85b7-a67d836a4a7b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is a request for review of the Status Server document for = the purposes of considering it for adoption as a RADEXT WG work item.
&= nbsp;
The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-dekok-radius-status-= server-02.txt
 
Please respond to the mailing list, indicati= ng whether your are IN FAVOR or AGAINST adoption of the document as a RADEX= T WG work item.  If you have comments on the document, please post the= se to the mailing list as well, in the format described in the RADEXT WG Is= sues page:
http://www.drizzle.com/~aboba/RADEXT/
 
This request f= or review will conclude on June 16, 2008.
= --_f17b4ab8-15d7-41ad-85b7-a67d836a4a7b_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 03 Jun 2008 02:27:55 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_0fdf7771-f4b0-408d-a1ef-27b1c5c3f1ac_" From: Bernard Aboba To: Subject: Approval of revised RADEXT WG Charter Date: Mon, 2 Jun 2008 19:26:38 -0700 MIME-Version: 1.0 --_0fdf7771-f4b0-408d-a1ef-27b1c5c3f1ac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The updated RADEXT WG charter has been approved by the IESG, and is now pos= ted on the WG web page: http://www.ietf.org/html.charters/radext-charter.html =20 = --_0fdf7771-f4b0-408d-a1ef-27b1c5c3f1ac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The updated RADEXT WG charter has been approved by the IESG, and is now pos= ted on the WG web page:
http://ww= w.ietf.org/html.charters/radext-charter.html
 
 
= --_0fdf7771-f4b0-408d-a1ef-27b1c5c3f1ac_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 03 Jun 2008 02:25:15 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_b917c35e-6cb0-4b74-9ff7-0566e3b32d75_" From: Bernard Aboba To: Subject: Consensus Call Summary: Changes to Extended Attributes Document Date: Mon, 2 Jun 2008 19:22:45 -0700 MIME-Version: 1.0 --_b917c35e-6cb0-4b74-9ff7-0566e3b32d75_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wednesday, May 7, a Consensus call was issued to the WG mailing list, in= order to confirm acceptance of the consensus call done at IETF 71, with re= spect to the changes made in the Extended Attributes Document version -01.= =20 =20 That Consensus call has now concluded. Based on the minimal mailing list r= esponse (1 response, in favor of the IETF 71 consensus), the consensus take= n at IETF 71 is judged to be AFFIRMED. =20 =20 That is:=20 =20 1. The change to the Ext-Type field (2 octets rather than 1) is APPROVED. 2= . The change to the RADIUS Extended Attribute format in (applied to existin= g standard RADIUS attributes, not just extended ones) is REJECTED. =20 Instructions to the Editor: Please submit a new document reflecting the RA= DEXT WG Consensus ASAP.=20 From: bernard_aboba@hotmail.comTo: radiusext@ops.ietf.orgSubject: Consensus= call: Changes to Extended Attributes documentDate: Wed, 7 May 2008 18:48:0= 5 -0700At IETF 71, a consensus call was taken regarding changes made in the= -01 version of theExtended Attributes document, as compared with -00. Th= e changes made were as follows:1. Ext-Type field was changed to 2 octets ra= ther than 1. 2. The RADIUS Extended Attribute format in -01 applied to exis= ting standard RADIUS attributes, not just extended ones. In the RADEXT WG = meeting at IETF 71, the consensus call was as follows: Change #1 was ADOPTE= D by a margin of 7-1. Change #2 was REJECTED by a margin of 6-2. We are no= w issuing a Consensus Call on the RADEXT WG mailing list in order to verify= the consensus of the room at IETF 71. This Consensus Call will last until= May 21, 2008. Please send email to the list, explicitly stating your pos= ition on changes #1 and #2, indicating whether you desire to ADOPT or REJEC= T each change. For reference, -00 is available here:http://www.waterspring= s.org/pub/id/draft-ietf-radext-extended-attributes-00.txt -01 is available = here:http://www.waterspring.org/pub/id/draft-ietf-radext-extended-attribute= s-01.txt ______________________ EMAILING FOR THE GREATER GOOD= --_b917c35e-6cb0-4b74-9ff7-0566e3b32d75_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wednesday, May 7, a Consensus call was issued to the WG mailing list, in= order to confirm acceptance of the consensus call done at IETF 71, with re= spect to the changes made in the Extended Attributes Document version = -01.
 
That Consensus call has now concluded.  Based on the minimal mailing l= ist response (1 response, in favor of the IETF 71 consensus), the consensus= taken at IETF 71 is judged to be AFFIRMED. 
 
That is:
 
1. The change to the Ext-Type field (2 octets rather than 1) is APPROVED.&n= bsp;
2. The change to the RADIUS Extended Attribute format in (applied t= o existing standard RADIUS attributes,  not just extended ones) is REJ= ECTED.
 
Instructions to the Editor:  Please submit a new document reflecting t= he RADEXT WG Consensus ASAP.

From: bernard_aboba@hotmail.com
To: radiusext@ops.ietf.org
Subject: C= onsensus call: Changes to Extended Attributes document
Date: Wed, 7 May = 2008 18:48:05 -0700

At IETF 71, a consensus call was taken regarding= changes made in the -01 version of the
Extended Attributes document, as= compared with -00. 
 
The changes made were as follows:1. Ext-Type field was changed to 2 octets rather than 1.
2. The RADIU= S Extended Attribute format in -01 applied to existing standard RADIUS attr= ibutes,  not just extended ones.
 
In the RADEXT WG meeting= at IETF 71, the consensus call was as follows:
 
Change #1 was = ADOPTED by a margin of 7-1.
Change #2 was REJECTED by a margin of 6-2. =
 
We are now issuing a Consensus Call on the RADEXT WG mailing = list in order to verify the consensus of the room at IETF 71.
 This Consensus Call will last until  May 21, 2008.  Please send = email to the list, explicitly stating your position on changes #1 and #2, i= ndicating whether you desire to ADOPT or REJECT each change.
 
= For reference, -00 is available here:
http://www.watersprings.org/pub/id/d= raft-ietf-radext-extended-attributes-00.txt
 
-01= is available here:
http://www.waterspring.org/pub/id/draft-ietf-radext-ext= ended-attributes-01.txt

 
 


_= _____________________
3D"i'm" EMAILING FOR TH= E GREATER GOOD
= --_b917c35e-6cb0-4b74-9ff7-0566e3b32d75_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: