From owner-radiusext@ops.ietf.org Wed May 6 07:46:44 2009 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 4F8A53A6A34 for ; Wed, 6 May 2009 07:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K01hfqioHxG for ; Wed, 6 May 2009 07:46:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6FB7A3A6EBE for ; Wed, 6 May 2009 07:45:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M1iGB-000IRn-3Y for radiusext-data0@psg.com; Wed, 06 May 2009 14:38:11 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M1iFy-000IQV-MF for radiusext@ops.ietf.org; Wed, 06 May 2009 14:38:04 +0000 Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 3C6A012343A4; Wed, 6 May 2009 16:37:56 +0200 (CEST) Message-ID: <4A01A0C3.9010807@deployingradius.com> Date: Wed, 06 May 2009 16:37:55 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Phillip Hallam-Baker , 'radext mailing list' CC: secdir@ietf.org, gdweber@gmail.com Subject: Re: Review of draft-ietf-radext-design-07 References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Phillip Hallam-Baker wrote: > As always with Radius documents it is somewhat hard to do a security > review of a security protocol that admits that the protocol does not > offer security. I agree. However... we are working with a legacy protocol here. > While the security is provided through layering on another protocol > (e.g. IPSEC), the mix and match approach is unsatisfactory. Security > is a property of a system. It is really not possible to analyze the > security of a system when one half of the system is unspecified. While it is not part of this document, the WG is working on RADIUS over TLS / DTLS. These specifications should improve the security of the protocol. > The Security Considerations section is adequate and given the purpose > of this draft it is appropriate to cite external documents where the > security issues are discussed in detail rather than repeat the caveats > here. But the question does have to be asked why we have so many > security caveats in what is a foundational security protocol. Historical practice, and the cost of upgrade. When the new TLS-based documents are approved, we expect that they will be the preferred approach for RADIUS transport. > While IPSEC security is certainly adequate for some applications, I > have a really hard time accepting it as the security layer for a > foundational security protocol. I prefer basic authentication and > authorization protocols to have security built in. In particular I > want to know what happens at the RADIUS protocol level when there is > an error at the IPSEC layer or vice versa. IPSEC is not secure against > active attack unless error conditions are appropriately handled. I agree. However, it's outside of the scope of this document. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed May 6 13:07:15 2009 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 ECFDB3A6ABC for ; Wed, 6 May 2009 13:07:15 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6nCRH-i0dbm for ; Wed, 6 May 2009 13:07:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 924C93A6A58 for ; Wed, 6 May 2009 13:07:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M1nKr-000DTT-4i for radiusext-data0@psg.com; Wed, 06 May 2009 20:03:21 +0000 Received: from bay0-omc1-s11.bay0.hotmail.com ([65.54.246.83]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M1nKc-000DSW-Am for radiusext@ops.ietf.org; Wed, 06 May 2009 20:03:12 +0000 Received: from hotmail.com ([10.4.31.16]) by bay0-omc1-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 13:03:05 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 6 May 2009 13:03:05 -0700 Message-ID: Received: from 131.107.0.82 by BLU137-DAV6.phx.gbl with DAV; Wed, 06 May 2009 20:03:03 +0000 X-Originating-IP: [131.107.0.82] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: Subject: Virtual interim meeting? Date: Wed, 6 May 2009 13:03:03 -0700 Message-ID: <006701c9ce85$a9c2add0$fd480970$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01C9CE4A.FD63D5D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnOhamXLC0my+1KTWSAnMsnHrcIyQ== Content-Language: en-us X-OriginalArrivalTime: 06 May 2009 20:03:05.0597 (UTC) FILETIME=[AB41FAD0:01C9CE85] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. ------=_NextPart_000_0068_01C9CE4A.FD63D5D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit A number of IETF WGs are now scheduling "virtual interim" meetings. For example, ECRIT scheduled such a meeting in the fall: http://trac.tools.ietf.org/wg/ecrit/trac/wiki We are wondering whether RADEXT WG participants would be interested in participating in such a "virtual interim" meeting, and if so, how many of you would potentially attend. Typical facilities provided through services such as DimDim include audio conferencing, chat and presentation sharing. ------=_NextPart_000_0068_01C9CE4A.FD63D5D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A number of IETF WGs are now scheduling = “virtual interim” meetings.   For example, ECRIT scheduled such a = meeting in the fall:

http://trac.tools.= ietf.org/wg/ecrit/trac/wiki

 

We are wondering whether RADEXT WG participants = would be interested in participating in such a “virtual interim” = meeting, and if so, how many of you would potentially attend.

 

Typical facilities provided through services such = as DimDim include audio conferencing, = chat and presentation sharing.

------=_NextPart_000_0068_01C9CE4A.FD63D5D0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu May 7 02:02:52 2009 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 8744A3A6F43 for ; Thu, 7 May 2009 02:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gChcoJDzhudp for ; Thu, 7 May 2009 02:02:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E054E3A6E16 for ; Thu, 7 May 2009 02:02:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M1zSD-0008LL-1v for radiusext-data0@psg.com; Thu, 07 May 2009 08:59:45 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M1zRq-0008Jl-Dj for radiusext@ops.ietf.org; Thu, 07 May 2009 08:59:28 +0000 Received: from Thor.local (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 0013C12343A4; Thu, 7 May 2009 10:59:20 +0200 (CEST) Message-ID: <4A02A2E9.7050600@deployingradius.com> Date: Thu, 07 May 2009 10:59:21 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Virtual interim meeting? References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > We are wondering whether RADEXT WG participants would be interested in > participating in such a “virtual interim” meeting, and if so, how many > of you would potentially attend. I would attend one, but I don't know what the topic would be. The main barrier now to WG progress is document review and editing. There are a number of documents that need review, and I haven't had time yet to review them. I always dislike meetings where documents are wordsmithed to death, but this might be useful here. i.e. Schedule a meeting where a document is reviewed in detail. If we can get 3-4 participants who are *not* co-authors, that should be sufficient to make WG progress. 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 Thu May 7 03:37:16 2009 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 6F6D33A6AC0 for ; Thu, 7 May 2009 03:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.456 X-Spam-Level: X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IILQIWZLXSVX for ; Thu, 7 May 2009 03:37:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D2B323A6C67 for ; Thu, 7 May 2009 03:37:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M20vd-000EUt-RJ for radiusext-data0@psg.com; Thu, 07 May 2009 10:34:13 +0000 Received: from [198.152.71.100] (helo=de307622-de-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M20vL-000ET3-U7 for radiusext@ops.ietf.org; Thu, 07 May 2009 10:34:07 +0000 X-IronPort-AV: E=Sophos;i="4.40,309,1238990400"; d="scan'208,217";a="145135402" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 May 2009 06:33:45 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 May 2009 06:33:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CEFF.49ECF84F" Subject: RE: Virtual interim meeting? Date: Thu, 7 May 2009 12:33:40 +0200 Message-ID: In-Reply-To: <006701c9ce85$a9c2add0$fd480970$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Virtual interim meeting? Thread-Index: AcnOhamXLC0my+1KTWSAnMsnHrcIyQAeYRHA References: <006701c9ce85$a9c2add0$fd480970$@com> From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CEFF.49ECF84F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would attend.=20 =20 Dan =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Wednesday, May 06, 2009 11:03 PM To: radiusext@ops.ietf.org Subject: Virtual interim meeting? =09 =09 A number of IETF WGs are now scheduling "virtual interim" meetings. For example, ECRIT scheduled such a meeting in the fall: http://trac.tools.ietf.org/wg/ecrit/trac/wiki =20 We are wondering whether RADEXT WG participants would be interested in participating in such a "virtual interim" meeting, and if so, how many of you would potentially attend.=20 =20 Typical facilities provided through services such as DimDim include audio conferencing, chat and presentation sharing.=20 ------_=_NextPart_001_01C9CEFF.49ECF84F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 would attend.
 
Dan
 

From: owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Wednesday, May 06, 2009 11:03 PM
To:=20 radiusext@ops.ietf.org
Subject: Virtual interim=20 meeting?

A number of IETF WGs are now scheduling = “virtual interim”=20 meetings.   For example, ECRIT scheduled such a meeting in = the=20 fall:

http://trac.tools.= ietf.org/wg/ecrit/trac/wiki

 

We are wondering whether RADEXT WG participants = would be=20 interested in participating in such a “virtual interim” = meeting, and if so,=20 how many of you would potentially attend.

 

Typical facilities provided through services such = as DimDim include audio conferencing, = chat and=20 presentation sharing.

------_=_NextPart_001_01C9CEFF.49ECF84F-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu May 7 08:27:03 2009 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 75F423A6A79 for ; Thu, 7 May 2009 08:27:03 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lebkODJi8szS for ; Thu, 7 May 2009 08:26:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A94E3A6924 for ; Thu, 7 May 2009 08:26:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M25Rk-000Ady-6O for radiusext-data0@psg.com; Thu, 07 May 2009 15:23:40 +0000 Received: from bay0-omc3-s9.bay0.hotmail.com ([65.54.246.209]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M25RV-000Acg-G5 for radiusext@ops.ietf.org; Thu, 07 May 2009 15:23:32 +0000 Received: from hotmail.com ([10.4.31.11]) by bay0-omc3-s9.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 08:23:25 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 7 May 2009 08:23:25 -0700 Message-ID: Received: from 24.16.117.112 by BLU137-DAV1.phx.gbl with DAV; Thu, 07 May 2009 15:23:20 +0000 X-Originating-IP: [24.16.117.112] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: Subject: FW: DISCUSS and COMMENT: draft-ietf-radext-design Date: Thu, 7 May 2009 08:23:28 -0700 Message-ID: <001b01c9cf27$c59c0360$50d40a20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnPHYNDgKmQCJOwQ7WUOwpXFaMDxAACjhpg Content-Language: en-us X-OriginalArrivalTime: 07 May 2009 15:23:25.0139 (UTC) FILETIME=[C3BD0A30:01C9CF27] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Thursday, May 07, 2009 7:08 AM To: iesg@ietf.org Cc: radext-chairs@tools.ietf.org; = draft-ietf-radext-design@tools.ietf.org; gdweber@gmail.com; = aland@freeradius.org Subject: DISCUSS and COMMENT: draft-ietf-radext-design=20 Discuss: Great doc! I will vote Yes on it, but I wanted to discuss two issues first, one is a Discuss-level problem and the other one a Comment that I'd like you to consider. The first issue is that Section 2.3 suggests 16-bit vendor space attribute number fields to replace the existing 8-bit recommendation. There are a couple of problems with this. First, if you really mean to change the recommendation, then Updates: RFC 2865 header in the beginning of the document would have been appropriate. Secondly, while I agree with the advice of going for 16 bits, the document is silent on some of the issues involved in such a change, such as: - Does RADIUS dictionary software support the VSA format for 16 bits, 8 bits, or both? - How do you cleanly print or report VSAs when you do not know if the field size is 8 or 16 bits? I realize that this situation already exists since the format was never required to be followed, but your new recommendation makes a potential problem much more likely to appear. Previously, you could print something like Vendor =3D ACME, Code =3D 17, Contents =3D ABCDEF0011... Now you couldn't do that. - Can a vendor who moved from 8 bits to 16 bits deal with this? Comment: I do agree that for functionality FOO, both the functionality itself and the MIB, RADIUS, etc. work should take place in the same standards body. However, Section 3.1 could have said a couple of additional things as well: The issues of attribute space and choice of forum are distinct; there is no reason why IETF couldn't use its own vendor code, for instance. The section also does not mention one of the potential drawbacks of SDO-driven development model: it is easy to come up with a number of different solutions to the same generic problem, as opposed to finding a common solution. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu May 7 08:33:39 2009 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 947EC3A6C49 for ; Thu, 7 May 2009 08:33:39 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNba18leFpdx for ; Thu, 7 May 2009 08:33:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC46A3A705E for ; Thu, 7 May 2009 08:33:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M25YL-000B5O-Bv for radiusext-data0@psg.com; Thu, 07 May 2009 15:30:29 +0000 Received: from bay0-omc1-s37.bay0.hotmail.com ([65.54.246.109]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M25Y7-000B4f-ND for radiusext@ops.ietf.org; Thu, 07 May 2009 15:30:22 +0000 Received: from hotmail.com ([10.4.31.18]) by bay0-omc1-s37.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 08:30:15 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 7 May 2009 08:30:15 -0700 Message-ID: Received: from 24.16.117.112 by BLU137-DAV8.phx.gbl with DAV; Thu, 07 May 2009 15:30:11 +0000 X-Originating-IP: [24.16.117.112] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: "'Alan DeKok'" Cc: References: <4A02A2E9.7050600@deployingradius.com> In-Reply-To: <4A02A2E9.7050600@deployingradius.com> Subject: RE: Virtual interim meeting? Date: Thu, 7 May 2009 08:30:20 -0700 Message-ID: <002201c9cf28$bb063f00$3112bd00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnO8t16ZNUKrmACS3S+gc2QUDJHmgANSW5g Content-Language: en-us X-OriginalArrivalTime: 07 May 2009 15:30:15.0084 (UTC) FILETIME=[B815AEC0:01C9CF28] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok wrote: " I would attend one, but I don't know what the topic would be. The main barrier now to WG progress is document review and editing. There are a number of documents that need review, and I haven't had time yet to review them. I always dislike meetings where documents are wordsmithed to death, but this might be useful here. i.e. Schedule a meeting where a document is reviewed in detail. If we can get 3-4 participants who are *not* co-authors, that should be sufficient to make WG progress." Typically an interim meeting will have a narrower focus, so that = detailed review of one or more documents would be a possibility.=20 The question is what documents it would be useful to review in depth.=20 The first ones that come to mind are WG work items with the longest = "seniority", such as crypto-agility and extended attributes. Both have been around a = while,=20 have been through WG last call, but have issues remaining.=20 Suggestions welcome.=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 Thu May 7 08:35:08 2009 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 CBA7D3A6E3E for ; Thu, 7 May 2009 08:35:08 -0700 (PDT) X-Quarantine-ID: <9GSykmdorFFp> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GSykmdorFFp for ; Thu, 7 May 2009 08:35:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E8A1C3A6A90 for ; Thu, 7 May 2009 08:35:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M25am-000BEo-1s for radiusext-data0@psg.com; Thu, 07 May 2009 15:33:00 +0000 Received: from bay0-omc2-s28.bay0.hotmail.com ([65.54.246.164]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M25aI-000BCm-Pt for radiusext@ops.ietf.org; Thu, 07 May 2009 15:32:52 +0000 Received: from hotmail.com ([10.4.31.20]) by bay0-omc2-s28.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 08:32:30 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 7 May 2009 08:32:30 -0700 Message-ID: Received: from 24.16.117.112 by BLU137-DAV10.phx.gbl with DAV; Thu, 07 May 2009 15:32:25 +0000 X-Originating-IP: [24.16.117.112] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: References: <4A02A2E9.7050600@deployingradius.com> In-Reply-To: <4A02A2E9.7050600@deployingradius.com> Subject: Virtual meeting technology Date: Thu, 7 May 2009 08:32:32 -0700 Message-ID: <002301c9cf29$0a43bcf0$1ecb36d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnO8t16ZNUKrmACS3S+gc2QUDJHmgANeCNA Content-Language: en-us X-OriginalArrivalTime: 07 May 2009 15:32:30.0251 (UTC) FILETIME=[08A687B0:01C9CF29] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: In terms of virtual meeting technology, there are a number of services = that provide free conferencing support.=20 One that I've looked at is DimDim ( http://www.dimdim.com/ ), which is = free for conferences of 20 users or less.=20 Has anyone used this (or any other) equivalent service? Any = recommendations?=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 Thu May 7 08:50:56 2009 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 78EE53A70FA for ; Thu, 7 May 2009 08:50:56 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 vRDOfogDpEkC for ; Thu, 7 May 2009 08:50:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B1A03A711F for ; Thu, 7 May 2009 08:50:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M25od-000CJt-HI for radiusext-data0@psg.com; Thu, 07 May 2009 15:47:19 +0000 Received: from bay0-omc2-s15.bay0.hotmail.com ([65.54.246.151]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M25oP-000CIJ-BQ for radiusext@ops.ietf.org; Thu, 07 May 2009 15:47:12 +0000 Received: from hotmail.com ([10.4.31.19]) by bay0-omc2-s15.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 08:47:04 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 7 May 2009 08:47:05 -0700 Message-ID: Received: from 24.16.117.112 by BLU137-DAV9.phx.gbl with DAV; Thu, 07 May 2009 15:47:01 +0000 X-Originating-IP: [24.16.117.112] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: "'Bernard Aboba'" , References: In-Reply-To: Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Thu, 7 May 2009 08:47:09 -0700 Message-ID: <002501c9cf2b$14c61900$3e524b00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnPHYNDgKmQCJOwQ7WUOwpXFaMDxAACjhpgAAB6qfA= Content-Language: en-us X-OriginalArrivalTime: 07 May 2009 15:47:05.0127 (UTC) FILETIME=[121E0370:01C9CF2B] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Here is the normative language in Section 2.3: In order to be compatible with the above recommendations for attribute definitions, it is RECOMMENDED that RADIUS servers support attributes using a 16-bit Vendor type field. IMHO, this doesn't suggest replacing 8-bit with 16-bit vendor type = fields, only that RADIUS servers should support 16-bit as well.=20 Earlier text discusses the situations in which 16-bit vendor type fields = are needed: Note that the Vendor type field in the recommended VSA format is only a single octet, like the RADIUS type field. While this limitation results in an efficient encoding, there are situations in which a vendor or SDO will eventually wish to define more than 255 attributes. Also, an SDO can be comprised of multiple subgroups, each of whom can desire autonomy over the definition of attributes within their group. In such a situation, a 16-bit Vendor type field would be more appropriate... -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Thursday, May 07, 2009 7:08 AM To: iesg@ietf.org Cc: radext-chairs@tools.ietf.org; = draft-ietf-radext-design@tools.ietf.org; gdweber@gmail.com; = aland@freeradius.org Subject: DISCUSS and COMMENT: draft-ietf-radext-design=20 Discuss: Great doc! I will vote Yes on it, but I wanted to discuss two issues first, one is a Discuss-level problem and the other one a Comment that I'd like you to consider. The first issue is that Section 2.3 suggests 16-bit vendor space attribute number fields to replace the existing 8-bit recommendation. There are a couple of problems with this. First, if you really mean to change the recommendation, then Updates: RFC 2865 header in the beginning of the document would have been appropriate. Secondly, while I agree with the advice of going for 16 bits, the document is silent on some of the issues involved in such a change, such as: - Does RADIUS dictionary software support the VSA format for 16 bits, 8 bits, or both? - How do you cleanly print or report VSAs when you do not know if the field size is 8 or 16 bits? I realize that this situation already exists since the format was never required to be followed, but your new recommendation makes a potential problem much more likely to appear. Previously, you could print something like Vendor =3D ACME, Code =3D 17, Contents =3D ABCDEF0011... Now you couldn't do that. - Can a vendor who moved from 8 bits to 16 bits deal with this? Comment: I do agree that for functionality FOO, both the functionality itself and the MIB, RADIUS, etc. work should take place in the same standards body. However, Section 3.1 could have said a couple of additional things as well: The issues of attribute space and choice of forum are distinct; there is no reason why IETF couldn't use its own vendor code, for instance. The section also does not mention one of the potential drawbacks of SDO-driven development model: it is easy to come up with a number of different solutions to the same generic problem, as opposed to finding a common solution. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu May 7 10:07:34 2009 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 9290D3A70EE for ; Thu, 7 May 2009 10:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M3g5WyYOHHT for ; Thu, 7 May 2009 10:07:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0F2E03A703D for ; Thu, 7 May 2009 10:07:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M26yn-000Ifb-2C for radiusext-data0@psg.com; Thu, 07 May 2009 17:01:53 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M26yZ-000Ie6-Hx for radiusext@ops.ietf.org; Thu, 07 May 2009 17:01:46 +0000 Received: (qmail 23437 invoked from network); 7 May 2009 13:01:37 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 7 May 2009 13:01:37 -0400 From: "David B. Nelson" To: References: <4A02A2E9.7050600@deployingradius.com> Subject: RE: Virtual interim meeting? Date: Thu, 7 May 2009 13:01:36 -0400 Organization: Elbrys Networks, Inc. Message-ID: <73BE91277C2D49978A200A9A68EA5748@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnO8t16ZNUKrmACS3S+gc2QUDJHmgANSW5gAAMt0CA= Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba writes... > The first ones that come to mind are WG work items with the > longest "seniority", such as crypto-agility and extended > attributes. Both have been around a while, have been through > WG last call, but have issues remaining. I think an "IEEE-style" virtual interim meeting, in which we focus on creating document editing instructions, that is to say hammering out text, would be a useful and effective "forcing function" to get some of these items ready for IESG submission. It addresses the syndrome of not doing much work on drafts except in the two weeks before an IETF meeting. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu May 7 10:33:29 2009 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 A84053A6F1D for ; Thu, 7 May 2009 10:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=-0.792, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8z0Hxdo40Ml for ; Thu, 7 May 2009 10:33:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CC61F3A6CB1 for ; Thu, 7 May 2009 10:33:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M27ES-000JvW-MO for radiusext-data0@psg.com; Thu, 07 May 2009 17:18:04 +0000 Received: from [213.165.64.20] (helo=mail.gmx.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M27Dz-000JtV-2w for radiusext@ops.ietf.org; Thu, 07 May 2009 17:17:58 +0000 Received: (qmail invoked by alias); 07 May 2009 17:17:33 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp036) with SMTP; 07 May 2009 19:17:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18PYFMVMPEPUNwWpiXWWpENsjG5Ewh3WIHtKBHZzY dmUJlY4yzXY/fI From: "Hannes Tschofenig" To: "'Bernard Aboba'" , References: <4A02A2E9.7050600@deployingradius.com> Subject: RE: Virtual meeting technology Date: Thu, 7 May 2009 20:19:12 +0300 Message-ID: <032601c9cf37$f10aaf50$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnO8t16ZNUKrmACS3S+gc2QUDJHmgANeCNAAAOV6ZA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: The IPSECME group is using an open source tool from the gaming community, see http://www.teamspeak.com/. I like it when folks join the conference bridge and the server announces "Player has joined". It does not provide slide sharing but that's OK. It does not allow folks to dial in via PSTN either... Paul has downloaded the server software and installed it on his server. Maybe you can re-use it. Ciao Hannes >-----Original Message----- >From: owner-radiusext@ops.ietf.org >[mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba >Sent: 07 May, 2009 18:33 >To: radiusext@ops.ietf.org >Subject: Virtual meeting technology > >In terms of virtual meeting technology, there are a number of >services that provide free conferencing support. > >One that I've looked at is DimDim ( http://www.dimdim.com/ ), >which is free for conferences of 20 users or less. > >Has anyone used this (or any other) equivalent service? Any >recommendations? > > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu May 7 10:46:49 2009 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 566F23A70BA for ; Thu, 7 May 2009 10:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXBSJFy0c6DK for ; Thu, 7 May 2009 10:46:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D0E4F28C2CA for ; Thu, 7 May 2009 10:45:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M27YF-000MBp-L7 for radiusext-data0@psg.com; Thu, 07 May 2009 17:38:31 +0000 Received: from blu0-omc1-s36.blu0.hotmail.com ([65.55.116.47]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M27Xc-000M78-Hz for radiusext@ops.ietf.org; Thu, 07 May 2009 17:38:08 +0000 Received: from BLU137-W8 ([65.55.116.9]) by blu0-omc1-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 10:37:52 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d61896ba-44d4-4902-9768-1e0742820d1f_" X-Originating-IP: [70.56.68.166] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RE: Virtual meeting technology Date: Thu, 7 May 2009 10:37:52 -0700 Importance: Normal In-Reply-To: <032601c9cf37$f10aaf50$0301a8c0@nsnintra.net> References: <4A02A2E9.7050600@deployingradius.com> <032601c9cf37$f10aaf50$0301a8c0@nsnintra.net> MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2009 17:37:52.0247 (UTC) FILETIME=[8C1C0870:01C9CF3A] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_d61896ba-44d4-4902-9768-1e0742820d1f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It looks like Teamspeak requires installation of client software=2C availab= le on Windows=2C MacOS X and Linux. How do people feel about that? In ex= change for the client software install requirement=2C the major advantage o= f Teamspeak (or SIP-based VOIP=2C for that matter) is the ability to bypass= the PSTN and associated charges.=20 For example=2C while Freeconference (http://www.freeconference.com/) offer= s free conference bridges=2C it does require the ability to reach the confe= rence call #=2C which could be an issue for people attending from outside t= he U.S. > From: Hannes.Tschofenig@gmx.net > To: Bernard_Aboba@hotmail.com=3B radiusext@ops.ietf.org > Subject: RE: Virtual meeting technology > Date: Thu=2C 7 May 2009 20:19:12 +0300 >=20 > The IPSECME group is using an open source tool from the gaming community= =2C > see http://www.teamspeak.com/.=20 >=20 > I like it when folks join the conference bridge and the server announces > "Player has joined".=20 >=20 > It does not provide slide sharing but that's OK. It does not allow folks = to > dial in via PSTN either... >=20 > Paul has downloaded the server software and installed it on his server. > Maybe you can re-use it.=20 >=20 > Ciao > Hannes >=20 > >-----Original Message----- > >From: owner-radiusext@ops.ietf.org=20 > >[mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > >Sent: 07 May=2C 2009 18:33 > >To: radiusext@ops.ietf.org > >Subject: Virtual meeting technology > > > >In terms of virtual meeting technology=2C there are a number of=20 > >services that provide free conferencing support.=20 > > > >One that I've looked at is DimDim ( http://www.dimdim.com/ )=2C=20 > >which is free for conferences of 20 users or less.=20 > > > >Has anyone used this (or any other) equivalent service? Any=20 > >recommendations?=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 --_d61896ba-44d4-4902-9768-1e0742820d1f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It looks like Teamspeak requires installation of client software=2C availab= le on Windows=2C MacOS X and Linux. =3B How do people feel about that?&= nbsp=3B =3B In exchange for the client software install requirement=2C = the major advantage of Teamspeak (or SIP-based VOIP=2C for that matter) is = the ability to bypass the PSTN and associated charges.

For example= =2C while Freeconference (http://www.freeconference.com/) =3B offers fr= ee conference bridges=2C it does require the ability to reach the conferenc= e call #=2C which could be an issue for people attending from outside the U= .S.





>=3B From: Hannes.Tschofenig@gmx.net>=3B To: Bernard_Aboba@hotmail.com=3B radiusext@ops.ietf.org
>=3B = Subject: RE: Virtual meeting technology
>=3B Date: Thu=2C 7 May 2009 2= 0:19:12 +0300
>=3B
>=3B The IPSECME group is using an open sourc= e tool from the gaming community=2C
>=3B see http://www.teamspeak.com= /.
>=3B
>=3B I like it when folks join the conference bridge an= d the server announces
>=3B "Player has joined".
>=3B
>=3B= It does not provide slide sharing but that's OK. It does not allow folks t= o
>=3B dial in via PSTN either...
>=3B
>=3B Paul has downlo= aded the server software and installed it on his server.
>=3B Maybe yo= u can re-use it.
>=3B
>=3B Ciao
>=3B Hannes
>=3B
= >=3B >=3B-----Original Message-----
>=3B >=3BFrom: owner-radiuse= xt@ops.ietf.org
>=3B >=3B[mailto:owner-radiusext@ops.ietf.org] On B= ehalf Of Bernard Aboba
>=3B >=3BSent: 07 May=2C 2009 18:33
>=3B= >=3BTo: radiusext@ops.ietf.org
>=3B >=3BSubject: Virtual meeting = technology
>=3B >=3B
>=3B >=3BIn terms of virtual meeting tec= hnology=2C there are a number of
>=3B >=3Bservices that provide fre= e conferencing support.
>=3B >=3B
>=3B >=3BOne that I've loo= ked at is DimDim ( http://www.dimdim.com/ )=2C
>=3B >=3Bwhich is f= ree for conferences of 20 users or less.
>=3B >=3B
>=3B >=3B= Has anyone used this (or any other) equivalent service? Any
>=3B >= =3Brecommendations?
>=3B >=3B
>=3B >=3B
>=3B >=3B-->=3B >=3Bto unsubscribe send a message to
>=3B >=3Bradiusext-= request@ops.ietf.org with the word 'unsubscribe' in
>=3B >=3Ba sing= le line as the message text body.
>=3B >=3Barchive: <=3Bhttp://psg= .com/lists/radiusext/>=3B
>=3B >=3B
>=3B
= --_d61896ba-44d4-4902-9768-1e0742820d1f_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu May 7 10:51:39 2009 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 BF4783A686A for ; Thu, 7 May 2009 10:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_05=-1.11] 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 uVI9af095WNn for ; Thu, 7 May 2009 10:51:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8998F28C31C for ; Thu, 7 May 2009 10:50:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M27iR-000NIB-Po for radiusext-data0@psg.com; Thu, 07 May 2009 17:49:03 +0000 Received: from blu0-omc2-s18.blu0.hotmail.com ([65.55.111.93]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M27iF-000NDv-1c for radiusext@ops.ietf.org; Thu, 07 May 2009 17:48:56 +0000 Received: from BLU137-W9 ([65.55.111.72]) by blu0-omc2-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 10:48:50 -0700 Message-ID: X-Originating-IP: [70.56.68.166] From: Bernard Aboba To: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: RE: Virtual interim meeting? Date: Thu, 7 May 2009 10:48:50 -0700 Importance: Normal In-Reply-To: <73BE91277C2D49978A200A9A68EA5748@xpsuperdvd2> References: <4A02A2E9.7050600@deployingradius.com> <73BE91277C2D49978A200A9A68EA5748@xpsuperdvd2> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2009 17:48:51.0005 (UTC) FILETIME=[14C286D0:01C9CF3C] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu May 7 10:59:23 2009 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 63F0D28C0FD for ; Thu, 7 May 2009 10:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lS7v5n3amBm for ; Thu, 7 May 2009 10:59:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4ACDA3A708E for ; Thu, 7 May 2009 10:59:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M27nm-000NeA-1j for radiusext-data0@psg.com; Thu, 07 May 2009 17:54:34 +0000 Received: from blu0-omc1-s3.blu0.hotmail.com ([65.55.116.14]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M27nV-000NdS-CA for radiusext@ops.ietf.org; Thu, 07 May 2009 17:54:26 +0000 Received: from BLU137-W11 ([65.55.116.9]) by blu0-omc1-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 10:54:17 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_994c2dae-769e-4f5e-8a8b-65677451b11d_" X-Originating-IP: [70.56.68.166] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Strawman Virtual Interim agenda (+ proposed time/date) Date: Thu, 7 May 2009 10:54:16 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2009 17:54:17.0317 (UTC) FILETIME=[D741C950:01C9CF3C] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_994c2dae-769e-4f5e-8a8b-65677451b11d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is a strawman proposal for the virtual interim agenda=2C plus a potent= ial time/date.=20 Comments welcome.=20 RADEXT WG Virtual Interim Agenda Chairs: Bernard Aboba David Nelson Wednesday=2C June 10=2C 2009 9 AM - 11 AM PDT 9:00 AM - 10:00 AM RADIUS Crypto-agility Requirements http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements 10:00 AM - 11:00 AM Extended RADIUS Attributes http://tools.ietf.org/html/draft-ietf-radext-extended-attributes --_994c2dae-769e-4f5e-8a8b-65677451b11d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is a strawman proposal for the virtual interim agenda=2C plus a potent= ial time/date.

Comments welcome.

RADEXT WG Virtual Interim = Agenda

Chairs: Bernard Aboba <=3Bbernard_aboba@hotmail.com>=3BDavid Nelson <=3Bd.b.nelson@comcast.net>=3B

Wednesday=2C June = 10=2C 2009
9 AM - 11 AM PDT

9:00 AM - 10:00 AM RADIUS Crypto-agil= ity Requirements
http://tools.ietf.org/html/draft-ietf-radext-crypto-agi= lity-requirements

10:00 AM - 11:00 AM Extended RADIUS Attributes
= http://tools.ietf.org/html/draft-ietf-radext-extended-attributes


= --_994c2dae-769e-4f5e-8a8b-65677451b11d_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu May 7 11:16:39 2009 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 C214F3A70C0 for ; Thu, 7 May 2009 11:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1yG-fpaipoc for ; Thu, 7 May 2009 11:16:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB40C3A70EA for ; Thu, 7 May 2009 11:16:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M284N-000POP-Uj for radiusext-data0@psg.com; Thu, 07 May 2009 18:11:43 +0000 Received: from blu0-omc2-s7.blu0.hotmail.com ([65.55.111.82]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M284A-000PJc-2o for radiusext@ops.ietf.org; Thu, 07 May 2009 18:11:36 +0000 Received: from BLU137-W28 ([65.55.111.72]) by blu0-omc2-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 May 2009 11:11:29 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_5989cd6c-9f0f-4d1a-9380-9d85b57b9448_" X-Originating-IP: [70.56.68.166] From: Bernard Aboba To: Jari Arkko , "iesg@ietf.org" CC: "radext-chairs@tools.ietf.org" , , , , "radiusext@ops.ietf.org" Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Thu, 7 May 2009 11:11:29 -0700 Importance: Normal In-Reply-To: <20090507140820.D19BB3A709C@core3.amsl.com> References: <20090507140820.D19BB3A709C@core3.amsl.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2009 18:11:29.0962 (UTC) FILETIME=[3EC2E8A0:01C9CF3F] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_5989cd6c-9f0f-4d1a-9380-9d85b57b9448_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for your comments.=20 Design Guidelines has a normative dependency on the Extended Attributes doc= ument=2C which currently uses a 16-bit vendor type field. Given that Exten= ded Attributes will require that RADIUS servers support a 16-bit vendor-typ= e field for IETF-defined extended attributes=2C it isn't much of a stretch = to recommend that RADIUS servers support a 16-bit type field for vendor and= SDO-specific attributes as well=2C since Extended Attributes is based on t= he VSA format.=20 The question is whether that recommendation belongs in this document=2C whi= ch is a BCP=2C or whether it should go into the Extended Attributes documen= t (Proposed Standard) instead=2C and just be referred to in Design Guidelin= es. Consolidating protocol changes into the Extended Attribute document mi= ght be cleaner=2C particularly since it is Extended Attributes that will pr= ovide much of the motivation for vendors to add 16-bit vendor type support. With respect to "replacement" of the 8-bit vendor-type field with a 16-bit = vendor type recommendation=2C my take on the text in 2.3 is that while it r= ecommends RADIUS server support for 16-bit vendor type fields=2C it doesn't= make a blanket recommendation that vendors adopt a 16-bit vendor type fiel= d in all situations=2C but rather points out situations in which use of a 1= 6-bit vendor type field would be appropriate: Note that the Vendor type field in the recommended VSA format is only a single octet=2C like the RADIUS type field. While this limitation results in an efficient encoding=2C there are situations in which a vendor or SDO will eventually wish to define more than 255 attributes. Also=2C an SDO can be comprised of multiple subgroups=2C each of whom can desire autonomy over the definition of attributes within their group. In such a situation=2C a 16-bit Vendor type field would be more appropriate: > From: jari.arkko@piuha.net > To: iesg@ietf.org > CC: radext-chairs@tools.ietf.org=3B draft-ietf-radext-design@tools.ietf.o= rg=3B gdweber@gmail.com=3B aland@freeradius.org > Date: Thu=2C 7 May 2009 07:08:20 -0700 > Subject: DISCUSS and COMMENT: draft-ietf-radext-design=20 >=20 > Discuss: > Great doc! I will vote Yes on it=2C but I wanted to discuss two issues > first=2C one is a Discuss-level problem and the other one a Comment that > I'd like you to consider. >=20 > The first issue is that Section 2.3 suggests 16-bit vendor space > attribute number fields to replace the existing 8-bit recommendation. >=20 > There are a couple of problems with this. First=2C if you really mean > to change the recommendation=2C then Updates: RFC 2865 header in the > beginning of the document would have been appropriate. >=20 > Secondly=2C while I agree with the advice of going for 16 bits=2C the > document is silent on some of the issues involved in such a change=2C > such as: >=20 > - Does RADIUS dictionary software support the VSA format for 16 bits=2C 8 > bits=2C or both? >=20 > - How do you cleanly print or report VSAs when you do not know if the > field size is 8 or 16 bits? I realize that this situation already > exists since the format was never required to be followed=2C but > your new recommendation makes a potential problem much more likely > to appear. Previously=2C you could print something like Vendor =3D ACME= =2C > Code =3D 17=2C Contents =3D ABCDEF0011... Now you couldn't do that. >=20 > - Can a vendor who moved from 8 bits to 16 bits deal with this? >=20 > Comment: > I do agree that for functionality FOO=2C both the functionality itself > and the MIB=2C RADIUS=2C etc. work should take place in the same standard= s > body. However=2C Section 3.1 could have said a couple of additional thing= s > as well: >=20 > The issues of attribute space and choice of forum are distinct=3B there > is no reason why IETF couldn't use its own vendor code=2C for instance. >=20 > The section also does not mention one of the potential drawbacks of > SDO-driven development model: it is easy to come up with a number of > different solutions to the same generic problem=2C as opposed to finding > a common solution. >=20 --_5989cd6c-9f0f-4d1a-9380-9d85b57b9448_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for your comments.

Design Guidelines has a normative depende= ncy on the Extended Attributes document=2C which currently uses a 16-bit ve= ndor type field. =3B Given that Extended Attributes will require that R= ADIUS servers support a 16-bit vendor-type field for IETF-defined extended = attributes=2C it isn't much of a stretch to recommend that RADIUS servers s= upport a 16-bit type field for vendor and SDO-specific attributes as well= =2C since Extended Attributes is based on the VSA format.

The quest= ion is whether that recommendation belongs in this document=2C which is a B= CP=2C or whether it should go into the Extended Attributes document (Propos= ed Standard) instead=2C and just be referred to in Design Guidelines. = =3B Consolidating protocol changes into the Extended Attribute document mig= ht be cleaner=2C particularly since it is Extended Attributes that will pro= vide much of the motivation for vendors to add 16-bit vendor type support.<= br>
With respect to "replacement" of the 8-bit vendor-type field with a = 16-bit vendor type recommendation=2C my take on the text in 2.3 is that whi= le it recommends RADIUS server support for 16-bit vendor type fields=2C it = doesn't make a blanket recommendation that vendors adopt a 16-bit vendor ty= pe field in all situations=2C but rather points out situations in which use= of a 16-bit vendor type field would be appropriate:
   Note that the Vendor type field in the recommended VSA format is onl=
y
   a single octet=2C like the RADIUS type field.  While this limitatio=
n
   results in an efficient encoding=2C there are situations in which a=

   vendor or SDO will eventually wish to define more than 255
   att=
ributes.  Also=2C an SDO can be comprised of multiple subgroups=2C
   ea=
ch of whom can desire autonomy over the definition of attributes
   with=
in their group.  In such a situation=2C a 16-bit Vendor type field
   wo=
uld be more appropriate:

=


>=3B From: jari.arkko@pi= uha.net
>=3B To: iesg@ietf.org
>=3B CC: radext-chairs@tools.ietf.= org=3B draft-ietf-radext-design@tools.ietf.org=3B gdweber@gmail.com=3B alan= d@freeradius.org
>=3B Date: Thu=2C 7 May 2009 07:08:20 -0700
>=3B= Subject: DISCUSS and COMMENT: draft-ietf-radext-design
>=3B
>= =3B Discuss:
>=3B Great doc! I will vote Yes on it=2C but I wanted to = discuss two issues
>=3B first=2C one is a Discuss-level problem and th= e other one a Comment that
>=3B I'd like you to consider.
>=3B >=3B The first issue is that Section 2.3 suggests 16-bit vendor space>=3B attribute number fields to replace the existing 8-bit recommendati= on.
>=3B
>=3B There are a couple of problems with this. First=2C= if you really mean
>=3B to change the recommendation=2C then Updates:= RFC 2865 header in the
>=3B beginning of the document would have been= appropriate.
>=3B
>=3B Secondly=2C while I agree with the advic= e of going for 16 bits=2C the
>=3B document is silent on some of the i= ssues involved in such a change=2C
>=3B such as:
>=3B
>=3B = - Does RADIUS dictionary software support the VSA format for 16 bits=2C 8>=3B bits=2C or both?
>=3B
>=3B - How do you cleanly print= or report VSAs when you do not know if the
>=3B field size is 8 or = 16 bits? I realize that this situation already
>=3B exists since the= format was never required to be followed=2C but
>=3B your new recom= mendation makes a potential problem much more likely
>=3B to appear.= Previously=2C you could print something like Vendor =3D ACME=2C
>=3B = Code =3D 17=2C Contents =3D ABCDEF0011... Now you couldn't do that.
&g= t=3B
>=3B - Can a vendor who moved from 8 bits to 16 bits deal with t= his?
>=3B
>=3B Comment:
>=3B I do agree that for functional= ity FOO=2C both the functionality itself
>=3B and the MIB=2C RADIUS=2C= etc. work should take place in the same standards
>=3B body. However= =2C Section 3.1 could have said a couple of additional things
>=3B as = well:
>=3B
>=3B The issues of attribute space and choice of foru= m are distinct=3B there
>=3B is no reason why IETF couldn't use its ow= n vendor code=2C for instance.
>=3B
>=3B The section also does n= ot mention one of the potential drawbacks of
>=3B SDO-driven developme= nt model: it is easy to come up with a number of
>=3B different soluti= ons to the same generic problem=2C as opposed to finding
>=3B a common= solution.
>=3B
= --_5989cd6c-9f0f-4d1a-9380-9d85b57b9448_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu May 7 11:58:53 2009 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 0DCFB3A7185 for ; Thu, 7 May 2009 11:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 ArjNOAv3frJQ for ; Thu, 7 May 2009 11:58:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9493B3A7181 for ; Thu, 7 May 2009 11:58:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M28kr-00032h-9Z for radiusext-data0@psg.com; Thu, 07 May 2009 18:55:37 +0000 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M28kc-00031V-Hf for radiusext@ops.ietf.org; Thu, 07 May 2009 18:55:29 +0000 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 87EA119871D; Thu, 7 May 2009 21:55:21 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 0BC7D198660; Thu, 7 May 2009 21:55:21 +0300 (EEST) Message-ID: <4A032E7B.50501@piuha.net> Date: Thu, 07 May 2009 21:54:51 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Bernard Aboba CC: "iesg@ietf.org" , "radext-chairs@tools.ietf.org" , draft-ietf-radext-design@tools.ietf.org, radiusextgdweber@gmail.com, aland@freeradius.org, "radiusext@ops.ietf.org" Subject: Re: DISCUSS and COMMENT: draft-ietf-radext-design References: <20090507140820.D19BB3A709C@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > Thanks for your comments. > > Design Guidelines has a normative dependency on the Extended > Attributes document, which currently uses a 16-bit vendor type field. > Given that Extended Attributes will require that RADIUS servers > support a 16-bit vendor-type field for IETF-defined extended > attributes, it isn't much of a stretch to recommend that RADIUS > servers support a 16-bit type field for vendor and SDO-specific > attributes as well, since Extended Attributes is based on the VSA format. > > The question is whether that recommendation belongs in this document, > which is a BCP, or whether it should go into the Extended Attributes > document (Proposed Standard) instead, and just be referred to in > Design Guidelines. Consolidating protocol changes into the Extended > Attribute document might be cleaner, particularly since it is Extended > Attributes that will provide much of the motivation for vendors to add > 16-bit vendor type support. Seems reasonable. > With respect to "replacement" of the 8-bit vendor-type field with a > 16-bit vendor type recommendation, my take on the text in 2.3 is that > while it recommends RADIUS server support for 16-bit vendor type > fields, it doesn't make a blanket recommendation that vendors adopt a > 16-bit vendor type field in all situations, but rather points out > situations in which use of a 16-bit vendor type field would be > appropriate: > Note that the Vendor type field in the recommended VSA format is only > a single octet, like the RADIUS type field. While this limitation > results in an efficient encoding, there are situations in which a > vendor or SDO will eventually wish to define more than 255 > attributes. Also, an SDO can be comprised of multiple subgroups, > each of whom can desire autonomy over the definition of attributes > within their group. In such a situation, a 16-bit Vendor type field > would be more appropriate: > Yeah. We talked about this on the call. I think it is reasonable to go to the 16 bit space, but I was only looking for guidance for, say, an SDO that has been using 8 bits before and now has to or wants to go 16 bits. Obviously this can be done, but requires care in how the allocations are done and what dictionaries say. Jari > > > > > > > From: jari.arkko@piuha.net > > To: iesg@ietf.org > > CC: radext-chairs@tools.ietf.org; > draft-ietf-radext-design@tools.ietf.org; gdweber@gmail.com; > aland@freeradius.org > > Date: Thu, 7 May 2009 07:08:20 -0700 > > Subject: DISCUSS and COMMENT: draft-ietf-radext-design > > > > Discuss: > > Great doc! I will vote Yes on it, but I wanted to discuss two issues > > first, one is a Discuss-level problem and the other one a Comment that > > I'd like you to consider. > > > > The first issue is that Section 2.3 suggests 16-bit vendor space > > attribute number fields to replace the existing 8-bit recommendation. > > > > There are a couple of problems with this. First, if you really mean > > to change the recommendation, then Updates: RFC 2865 header in the > > beginning of the document would have been appropriate. > > > > Secondly, while I agree with the advice of going for 16 bits, the > > document is silent on some of the issues involved in such a change, > > such as: > > > > - Does RADIUS dictionary software support the VSA format for 16 bits, 8 > > bits, or both? > > > > - How do you cleanly print or report VSAs when you do not know if the > > field size is 8 or 16 bits? I realize that this situation already > > exists since the format was never required to be followed, but > > your new recommendation makes a potential problem much more likely > > to appear. Previously, you could print something like Vendor = ACME, > > Code = 17, Contents = ABCDEF0011... Now you couldn't do that. > > > > - Can a vendor who moved from 8 bits to 16 bits deal with this? > > > > Comment: > > I do agree that for functionality FOO, both the functionality itself > > and the MIB, RADIUS, etc. work should take place in the same standards > > body. However, Section 3.1 could have said a couple of additional things > > as well: > > > > The issues of attribute space and choice of forum are distinct; there > > is no reason why IETF couldn't use its own vendor code, for instance. > > > > The section also does not mention one of the potential drawbacks of > > SDO-driven development model: it is easy to come up with a number of > > different solutions to the same generic problem, as opposed to finding > > a common solution. > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu May 7 15:47:08 2009 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 199353A6A56 for ; Thu, 7 May 2009 15:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UByxHkZcAkNu for ; Thu, 7 May 2009 15:47:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 59B693A67E5 for ; Thu, 7 May 2009 15:47:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2CJq-000Jcc-F2 for radiusext-data0@psg.com; Thu, 07 May 2009 22:43:58 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2CJZ-000Jar-En for radiusext@ops.ietf.org; Thu, 07 May 2009 22:43:52 +0000 Received: (qmail 31585 invoked from network); 7 May 2009 18:43:37 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 7 May 2009 18:43:37 -0400 From: "David B. Nelson" To: References: Subject: RE: Strawman Virtual Interim agenda (+ proposed time/date) Date: Thu, 7 May 2009 18:43:37 -0400 Organization: Elbrys Networks, Inc. Message-ID: <773509A43B2745CC9419D23961D493E4@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnPPa2lg3vnAYjOQAWRgVkDLM5fxwAJkY8g In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > Here is a strawman proposal for the virtual interim > agenda, plus a potential time/date. The agenda seems fine to me. The date and time works for me, too. -- 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 May 8 05:52:53 2009 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 DB9EC3A6C25 for ; Fri, 8 May 2009 05:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.086 X-Spam-Level: X-Spam-Status: No, score=-1.086 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB-R1wZW02dP for ; Fri, 8 May 2009 05:52:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A27273A714F for ; Fri, 8 May 2009 05:52:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2PVp-000OtU-4X for radiusext-data0@psg.com; Fri, 08 May 2009 12:49:13 +0000 Received: from [76.96.62.64] (helo=QMTA07.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2PVd-000OsG-5j for radiusext@ops.ietf.org; Fri, 08 May 2009 12:49:07 +0000 Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA07.westchester.pa.mail.comcast.net with comcast id oyUb1b0011HzFnQ570omaC; Fri, 08 May 2009 12:48:46 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA14.westchester.pa.mail.comcast.net with comcast id p0p01b00E4H2mdz3a0p0eg; Fri, 08 May 2009 12:49:01 +0000 From: "Dave Nelson" To: , "'Jari Arkko'" Cc: , , , , "'radext mailing list'" References: <20090507140820.D19BB3A709C@core3.amsl.com> <4A041C6F.5010900@freeradius.org> Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Fri, 8 May 2009 08:49:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <4A041C6F.5010900@freeradius.org> Thread-Index: AcnP0ytnu1X/ZnesRgOe9OZzw1urcgAB+R0g Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > > There are a couple of problems with this. First, if you really mean > > to change the recommendation, then Updates: RFC 2865 header in the > > beginning of the document would have been appropriate. > > We could add that, but I don't think it's critical. Hmmm. I have doubts about a BCP updating a Draft Standard. -- 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 May 8 06:11:40 2009 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 AD4ED3A7151 for ; Fri, 8 May 2009 06:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 5SNKJQ8kajdV for ; Fri, 8 May 2009 06:11:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E3A1F3A716A for ; Fri, 8 May 2009 06:11:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2Pn1-0000ih-BP for radiusext-data0@psg.com; Fri, 08 May 2009 13:06:59 +0000 Received: from [2001:14b8:400::130] (helo=smtp.piuha.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2Pmo-0000hY-80 for radiusext@ops.ietf.org; Fri, 08 May 2009 13:06:52 +0000 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 4FD2019877B; Fri, 8 May 2009 16:06:45 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 11EBA198660; Fri, 8 May 2009 16:06:45 +0300 (EEST) Message-ID: <4A042E47.6000809@piuha.net> Date: Fri, 08 May 2009 16:06:15 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: aland@freeradius.org CC: gdweber@gmail.com, draft-ietf-radext-design@tools.ietf.org, iesg@ietf.org, radext-chairs@tools.ietf.org, 'radext mailing list' Subject: Re: DISCUSS and COMMENT: draft-ietf-radext-design References: <20090507140820.D19BB3A709C@core3.amsl.com> <4A041C6F.5010900@freeradius.org> In-Reply-To: <4A041C6F.5010900@freeradius.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan, >> The first issue is that Section 2.3 suggests 16-bit vendor space >> attribute number fields to replace the existing 8-bit recommendation. >> > > In *addition* to 8-bit spaces. Not to replace it. > Well... there was a previous SHOULD recommendation. Now there is a new one (use the old the new). >> There are a couple of problems with this. First, if you really mean >> to change the recommendation, then Updates: RFC 2865 header in the >> beginning of the document would have been appropriate. >> > > We could add that, but I don't think it's critical. > Not very, but I think if we change an earlier requirement it would be helpful to add the Updates pointer so that people who review older RFCs are more likely to remember to check the new one, too. >> Secondly, while I agree with the advice of going for 16 bits, the >> document is silent on some of the issues involved in such a change, >> such as: >> >> - Does RADIUS dictionary software support the VSA format for 16 bits, 8 >> bits, or both? >> > > All major products already support many non-RFC VSA formats, including > 16 bits. > This is very good! Can you say something along these lines in the document, too, because it goes a long way towards resolving any issues the change has. >> - How do you cleanly print or report VSAs when you do not know if the >> field size is 8 or 16 bits? I realize that this situation already >> exists since the format was never required to be followed, but >> your new recommendation makes a potential problem much more likely >> to appear. Previously, you could print something like Vendor = ACME, >> Code = 17, Contents = ABCDEF0011... Now you couldn't do that. >> > > The *current* implementations have the same problem. If they receive > a VSA from an unknown vendor, and it's not in the RFC format, they have > *no* idea what format to use. > Are you saying that no implementation is capable of by default printing out text like I had in my example above? >> - Can a vendor who moved from 8 bits to 16 bits deal with this? >> > > Vendors cannot create VSAs of both 8 and 16 bits with the same > Vendor-Id. Some have tried, and have quickly fixed their product when > *everyone* complained. > > If vendors want to "switch" to using 16-bit types, they need to use a > new vendor-id. > Ok. I didn't think that was the case but clearly you have the operational experience on this. I think it would be essential to spell this out in the draft -- its important information! Jari -- 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 May 8 06:27:05 2009 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 6FEDC28C1B2 for ; Fri, 8 May 2009 06:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.083 X-Spam-Level: X-Spam-Status: No, score=-1.083 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaF3ra74LdAT for ; Fri, 8 May 2009 06:26:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 88AA228C194 for ; Fri, 8 May 2009 06:26:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2Q3y-0002iG-C4 for radiusext-data0@psg.com; Fri, 08 May 2009 13:24:30 +0000 Received: from [76.96.59.211] (helo=QMTA11.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2Q3m-0002hP-Pr for radiusext@ops.ietf.org; Fri, 08 May 2009 13:24:24 +0000 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA11.westchester.pa.mail.comcast.net with comcast id p0jq1b00p1GhbT85B1QJpc; Fri, 08 May 2009 13:24:18 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA07.westchester.pa.mail.comcast.net with comcast id p1QH1b0034H2mdz3T1QHyt; Fri, 08 May 2009 13:24:18 +0000 From: "Dave Nelson" To: "'Jari Arkko'" , Cc: , , , , "'radext mailing list'" References: <20090507140820.D19BB3A709C@core3.amsl.com> <4A041C6F.5010900@freeradius.org> <4A042E47.6000809@piuha.net> Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Fri, 8 May 2009 09:24:37 -0400 Message-ID: <6E09E7F7D0B440DBB676FD1C8EA60852@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <4A042E47.6000809@piuha.net> Thread-Index: AcnP3dxyT6MRSao2QEaqQ80ufMfOSwAATGOw Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > > Vendors cannot create VSAs of both 8 and 16 bits with the same > > Vendor-Id. Some have tried, and have quickly fixed their product when > > *everyone* complained. > > > > If vendors want to "switch" to using 16-bit types, they need to use a > > new vendor-id. > > > > Ok. I didn't think that was the case but clearly you have the > operational experience on this. > > I think it would be essential to spell this out in the draft -- its > important information! Quite frankly, this line of reasoning disturbs me. It's well known that there have been all sorts of non-standard behaviors (and a few ugly hacks) implemented in RADIUS clients and servers over the years. Dave Mitton documented some of these in RFC 2882. This document is a BCP. That means it should document the *best* current practices and not the more dubious ones. Not all hacks are created equal. This document should aim to bring order out of chaos. I think it would be fine if the Extended Attributes have 16-bit IDs and the traditional RFC 2865 format VSAs kept their 8-bit IDs. Anything else, e.g. non-standard VSA formats, is simply "off the reservation" and outside the scope of this document. -- 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 May 8 14:26:40 2009 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 8564E3A6CDC for ; Fri, 8 May 2009 14:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.621 X-Spam-Level: * X-Spam-Status: No, score=1.621 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFrAnclZfK80 for ; Fri, 8 May 2009 14:26:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A86FA3A6E2F for ; Fri, 8 May 2009 14:26:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2XX7-000Chd-Jx for radiusext-data0@psg.com; Fri, 08 May 2009 21:23:05 +0000 Received: from [129.41.63.69] (helo=out001.atlarge.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2XWY-000CfE-Qf for radiusext@ops.ietf.org; Fri, 08 May 2009 21:22:59 +0000 Received: from CHI1SIMR001.atlarge.net ([10.100.60.26]) by out001.atlarge.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 May 2009 16:16:40 -0500 Received: from ([10.100.70.9]) by CHI1SIMR001.atlarge.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 May 2009 16:12:04 -0500 Message-ID: <15946675.51561241817459900.JavaMail.javamailuser@localhost> Date: Fri, 8 May 2009 17:17:39 -0400 (EDT) From: Dimdim Invitations Reply-To: bernard_aboba@hotmail.com To: radiusext@ops.ietf.org Subject: RADEXT has invited you to a Dimdim Web Meeting MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 May 2009 21:12:04.0406 (UTC) FILETIME=[A3019D60:01C9D021] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Dimdim Web Meeting Invitation
 

Hello!
 
Your friend, RADEXT, has invited you to a Dimdim Web Meeting for
June 10, 2009 09:00:AM PDT. To join the web meeting simply click here

You can also join the meeting by entering the meeting ID aboba at Dimdim.com at the time of the meeting.
Join Meeting
You can also join by entering aboba at www.dimdim.com/join
  Meeting : RADEXT
 Key:
  Dial In: 712-432-6139 Pass Code: 226220
  Start: June 10, 2009 09:00:AM PDT (Add to Outlook)
  Schedule Ends At: Not Applicable
  This meeting happens only once
  Meeting Agenda: http://www.drizzle.com/~aboba/RADEXT/jun-virtual-interim.txt


Hint: You don't need to be a member of Dimdim to attend this meeting. It's easy to join and get started, Click here to sign up for Dimdim Free.
But you may find it helpful to check your bandwidth and your A/V setup here.

This is a personal meeting invitation, please do not forward.

Sincerely,
Your Dimdim Team
 
*If the link above is broken (as can happen with some email systems) simply copy and paste the following URL into your browser address bar: http://webmeeting.dimdim.com/portal/JoinForm.action?confKey=aboba&email=radiusext@ops.ietf.org&asPresenter=false&meetingId=4036f7f7-d7b1-4467-8b91-f4c15b8c7c78&attendeePwd=
Note: Some email clients will split the above link into multiple lines.
          Please make sure you copy the entire link (all lines) to join your meeting.

Copyright © 2009 Dimdim. Meet freely.
All Rights Reserved / Privacy Policy
-- 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 May 8 15:11:38 2009 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 E0B583A6B55 for ; Fri, 8 May 2009 15:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAAKJX7FpycK for ; Fri, 8 May 2009 15:11:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 72FF53A6C8C for ; Fri, 8 May 2009 15:11:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2YEt-000F21-LR for radiusext-data0@psg.com; Fri, 08 May 2009 22:08:19 +0000 Received: from blu0-omc1-s35.blu0.hotmail.com ([65.55.116.46]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2YEg-000F1I-JH for radiusext@ops.ietf.org; Fri, 08 May 2009 22:08:13 +0000 Received: from BLU137-W26 ([65.55.116.9]) by blu0-omc1-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 May 2009 15:08:06 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_8e67d668-3faf-4aeb-82c7-ca769fe0f017_" X-Originating-IP: [131.107.0.112] From: Bernard Aboba To: Subject: RADEXT WG Interim Virtual Meeting June 10, 2009 Date: Fri, 8 May 2009 15:08:06 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 May 2009 22:08:06.0134 (UTC) FILETIME=[76C09960:01C9D029] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_8e67d668-3faf-4aeb-82c7-ca769fe0f017_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The RADEXT WG will be having an Interim "Virtual Meeting" on June 10=2C 200= 9 from 9 AM - 11 AM PDT.=20 The proposed agenda for the virtual interim is available here: http://www.drizzle.com/~aboba/RADEXT/jun-virtual-interim.txt Further details on the Virtual Interim will be announced on the list.=20 --_8e67d668-3faf-4aeb-82c7-ca769fe0f017_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The RADEXT WG will be having an Interim "Virtual Meeting" on June 10=2C 200= 9 from 9 AM - 11 AM PDT.

The proposed agenda for the virtual interi= m is available here:
http://www.drizzle.com/~aboba/RADEXT/jun-virtual-in= terim.txt

Further details on the Virtual Interim will be announced o= n the list.




<= tbody>

= --_8e67d668-3faf-4aeb-82c7-ca769fe0f017_-- -- 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 May 8 19:52:16 2009 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 4CA493A6B45 for ; Fri, 8 May 2009 19:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTfZXxlKX5aC for ; Fri, 8 May 2009 19:52:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47F513A6A47 for ; Fri, 8 May 2009 19:52:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2cci-0005Cl-Mn for radiusext-data0@psg.com; Sat, 09 May 2009 02:49:12 +0000 Received: from [76.96.62.40] (helo=QMTA04.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2ccW-0005Bq-Dn for radiusext@ops.ietf.org; Sat, 09 May 2009 02:49:05 +0000 Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA04.westchester.pa.mail.comcast.net with comcast id pCtS1b00E1HzFnQ54Ep0WE; Sat, 09 May 2009 02:49:00 +0000 Received: from gwzPC ([210.57.242.40]) by OMTA14.westchester.pa.mail.comcast.net with comcast id pEoY1b0020t0P5u3aEocNz; Sat, 09 May 2009 02:48:58 +0000 From: "Glen Zorn" To: "'Dave Nelson'" , "'Jari Arkko'" , Cc: , , , , "'radext mailing list'" References: <20090507140820.D19BB3A709C@core3.amsl.com> <4A041C6F.5010900@freeradius.org> <4A042E47.6000809@piuha.net> <6E09E7F7D0B440DBB676FD1C8EA60852@NEWTON603> In-Reply-To: <6E09E7F7D0B440DBB676FD1C8EA60852@NEWTON603> Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Sat, 9 May 2009 11:48:04 +0900 Message-ID: <000301c9d050$a30d2ac0$e9278040$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnP3dxyT6MRSao2QEaqQ80ufMfOSwAATGOwABu3mnA= Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Dave Nelson [mailto:d.b.nelson@comcast.net] writes: ... > This document should aim to bring order out of chaos. > > I think it would be fine if the Extended Attributes have 16-bit IDs and > the > traditional RFC 2865 format VSAs kept their 8-bit IDs. Anything else, > e.g. > non-standard VSA formats, is simply "off the reservation" and outside > the > scope of this document. The problem is that, first of all, there is no "standard VSA format: the format given in RFC 2865 is recommended, not required. Next, the format recommended was widely and immediately recognized (except, perhaps, by the guardians of orthodoxy in the IETF) as being woefully inadequate and therefore ignored by many large vendors. Last, and perhaps most important, the scope of this document is not (or shouldn't be, IMHO), the preservation of past mistakes but the prevention of future ones. If it is too uncomfortable to admit & fix the VSA fiasco in a BCP, then the WG needs to adopt as a work item a standards-track draft that updates section 5.26 of RFC 2865. In any case, we need to pull our collective head out of the sand. -- 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 May 8 21:28:09 2009 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 136CF3A6B2B for ; Fri, 8 May 2009 21:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.434 X-Spam-Level: X-Spam-Status: No, score=-0.434 tagged_above=-999 required=5 tests=[AWL=-1.857, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEWoI2Xdgc0M for ; Fri, 8 May 2009 21:28:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D6243A6836 for ; Fri, 8 May 2009 21:28:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2e8n-000AAU-Om for radiusext-data0@psg.com; Sat, 09 May 2009 04:26:25 +0000 Received: from [76.96.62.32] (helo=QMTA03.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2e8b-000A9k-5T for radiusext@ops.ietf.org; Sat, 09 May 2009 04:26:19 +0000 Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA03.westchester.pa.mail.comcast.net with comcast id oz9k1b00A17dt5G53GRqoo; Sat, 09 May 2009 04:25:50 +0000 Received: from gwzPC ([210.57.242.40]) by OMTA13.westchester.pa.mail.comcast.net with comcast id pGRy1b00Z0t0P5u3ZGS2ks; Sat, 09 May 2009 04:26:09 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: References: In-Reply-To: Subject: RE: RADEXT WG Interim Virtual Meeting June 10, 2009 Date: Sat, 9 May 2009 13:25:29 +0900 Message-ID: <000a01c9d05e$367106d0$a3531470$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C9D0A9.A658AED0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnQKgZRANfsbb1OTf+G/B9+bfxABQANBWAg Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C9D0A9.A658AED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit How long is this expected to last? ------=_NextPart_000_000B_01C9D0A9.A658AED0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How long is this expected to last?

------=_NextPart_000_000B_01C9D0A9.A658AED0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat May 9 02:49:34 2009 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 448763A6BB7 for ; Sat, 9 May 2009 02:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.223 X-Spam-Level: X-Spam-Status: No, score=-1.223 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D70rLEYFeqcM for ; Sat, 9 May 2009 02:49:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 367523A6DDF for ; Sat, 9 May 2009 02:49:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2j8w-0000i2-Vq for radiusext-data0@psg.com; Sat, 09 May 2009 09:46:55 +0000 Received: from [213.165.64.20] (helo=mail.gmx.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M2j8k-0000gu-D8 for radiusext@ops.ietf.org; Sat, 09 May 2009 09:46:48 +0000 Received: (qmail invoked by alias); 09 May 2009 09:46:40 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp069) with SMTP; 09 May 2009 11:46:40 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19CERMP32xCcZrKrDpyOmYrW830gJMqJchcAVhSfz oOZgB+NFFush48 From: "Hannes Tschofenig" To: "'Glen Zorn'" , "'Dave Nelson'" , "'Jari Arkko'" , Cc: , , , , "'radext mailing list'" References: <20090507140820.D19BB3A709C@core3.amsl.com> <4A041C6F.5010900@freeradius.org> <4A042E47.6000809@piuha.net> <6E09E7F7D0B440DBB676FD1C8EA60852@NEWTON603> <000301c9d050$a30d2ac0$e9278040$@net> Subject: My problem with draft-ietf-radext-design Date: Sat, 9 May 2009 12:48:14 +0300 Message-ID: <009601c9d08b$48211910$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000301c9d050$a30d2ac0$e9278040$@net> Thread-Index: AcnP3dxyT6MRSao2QEaqQ80ufMfOSwAATGOwABu3mnAAC2jtIA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi all, The document assumes a certain implementation and processing model. This model is not explicitly documented in the draft and unfortunately has implications on the design of attributes particularly when it comes to data types used by RADIUS attributes and for the claimed problems that arise from adding new code to the RADIUS server. In previous mail exchanges on the list I did not agree with certain aspects of the implicitly assumed progressing model. I am, however, OK with documenting the model and to thereby make it explicit to the reader. The understanding of some of the claimed limitations might also be clearer. Ciao Hannes PS: FYI, I stated my concerns previously on the RADEXT list. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun May 10 02:52:58 2009 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 EBC663A67B5 for ; Sun, 10 May 2009 02:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.455 X-Spam-Level: X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4czyzsxf0BQI for ; Sun, 10 May 2009 02:52:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 037813A68AD for ; Sun, 10 May 2009 02:52:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M35fM-000DT5-2H for radiusext-data0@psg.com; Sun, 10 May 2009 09:49:52 +0000 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M35f0-000DS6-Q7 for radiusext@ops.ietf.org; Sun, 10 May 2009 09:49:46 +0000 X-IronPort-AV: E=Sophos;i="4.40,323,1238990400"; d="scan'208";a="160870841" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 10 May 2009 05:49:28 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 May 2009 05:49:27 -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: DISCUSS and COMMENT: draft-ietf-radext-design Date: Sun, 10 May 2009 11:49:07 +0200 Message-ID: In-Reply-To: <4A041C6F.5010900@freeradius.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: draft-ietf-radext-design Thread-Index: AcnP0yeoH0irKJf9QjuEMB45A1lJEwBgTeeA References: <20090507140820.D19BB3A709C@core3.amsl.com> <4A041C6F.5010900@freeradius.org> From: "Romascanu, Dan (Dan)" To: , "Jari Arkko" Cc: , , , , "radext mailing list" Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: =20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Alan T DeKok >=20 > > - Can a vendor who moved from 8 bits to 16 bits deal with this? >=20 > Vendors cannot create VSAs of both 8 and 16 bits with the=20 > same Vendor-Id. Some have tried, and have quickly fixed=20 > their product when > *everyone* complained. >=20 > If vendors want to "switch" to using 16-bit types, they=20 > need to use a new vendor-id. >=20 Hmmmm ... There is nothing in the guidelines that says this. Should there be text on this respect if this is the consensus of the editor and WG?=20 Dan -- 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 May 10 18:25:15 2009 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 D6F7D3A6ED1 for ; Sun, 10 May 2009 18:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIg1bwM-Z8H1 for ; Sun, 10 May 2009 18:25:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3EA6C3A659C for ; Sun, 10 May 2009 18:25:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M3KEB-0000zO-58 for radiusext-data0@psg.com; Mon, 11 May 2009 01:22:47 +0000 Received: from [76.96.62.24] (helo=QMTA02.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M3KDo-0000xl-M1 for radiusext@ops.ietf.org; Mon, 11 May 2009 01:22:30 +0000 Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA02.westchester.pa.mail.comcast.net with comcast id q04L1b00B17dt5G521N9dV; Mon, 11 May 2009 01:22:09 +0000 Received: from gwzPC ([210.57.242.40]) by OMTA13.westchester.pa.mail.comcast.net with comcast id q1Ms1b00i0t0P5u3Z1Mxjp; Mon, 11 May 2009 01:22:22 +0000 From: "Glen Zorn" To: , "'Cullen Jennings'" Cc: , "'Dave Nelson'" , "'Jari Arkko'" , "'radext mailing list'" , , , "'IESG IESG'" References: <20090507140820.D19BB3A709C@core3.amsl.com> <4A041C6F.5010900@freeradius.org> <4A042E47.6000809@piuha.net> <6E09E7F7D0B440DBB676FD1C8EA60852@NEWTON603> <000301c9d050$a30d2ac0$e9278040$@net> <4A073285.8080409@freeradius.org> In-Reply-To: <4A073285.8080409@freeradius.org> Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Mon, 11 May 2009 10:21:08 +0900 Message-ID: <008a01c9d1d6$d54a1b60$7fde5220$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnRqhJkCf+mde/sTKGLeVX0faWfwQAJ2vJA Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan T DeKok [mailto:aland@freeradius.org] > Cullen Jennings wrote: > > > > On May 8, 2009, at 20:48 , Glen Zorn wrote: > > > >> Next, the format > >> recommended was widely and immediately recognized (except, perhaps, > by > >> the > >> guardians of orthodoxy in the IETF) as being woefully inadequate and > >> therefore ignored by many large vendors. > > > > Folks, is this statement is true - I am very concerned about this > being > > ready to be a BCP. Was there a consensus call on this? Does the WG > have > > consensus on this? > > Based on the vendor files I have: > > ~100 vendors > ~4 use non-RFC format > > Lucent > Starent > USR (going back to 1994 or so) > WiMAX > > i.e. the overwhelming majority (> 95%) of the major and minor vendors > find the RFC VSA format acceptable. I wonder, does your survey include only actual vendors or just distinct vendor IDs? I suspect the latter, since 3COM (not on your list) bought USR, inheriting that type space. It also appears that the same weight is given to vendors like Cisco & Lucent as to "Bob's NAS Factory". Is this important? It certainly seems important to me, since small vendors are unlikely to put RADIUS to the number and variety of uses that would push the envelope of the type space. It also ignores the internal structure of those "RFC format" VSAs, in many cases chosen to avoid exhausting the VSA type space (see below). > > This includes Cisco, who uses the RFC format, and then extends it to > encapsulate (almost) free-form text. Perhaps you are unaware of the fact that a major purpose of the encapsulation of "(almost) free-form text" was to extend the inadequate VSA type space. > > I doubt very much that any other RADIUS server will have different > statistics. So do I, which would be damning indeed if these statistics had any meaning at all. > Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon May 11 09:21:30 2009 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 9CB173A6A3D for ; Mon, 11 May 2009 09:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1IztHRJvt87 for ; Mon, 11 May 2009 09:21:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D32C3A69F7 for ; Mon, 11 May 2009 09:21:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M3YDm-000LT0-Q6 for radiusext-data0@psg.com; Mon, 11 May 2009 16:19:19 +0000 Received: from blu0-omc2-s33.blu0.hotmail.com ([65.55.111.108]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M3YDX-000LRQ-Ty for radiusext@ops.ietf.org; Mon, 11 May 2009 16:19:10 +0000 Received: from BLU137-W21 ([65.55.111.73]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 May 2009 09:19:03 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_841e0c59-74dd-4991-bbc1-cff4e768a7b4_" X-Originating-IP: [24.22.247.82] From: Bernard Aboba To: , CC: "radext-chairs@tools.ietf.org" , "David B. Nelson" , Glen Zorn , Jari Arkko , "radiusext@ops.ietf.org" , , , "iesg@ietf.org" Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Mon, 11 May 2009 09:19:03 -0700 Importance: Normal In-Reply-To: <4A073285.8080409@freeradius.org> References: <20090507140820.D19BB3A709C@core3.amsl.com> <4A041C6F.5010900@freeradius.org> <4A042E47.6000809@piuha.net> <6E09E7F7D0B440DBB676FD1C8EA60852@NEWTON603> <000301c9d050$a30d2ac0$e9278040$@net> <4A073285.8080409@freeradius.org> MIME-Version: 1.0 X-OriginalArrivalTime: 11 May 2009 16:19:03.0734 (UTC) FILETIME=[33593560:01C9D254] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_841e0c59-74dd-4991-bbc1-cff4e768a7b4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > Folks=2C is this statement is true - I am very concerned about this bei= ng > > ready to be a BCP. Was there a consensus call on this? Does the WG have > > consensus on this? >From what I can tell=2C Section 3.2 does not make a recommendation on switc= hing from an 8-bit to a 16-bit vendor-type format. It does describe situations in w= hich an 8-bit vendor type field would be inadequate.=20 As noted by Jari=2C there is a normative recommendation that RADIUS servers= support a 16-bit vendor-type (presumably in addition to the 8-bit vendor type). IMHO=2C tha= t normative=20 recommendation would be more appropriate in the Extended Attributes documen= t=2C which=20 actually utilizes the 16-bit vendor type.=20 > i.e. the overwhelming majority (> 95%) of the major and minor vendors f= ind the RFC VSA format acceptable. Right. Almost all vendors use the 8-bit vendor-type. This should not be = surprising since the issues described in Section 3.2 will typically apply more to SDOs than to v= endors. =20 But since the document doesn't recommend against use of the 8-bit vendor-ty= pe=2C this isn't an issue.=20 --_841e0c59-74dd-4991-bbc1-cff4e768a7b4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B >=3B Folks=2C is this statement is true - I am very concerned abou= t this being
>=3B >=3B ready to be a BCP. Was there a consensus call= on this? Does the WG have
>=3B >=3B consensus on this?

From = what I can tell=2C Section 3.2 does not make a recommendation on switching = from
an 8-bit to a 16-bit vendor-type format. =3B =3B It does de= scribe situations in which an 8-bit
vendor type field would be inadequat= e.

As noted by Jari=2C there is a normative recommendation that RAD= IUS servers support a 16-bit
vendor-type (presumably in addition to the = 8-bit vendor type). =3B IMHO=2C that normative
recommendation would= be more appropriate in the Extended Attributes document=2C which
actua= lly utilizes the 16-bit vendor type.

>=3B i.e. the overwhelming= majority (>=3B 95%) of the major and minor vendors find the RFC VSA form= at acceptable.

Right. =3B Almost all vendors use the 8-bit vendo= r-type. =3B =3B This should not be surprising since the
issues d= escribed in Section 3.2 will typically apply more to SDOs than to vendors.&= nbsp=3B

But since the document doesn't recommend against use of the= 8-bit vendor-type=2C this isn't an issue.
= --_841e0c59-74dd-4991-bbc1-cff4e768a7b4_-- -- 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 May 11 09:27:05 2009 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 8974A3A68DC for ; Mon, 11 May 2009 09:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zybCuCfOkgnX for ; Mon, 11 May 2009 09:27:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EF10C3A6B28 for ; Mon, 11 May 2009 09:27:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M3YJI-000Lw7-Jp for radiusext-data0@psg.com; Mon, 11 May 2009 16:25:00 +0000 Received: from [213.165.64.20] (helo=mail.gmx.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M3YJ3-000LsY-N6 for radiusext@ops.ietf.org; Mon, 11 May 2009 16:24:51 +0000 Received: (qmail invoked by alias); 11 May 2009 16:24:44 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp050) with SMTP; 11 May 2009 18:24:44 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+1FHExm3K1zKsWsqMehQXc8+WcFZkeDSuBLNS4La SjdwrRx6DWTRdE From: "Hannes Tschofenig" To: Cc: "'Glen Zorn'" , "'Dave Nelson'" , "'Jari Arkko'" , , , , , "'radext mailing list'" References: <20090507140820.D19BB3A709C@core3.amsl.com> <4A041C6F.5010900@freeradius.org> <4A042E47.6000809@piuha.net> <6E09E7F7D0B440DBB676FD1C8EA60852@NEWTON603> <000301c9d050$a30d2ac0$e9278040$@net> <009601c9d08b$48211910$0301a8c0@nsnintra.net> <4A0824D2.9050102@freeradius.org> Subject: RE: My problem with draft-ietf-radext-design Date: Mon, 11 May 2009 19:26:21 +0300 Message-ID: <009301c9d255$39fb3f70$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnSOnr7PtRVLJAxRYm1IfdV3yNR4wAGTPdA In-Reply-To: <4A0824D2.9050102@freeradius.org> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: I can compile some text but this is not saying that I agree with the assumed model, i.e. one where essentially no improvement in implementations was made over the last 10 years. >-----Original Message----- >From: Alan T DeKok [mailto:aland@freeradius.org] >Sent: 11 May, 2009 16:15 >To: Hannes Tschofenig >Cc: 'Glen Zorn'; 'Dave Nelson'; 'Jari Arkko'; >gdweber@gmail.com; draft-ietf-radext-design@tools.ietf.org; >iesg@ietf.org; radext-chairs@tools.ietf.org; 'radext mailing list' >Subject: Re: My problem with draft-ietf-radext-design > >Hannes Tschofenig wrote: >> The document assumes a certain implementation and processing model. > > Yes. This model goes back to the original Livingston >server, and is at least consistent with all existing RADIUS >servers. i.e. the use of static dictionary files. > > Some RADIUS servers offer *additional* functionality, but >this practice is not ubiquitous. > >> This >> model is not explicitly documented in the draft and >unfortunately has >> implications on the design of attributes particularly when >it comes to >> data types used by RADIUS attributes and for the claimed >problems that >> arise from adding new code to the RADIUS server. > > The goal of the document is to describe recommended >practices that will result in wide adoption of any proposal. >Using the lowest common denominator for RADIUS dictionary >capabilities gives the wides possible adoption. > > Other capabilities can be added with new code such as >scripting languages (Perl, Python), C / C++, or Java. Many >implementations also support simple programmatic capabilities >to describe new data types. > > But these capabilities are not *ubiquitous*. > >> In previous mail exchanges on the list I did not agree with certain >> aspects of the implicitly assumed progressing model. I am, >however, OK >> with documenting the model and to thereby make it explicit to the >> reader. The understanding of some of the claimed limitations >might also be clearer. > > Do you have suggested text for the document? > > Alan DeKok. > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon May 11 09:55:28 2009 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 7076A3A6BF2 for ; Mon, 11 May 2009 09:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.823 X-Spam-Level: X-Spam-Status: No, score=-0.823 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id da4fh5Nm3B2Z for ; Mon, 11 May 2009 09:55:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3DD2B3A68F5 for ; Mon, 11 May 2009 09:55:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M3Yjz-000O6S-NY for radiusext-data0@psg.com; Mon, 11 May 2009 16:52:35 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M3Yja-000O3z-QG for radiusext@ops.ietf.org; Mon, 11 May 2009 16:52:16 +0000 Received: (qmail 27669 invoked from network); 11 May 2009 12:52:02 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 11 May 2009 12:52:02 -0400 From: "David B. Nelson" To: "'Hannes Tschofenig'" , Cc: "'Glen Zorn'" , "'Dave Nelson'" , "'Jari Arkko'" , , , , , "'radext mailing list'" References: <20090507140820.D19BB3A709C@core3.amsl.com> <4A041C6F.5010900@freeradius.org> <4A042E47.6000809@piuha.net> <6E09E7F7D0B440DBB676FD1C8EA60852@NEWTON603> <000301c9d050$a30d2ac0$e9278040$@net> <009601c9d08b$48211910$0301a8c0@nsnintra.net> <4A0824D2.9050102@freeradius.org> <009301c9d255$39fb3f70$0301a8c0@nsnintra.net> Subject: RE: My problem with draft-ietf-radext-design Date: Mon, 11 May 2009 12:52:08 -0400 Organization: Elbrys Networks, Inc. Message-ID: <090209B137404C4594713A5CD89DABD7@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <009301c9d255$39fb3f70$0301a8c0@nsnintra.net> Thread-Index: AcnSOnr7PtRVLJAxRYm1IfdV3yNR4wAGTPdAAAD0rgA= Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hannes Tschofenig writes... > ...but this is not saying that I agree with the > assumed model, i.e. one where essentially no improvement > in implementations was made over the last 10 years. Perhaps, but this seems to presume that data-dictionary-driven server implementations are a liability which requires improvement. Like a network management application for SNMP which has the ability to "enroll" a MIB module without code changes, a RADIUS server that can simply add new attributes to its dictionary is a boon to users. We can split hairs about what types of user-added executable scripts are or are not "coding". I still think that the data dictionary architecture is a very powerful concept. Not to mention a very widely deployed one. -- 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 May 11 22:54:53 2009 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 4CAEF3A6AA5 for ; Mon, 11 May 2009 22:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkuW4bFlucFd for ; Mon, 11 May 2009 22:54:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E1BE03A67DB for ; Mon, 11 May 2009 22:54:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M3ktP-000MAs-7F for radiusext-data0@psg.com; Tue, 12 May 2009 05:51:07 +0000 Received: from [76.96.62.48] (helo=QMTA05.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M3ktC-000MAF-8b for radiusext@ops.ietf.org; Tue, 12 May 2009 05:51:00 +0000 Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA05.westchester.pa.mail.comcast.net with comcast id qVbE1b00317dt5G55VqubG; Tue, 12 May 2009 05:50:54 +0000 Received: from gwzPC ([124.122.162.228]) by OMTA13.westchester.pa.mail.comcast.net with comcast id qVpk1b0024vyaqc3ZVptZV; Tue, 12 May 2009 05:50:49 +0000 From: "Glen Zorn" To: Cc: "'Cullen Jennings'" , , "'Dave Nelson'" , "'Jari Arkko'" , "'radext mailing list'" , , , "'IESG IESG'" References: <20090507140820.D19BB3A709C@core3.amsl.com> <4A041C6F.5010900@freeradius.org> <4A042E47.6000809@piuha.net> <6E09E7F7D0B440DBB676FD1C8EA60852@NEWTON603> <000301c9d050$a30d2ac0$e9278040$@net> <4A073285.8080409@freeradius.org> <008a01c9d1d6$d54a1b60$7fde5220$@net> <4A07BF14.1040100@freeradius.org> In-Reply-To: <4A07BF14.1040100@freeradius.org> Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Tue, 12 May 2009 12:48:59 +0700 Message-ID: <01bd01c9d2c5$8001ed50$8005c7f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnR/dlWHixk0SfNSFeg+ykFMXuDcgAwCibw Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan T DeKok [mailto:aland@freeradius.org] writes: > Glen Zorn wrote: > > I wonder, does your survey include only actual vendors or just > distinct > > vendor IDs? > > The data is freely available, you are welcome to do your own analysis > on it. > > > I suspect the latter, since 3COM (not on your list) bought USR, > > inheriting that type space. > > Ah. So a vendor doesn't count if they've "sold out" to a bigger one? You didn't count 3COM in you "nonstandard". Far from saying that USR doesn't count, I'm saying that _both_ USR and 3COM count. > > > It also appears that the same weight is given > > to vendors like Cisco & Lucent as to "Bob's NAS Factory". Is this > > important? It certainly seems important to me, since small vendors > are > > unlikely to put RADIUS to the number and variety of uses that would > push the > > envelope of the type space. > > So small vendors don't count because the design of RADIUS is > sufficient for them? I didn't say that they don't count, and the fact that they may not have needed to define huge numbers of VSAs doesn't say anything about the design of RADIUS. Another important thing that was left out of your simple count was the question of how many vendors, when needing a particular piece of functionality, simply chose to support a VSA already defined by another vendor (the Microsoft MS-MPPE-*-Key Attributes are poster children for this, but there are others). > > > It also ignores the internal structure of those > > "RFC format" VSAs, in many cases chosen to avoid exhausting the VSA > type > > space (see below). > > It also ignores the many vendors (large ones) who have poached on the > standard attribute space... without coming close to exhausting the VSA > space assigned to them. What's your point? > > >> This includes Cisco, who uses the RFC format, and then extends it > to > >> encapsulate (almost) free-form text. > > > > Perhaps you are unaware of the fact that a major purpose of the > > encapsulation of "(almost) free-form text" was to extend the > inadequate VSA > > type space. > > In an ad-hoc and inefficient way. If Cisco had simply asked for a new > vendor-Id, and then used the USR style format in that space, there > would > have been no need to extend the VSA space with VSAs formatted as text > strings. Since USR had been a major player, all RADIUS servers support > the format. Again what's your point? My point was that the size of the VSA type size was inadequate, so people had to work around it. Does it really matter what forms the work-around took? It's also a little bizarre that you are suggesting that Cisco go from a (superficially) "standard" VSA format to one you list as "non-standard" (although it seems at least as "standard" as the Cisco format... > > I would think that 2^32 VSAs is sufficient space, even for Cisco. The Type field in the Vendor-Specific Attribute is one octet long; where did 2^32 come from? > > > So do I, which would be damning indeed if these statistics had any > meaning > > at all. > > Then by all means, let's ignore the data we have at hand. The problem isn't with the data at hand, it's with the analysis. > In it's place we might use appeals to authority, dismissal of "minor" playors, suggestions to move to protocols that the "major" vendors don't support, etc. If you like; I don't recall suggesting any such things, however. An alternative might be to use reason and logic, as opposed to relying solely upon primary school counting skills. > > Since Cisco is such a large player, and has a blatant need for more > VSA space, let's just ignore the IETF review process, and standardize > on > whatever Cisco comes up with. If you want to pick one, I much prefer the USR method; there is IPR attached, though. > But I recall some objection to that idea. I don't remember your being involved in the discussions at the time, maybe lurking? In any case, IIRC, the Cisco engineers participating in the radius WG attempted to argue for a 16-bit (at least) Type field in the Vendor-Specific Attribute but were shut down. Since the very existence of VSAs was highly controversial, they gave up & took what the could get (along w/USR). I'm not really sure what we're arguing about, anyway: I thought that you were defending the suggestion in the Guidelines draft that 16-bit Types be supported & I'm agreeing. Did you change your position? > > 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 Thu May 14 10:05:38 2009 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 9F17B3A69D2 for ; Thu, 14 May 2009 10:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3qA+tTVE7VE for ; Thu, 14 May 2009 10:05:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1AFB23A6F48 for ; Thu, 14 May 2009 10:05:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M4eJa-000Otg-L1 for radiusext-data0@psg.com; Thu, 14 May 2009 17:01:50 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1M4eJM-000Osz-Iy for radiusext@ops.ietf.org; Thu, 14 May 2009 17:01:43 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 27F0628C2F6; Thu, 14 May 2009 10:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: RADEXT Interim Virtual Meeting Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090514170002.27F0628C2F6@core3.amsl.com> Date: Thu, 14 May 2009 10:00:02 -0700 (PDT) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: On Wednesday, June 10, 2009, 09:00-11:00AM PDT (12:00-14:00 EDT), RADEXT WG will be having a virtual interim meeting, with the following agenda: * Crypto-agility Requirements http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements * Extended RADIUS Attributes http://tools.ietf.org/html/draft-ietf-radext-extended-attributes Virtual meeting information for this meeting will be posted at: http://www.drizzle.com/~aboba/RADEXT/jun-virtual-interim.txt -- 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 May 31 09:34:38 2009 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 33C953A6F37 for ; Sun, 31 May 2009 09:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.347 X-Spam-Level: X-Spam-Status: No, score=-102.347 tagged_above=-999 required=5 tests=[AWL=0.253, 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 w67PJmsr1F3A for ; Sun, 31 May 2009 09:34:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B19D3A6F78 for ; Sun, 31 May 2009 09:34:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAnx3-000CXs-TJ for radiusext-data0@psg.com; Sun, 31 May 2009 16:32:01 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAnwp-000CVq-Su for radiusext@ops.ietf.org; Sun, 31 May 2009 16:31:56 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 44DE628C18B; Sun, 31 May 2009 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-management-authorization-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090531163001.44DE628C18B@core3.amsl.com> Date: Sun, 31 May 2009 09:30:01 -0700 (PDT) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management Author(s) : D. Nelson, G. Weber Filename : draft-ietf-radext-management-authorization-07.txt Pages : 25 Date : 2009-05-31 This document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for authorizing management access to a Network Access Server (NAS). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via framed management protocols, and for management access over a secure transport protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-management-authorization-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-31092528.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, 31 May 2009 16:32:48 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-management-authorization-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090531163001.44DE628C18B@core3.amsl.com> Date: Sun, 31 May 2009 09:30:01 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management Author(s) : D. Nelson, G. Weber Filename : draft-ietf-radext-management-authorization-07.txt Pages : 25 Date : 2009-05-31 This document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for authorizing management access to a Network Access Server (NAS). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via framed management protocols, and for management access over a secure transport protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-management-authorization-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-31092528.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: Thu, 14 May 2009 17:03:00 +0000 From: IESG Secretary To: ietf-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: RADEXT Interim Virtual Meeting Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090514170002.27F0628C2F6@core3.amsl.com> Date: Thu, 14 May 2009 10:00:02 -0700 (PDT) On Wednesday, June 10, 2009, 09:00-11:00AM PDT (12:00-14:00 EDT), RADEXT WG will be having a virtual interim meeting, with the following agenda: * Crypto-agility Requirements http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements * Extended RADIUS Attributes http://tools.ietf.org/html/draft-ietf-radext-extended-attributes Virtual meeting information for this meeting will be posted at: http://www.drizzle.com/~aboba/RADEXT/jun-virtual-interim.txt -- 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 May 2009 05:52:04 +0000 From: "Glen Zorn" To: Cc: "'Cullen Jennings'" , , "'Dave Nelson'" , "'Jari Arkko'" , "'radext mailing list'" , , , "'IESG IESG'" Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Tue, 12 May 2009 12:48:59 +0700 Message-ID: <01bd01c9d2c5$8001ed50$8005c7f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcnR/dlWHixk0SfNSFeg+ykFMXuDcgAwCibw Content-Language: en-us Alan T DeKok [mailto:aland@freeradius.org] writes: > Glen Zorn wrote: > > I wonder, does your survey include only actual vendors or just > distinct > > vendor IDs? > > The data is freely available, you are welcome to do your own analysis > on it. > > > I suspect the latter, since 3COM (not on your list) bought USR, > > inheriting that type space. > > Ah. So a vendor doesn't count if they've "sold out" to a bigger one? You didn't count 3COM in you "nonstandard". Far from saying that USR doesn't count, I'm saying that _both_ USR and 3COM count. > > > It also appears that the same weight is given > > to vendors like Cisco & Lucent as to "Bob's NAS Factory". Is this > > important? It certainly seems important to me, since small vendors > are > > unlikely to put RADIUS to the number and variety of uses that would > push the > > envelope of the type space. > > So small vendors don't count because the design of RADIUS is > sufficient for them? I didn't say that they don't count, and the fact that they may not have needed to define huge numbers of VSAs doesn't say anything about the design of RADIUS. Another important thing that was left out of your simple count was the question of how many vendors, when needing a particular piece of functionality, simply chose to support a VSA already defined by another vendor (the Microsoft MS-MPPE-*-Key Attributes are poster children for this, but there are others). > > > It also ignores the internal structure of those > > "RFC format" VSAs, in many cases chosen to avoid exhausting the VSA > type > > space (see below). > > It also ignores the many vendors (large ones) who have poached on the > standard attribute space... without coming close to exhausting the VSA > space assigned to them. What's your point? > > >> This includes Cisco, who uses the RFC format, and then extends it > to > >> encapsulate (almost) free-form text. > > > > Perhaps you are unaware of the fact that a major purpose of the > > encapsulation of "(almost) free-form text" was to extend the > inadequate VSA > > type space. > > In an ad-hoc and inefficient way. If Cisco had simply asked for a new > vendor-Id, and then used the USR style format in that space, there > would > have been no need to extend the VSA space with VSAs formatted as text > strings. Since USR had been a major player, all RADIUS servers support > the format. Again what's your point? My point was that the size of the VSA type size was inadequate, so people had to work around it. Does it really matter what forms the work-around took? It's also a little bizarre that you are suggesting that Cisco go from a (superficially) "standard" VSA format to one you list as "non-standard" (although it seems at least as "standard" as the Cisco format... > > I would think that 2^32 VSAs is sufficient space, even for Cisco. The Type field in the Vendor-Specific Attribute is one octet long; where did 2^32 come from? > > > So do I, which would be damning indeed if these statistics had any > meaning > > at all. > > Then by all means, let's ignore the data we have at hand. The problem isn't with the data at hand, it's with the analysis. > In it's place we might use appeals to authority, dismissal of "minor" playors, suggestions to move to protocols that the "major" vendors don't support, etc. If you like; I don't recall suggesting any such things, however. An alternative might be to use reason and logic, as opposed to relying solely upon primary school counting skills. > > Since Cisco is such a large player, and has a blatant need for more > VSA space, let's just ignore the IETF review process, and standardize > on > whatever Cisco comes up with. If you want to pick one, I much prefer the USR method; there is IPR attached, though. > But I recall some objection to that idea. I don't remember your being involved in the discussions at the time, maybe lurking? In any case, IIRC, the Cisco engineers participating in the radius WG attempted to argue for a 16-bit (at least) Type field in the Vendor-Specific Attribute but were shut down. Since the very existence of VSAs was highly controversial, they gave up & took what the could get (along w/USR). I'm not really sure what we're arguing about, anyway: I thought that you were defending the suggestion in the Guidelines draft that 16-bit Types be supported & I'm agreeing. Did you change your position? > > 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: Mon, 11 May 2009 16:53:04 +0000 From: "David B. Nelson" To: "'Hannes Tschofenig'" , Cc: "'Glen Zorn'" , "'Dave Nelson'" , "'Jari Arkko'" , , , , , "'radext mailing list'" Subject: RE: My problem with draft-ietf-radext-design Date: Mon, 11 May 2009 12:52:08 -0400 Organization: Elbrys Networks, Inc. Message-ID: <090209B137404C4594713A5CD89DABD7@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcnSOnr7PtRVLJAxRYm1IfdV3yNR4wAGTPdAAAD0rgA= Hannes Tschofenig writes... > ...but this is not saying that I agree with the > assumed model, i.e. one where essentially no improvement > in implementations was made over the last 10 years. Perhaps, but this seems to presume that data-dictionary-driven server implementations are a liability which requires improvement. Like a network management application for SNMP which has the ability to "enroll" a MIB module without code changes, a RADIUS server that can simply add new attributes to its dictionary is a boon to users. We can split hairs about what types of user-added executable scripts are or are not "coding". I still think that the data dictionary architecture is a very powerful concept. Not to mention a very widely deployed one. -- 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 May 2009 16:25:17 +0000 From: "Hannes Tschofenig" To: Cc: "'Glen Zorn'" , "'Dave Nelson'" , "'Jari Arkko'" , , , , , "'radext mailing list'" Subject: RE: My problem with draft-ietf-radext-design Date: Mon, 11 May 2009 19:26:21 +0300 Message-ID: <009301c9d255$39fb3f70$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcnSOnr7PtRVLJAxRYm1IfdV3yNR4wAGTPdA I can compile some text but this is not saying that I agree with the assumed model, i.e. one where essentially no improvement in implementations was made over the last 10 years. >-----Original Message----- >From: Alan T DeKok [mailto:aland@freeradius.org] >Sent: 11 May, 2009 16:15 >To: Hannes Tschofenig >Cc: 'Glen Zorn'; 'Dave Nelson'; 'Jari Arkko'; >gdweber@gmail.com; draft-ietf-radext-design@tools.ietf.org; >iesg@ietf.org; radext-chairs@tools.ietf.org; 'radext mailing list' >Subject: Re: My problem with draft-ietf-radext-design > >Hannes Tschofenig wrote: >> The document assumes a certain implementation and processing model. > > Yes. This model goes back to the original Livingston >server, and is at least consistent with all existing RADIUS >servers. i.e. the use of static dictionary files. > > Some RADIUS servers offer *additional* functionality, but >this practice is not ubiquitous. > >> This >> model is not explicitly documented in the draft and >unfortunately has >> implications on the design of attributes particularly when >it comes to >> data types used by RADIUS attributes and for the claimed >problems that >> arise from adding new code to the RADIUS server. > > The goal of the document is to describe recommended >practices that will result in wide adoption of any proposal. >Using the lowest common denominator for RADIUS dictionary >capabilities gives the wides possible adoption. > > Other capabilities can be added with new code such as >scripting languages (Perl, Python), C / C++, or Java. Many >implementations also support simple programmatic capabilities >to describe new data types. > > But these capabilities are not *ubiquitous*. > >> In previous mail exchanges on the list I did not agree with certain >> aspects of the implicitly assumed progressing model. I am, >however, OK >> with documenting the model and to thereby make it explicit to the >> reader. The understanding of some of the claimed limitations >might also be clearer. > > Do you have suggested text for the document? > > 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: Mon, 11 May 2009 16:19:58 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_841e0c59-74dd-4991-bbc1-cff4e768a7b4_" From: Bernard Aboba To: , CC: "radext-chairs@tools.ietf.org" , "David B. Nelson" , Glen Zorn , Jari Arkko , "radiusext@ops.ietf.org" , , , "iesg@ietf.org" Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Mon, 11 May 2009 09:19:03 -0700 MIME-Version: 1.0 --_841e0c59-74dd-4991-bbc1-cff4e768a7b4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > Folks=2C is this statement is true - I am very concerned about this bei= ng > > ready to be a BCP. Was there a consensus call on this? Does the WG have > > consensus on this? >From what I can tell=2C Section 3.2 does not make a recommendation on switc= hing from an 8-bit to a 16-bit vendor-type format. It does describe situations in w= hich an 8-bit vendor type field would be inadequate.=20 As noted by Jari=2C there is a normative recommendation that RADIUS servers= support a 16-bit vendor-type (presumably in addition to the 8-bit vendor type). IMHO=2C tha= t normative=20 recommendation would be more appropriate in the Extended Attributes documen= t=2C which=20 actually utilizes the 16-bit vendor type.=20 > i.e. the overwhelming majority (> 95%) of the major and minor vendors f= ind the RFC VSA format acceptable. Right. Almost all vendors use the 8-bit vendor-type. This should not be = surprising since the issues described in Section 3.2 will typically apply more to SDOs than to v= endors. =20 But since the document doesn't recommend against use of the 8-bit vendor-ty= pe=2C this isn't an issue.=20 --_841e0c59-74dd-4991-bbc1-cff4e768a7b4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B >=3B Folks=2C is this statement is true - I am very concerned abou= t this being
>=3B >=3B ready to be a BCP. Was there a consensus call= on this? Does the WG have
>=3B >=3B consensus on this?

From = what I can tell=2C Section 3.2 does not make a recommendation on switching = from
an 8-bit to a 16-bit vendor-type format. =3B =3B It does de= scribe situations in which an 8-bit
vendor type field would be inadequat= e.

As noted by Jari=2C there is a normative recommendation that RAD= IUS servers support a 16-bit
vendor-type (presumably in addition to the = 8-bit vendor type). =3B IMHO=2C that normative
recommendation would= be more appropriate in the Extended Attributes document=2C which
actua= lly utilizes the 16-bit vendor type.

>=3B i.e. the overwhelming= majority (>=3B 95%) of the major and minor vendors find the RFC VSA form= at acceptable.

Right. =3B Almost all vendors use the 8-bit vendo= r-type. =3B =3B This should not be surprising since the
issues d= escribed in Section 3.2 will typically apply more to SDOs than to vendors.&= nbsp=3B

But since the document doesn't recommend against use of the= 8-bit vendor-type=2C this isn't an issue.
= --_841e0c59-74dd-4991-bbc1-cff4e768a7b4_-- -- 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 May 2009 01:23:46 +0000 From: "Glen Zorn" To: , "'Cullen Jennings'" Cc: , "'Dave Nelson'" , "'Jari Arkko'" , "'radext mailing list'" , , , "'IESG IESG'" Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Mon, 11 May 2009 10:21:08 +0900 Message-ID: <008a01c9d1d6$d54a1b60$7fde5220$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcnRqhJkCf+mde/sTKGLeVX0faWfwQAJ2vJA Content-Language: en-us Alan T DeKok [mailto:aland@freeradius.org] > Cullen Jennings wrote: > > > > On May 8, 2009, at 20:48 , Glen Zorn wrote: > > > >> Next, the format > >> recommended was widely and immediately recognized (except, perhaps, > by > >> the > >> guardians of orthodoxy in the IETF) as being woefully inadequate and > >> therefore ignored by many large vendors. > > > > Folks, is this statement is true - I am very concerned about this > being > > ready to be a BCP. Was there a consensus call on this? Does the WG > have > > consensus on this? > > Based on the vendor files I have: > > ~100 vendors > ~4 use non-RFC format > > Lucent > Starent > USR (going back to 1994 or so) > WiMAX > > i.e. the overwhelming majority (> 95%) of the major and minor vendors > find the RFC VSA format acceptable. I wonder, does your survey include only actual vendors or just distinct vendor IDs? I suspect the latter, since 3COM (not on your list) bought USR, inheriting that type space. It also appears that the same weight is given to vendors like Cisco & Lucent as to "Bob's NAS Factory". Is this important? It certainly seems important to me, since small vendors are unlikely to put RADIUS to the number and variety of uses that would push the envelope of the type space. It also ignores the internal structure of those "RFC format" VSAs, in many cases chosen to avoid exhausting the VSA type space (see below). > > This includes Cisco, who uses the RFC format, and then extends it to > encapsulate (almost) free-form text. Perhaps you are unaware of the fact that a major purpose of the encapsulation of "(almost) free-form text" was to extend the inadequate VSA type space. > > I doubt very much that any other RADIUS server will have different > statistics. So do I, which would be damning indeed if these statistics had any meaning at all. > 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: Sun, 10 May 2009 09:50:54 +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: DISCUSS and COMMENT: draft-ietf-radext-design Date: Sun, 10 May 2009 11:49:07 +0200 Message-ID: Thread-Topic: DISCUSS and COMMENT: draft-ietf-radext-design Thread-Index: AcnP0yeoH0irKJf9QjuEMB45A1lJEwBgTeeA From: "Romascanu, Dan (Dan)" To: , "Jari Arkko" Cc: , , , , "radext mailing list" =20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Alan T DeKok >=20 > > - Can a vendor who moved from 8 bits to 16 bits deal with this? >=20 > Vendors cannot create VSAs of both 8 and 16 bits with the=20 > same Vendor-Id. Some have tried, and have quickly fixed=20 > their product when > *everyone* complained. >=20 > If vendors want to "switch" to using 16-bit types, they=20 > need to use a new vendor-id. >=20 Hmmmm ... There is nothing in the guidelines that says this. Should there be text on this respect if this is the consensus of the editor and WG?=20 Dan -- 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: Sat, 09 May 2009 09:47:52 +0000 From: "Hannes Tschofenig" To: "'Glen Zorn'" , "'Dave Nelson'" , "'Jari Arkko'" , Cc: , , , , "'radext mailing list'" Subject: My problem with draft-ietf-radext-design Date: Sat, 9 May 2009 12:48:14 +0300 Message-ID: <009601c9d08b$48211910$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcnP3dxyT6MRSao2QEaqQ80ufMfOSwAATGOwABu3mnAAC2jtIA== Hi all, The document assumes a certain implementation and processing model. This model is not explicitly documented in the draft and unfortunately has implications on the design of attributes particularly when it comes to data types used by RADIUS attributes and for the claimed problems that arise from adding new code to the RADIUS server. In previous mail exchanges on the list I did not agree with certain aspects of the implicitly assumed progressing model. I am, however, OK with documenting the model and to thereby make it explicit to the reader. The understanding of some of the claimed limitations might also be clearer. Ciao Hannes PS: FYI, I stated my concerns previously on the RADEXT list. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 09 May 2009 04:27:00 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: Subject: RE: RADEXT WG Interim Virtual Meeting June 10, 2009 Date: Sat, 9 May 2009 13:25:29 +0900 Message-ID: <000a01c9d05e$367106d0$a3531470$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C9D0A9.A658AED0" Thread-Index: AcnQKgZRANfsbb1OTf+G/B9+bfxABQANBWAg Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C9D0A9.A658AED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit How long is this expected to last? ------=_NextPart_000_000B_01C9D0A9.A658AED0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How long is this expected to last?

------=_NextPart_000_000B_01C9D0A9.A658AED0-- -- 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: Sat, 09 May 2009 02:50:17 +0000 From: "Glen Zorn" To: "'Dave Nelson'" , "'Jari Arkko'" , Cc: , , , , "'radext mailing list'" Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Sat, 9 May 2009 11:48:04 +0900 Message-ID: <000301c9d050$a30d2ac0$e9278040$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcnP3dxyT6MRSao2QEaqQ80ufMfOSwAATGOwABu3mnA= Content-Language: en-us Dave Nelson [mailto:d.b.nelson@comcast.net] writes: ... > This document should aim to bring order out of chaos. > > I think it would be fine if the Extended Attributes have 16-bit IDs and > the > traditional RFC 2865 format VSAs kept their 8-bit IDs. Anything else, > e.g. > non-standard VSA formats, is simply "off the reservation" and outside > the > scope of this document. The problem is that, first of all, there is no "standard VSA format: the format given in RFC 2865 is recommended, not required. Next, the format recommended was widely and immediately recognized (except, perhaps, by the guardians of orthodoxy in the IETF) as being woefully inadequate and therefore ignored by many large vendors. Last, and perhaps most important, the scope of this document is not (or shouldn't be, IMHO), the preservation of past mistakes but the prevention of future ones. If it is too uncomfortable to admit & fix the VSA fiasco in a BCP, then the WG needs to adopt as a work item a standards-track draft that updates section 5.26 of RFC 2865. In any case, we need to pull our collective head out of the sand. -- 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 May 2009 22:08:41 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_8e67d668-3faf-4aeb-82c7-ca769fe0f017_" From: Bernard Aboba To: Subject: RADEXT WG Interim Virtual Meeting June 10, 2009 Date: Fri, 8 May 2009 15:08:06 -0700 MIME-Version: 1.0 --_8e67d668-3faf-4aeb-82c7-ca769fe0f017_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The RADEXT WG will be having an Interim "Virtual Meeting" on June 10=2C 200= 9 from 9 AM - 11 AM PDT.=20 The proposed agenda for the virtual interim is available here: http://www.drizzle.com/~aboba/RADEXT/jun-virtual-interim.txt Further details on the Virtual Interim will be announced on the list.=20 --_8e67d668-3faf-4aeb-82c7-ca769fe0f017_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The RADEXT WG will be having an Interim "Virtual Meeting" on June 10=2C 200= 9 from 9 AM - 11 AM PDT.

The proposed agenda for the virtual interi= m is available here:
http://www.drizzle.com/~aboba/RADEXT/jun-virtual-in= terim.txt

Further details on the Virtual Interim will be announced o= n the list.




<= tbody>

= --_8e67d668-3faf-4aeb-82c7-ca769fe0f017_-- -- 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 May 2009 21:23:52 +0000 Message-ID: <15946675.51561241817459900.JavaMail.javamailuser@localhost> Date: Fri, 8 May 2009 17:17:39 -0400 (EDT) From: Dimdim Invitations Reply-To: bernard_aboba@hotmail.com To: radiusext@ops.ietf.org Subject: RADEXT has invited you to a Dimdim Web Meeting MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dimdim Web Meeting Invitation
 

Hello!
 
Your friend, RADEXT, has invited you to a Dimdim Web Meeting for
June 10, 2009 09:00:AM PDT. To join the web meeting simply click here

You can also join the meeting by entering the meeting ID aboba at Dimdim.com at the time of the meeting.
Join Meeting
You can also join by entering aboba at www.dimdim.com/join
  Meeting : RADEXT
 Key:
  Dial In: 712-432-6139 Pass Code: 226220
  Start: June 10, 2009 09:00:AM PDT (Add to Outlook)
  Schedule Ends At: Not Applicable
  This meeting happens only once
  Meeting Agenda: http://www.drizzle.com/~aboba/RADEXT/jun-virtual-interim.txt


Hint: You don't need to be a member of Dimdim to attend this meeting. It's easy to join and get started, Click here to sign up for Dimdim Free.
But you may find it helpful to check your bandwidth and your A/V setup here.

This is a personal meeting invitation, please do not forward.

Sincerely,
Your Dimdim Team
 
*If the link above is broken (as can happen with some email systems) simply copy and paste the following URL into your browser address bar: http://webmeeting.dimdim.com/portal/JoinForm.action?confKey=aboba&email=radiusext@ops.ietf.org&asPresenter=false&meetingId=4036f7f7-d7b1-4467-8b91-f4c15b8c7c78&attendeePwd=
Note: Some email clients will split the above link into multiple lines.
          Please make sure you copy the entire link (all lines) to join your meeting.

Copyright © 2009 Dimdim. Meet freely.
All Rights Reserved / Privacy Policy
-- 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 May 2009 13:24:48 +0000 From: "Dave Nelson" To: "'Jari Arkko'" , Cc: , , , , "'radext mailing list'" Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Fri, 8 May 2009 09:24:37 -0400 Message-ID: <6E09E7F7D0B440DBB676FD1C8EA60852@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcnP3dxyT6MRSao2QEaqQ80ufMfOSwAATGOw > > Vendors cannot create VSAs of both 8 and 16 bits with the same > > Vendor-Id. Some have tried, and have quickly fixed their product when > > *everyone* complained. > > > > If vendors want to "switch" to using 16-bit types, they need to use a > > new vendor-id. > > > > Ok. I didn't think that was the case but clearly you have the > operational experience on this. > > I think it would be essential to spell this out in the draft -- its > important information! Quite frankly, this line of reasoning disturbs me. It's well known that there have been all sorts of non-standard behaviors (and a few ugly hacks) implemented in RADIUS clients and servers over the years. Dave Mitton documented some of these in RFC 2882. This document is a BCP. That means it should document the *best* current practices and not the more dubious ones. Not all hacks are created equal. This document should aim to bring order out of chaos. I think it would be fine if the Extended Attributes have 16-bit IDs and the traditional RFC 2865 format VSAs kept their 8-bit IDs. Anything else, e.g. non-standard VSA formats, is simply "off the reservation" and outside the scope of this document. -- 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 May 2009 13:07:21 +0000 Message-ID: <4A042E47.6000809@piuha.net> Date: Fri, 08 May 2009 16:06:15 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: aland@freeradius.org CC: gdweber@gmail.com, draft-ietf-radext-design@tools.ietf.org, iesg@ietf.org, radext-chairs@tools.ietf.org, 'radext mailing list' Subject: Re: DISCUSS and COMMENT: draft-ietf-radext-design Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Alan, >> The first issue is that Section 2.3 suggests 16-bit vendor space >> attribute number fields to replace the existing 8-bit recommendation. >> > > In *addition* to 8-bit spaces. Not to replace it. > Well... there was a previous SHOULD recommendation. Now there is a new one (use the old the new). >> There are a couple of problems with this. First, if you really mean >> to change the recommendation, then Updates: RFC 2865 header in the >> beginning of the document would have been appropriate. >> > > We could add that, but I don't think it's critical. > Not very, but I think if we change an earlier requirement it would be helpful to add the Updates pointer so that people who review older RFCs are more likely to remember to check the new one, too. >> Secondly, while I agree with the advice of going for 16 bits, the >> document is silent on some of the issues involved in such a change, >> such as: >> >> - Does RADIUS dictionary software support the VSA format for 16 bits, 8 >> bits, or both? >> > > All major products already support many non-RFC VSA formats, including > 16 bits. > This is very good! Can you say something along these lines in the document, too, because it goes a long way towards resolving any issues the change has. >> - How do you cleanly print or report VSAs when you do not know if the >> field size is 8 or 16 bits? I realize that this situation already >> exists since the format was never required to be followed, but >> your new recommendation makes a potential problem much more likely >> to appear. Previously, you could print something like Vendor = ACME, >> Code = 17, Contents = ABCDEF0011... Now you couldn't do that. >> > > The *current* implementations have the same problem. If they receive > a VSA from an unknown vendor, and it's not in the RFC format, they have > *no* idea what format to use. > Are you saying that no implementation is capable of by default printing out text like I had in my example above? >> - Can a vendor who moved from 8 bits to 16 bits deal with this? >> > > Vendors cannot create VSAs of both 8 and 16 bits with the same > Vendor-Id. Some have tried, and have quickly fixed their product when > *everyone* complained. > > If vendors want to "switch" to using 16-bit types, they need to use a > new vendor-id. > Ok. I didn't think that was the case but clearly you have the operational experience on this. I think it would be essential to spell this out in the draft -- its important information! Jari -- 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 May 2009 12:49:59 +0000 From: "Dave Nelson" To: , "'Jari Arkko'" Cc: , , , , "'radext mailing list'" Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Fri, 8 May 2009 08:49:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcnP0ytnu1X/ZnesRgOe9OZzw1urcgAB+R0g > > There are a couple of problems with this. First, if you really mean > > to change the recommendation, then Updates: RFC 2865 header in the > > beginning of the document would have been appropriate. > > We could add that, but I don't think it's critical. Hmmm. I have doubts about a BCP updating a Draft Standard. -- 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: Thu, 07 May 2009 22:44:39 +0000 From: "David B. Nelson" To: Subject: RE: Strawman Virtual Interim agenda (+ proposed time/date) Date: Thu, 7 May 2009 18:43:37 -0400 Organization: Elbrys Networks, Inc. Message-ID: <773509A43B2745CC9419D23961D493E4@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcnPPa2lg3vnAYjOQAWRgVkDLM5fxwAJkY8g > Here is a strawman proposal for the virtual interim > agenda, plus a potential time/date. The agenda seems fine to me. The date and time works for me, too. -- 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: Thu, 07 May 2009 18:56:10 +0000 Message-ID: <4A032E7B.50501@piuha.net> Date: Thu, 07 May 2009 21:54:51 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Bernard Aboba CC: "iesg@ietf.org" , "radext-chairs@tools.ietf.org" , draft-ietf-radext-design@tools.ietf.org, radiusextgdweber@gmail.com, aland@freeradius.org, "radiusext@ops.ietf.org" Subject: Re: DISCUSS and COMMENT: draft-ietf-radext-design Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Thanks for your comments. > > Design Guidelines has a normative dependency on the Extended > Attributes document, which currently uses a 16-bit vendor type field. > Given that Extended Attributes will require that RADIUS servers > support a 16-bit vendor-type field for IETF-defined extended > attributes, it isn't much of a stretch to recommend that RADIUS > servers support a 16-bit type field for vendor and SDO-specific > attributes as well, since Extended Attributes is based on the VSA format. > > The question is whether that recommendation belongs in this document, > which is a BCP, or whether it should go into the Extended Attributes > document (Proposed Standard) instead, and just be referred to in > Design Guidelines. Consolidating protocol changes into the Extended > Attribute document might be cleaner, particularly since it is Extended > Attributes that will provide much of the motivation for vendors to add > 16-bit vendor type support. Seems reasonable. > With respect to "replacement" of the 8-bit vendor-type field with a > 16-bit vendor type recommendation, my take on the text in 2.3 is that > while it recommends RADIUS server support for 16-bit vendor type > fields, it doesn't make a blanket recommendation that vendors adopt a > 16-bit vendor type field in all situations, but rather points out > situations in which use of a 16-bit vendor type field would be > appropriate: > Note that the Vendor type field in the recommended VSA format is only > a single octet, like the RADIUS type field. While this limitation > results in an efficient encoding, there are situations in which a > vendor or SDO will eventually wish to define more than 255 > attributes. Also, an SDO can be comprised of multiple subgroups, > each of whom can desire autonomy over the definition of attributes > within their group. In such a situation, a 16-bit Vendor type field > would be more appropriate: > Yeah. We talked about this on the call. I think it is reasonable to go to the 16 bit space, but I was only looking for guidance for, say, an SDO that has been using 8 bits before and now has to or wants to go 16 bits. Obviously this can be done, but requires care in how the allocations are done and what dictionaries say. Jari > > > > > > > From: jari.arkko@piuha.net > > To: iesg@ietf.org > > CC: radext-chairs@tools.ietf.org; > draft-ietf-radext-design@tools.ietf.org; gdweber@gmail.com; > aland@freeradius.org > > Date: Thu, 7 May 2009 07:08:20 -0700 > > Subject: DISCUSS and COMMENT: draft-ietf-radext-design > > > > Discuss: > > Great doc! I will vote Yes on it, but I wanted to discuss two issues > > first, one is a Discuss-level problem and the other one a Comment that > > I'd like you to consider. > > > > The first issue is that Section 2.3 suggests 16-bit vendor space > > attribute number fields to replace the existing 8-bit recommendation. > > > > There are a couple of problems with this. First, if you really mean > > to change the recommendation, then Updates: RFC 2865 header in the > > beginning of the document would have been appropriate. > > > > Secondly, while I agree with the advice of going for 16 bits, the > > document is silent on some of the issues involved in such a change, > > such as: > > > > - Does RADIUS dictionary software support the VSA format for 16 bits, 8 > > bits, or both? > > > > - How do you cleanly print or report VSAs when you do not know if the > > field size is 8 or 16 bits? I realize that this situation already > > exists since the format was never required to be followed, but > > your new recommendation makes a potential problem much more likely > > to appear. Previously, you could print something like Vendor = ACME, > > Code = 17, Contents = ABCDEF0011... Now you couldn't do that. > > > > - Can a vendor who moved from 8 bits to 16 bits deal with this? > > > > Comment: > > I do agree that for functionality FOO, both the functionality itself > > and the MIB, RADIUS, etc. work should take place in the same standards > > body. However, Section 3.1 could have said a couple of additional things > > as well: > > > > The issues of attribute space and choice of forum are distinct; there > > is no reason why IETF couldn't use its own vendor code, for instance. > > > > The section also does not mention one of the potential drawbacks of > > SDO-driven development model: it is easy to come up with a number of > > different solutions to the same generic problem, as opposed to finding > > a common solution. > > -- 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: Thu, 07 May 2009 18:12:12 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_5989cd6c-9f0f-4d1a-9380-9d85b57b9448_" From: Bernard Aboba To: Jari Arkko , "iesg@ietf.org" CC: "radext-chairs@tools.ietf.org" , , , , "radiusext@ops.ietf.org" Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Thu, 7 May 2009 11:11:29 -0700 MIME-Version: 1.0 --_5989cd6c-9f0f-4d1a-9380-9d85b57b9448_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for your comments.=20 Design Guidelines has a normative dependency on the Extended Attributes doc= ument=2C which currently uses a 16-bit vendor type field. Given that Exten= ded Attributes will require that RADIUS servers support a 16-bit vendor-typ= e field for IETF-defined extended attributes=2C it isn't much of a stretch = to recommend that RADIUS servers support a 16-bit type field for vendor and= SDO-specific attributes as well=2C since Extended Attributes is based on t= he VSA format.=20 The question is whether that recommendation belongs in this document=2C whi= ch is a BCP=2C or whether it should go into the Extended Attributes documen= t (Proposed Standard) instead=2C and just be referred to in Design Guidelin= es. Consolidating protocol changes into the Extended Attribute document mi= ght be cleaner=2C particularly since it is Extended Attributes that will pr= ovide much of the motivation for vendors to add 16-bit vendor type support. With respect to "replacement" of the 8-bit vendor-type field with a 16-bit = vendor type recommendation=2C my take on the text in 2.3 is that while it r= ecommends RADIUS server support for 16-bit vendor type fields=2C it doesn't= make a blanket recommendation that vendors adopt a 16-bit vendor type fiel= d in all situations=2C but rather points out situations in which use of a 1= 6-bit vendor type field would be appropriate: Note that the Vendor type field in the recommended VSA format is only a single octet=2C like the RADIUS type field. While this limitation results in an efficient encoding=2C there are situations in which a vendor or SDO will eventually wish to define more than 255 attributes. Also=2C an SDO can be comprised of multiple subgroups=2C each of whom can desire autonomy over the definition of attributes within their group. In such a situation=2C a 16-bit Vendor type field would be more appropriate: > From: jari.arkko@piuha.net > To: iesg@ietf.org > CC: radext-chairs@tools.ietf.org=3B draft-ietf-radext-design@tools.ietf.o= rg=3B gdweber@gmail.com=3B aland@freeradius.org > Date: Thu=2C 7 May 2009 07:08:20 -0700 > Subject: DISCUSS and COMMENT: draft-ietf-radext-design=20 >=20 > Discuss: > Great doc! I will vote Yes on it=2C but I wanted to discuss two issues > first=2C one is a Discuss-level problem and the other one a Comment that > I'd like you to consider. >=20 > The first issue is that Section 2.3 suggests 16-bit vendor space > attribute number fields to replace the existing 8-bit recommendation. >=20 > There are a couple of problems with this. First=2C if you really mean > to change the recommendation=2C then Updates: RFC 2865 header in the > beginning of the document would have been appropriate. >=20 > Secondly=2C while I agree with the advice of going for 16 bits=2C the > document is silent on some of the issues involved in such a change=2C > such as: >=20 > - Does RADIUS dictionary software support the VSA format for 16 bits=2C 8 > bits=2C or both? >=20 > - How do you cleanly print or report VSAs when you do not know if the > field size is 8 or 16 bits? I realize that this situation already > exists since the format was never required to be followed=2C but > your new recommendation makes a potential problem much more likely > to appear. Previously=2C you could print something like Vendor =3D ACME= =2C > Code =3D 17=2C Contents =3D ABCDEF0011... Now you couldn't do that. >=20 > - Can a vendor who moved from 8 bits to 16 bits deal with this? >=20 > Comment: > I do agree that for functionality FOO=2C both the functionality itself > and the MIB=2C RADIUS=2C etc. work should take place in the same standard= s > body. However=2C Section 3.1 could have said a couple of additional thing= s > as well: >=20 > The issues of attribute space and choice of forum are distinct=3B there > is no reason why IETF couldn't use its own vendor code=2C for instance. >=20 > The section also does not mention one of the potential drawbacks of > SDO-driven development model: it is easy to come up with a number of > different solutions to the same generic problem=2C as opposed to finding > a common solution. >=20 --_5989cd6c-9f0f-4d1a-9380-9d85b57b9448_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for your comments.

Design Guidelines has a normative depende= ncy on the Extended Attributes document=2C which currently uses a 16-bit ve= ndor type field. =3B Given that Extended Attributes will require that R= ADIUS servers support a 16-bit vendor-type field for IETF-defined extended = attributes=2C it isn't much of a stretch to recommend that RADIUS servers s= upport a 16-bit type field for vendor and SDO-specific attributes as well= =2C since Extended Attributes is based on the VSA format.

The quest= ion is whether that recommendation belongs in this document=2C which is a B= CP=2C or whether it should go into the Extended Attributes document (Propos= ed Standard) instead=2C and just be referred to in Design Guidelines. = =3B Consolidating protocol changes into the Extended Attribute document mig= ht be cleaner=2C particularly since it is Extended Attributes that will pro= vide much of the motivation for vendors to add 16-bit vendor type support.<= br>
With respect to "replacement" of the 8-bit vendor-type field with a = 16-bit vendor type recommendation=2C my take on the text in 2.3 is that whi= le it recommends RADIUS server support for 16-bit vendor type fields=2C it = doesn't make a blanket recommendation that vendors adopt a 16-bit vendor ty= pe field in all situations=2C but rather points out situations in which use= of a 16-bit vendor type field would be appropriate:
   Note that the Vendor type field in the recommended VSA format is onl=
y
   a single octet=2C like the RADIUS type field.  While this limitatio=
n
   results in an efficient encoding=2C there are situations in which a=

   vendor or SDO will eventually wish to define more than 255
   att=
ributes.  Also=2C an SDO can be comprised of multiple subgroups=2C
   ea=
ch of whom can desire autonomy over the definition of attributes
   with=
in their group.  In such a situation=2C a 16-bit Vendor type field
   wo=
uld be more appropriate:

=


>=3B From: jari.arkko@pi= uha.net
>=3B To: iesg@ietf.org
>=3B CC: radext-chairs@tools.ietf.= org=3B draft-ietf-radext-design@tools.ietf.org=3B gdweber@gmail.com=3B alan= d@freeradius.org
>=3B Date: Thu=2C 7 May 2009 07:08:20 -0700
>=3B= Subject: DISCUSS and COMMENT: draft-ietf-radext-design
>=3B
>= =3B Discuss:
>=3B Great doc! I will vote Yes on it=2C but I wanted to = discuss two issues
>=3B first=2C one is a Discuss-level problem and th= e other one a Comment that
>=3B I'd like you to consider.
>=3B >=3B The first issue is that Section 2.3 suggests 16-bit vendor space>=3B attribute number fields to replace the existing 8-bit recommendati= on.
>=3B
>=3B There are a couple of problems with this. First=2C= if you really mean
>=3B to change the recommendation=2C then Updates:= RFC 2865 header in the
>=3B beginning of the document would have been= appropriate.
>=3B
>=3B Secondly=2C while I agree with the advic= e of going for 16 bits=2C the
>=3B document is silent on some of the i= ssues involved in such a change=2C
>=3B such as:
>=3B
>=3B = - Does RADIUS dictionary software support the VSA format for 16 bits=2C 8>=3B bits=2C or both?
>=3B
>=3B - How do you cleanly print= or report VSAs when you do not know if the
>=3B field size is 8 or = 16 bits? I realize that this situation already
>=3B exists since the= format was never required to be followed=2C but
>=3B your new recom= mendation makes a potential problem much more likely
>=3B to appear.= Previously=2C you could print something like Vendor =3D ACME=2C
>=3B = Code =3D 17=2C Contents =3D ABCDEF0011... Now you couldn't do that.
&g= t=3B
>=3B - Can a vendor who moved from 8 bits to 16 bits deal with t= his?
>=3B
>=3B Comment:
>=3B I do agree that for functional= ity FOO=2C both the functionality itself
>=3B and the MIB=2C RADIUS=2C= etc. work should take place in the same standards
>=3B body. However= =2C Section 3.1 could have said a couple of additional things
>=3B as = well:
>=3B
>=3B The issues of attribute space and choice of foru= m are distinct=3B there
>=3B is no reason why IETF couldn't use its ow= n vendor code=2C for instance.
>=3B
>=3B The section also does n= ot mention one of the potential drawbacks of
>=3B SDO-driven developme= nt model: it is easy to come up with a number of
>=3B different soluti= ons to the same generic problem=2C as opposed to finding
>=3B a common= solution.
>=3B
= --_5989cd6c-9f0f-4d1a-9380-9d85b57b9448_-- -- 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: Thu, 07 May 2009 17:54:59 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_994c2dae-769e-4f5e-8a8b-65677451b11d_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Strawman Virtual Interim agenda (+ proposed time/date) Date: Thu, 7 May 2009 10:54:16 -0700 MIME-Version: 1.0 --_994c2dae-769e-4f5e-8a8b-65677451b11d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is a strawman proposal for the virtual interim agenda=2C plus a potent= ial time/date.=20 Comments welcome.=20 RADEXT WG Virtual Interim Agenda Chairs: Bernard Aboba David Nelson Wednesday=2C June 10=2C 2009 9 AM - 11 AM PDT 9:00 AM - 10:00 AM RADIUS Crypto-agility Requirements http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements 10:00 AM - 11:00 AM Extended RADIUS Attributes http://tools.ietf.org/html/draft-ietf-radext-extended-attributes --_994c2dae-769e-4f5e-8a8b-65677451b11d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is a strawman proposal for the virtual interim agenda=2C plus a potent= ial time/date.

Comments welcome.

RADEXT WG Virtual Interim = Agenda

Chairs: Bernard Aboba <=3Bbernard_aboba@hotmail.com>=3BDavid Nelson <=3Bd.b.nelson@comcast.net>=3B

Wednesday=2C June = 10=2C 2009
9 AM - 11 AM PDT

9:00 AM - 10:00 AM RADIUS Crypto-agil= ity Requirements
http://tools.ietf.org/html/draft-ietf-radext-crypto-agi= lity-requirements

10:00 AM - 11:00 AM Extended RADIUS Attributes
= http://tools.ietf.org/html/draft-ietf-radext-extended-attributes


= --_994c2dae-769e-4f5e-8a8b-65677451b11d_-- -- 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: Thu, 07 May 2009 17:49:21 +0000 Message-ID: From: Bernard Aboba To: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: RE: Virtual interim meeting? Date: Thu, 7 May 2009 10:48:50 -0700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 -- 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: Thu, 07 May 2009 17:38:54 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_d61896ba-44d4-4902-9768-1e0742820d1f_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RE: Virtual meeting technology Date: Thu, 7 May 2009 10:37:52 -0700 MIME-Version: 1.0 --_d61896ba-44d4-4902-9768-1e0742820d1f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It looks like Teamspeak requires installation of client software=2C availab= le on Windows=2C MacOS X and Linux. How do people feel about that? In ex= change for the client software install requirement=2C the major advantage o= f Teamspeak (or SIP-based VOIP=2C for that matter) is the ability to bypass= the PSTN and associated charges.=20 For example=2C while Freeconference (http://www.freeconference.com/) offer= s free conference bridges=2C it does require the ability to reach the confe= rence call #=2C which could be an issue for people attending from outside t= he U.S. > From: Hannes.Tschofenig@gmx.net > To: Bernard_Aboba@hotmail.com=3B radiusext@ops.ietf.org > Subject: RE: Virtual meeting technology > Date: Thu=2C 7 May 2009 20:19:12 +0300 >=20 > The IPSECME group is using an open source tool from the gaming community= =2C > see http://www.teamspeak.com/.=20 >=20 > I like it when folks join the conference bridge and the server announces > "Player has joined".=20 >=20 > It does not provide slide sharing but that's OK. It does not allow folks = to > dial in via PSTN either... >=20 > Paul has downloaded the server software and installed it on his server. > Maybe you can re-use it.=20 >=20 > Ciao > Hannes >=20 > >-----Original Message----- > >From: owner-radiusext@ops.ietf.org=20 > >[mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > >Sent: 07 May=2C 2009 18:33 > >To: radiusext@ops.ietf.org > >Subject: Virtual meeting technology > > > >In terms of virtual meeting technology=2C there are a number of=20 > >services that provide free conferencing support.=20 > > > >One that I've looked at is DimDim ( http://www.dimdim.com/ )=2C=20 > >which is free for conferences of 20 users or less.=20 > > > >Has anyone used this (or any other) equivalent service? Any=20 > >recommendations?=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 --_d61896ba-44d4-4902-9768-1e0742820d1f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It looks like Teamspeak requires installation of client software=2C availab= le on Windows=2C MacOS X and Linux. =3B How do people feel about that?&= nbsp=3B =3B In exchange for the client software install requirement=2C = the major advantage of Teamspeak (or SIP-based VOIP=2C for that matter) is = the ability to bypass the PSTN and associated charges.

For example= =2C while Freeconference (http://www.freeconference.com/) =3B offers fr= ee conference bridges=2C it does require the ability to reach the conferenc= e call #=2C which could be an issue for people attending from outside the U= .S.





>=3B From: Hannes.Tschofenig@gmx.net>=3B To: Bernard_Aboba@hotmail.com=3B radiusext@ops.ietf.org
>=3B = Subject: RE: Virtual meeting technology
>=3B Date: Thu=2C 7 May 2009 2= 0:19:12 +0300
>=3B
>=3B The IPSECME group is using an open sourc= e tool from the gaming community=2C
>=3B see http://www.teamspeak.com= /.
>=3B
>=3B I like it when folks join the conference bridge an= d the server announces
>=3B "Player has joined".
>=3B
>=3B= It does not provide slide sharing but that's OK. It does not allow folks t= o
>=3B dial in via PSTN either...
>=3B
>=3B Paul has downlo= aded the server software and installed it on his server.
>=3B Maybe yo= u can re-use it.
>=3B
>=3B Ciao
>=3B Hannes
>=3B
= >=3B >=3B-----Original Message-----
>=3B >=3BFrom: owner-radiuse= xt@ops.ietf.org
>=3B >=3B[mailto:owner-radiusext@ops.ietf.org] On B= ehalf Of Bernard Aboba
>=3B >=3BSent: 07 May=2C 2009 18:33
>=3B= >=3BTo: radiusext@ops.ietf.org
>=3B >=3BSubject: Virtual meeting = technology
>=3B >=3B
>=3B >=3BIn terms of virtual meeting tec= hnology=2C there are a number of
>=3B >=3Bservices that provide fre= e conferencing support.
>=3B >=3B
>=3B >=3BOne that I've loo= ked at is DimDim ( http://www.dimdim.com/ )=2C
>=3B >=3Bwhich is f= ree for conferences of 20 users or less.
>=3B >=3B
>=3B >=3B= Has anyone used this (or any other) equivalent service? Any
>=3B >= =3Brecommendations?
>=3B >=3B
>=3B >=3B
>=3B >=3B-->=3B >=3Bto unsubscribe send a message to
>=3B >=3Bradiusext-= request@ops.ietf.org with the word 'unsubscribe' in
>=3B >=3Ba sing= le line as the message text body.
>=3B >=3Barchive: <=3Bhttp://psg= .com/lists/radiusext/>=3B
>=3B >=3B
>=3B
= --_d61896ba-44d4-4902-9768-1e0742820d1f_-- -- 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: Thu, 07 May 2009 17:18:23 +0000 From: "Hannes Tschofenig" To: "'Bernard Aboba'" , Subject: RE: Virtual meeting technology Date: Thu, 7 May 2009 20:19:12 +0300 Message-ID: <032601c9cf37$f10aaf50$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcnO8t16ZNUKrmACS3S+gc2QUDJHmgANeCNAAAOV6ZA= The IPSECME group is using an open source tool from the gaming community, see http://www.teamspeak.com/. I like it when folks join the conference bridge and the server announces "Player has joined". It does not provide slide sharing but that's OK. It does not allow folks to dial in via PSTN either... Paul has downloaded the server software and installed it on his server. Maybe you can re-use it. Ciao Hannes >-----Original Message----- >From: owner-radiusext@ops.ietf.org >[mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba >Sent: 07 May, 2009 18:33 >To: radiusext@ops.ietf.org >Subject: Virtual meeting technology > >In terms of virtual meeting technology, there are a number of >services that provide free conferencing support. > >One that I've looked at is DimDim ( http://www.dimdim.com/ ), >which is free for conferences of 20 users or less. > >Has anyone used this (or any other) equivalent service? Any >recommendations? > > >-- >to unsubscribe send a message to >radiusext-request@ops.ietf.org with the word 'unsubscribe' in >a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 07 May 2009 17:02:31 +0000 From: "David B. Nelson" To: Subject: RE: Virtual interim meeting? Date: Thu, 7 May 2009 13:01:36 -0400 Organization: Elbrys Networks, Inc. Message-ID: <73BE91277C2D49978A200A9A68EA5748@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcnO8t16ZNUKrmACS3S+gc2QUDJHmgANSW5gAAMt0CA= Bernard Aboba writes... > The first ones that come to mind are WG work items with the > longest "seniority", such as crypto-agility and extended > attributes. Both have been around a while, have been through > WG last call, but have issues remaining. I think an "IEEE-style" virtual interim meeting, in which we focus on creating document editing instructions, that is to say hammering out text, would be a useful and effective "forcing function" to get some of these items ready for IESG submission. It addresses the syndrome of not doing much work on drafts except in the two weeks before an IETF meeting. -- 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: Thu, 07 May 2009 15:47:51 +0000 Message-ID: From: "Bernard Aboba" To: "'Bernard Aboba'" , Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-design Date: Thu, 7 May 2009 08:47:09 -0700 Message-ID: <002501c9cf2b$14c61900$3e524b00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thread-Index: AcnPHYNDgKmQCJOwQ7WUOwpXFaMDxAACjhpgAAB6qfA= Content-Language: en-us Here is the normative language in Section 2.3: In order to be compatible with the above recommendations for attribute definitions, it is RECOMMENDED that RADIUS servers support attributes using a 16-bit Vendor type field. IMHO, this doesn't suggest replacing 8-bit with 16-bit vendor type = fields, only that RADIUS servers should support 16-bit as well.=20 Earlier text discusses the situations in which 16-bit vendor type fields = are needed: Note that the Vendor type field in the recommended VSA format is only a single octet, like the RADIUS type field. While this limitation results in an efficient encoding, there are situations in which a vendor or SDO will eventually wish to define more than 255 attributes. Also, an SDO can be comprised of multiple subgroups, each of whom can desire autonomy over the definition of attributes within their group. In such a situation, a 16-bit Vendor type field would be more appropriate... -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Thursday, May 07, 2009 7:08 AM To: iesg@ietf.org Cc: radext-chairs@tools.ietf.org; = draft-ietf-radext-design@tools.ietf.org; gdweber@gmail.com; = aland@freeradius.org Subject: DISCUSS and COMMENT: draft-ietf-radext-design=20 Discuss: Great doc! I will vote Yes on it, but I wanted to discuss two issues first, one is a Discuss-level problem and the other one a Comment that I'd like you to consider. The first issue is that Section 2.3 suggests 16-bit vendor space attribute number fields to replace the existing 8-bit recommendation. There are a couple of problems with this. First, if you really mean to change the recommendation, then Updates: RFC 2865 header in the beginning of the document would have been appropriate. Secondly, while I agree with the advice of going for 16 bits, the document is silent on some of the issues involved in such a change, such as: - Does RADIUS dictionary software support the VSA format for 16 bits, 8 bits, or both? - How do you cleanly print or report VSAs when you do not know if the field size is 8 or 16 bits? I realize that this situation already exists since the format was never required to be followed, but your new recommendation makes a potential problem much more likely to appear. Previously, you could print something like Vendor =3D ACME, Code =3D 17, Contents =3D ABCDEF0011... Now you couldn't do that. - Can a vendor who moved from 8 bits to 16 bits deal with this? Comment: I do agree that for functionality FOO, both the functionality itself and the MIB, RADIUS, etc. work should take place in the same standards body. However, Section 3.1 could have said a couple of additional things as well: The issues of attribute space and choice of forum are distinct; there is no reason why IETF couldn't use its own vendor code, for instance. The section also does not mention one of the potential drawbacks of SDO-driven development model: it is easy to come up with a number of different solutions to the same generic problem, as opposed to finding a common solution. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 07 May 2009 15:33:11 +0000 Message-ID: From: "Bernard Aboba" To: Subject: Virtual meeting technology Date: Thu, 7 May 2009 08:32:32 -0700 Message-ID: <002301c9cf29$0a43bcf0$1ecb36d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thread-Index: AcnO8t16ZNUKrmACS3S+gc2QUDJHmgANeCNA Content-Language: en-us In terms of virtual meeting technology, there are a number of services = that provide free conferencing support.=20 One that I've looked at is DimDim ( http://www.dimdim.com/ ), which is = free for conferences of 20 users or less.=20 Has anyone used this (or any other) equivalent service? Any = recommendations?=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: Thu, 07 May 2009 15:30:45 +0000 Message-ID: From: "Bernard Aboba" To: "'Alan DeKok'" Cc: Subject: RE: Virtual interim meeting? Date: Thu, 7 May 2009 08:30:20 -0700 Message-ID: <002201c9cf28$bb063f00$3112bd00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thread-Index: AcnO8t16ZNUKrmACS3S+gc2QUDJHmgANSW5g Content-Language: en-us Alan DeKok wrote: " I would attend one, but I don't know what the topic would be. The main barrier now to WG progress is document review and editing. There are a number of documents that need review, and I haven't had time yet to review them. I always dislike meetings where documents are wordsmithed to death, but this might be useful here. i.e. Schedule a meeting where a document is reviewed in detail. If we can get 3-4 participants who are *not* co-authors, that should be sufficient to make WG progress." Typically an interim meeting will have a narrower focus, so that = detailed review of one or more documents would be a possibility.=20 The question is what documents it would be useful to review in depth.=20 The first ones that come to mind are WG work items with the longest = "seniority", such as crypto-agility and extended attributes. Both have been around a = while,=20 have been through WG last call, but have issues remaining.=20 Suggestions welcome.=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: Thu, 07 May 2009 15:24:28 +0000 Message-ID: From: "Bernard Aboba" To: Subject: FW: DISCUSS and COMMENT: draft-ietf-radext-design Date: Thu, 7 May 2009 08:23:28 -0700 Message-ID: <001b01c9cf27$c59c0360$50d40a20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thread-Index: AcnPHYNDgKmQCJOwQ7WUOwpXFaMDxAACjhpg Content-Language: en-us -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Thursday, May 07, 2009 7:08 AM To: iesg@ietf.org Cc: radext-chairs@tools.ietf.org; = draft-ietf-radext-design@tools.ietf.org; gdweber@gmail.com; = aland@freeradius.org Subject: DISCUSS and COMMENT: draft-ietf-radext-design=20 Discuss: Great doc! I will vote Yes on it, but I wanted to discuss two issues first, one is a Discuss-level problem and the other one a Comment that I'd like you to consider. The first issue is that Section 2.3 suggests 16-bit vendor space attribute number fields to replace the existing 8-bit recommendation. There are a couple of problems with this. First, if you really mean to change the recommendation, then Updates: RFC 2865 header in the beginning of the document would have been appropriate. Secondly, while I agree with the advice of going for 16 bits, the document is silent on some of the issues involved in such a change, such as: - Does RADIUS dictionary software support the VSA format for 16 bits, 8 bits, or both? - How do you cleanly print or report VSAs when you do not know if the field size is 8 or 16 bits? I realize that this situation already exists since the format was never required to be followed, but your new recommendation makes a potential problem much more likely to appear. Previously, you could print something like Vendor =3D ACME, Code =3D 17, Contents =3D ABCDEF0011... Now you couldn't do that. - Can a vendor who moved from 8 bits to 16 bits deal with this? Comment: I do agree that for functionality FOO, both the functionality itself and the MIB, RADIUS, etc. work should take place in the same standards body. However, Section 3.1 could have said a couple of additional things as well: The issues of attribute space and choice of forum are distinct; there is no reason why IETF couldn't use its own vendor code, for instance. The section also does not mention one of the potential drawbacks of SDO-driven development model: it is easy to come up with a number of different solutions to the same generic problem, as opposed to finding a common solution. -- 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: Thu, 07 May 2009 10:34:44 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CEFF.49ECF84F" Subject: RE: Virtual interim meeting? Date: Thu, 7 May 2009 12:33:40 +0200 Message-ID: Thread-Topic: Virtual interim meeting? Thread-Index: AcnOhamXLC0my+1KTWSAnMsnHrcIyQAeYRHA From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C9CEFF.49ECF84F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would attend.=20 =20 Dan =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Wednesday, May 06, 2009 11:03 PM To: radiusext@ops.ietf.org Subject: Virtual interim meeting? =09 =09 A number of IETF WGs are now scheduling "virtual interim" meetings. For example, ECRIT scheduled such a meeting in the fall: http://trac.tools.ietf.org/wg/ecrit/trac/wiki =20 We are wondering whether RADEXT WG participants would be interested in participating in such a "virtual interim" meeting, and if so, how many of you would potentially attend.=20 =20 Typical facilities provided through services such as DimDim include audio conferencing, chat and presentation sharing.=20 ------_=_NextPart_001_01C9CEFF.49ECF84F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 would attend.
 
Dan
 

From: owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Wednesday, May 06, 2009 11:03 PM
To:=20 radiusext@ops.ietf.org
Subject: Virtual interim=20 meeting?

A number of IETF WGs are now scheduling = “virtual interim”=20 meetings.   For example, ECRIT scheduled such a meeting in = the=20 fall:

http://trac.tools.= ietf.org/wg/ecrit/trac/wiki

 

We are wondering whether RADEXT WG participants = would be=20 interested in participating in such a “virtual interim” = meeting, and if so,=20 how many of you would potentially attend.

 

Typical facilities provided through services such = as DimDim include audio conferencing, = chat and=20 presentation sharing.

------_=_NextPart_001_01C9CEFF.49ECF84F-- -- 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: Thu, 07 May 2009 09:00:44 +0000 Message-ID: <4A02A2E9.7050600@deployingradius.com> Date: Thu, 07 May 2009 10:59:21 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Virtual interim meeting? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bernard Aboba wrote: > We are wondering whether RADEXT WG participants would be interested in > participating in such a “virtual interim” meeting, and if so, how many > of you would potentially attend. I would attend one, but I don't know what the topic would be. The main barrier now to WG progress is document review and editing. There are a number of documents that need review, and I haven't had time yet to review them. I always dislike meetings where documents are wordsmithed to death, but this might be useful here. i.e. Schedule a meeting where a document is reviewed in detail. If we can get 3-4 participants who are *not* co-authors, that should be sufficient to make WG progress. 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: Wed, 06 May 2009 20:04:04 +0000 Message-ID: From: "Bernard Aboba" To: Subject: Virtual interim meeting? Date: Wed, 6 May 2009 13:03:03 -0700 Message-ID: <006701c9ce85$a9c2add0$fd480970$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01C9CE4A.FD63D5D0" Thread-Index: AcnOhamXLC0my+1KTWSAnMsnHrcIyQ== Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0068_01C9CE4A.FD63D5D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit A number of IETF WGs are now scheduling "virtual interim" meetings. For example, ECRIT scheduled such a meeting in the fall: http://trac.tools.ietf.org/wg/ecrit/trac/wiki We are wondering whether RADEXT WG participants would be interested in participating in such a "virtual interim" meeting, and if so, how many of you would potentially attend. Typical facilities provided through services such as DimDim include audio conferencing, chat and presentation sharing. ------=_NextPart_000_0068_01C9CE4A.FD63D5D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A number of IETF WGs are now scheduling = “virtual interim” meetings.   For example, ECRIT scheduled such a = meeting in the fall:

http://trac.tools.= ietf.org/wg/ecrit/trac/wiki

 

We are wondering whether RADEXT WG participants = would be interested in participating in such a “virtual interim” = meeting, and if so, how many of you would potentially attend.

 

Typical facilities provided through services such = as DimDim include audio conferencing, = chat and presentation sharing.

------=_NextPart_000_0068_01C9CE4A.FD63D5D0-- -- 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, 06 May 2009 14:39:35 +0000 Message-ID: <4A01A0C3.9010807@deployingradius.com> Date: Wed, 06 May 2009 16:37:55 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Phillip Hallam-Baker , 'radext mailing list' CC: secdir@ietf.org, gdweber@gmail.com Subject: Re: Review of draft-ietf-radext-design-07 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Phillip Hallam-Baker wrote: > As always with Radius documents it is somewhat hard to do a security > review of a security protocol that admits that the protocol does not > offer security. I agree. However... we are working with a legacy protocol here. > While the security is provided through layering on another protocol > (e.g. IPSEC), the mix and match approach is unsatisfactory. Security > is a property of a system. It is really not possible to analyze the > security of a system when one half of the system is unspecified. While it is not part of this document, the WG is working on RADIUS over TLS / DTLS. These specifications should improve the security of the protocol. > The Security Considerations section is adequate and given the purpose > of this draft it is appropriate to cite external documents where the > security issues are discussed in detail rather than repeat the caveats > here. But the question does have to be asked why we have so many > security caveats in what is a foundational security protocol. Historical practice, and the cost of upgrade. When the new TLS-based documents are approved, we expect that they will be the preferred approach for RADIUS transport. > While IPSEC security is certainly adequate for some applications, I > have a really hard time accepting it as the security layer for a > foundational security protocol. I prefer basic authentication and > authorization protocols to have security built in. In particular I > want to know what happens at the RADIUS protocol level when there is > an error at the IPSEC layer or vice versa. IPSEC is not secure against > active attack unless error conditions are appropriately handled. I agree. However, it's outside of the scope of this document. 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: