From owner-radiusext@ops.ietf.org Sun Oct 3 11:07:10 2010 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 8A6663A6DA6 for ; Sun, 3 Oct 2010 11:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.88 X-Spam-Level: X-Spam-Status: No, score=-100.88 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_20=-0.74, HTML_MESSAGE=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 US1o0FHzo-Jz for ; Sun, 3 Oct 2010 11:07:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1D4023A6DF8 for ; Sun, 3 Oct 2010 11:07:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P2Suw-000LW1-IK for radiusext-data0@psg.com; Sun, 03 Oct 2010 18:04:10 +0000 Received: from blu0-omc1-s31.blu0.hotmail.com ([65.55.116.42]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P2Sur-000LUJ-5l for radiusext@ops.ietf.org; Sun, 03 Oct 2010 18:04:06 +0000 Received: from BLU137-DS7 ([65.55.116.7]) by blu0-omc1-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Oct 2010 11:04:03 -0700 X-Originating-IP: [98.203.197.175] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: References: ,<4C9EF53D.80406@deployingradius.com> In-Reply-To: Subject: RADEXT Virtual Interim Agenda - Take Four Date: Sun, 3 Oct 2010 11:04:36 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01CB62EA.C4A86270" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Actdi4MCPPubv6TPSPK3p291qRj2IQFmb7iw Content-Language: en-us X-OriginalArrivalTime: 03 Oct 2010 18:04:03.0771 (UTC) FILETIME=[5D2310B0:01CB6325] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0034_01CB62EA.C4A86270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agenda 8 AM - 8:10 AM Preliminaries (10 minutes) Attendance Note takers Agenda bash Document Status Documents Completing IETF Last Call (40 minutes) 8:10 AM - 8:30 AM RADIUS over TCP, Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp 8:30AM - 8:50 AM Design Guidelines, Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-design-guidelines RADEXT WG Work Items (40 minutes) 8:50 AM - 9:20 AM Extended RADIUS Attributes, Alan DeKok (30 minutes) http://tools.ietf.org/html/draft-dekok-radext-radius-extensions 9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls-00.txt ------=_NextPart_000_0034_01CB62EA.C4A86270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agenda<= /o:p>

 <= /o:p>

8 AM - 8:10 AM Preliminaries (10 minutes)

  =    Attendance

  =    Note takers

  =    Agenda bash

  =    Document Status

 <= /o:p>

Documents Completing IETF Last Call (40 minutes)

 <= /o:p>

8:10 AM - 8:30 AM RADIUS over TCP, Alan DeKok (20 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-tcp<= /span>

 

8:30AM - 8:50 AM Design Guidelines, Alan DeKok (20 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-design-guidelin= es

 

RADEXT WG Work Items (4= 0 minutes)

 

8:50 AM - 9:20 AM Extended RADIUS Attributes, Alan DeKok = (30 minutes)

http://tools.ietf.org/html/draft-dekok-radext-radius-extensi= ons

 

9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-dtls-00.txt

 

 <= /o:p>

------=_NextPart_000_0034_01CB62EA.C4A86270-- -- 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 Oct 3 11:07:17 2010 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 B8F453A6DA6 for ; Sun, 3 Oct 2010 11:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.718 X-Spam-Level: X-Spam-Status: No, score=-101.718 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, SARE_OBFU_SPLIT_HR2=0.183, 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 ddkoivW-96G8 for ; Sun, 3 Oct 2010 11:07:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 713853A6C19 for ; Sun, 3 Oct 2010 11:07:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P2Sve-000LXB-Me for radiusext-data0@psg.com; Sun, 03 Oct 2010 18:04:54 +0000 Received: from blu0-omc1-s17.blu0.hotmail.com ([65.55.116.28]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P2Svc-000LX0-Hb for radiusext@ops.ietf.org; Sun, 03 Oct 2010 18:04:52 +0000 Received: from BLU137-DS7 ([65.55.116.8]) by blu0-omc1-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Oct 2010 11:04:52 -0700 X-Originating-IP: [98.203.197.175] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Subject: RADEXT WG Virtual Interim Date: Sun, 3 Oct 2010 11:05:25 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActdPFtAhMPT7pKEQmOiEzANiG8tbAF6TJfA Content-Language: en-us X-OriginalArrivalTime: 03 Oct 2010 18:04:52.0070 (UTC) FILETIME=[79ECE860:01CB6325] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN=radiusext@ops.ietf.org;RSVP=TRUE:mailto:radiusext@ops.ietf.org CLASS:PUBLIC CREATED:20101003T180525Z DESCRIPTION:When: Monday\, October 11\, 2010 8:00 AM-10:00 AM (UTC-08:00) P acific Time (US & Canada).\nWhere: Teleconference\n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~ *~*~*\n\nConference phone number: +17024733463\nPasscode: 226220\nWeb con ference: https://my.dimdim.com/all/aboba/default/\nJabber room: radext at jabber.ietf.org (please join)\nPresentations: http://www.drizzle.com/~ab oba/RADEXT/Oct-Interim/\n\nChairs\n Bernard Aboba \n Mauricio Sanchez \n\nAg enda\n\n8 AM - 8:10 AM Preliminaries (10 minutes)\n Attendance\n N ote takers\n Agenda bash\n Document Status\n\nDocuments Completing IETF Last Call (40 minutes)\n\n8:10 AM - 8:30 AM RADIUS over TCP\, Alan D eKok (20 minutes)\nhttp://tools.ietf.org/html/draft-ietf-radext-tcp\n\n8:3 0AM - 8:50 AM Design Guidelines\, Alan DeKok (20 minutes)\nhttp://tools.ie tf.org/html/draft-ietf-radext-design-guidelines\n\nRADEXT WG Work Items (4 0 minutes)\n\n8:50 AM - 9:20 AM Extended RADIUS Attributes\, Alan DeKok (3 0 minutes)\nhttp://tools.ietf.org/html/draft-dekok-radext-radius-extension s\n\n9:20 - 9:30 AM RADIUS over DTLS\, Alan DeKok (10 minutes)\nhttp://too ls.ietf.org/html/draft-ietf-radext-dtls-00.txt\n\n\n\n\n DTEND:20101011T170000Z DTSTAMP:20101003T180525Z DTSTART:20101011T150000Z LAST-MODIFIED:20101003T180525Z LOCATION:Teleconference ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:0 SUMMARY;LANGUAGE=en-us:RADEXT WG Virtual Interim TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000B006E2AE015DCB01000000000000000 0100000008F04804402948D4CB07C1206789F9361 X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Monday\, October 11\, 2010 8:00 AM-10:00 AM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: Teleconference

\n\n

Note: The GMT offset above does not reflect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~*~*~*

\n\n

Conference phone number: \; +17024733463

\n\n

Passcode: 226220

\n\n

Web conference: https://my.dimdim.com/all/ aboba/default/

\n\n

J abber room: \; radext at jabber.ietf.org (please join)\n\n

Presentations: < /FONT> http://www.drizzle.com/~aboba/RADEXT/Oct-Interim/

\n\n

Chairs

\n\n< P DIR=LTR> \; \; \;&nb sp\; \; \; \; Bernard Aboba <\;bernard_aboba at hotmail.com& gt\;

\n\n

 \; \; \; \; \; \; \; Mauricio Sanchez <\ ;mauricio.sanchez at hp.com>\;

\n\n

Agenda

\n\n

8 AM - 8:10 AM Preliminaries (10 minut es)

\n\n

 \; \; \; \; Attendance

\n\n

 \; \; \; \; Note takers

\n\n

 \; \; \; \; Agenda bash

\n\n

 \; \; \; \; D ocument Status

\n\n

Documents Completing IETF Last Call (40 minutes)

\n\n

8:10 AM - 8:30 AM RADIUS over TCP\, Alan DeKok (20 minutes)

\n\n

http://tools.ietf.org/html/draft-ietf-radext-tcp

\n\n

8:30AM - 8:50 AM Design Guidelines\, Alan DeKok (20 minutes)

\n\n

http://tools .ietf.org/html/draft-ietf-radext-design-guidelines

\n\n

RADEXT WG Work Items (40 minutes)

\n\n

8:50 AM - 9:20 AM Extended RADIUS Attributes\, Alan DeKok (30 minutes)

\n\n

http://tools.ietf.org/html/draft-dekok-radext-radius-exte nsions< /SPAN>

\n\n

\n\n

9:20 - 9:30 AM RADIUS over DTLS\, Alan DeKok (10 minutes)

\n\n

http://tools.ietf.org/html/draft-ietf-ra dext-dtls-00.txt

\n
\n\n

\n\ n

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR -- 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 Oct 3 11:14:02 2010 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 B24A83A6E36 for ; Sun, 3 Oct 2010 11:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.814 X-Spam-Level: X-Spam-Status: No, score=-101.814 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, HTML_MESSAGE=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 crYTrjQgYcWg for ; Sun, 3 Oct 2010 11:14:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA2AA3A6DFB for ; Sun, 3 Oct 2010 11:14:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P2T1l-000Lud-Sy for radiusext-data0@psg.com; Sun, 03 Oct 2010 18:11:13 +0000 Received: from blu0-omc1-s20.blu0.hotmail.com ([65.55.116.31]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P2T1i-000LuQ-Uh for radiusext@ops.ietf.org; Sun, 03 Oct 2010 18:11:11 +0000 Received: from BLU137-DS9 ([65.55.116.8]) by blu0-omc1-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Oct 2010 11:11:09 -0700 X-Originating-IP: [98.203.197.175] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: References: ,<4C9EF53D.80406@deployingradius.com> In-Reply-To: Subject: RADEXT Virtual Interim Teleconference parameters Date: Sun, 3 Oct 2010 11:11:42 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01CB62EB.C27ED640" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Actdi4MCPPubv6TPSPK3p291qRj2IQFmb7iwAAA7gfA= Content-Language: en-us X-OriginalArrivalTime: 03 Oct 2010 18:11:09.0631 (UTC) FILETIME=[5AF824F0:01CB6326] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_003A_01CB62EB.C27ED640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Here are the teleconference parameters: Date: October 11, 2010 Time: 8 AM - 10 AM Pacific Time Conference phone number: +17024733463 Passcode: 226220 Web conference: https://my.dimdim.com/all/aboba/default/ Jabber room: radext at jabber.ietf.org (please join) Presentations: http://www.drizzle.com/~aboba/RADEXT/Oct-Interim/ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Sunday, October 03, 2010 11:05 AM To: 'radiusext@ops.ietf.org' Subject: RADEXT Virtual Interim Agenda - Take Four Agenda 8 AM - 8:10 AM Preliminaries (10 minutes) Attendance Note takers Agenda bash Document Status Documents Completing IETF Last Call (40 minutes) 8:10 AM - 8:30 AM RADIUS over TCP, Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp 8:30AM - 8:50 AM Design Guidelines, Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-design-guidelines RADEXT WG Work Items (40 minutes) 8:50 AM - 9:20 AM Extended RADIUS Attributes, Alan DeKok (30 minutes) http://tools.ietf.org/html/draft-dekok-radext-radius-extensions 9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls-00.txt ------=_NextPart_000_003A_01CB62EB.C27ED640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are the teleconference = parameters:

 

Date:  October 11, 2010

Time: 8 AM - 10 AM Pacific Time

Conference phone number:  +17024733463

Passcode: 226220

Web conference: https://my.dimdim.com/a= ll/aboba/default/

Jabber room:  radext at jabber.ietf.org (please = join)

Presentation= s:  http://www.dri= zzle.com/~aboba/RADEXT/Oct-Interim/

 

 

From:= Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Sunday, October 03, 2010 11:05 AM
To: 'radiusext@ops.ietf.org'
Subject: RADEXT Virtual Interim Agenda - Take = Four

 

Agenda<= /o:p>

 <= /o:p>

8 AM - 8:10 AM Preliminaries (10 minutes)

  =    Attendance

  =    Note takers

  =    Agenda bash

  =    Document Status

 <= /o:p>

Documents Completing IETF Last Call (40 minutes)

 <= /o:p>

8:10 AM - 8:30 AM RADIUS over TCP, Alan DeKok (20 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-tcp<= /span>

 

8:30AM - 8:50 AM Design Guidelines, Alan DeKok (20 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-design-guidelin= es

 

RADEXT WG Work Items (4= 0 minutes)

 

8:50 AM - 9:20 AM Extended RADIUS Attributes, Alan DeKok = (30 minutes)

http://tools.ietf.org/html/draft-dekok-radext-radius-extensi= ons

 

9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-dtls-00.txt

 

 <= /o:p>

------=_NextPart_000_003A_01CB62EB.C27ED640-- -- 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 Oct 3 11:16:05 2010 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 D4CA43A6E36 for ; Sun, 3 Oct 2010 11:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.074 X-Spam-Level: X-Spam-Status: No, score=-101.074 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_05=-1.11, HTML_MESSAGE=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 IyzECDcdChsB for ; Sun, 3 Oct 2010 11:16:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC18A3A6E38 for ; Sun, 3 Oct 2010 11:16:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P2T45-000MGE-Uk for radiusext-data0@psg.com; Sun, 03 Oct 2010 18:13:38 +0000 Received: from blu0-omc1-s35.blu0.hotmail.com ([65.55.116.46]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P2T43-000MFy-PC for radiusext@ops.ietf.org; Sun, 03 Oct 2010 18:13:35 +0000 Received: from BLU137-DS4 ([65.55.116.7]) by blu0-omc1-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Oct 2010 11:13:35 -0700 X-Originating-IP: [98.203.197.175] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Subject: Slides Date: Sun, 3 Oct 2010 11:14:08 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01CB62EC.194C0F10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActjJquKW2235m9WShWafV4tg6tK+AAAA/ig Content-Language: en-us X-OriginalArrivalTime: 03 Oct 2010 18:13:35.0112 (UTC) FILETIME=[B1AEC880:01CB6326] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_003F_01CB62EC.194C0F10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If you are presenting at the RADEXT Virtual Interim, please submit your slides by Friday, October 8. ------=_NextPart_000_003F_01CB62EC.194C0F10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you are presenting at the RADEXT Virtual = Interim, please submit your slides by Friday, October 8. 

------=_NextPart_000_003F_01CB62EC.194C0F10-- -- 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 Oct 8 04:18:24 2010 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 95E2D3A687E for ; Fri, 8 Oct 2010 04:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.211, 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 9l6Bo1byqbmF for ; Fri, 8 Oct 2010 04:18:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 873383A6841 for ; Fri, 8 Oct 2010 04:18:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P4Avt-0002Ya-BG for radiusext-data0@psg.com; Fri, 08 Oct 2010 11:16:13 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::20]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P4Avq-0002YC-AK for radiusext@ops.ietf.org; Fri, 08 Oct 2010 11:16:10 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 6466D3A6885; Fri, 8 Oct 2010 04:15: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-dtls-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101008111502.6466D3A6885@core3.amsl.com> Date: Fri, 8 Oct 2010 04:15: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 : DTLS as a Transport Layer for RADIUS Author(s) : A. DeKok Filename : draft-ietf-radext-dtls-00.txt Pages : 17 Date : 2010-10-08 The RADIUS protocol [RFC2865] has limited support for authentication and encryption of RADIUS packets. The protocol transports data "in the clear", although some parts of the packets can have "hidden" content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can co-exist with current RADIUS systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-dtls-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-dtls-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-08040234.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 Oct 8 04:20:37 2010 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 78A663A688F for ; Fri, 8 Oct 2010 04:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 5QGbcPV9H+Pl for ; Fri, 8 Oct 2010 04:20:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 095BB3A6883 for ; Fri, 8 Oct 2010 04:20:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P4AyI-0002o9-Qn for radiusext-data0@psg.com; Fri, 08 Oct 2010 11:18:42 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P4AyG-0002nd-9i for radiusext@ops.ietf.org; Fri, 08 Oct 2010 11:18:40 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P4AyC-0005D0-VN; Fri, 08 Oct 2010 04:18:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: aland@deployingradius.com X-Trac-Project: radext Date: Fri, 08 Oct 2010 11:18:36 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] tcp-transport #25 (closed): IESG DISCUSS Comments X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/25#comment:1 Message-ID: <063.c3e25e6aedee7a675331eecd8d548e42@tools.ietf.org> References: <054.920a9e623434ddb929f86da019a86134@tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <054.920a9e623434ddb929f86da019a86134@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #25: IESG DISCUSS Comments -----------------------------------+---------------------------------------- Reporter: iesg@… | Owner: aland@… Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: tcp-transport | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Changes (by aland@…): * status: new => closed * resolution: => fixed Comment: All comments have been addressed in -08 -- Ticket URL: radext -- 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 Oct 10 09:03:00 2010 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 801073A67FC for ; Sun, 10 Oct 2010 09:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.519 X-Spam-Level: X-Spam-Status: No, score=-100.519 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_50=0.001, HTML_MESSAGE=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 o6GYuwCO2mS8 for ; Sun, 10 Oct 2010 09:02:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93D5E3A67EF for ; Sun, 10 Oct 2010 09:02:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P4yJr-000MMu-Hg for radiusext-data0@psg.com; Sun, 10 Oct 2010 16:00:15 +0000 Received: from blu0-omc1-s25.blu0.hotmail.com ([65.55.116.36]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P4yJo-000MMf-MV for radiusext@ops.ietf.org; Sun, 10 Oct 2010 16:00:12 +0000 Received: from BLU137-DS9 ([65.55.116.9]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 10 Oct 2010 09:00:12 -0700 X-Originating-IP: [24.19.29.20] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Subject: REMINDER: RADEXT Virtual Interim on October 11, 2010 (tommorrow!) Date: Sun, 10 Oct 2010 09:00:12 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0112_01CB6859.8CD1F860" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActolDjm6nuEt6U3RvmNw8NUSw68vQ== Content-Language: en-us X-OriginalArrivalTime: 10 Oct 2010 16:00:12.0056 (UTC) FILETIME=[38619980:01CB6894] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0112_01CB6859.8CD1F860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We are holding a RADEXT Virtual Interim meeting on October 11, 2010 (tommorrow!). If you are presenting, please send slides to me NOW, so I can get them up on the archive. Date: October 11, 2010 Time: 8 AM - 10 AM Pacific Time Conference phone number: +17024733463 Passcode: 226220 Web conference: https://my.dimdim.com/all/aboba/default/ Jabber room: radext at jabber.ietf.org (please join) Presentations: http://www.drizzle.com/~aboba/RADEXT/Oct-Interim/ Agenda 8 AM - 8:10 AM Preliminaries (10 minutes) Attendance Note takers Agenda bash Document Status Documents Completing IETF Last Call (40 minutes) 8:10 AM - 8:30 AM RADIUS over TCP, Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp 8:30AM - 8:50 AM Design Guidelines, Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-design-guidelines RADEXT WG Work Items (40 minutes) 8:50 AM - 9:20 AM Extended RADIUS Attributes, Alan DeKok (30 minutes) http://tools.ietf.org/html/draft-dekok-radext-radius-extensions 9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls-00.txt ------=_NextPart_000_0112_01CB6859.8CD1F860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are holding a RADEXT Virtual Interim meeting on = October 11, 2010 (tommorrow!).   If you are presenting, please send = slides to me NOW, so I can get them up on the archive.

 

Date:  October 11, 2010

Time: 8 AM - 10 AM Pacific Time

 

Conference phone number:  = +17024733463

Passcode: 226220

 

Web conference: = https://my.dimdim.com/all/aboba/default/

Jabber room:  radext at jabber.ietf.org = (please join)

Presentations:  http://www.drizzle.com/~aboba/RADEXT/Oct-Interim/

 

Agenda

 

8 AM - 8:10 AM Preliminaries (10 = minutes)

     Attendance

     Note takers

     Agenda bash

     Document = Status

 

Documents Completing IETF Last Call (40 = minutes)

 

8:10 AM - 8:30 AM RADIUS over TCP, Alan DeKok (20 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-tcp

 

8:30AM - 8:50 AM Design Guidelines, Alan DeKok (20 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-design-gui= delines

 

RADEXT WG Work Items (40 minutes)

 

8:50 AM - 9:20 AM Extended RADIUS Attributes, Alan = DeKok (30 minutes)

http://tools.ietf.org/html/draft-dekok-radext-radius-ex= tensions

 

9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-dtls-00.tx= t

 

------=_NextPart_000_0112_01CB6859.8CD1F860-- -- 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 Oct 10 09:08:54 2010 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 070E13A67FC for ; Sun, 10 Oct 2010 09:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.725 X-Spam-Level: X-Spam-Status: No, score=-101.725 tagged_above=-999 required=5 tests=[AWL=0.691, BAYES_00=-2.599, SARE_OBFU_SPLIT_HR2=0.183, 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 mIYLSMIrtN39 for ; Sun, 10 Oct 2010 09:08:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E37F13A67EF for ; Sun, 10 Oct 2010 09:08:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P4yPk-000MdQ-5X for radiusext-data0@psg.com; Sun, 10 Oct 2010 16:06:20 +0000 Received: from blu0-omc1-s1.blu0.hotmail.com ([65.55.116.12]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P4yPi-000MdD-1o for radiusext@ops.ietf.org; Sun, 10 Oct 2010 16:06:18 +0000 Received: from BLU137-DS12 ([65.55.116.9]) by blu0-omc1-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 10 Oct 2010 09:06:17 -0700 X-Originating-IP: [24.19.29.20] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Subject: RADEXT WG Virtual Interim Date: Sun, 10 Oct 2010 09:06:18 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActdPFtAhMPT7pKEQmOiEzANiG8tbALWLdcw Content-Language: en-us X-OriginalArrivalTime: 10 Oct 2010 16:06:17.0174 (UTC) FILETIME=[12022F60:01CB6895] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN=radiusext@ops.ietf.org;RSVP=TRUE:mailto:radiusext@ops.ietf.org CLASS:PUBLIC CREATED:20101010T160618Z DESCRIPTION:When: Monday\, October 11\, 2010 8:00 AM-10:00 AM (UTC-08:00) P acific Time (US & Canada).\nWhere: Teleconference\n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~ *~*~*\n\nConference phone number: +17024733463\nPasscode: 226220\nWeb con ference: https://my.dimdim.com/all/aboba/default/\nJabber room: radext at jabber.ietf.org (please join)\nPresentations: http://www.drizzle.com/~ab oba/RADEXT/Oct-Interim/\n\nChairs\n Bernard Aboba \n Mauricio Sanchez \n\nAg enda\n\n8 AM - 8:10 AM Preliminaries (10 minutes)\n Attendance\n N ote takers\n Agenda bash\n Document Status\n\nDocuments Completing IETF Last Call (40 minutes)\n\n8:10 AM - 8:30 AM RADIUS over TCP\, Alan D eKok (20 minutes)\nhttp://tools.ietf.org/html/draft-ietf-radext-tcp\n\n8:3 0AM - 8:50 AM Design Guidelines\, Alan DeKok (20 minutes)\nhttp://tools.ie tf.org/html/draft-ietf-radext-design-guidelines\n\nRADEXT WG Work Items (4 0 minutes)\n\n8:50 AM - 9:20 AM Extended RADIUS Attributes\, Alan DeKok (3 0 minutes)\nhttp://tools.ietf.org/html/draft-dekok-radext-radius-extension s\n\n9:20 - 9:30 AM RADIUS over DTLS\, Alan DeKok (10 minutes)\nhttp://too ls.ietf.org/html/draft-ietf-radext-dtls-00.txt\n\n\n\n\n DTEND:20101011T170000Z DTSTAMP:20101010T160618Z DTSTART:20101011T150000Z LAST-MODIFIED:20101010T160618Z LOCATION:Teleconference ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:1 SUMMARY;LANGUAGE=en-us:RADEXT WG Virtual Interim TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000B006E2AE015DCB01000000000000000 0100000008F04804402948D4CB07C1206789F9361 X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Monday\, October 11\, 2010 8:00 AM-10:00 AM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: Teleconference

\n\n

Note: The GMT offset above does not reflect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~*~*~*

\n\n

Conference phone number: \; +17024733463

\n\n

Passcode: 226220

\n\n

Web conference: https://my.dimdim.com/all/ aboba/default/

\n\n

J abber room: \; radext at jabber.ietf.org (please join)\n\n

Presentations: < /FONT> http://www.drizzle.com/~aboba/RADEXT/Oct-Interim/

\n\n

Chairs

\n\n< P DIR=LTR> \; \; \;&nb sp\; \; \; \; Bernard Aboba <\;bernard_aboba at hotmail.com& gt\;

\n\n

 \; \; \; \; \; \; \; Mauricio Sanchez <\ ;mauricio.sanchez at hp.com>\;

\n\n

Agenda

\n\n

8 AM - 8:10 AM Preliminaries (10 minut es)

\n\n

 \; \; \; \; Attendance

\n\n

 \; \; \; \; Note takers

\n\n

 \; \; \; \; Agenda bash

\n\n

 \; \; \; \; D ocument Status

\n\n

Documents Completing IETF Last Call (40 minutes)

\n\n

8:10 AM - 8:30 AM RADIUS over TCP\, Alan DeKok (20 minutes)

\n\n

http://tools.ietf.org/html/draft-ietf-radext-tcp

\n\n

8:30AM - 8:50 AM Design Guidelines\, Alan DeKok (20 minutes)

\n\n

http://tools .ietf.org/html/draft-ietf-radext-design-guidelines

\n\n

RADEXT WG Work Items (40 minutes)

\n\n

8:50 AM - 9:20 AM Extended RADIUS Attributes\, Alan DeKok (30 minutes)

\n\n

http://tools.ietf.org/html/draft-dekok-radext-radius-exte nsions< /SPAN>

\n\n

\n\n

9:20 - 9:30 AM RADIUS over DTLS\, Alan DeKok (10 minutes)

\n\n

http://tools.ietf.org/html/draft-ietf-ra dext-dtls-00.txt

\n
\n\n

\n\ n

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTSEQTIME:20101003T180525Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR -- 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 Oct 10 11:23:21 2010 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 5008D3A6800 for ; Sun, 10 Oct 2010 11:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.82 X-Spam-Level: X-Spam-Status: No, score=-101.82 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, HTML_MESSAGE=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 PPbGpMZj9VYY for ; Sun, 10 Oct 2010 11:23:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 18D693A6807 for ; Sun, 10 Oct 2010 11:23:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P50WO-0003ah-Le for radiusext-data0@psg.com; Sun, 10 Oct 2010 18:21:20 +0000 Received: from blu0-omc1-s25.blu0.hotmail.com ([65.55.116.36]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P50WM-0003aR-Ak for radiusext@ops.ietf.org; Sun, 10 Oct 2010 18:21:18 +0000 Received: from BLU137-DS3 ([65.55.116.7]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 10 Oct 2010 11:21:17 -0700 X-Originating-IP: [24.19.29.20] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Subject: Virtual Interim Slides Date: Sun, 10 Oct 2010 11:21:15 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0146_01CB686D.434D1440" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Actop+z3m5G8sVB/QbSu5U4yOUKiDg== Content-Language: en-us x-cr-hashedpuzzle: AnFy BISP BNzo Cson Cx5j DSs0 DYKK ED8K EKd+ FrHp G+au Hno9 JgYZ J1Gj LcVM LvfH;1;cgBhAGQAaQB1AHMAZQB4AHQAQABvAHAAcwAuAGkAZQB0AGYALgBvAHIAZwA=;Sosha1_v1;7;{8E664441-506C-40CB-BD59-9E90231BDE6A};YgBlAHIAbgBhAHIAZABhAEAAbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQA=;Sun, 10 Oct 2010 18:21:15 GMT;VgBpAHIAdAB1AGEAbAAgAEkAbgB0AGUAcgBpAG0AIABTAGwAaQBkAGUAcwA= x-cr-puzzleid: {8E664441-506C-40CB-BD59-9E90231BDE6A} X-OriginalArrivalTime: 10 Oct 2010 18:21:17.0850 (UTC) FILETIME=[EE633FA0:01CB68A7] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0146_01CB686D.434D1440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit are now online: http://aboba.drizzlehosting.com/RADEXT/Oct-Interim/ ------=_NextPart_000_0146_01CB686D.434D1440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

are now online:

http://aboba.drizzlehosting.com/RADEXT/Oct-Interim/

 

 

------=_NextPart_000_0146_01CB686D.434D1440-- -- 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 Oct 11 08:21:23 2010 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 589433A6927 for ; Mon, 11 Oct 2010 08:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 mpBfv-B+sZW1 for ; Mon, 11 Oct 2010 08:21:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B3173A6A86 for ; Mon, 11 Oct 2010 08:21:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5K8b-000Frl-7s for radiusext-data0@psg.com; Mon, 11 Oct 2010 15:18:05 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5K8Y-000FqT-4S for radiusext@ops.ietf.org; Mon, 11 Oct 2010 15:18:02 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P5K8T-0005ph-3Q; Mon, 11 Oct 2010 08:17:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 11 Oct 2010 15:17:57 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] tcp-transport #59 (closed): Section 2.2 Assigned Ports X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/59#comment:1 Message-ID: <075.bd294a0f4c505e1032a1bc61dc961a54@tools.ietf.org> References: <066.6a0d47790b6af91f3cec957878abeb85@tools.ietf.org> X-Trac-Ticket-ID: 59 In-Reply-To: <066.6a0d47790b6af91f3cec957878abeb85@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #59: Section 2.2 Assigned Ports Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Resolution: Remove the radsec 2083/tcp allocation. That should be accomplished in the RADSEC document. Discussion of Dynauth over TLS port usage should go in the RTLS document. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: tcp-transport | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- 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 Oct 11 08:27:15 2010 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 E85A73A6927 for ; Mon, 11 Oct 2010 08:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 p23-S0KnIKkl for ; Mon, 11 Oct 2010 08:27:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AAF033A68FF for ; Mon, 11 Oct 2010 08:27:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5KGD-000GgA-5a for radiusext-data0@psg.com; Mon, 11 Oct 2010 15:25:57 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5KG9-000GfW-7d for radiusext@ops.ietf.org; Mon, 11 Oct 2010 15:25:53 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P5KG6-0006vV-Q2; Mon, 11 Oct 2010 08:25:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 11 Oct 2010 15:25:50 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] design #54 (closed): Editorial Nits X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/54#comment:2 Message-ID: <075.b0c6662141d18fa06b784e90d5adb1a5@tools.ietf.org> References: <066.ce092b7de24c85b50bd0c69c75de0a53@tools.ietf.org> X-Trac-Ticket-ID: 54 In-Reply-To: <066.ce092b7de24c85b50bd0c69c75de0a53@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #54: Editorial Nits Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: aland@… Type: defect | Status: closed Priority: trivial | Milestone: milestone1 Component: design | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- 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 Oct 11 08:29:31 2010 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 7536B3A68DA for ; Mon, 11 Oct 2010 08:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 GdUhYXWkHEkx for ; Mon, 11 Oct 2010 08:29:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4CBA33A68D6 for ; Mon, 11 Oct 2010 08:29:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5KJ2-000Gyd-AR for radiusext-data0@psg.com; Mon, 11 Oct 2010 15:28:52 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5KIz-000Gy5-5j for radiusext@ops.ietf.org; Mon, 11 Oct 2010 15:28:49 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P5KIw-0006re-Ha; Mon, 11 Oct 2010 08:28:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 11 Oct 2010 15:28:46 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] design #55 (closed): Disconnect-Request X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/55#comment:4 Message-ID: <075.db04ba9085d45859addd9d1f72d6575e@tools.ietf.org> References: <066.cf1a17b419e1fc4be4685d5a67f180ad@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <066.cf1a17b419e1fc4be4685d5a67f180ad@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #55: Disconnect-Request Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: aland@… Type: enhancement | Status: closed Priority: major | Milestone: milestone1 Component: design | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- 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 Oct 11 08:34:09 2010 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 DE5CC3A6B11 for ; Mon, 11 Oct 2010 08:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 vGAjJCUGBjGk for ; Mon, 11 Oct 2010 08:34:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BAEBB3A6B2C for ; Mon, 11 Oct 2010 08:33:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5KMM-000HI3-9o for radiusext-data0@psg.com; Mon, 11 Oct 2010 15:32:18 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5KMJ-000HHa-O2 for radiusext@ops.ietf.org; Mon, 11 Oct 2010 15:32:15 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P5KMH-0003GF-PP; Mon, 11 Oct 2010 08:32:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 11 Oct 2010 15:32:13 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] design #58 (closed): Section A.4 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/58#comment:1 Message-ID: <075.09d0f90ca47e1173bc9c517c1f437f10@tools.ietf.org> References: <066.c4dce718b3da817f1edcb931ae513325@tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <066.c4dce718b3da817f1edcb931ae513325@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #58: Section A.4 Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: To be fixed in -18. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: design | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- 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 Oct 11 08:34:51 2010 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 3DB183A682F for ; Mon, 11 Oct 2010 08:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.028, 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 7OYa3x8FXnJG for ; Mon, 11 Oct 2010 08:34:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 872343A68D5 for ; Mon, 11 Oct 2010 08:34:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5KMf-000HJT-Qw for radiusext-data0@psg.com; Mon, 11 Oct 2010 15:32:37 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5KMd-000HJ2-66 for radiusext@ops.ietf.org; Mon, 11 Oct 2010 15:32:35 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P5KMb-0003GL-2d; Mon, 11 Oct 2010 08:32:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 11 Oct 2010 15:32:33 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] design #57 (closed): Disconnect-Request X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/57#comment:1 Message-ID: <075.acd228ad9d1f22a5e557a65943dbdc03@tools.ietf.org> References: <066.636acb3e3b5b260501c8f06b66d5564a@tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <066.636acb3e3b5b260501c8f06b66d5564a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #57: Disconnect-Request Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: To be fixed in -18. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: design | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- 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 Oct 11 08:36:37 2010 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 375933A68D5 for ; Mon, 11 Oct 2010 08:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, 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 UATIE2Z1Qczf for ; Mon, 11 Oct 2010 08:36:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A64C93A682F for ; Mon, 11 Oct 2010 08:36:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5KOs-000HVC-Jc for radiusext-data0@psg.com; Mon, 11 Oct 2010 15:34:54 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5KOq-000HUn-3v for radiusext@ops.ietf.org; Mon, 11 Oct 2010 15:34:52 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P5KOn-0003Kh-Tf; Mon, 11 Oct 2010 08:34:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 11 Oct 2010 15:34:49 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] design #53 (closed): Notes X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/53#comment:2 Message-ID: <075.d5c427acc60d7e6084b57e6497c3bf5f@tools.ietf.org> References: <066.c1c746728a1b41ae977338231715517d@tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <066.c1c746728a1b41ae977338231715517d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #53: Notes Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Addressed in -17. -- ---------------------------------------+------------------------------------ Reporter: Hannes.Tschofenig@… | Owner: aland@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: design | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- 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 Oct 11 08:39:54 2010 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 269113A68DB for ; Mon, 11 Oct 2010 08:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, 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 Yn7SXX+t0GGi for ; Mon, 11 Oct 2010 08:39:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A4F2C3A68D5 for ; Mon, 11 Oct 2010 08:39:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5KSC-000HnP-02 for radiusext-data0@psg.com; Mon, 11 Oct 2010 15:38:20 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5KS9-000Hn8-Ei for radiusext@ops.ietf.org; Mon, 11 Oct 2010 15:38:17 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P5KS7-0003VT-V4; Mon, 11 Oct 2010 08:38:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 11 Oct 2010 15:38:15 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] design #52 (closed): Basic vs. Complex Attributes X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/52#comment:1 Message-ID: <075.5fc55799f9e9fbfb3b253bac5674a377@tools.ietf.org> References: <066.54d52c6498ad6aa12ad174b1ebfe843b@tools.ietf.org> X-Trac-Ticket-ID: 52 In-Reply-To: <066.54d52c6498ad6aa12ad174b1ebfe843b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #52: Basic vs. Complex Attributes Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Addressed in Section 1.3 as of -17. -- ---------------------------------------+------------------------------------ Reporter: Hannes.Tschofenig@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: design | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- 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 Oct 12 05:50:59 2010 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 72DA83A694F for ; Tue, 12 Oct 2010 05:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, 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 NYR1EMa2k5fm for ; Tue, 12 Oct 2010 05:50:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BAD403A67EA for ; Tue, 12 Oct 2010 05:50:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5eFJ-0003QW-Gr for radiusext-data0@psg.com; Tue, 12 Oct 2010 12:46:21 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::20]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5eFG-0003QE-Fm for radiusext@ops.ietf.org; Tue, 12 Oct 2010 12:46:18 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 745FD3A68E4; Tue, 12 Oct 2010 05: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-tcp-transport-09.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101012124502.745FD3A68E4@core3.amsl.com> Date: Tue, 12 Oct 2010 05: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 : RADIUS Over TCP Author(s) : A. DeKok Filename : draft-ietf-radext-tcp-transport-09.txt Pages : 18 Date : 2010-10-12 The Remote Authentication Dial In User Server (RADIUS) Protocol has until now required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security (RADIUS/TLS). It permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentialy and security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-tcp-transport-09.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-tcp-transport-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-12054222.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 Tue Oct 12 06:50:52 2010 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 338163A6982 for ; Tue, 12 Oct 2010 06:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.106, 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 UzW1m69y7H-C for ; Tue, 12 Oct 2010 06:50:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DAA983A6980 for ; Tue, 12 Oct 2010 06:50:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5fBR-0008mM-23 for radiusext-data0@psg.com; Tue, 12 Oct 2010 13:46:25 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::20]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5fBN-0008lt-1I for radiusext@ops.ietf.org; Tue, 12 Oct 2010 13:46:22 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 3B1FB3A6917; Tue, 12 Oct 2010 06:45: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-18.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101012134502.3B1FB3A6917@core3.amsl.com> Date: Tue, 12 Oct 2010 06: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 : RADIUS Design Guidelines Author(s) : G. Weber, A. DeKok Filename : draft-ietf-radext-design-18.txt Pages : 37 Date : 2010-10-12 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-18.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-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-12063326.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 Tue Oct 12 07:09:43 2010 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 5C7D23A696F for ; Tue, 12 Oct 2010 07:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.082 X-Spam-Level: X-Spam-Status: No, score=-102.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, 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 SGP6SBzyomR5 for ; Tue, 12 Oct 2010 07:09:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6489F3A696E for ; Tue, 12 Oct 2010 07:09:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5fWN-000Amo-3S for radiusext-data0@psg.com; Tue, 12 Oct 2010 14:08:03 +0000 Received: from liberty.deployingradius.com ([88.191.76.128]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5fWK-000AmL-Rh for radiusext@ops.ietf.org; Tue, 12 Oct 2010 14:08:01 +0000 Message-ID: <4CB46BBD.4050406@deployingradius.com> Date: Tue, 12 Oct 2010 16:07:57 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: 'radext mailing list' Subject: Updated drafts X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: I've updated a few documents today: guidelines: addressed the last few issues as noted on the tracker. The are now no open issues against the document. tcp transport: removed references to "radsec" port The are now no open issues against the document. DTLS: added a short discussion on NAT NAT and RADIUS are fundamentally incompatible. 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 Oct 12 07:17:37 2010 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 AC8A53A699E for ; Tue, 12 Oct 2010 07:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, 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 7vGLUd0+5MaV for ; Tue, 12 Oct 2010 07:17:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BBB0C3A69A0 for ; Tue, 12 Oct 2010 07:17:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5feT-000Bgy-B0 for radiusext-data0@psg.com; Tue, 12 Oct 2010 14:16:25 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::20]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5feQ-000Bgf-6Q for radiusext@ops.ietf.org; Tue, 12 Oct 2010 14:16:22 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 269373A696B; Tue, 12 Oct 2010 07:15: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-dtls-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101012141504.269373A696B@core3.amsl.com> Date: Tue, 12 Oct 2010 07:15: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 : DTLS as a Transport Layer for RADIUS Author(s) : A. DeKok Filename : draft-ietf-radext-dtls-01.txt Pages : 18 Date : 2010-10-12 The RADIUS protocol [RFC2865] has limited support for authentication and encryption of RADIUS packets. The protocol transports data "in the clear", although some parts of the packets can have "hidden" content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can co-exist with current RADIUS systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-dtls-01.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-dtls-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-12070330.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 Tue Oct 12 07:25:32 2010 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 2A0AB3A69AA for ; Tue, 12 Oct 2010 07:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, 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 qRZA1wC6Tm27 for ; Tue, 12 Oct 2010 07:25:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E70EC3A69A1 for ; Tue, 12 Oct 2010 07:25:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5flt-000CQa-7P for radiusext-data0@psg.com; Tue, 12 Oct 2010 14:24:05 +0000 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5flq-000CQA-NC for radiusext@ops.ietf.org; Tue, 12 Oct 2010 14:24:02 +0000 X-IronPort-AV: E=Sophos;i="4.57,320,1283745600"; d="scan'208";a="242312216" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Oct 2010 10:24:00 -0400 X-IronPort-AV: E=Sophos;i="4.57,320,1283745600"; d="scan'208";a="521971948" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Oct 2010 10:23:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Updated drafts Date: Tue, 12 Oct 2010 16:23:41 +0200 Message-ID: In-Reply-To: <4CB46BBD.4050406@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated drafts Thread-Index: ActqFwiQ3mBMl5mYS+y623ILV1e3EwAATQ1A References: <4CB46BBD.4050406@deployingradius.com> From: "Romascanu, Dan (Dan)" To: "Alan DeKok" , "radext mailing list" Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: See in-line. Thanks and Regards, Dan =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok > Sent: Tuesday, October 12, 2010 4:08 PM > To: 'radext mailing list' > Subject: Updated drafts >=20 >=20 > I've updated a few documents today: >=20 > guidelines: addressed the last few issues as noted on the tracker. >=20 > The are now no open issues against the document. >=20 As discueed in the virtual interim - this document will go to a new IETF Last Call and a new IESG review.=20 >=20 > tcp transport: removed references to "radsec" port >=20 > The are now no open issues against the document. >=20 >=20 As discussed in the virtual interim - we shall work to clear the pending DISCUSS and approve this document.=20 > DTLS: added a short discussion on NAT >=20 > NAT and RADIUS are fundamentally incompatible. >=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 Tue Oct 12 10:59:16 2010 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 210723A6A0E for ; Tue, 12 Oct 2010 10:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.488 X-Spam-Level: X-Spam-Status: No, score=-103.488 tagged_above=-999 required=5 tests=[AWL=0.949, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, 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 LSjVUgCCecvt for ; Tue, 12 Oct 2010 10:57:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 632603A6927 for ; Tue, 12 Oct 2010 10:57:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5j2U-0005wn-TZ for radiusext-data0@psg.com; Tue, 12 Oct 2010 17:53:26 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::20]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P5j2S-0005w9-3c for radiusext@ops.ietf.org; Tue, 12 Oct 2010 17:53:24 +0000 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1C33A68DA for ; Tue, 12 Oct 2010 10:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 Spex3kTVYv04; Tue, 12 Oct 2010 10:52:07 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDBDE3A68E8; Tue, 12 Oct 2010 10:52:06 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Cc: Subject: Last Call: (RADIUS Design Guidelines) to BCP X-Test-IDTracker: no Message-ID: <20101012175206.8069.4849.idtracker@localhost> Date: Tue, 12 Oct 2010 10:52:06 -0700 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'RADIUS Design Guidelines' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-10-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note that this is a second IETF Last Call. As the document underwent through significant changes after the IESG review, the Area Director and the Working Group chairs decided to request again the community consensus before another IESG review. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-radext-design/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-radext-design/ No IPR declarations were found that appear related to this I-D. -- 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 Oct 25 22:19:44 2010 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 8047A3A67AB for ; Mon, 25 Oct 2010 22:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.872 X-Spam-Level: X-Spam-Status: No, score=-101.872 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599, HTML_MESSAGE=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 dpqwbb02VuQB for ; Mon, 25 Oct 2010 22:19:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B0773A67D1 for ; Mon, 25 Oct 2010 22:19:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAbu8-0001hN-OB for radiusext-data0@psg.com; Tue, 26 Oct 2010 05:17:00 +0000 Received: from blu0-omc1-s7.blu0.hotmail.com ([65.55.116.18]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAbu5-0001gy-8B for radiusext@ops.ietf.org; Tue, 26 Oct 2010 05:16:57 +0000 Received: from BLU104-W20 ([65.55.116.9]) by blu0-omc1-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Oct 2010 22:16:50 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_7f9b9d45-e0f8-437c-be9a-faa08a0249c3_" X-Originating-IP: [24.19.29.20] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Draft minutes of the RADEXT Virtual Interim Date: Mon, 25 Oct 2010 22:16:50 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 26 Oct 2010 05:16:50.0427 (UTC) FILETIME=[FEA074B0:01CB74CC] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_7f9b9d45-e0f8-437c-be9a-faa08a0249c3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Minutes of the RADEXT Virtual Interim Meeting Monday=2C October 11=2C 2010 8 AM - 10 AM Pacific Time Chairs Bernard Aboba Mauricio Sanchez Agenda 8 AM - 8:10 AM Preliminaries (10 minutes) Attendance Note takers Agenda bash Document Status Documents Completing IETF Last Call (40 minutes) 8:10 AM - 8:30 AM RADIUS over TCP=2C Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp Major open issue is what port is to be reserved for Dynauth over TLS.=20 Should this port be reserved in the RADIUS over TCP document or in the RTLS document? Since we are talking about Dynauth over TLS=2C not Dynauth over TCP=2C it's not clear why this has to be reserved in this document.=20 Resolution is to remove the port reservation for Dynauth over TLS.=20 8:30AM - 8:50 AM Design Guidelines=2C Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-design-guidelines Went over open Issues: 52=2C 53=2C 54=2C 55=2C 57=2C 58. =20 Most have been addressed in Design Guidelines -17. Remainder will be fixed in -18.=20 Once -18 is issued=2C the document will need to go back to IETF last call=3B too many changes have been made to it.=20 RADEXT WG Work Items (40 minutes) 8:50 AM - 9:20 AM Extended RADIUS Attributes=2C Alan DeKok (30 minutes) http://tools.ietf.org/html/draft-dekok-radext-radius-extensions Alan DeKok and Avi Lior have been working on a new proposal for Extended RADIUS attributes to replace the old (moribund) proposal.=20 The requirements are to enable more RADIUS Attribute Type space=2C and provide standard support for "long" attributes as well as better=20 grouping.=20 The proposal is to "steal" one octet of "value" for extended types=2C and allocate 4 attributes for this format: 241=2C 242=2C 243=2C 244. This wil= l=20 allow for ~1K new attributes=2C which should last a few decades at least.=20 To name the new attributes "dotted number" notation is proposed=20 (e.g. 241.1). This is only relevant for the IANA registry=2C not the protocol itself.=20 Grouping is enabled by defining a TLV data type. This is already in use in WiMAX=2C 3GPP2 and other SDOs. Multiple TLVs can be in one Extended Attribute=2C nested or concatenated=2C with nesting limited only by TLV length (253/3 =3D ~80). Depth of 5 is sufficient. For "Long" Attributes two attributes are allocated: 245=2C 246. A "flag" field is added to enable "more than 253 octets of data" to be indicated.=20 The proposal also enables additional VSAs to be provided to vendors.=20 Some vendors have run out (and their request for additional Enterprise Codes has been denied) so this will come in handy.=20 How do we move forward? Some vendors (who can't get Enterprise Codes) need this now=3B others will need it in 2-3 years when the RADIUS attribute space could run out.=20 Sense of the room is that the proposal is promising=3B the draft will be pl= aced on the IETF 79 agenda for further discussion.=20 9:20 - 9:30 AM RADIUS over DTLS=2C Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls-00.txt This document currently reuses existing RADIUS and Dynauth ports. This is convenient because no new ports are needed=2C and because DTLS and RADIUS c= an easily be distinguished from each other. If we asked for new ports for TLS=2C DTLS=2C for both RADIUS and Dynauth=2C some eyebrows would probably = be raised (and rightfully so).=20 Implementations are currently in progress in RadSecProxy=2C Jradius and Fre= eRADIUS (expected 1Q 2011). Review from the implementers is an outstanding item.=20 Meeting Adjourned at 9:45 AM.=20 =20 = --_7f9b9d45-e0f8-437c-be9a-faa08a0249c3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Minutes of the RADEXT Virtual Interim Meeting

Monday=2C October 11= =2C 2010
8 AM - 10 AM Pacific Time

Chairs
Bernard Aboba <=3B= bernard_aboba at hotmail.com>=3B
Mauricio Sanchez <=3Bmauricio.sanch= ez at hp.com>=3B

Agenda

8 AM - 8:10 AM Preliminaries (10 mi= nutes)
 =3B =3B =3B =3B Attendance
 =3B =3B&n= bsp=3B =3B Note takers
 =3B =3B =3B =3B Agenda bash<= br> =3B =3B =3B =3B Document Status

Documents Comple= ting IETF Last Call (40 minutes)

8:10 AM - 8:30 AM RADIUS over TCP= =2C Alan DeKok (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext= -tcp

Major open issue is what port is to be reserved for Dynauth ove= r TLS.
Should this port be reserved in the RADIUS over TCP document or = in the
RTLS document? =3B Since we are talking about Dynauth over TL= S=2C not Dynauth
over TCP=2C it's not clear why this has to be reserved = in this document.

Resolution is to remove the port reservation for = Dynauth over TLS.

8:30AM - 8:50 AM Design Guidelines=2C Alan DeKok = (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-design-guideli= nes

Went over open Issues: 52=2C 53=2C 54=2C 55=2C 57=2C 58.  = =3B
Most have been addressed in Design Guidelines -17. =3B Remainder=
will be fixed in -18.

Once -18 is issued=2C the document will n= eed to go back to IETF last
call=3B too many changes have been made to i= t.

RADEXT WG Work Items (40 minutes)

8:50 AM - 9:20 AM Exten= ded RADIUS Attributes=2C Alan DeKok (30 minutes)
http://tools.ietf.org/h= tml/draft-dekok-radext-radius-extensions

Alan DeKok and Avi Lior hav= e been working on a new proposal for Extended
RADIUS attributes to repla= ce the old (moribund) proposal.

The requirements are to enable more= RADIUS Attribute Type space=2C and
provide standard support for "long" = attributes as well as better
grouping.

The proposal is to "stea= l" one octet of "value" for extended types=2C and
allocate 4 attributes = for this format: =3B 241=2C 242=2C 243=2C 244. =3B This will
al= low for ~1K new attributes=2C which should last a few decades at least.
To name the new attributes "dotted number" notation is proposed
(e= .g. 241.1). =3B This is only relevant for the IANA registry=2C not the<= br>protocol itself.

Grouping is enabled by defining a TLV data type= . =3B This is already
in use in WiMAX=2C 3GPP2 and other SDOs. = =3B Multiple TLVs can be in
one Extended Attribute=2C nested or concaten= ated=2C with nesting
limited only by TLV length (253/3 =3D ~80). =3B= Depth of 5 is sufficient.

For "Long" Attributes two attributes are = allocated: =3B 245=2C 246. A
"flag" field is added to enable "more t= han 253 octets of data"
to be indicated.

The proposal also enabl= es additional VSAs to be provided to vendors.
Some vendors have run out= (and their request for additional Enterprise
Codes has been denied) so = this will come in handy.

How do we move forward? =3B Some vendo= rs (who can't get Enterprise Codes)
need this now=3B others will need it= in 2-3 years when the RADIUS attribute
space could run out.

Sen= se of the room is that the proposal is promising=3B the draft will be place= d on
the IETF 79 agenda for further discussion.

9:20 - 9:30 AM R= ADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/dr= aft-ietf-radext-dtls-00.txt

This document currently reuses existing = RADIUS and Dynauth ports. =3B This is
convenient because no new port= s are needed=2C and because DTLS and RADIUS can
easily be distinguished = from each other. =3B If we asked for new ports for
TLS=2C DTLS=2C fo= r both RADIUS and Dynauth=2C some eyebrows would probably be raised
(and= rightfully so).

Implementations are currently in progress in RadSe= cProxy=2C Jradius and FreeRADIUS
(expected 1Q 2011). =3B Review from= the implementers is an outstanding item.

Meeting Adjourned at 9:45= AM.

 =3B



= --_7f9b9d45-e0f8-437c-be9a-faa08a0249c3_-- -- 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 Oct 26 04:56:27 2010 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 832CF3A6941 for ; Tue, 26 Oct 2010 04:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.88 X-Spam-Level: X-Spam-Status: No, score=-101.88 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, HTML_MESSAGE=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 ebeCJ2kQUVWu for ; Tue, 26 Oct 2010 04:56:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 521A33A6939 for ; Tue, 26 Oct 2010 04:56:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAi7M-000BZs-E4 for radiusext-data0@psg.com; Tue, 26 Oct 2010 11:55:04 +0000 Received: from blu0-omc1-s30.blu0.hotmail.com ([65.55.116.41]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PAi75-000BVp-BD for radiusext@ops.ietf.org; Tue, 26 Oct 2010 11:55:01 +0000 Received: from BLU104-DS2 ([65.55.116.7]) by blu0-omc1-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Oct 2010 04:54:46 -0700 X-Originating-IP: [24.19.29.20] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Subject: Call for Agenda Items for IETF 79 Date: Tue, 26 Oct 2010 04:54:59 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0205_01CB74C9.F1CA0BF0" X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: Act1BD6iiQqJG+veRMig92RFA021NwAABNlw X-OriginalArrivalTime: 26 Oct 2010 11:54:46.0366 (UTC) FILETIME=[95CB9FE0:01CB7504] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0205_01CB74C9.F1CA0BF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The RADEXT WG has a session scheduled at IETF 79 on Friday, November 12, 2010 from 0900 - 1130 AM. We would now like to solicit agenda items. If you have an agenda item, please send it to myself or Mauricio. ------=_NextPart_000_0205_01CB74C9.F1CA0BF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The RADEXT WG has a = session scheduled at IETF 79 on Friday, November 12, 2010 from 0900 - 1130 AM. =

 

We would now like to = solicit agenda items.

 

If you have an agenda = item, please send it to myself or Mauricio.  

------=_NextPart_000_0205_01CB74C9.F1CA0BF0-- -- 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 Oct 27 06:40:09 2010 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 60CC93A6A25 for ; Wed, 27 Oct 2010 06:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.938 X-Spam-Level: X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 PWEmncDgAGdv for ; Wed, 27 Oct 2010 06:40:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B63D23A6802 for ; Wed, 27 Oct 2010 06:40:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PB6BV-0009i6-Ar for radiusext-data0@psg.com; Wed, 27 Oct 2010 13:36:57 +0000 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PB6AZ-0009am-9e for radiusext@ops.ietf.org; Wed, 27 Oct 2010 13:35:59 +0000 Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E7AAF8B80CF; Wed, 27 Oct 2010 15:24:28 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id BD8E38B8095; Wed, 27 Oct 2010 15:03:16 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Oct 2010 15:02:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Operations Directorate Review of draft-ietf-radext-design-18 Date: Wed, 27 Oct 2010 15:02:18 +0200 Message-ID: In-Reply-To: <4CC820D6.4050808@freeradius.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operations Directorate Review of draft-ietf-radext-design-18 Thread-Index: Act11gCn/umKpWOWT6iTJYiA+uqhFwAAH9+Q References: <4CC820D6.4050808@freeradius.org> From: To: Cc: , , X-OriginalArrivalTime: 27 Oct 2010 13:02:21.0496 (UTC) FILETIME=[31411B80:01CB75D7] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi Alan, Thanks for your prompt answer. And thank you for taking account my = comment. I have no problem with the proposed answer. About re-organizing the doc, I understand your concerns. Regards, Lionel =20 > -----Message d'origine----- > De : Alan T DeKok [mailto:aland@freeradius.org]=20 > Envoy=E9 : mercredi 27 octobre 2010 14:54 > =C0 : MORAND Lionel RD-CORE-ISS > Cc : ops-dir@ietf.org; gdweber@gmail.com; 'radext mailing list' > Objet : Re: Operations Directorate Review of=20 > draft-ietf-radext-design-18 >=20 > lionel.morand@orange-ftgroup.com wrote: > > I reviewed the document draft-ietf-radext-design-18 and here is my=20 > > feedback. > ... > > I found this draft OK. Authors and reviewers have tried to provide=20 > > clear statements and recommendations regarding the RADIUS attribute=20 > > design. I can only regret that the recommendations are=20 > spread all over=20 > > the document and it is quite difficult to find them if you are not=20 > > reading the whole doucment. >=20 > Appendix A outlines the recommendations in detail, and in a=20 > short form. We can add text at the start which points to the=20 > appendix as a simple set of the recommendations. >=20 > > This document provides guidelines for the design of RADIUS=20 > > attributes > >=20 > > [LM] RADIUS acronym can be expended at this stage, instead=20 > of doing it=20 > > later. [LM] >=20 > OK. >=20 > > [LM] s/will used/will be used [LM] >=20 > Fixes. >=20 > > standard space > > RADIUS attributes which are allocated by IANA and=20 > which follow the > > format defined in RFC 2865 [RFC2865] Section 5. > >=20 > > [LM] Comment: instead of speaking of attributes, we should=20 > speak about=20 > > codes allocated from the standard/vendor space. [LM] >=20 > OK. >=20 >=20 > > The advice in this document applies to attributes used to encode > >=20 > > [LM] s/applies to attributes/applies to RADIUS attributes [LM] >=20 > That should be implicit, but OK. >=20 > > [LM] s/standards space/standard space [LM] >=20 > Fixed here, and elsewhere. >=20 > > Note that the RADEXT WG is currently (as of 2010) involved in > > developing updates to RADIUS. Those updates will=20 > provide their own > > usage guidelines that may "override" some of the=20 > guidelines discussed > > here. > >=20 > > [LM] comment: this part is a little bit tricky. It is said at the=20 > > beginning that this document should be used as guidelines,=20 > especially=20 > > for standard code allocation, while it is said right after that the=20 > > existing work could "override" some of the statements=20 > encapuslated in=20 > > this BCP. Is "override" the right wording here? I mean, do=20 > you foresee=20 > > any possible 'conflict' or it is just to say that some guidelines=20 > > introduced by new documents miht not be covered by this BCP? Some=20 > > clarification text may be useful [LM] >=20 > OK. I think "modify" is a better work than "over-ride". =20 > Adding an example like "such as adding new data types" should=20 > be a good clarification. >=20 > > conformance with the design guidelines in this document=20 > is expected > > unless a good case can be made for an exception. =20 > Reviewers SHOULD > > use the design guidelines as a review checklist. > >=20 > > [LM] why just a "SHOULD" here, when speaking about standard=20 > space? The=20 > > use of this checlinst can be made required in the IETF=20 > process, except=20 > > if it is out of scope of BCP. Mandate the use of this=20 > checklist does=20 > > not mean that we mandate to follow scrupulously all the guidelines.=20 > > [LM] >=20 > The document is a BCP, and can't require modifications to=20 > the IETF process. >=20 > > While not required, IETF review may also be beneficial for > > specifications utilizing the Vendor-Specific space.=20 > Experience has > > shown that attributes not originally designed for=20 > general usage can > > subsequently garner wide-spread deployment. An example is the > > vendor-specific attributes defined in [RFC2548], which have been > > widely implemented within IEEE 802.11 Access Points. > >=20 > > [LM] I failded to see the link between this BCP and an IETF=20 > review of=20 > > vendor specific attributes. What would be the added value=20 > of an IETF=20 > > review if vendors/SDOs are following the guidelines of this BCP? >=20 > If the SDOs are doing something which has wider use, the=20 > review might suggest to do the work within the IETF, rather=20 > than within the SDO. >=20 > > Similarly, vendors are encouraged to make their specifications > > publicly available, for maximum interoperability. =20 > However, it is not > > necessary for a vendor to request publication of a VSA=20 > specification > > as an Informational RFC by the IETF. > >=20 > > [LM] the main part of this text details the process for an=20 > IETF review. > > As expressed above, the link of this process and the present BCP is=20 > > not obvious. It even seems quite contradictory. [LM] >=20 > It suggest reviews are good, but not mandatory. >=20 > > 2. Guidelines > >=20 > > The Remote Authentication Dial In User Service (RADIUS)=20 > defined in > >=20 > > [LM] see comment in Introduction reagrding RADIUS acronym expansion=20 > > [LM] >=20 > OK. >=20 > > [LM] RADIUS design decision we/RADIUS design decision, we [LM] >=20 > OK. >=20 > > [LM] s/defined in Section 2.1,/defined in Section 2.1 of this=20 > > document, [LM] >=20 > OK. >=20 > > [RFC2865] RADIUS VSA. All other data formats are=20 > "complex types". > >=20 > > [LM] in section 3.2.3, complex data type is characherized as=20 > > attributes with multiple sub-fields into the > > "Value" field. Should we reflect this point at this stage, when=20 > > defining the two kinds of data types? [LM] >=20 > No. The text in 3.2.3 gives an *example* of a complex=20 > type. It shouldn't be construed as defining what a complex type is. >=20 > > [LM] s/this situation.. Code-point/this situation. Code-point [LM] >=20 > OK. >=20 > > * Attributes that are of broad interest to the=20 > Internet Community. > > Multi-vendor interoperability is expected. > >=20 > > [LM] I think that if it is foro Internet Community,=20 > interoperability=20 > > is required and not "expected" [LM] >=20 > Sure... but we can't require that in a BCO. >=20 > > [LM] we should not speak about "self-allocation" but use of code=20 > > values reserved for standard attributes. [LM] >=20 > OK. >=20 > > * Enumerated data types, represented as a 32-bit=20 > unsigned integer > > with a list of name to value mappings. (e.g. Service-Type) > >=20 > > [LM] why a specific example here? [LM] >=20 > Because it makes it clearer...? >=20 > > [LM] s/their own Attributes/their own attributes [LM] >=20 > OK. >=20 > > [LM] s/allocation (or self-allocating) from/allocation from [LM] >=20 > OK. >=20 > > It is therefore NOT RECOMMENDED that specifications=20 > intended solely > > for use by a vendor or SDO use be translated into the=20 > standard space. > >=20 > > [LM] It would be maybe useful to summarize the set of=20 > recommendations=20 > > in a dedicated sub-section at the end of this chapter. It could be=20 > > done through a table listing the recommendations and a reference to=20 > > the section in which the recommendation is explained. This=20 > table could=20 > > help reviewer, along with the checking list provided in Annex. [LM] >=20 > That's already done in Appendix A. I don't think we need=20 > to repeat it here. >=20 > > 3. Rationale > >=20 > > This section outlines the rationale behind the above=20 > recommendations. > >=20 > > [skip] > >=20 > > [LM] I would suggest to split the whole section on multiple=20 > > sub-sections dedicated to a single point concluded by a=20 > recommendation=20 > > [LM] >=20 > I disagree. The first sentence clearly says=20 > "recommendations are given above". Repeating them here is awkward. >=20 > The WG went through 3-4 complete re-organizations of the document. > The form it's in now was judged to the the simplest of the=20 > alternatives, including the one you're proposing here. >=20 > > [LM] and this has lead/and this has led [LM] >=20 > OK. >=20 > > Subsequent RADIUS specifications defined attributes by using type > > names not defined in [RFC2865], without defining the new=20 > names as was > > done in [RFC2865]. They did not consistently indicate=20 > the format=20 > > of > >=20 > > [LM] either "names as it was done" or "names as done" [LM] >=20 > "names as done" seems clearer. >=20 > > In other cases, the data in the complex type are=20 > described textually. > > This is possible because the data types are not sent within the > > attributes, but are a matter for endpoint interpretation. An > > implementation can define additional data types, and use=20 > these data > > types today by matching them to the attribute's textual=20 > description. > >=20 > > [LM] an example could help to understand the paragraph above [LM] >=20 > OK. I'll work on something. >=20 > > 3.3.1. Interoperability Considerations > >=20 > > Vendors and SDOs are reminded that the standard RADIUS attribute > > space, and the enumerated value space for enumerated=20 > attributes, are > > reserved for allocation through work published via the=20 > IETF, as noted > > in [RFC3575] Section 2.1. Some vendors and SDOs have in the past > > performed self-allocation by assigning vendor-specific meaning to > > "unused" values from the standard RADIUS attribute ID or=20 > enumerated > > value space. This self-allocation results in interoperability > > issues, and is counter-productive. Similarly, the=20 > Vendor-Specific > > enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT > > RECOMMENDED. > >=20 > > [LM] here it is exactly why I'm relunctant to speak about=20 > > self-allocation. Values from the standard space are not formally=20 > > allocated but used by vendors/SDOs. Self-allocation would mean that=20 > > you can decide on your own to allocate standard values to=20 > non-standard=20 > > attributes and that theses values would be considered by IETF as=20 > > already allocated, that is not the case here. If it was the case,=20 > > there will be no interoperability issue, only a problem of=20 > standard value exhaustion. > > As I said, what it is not recommended is to use values from the=20 > > standard space without official IETF allocation. [LM] >=20 > OK. I'll re-word it to remove the "self-allocation" text. >=20 > > If it is not possible to follow the IETF process,=20 > vendors and SDOs > > SHOULD self-allocate an attribute, which MUST be in=20 > vendor space, as > > discussed in Sections 3.3.2 and 3.3.3, below. > >=20 > > [LM] just a note: vendors and SDOs do not share the same=20 > vendor space=20 > > and vendors are not encouraged to pick values in the SDO=20 > vendor space. > > [LM] >=20 > Hmm... OK. It could say "MUST be in their own vendor space". >=20 > > [LM] s/requesting a PEC/requesting a PEN [LM] >=20 > OK. >=20 > > [LM] s/As a result. pre-existing/As a result, pre-existing [LM] >=20 > OK. >=20 > > in Appendix B MAY be used. > >=20 > > [skip] > >=20 > > A.2.2. More Complex Data Types > >=20 > > Does the attribute: > >=20 > > * define a complex data type not described in Appendix B, > >=20 > > [LM] s/Appendix B,/Appendix B? [LM] > >=20 >=20 > I disagree. The text is part of a run-on sentence which=20 > continues to the next bullet point. >=20 > Alan DeKok. >=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 Wed Oct 27 12:56:56 2010 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 DAAD33A6981 for ; Wed, 27 Oct 2010 12:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, 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 wDpyNrk3mTUe for ; Wed, 27 Oct 2010 12:56:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5F2033A680A for ; Wed, 27 Oct 2010 12:56:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PBC3s-0007NK-C2 for radiusext-data0@psg.com; Wed, 27 Oct 2010 19:53:28 +0000 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PBC3m-0007Ia-4o for radiusext@ops.ietf.org; Wed, 27 Oct 2010 19:53:22 +0000 X-IronPort-AV: E=Sophos;i="4.58,247,1286164800"; d="scan'208";a="215234277" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Oct 2010 15:50:13 -0400 X-IronPort-AV: E=Sophos;i="4.58,247,1286164800"; d="scan'208";a="533330103" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Oct 2010 14:28:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OPS-DIR] Operations Directorate Review ofdraft-ietf-radext-design-18 Date: Wed, 27 Oct 2010 20:28:31 +0200 Message-ID: In-Reply-To: <4CC820D6.4050808@freeradius.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] Operations Directorate Review ofdraft-ietf-radext-design-18 Thread-Index: Act2AYQ4DEMs1RQdQ16MFOqhitu2uAAAu72Q References: <4CC820D6.4050808@freeradius.org> From: "Romascanu, Dan (Dan)" To: , Cc: , "radext mailing list" , Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi Alan, Please prepare a revised ID and submit it as soon as the pre-IETF submission blackout is over which is the Monday of the IETF meeting. I plan to put this document on the agenda of the first IESG telechat after Beijing.=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: ops-dir-bounces@ietf.org=20 > [mailto:ops-dir-bounces@ietf.org] On Behalf Of Alan T DeKok > Sent: Wednesday, October 27, 2010 2:54 PM > To: lionel.morand@orange-ftgroup.com > Cc: ops-dir@ietf.org; 'radext mailing list'; gdweber@gmail.com > Subject: Re: [OPS-DIR] Operations Directorate Review=20 > ofdraft-ietf-radext-design-18 >=20 > lionel.morand@orange-ftgroup.com wrote: > > I reviewed the document draft-ietf-radext-design-18 and here is my=20 > > feedback. > ... > > I found this draft OK. Authors and reviewers have tried to provide=20 > > clear statements and recommendations regarding the RADIUS attribute=20 > > design. I can only regret that the recommendations are=20 > spread all over=20 > > the document and it is quite difficult to find them if you are not=20 > > reading the whole doucment. >=20 > Appendix A outlines the recommendations in detail, and in a=20 > short form. We can add text at the start which points to the=20 > appendix as a simple set of the recommendations. >=20 > > This document provides guidelines for the design of RADIUS=20 > > attributes > >=20 > > [LM] RADIUS acronym can be expended at this stage, instead=20 > of doing it=20 > > later. [LM] >=20 > OK. >=20 > > [LM] s/will used/will be used [LM] >=20 > Fixes. >=20 > > standard space > > RADIUS attributes which are allocated by IANA and=20 > which follow the > > format defined in RFC 2865 [RFC2865] Section 5. > >=20 > > [LM] Comment: instead of speaking of attributes, we should=20 > speak about=20 > > codes allocated from the standard/vendor space. [LM] >=20 > OK. >=20 >=20 > > The advice in this document applies to attributes used to encode > >=20 > > [LM] s/applies to attributes/applies to RADIUS attributes [LM] >=20 > That should be implicit, but OK. >=20 > > [LM] s/standards space/standard space [LM] >=20 > Fixed here, and elsewhere. >=20 > > Note that the RADEXT WG is currently (as of 2010) involved in > > developing updates to RADIUS. Those updates will=20 > provide their own > > usage guidelines that may "override" some of the=20 > guidelines discussed > > here. > >=20 > > [LM] comment: this part is a little bit tricky. It is said at the=20 > > beginning that this document should be used as guidelines,=20 > especially=20 > > for standard code allocation, while it is said right after that the=20 > > existing work could "override" some of the statements=20 > encapuslated in=20 > > this BCP. Is "override" the right wording here? I mean, do=20 > you foresee=20 > > any possible 'conflict' or it is just to say that some guidelines=20 > > introduced by new documents miht not be covered by this BCP? Some=20 > > clarification text may be useful [LM] >=20 > OK. I think "modify" is a better work than "over-ride". =20 > Adding an example like "such as adding new data types" should=20 > be a good clarification. >=20 > > conformance with the design guidelines in this document=20 > is expected > > unless a good case can be made for an exception. =20 > Reviewers SHOULD > > use the design guidelines as a review checklist. > >=20 > > [LM] why just a "SHOULD" here, when speaking about standard=20 > space? The=20 > > use of this checlinst can be made required in the IETF=20 > process, except=20 > > if it is out of scope of BCP. Mandate the use of this=20 > checklist does=20 > > not mean that we mandate to follow scrupulously all the guidelines.=20 > > [LM] >=20 > The document is a BCP, and can't require modifications to=20 > the IETF process. >=20 > > While not required, IETF review may also be beneficial for > > specifications utilizing the Vendor-Specific space.=20 > Experience has > > shown that attributes not originally designed for=20 > general usage can > > subsequently garner wide-spread deployment. An example is the > > vendor-specific attributes defined in [RFC2548], which have been > > widely implemented within IEEE 802.11 Access Points. > >=20 > > [LM] I failded to see the link between this BCP and an IETF=20 > review of=20 > > vendor specific attributes. What would be the added value=20 > of an IETF=20 > > review if vendors/SDOs are following the guidelines of this BCP? >=20 > If the SDOs are doing something which has wider use, the=20 > review might suggest to do the work within the IETF, rather=20 > than within the SDO. >=20 > > Similarly, vendors are encouraged to make their specifications > > publicly available, for maximum interoperability. =20 > However, it is not > > necessary for a vendor to request publication of a VSA=20 > specification > > as an Informational RFC by the IETF. > >=20 > > [LM] the main part of this text details the process for an=20 > IETF review. > > As expressed above, the link of this process and the present BCP is=20 > > not obvious. It even seems quite contradictory. [LM] >=20 > It suggest reviews are good, but not mandatory. >=20 > > 2. Guidelines > >=20 > > The Remote Authentication Dial In User Service (RADIUS)=20 > defined in > >=20 > > [LM] see comment in Introduction reagrding RADIUS acronym expansion=20 > > [LM] >=20 > OK. >=20 > > [LM] RADIUS design decision we/RADIUS design decision, we [LM] >=20 > OK. >=20 > > [LM] s/defined in Section 2.1,/defined in Section 2.1 of this=20 > > document, [LM] >=20 > OK. >=20 > > [RFC2865] RADIUS VSA. All other data formats are=20 > "complex types". > >=20 > > [LM] in section 3.2.3, complex data type is characherized as=20 > > attributes with multiple sub-fields into the > > "Value" field. Should we reflect this point at this stage, when=20 > > defining the two kinds of data types? [LM] >=20 > No. The text in 3.2.3 gives an *example* of a complex=20 > type. It shouldn't be construed as defining what a complex type is. >=20 > > [LM] s/this situation.. Code-point/this situation. Code-point [LM] >=20 > OK. >=20 > > * Attributes that are of broad interest to the=20 > Internet Community. > > Multi-vendor interoperability is expected. > >=20 > > [LM] I think that if it is foro Internet Community,=20 > interoperability=20 > > is required and not "expected" [LM] >=20 > Sure... but we can't require that in a BCO. >=20 > > [LM] we should not speak about "self-allocation" but use of code=20 > > values reserved for standard attributes. [LM] >=20 > OK. >=20 > > * Enumerated data types, represented as a 32-bit=20 > unsigned integer > > with a list of name to value mappings. (e.g. Service-Type) > >=20 > > [LM] why a specific example here? [LM] >=20 > Because it makes it clearer...? >=20 > > [LM] s/their own Attributes/their own attributes [LM] >=20 > OK. >=20 > > [LM] s/allocation (or self-allocating) from/allocation from [LM] >=20 > OK. >=20 > > It is therefore NOT RECOMMENDED that specifications=20 > intended solely > > for use by a vendor or SDO use be translated into the=20 > standard space. > >=20 > > [LM] It would be maybe useful to summarize the set of=20 > recommendations=20 > > in a dedicated sub-section at the end of this chapter. It could be=20 > > done through a table listing the recommendations and a reference to=20 > > the section in which the recommendation is explained. This=20 > table could=20 > > help reviewer, along with the checking list provided in Annex. [LM] >=20 > That's already done in Appendix A. I don't think we need=20 > to repeat it here. >=20 > > 3. Rationale > >=20 > > This section outlines the rationale behind the above=20 > recommendations. > >=20 > > [skip] > >=20 > > [LM] I would suggest to split the whole section on multiple=20 > > sub-sections dedicated to a single point concluded by a=20 > recommendation=20 > > [LM] >=20 > I disagree. The first sentence clearly says=20 > "recommendations are given above". Repeating them here is awkward. >=20 > The WG went through 3-4 complete re-organizations of the document. > The form it's in now was judged to the the simplest of the=20 > alternatives, including the one you're proposing here. >=20 > > [LM] and this has lead/and this has led [LM] >=20 > OK. >=20 > > Subsequent RADIUS specifications defined attributes by using type > > names not defined in [RFC2865], without defining the new=20 > names as was > > done in [RFC2865]. They did not consistently indicate=20 > the format=20 > > of > >=20 > > [LM] either "names as it was done" or "names as done" [LM] >=20 > "names as done" seems clearer. >=20 > > In other cases, the data in the complex type are=20 > described textually. > > This is possible because the data types are not sent within the > > attributes, but are a matter for endpoint interpretation. An > > implementation can define additional data types, and use=20 > these data > > types today by matching them to the attribute's textual=20 > description. > >=20 > > [LM] an example could help to understand the paragraph above [LM] >=20 > OK. I'll work on something. >=20 > > 3.3.1. Interoperability Considerations > >=20 > > Vendors and SDOs are reminded that the standard RADIUS attribute > > space, and the enumerated value space for enumerated=20 > attributes, are > > reserved for allocation through work published via the=20 > IETF, as noted > > in [RFC3575] Section 2.1. Some vendors and SDOs have in the past > > performed self-allocation by assigning vendor-specific meaning to > > "unused" values from the standard RADIUS attribute ID or=20 > enumerated > > value space. This self-allocation results in interoperability > > issues, and is counter-productive. Similarly, the=20 > Vendor-Specific > > enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT > > RECOMMENDED. > >=20 > > [LM] here it is exactly why I'm relunctant to speak about=20 > > self-allocation. Values from the standard space are not formally=20 > > allocated but used by vendors/SDOs. Self-allocation would mean that=20 > > you can decide on your own to allocate standard values to=20 > non-standard=20 > > attributes and that theses values would be considered by IETF as=20 > > already allocated, that is not the case here. If it was the case,=20 > > there will be no interoperability issue, only a problem of=20 > standard value exhaustion. > > As I said, what it is not recommended is to use values from the=20 > > standard space without official IETF allocation. [LM] >=20 > OK. I'll re-word it to remove the "self-allocation" text. >=20 > > If it is not possible to follow the IETF process,=20 > vendors and SDOs > > SHOULD self-allocate an attribute, which MUST be in=20 > vendor space, as > > discussed in Sections 3.3.2 and 3.3.3, below. > >=20 > > [LM] just a note: vendors and SDOs do not share the same=20 > vendor space=20 > > and vendors are not encouraged to pick values in the SDO=20 > vendor space. > > [LM] >=20 > Hmm... OK. It could say "MUST be in their own vendor space". >=20 > > [LM] s/requesting a PEC/requesting a PEN [LM] >=20 > OK. >=20 > > [LM] s/As a result. pre-existing/As a result, pre-existing [LM] >=20 > OK. >=20 > > in Appendix B MAY be used. > >=20 > > [skip] > >=20 > > A.2.2. More Complex Data Types > >=20 > > Does the attribute: > >=20 > > * define a complex data type not described in Appendix B, > >=20 > > [LM] s/Appendix B,/Appendix B? [LM] > >=20 >=20 > I disagree. The text is part of a run-on sentence which=20 > continues to the next bullet point. >=20 > Alan DeKok. > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir >=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 Oct 31 10:34:54 2010 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 61B4E3A69B0 for ; Sun, 31 Oct 2010 10:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_20=-0.74, HTML_MESSAGE=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 pc39dPfG84ee for ; Sun, 31 Oct 2010 10:34:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 51AEB3A69E4 for ; Sun, 31 Oct 2010 10:34:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PCblw-000D5F-Je for radiusext-data0@psg.com; Sun, 31 Oct 2010 17:32:48 +0000 Received: from blu0-omc1-s6.blu0.hotmail.com ([65.55.116.17]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PCbls-000D4r-UI for radiusext@ops.ietf.org; Sun, 31 Oct 2010 17:32:45 +0000 Received: from BLU104-DS6 ([65.55.116.8]) by blu0-omc1-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 31 Oct 2010 10:32:43 -0700 X-Originating-IP: [24.19.29.20] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Subject: RADEXT WG Agenda for IETF 79 - Take One Date: Sun, 31 Oct 2010 10:33:27 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0394_01CB78E7.0E2F7200" X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: Act5IbpF3kQgvREyRdm1MvgyRjh9uw== X-OriginalArrivalTime: 31 Oct 2010 17:32:43.0326 (UTC) FILETIME=[9FDEEDE0:01CB7921] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0394_01CB78E7.0E2F7200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit RADEXT WG IETF 79 Agenda Chairs: Bernard Aboba Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Friday November 12, 2010 0900 - 1130 Emerald Room 09:00 - 09:20, Preliminaries Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status Documents completing IETF Last Call (20 minutes) 9:20 - 9:30 RADIUS over TCP, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp 9:30 - 9:40 Design Guidelines, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-design-guidelines WG Work Items (50 minutes) 9:40 - 10:00 RADIUS over TLS, Stefan Winter (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec 10:00 - 10:20 Dynamic Peer Discovery, Stefan Winter (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery 10:20 - 10:30 RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls Individual Submissions (30 minutes) 10:30 - 11:00 Extended RADIUS Attributes, Alan DeKok (30 minutes) http://tools.ietf.org/html/draft-dekok-radext-radius-extensions Discussion and Wrap-up (30 minutes) 11:00 - 11:15 Discussion (15 minutes) 11:15 - 11:30 Next Steps: WG Chairs & ADs (15 minutes) ------=_NextPart_000_0394_01CB78E7.0E2F7200 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RADEXT WG IETF 79 Agenda

 

Chairs:

Bernard Aboba <bernard_aboba at = hotmail.com>

Mauricio Sanchez <mauricio.sanchez at = hp.com>

 

Jabber room:  radext at jabber.ietf.org = (Please join)

 

Friday November 12, 2010

 

0900 - 1130

 

Emerald Room

 

09:00 - 09:20, Preliminaries

 

     Debugging

     Note Well

     Note Takers

     Jabber = scribe

     Agenda bash

     Document = Status

 

Documents completing IETF Last Call (20 = minutes)

 

9:20 - 9:30 RADIUS over TCP, Alan DeKok (10 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-tcp

 

9:30 - 9:40 Design Guidelines, Alan DeKok (10 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-design-gui= delines

 

WG Work Items (50 minutes)

 

9:40 - 10:00 RADIUS over TLS, Stefan Winter (20 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-radsec

 

10:00 - 10:20 Dynamic Peer Discovery, Stefan Winter = (20 minutes)

http://tools.ietf.org/html/draft-ietf-radext-dynamic-di= scovery

 

10:20 - 10:30 RADIUS over DTLS, Alan DeKok (10 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-dtls<= /o:p>

 

 

Individual Submissions (30 minutes)

 

10:30 - 11:00 Extended RADIUS Attributes, Alan = DeKok (30 minutes)

http://tools.ietf.org/html/draft-dekok-radext-radius-ex= tensions

 

Discussion and Wrap-up (30 minutes)

 

 

11:00 – 11:15 Discussion (15 = minutes)

11:15 - 11:30  Next Steps:  WG Chairs = & ADs (15 minutes)

------=_NextPart_000_0394_01CB78E7.0E2F7200-- -- 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 Oct 31 10:36:47 2010 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 23E553A69B0 for ; Sun, 31 Oct 2010 10:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.906 X-Spam-Level: X-Spam-Status: No, score=-101.906 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, HTML_MESSAGE=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 2wRvTd1jxSWx for ; Sun, 31 Oct 2010 10:35:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 681803A69DF for ; Sun, 31 Oct 2010 10:35:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PCbod-000DNa-Ex for radiusext-data0@psg.com; Sun, 31 Oct 2010 17:35:35 +0000 Received: from blu0-omc1-s32.blu0.hotmail.com ([65.55.116.43]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PCboa-000DKT-S9 for radiusext@ops.ietf.org; Sun, 31 Oct 2010 17:35:33 +0000 Received: from BLU104-DS14 ([65.55.116.9]) by blu0-omc1-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 31 Oct 2010 10:35:31 -0700 X-Originating-IP: [24.19.29.20] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Subject: Remote Presentation Arrangements for IETF 79 Date: Sun, 31 Oct 2010 10:36:16 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_039C_01CB78E7.729D96E0" X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: Act5Ih6z92xGRo2NTxKQ+Ex7WI0rWA== X-OriginalArrivalTime: 31 Oct 2010 17:35:31.0896 (UTC) FILETIME=[0458AB80:01CB7922] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_039C_01CB78E7.729D96E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Since many of the participants will not be attending IETF 79 (including myself), the RADEXT WG meeting will include support for remote presentation. We are looking at a combination of WebEx (for remote slide presentation) and Skype (for audio). If you are listed on the agenda to present and will not be attending the Beijing meeting in person, please send your Skype account to myself and Mauricio. ------=_NextPart_000_039C_01CB78E7.729D96E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since many of the participants will not be = attending IETF 79 (including myself), the RADEXT WG meeting will include support for = remote presentation.

 

We are looking at a combination of WebEx (for = remote slide presentation) and Skype (for audio).

 

If you are listed on the agenda to present and will = not be attending the Beijing meeting in person, please send your Skype account = to myself and Mauricio.   

------=_NextPart_000_039C_01CB78E7.729D96E0-- -- 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-data0@psg.com Delivery-date: Sun, 31 Oct 2010 17:35:42 +0000 Message-ID: From: Bernard Aboba To: Subject: Remote Presentation Arrangements for IETF 79 Date: Sun, 31 Oct 2010 10:36:16 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_039C_01CB78E7.729D96E0" Content-Language: en-us Thread-Index: Act5Ih6z92xGRo2NTxKQ+Ex7WI0rWA== ------=_NextPart_000_039C_01CB78E7.729D96E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Since many of the participants will not be attending IETF 79 (including myself), the RADEXT WG meeting will include support for remote presentation. We are looking at a combination of WebEx (for remote slide presentation) and Skype (for audio). If you are listed on the agenda to present and will not be attending the Beijing meeting in person, please send your Skype account to myself and Mauricio. ------=_NextPart_000_039C_01CB78E7.729D96E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since many of the participants will not be = attending IETF 79 (including myself), the RADEXT WG meeting will include support for = remote presentation.

 

We are looking at a combination of WebEx (for = remote slide presentation) and Skype (for audio).

 

If you are listed on the agenda to present and will = not be attending the Beijing meeting in person, please send your Skype account = to myself and Mauricio.   

------=_NextPart_000_039C_01CB78E7.729D96E0-- -- 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-data0@psg.com Delivery-date: Sun, 31 Oct 2010 17:33:52 +0000 Message-ID: From: Bernard Aboba To: Subject: RADEXT WG Agenda for IETF 79 - Take One Date: Sun, 31 Oct 2010 10:33:27 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0394_01CB78E7.0E2F7200" Content-Language: en-us Thread-Index: Act5IbpF3kQgvREyRdm1MvgyRjh9uw== ------=_NextPart_000_0394_01CB78E7.0E2F7200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit RADEXT WG IETF 79 Agenda Chairs: Bernard Aboba Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Friday November 12, 2010 0900 - 1130 Emerald Room 09:00 - 09:20, Preliminaries Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status Documents completing IETF Last Call (20 minutes) 9:20 - 9:30 RADIUS over TCP, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp 9:30 - 9:40 Design Guidelines, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-design-guidelines WG Work Items (50 minutes) 9:40 - 10:00 RADIUS over TLS, Stefan Winter (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec 10:00 - 10:20 Dynamic Peer Discovery, Stefan Winter (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery 10:20 - 10:30 RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls Individual Submissions (30 minutes) 10:30 - 11:00 Extended RADIUS Attributes, Alan DeKok (30 minutes) http://tools.ietf.org/html/draft-dekok-radext-radius-extensions Discussion and Wrap-up (30 minutes) 11:00 - 11:15 Discussion (15 minutes) 11:15 - 11:30 Next Steps: WG Chairs & ADs (15 minutes) ------=_NextPart_000_0394_01CB78E7.0E2F7200 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RADEXT WG IETF 79 Agenda

 

Chairs:

Bernard Aboba <bernard_aboba at = hotmail.com>

Mauricio Sanchez <mauricio.sanchez at = hp.com>

 

Jabber room:  radext at jabber.ietf.org = (Please join)

 

Friday November 12, 2010

 

0900 - 1130

 

Emerald Room

 

09:00 - 09:20, Preliminaries

 

     Debugging

     Note Well

     Note Takers

     Jabber = scribe

     Agenda bash

     Document = Status

 

Documents completing IETF Last Call (20 = minutes)

 

9:20 - 9:30 RADIUS over TCP, Alan DeKok (10 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-tcp

 

9:30 - 9:40 Design Guidelines, Alan DeKok (10 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-design-gui= delines

 

WG Work Items (50 minutes)

 

9:40 - 10:00 RADIUS over TLS, Stefan Winter (20 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-radsec

 

10:00 - 10:20 Dynamic Peer Discovery, Stefan Winter = (20 minutes)

http://tools.ietf.org/html/draft-ietf-radext-dynamic-di= scovery

 

10:20 - 10:30 RADIUS over DTLS, Alan DeKok (10 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-dtls<= /o:p>

 

 

Individual Submissions (30 minutes)

 

10:30 - 11:00 Extended RADIUS Attributes, Alan = DeKok (30 minutes)

http://tools.ietf.org/html/draft-dekok-radext-radius-ex= tensions

 

Discussion and Wrap-up (30 minutes)

 

 

11:00 – 11:15 Discussion (15 = minutes)

11:15 - 11:30  Next Steps:  WG Chairs = & ADs (15 minutes)

------=_NextPart_000_0394_01CB78E7.0E2F7200-- -- 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-data0@psg.com Delivery-date: Wed, 27 Oct 2010 19:54:19 +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: [OPS-DIR] Operations Directorate Review ofdraft-ietf-radext-design-18 Date: Wed, 27 Oct 2010 20:28:31 +0200 Message-ID: Thread-Topic: [OPS-DIR] Operations Directorate Review ofdraft-ietf-radext-design-18 Thread-Index: Act2AYQ4DEMs1RQdQ16MFOqhitu2uAAAu72Q From: "Romascanu, Dan (Dan)" To: , Cc: , "radext mailing list" , Hi Alan, Please prepare a revised ID and submit it as soon as the pre-IETF submission blackout is over which is the Monday of the IETF meeting. I plan to put this document on the agenda of the first IESG telechat after Beijing.=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: ops-dir-bounces@ietf.org=20 > [mailto:ops-dir-bounces@ietf.org] On Behalf Of Alan T DeKok > Sent: Wednesday, October 27, 2010 2:54 PM > To: lionel.morand@orange-ftgroup.com > Cc: ops-dir@ietf.org; 'radext mailing list'; gdweber@gmail.com > Subject: Re: [OPS-DIR] Operations Directorate Review=20 > ofdraft-ietf-radext-design-18 >=20 > lionel.morand@orange-ftgroup.com wrote: > > I reviewed the document draft-ietf-radext-design-18 and here is my=20 > > feedback. > ... > > I found this draft OK. Authors and reviewers have tried to provide=20 > > clear statements and recommendations regarding the RADIUS attribute=20 > > design. I can only regret that the recommendations are=20 > spread all over=20 > > the document and it is quite difficult to find them if you are not=20 > > reading the whole doucment. >=20 > Appendix A outlines the recommendations in detail, and in a=20 > short form. We can add text at the start which points to the=20 > appendix as a simple set of the recommendations. >=20 > > This document provides guidelines for the design of RADIUS=20 > > attributes > >=20 > > [LM] RADIUS acronym can be expended at this stage, instead=20 > of doing it=20 > > later. [LM] >=20 > OK. >=20 > > [LM] s/will used/will be used [LM] >=20 > Fixes. >=20 > > standard space > > RADIUS attributes which are allocated by IANA and=20 > which follow the > > format defined in RFC 2865 [RFC2865] Section 5. > >=20 > > [LM] Comment: instead of speaking of attributes, we should=20 > speak about=20 > > codes allocated from the standard/vendor space. [LM] >=20 > OK. >=20 >=20 > > The advice in this document applies to attributes used to encode > >=20 > > [LM] s/applies to attributes/applies to RADIUS attributes [LM] >=20 > That should be implicit, but OK. >=20 > > [LM] s/standards space/standard space [LM] >=20 > Fixed here, and elsewhere. >=20 > > Note that the RADEXT WG is currently (as of 2010) involved in > > developing updates to RADIUS. Those updates will=20 > provide their own > > usage guidelines that may "override" some of the=20 > guidelines discussed > > here. > >=20 > > [LM] comment: this part is a little bit tricky. It is said at the=20 > > beginning that this document should be used as guidelines,=20 > especially=20 > > for standard code allocation, while it is said right after that the=20 > > existing work could "override" some of the statements=20 > encapuslated in=20 > > this BCP. Is "override" the right wording here? I mean, do=20 > you foresee=20 > > any possible 'conflict' or it is just to say that some guidelines=20 > > introduced by new documents miht not be covered by this BCP? Some=20 > > clarification text may be useful [LM] >=20 > OK. I think "modify" is a better work than "over-ride". =20 > Adding an example like "such as adding new data types" should=20 > be a good clarification. >=20 > > conformance with the design guidelines in this document=20 > is expected > > unless a good case can be made for an exception. =20 > Reviewers SHOULD > > use the design guidelines as a review checklist. > >=20 > > [LM] why just a "SHOULD" here, when speaking about standard=20 > space? The=20 > > use of this checlinst can be made required in the IETF=20 > process, except=20 > > if it is out of scope of BCP. Mandate the use of this=20 > checklist does=20 > > not mean that we mandate to follow scrupulously all the guidelines.=20 > > [LM] >=20 > The document is a BCP, and can't require modifications to=20 > the IETF process. >=20 > > While not required, IETF review may also be beneficial for > > specifications utilizing the Vendor-Specific space.=20 > Experience has > > shown that attributes not originally designed for=20 > general usage can > > subsequently garner wide-spread deployment. An example is the > > vendor-specific attributes defined in [RFC2548], which have been > > widely implemented within IEEE 802.11 Access Points. > >=20 > > [LM] I failded to see the link between this BCP and an IETF=20 > review of=20 > > vendor specific attributes. What would be the added value=20 > of an IETF=20 > > review if vendors/SDOs are following the guidelines of this BCP? >=20 > If the SDOs are doing something which has wider use, the=20 > review might suggest to do the work within the IETF, rather=20 > than within the SDO. >=20 > > Similarly, vendors are encouraged to make their specifications > > publicly available, for maximum interoperability. =20 > However, it is not > > necessary for a vendor to request publication of a VSA=20 > specification > > as an Informational RFC by the IETF. > >=20 > > [LM] the main part of this text details the process for an=20 > IETF review. > > As expressed above, the link of this process and the present BCP is=20 > > not obvious. It even seems quite contradictory. [LM] >=20 > It suggest reviews are good, but not mandatory. >=20 > > 2. Guidelines > >=20 > > The Remote Authentication Dial In User Service (RADIUS)=20 > defined in > >=20 > > [LM] see comment in Introduction reagrding RADIUS acronym expansion=20 > > [LM] >=20 > OK. >=20 > > [LM] RADIUS design decision we/RADIUS design decision, we [LM] >=20 > OK. >=20 > > [LM] s/defined in Section 2.1,/defined in Section 2.1 of this=20 > > document, [LM] >=20 > OK. >=20 > > [RFC2865] RADIUS VSA. All other data formats are=20 > "complex types". > >=20 > > [LM] in section 3.2.3, complex data type is characherized as=20 > > attributes with multiple sub-fields into the > > "Value" field. Should we reflect this point at this stage, when=20 > > defining the two kinds of data types? [LM] >=20 > No. The text in 3.2.3 gives an *example* of a complex=20 > type. It shouldn't be construed as defining what a complex type is. >=20 > > [LM] s/this situation.. Code-point/this situation. Code-point [LM] >=20 > OK. >=20 > > * Attributes that are of broad interest to the=20 > Internet Community. > > Multi-vendor interoperability is expected. > >=20 > > [LM] I think that if it is foro Internet Community,=20 > interoperability=20 > > is required and not "expected" [LM] >=20 > Sure... but we can't require that in a BCO. >=20 > > [LM] we should not speak about "self-allocation" but use of code=20 > > values reserved for standard attributes. [LM] >=20 > OK. >=20 > > * Enumerated data types, represented as a 32-bit=20 > unsigned integer > > with a list of name to value mappings. (e.g. Service-Type) > >=20 > > [LM] why a specific example here? [LM] >=20 > Because it makes it clearer...? >=20 > > [LM] s/their own Attributes/their own attributes [LM] >=20 > OK. >=20 > > [LM] s/allocation (or self-allocating) from/allocation from [LM] >=20 > OK. >=20 > > It is therefore NOT RECOMMENDED that specifications=20 > intended solely > > for use by a vendor or SDO use be translated into the=20 > standard space. > >=20 > > [LM] It would be maybe useful to summarize the set of=20 > recommendations=20 > > in a dedicated sub-section at the end of this chapter. It could be=20 > > done through a table listing the recommendations and a reference to=20 > > the section in which the recommendation is explained. This=20 > table could=20 > > help reviewer, along with the checking list provided in Annex. [LM] >=20 > That's already done in Appendix A. I don't think we need=20 > to repeat it here. >=20 > > 3. Rationale > >=20 > > This section outlines the rationale behind the above=20 > recommendations. > >=20 > > [skip] > >=20 > > [LM] I would suggest to split the whole section on multiple=20 > > sub-sections dedicated to a single point concluded by a=20 > recommendation=20 > > [LM] >=20 > I disagree. The first sentence clearly says=20 > "recommendations are given above". Repeating them here is awkward. >=20 > The WG went through 3-4 complete re-organizations of the document. > The form it's in now was judged to the the simplest of the=20 > alternatives, including the one you're proposing here. >=20 > > [LM] and this has lead/and this has led [LM] >=20 > OK. >=20 > > Subsequent RADIUS specifications defined attributes by using type > > names not defined in [RFC2865], without defining the new=20 > names as was > > done in [RFC2865]. They did not consistently indicate=20 > the format=20 > > of > >=20 > > [LM] either "names as it was done" or "names as done" [LM] >=20 > "names as done" seems clearer. >=20 > > In other cases, the data in the complex type are=20 > described textually. > > This is possible because the data types are not sent within the > > attributes, but are a matter for endpoint interpretation. An > > implementation can define additional data types, and use=20 > these data > > types today by matching them to the attribute's textual=20 > description. > >=20 > > [LM] an example could help to understand the paragraph above [LM] >=20 > OK. I'll work on something. >=20 > > 3.3.1. Interoperability Considerations > >=20 > > Vendors and SDOs are reminded that the standard RADIUS attribute > > space, and the enumerated value space for enumerated=20 > attributes, are > > reserved for allocation through work published via the=20 > IETF, as noted > > in [RFC3575] Section 2.1. Some vendors and SDOs have in the past > > performed self-allocation by assigning vendor-specific meaning to > > "unused" values from the standard RADIUS attribute ID or=20 > enumerated > > value space. This self-allocation results in interoperability > > issues, and is counter-productive. Similarly, the=20 > Vendor-Specific > > enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT > > RECOMMENDED. > >=20 > > [LM] here it is exactly why I'm relunctant to speak about=20 > > self-allocation. Values from the standard space are not formally=20 > > allocated but used by vendors/SDOs. Self-allocation would mean that=20 > > you can decide on your own to allocate standard values to=20 > non-standard=20 > > attributes and that theses values would be considered by IETF as=20 > > already allocated, that is not the case here. If it was the case,=20 > > there will be no interoperability issue, only a problem of=20 > standard value exhaustion. > > As I said, what it is not recommended is to use values from the=20 > > standard space without official IETF allocation. [LM] >=20 > OK. I'll re-word it to remove the "self-allocation" text. >=20 > > If it is not possible to follow the IETF process,=20 > vendors and SDOs > > SHOULD self-allocate an attribute, which MUST be in=20 > vendor space, as > > discussed in Sections 3.3.2 and 3.3.3, below. > >=20 > > [LM] just a note: vendors and SDOs do not share the same=20 > vendor space=20 > > and vendors are not encouraged to pick values in the SDO=20 > vendor space. > > [LM] >=20 > Hmm... OK. It could say "MUST be in their own vendor space". >=20 > > [LM] s/requesting a PEC/requesting a PEN [LM] >=20 > OK. >=20 > > [LM] s/As a result. pre-existing/As a result, pre-existing [LM] >=20 > OK. >=20 > > in Appendix B MAY be used. > >=20 > > [skip] > >=20 > > A.2.2. More Complex Data Types > >=20 > > Does the attribute: > >=20 > > * define a complex data type not described in Appendix B, > >=20 > > [LM] s/Appendix B,/Appendix B? [LM] > >=20 >=20 > I disagree. The text is part of a run-on sentence which=20 > continues to the next bullet point. >=20 > Alan DeKok. > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir >=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-data0@psg.com Delivery-date: Wed, 27 Oct 2010 13:37:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Operations Directorate Review of draft-ietf-radext-design-18 Date: Wed, 27 Oct 2010 15:02:18 +0200 Message-ID: Thread-Topic: Operations Directorate Review of draft-ietf-radext-design-18 Thread-Index: Act11gCn/umKpWOWT6iTJYiA+uqhFwAAH9+Q From: To: Cc: , , Hi Alan, Thanks for your prompt answer. And thank you for taking account my = comment. I have no problem with the proposed answer. About re-organizing the doc, I understand your concerns. Regards, Lionel =20 > -----Message d'origine----- > De : Alan T DeKok [mailto:aland@freeradius.org]=20 > Envoy=E9 : mercredi 27 octobre 2010 14:54 > =C0 : MORAND Lionel RD-CORE-ISS > Cc : ops-dir@ietf.org; gdweber@gmail.com; 'radext mailing list' > Objet : Re: Operations Directorate Review of=20 > draft-ietf-radext-design-18 >=20 > lionel.morand@orange-ftgroup.com wrote: > > I reviewed the document draft-ietf-radext-design-18 and here is my=20 > > feedback. > ... > > I found this draft OK. Authors and reviewers have tried to provide=20 > > clear statements and recommendations regarding the RADIUS attribute=20 > > design. I can only regret that the recommendations are=20 > spread all over=20 > > the document and it is quite difficult to find them if you are not=20 > > reading the whole doucment. >=20 > Appendix A outlines the recommendations in detail, and in a=20 > short form. We can add text at the start which points to the=20 > appendix as a simple set of the recommendations. >=20 > > This document provides guidelines for the design of RADIUS=20 > > attributes > >=20 > > [LM] RADIUS acronym can be expended at this stage, instead=20 > of doing it=20 > > later. [LM] >=20 > OK. >=20 > > [LM] s/will used/will be used [LM] >=20 > Fixes. >=20 > > standard space > > RADIUS attributes which are allocated by IANA and=20 > which follow the > > format defined in RFC 2865 [RFC2865] Section 5. > >=20 > > [LM] Comment: instead of speaking of attributes, we should=20 > speak about=20 > > codes allocated from the standard/vendor space. [LM] >=20 > OK. >=20 >=20 > > The advice in this document applies to attributes used to encode > >=20 > > [LM] s/applies to attributes/applies to RADIUS attributes [LM] >=20 > That should be implicit, but OK. >=20 > > [LM] s/standards space/standard space [LM] >=20 > Fixed here, and elsewhere. >=20 > > Note that the RADEXT WG is currently (as of 2010) involved in > > developing updates to RADIUS. Those updates will=20 > provide their own > > usage guidelines that may "override" some of the=20 > guidelines discussed > > here. > >=20 > > [LM] comment: this part is a little bit tricky. It is said at the=20 > > beginning that this document should be used as guidelines,=20 > especially=20 > > for standard code allocation, while it is said right after that the=20 > > existing work could "override" some of the statements=20 > encapuslated in=20 > > this BCP. Is "override" the right wording here? I mean, do=20 > you foresee=20 > > any possible 'conflict' or it is just to say that some guidelines=20 > > introduced by new documents miht not be covered by this BCP? Some=20 > > clarification text may be useful [LM] >=20 > OK. I think "modify" is a better work than "over-ride". =20 > Adding an example like "such as adding new data types" should=20 > be a good clarification. >=20 > > conformance with the design guidelines in this document=20 > is expected > > unless a good case can be made for an exception. =20 > Reviewers SHOULD > > use the design guidelines as a review checklist. > >=20 > > [LM] why just a "SHOULD" here, when speaking about standard=20 > space? The=20 > > use of this checlinst can be made required in the IETF=20 > process, except=20 > > if it is out of scope of BCP. Mandate the use of this=20 > checklist does=20 > > not mean that we mandate to follow scrupulously all the guidelines.=20 > > [LM] >=20 > The document is a BCP, and can't require modifications to=20 > the IETF process. >=20 > > While not required, IETF review may also be beneficial for > > specifications utilizing the Vendor-Specific space.=20 > Experience has > > shown that attributes not originally designed for=20 > general usage can > > subsequently garner wide-spread deployment. An example is the > > vendor-specific attributes defined in [RFC2548], which have been > > widely implemented within IEEE 802.11 Access Points. > >=20 > > [LM] I failded to see the link between this BCP and an IETF=20 > review of=20 > > vendor specific attributes. What would be the added value=20 > of an IETF=20 > > review if vendors/SDOs are following the guidelines of this BCP? >=20 > If the SDOs are doing something which has wider use, the=20 > review might suggest to do the work within the IETF, rather=20 > than within the SDO. >=20 > > Similarly, vendors are encouraged to make their specifications > > publicly available, for maximum interoperability. =20 > However, it is not > > necessary for a vendor to request publication of a VSA=20 > specification > > as an Informational RFC by the IETF. > >=20 > > [LM] the main part of this text details the process for an=20 > IETF review. > > As expressed above, the link of this process and the present BCP is=20 > > not obvious. It even seems quite contradictory. [LM] >=20 > It suggest reviews are good, but not mandatory. >=20 > > 2. Guidelines > >=20 > > The Remote Authentication Dial In User Service (RADIUS)=20 > defined in > >=20 > > [LM] see comment in Introduction reagrding RADIUS acronym expansion=20 > > [LM] >=20 > OK. >=20 > > [LM] RADIUS design decision we/RADIUS design decision, we [LM] >=20 > OK. >=20 > > [LM] s/defined in Section 2.1,/defined in Section 2.1 of this=20 > > document, [LM] >=20 > OK. >=20 > > [RFC2865] RADIUS VSA. All other data formats are=20 > "complex types". > >=20 > > [LM] in section 3.2.3, complex data type is characherized as=20 > > attributes with multiple sub-fields into the > > "Value" field. Should we reflect this point at this stage, when=20 > > defining the two kinds of data types? [LM] >=20 > No. The text in 3.2.3 gives an *example* of a complex=20 > type. It shouldn't be construed as defining what a complex type is. >=20 > > [LM] s/this situation.. Code-point/this situation. Code-point [LM] >=20 > OK. >=20 > > * Attributes that are of broad interest to the=20 > Internet Community. > > Multi-vendor interoperability is expected. > >=20 > > [LM] I think that if it is foro Internet Community,=20 > interoperability=20 > > is required and not "expected" [LM] >=20 > Sure... but we can't require that in a BCO. >=20 > > [LM] we should not speak about "self-allocation" but use of code=20 > > values reserved for standard attributes. [LM] >=20 > OK. >=20 > > * Enumerated data types, represented as a 32-bit=20 > unsigned integer > > with a list of name to value mappings. (e.g. Service-Type) > >=20 > > [LM] why a specific example here? [LM] >=20 > Because it makes it clearer...? >=20 > > [LM] s/their own Attributes/their own attributes [LM] >=20 > OK. >=20 > > [LM] s/allocation (or self-allocating) from/allocation from [LM] >=20 > OK. >=20 > > It is therefore NOT RECOMMENDED that specifications=20 > intended solely > > for use by a vendor or SDO use be translated into the=20 > standard space. > >=20 > > [LM] It would be maybe useful to summarize the set of=20 > recommendations=20 > > in a dedicated sub-section at the end of this chapter. It could be=20 > > done through a table listing the recommendations and a reference to=20 > > the section in which the recommendation is explained. This=20 > table could=20 > > help reviewer, along with the checking list provided in Annex. [LM] >=20 > That's already done in Appendix A. I don't think we need=20 > to repeat it here. >=20 > > 3. Rationale > >=20 > > This section outlines the rationale behind the above=20 > recommendations. > >=20 > > [skip] > >=20 > > [LM] I would suggest to split the whole section on multiple=20 > > sub-sections dedicated to a single point concluded by a=20 > recommendation=20 > > [LM] >=20 > I disagree. The first sentence clearly says=20 > "recommendations are given above". Repeating them here is awkward. >=20 > The WG went through 3-4 complete re-organizations of the document. > The form it's in now was judged to the the simplest of the=20 > alternatives, including the one you're proposing here. >=20 > > [LM] and this has lead/and this has led [LM] >=20 > OK. >=20 > > Subsequent RADIUS specifications defined attributes by using type > > names not defined in [RFC2865], without defining the new=20 > names as was > > done in [RFC2865]. They did not consistently indicate=20 > the format=20 > > of > >=20 > > [LM] either "names as it was done" or "names as done" [LM] >=20 > "names as done" seems clearer. >=20 > > In other cases, the data in the complex type are=20 > described textually. > > This is possible because the data types are not sent within the > > attributes, but are a matter for endpoint interpretation. An > > implementation can define additional data types, and use=20 > these data > > types today by matching them to the attribute's textual=20 > description. > >=20 > > [LM] an example could help to understand the paragraph above [LM] >=20 > OK. I'll work on something. >=20 > > 3.3.1. Interoperability Considerations > >=20 > > Vendors and SDOs are reminded that the standard RADIUS attribute > > space, and the enumerated value space for enumerated=20 > attributes, are > > reserved for allocation through work published via the=20 > IETF, as noted > > in [RFC3575] Section 2.1. Some vendors and SDOs have in the past > > performed self-allocation by assigning vendor-specific meaning to > > "unused" values from the standard RADIUS attribute ID or=20 > enumerated > > value space. This self-allocation results in interoperability > > issues, and is counter-productive. Similarly, the=20 > Vendor-Specific > > enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT > > RECOMMENDED. > >=20 > > [LM] here it is exactly why I'm relunctant to speak about=20 > > self-allocation. Values from the standard space are not formally=20 > > allocated but used by vendors/SDOs. Self-allocation would mean that=20 > > you can decide on your own to allocate standard values to=20 > non-standard=20 > > attributes and that theses values would be considered by IETF as=20 > > already allocated, that is not the case here. If it was the case,=20 > > there will be no interoperability issue, only a problem of=20 > standard value exhaustion. > > As I said, what it is not recommended is to use values from the=20 > > standard space without official IETF allocation. [LM] >=20 > OK. I'll re-word it to remove the "self-allocation" text. >=20 > > If it is not possible to follow the IETF process,=20 > vendors and SDOs > > SHOULD self-allocate an attribute, which MUST be in=20 > vendor space, as > > discussed in Sections 3.3.2 and 3.3.3, below. > >=20 > > [LM] just a note: vendors and SDOs do not share the same=20 > vendor space=20 > > and vendors are not encouraged to pick values in the SDO=20 > vendor space. > > [LM] >=20 > Hmm... OK. It could say "MUST be in their own vendor space". >=20 > > [LM] s/requesting a PEC/requesting a PEN [LM] >=20 > OK. >=20 > > [LM] s/As a result. pre-existing/As a result, pre-existing [LM] >=20 > OK. >=20 > > in Appendix B MAY be used. > >=20 > > [skip] > >=20 > > A.2.2. More Complex Data Types > >=20 > > Does the attribute: > >=20 > > * define a complex data type not described in Appendix B, > >=20 > > [LM] s/Appendix B,/Appendix B? [LM] > >=20 >=20 > I disagree. The text is part of a run-on sentence which=20 > continues to the next bullet point. >=20 > Alan DeKok. >=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-data0@psg.com Delivery-date: Tue, 26 Oct 2010 11:55:48 +0000 Message-ID: From: Bernard Aboba To: Subject: Call for Agenda Items for IETF 79 Date: Tue, 26 Oct 2010 04:54:59 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0205_01CB74C9.F1CA0BF0" Content-Language: en-us Thread-Index: Act1BD6iiQqJG+veRMig92RFA021NwAABNlw ------=_NextPart_000_0205_01CB74C9.F1CA0BF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The RADEXT WG has a session scheduled at IETF 79 on Friday, November 12, 2010 from 0900 - 1130 AM. We would now like to solicit agenda items. If you have an agenda item, please send it to myself or Mauricio. ------=_NextPart_000_0205_01CB74C9.F1CA0BF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The RADEXT WG has a = session scheduled at IETF 79 on Friday, November 12, 2010 from 0900 - 1130 AM. =

 

We would now like to = solicit agenda items.

 

If you have an agenda = item, please send it to myself or Mauricio.  

------=_NextPart_000_0205_01CB74C9.F1CA0BF0-- -- 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-data0@psg.com Delivery-date: Tue, 26 Oct 2010 05:18:17 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_7f9b9d45-e0f8-437c-be9a-faa08a0249c3_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Draft minutes of the RADEXT Virtual Interim Date: Mon, 25 Oct 2010 22:16:50 -0700 MIME-Version: 1.0 --_7f9b9d45-e0f8-437c-be9a-faa08a0249c3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Minutes of the RADEXT Virtual Interim Meeting Monday=2C October 11=2C 2010 8 AM - 10 AM Pacific Time Chairs Bernard Aboba Mauricio Sanchez Agenda 8 AM - 8:10 AM Preliminaries (10 minutes) Attendance Note takers Agenda bash Document Status Documents Completing IETF Last Call (40 minutes) 8:10 AM - 8:30 AM RADIUS over TCP=2C Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp Major open issue is what port is to be reserved for Dynauth over TLS.=20 Should this port be reserved in the RADIUS over TCP document or in the RTLS document? Since we are talking about Dynauth over TLS=2C not Dynauth over TCP=2C it's not clear why this has to be reserved in this document.=20 Resolution is to remove the port reservation for Dynauth over TLS.=20 8:30AM - 8:50 AM Design Guidelines=2C Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-design-guidelines Went over open Issues: 52=2C 53=2C 54=2C 55=2C 57=2C 58. =20 Most have been addressed in Design Guidelines -17. Remainder will be fixed in -18.=20 Once -18 is issued=2C the document will need to go back to IETF last call=3B too many changes have been made to it.=20 RADEXT WG Work Items (40 minutes) 8:50 AM - 9:20 AM Extended RADIUS Attributes=2C Alan DeKok (30 minutes) http://tools.ietf.org/html/draft-dekok-radext-radius-extensions Alan DeKok and Avi Lior have been working on a new proposal for Extended RADIUS attributes to replace the old (moribund) proposal.=20 The requirements are to enable more RADIUS Attribute Type space=2C and provide standard support for "long" attributes as well as better=20 grouping.=20 The proposal is to "steal" one octet of "value" for extended types=2C and allocate 4 attributes for this format: 241=2C 242=2C 243=2C 244. This wil= l=20 allow for ~1K new attributes=2C which should last a few decades at least.=20 To name the new attributes "dotted number" notation is proposed=20 (e.g. 241.1). This is only relevant for the IANA registry=2C not the protocol itself.=20 Grouping is enabled by defining a TLV data type. This is already in use in WiMAX=2C 3GPP2 and other SDOs. Multiple TLVs can be in one Extended Attribute=2C nested or concatenated=2C with nesting limited only by TLV length (253/3 =3D ~80). Depth of 5 is sufficient. For "Long" Attributes two attributes are allocated: 245=2C 246. A "flag" field is added to enable "more than 253 octets of data" to be indicated.=20 The proposal also enables additional VSAs to be provided to vendors.=20 Some vendors have run out (and their request for additional Enterprise Codes has been denied) so this will come in handy.=20 How do we move forward? Some vendors (who can't get Enterprise Codes) need this now=3B others will need it in 2-3 years when the RADIUS attribute space could run out.=20 Sense of the room is that the proposal is promising=3B the draft will be pl= aced on the IETF 79 agenda for further discussion.=20 9:20 - 9:30 AM RADIUS over DTLS=2C Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls-00.txt This document currently reuses existing RADIUS and Dynauth ports. This is convenient because no new ports are needed=2C and because DTLS and RADIUS c= an easily be distinguished from each other. If we asked for new ports for TLS=2C DTLS=2C for both RADIUS and Dynauth=2C some eyebrows would probably = be raised (and rightfully so).=20 Implementations are currently in progress in RadSecProxy=2C Jradius and Fre= eRADIUS (expected 1Q 2011). Review from the implementers is an outstanding item.=20 Meeting Adjourned at 9:45 AM.=20 =20 = --_7f9b9d45-e0f8-437c-be9a-faa08a0249c3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Minutes of the RADEXT Virtual Interim Meeting

Monday=2C October 11= =2C 2010
8 AM - 10 AM Pacific Time

Chairs
Bernard Aboba <=3B= bernard_aboba at hotmail.com>=3B
Mauricio Sanchez <=3Bmauricio.sanch= ez at hp.com>=3B

Agenda

8 AM - 8:10 AM Preliminaries (10 mi= nutes)
 =3B =3B =3B =3B Attendance
 =3B =3B&n= bsp=3B =3B Note takers
 =3B =3B =3B =3B Agenda bash<= br> =3B =3B =3B =3B Document Status

Documents Comple= ting IETF Last Call (40 minutes)

8:10 AM - 8:30 AM RADIUS over TCP= =2C Alan DeKok (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext= -tcp

Major open issue is what port is to be reserved for Dynauth ove= r TLS.
Should this port be reserved in the RADIUS over TCP document or = in the
RTLS document? =3B Since we are talking about Dynauth over TL= S=2C not Dynauth
over TCP=2C it's not clear why this has to be reserved = in this document.

Resolution is to remove the port reservation for = Dynauth over TLS.

8:30AM - 8:50 AM Design Guidelines=2C Alan DeKok = (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-design-guideli= nes

Went over open Issues: 52=2C 53=2C 54=2C 55=2C 57=2C 58.  = =3B
Most have been addressed in Design Guidelines -17. =3B Remainder=
will be fixed in -18.

Once -18 is issued=2C the document will n= eed to go back to IETF last
call=3B too many changes have been made to i= t.

RADEXT WG Work Items (40 minutes)

8:50 AM - 9:20 AM Exten= ded RADIUS Attributes=2C Alan DeKok (30 minutes)
http://tools.ietf.org/h= tml/draft-dekok-radext-radius-extensions

Alan DeKok and Avi Lior hav= e been working on a new proposal for Extended
RADIUS attributes to repla= ce the old (moribund) proposal.

The requirements are to enable more= RADIUS Attribute Type space=2C and
provide standard support for "long" = attributes as well as better
grouping.

The proposal is to "stea= l" one octet of "value" for extended types=2C and
allocate 4 attributes = for this format: =3B 241=2C 242=2C 243=2C 244. =3B This will
al= low for ~1K new attributes=2C which should last a few decades at least.
To name the new attributes "dotted number" notation is proposed
(e= .g. 241.1). =3B This is only relevant for the IANA registry=2C not the<= br>protocol itself.

Grouping is enabled by defining a TLV data type= . =3B This is already
in use in WiMAX=2C 3GPP2 and other SDOs. = =3B Multiple TLVs can be in
one Extended Attribute=2C nested or concaten= ated=2C with nesting
limited only by TLV length (253/3 =3D ~80). =3B= Depth of 5 is sufficient.

For "Long" Attributes two attributes are = allocated: =3B 245=2C 246. A
"flag" field is added to enable "more t= han 253 octets of data"
to be indicated.

The proposal also enabl= es additional VSAs to be provided to vendors.
Some vendors have run out= (and their request for additional Enterprise
Codes has been denied) so = this will come in handy.

How do we move forward? =3B Some vendo= rs (who can't get Enterprise Codes)
need this now=3B others will need it= in 2-3 years when the RADIUS attribute
space could run out.

Sen= se of the room is that the proposal is promising=3B the draft will be place= d on
the IETF 79 agenda for further discussion.

9:20 - 9:30 AM R= ADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/dr= aft-ietf-radext-dtls-00.txt

This document currently reuses existing = RADIUS and Dynauth ports. =3B This is
convenient because no new port= s are needed=2C and because DTLS and RADIUS can
easily be distinguished = from each other. =3B If we asked for new ports for
TLS=2C DTLS=2C fo= r both RADIUS and Dynauth=2C some eyebrows would probably be raised
(and= rightfully so).

Implementations are currently in progress in RadSe= cProxy=2C Jradius and FreeRADIUS
(expected 1Q 2011). =3B Review from= the implementers is an outstanding item.

Meeting Adjourned at 9:45= AM.

 =3B



= --_7f9b9d45-e0f8-437c-be9a-faa08a0249c3_-- -- 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-data0@psg.com Delivery-date: Tue, 12 Oct 2010 17:54:20 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Cc: Subject: Last Call: (RADIUS Design Guidelines) to BCP Message-ID: <20101012175206.8069.4849.idtracker@localhost> Date: Tue, 12 Oct 2010 10:52:06 -0700 The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'RADIUS Design Guidelines' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-10-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note that this is a second IETF Last Call. As the document underwent through significant changes after the IESG review, the Area Director and the Working Group chairs decided to request again the community consensus before another IESG review. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-radext-design/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-radext-design/ No IPR declarations were found that appear related to this I-D. -- 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-data0@psg.com Delivery-date: Tue, 12 Oct 2010 14:24:25 +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: Updated drafts Date: Tue, 12 Oct 2010 16:23:41 +0200 Message-ID: Thread-Topic: Updated drafts Thread-Index: ActqFwiQ3mBMl5mYS+y623ILV1e3EwAATQ1A From: "Romascanu, Dan (Dan)" To: "Alan DeKok" , "radext mailing list" See in-line. Thanks and Regards, Dan =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok > Sent: Tuesday, October 12, 2010 4:08 PM > To: 'radext mailing list' > Subject: Updated drafts >=20 >=20 > I've updated a few documents today: >=20 > guidelines: addressed the last few issues as noted on the tracker. >=20 > The are now no open issues against the document. >=20 As discueed in the virtual interim - this document will go to a new IETF Last Call and a new IESG review.=20 >=20 > tcp transport: removed references to "radsec" port >=20 > The are now no open issues against the document. >=20 >=20 As discussed in the virtual interim - we shall work to clear the pending DISCUSS and approve this document.=20 > DTLS: added a short discussion on NAT >=20 > NAT and RADIUS are fundamentally incompatible. >=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-data0@psg.com Delivery-date: Tue, 12 Oct 2010 14:16:37 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-dtls-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101012141504.269373A696B@core3.amsl.com> Date: Tue, 12 Oct 2010 07:15: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 : DTLS as a Transport Layer for RADIUS Author(s) : A. DeKok Filename : draft-ietf-radext-dtls-01.txt Pages : 18 Date : 2010-10-12 The RADIUS protocol [RFC2865] has limited support for authentication and encryption of RADIUS packets. The protocol transports data "in the clear", although some parts of the packets can have "hidden" content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can co-exist with current RADIUS systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-dtls-01.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-dtls-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-12070330.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-data0@psg.com Delivery-date: Tue, 12 Oct 2010 14:08:25 +0000 Message-ID: <4CB46BBD.4050406@deployingradius.com> Date: Tue, 12 Oct 2010 16:07:57 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: 'radext mailing list' Subject: Updated drafts Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've updated a few documents today: guidelines: addressed the last few issues as noted on the tracker. The are now no open issues against the document. tcp transport: removed references to "radsec" port The are now no open issues against the document. DTLS: added a short discussion on NAT NAT and RADIUS are fundamentally incompatible. 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-data0@psg.com Delivery-date: Tue, 12 Oct 2010 13:47:08 +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-18.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101012134502.3B1FB3A6917@core3.amsl.com> Date: Tue, 12 Oct 2010 06: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 : RADIUS Design Guidelines Author(s) : G. Weber, A. DeKok Filename : draft-ietf-radext-design-18.txt Pages : 37 Date : 2010-10-12 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-18.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-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-12063326.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-data0@psg.com Delivery-date: Tue, 12 Oct 2010 12:47:12 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-tcp-transport-09.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101012124502.745FD3A68E4@core3.amsl.com> Date: Tue, 12 Oct 2010 05: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 : RADIUS Over TCP Author(s) : A. DeKok Filename : draft-ietf-radext-tcp-transport-09.txt Pages : 18 Date : 2010-10-12 The Remote Authentication Dial In User Server (RADIUS) Protocol has until now required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security (RADIUS/TLS). It permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentialy and security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-tcp-transport-09.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-tcp-transport-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-12054222.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-data0@psg.com Delivery-date: Mon, 11 Oct 2010 15:38:31 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Mon, 11 Oct 2010 15:38:15 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] design #52 (closed): Basic vs. Complex Attributes Message-ID: <075.5fc55799f9e9fbfb3b253bac5674a377@tools.ietf.org> #52: Basic vs. Complex Attributes Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Addressed in Section 1.3 as of -17. -- ---------------------------------------+------------------------------------ Reporter: Hannes.Tschofenig@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: design | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- 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-data0@psg.com Delivery-date: Mon, 11 Oct 2010 15:35:02 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: aland@deployingradius.com, bernard_aboba@hotmail.com Date: Mon, 11 Oct 2010 15:34:49 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] design #53 (closed): Notes Message-ID: <075.d5c427acc60d7e6084b57e6497c3bf5f@tools.ietf.org> #53: Notes Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Addressed in -17. -- ---------------------------------------+------------------------------------ Reporter: Hannes.Tschofenig@… | Owner: aland@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: design | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- 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-data0@psg.com Delivery-date: Mon, 11 Oct 2010 15:32:42 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: aland@deployingradius.com, bernard_aboba@hotmail.com Date: Mon, 11 Oct 2010 15:32:33 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] design #57 (closed): Disconnect-Request Message-ID: <075.acd228ad9d1f22a5e557a65943dbdc03@tools.ietf.org> #57: Disconnect-Request Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: To be fixed in -18. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: design | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- 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-data0@psg.com Delivery-date: Mon, 11 Oct 2010 15:32:27 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: aland@deployingradius.com, bernard_aboba@hotmail.com Date: Mon, 11 Oct 2010 15:32:13 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] design #58 (closed): Section A.4 Message-ID: <075.09d0f90ca47e1173bc9c517c1f437f10@tools.ietf.org> #58: Section A.4 Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: To be fixed in -18. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: design | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- 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-data0@psg.com Delivery-date: Mon, 11 Oct 2010 15:29:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: aland@deployingradius.com, bernard_aboba@hotmail.com Date: Mon, 11 Oct 2010 15:28:46 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] design #55 (closed): Disconnect-Request Message-ID: <075.db04ba9085d45859addd9d1f72d6575e@tools.ietf.org> #55: Disconnect-Request Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: aland@… Type: enhancement | Status: closed Priority: major | Milestone: milestone1 Component: design | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- 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-data0@psg.com Delivery-date: Mon, 11 Oct 2010 15:26:14 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: aland@deployingradius.com, bernard_aboba@hotmail.com Date: Mon, 11 Oct 2010 15:25:50 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] design #54 (closed): Editorial Nits Message-ID: <075.b0c6662141d18fa06b784e90d5adb1a5@tools.ietf.org> #54: Editorial Nits Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: aland@… Type: defect | Status: closed Priority: trivial | Milestone: milestone1 Component: design | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- 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-data0@psg.com Delivery-date: Mon, 11 Oct 2010 15:18:46 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: aland@deployingradius.com, bernard_aboba@hotmail.com Date: Mon, 11 Oct 2010 15:17:57 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] tcp-transport #59 (closed): Section 2.2 Assigned Ports Message-ID: <075.bd294a0f4c505e1032a1bc61dc961a54@tools.ietf.org> #59: Section 2.2 Assigned Ports Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Resolution: Remove the radsec 2083/tcp allocation. That should be accomplished in the RADSEC document. Discussion of Dynauth over TLS port usage should go in the RTLS document. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: tcp-transport | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- 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-data0@psg.com Delivery-date: Sun, 10 Oct 2010 18:21:58 +0000 Message-ID: From: Bernard Aboba To: Subject: Virtual Interim Slides Date: Sun, 10 Oct 2010 11:21:15 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0146_01CB686D.434D1440" Thread-Index: Actop+z3m5G8sVB/QbSu5U4yOUKiDg== Content-Language: en-us ------=_NextPart_000_0146_01CB686D.434D1440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit are now online: http://aboba.drizzlehosting.com/RADEXT/Oct-Interim/ ------=_NextPart_000_0146_01CB686D.434D1440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

are now online:

http://aboba.drizzlehosting.com/RADEXT/Oct-Interim/

 

 

------=_NextPart_000_0146_01CB686D.434D1440-- -- 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-data0@psg.com Delivery-date: Sun, 10 Oct 2010 16:06:31 +0000 Message-ID: From: Bernard Aboba To: Subject: RADEXT WG Virtual Interim Date: Sun, 10 Oct 2010 09:06:18 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 8bit Thread-Index: ActdPFtAhMPT7pKEQmOiEzANiG8tbALWLdcw Content-Language: en-us BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN=radiusext@ops.ietf.org;RSVP=TRUE:mailto:radiusext@ops.ietf.org CLASS:PUBLIC CREATED:20101010T160618Z DESCRIPTION:When: Monday\, October 11\, 2010 8:00 AM-10:00 AM (UTC-08:00) P acific Time (US & Canada).\nWhere: Teleconference\n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~ *~*~*\n\nConference phone number: +17024733463\nPasscode: 226220\nWeb con ference: https://my.dimdim.com/all/aboba/default/\nJabber room: radext at jabber.ietf.org (please join)\nPresentations: http://www.drizzle.com/~ab oba/RADEXT/Oct-Interim/\n\nChairs\n Bernard Aboba \n Mauricio Sanchez \n\nAg enda\n\n8 AM - 8:10 AM Preliminaries (10 minutes)\n Attendance\n N ote takers\n Agenda bash\n Document Status\n\nDocuments Completing IETF Last Call (40 minutes)\n\n8:10 AM - 8:30 AM RADIUS over TCP\, Alan D eKok (20 minutes)\nhttp://tools.ietf.org/html/draft-ietf-radext-tcp\n\n8:3 0AM - 8:50 AM Design Guidelines\, Alan DeKok (20 minutes)\nhttp://tools.ie tf.org/html/draft-ietf-radext-design-guidelines\n\nRADEXT WG Work Items (4 0 minutes)\n\n8:50 AM - 9:20 AM Extended RADIUS Attributes\, Alan DeKok (3 0 minutes)\nhttp://tools.ietf.org/html/draft-dekok-radext-radius-extension s\n\n9:20 - 9:30 AM RADIUS over DTLS\, Alan DeKok (10 minutes)\nhttp://too ls.ietf.org/html/draft-ietf-radext-dtls-00.txt\n\n\n\n\n DTEND:20101011T170000Z DTSTAMP:20101010T160618Z DTSTART:20101011T150000Z LAST-MODIFIED:20101010T160618Z LOCATION:Teleconference ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:1 SUMMARY;LANGUAGE=en-us:RADEXT WG Virtual Interim TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000B006E2AE015DCB01000000000000000 0100000008F04804402948D4CB07C1206789F9361 X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Monday\, October 11\, 2010 8:00 AM-10:00 AM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: Teleconference

\n\n

Note: The GMT offset above does not reflect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~*~*~*

\n\n

Conference phone number: \; +17024733463

\n\n

Passcode: 226220

\n\n

Web conference: https://my.dimdim.com/all/ aboba/default/

\n\n

J abber room: \; radext at jabber.ietf.org (please join)\n\n

Presentations: < /FONT> http://www.drizzle.com/~aboba/RADEXT/Oct-Interim/

\n\n

Chairs

\n\n< P DIR=LTR> \; \; \;&nb sp\; \; \; \; Bernard Aboba <\;bernard_aboba at hotmail.com& gt\;

\n\n

 \; \; \; \; \; \; \; Mauricio Sanchez <\ ;mauricio.sanchez at hp.com>\;

\n\n

Agenda

\n\n

8 AM - 8:10 AM Preliminaries (10 minut es)

\n\n

 \; \; \; \; Attendance

\n\n

 \; \; \; \; Note takers

\n\n

 \; \; \; \; Agenda bash

\n\n

 \; \; \; \; D ocument Status

\n\n

Documents Completing IETF Last Call (40 minutes)

\n\n

8:10 AM - 8:30 AM RADIUS over TCP\, Alan DeKok (20 minutes)

\n\n

http://tools.ietf.org/html/draft-ietf-radext-tcp

\n\n

8:30AM - 8:50 AM Design Guidelines\, Alan DeKok (20 minutes)

\n\n

http://tools .ietf.org/html/draft-ietf-radext-design-guidelines

\n\n

RADEXT WG Work Items (40 minutes)

\n\n

8:50 AM - 9:20 AM Extended RADIUS Attributes\, Alan DeKok (30 minutes)

\n\n

http://tools.ietf.org/html/draft-dekok-radext-radius-exte nsions< /SPAN>

\n\n

\n\n

9:20 - 9:30 AM RADIUS over DTLS\, Alan DeKok (10 minutes)

\n\n

http://tools.ietf.org/html/draft-ietf-ra dext-dtls-00.txt

\n
\n\n

\n\ n

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTSEQTIME:20101003T180525Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR -- 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-data0@psg.com Delivery-date: Sun, 10 Oct 2010 16:01:16 +0000 Message-ID: From: Bernard Aboba To: Subject: REMINDER: RADEXT Virtual Interim on October 11, 2010 (tommorrow!) Date: Sun, 10 Oct 2010 09:00:12 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0112_01CB6859.8CD1F860" Thread-Index: ActolDjm6nuEt6U3RvmNw8NUSw68vQ== Content-Language: en-us ------=_NextPart_000_0112_01CB6859.8CD1F860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We are holding a RADEXT Virtual Interim meeting on October 11, 2010 (tommorrow!). If you are presenting, please send slides to me NOW, so I can get them up on the archive. Date: October 11, 2010 Time: 8 AM - 10 AM Pacific Time Conference phone number: +17024733463 Passcode: 226220 Web conference: https://my.dimdim.com/all/aboba/default/ Jabber room: radext at jabber.ietf.org (please join) Presentations: http://www.drizzle.com/~aboba/RADEXT/Oct-Interim/ Agenda 8 AM - 8:10 AM Preliminaries (10 minutes) Attendance Note takers Agenda bash Document Status Documents Completing IETF Last Call (40 minutes) 8:10 AM - 8:30 AM RADIUS over TCP, Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp 8:30AM - 8:50 AM Design Guidelines, Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-design-guidelines RADEXT WG Work Items (40 minutes) 8:50 AM - 9:20 AM Extended RADIUS Attributes, Alan DeKok (30 minutes) http://tools.ietf.org/html/draft-dekok-radext-radius-extensions 9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls-00.txt ------=_NextPart_000_0112_01CB6859.8CD1F860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are holding a RADEXT Virtual Interim meeting on = October 11, 2010 (tommorrow!).   If you are presenting, please send = slides to me NOW, so I can get them up on the archive.

 

Date:  October 11, 2010

Time: 8 AM - 10 AM Pacific Time

 

Conference phone number:  = +17024733463

Passcode: 226220

 

Web conference: = https://my.dimdim.com/all/aboba/default/

Jabber room:  radext at jabber.ietf.org = (please join)

Presentations:  http://www.drizzle.com/~aboba/RADEXT/Oct-Interim/

 

Agenda

 

8 AM - 8:10 AM Preliminaries (10 = minutes)

     Attendance

     Note takers

     Agenda bash

     Document = Status

 

Documents Completing IETF Last Call (40 = minutes)

 

8:10 AM - 8:30 AM RADIUS over TCP, Alan DeKok (20 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-tcp

 

8:30AM - 8:50 AM Design Guidelines, Alan DeKok (20 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-design-gui= delines

 

RADEXT WG Work Items (40 minutes)

 

8:50 AM - 9:20 AM Extended RADIUS Attributes, Alan = DeKok (30 minutes)

http://tools.ietf.org/html/draft-dekok-radext-radius-ex= tensions

 

9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-dtls-00.tx= t

 

------=_NextPart_000_0112_01CB6859.8CD1F860-- -- 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-data0@psg.com Delivery-date: Fri, 08 Oct 2010 11:18:49 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: aland@deployingradius.com Date: Fri, 08 Oct 2010 11:18:36 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] tcp-transport #25 (closed): IESG DISCUSS Comments Message-ID: <063.c3e25e6aedee7a675331eecd8d548e42@tools.ietf.org> #25: IESG DISCUSS Comments -----------------------------------+---------------------------------------- Reporter: iesg@… | Owner: aland@… Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: tcp-transport | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Changes (by aland@…): * status: new => closed * resolution: => fixed Comment: All comments have been addressed in -08 -- Ticket URL: radext -- 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-data0@psg.com Delivery-date: Fri, 08 Oct 2010 11:17:12 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-dtls-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101008111502.6466D3A6885@core3.amsl.com> Date: Fri, 8 Oct 2010 04:15: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 : DTLS as a Transport Layer for RADIUS Author(s) : A. DeKok Filename : draft-ietf-radext-dtls-00.txt Pages : 17 Date : 2010-10-08 The RADIUS protocol [RFC2865] has limited support for authentication and encryption of RADIUS packets. The protocol transports data "in the clear", although some parts of the packets can have "hidden" content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can co-exist with current RADIUS systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-dtls-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-dtls-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-08040234.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-data0@psg.com Delivery-date: Sun, 03 Oct 2010 18:13:46 +0000 Message-ID: From: Bernard Aboba To: Subject: Slides Date: Sun, 3 Oct 2010 11:14:08 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01CB62EC.194C0F10" Thread-Index: ActjJquKW2235m9WShWafV4tg6tK+AAAA/ig Content-Language: en-us ------=_NextPart_000_003F_01CB62EC.194C0F10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If you are presenting at the RADEXT Virtual Interim, please submit your slides by Friday, October 8. ------=_NextPart_000_003F_01CB62EC.194C0F10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you are presenting at the RADEXT Virtual = Interim, please submit your slides by Friday, October 8. 

------=_NextPart_000_003F_01CB62EC.194C0F10-- -- 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-data0@psg.com Delivery-date: Sun, 03 Oct 2010 18:11:26 +0000 Message-ID: From: Bernard Aboba To: Subject: RADEXT Virtual Interim Teleconference parameters Date: Sun, 3 Oct 2010 11:11:42 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01CB62EB.C27ED640" Thread-Index: Actdi4MCPPubv6TPSPK3p291qRj2IQFmb7iwAAA7gfA= Content-Language: en-us ------=_NextPart_000_003A_01CB62EB.C27ED640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Here are the teleconference parameters: Date: October 11, 2010 Time: 8 AM - 10 AM Pacific Time Conference phone number: +17024733463 Passcode: 226220 Web conference: https://my.dimdim.com/all/aboba/default/ Jabber room: radext at jabber.ietf.org (please join) Presentations: http://www.drizzle.com/~aboba/RADEXT/Oct-Interim/ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Sunday, October 03, 2010 11:05 AM To: 'radiusext@ops.ietf.org' Subject: RADEXT Virtual Interim Agenda - Take Four Agenda 8 AM - 8:10 AM Preliminaries (10 minutes) Attendance Note takers Agenda bash Document Status Documents Completing IETF Last Call (40 minutes) 8:10 AM - 8:30 AM RADIUS over TCP, Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp 8:30AM - 8:50 AM Design Guidelines, Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-design-guidelines RADEXT WG Work Items (40 minutes) 8:50 AM - 9:20 AM Extended RADIUS Attributes, Alan DeKok (30 minutes) http://tools.ietf.org/html/draft-dekok-radext-radius-extensions 9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls-00.txt ------=_NextPart_000_003A_01CB62EB.C27ED640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are the teleconference = parameters:

 

Date:  October 11, 2010

Time: 8 AM - 10 AM Pacific Time

Conference phone number:  +17024733463

Passcode: 226220

Web conference: https://my.dimdim.com/a= ll/aboba/default/

Jabber room:  radext at jabber.ietf.org (please = join)

Presentation= s:  http://www.dri= zzle.com/~aboba/RADEXT/Oct-Interim/

 

 

From:= Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Sunday, October 03, 2010 11:05 AM
To: 'radiusext@ops.ietf.org'
Subject: RADEXT Virtual Interim Agenda - Take = Four

 

Agenda<= /o:p>

 <= /o:p>

8 AM - 8:10 AM Preliminaries (10 minutes)

  =    Attendance

  =    Note takers

  =    Agenda bash

  =    Document Status

 <= /o:p>

Documents Completing IETF Last Call (40 minutes)

 <= /o:p>

8:10 AM - 8:30 AM RADIUS over TCP, Alan DeKok (20 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-tcp<= /span>

 

8:30AM - 8:50 AM Design Guidelines, Alan DeKok (20 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-design-guidelin= es

 

RADEXT WG Work Items (4= 0 minutes)

 

8:50 AM - 9:20 AM Extended RADIUS Attributes, Alan DeKok = (30 minutes)

http://tools.ietf.org/html/draft-dekok-radext-radius-extensi= ons

 

9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-dtls-00.txt

 

 <= /o:p>

------=_NextPart_000_003A_01CB62EB.C27ED640-- -- 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-data0@psg.com Delivery-date: Sun, 03 Oct 2010 18:05:20 +0000 Message-ID: From: Bernard Aboba To: Subject: RADEXT Virtual Interim Agenda - Take Four Date: Sun, 3 Oct 2010 11:04:36 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01CB62EA.C4A86270" Thread-Index: Actdi4MCPPubv6TPSPK3p291qRj2IQFmb7iw Content-Language: en-us ------=_NextPart_000_0034_01CB62EA.C4A86270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agenda 8 AM - 8:10 AM Preliminaries (10 minutes) Attendance Note takers Agenda bash Document Status Documents Completing IETF Last Call (40 minutes) 8:10 AM - 8:30 AM RADIUS over TCP, Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp 8:30AM - 8:50 AM Design Guidelines, Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-design-guidelines RADEXT WG Work Items (40 minutes) 8:50 AM - 9:20 AM Extended RADIUS Attributes, Alan DeKok (30 minutes) http://tools.ietf.org/html/draft-dekok-radext-radius-extensions 9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls-00.txt ------=_NextPart_000_0034_01CB62EA.C4A86270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agenda<= /o:p>

 <= /o:p>

8 AM - 8:10 AM Preliminaries (10 minutes)

  =    Attendance

  =    Note takers

  =    Agenda bash

  =    Document Status

 <= /o:p>

Documents Completing IETF Last Call (40 minutes)

 <= /o:p>

8:10 AM - 8:30 AM RADIUS over TCP, Alan DeKok (20 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-tcp<= /span>

 

8:30AM - 8:50 AM Design Guidelines, Alan DeKok (20 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-design-guidelin= es

 

RADEXT WG Work Items (4= 0 minutes)

 

8:50 AM - 9:20 AM Extended RADIUS Attributes, Alan DeKok = (30 minutes)

http://tools.ietf.org/html/draft-dekok-radext-radius-extensi= ons

 

9:20 AM - 9:30 AM RADIUS over DTLS, Alan DeKok (10 = minutes)

http://tools.ietf.org/html/draft-ietf-radext-dtls-00.txt

 

 <= /o:p>

------=_NextPart_000_0034_01CB62EA.C4A86270-- -- 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-data0@psg.com Delivery-date: Sun, 03 Oct 2010 18:05:13 +0000 Message-ID: From: Bernard Aboba To: Subject: RADEXT WG Virtual Interim Date: Sun, 3 Oct 2010 11:05:25 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 8bit Thread-Index: ActdPFtAhMPT7pKEQmOiEzANiG8tbAF6TJfA Content-Language: en-us BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN=radiusext@ops.ietf.org;RSVP=TRUE:mailto:radiusext@ops.ietf.org CLASS:PUBLIC CREATED:20101003T180525Z DESCRIPTION:When: Monday\, October 11\, 2010 8:00 AM-10:00 AM (UTC-08:00) P acific Time (US & Canada).\nWhere: Teleconference\n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~ *~*~*\n\nConference phone number: +17024733463\nPasscode: 226220\nWeb con ference: https://my.dimdim.com/all/aboba/default/\nJabber room: radext at jabber.ietf.org (please join)\nPresentations: http://www.drizzle.com/~ab oba/RADEXT/Oct-Interim/\n\nChairs\n Bernard Aboba \n Mauricio Sanchez \n\nAg enda\n\n8 AM - 8:10 AM Preliminaries (10 minutes)\n Attendance\n N ote takers\n Agenda bash\n Document Status\n\nDocuments Completing IETF Last Call (40 minutes)\n\n8:10 AM - 8:30 AM RADIUS over TCP\, Alan D eKok (20 minutes)\nhttp://tools.ietf.org/html/draft-ietf-radext-tcp\n\n8:3 0AM - 8:50 AM Design Guidelines\, Alan DeKok (20 minutes)\nhttp://tools.ie tf.org/html/draft-ietf-radext-design-guidelines\n\nRADEXT WG Work Items (4 0 minutes)\n\n8:50 AM - 9:20 AM Extended RADIUS Attributes\, Alan DeKok (3 0 minutes)\nhttp://tools.ietf.org/html/draft-dekok-radext-radius-extension s\n\n9:20 - 9:30 AM RADIUS over DTLS\, Alan DeKok (10 minutes)\nhttp://too ls.ietf.org/html/draft-ietf-radext-dtls-00.txt\n\n\n\n\n DTEND:20101011T170000Z DTSTAMP:20101003T180525Z DTSTART:20101011T150000Z LAST-MODIFIED:20101003T180525Z LOCATION:Teleconference ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:0 SUMMARY;LANGUAGE=en-us:RADEXT WG Virtual Interim TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000B006E2AE015DCB01000000000000000 0100000008F04804402948D4CB07C1206789F9361 X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Monday\, October 11\, 2010 8:00 AM-10:00 AM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: Teleconference

\n\n

Note: The GMT offset above does not reflect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~*~*~*

\n\n

Conference phone number: \; +17024733463

\n\n

Passcode: 226220

\n\n

Web conference: https://my.dimdim.com/all/ aboba/default/

\n\n

J abber room: \; radext at jabber.ietf.org (please join)\n\n

Presentations: < /FONT> http://www.drizzle.com/~aboba/RADEXT/Oct-Interim/

\n\n

Chairs

\n\n< P DIR=LTR> \; \; \;&nb sp\; \; \; \; Bernard Aboba <\;bernard_aboba at hotmail.com& gt\;

\n\n

 \; \; \; \; \; \; \; Mauricio Sanchez <\ ;mauricio.sanchez at hp.com>\;

\n\n

Agenda

\n\n

8 AM - 8:10 AM Preliminaries (10 minut es)

\n\n

 \; \; \; \; Attendance

\n\n

 \; \; \; \; Note takers

\n\n

 \; \; \; \; Agenda bash

\n\n

 \; \; \; \; D ocument Status

\n\n

Documents Completing IETF Last Call (40 minutes)

\n\n

8:10 AM - 8:30 AM RADIUS over TCP\, Alan DeKok (20 minutes)

\n\n

http://tools.ietf.org/html/draft-ietf-radext-tcp

\n\n

8:30AM - 8:50 AM Design Guidelines\, Alan DeKok (20 minutes)

\n\n

http://tools .ietf.org/html/draft-ietf-radext-design-guidelines

\n\n

RADEXT WG Work Items (40 minutes)

\n\n

8:50 AM - 9:20 AM Extended RADIUS Attributes\, Alan DeKok (30 minutes)

\n\n

http://tools.ietf.org/html/draft-dekok-radext-radius-exte nsions< /SPAN>

\n\n

\n\n

9:20 - 9:30 AM RADIUS over DTLS\, Alan DeKok (10 minutes)

\n\n

http://tools.ietf.org/html/draft-ietf-ra dext-dtls-00.txt

\n
\n\n

\n\ n

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR -- 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: