From owner-radiusext@ops.ietf.org Fri Oct 2 03:36:33 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 CFF2F3A67A3 for ; Fri, 2 Oct 2009 03:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[AWL=-0.921, 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 OmZcTCBTv82s for ; Fri, 2 Oct 2009 03:36:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D6F053A6825 for ; Fri, 2 Oct 2009 03:36:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtfRH-0009gy-CR for radiusext-data0@psg.com; Fri, 02 Oct 2009 10:32:39 +0000 Received: from [198.152.13.100] (helo=co300216-co-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MtfR8-0009g7-50 for radiusext@ops.ietf.org; Fri, 02 Oct 2009 10:32:37 +0000 X-IronPort-AV: E=Sophos;i="4.44,493,1249272000"; d="scan'208";a="185388286" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Oct 2009 06:32:22 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Oct 2009 06:32:22 -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: FW: Need for WebEx at IETF 76 Date: Fri, 2 Oct 2009 12:32:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for WebEx at IETF 76 thread-index: AcpC62cK+Vp4d9meScWEUESp+2mT7QAXlQ/Q From: "Romascanu, Dan (Dan)" To: , "OPS Area (E-mail)" , "radext mailing list" , , , , "IETF IPFIX Working Group" Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Alexa Morris Sent: Friday, October 02, 2009 1:03 AM To: The IESG Subject: Need for WebEx at IETF 76 I'd like to know if any of you might need to use WebEx for any working group sessions taking place at IETF 76. Please note that at present I'm looking more for a "I need WebEx because one of my key presenters will not be physically present"=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 4 12:08: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 8189B28C10E for ; Sun, 4 Oct 2009 12:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.424 X-Spam-Level: * X-Spam-Status: No, score=1.424 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_50=0.001, 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 MGKsAGcyNT00 for ; Sun, 4 Oct 2009 12:08:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE47928C0E1 for ; Sun, 4 Oct 2009 12:08:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuWOh-0008ZR-Mj for radiusext-data0@psg.com; Sun, 04 Oct 2009 19:05:31 +0000 Received: from [65.55.116.30] (helo=blu0-omc1-s19.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuWOY-0008Ys-J8 for radiusext@ops.ietf.org; Sun, 04 Oct 2009 19:05:29 +0000 Received: from BLU137-W2 ([65.55.116.7]) by blu0-omc1-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Oct 2009 12:05:22 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_67fc6fee-6279-4b28-a0e0-be3aa7fed4fc_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Draft updates and slides Date: Sun, 4 Oct 2009 12:05:21 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 04 Oct 2009 19:05:22.0352 (UTC) FILETIME=[9F60FB00:01CA4525] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_67fc6fee-6279-4b28-a0e0-be3aa7fed4fc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In advance of the Virtual Interim meeting on October 13=2C we are asking fo= r authors to update their drafts and send in their slides=2C so that we can make them available for m= eeting participants.=20 Please submit updates to your drafts as well as slides by October 11=2C 200= 9.=20 = --_67fc6fee-6279-4b28-a0e0-be3aa7fed4fc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In advance of the Virtual Interim meeting on October 13=2C we are asking fo= r authors to update their
drafts and send in their slides=2C so that we = can make them available for meeting participants.

Please submit upd= ates to your drafts as well as slides by October 11=2C 2009.



= --_67fc6fee-6279-4b28-a0e0-be3aa7fed4fc_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Oct 5 08:06:06 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 EE30A3A695D for ; Mon, 5 Oct 2009 08:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=-0.455, 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 kxwhcCjHNolU for ; Mon, 5 Oct 2009 08:06:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CDBAE3A6873 for ; Mon, 5 Oct 2009 08:06:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mup5F-000LCM-O1 for radiusext-data0@psg.com; Mon, 05 Oct 2009 15:02:41 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mup56-000L9t-Kr for radiusext@ops.ietf.org; Mon, 05 Oct 2009 15:02:40 +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 2EE9212344AA; Mon, 5 Oct 2009 17:02:31 +0200 (CEST) Message-ID: <4ACA0A86.3020303@deployingradius.com> Date: Mon, 05 Oct 2009 17:02:30 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: IPv6 References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > How about this? ... > For these reasons, the tagging scheme described in RFC 2868 is > not suitable for use as a generic grouping mechanism. Where > a tagging scheme is required for use with arbitrary data types, > it is RECOMMENDED that: > > * A fixed tagging field be used so as to remove potential > interoperability issues associated with determining whether > an optional tag is present; > > * The design make no assumption about the content of the > data within tagged attributes." Hmm... OK. This sounds an awful lot like making recommendations on later RADEXT documents. I'm not sure that's useful. The alternative is to interpret this as recommending a new data type: tagged attributes with a format defined outside of RADEXT. I'm not sure I like that much better. 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 Oct 5 10:52:48 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 2F05028C213 for ; Mon, 5 Oct 2009 10:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.316 X-Spam-Level: * X-Spam-Status: No, score=1.316 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, 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 jXNvrNnSsIC4 for ; Mon, 5 Oct 2009 10:52:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3CA1E3A6947 for ; Mon, 5 Oct 2009 10:52:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Muri5-000BgF-NM for radiusext-data0@psg.com; Mon, 05 Oct 2009 17:50:57 +0000 Received: from [65.55.111.111] (helo=blu0-omc2-s36.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Murhv-000Bef-KI for radiusext@ops.ietf.org; Mon, 05 Oct 2009 17:50:55 +0000 Received: from BLU137-W33 ([65.55.111.71]) by blu0-omc2-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 10:50:47 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_29c902fa-2703-4a91-a23a-e44cdffed479_" X-Originating-IP: [131.107.0.75] From: Bernard Aboba To: Alan DeKok CC: "radiusext@ops.ietf.org" Subject: RE: IPv6 Date: Mon, 5 Oct 2009 10:50:46 -0700 Importance: Normal In-Reply-To: <4ACA0A86.3020303@deployingradius.com> References: X-OriginalArrivalTime: 05 Oct 2009 17:50:47.0041 (UTC) FILETIME=[5E4C7710:01CA45E4] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: <4ACA0A86.3020303@deployingradius.com> MIME-Version: 1.0 --_29c902fa-2703-4a91-a23a-e44cdffed479_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > For these reasons=2C the tagging scheme described in RFC 2868 is > > not suitable for use as a generic grouping mechanism. Where > > a tagging scheme is required for use with arbitrary data types=2C > > it is RECOMMENDED that: > > =20 > > * A fixed tagging field be used so as to remove potential > > interoperability issues associated with determining whether > > an optional tag is present=3B=20 > >=20 > > * The design make no assumption about the content of the > > data within tagged attributes." =20 >=20 > Hmm... OK. This sounds an awful lot like making recommendations on > later RADEXT documents. I'm not sure that's useful. Assuming that the first sentence makes sense=2C the next question that a reader will ask is "What is the alternative?" =20 > The alternative is to interpret this as recommending a new data type: > tagged attributes with a format defined outside of RADEXT. I'm not sure > I like that much better. Given that existing tagged types are not suitable for generic use=2C there doesn't seem to be an alternative to a new data type. The question is what this document can or should say about that.=20 While the Extended Attributes document is probably the right place to deal with this issue in depth=2C the question is whether something can be said in the Design Guidelines document=2C and if so=2C what.=20 = --_29c902fa-2703-4a91-a23a-e44cdffed479_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B >=3B For these reasons=2C the tagging scheme described in R= FC 2868 is
>=3B >=3B not suitable for use as a generic grouping m= echanism. Where
>=3B >=3B a tagging scheme is required for use w= ith arbitrary data types=2C
>=3B >=3B it is RECOMMENDED that:
= >=3B >=3B
>=3B >=3B * A fixed tagging field be us= ed so as to remove potential
>=3B >=3B interoperability is= sues associated with determining whether
>=3B >=3B an opti= onal tag is present=3B
>=3B >=3B
>=3B >=3B * The de= sign make no assumption about the content of the
>=3B >=3B = data within tagged attributes."
>=3B
>=3B Hmm... OK. This = sounds an awful lot like making recommendations on
>=3B later RADEXT d= ocuments. I'm not sure that's useful.

Assuming that the first sente= nce makes sense=2C the next question that
a reader will ask is "What is = the alternative?" =3B

>=3B The alternative is to interpret = this as recommending a new data type:
>=3B tagged attributes with a fo= rmat defined outside of RADEXT. I'm not sure
>=3B I like that much be= tter.

Given that existing tagged types are not suitable for generic = use=2C =3B there
doesn't seem to be an alternative to a new data typ= e. =3B The question is
what this document can or should say about th= at.

While the Extended Attributes document is probably the right pl= ace to
deal with this issue in depth=2C the question is whether somethin= g can
be said in the Design Guidelines document=2C and if so=2C what.

= --_29c902fa-2703-4a91-a23a-e44cdffed479_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Oct 5 15:04:20 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 71E703A6A38 for ; Mon, 5 Oct 2009 15:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.147 X-Spam-Level: X-Spam-Status: No, score=0.147 tagged_above=-999 required=5 tests=[AWL=0.642, 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 YGX8Yo2e9xJP for ; Mon, 5 Oct 2009 15:04:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AD6923A6A4C for ; Mon, 5 Oct 2009 15:04:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuvbE-000GNm-VK for radiusext-data0@psg.com; Mon, 05 Oct 2009 22:00:08 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Muvb4-000GKL-1k for radiusext@ops.ietf.org; Mon, 05 Oct 2009 22:00:06 +0000 Received: (qmail 23686 invoked from network); 5 Oct 2009 21:59:49 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 5 Oct 2009 21:59:49 -0000 Message-Id: From: "David B. Nelson" To: radiusext@ops.ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: IPv6 Date: Mon, 5 Oct 2009 17:59:49 -0400 References: X-Mailer: Apple Mail (2.936) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: On Oct 5, 2009, at 1:50 PM, Bernard Aboba wrote: > While the Extended Attributes document is probably the right place to > deal with this issue in depth, the question is whether something can > be said in the Design Guidelines document, and if so, what. This sounds like we're coming full circle. I think where we started was with the Design Guidelines for "RADIUS Classic" directing developers who wanted to make effective use tagging to the Extended RADIUS Attributes draft / RFC. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Oct 5 15:36: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 7A81728C20B for ; Mon, 5 Oct 2009 15:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[AWL=-1.187, BAYES_05=-1.11, 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 ur9Y8d26ASmo for ; Mon, 5 Oct 2009 15:36:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 931853A677E for ; Mon, 5 Oct 2009 15:36:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Muw9C-000Jhu-LW for radiusext-data0@psg.com; Mon, 05 Oct 2009 22:35:14 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Muw93-000Jgf-B7 for radiusext@ops.ietf.org; Mon, 05 Oct 2009 22:35:12 +0000 Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 4CD5012344AA; Tue, 6 Oct 2009 00:35:03 +0200 (CEST) Message-ID: <4ACA7496.60208@deployingradius.com> Date: Tue, 06 Oct 2009 00:35:02 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: IPv6 References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > Given that existing tagged types are not suitable for generic use, there > doesn't seem to be an alternative to a new data type. The question is > what this document can or should say about that. I agree with David. It should stick to recommended practices, and not define new standards. > While the Extended Attributes document is probably the right place to > deal with this issue in depth, the question is whether something can > be said in the Design Guidelines document, and if so, what. It should say what's bad about the current tags, and leave it to later documents to decide how to fix them. 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 Oct 5 18:19:36 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 4650B3A6915 for ; Mon, 5 Oct 2009 18:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.692 X-Spam-Level: * X-Spam-Status: No, score=1.692 tagged_above=-999 required=5 tests=[AWL=-0.974, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, 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 qbUexB2EsHb9 for ; Mon, 5 Oct 2009 18:19:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 713303A689A for ; Mon, 5 Oct 2009 18:19:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Muyhb-0008YV-LZ for radiusext-data0@psg.com; Tue, 06 Oct 2009 01:18:55 +0000 Received: from [65.55.111.96] (helo=blu0-omc2-s21.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MuyhS-0008Xp-Cq for radiusext@ops.ietf.org; Tue, 06 Oct 2009 01:18:53 +0000 Received: from BLU137-W3 ([65.55.111.71]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 18:18:45 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3b3aeb65-c11f-4af3-ae9c-8e0a3b08d4bd_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Alan DeKok , "radiusext@ops.ietf.org" Subject: RE: IPv6 Date: Mon, 5 Oct 2009 18:18:45 -0700 Importance: Normal In-Reply-To: <4ACA7496.60208@deployingradius.com> References: X-OriginalArrivalTime: 06 Oct 2009 01:18:45.0838 (UTC) FILETIME=[F34F66E0:01CA4622] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: <4ACA7496.60208@deployingradius.com> MIME-Version: 1.0 --_3b3aeb65-c11f-4af3-ae9c-8e0a3b08d4bd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It should say what's bad about the current tags=2C and leave it to late= r > documents to decide how to fix them. One approach might be to say just that: "For these reasons=2C the tagging scheme described in RFC 2868 is not suitable for use as a generic grouping mechanism. Further guidance in this area is left to future documents." = --_3b3aeb65-c11f-4af3-ae9c-8e0a3b08d4bd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B It should say what's bad about the current tags=2C and leave it to= later
>=3B documents to decide how to fix them.

One approach m= ight be to say just that:

"For these reasons=2C the tagging scheme d= escribed in RFC 2868 is
not suitable for use as a generic grouping mecha= nism. =3B =3B Further
guidance in this area is left to future do= cuments."
= --_3b3aeb65-c11f-4af3-ae9c-8e0a3b08d4bd_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 6 07:25:22 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 093CD3A690F for ; Tue, 6 Oct 2009 07:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[AWL=-0.425, 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 kzlJtabWYwO8 for ; Tue, 6 Oct 2009 07:25:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE8BB3A68F3 for ; Tue, 6 Oct 2009 07:25:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvAvw-000Emx-EX for radiusext-data0@psg.com; Tue, 06 Oct 2009 14:22:32 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvAvm-000Elt-Di for radiusext@ops.ietf.org; Tue, 06 Oct 2009 14:22:30 +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 6103412344AA; Tue, 6 Oct 2009 16:22:18 +0200 (CEST) Message-ID: <4ACB529A.50702@deployingradius.com> Date: Tue, 06 Oct 2009 16:22:18 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: IPv6 References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: >> It should say what's bad about the current tags, and leave it to later >> documents to decide how to fix them. > > One approach might be to say just that: > > "For these reasons, the tagging scheme described in RFC 2868 is > not suitable for use as a generic grouping mechanism. Further > guidance in this area is left to future documents." Sounds good to me. I'll see if I can rev the document this week. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 6 07:29: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 22B743A6848 for ; Tue, 6 Oct 2009 07:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=-0.414, 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 b5Q3yy+CWq5n for ; Tue, 6 Oct 2009 07:29:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1700D3A68F8 for ; Tue, 6 Oct 2009 07:29:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvB0r-000FSE-3B for radiusext-data0@psg.com; Tue, 06 Oct 2009 14:27:37 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvB0f-000FOV-FZ for radiusext@ops.ietf.org; Tue, 06 Oct 2009 14:27:34 +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 3BD8312344AA; Tue, 6 Oct 2009 16:27:24 +0200 (CEST) Message-ID: <4ACB53CB.2000606@deployingradius.com> Date: Tue, 06 Oct 2009 16:27:23 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: Jari Arkko , "dromasca@avaya.com" , gdweber@avaya.com, "David B. Nelson" , "radiusext@ops.ietf.org" Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt References: <4A9D3578.6090908@deployingradius.com> <4AAE26D4.9080607@piuha.net> <4AB0B100.5000602@deployingradius.com> <4AB20A1C.906@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > How about this? > > All VSA schemes that do not follow the [RFC2865] recommendations > are NOT RECOMMENDED since these formats will typically not be > implementable without RADIUS server code changes. This includes all > the above formats, as well as Vendor types of more than 8 bits, vendor > lengths of less than 8 bits, vendor lengths of more than 8 bits and > Vendor-Specific contents that are not in Type-Length-Value format. Looks good to me. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 6 07:30:10 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 2DF673A693E for ; Tue, 6 Oct 2009 07:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=-0.404, 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 Mdp1gxtgxaA5 for ; Tue, 6 Oct 2009 07:30:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 002CE3A68F8 for ; Tue, 6 Oct 2009 07:30:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvB2r-000Fh0-4M for radiusext-data0@psg.com; Tue, 06 Oct 2009 14:29:41 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvB2S-000Fcl-91 for radiusext@ops.ietf.org; Tue, 06 Oct 2009 14:29:30 +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 2ABC512344AA; Tue, 6 Oct 2009 16:29:15 +0200 (CEST) Message-ID: <4ACB543A.3010904@deployingradius.com> Date: Tue, 06 Oct 2009 16:29:14 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: Jari Arkko , "dromasca@avaya.com" , gdweber@avaya.com, "David B. Nelson" , "radiusext@ops.ietf.org" Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt References: <4A9D3578.6090908@deployingradius.com> <4AAE26D4.9080607@piuha.net> <4AB0B100.5000602@deployingradius.com> <4AB20A1C.906@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > How about this? > > "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. The most interoperable way to address these > issues is for the vendor or SDO to request allocation of multiple > Vendor identifiers. > > However, instead of doing this, vendors have defined the following > non-standard VSA formats:" Looks good to me. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 6 07:45:11 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 AD1533A6848 for ; Tue, 6 Oct 2009 07:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[AWL=0.589, 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 8XDxSM5WHO1k for ; Tue, 6 Oct 2009 07:45:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD59D3A6953 for ; Tue, 6 Oct 2009 07:45:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvBFv-000HJi-P6 for radiusext-data0@psg.com; Tue, 06 Oct 2009 14:43:11 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvBFl-000HID-EX for radiusext@ops.ietf.org; Tue, 06 Oct 2009 14:43:09 +0000 Received: (qmail 1857 invoked from network); 6 Oct 2009 14:42:51 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 6 Oct 2009 14:42:51 -0000 Message-Id: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> From: "David B. Nelson" To: radiusext@ops.ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: IPv6 Date: Tue, 6 Oct 2009 10:42:51 -0400 References: X-Mailer: Apple Mail (2.936) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: On Oct 5, 2009, at 9:18 PM, Bernard Aboba wrote: > > It should say what's bad about the current tags, and leave it to > later > > documents to decide how to fix them. > > One approach might be to say just that: > > "For these reasons, the tagging scheme described in RFC 2868 is > not suitable for use as a generic grouping mechanism. Further > guidance in this area is left to future documents." All of this dancing around, simply to avoid a non-normative reference to the RADIUS Extended Attributes document? Why? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 6 07:56:32 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 C50063A682D for ; Tue, 6 Oct 2009 07:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[AWL=-0.394, 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 3k+RePcwYv0R for ; Tue, 6 Oct 2009 07:56:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F3A2A28C188 for ; Tue, 6 Oct 2009 07:56:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvBR0-000JLH-QM for radiusext-data0@psg.com; Tue, 06 Oct 2009 14:54:38 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvBQr-000JHD-QG for radiusext@ops.ietf.org; Tue, 06 Oct 2009 14:54:37 +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 E31E612344AA; Tue, 6 Oct 2009 16:54:28 +0200 (CEST) Message-ID: <4ACB5A24.1000400@deployingradius.com> Date: Tue, 06 Oct 2009 16:54:28 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: IPv6 References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> In-Reply-To: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: David B. Nelson wrote: > All of this dancing around, simply to avoid a non-normative reference to > the RADIUS Extended Attributes document? Why? It doesn't matter too much to me. But I don't see a need to reference future documents, when those documents can simply state that they update this one. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 6 08:01:02 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 925523A67F7 for ; Tue, 6 Oct 2009 08:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fspxiqnrkBjS for ; Tue, 6 Oct 2009 08:01:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B930D3A67A1 for ; Tue, 6 Oct 2009 08:01:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvBVh-000K5e-Uc for radiusext-data0@psg.com; Tue, 06 Oct 2009 14:59:29 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvBVX-000K4V-TT for radiusext@ops.ietf.org; Tue, 06 Oct 2009 14:59:28 +0000 Received: (qmail 2568 invoked from network); 6 Oct 2009 14:59:17 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 6 Oct 2009 14:59:17 -0000 Cc: radiusext@ops.ietf.org Message-Id: <4A71C395-DEAB-41C0-A94F-09A68A0A28D5@elbrysnetworks.com> From: "David B. Nelson" To: Alan DeKok In-Reply-To: <4ACB5A24.1000400@deployingradius.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: IPv6 Date: Tue, 6 Oct 2009 10:59:17 -0400 References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> X-Mailer: Apple Mail (2.936) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: On Oct 6, 2009, at 10:54 AM, Alan DeKok wrote: > ...I don't see a need to reference future documents, when those > documents can simply state that they update this one. True. OTOH, I don't see any need to be coy about "future documents" when we know exactly what document we're talking about and exactly what it recommends. Often the best approach is the most straightforward approach. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 6 08:33:02 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 E977528C171 for ; Tue, 6 Oct 2009 08:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, 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 a8w2tjSb82zZ for ; Tue, 6 Oct 2009 08:33:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2756C3A69EA for ; Tue, 6 Oct 2009 08:33:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvC0g-000Nk2-W2 for radiusext-data0@psg.com; Tue, 06 Oct 2009 15:31:30 +0000 Received: from [65.55.111.105] (helo=blu0-omc2-s30.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvC0X-000NjK-CL for radiusext@ops.ietf.org; Tue, 06 Oct 2009 15:31:28 +0000 Received: from BLU137-W11 ([65.55.111.71]) by blu0-omc2-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 08:31:21 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_41e262d3-b06b-40b9-999e-c137d002c02b_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: "David B. Nelson" , Alan DeKok CC: "radiusext@ops.ietf.org" Subject: RE: IPv6 Date: Tue, 6 Oct 2009 08:31:21 -0700 Importance: Normal In-Reply-To: <4A71C395-DEAB-41C0-A94F-09A68A0A28D5@elbrysnetworks.com> References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> X-OriginalArrivalTime: 06 Oct 2009 15:31:21.0144 (UTC) FILETIME=[0E3FA380:01CA469A] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: <4A71C395-DEAB-41C0-A94F-09A68A0A28D5@elbrysnetworks.com> MIME-Version: 1.0 --_41e262d3-b06b-40b9-999e-c137d002c02b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > True. OTOH=2C I don't see any need to be coy about "future documents" =20 > when we know exactly what document we're talking about and exactly =20 > what it recommends. Often the best approach is the most =20 > straightforward approach. Do we know exactly which document we're talking about? Both the IPv6 document and Extended Attributes define tagging schemes.=20 = --_41e262d3-b06b-40b9-999e-c137d002c02b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B True. OTOH=2C I don't see any need to be coy about "future docu= ments"
>=3B when we know exactly what document we're talking about a= nd exactly
>=3B what it recommends. Often the best approach is the = most
>=3B straightforward approach.

Do we know exactly which = document we're talking about? =3B Both the
IPv6 document and Extende= d Attributes define tagging schemes.

= --_41e262d3-b06b-40b9-999e-c137d002c02b_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 6 09:56:37 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 7B5EE3A68A8 for ; Tue, 6 Oct 2009 09:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.859 X-Spam-Level: X-Spam-Status: No, score=-8.859 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 oz-sruc5dUPR for ; Tue, 6 Oct 2009 09:56:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 321633A6804 for ; Tue, 6 Oct 2009 09:56:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvDJZ-0007gV-2j for radiusext-data0@psg.com; Tue, 06 Oct 2009 16:55:05 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvDJO-0007dg-JG for radiusext@ops.ietf.org; Tue, 06 Oct 2009 16:55:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=3560; q=dns/txt; s=amsiport01001; t=1254848094; x=1256057694; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20IPv6|Date:=20Tue,=206=20Oct=202009=2018 :54:46=20+0200|Message-ID:=20|To:=20"Bernard=20Aboba "=20,=0D=0A=20=20=20=20=20=20 =20=20"David=20B.=20Nelson"=20,=0D=0A=20=20=20=20=20=20=20=20"Alan=20DeKok"=20|Cc:=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20=20=20=20 =20<9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.c om>=20<4ACB5A24.1000400@deployingradius.com>=20; bh=wq4WmOvXymyLivyiJguu+4CxmdwmLxwlxexaCMgv/lo=; b=VPPP6/lC4jUpiC/gFKf/AsTM5tLlwrfGYkG3bg44W0GF4J6aEc4ei3KV 07r33mbPPK9d/U8Uku0vGLVKFYk90nym46T4DMUPAdaqFut5aguMVOKPx kDf4I/KvAwZYD1C+6qBC+4SWE8o4LoNLXLRHhTmLDlp+C9KMpRkzbbCpe E=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (partially verified [3499 bytes] [TEST]) header.i=wdec@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEAAAYTy0qQ/uCKe2dsb2JhbACCJy2YJAEBFiQGoCmIYwGPJQaEKoFX X-IronPort-AV: E=Sophos;i="4.44,513,1249257600"; d="scan'208,217";a="51105230" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Oct 2009 16:54:52 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n96Gsq9k004189; Tue, 6 Oct 2009 18:54:52 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n96Gsqou021898; Tue, 6 Oct 2009 16:54:52 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 18:54:52 +0200 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_01CA46A5.B936BA37" Subject: RE: IPv6 Date: Tue, 6 Oct 2009 18:54:46 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Thread-Index: AcpGmimNmHL4XJmDSkmkFVc1VhiTrAAAUplQ References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> From: "Wojciech Dec (wdec)" To: "Bernard Aboba" , "David B. Nelson" , "Alan DeKok" Cc: X-OriginalArrivalTime: 06 Oct 2009 16:54:52.0356 (UTC) FILETIME=[B929E840:01CA46A5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3499; t=1254848092; x=1255712092; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20IPv6 |Sender:=20; bh=A+sqFbd66jmbYD//pVVaIN0cvpjhaXTb9lkcY8AtQpE=; b=YbKMD421H8Z5nGux28eNrcNy6B9a5JvhDLrkCQrGPIST8awm5fO86cr3cC Oe57ZXFq/atIL211BN8hy+YLhTqJ/i7vPgyDrHpmM2oOPw42M38d19xTUAIo ctgN+i/qLW; Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA46A5.B936BA37 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: 06 October 2009 17:31 To: David B. Nelson; Alan DeKok Cc: radiusext@ops.ietf.org Subject: RE: IPv6 =09 =09 > True. OTOH, I don't see any need to be coy about "future documents"=20 > when we know exactly what document we're talking about and exactly=20 > what it recommends. Often the best approach is the most=20 > straightforward approach. =09 Do we know exactly which document we're talking about? Both the IPv6 document and Extended Attributes define tagging schemes. =20 =20 Woj> Indeed... What's the IPv6 document being referred to here? If it happens to be draft-lourdelet-radext-ipv6-access, then it does not define any new tagging scheme. =09 =09 - Woj.=20 =09 =09 ------_=_NextPart_001_01CA46A5.B936BA37 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: 06 October 2009 17:31
To: David B. = Nelson;=20 Alan DeKok
Cc: radiusext@ops.ietf.org
Subject: RE: = IPv6


> True. OTOH, I don't see any need to be coy about "future = documents"
> when we know exactly what document we're talking = about and=20 exactly
> what it recommends. Often the best approach is the = most=20
> straightforward approach.

Do we know exactly which = document=20 we're talking about?  Both the
IPv6 document and Extended = Attributes=20 define tagging schemes.  
 
Woj> = Indeed... What's=20 the IPv6 document being referred to here? If it happens to be=20 draft-lourdelet-radext-ipv6-access, then it does not define any new = tagging=20 scheme.
- Woj. 

------_=_NextPart_001_01CA46A5.B936BA37-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 6 12:50:12 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 52F333A6863 for ; Tue, 6 Oct 2009 12:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.905 X-Spam-Level: X-Spam-Status: No, score=-0.905 tagged_above=-999 required=5 tests=[AWL=-0.410, 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 8LhUrpyDOhbf for ; Tue, 6 Oct 2009 12:50:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 98D9C3A67F4 for ; Tue, 6 Oct 2009 12:50:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvG0H-0003nc-8A for radiusext-data0@psg.com; Tue, 06 Oct 2009 19:47:21 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvG07-0003mn-V2 for radiusext@ops.ietf.org; Tue, 06 Oct 2009 19:47:19 +0000 Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id CB3DF12344AA; Tue, 6 Oct 2009 21:47:07 +0200 (CEST) Message-ID: <4ACB9EBB.9010304@deployingradius.com> Date: Tue, 06 Oct 2009 21:47:07 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" CC: Bernard Aboba , "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: IPv6 References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Wojciech Dec (wdec) wrote: > Woj> Indeed... What's the IPv6 document being referred to here? If > it happens to be draft-lourdelet-radext-ipv6-access, then it does > not define any new tagging scheme. Uh... have you compared it to RFC 2868? 3.3 IPv6-Prefix Defines an IPv6 prefix with a tag. There are NO existing tagged IPv6 attributes. RFC 2868 defines tagged integers and strings *only*. This data type is new. 3.5 IPv6-Route-Option-Lifetime Defines an 8-bit tag, followed by a 32-bit integer. RFC 2868 defines a 32-bit integer where the 8-bit tag over-writes the highest 8 bit of the integer. This data type is new. 3.6 and 3.7 have the same issue. 3.8. Auth-IPv6-Prefix-User-ID Defines an 8-bit tag followed by a 64-bit integer. There are NO existing attributes that are tagged 64-bit integers. This data type is new. This draft defines a number of new tagged data types which are not previously used in any RFC, or on any vendor equipment, or in any specification from another standards body. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 6 14:15: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 197583A6835 for ; Tue, 6 Oct 2009 14:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.819 X-Spam-Level: X-Spam-Status: No, score=-8.819 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 JkeW3uW6eEZo for ; Tue, 6 Oct 2009 14:15:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3AB943A687A for ; Tue, 6 Oct 2009 14:15:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvHMs-000C4y-0o for radiusext-data0@psg.com; Tue, 06 Oct 2009 21:14:46 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvHMi-000C47-6I for radiusext@ops.ietf.org; Tue, 06 Oct 2009 21:14:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=2058; q=dns/txt; s=amsiport01001; t=1254863676; x=1256073276; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20IPv6|Date:=20Tue,=206=20Oct=202009=2023 :14:11=20+0200|Message-ID:=20|To:=20"Alan=20DeKok" =20|Cc:=20"Bernard=20Aboba"=20 ,=0D=0A=20=20=20=20=20=20=20 =20"David=20B.=20Nelson"=20, =0D=0A=20=20=20=20=20=20=20=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<4ACB9EBB.9010304@deployingradiu s.com>|References:=20=20 =20=20=20<9E1DAF16-40C5-4 A25-82D0-EEDB7561BA64@elbrysnetworks.com>=20<4ACB5A24.100 0400@deployingradius.com>=20=20=20<4ACB9EBB.9010304@deployingrad ius.com>; bh=wjW6yQkDaVzx5/wX1Pz5CSxV9cpBpKuQUA3k5O9iXA0=; b=e1V31N3A6erU0NjthdzXKRGHEPjTYfK+eMxGaTu3KUvV45Ot17vdtCQb VQyUodFhVr/JzZhfM1OEJ7bC9vBWRX/2Kf8hVp/37kTZhtj9jxUwH2KoD YhwQRQy0jMod2U06RB+pMsg/M3TrM0Y9pLfcnO5QkPRW9Jj58qHMWwsny 0=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=wdec@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcAAPdPy0qQ/uCKe2dsb2JhbACafAEBFiQGoF2IYwGPMAaEKoFX X-IronPort-AV: E=Sophos;i="4.44,515,1249257600"; d="scan'208";a="51118634" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Oct 2009 21:14:34 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n96LEYTF020071; Tue, 6 Oct 2009 23:14:34 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n96LEYng009534; Tue, 6 Oct 2009 21:14:34 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 23:14:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Date: Tue, 6 Oct 2009 23:14:11 +0200 Message-ID: In-Reply-To: <4ACB9EBB.9010304@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Thread-Index: AcpGvdYH5mXEhoIYSCyy4FaarcDu0gACGGLA References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> From: "Wojciech Dec (wdec)" To: "Alan DeKok" Cc: "Bernard Aboba" , "David B. Nelson" , X-OriginalArrivalTime: 06 Oct 2009 21:14:34.0177 (UTC) FILETIME=[00A71B10:01CA46CA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2058; t=1254863674; x=1255727674; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20IPv6 |Sender:=20; bh=wjW6yQkDaVzx5/wX1Pz5CSxV9cpBpKuQUA3k5O9iXA0=; b=H0CGJhDWE+R7CaQmO2TX68IYYOoKr+aKXvdpsJSZ8kWaXJIdUGph22PvZS doyIpNC3BBZMdDe7INYHsJ03Hw+nuqrtuCWqVIh5GxIgjiNyKbr6h1HI4+Kn Eu9xPLL07N; Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: =20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: 06 October 2009 21:47 > To: Wojciech Dec (wdec) > Cc: Bernard Aboba; David B. Nelson; radiusext@ops.ietf.org > Subject: Re: IPv6 >=20 > Wojciech Dec (wdec) wrote: > > Woj> Indeed... What's the IPv6 document being referred=20 > to here? If > > it happens to be draft-lourdelet-radext-ipv6-access,=20 > then it does > > not define any new tagging scheme. >=20 > Uh... have you compared it to RFC 2868? That same RFC 2865, in section 5, states: string 1-253 octets containing binary data (values 0 through 255 decimal, inclusive). Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. With that, Ipv6 Prefix, Route options, Auth-IPv6-Prefix-User-ID, etc would be pretty much covered by using the string term. >=20 > 3.3 IPv6-Prefix >=20 > Defines an IPv6 prefix with a tag. There are NO existing=20 > tagged IPv6 attributes. RFC 2868 defines tagged integers and=20 > strings *only*. This data type is new. >=20 > 3.5 IPv6-Route-Option-Lifetime >=20 > Defines an 8-bit tag, followed by a 32-bit integer. RFC=20 > 2868 defines a 32-bit integer where the 8-bit tag over-writes=20 > the highest 8 bit of the integer. This data type is new. >=20 > 3.6 and 3.7 have the same issue. >=20 > 3.8. Auth-IPv6-Prefix-User-ID >=20 > Defines an 8-bit tag followed by a 64-bit integer. There=20 > are NO existing attributes that are tagged 64-bit integers. =20 > This data type is new. Are unsigned 64-bit integers really a new thing to Radius? That would seemingly contradict what's presented as de facto in http://tools.ietf.org/html/draft-ietf-radext-design-08#section-2.1.1 -Woj. >=20 >=20 > This draft defines a number of new tagged data types which=20 > are not previously used in any RFC, or on any vendor=20 > equipment, or in any specification from another standards body. >=20 > Alan DeKok. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 6 14:35:45 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 058893A6A0E for ; Tue, 6 Oct 2009 14:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[AWL=-0.399, 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 JZS73LU2C1iW for ; Tue, 6 Oct 2009 14:35:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6BDAA3A69BD for ; Tue, 6 Oct 2009 14:35:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvHfY-000Dcl-OT for radiusext-data0@psg.com; Tue, 06 Oct 2009 21:34:04 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvHfP-000Dby-3G for radiusext@ops.ietf.org; Tue, 06 Oct 2009 21:34:02 +0000 Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id DF88612344AA; Tue, 6 Oct 2009 23:33:53 +0200 (CEST) Message-ID: <4ACBB7C1.2000900@deployingradius.com> Date: Tue, 06 Oct 2009 23:33:53 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" CC: Bernard Aboba , "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: IPv6 References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Wojciech Dec (wdec) wrote: > That same RFC 2865, in section 5, states: > > string 1-253 octets containing binary data (values 0 through > 255 decimal, inclusive). Strings of length zero (0) > MUST NOT be sent; omit the entire attribute instead. > > With that, Ipv6 Prefix, Route options, Auth-IPv6-Prefix-User-ID, etc > would be pretty much covered by using the string term. The document says that attributes are of type "string", and not IPv6 prefix or integer. Re-defining "32-bit integer" to mean "string" is an argument from absurdity. >> 3.3 IPv6-Prefix >> Defines an 8-bit tag followed by a 64-bit integer. There >> are NO existing attributes that are tagged 64-bit integers. >> This data type is new. > > Are unsigned 64-bit integers really a new thing to Radius? You missed the word "tagged" in the sentence above. That makes my comment meaningful, instead of nonsensical. > That would > seemingly contradict what's presented as de facto in > http://tools.ietf.org/html/draft-ietf-radext-design-08#section-2.1.1 Only if you take a discussion about "tagged" attributes, and ignore key words like "tagged". Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 6 14:40:27 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 0F8483A6A18 for ; Tue, 6 Oct 2009 14:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.009 X-Spam-Level: X-Spam-Status: No, score=0.009 tagged_above=-999 required=5 tests=[AWL=0.504, 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 l9kdsZVwFIHF for ; Tue, 6 Oct 2009 14:40:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1360A3A6A16 for ; Tue, 6 Oct 2009 14:40:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvHkN-000E7D-LN for radiusext-data0@psg.com; Tue, 06 Oct 2009 21:39:03 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvHkE-000E6a-0L for radiusext@ops.ietf.org; Tue, 06 Oct 2009 21:39:02 +0000 Received: (qmail 21384 invoked from network); 6 Oct 2009 21:38:50 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 6 Oct 2009 21:38:50 -0000 Message-Id: <30B10043-1F22-4AD6-8246-2F80DFA081AE@elbrysnetworks.com> From: "David B. Nelson" To: radiusext@ops.ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: IPv6 Date: Tue, 6 Oct 2009 17:38:50 -0400 References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> X-Mailer: Apple Mail (2.936) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: On Oct 6, 2009, at 5:14 PM, Wojciech Dec (wdec) wrote: > That same RFC 2865, in section 5, states: > > string 1-253 octets containing binary data (values 0 through > 255 decimal, inclusive). Strings of length zero (0) > MUST NOT be sent; omit the entire attribute instead. > > With that, Ipv6 Prefix, Route options, Auth-IPv6-Prefix-User-ID, etc > would be pretty much covered by using the string term. With all due respect, the String data type is just a string of undistinguished octets. While you may conceptually overlay it with a structure, i.e define sub-fields, that action creates a new data type. In other words, the String type is just a string. You may lament the fact that RADIUS, as defined in RFCs up through 2865, has no method to formally define structured data, but the fact is that it has none. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Oct 7 00:57: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 770FD3A6A4A for ; Wed, 7 Oct 2009 00:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.786 X-Spam-Level: X-Spam-Status: No, score=-8.786 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 i8rmy-M6JtnB for ; Wed, 7 Oct 2009 00:57:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 173353A67E5 for ; Wed, 7 Oct 2009 00:57:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvRLB-000JA0-PM for radiusext-data0@psg.com; Wed, 07 Oct 2009 07:53:41 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvRL1-000J99-8J for radiusext@ops.ietf.org; Wed, 07 Oct 2009 07:53:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=2586; q=dns/txt; s=amsiport01001; t=1254902011; x=1256111611; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20IPv6|Date:=20Wed,=207=20Oct=202009=2009 :53:25=20+0200|Message-ID:=20|To:=20"Alan=20DeKok" =20|Cc:=20"Bernard=20Aboba"=20 ,=0D=0A=20=20=20=20=20=20=20 =20"David=20B.=20Nelson"=20, =0D=0A=20=20=20=20=20=20=20=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<4ACBB7C1.2000900@deployingradiu s.com>|References:=20=20 =20=20=20<9E1DAF16-40C5-4 A25-82D0-EEDB7561BA64@elbrysnetworks.com>=20<4ACB5A24.100 0400@deployingradius.com>=20=20=20<4ACB9EBB.9010304@deployingrad ius.com>=20=20<4ACBB7C1.2000900@deployingradius.com>; bh=lE5ljsZcIN38j3qem/6paiAb7AmspO/c4kbN3UPeUzw=; b=Jeo2F/ZCpw4s4KOq/+EGUrM53jKzsFFPYv7jsP0xxV5fkycdKarvck6x GJUMkD2aM0gfQIeRnoRJljlQtdjrYQQd4eeoCnD5nJk01GL5wI/xQLv9I 6bZ0aEUGbo9jtwQVeYIG3rK7kibhwV0Z480Gg1zRhs0Be/5rd55ZHPcaz E=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=wdec@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8AAPbly0qQ/uCKe2dsb2JhbACafAEBFiQGoFuIYwGPNgaEKoFY X-IronPort-AV: E=Sophos;i="4.44,518,1249257600"; d="scan'208";a="51147441" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2009 07:53:29 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n977rT3F030310; Wed, 7 Oct 2009 09:53:29 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n977rTK1020428; Wed, 7 Oct 2009 07:53:29 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 09:53:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Date: Wed, 7 Oct 2009 09:53:25 +0200 Message-ID: In-Reply-To: <4ACBB7C1.2000900@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Thread-Index: AcpGzLZZUU3YYe+NQrudLX8CLV7L4gAUuOfQ References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> <4ACBB7C1.2000900@deployingradius.com> From: "Wojciech Dec (wdec)" To: "Alan DeKok" Cc: "Bernard Aboba" , "David B. Nelson" , X-OriginalArrivalTime: 07 Oct 2009 07:53:29.0240 (UTC) FILETIME=[42218180:01CA4723] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2586; t=1254902009; x=1255766009; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20IPv6 |Sender:=20; bh=lE5ljsZcIN38j3qem/6paiAb7AmspO/c4kbN3UPeUzw=; b=Hwylk6vIiTaAWqoEtDxq7l3IKGYts++i0EshPM2v6TlxW1++txlIzi0tvK 0RTT5HIXQj96E79Giuo2opV0F558qG7SDemNGS1667WhxdSjM/GFV82yNEN7 rF3eJ58Eej; Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: =20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: 06 October 2009 23:34 > To: Wojciech Dec (wdec) > Cc: Bernard Aboba; David B. Nelson; radiusext@ops.ietf.org > Subject: Re: IPv6 >=20 > Wojciech Dec (wdec) wrote: > > That same RFC 2865, in section 5, states: > >=20 > > string 1-253 octets containing binary data (values=20 > 0 through > > 255 decimal, inclusive). Strings of length zero (0) > > MUST NOT be sent; omit the entire attribute instead. > >=20 > > With that, Ipv6 Prefix, Route options,=20 > Auth-IPv6-Prefix-User-ID, etc=20 > > would be pretty much covered by using the string term. >=20 > The document says that attributes are of type "string", and=20 > not IPv6 prefix or integer. Re-defining "32-bit integer" to=20 > mean "string" is an argument from absurdity. Guess someone forgot to add a character encoding set limitation to the definition of "string" above. Without it, any sequence of 1-253 octets falls neatly under the "a string". That said, rfc 3162 clearly already has a "call it whatever you want" data-type for "Framed-IPv6-Prefix", which happens to be the same type of data as in the IPv6-Prefix in draft-lourdelet. Re Auth-IPv6-Prefix-User-ID, changing it to a string would definitely work (and I see no problem in that). The odd one out is probably the IPv6-Route-Option-Preference in draft-lourdelet, which has an rfc4191 derived 2 bit signed integer. No problem in changing that to a simple signed integer, while restricting the values. =20 >=20 > >> 3.3 IPv6-Prefix > >> Defines an 8-bit tag followed by a 64-bit integer. There are NO=20 > >> existing attributes that are tagged 64-bit integers. > >> This data type is new. > >=20 > > Are unsigned 64-bit integers really a new thing to Radius?=20 >=20 > You missed the word "tagged" in the sentence above. That=20 > makes my comment meaningful, instead of nonsensical. I'm still finding the issue rather nonsensical. Do you really mean to say that the addition of an attribute, the tag, requires the re-definition of each and every data type that radius has, eg "the tagged 64-bit unsigned integer", etc? That's bizzarre at best... Why? -Woj. >=20 > > That would > > seemingly contradict what's presented as de facto in > > http://tools.ietf.org/html/draft-ietf-radext-design-08#section-2.1.1 >=20 > Only if you take a discussion about "tagged" attributes,=20 > and ignore key words like "tagged". >=20 > Alan DeKok. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Oct 7 02:14: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 EA94328C0DB for ; Wed, 7 Oct 2009 02:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[AWL=-0.385, 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 VByv3ifCeXc5 for ; Wed, 7 Oct 2009 02:14:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA6D228B56A for ; Wed, 7 Oct 2009 02:14:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvSXn-0001GI-Hv for radiusext-data0@psg.com; Wed, 07 Oct 2009 09:10:47 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvSXd-0001FE-Mf for radiusext@ops.ietf.org; Wed, 07 Oct 2009 09:10:45 +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 41EBB12344AA; Wed, 7 Oct 2009 11:10:36 +0200 (CEST) Message-ID: <4ACC5B0B.9060906@deployingradius.com> Date: Wed, 07 Oct 2009 11:10:35 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" CC: Bernard Aboba , "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: IPv6 References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> <4ACBB7C1.2000900@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Wojciech Dec (wdec) wrote: > Guess someone forgot to add a character encoding set limitation to the > definition of "string" above. Without it, any sequence of 1-253 octets > falls neatly under the "a string". Is this a joke? Here's a short explanation, as it's clear you are completely unfamiliar with RADIUS. RADIUS attributes are typed. The list of types is small. Each type is statically defined in an RFC. RADIUS implementations use these definitions to determine how to manipulate the attributes (parse, print, wire-encode, wire-decode). The types cannot be changed, because they have existing definitions. Defining new encoding/decode means defining new types... because you can't encode the OLD type in a NEW way, and you can't encode the NEW type in the OLD way. Otherwise... please suggest how implementations can do the impossible, and encode these new attributes using a novel format, without adding a new encoding method. > That said, rfc 3162 clearly already > has a "call it whatever you want" data-type for "Framed-IPv6-Prefix", > which happens to be the same type of data as in the IPv6-Prefix in > draft-lourdelet. Absolute nonsense. Framed-IPv6-Prefix has a different on-the-wire format than IPv6-prefix. Therefore, they are different data types. > The odd one out is probably the IPv6-Route-Option-Preference in > draft-lourdelet, which has an rfc4191 derived 2 bit signed integer. No > problem in changing that to a simple signed integer, while restricting > the values. RADIUS has no support for signed integers. See: http://tools.ietf.org/html/draft-ietf-radext-design-08 I suggest reading the document before posting any more confusion about data types in RADIUS. It describes the RADIUS data model, along with supported and not-supported data types. > I'm still finding the issue rather nonsensical. Do you really mean to > say that the addition of an attribute, the tag, requires the > re-definition of each and every data type that radius has, eg "the > tagged 64-bit unsigned integer", etc? That's bizzarre at best... Why? Because that's how RADIUS works. DHCP works the same way. As does DNS. As does SNMP. As does NTP. The list goes on... In fact, *any* protocol that has bit-packing of data (as opposed to text encoding like FTP or SMTP) has pretty much fixed data types. You can't change the interpretation of a "32-bit integer", because its meaning is already defined. Try updating your C compiler to interpret "uint32_t" as "struct foo". See how many third-party programs compile without error. Those programs make assumptions base on the definitions of the data types. Changing the data types means that the assumptions are no longer valid, and the programs no longer work as intended. I'm surprised that this behavior is novel to you. Binary packed protocols have worked this way for a *long* time. 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 Oct 7 05:11: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 441C13A6A7D for ; Wed, 7 Oct 2009 05:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.76 X-Spam-Level: X-Spam-Status: No, score=-6.76 tagged_above=-999 required=5 tests=[AWL=-2.265, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6yooAeR34Dy for ; Wed, 7 Oct 2009 05:11:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C54BD3A6936 for ; Wed, 7 Oct 2009 05:11:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvVJc-000KFx-DH for radiusext-data0@psg.com; Wed, 07 Oct 2009 12:08:20 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvVJP-000KEz-6x for radiusext@ops.ietf.org; Wed, 07 Oct 2009 12:08:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=7443; q=dns/txt; s=sjiport06001; t=1254917287; x=1256126887; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20IPv6|Date:=20Wed,=207=20Oct=202009=2014 :07:46=20+0200|Message-ID:=20|To:=20"Alan=20DeKok" =20|Cc:=20"Bernard=20Aboba"=20 ,=0D=0A=20=20=20=20=20=20=20 =20"David=20B.=20Nelson"=20, =0D=0A=20=20=20=20=20=20=20=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<4ACC5B0B.9060906@deployingradiu s.com>|References:=20=20 =20=20=20<9E1DAF16-40C5-4 A25-82D0-EEDB7561BA64@elbrysnetworks.com>=20<4ACB5A24.100 0400@deployingradius.com>=20=20=20<4ACB9EBB.9010304@deployingrad ius.com>=20=20<4ACBB7C1.2000900@deployingradius.com> =20=20<4ACC5B0B.9060906@deployingradius.com>; bh=GlK3jBdBRNkSit9us/JKNGHaMIYbYfvQOqQEAUqNqgE=; b=pRiaGP9dtvccjuPh3xyB35pXHVkOShDsJA2RV109J8rMG4DGIPBxKLKd bwZW76t8OXWC9e16nydxZtLaImo+ac2NSKsPJVeeIYmn89KurwyXGkCgF mgbrqViV+cwFXVChfi8+ejGPSOO6w3yRAqdFZ76UUYvqDjUAHjZVIM0SN U=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=wdec@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAchzEqrR7PE/2dsb2JhbAC8d4hjAY8zBoQqgVg X-IronPort-AV: E=Sophos;i="4.44,519,1249257600"; d="scan'208";a="403669237" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Oct 2009 12:08:06 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n97C86fS005059; Wed, 7 Oct 2009 05:08:06 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n97C7g3F015521; Wed, 7 Oct 2009 12:08:06 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 14:07:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Date: Wed, 7 Oct 2009 14:07:46 +0200 Message-ID: In-Reply-To: <4ACC5B0B.9060906@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Thread-Index: AcpHLhiy+skUtrTYSymOv1L0eu5lqgACEvHw References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> <4ACBB7C1.2000900@deployingradius.com> <4ACC5B0B.9060906@deployingradius.com> From: "Wojciech Dec (wdec)" To: "Alan DeKok" Cc: "Bernard Aboba" , "David B. Nelson" , X-OriginalArrivalTime: 07 Oct 2009 12:07:50.0261 (UTC) FILETIME=[CA688250:01CA4746] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7443; t=1254917286; x=1255781286; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20IPv6 |Sender:=20; bh=GlK3jBdBRNkSit9us/JKNGHaMIYbYfvQOqQEAUqNqgE=; b=cLjevWfgyAnFg1UhtMEJKbXOngCJUmQjNlgZew07jTy5CSZ7yxd27Zcw/5 kuCE96Y+PXOYBjPcxt7IPEXKuxkYQJRxZLSmj8Qq9fSPcfnJ+7F7n+jXaigb doYvuFnCep; Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: =20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: 07 October 2009 11:11 > To: Wojciech Dec (wdec) > Cc: Bernard Aboba; David B. Nelson; radiusext@ops.ietf.org > Subject: Re: IPv6 >=20 > Wojciech Dec (wdec) wrote: > > Guess someone forgot to add a character encoding set=20 > limitation to the=20 > > definition of "string" above. Without it, any sequence of=20 > 1-253 octets=20 > > falls neatly under the "a string". >=20 > Is this a joke? >=20 > Here's a short explanation, as it's clear you are=20 > completely unfamiliar with RADIUS. >=20 > RADIUS attributes are typed. The list of types is small. =20 > Each type is statically defined in an RFC. RADIUS=20 > implementations use these definitions to determine how to=20 > manipulate the attributes (parse, print, wire-encode,=20 > wire-decode). The types cannot be changed, because they have=20 > existing definitions. Defining new encoding/decode means=20 > defining new types... because you can't encode the OLD type=20 > in a NEW way, and you can't encode the NEW type in the OLD way. So a number of points: Draft-lourdelet clearly defins NEW Attributes NOT changing existing attributes and the draft does not propose anything for which there isn't a precedent (see rfc2868, rfc3162).=20 Overall, thanks for educating me, but perhaps you should take a step back: In draft-lourdelet we're defining the on-the-wire format of these new attributes. The data-type used for internal bindings of these attributes is an implementation detail, which you (and perhaps others) appear to make a business of the Radext WG (it seems that while new to Radext, I haven't been missing out on much fun after all).=20 Now, even if that were justfiied, with a definition of "string" like the one above you have no right to claim that a "string" data-type cannot be used for sending an arbitrary sequence of 1-255 octets of/in whatever encoding. You're clearly basing your point on non-atomic data-types, which I comment on further below... >=20 > Otherwise... please suggest how implementations can do the=20 > impossible, and encode these new attributes using a novel=20 > format, without adding a new encoding method. Uhm, for the IPv6-Prefix attribute one could have one of the following abstract definitions (all of them with no new exotic data-types other than those likely already used) struct IPv6-Prefix { uint8_t tag; uint8_t prefix-length; uint128_t prefix; }; OR struct IPv6-Prefix { uint8_t tag; uint8_t prefix-length; string_t prefix; }; Etc. >=20 > > That said, rfc 3162 clearly already > > has a "call it whatever you want" data-type for=20 > "Framed-IPv6-Prefix",=20 > > which happens to be the same type of data as in the IPv6-Prefix in=20 > > draft-lourdelet. >=20 > Absolute nonsense. Framed-IPv6-Prefix has a different=20 > on-the-wire format than IPv6-prefix. Therefore, they are=20 > different data types. May I suggest that once more you're confusing on-the-wire format with internal data-type representation. It would seem that according to you each attribute in Radius with some internal structure not seen previoulsy is effectively a new data-type and that this needs to be enforced by the Radius specs. I'll call these non-atomic-data-types to differentiate from what I consider common atomic data-types that rely on common types/units of data (unit 32, etc). It's from the perspective of non-atomic-data-types that draft-lourdelet *may* indeed be seen to call for something new. It "may* but *it doesn't have* because that's again all up to *implementation detail*. I'll use the following example to illustrate.=20 RFC3162 defines the framed-ipv6-attribute, and so presumably an implementation also has a pseudo-data-type to support it: Framed-IPv6-Prefix 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Implementation wise, the difference between the above and the IPv6-Prefix attribute in draft-lauderlet is the semantic of the Reserved field vs the Tag field. If, when coding the psudeo-data-type one chose to have the Reserved field modelled as a unit8 then it would be the same pseudo-data-type that would apply to draft-lourdelet. If a different choice was made, then a new psudo-data-type need to be cast. Coincidentally, the Radius spec doesn't say which data-type should the Reserved field be cast as. All this shows how pointless is defining the protocol *and* such non-atomic-data-type implementation specifics at the same time. The protocol spec should not go into implementation specifics and your argument around why it should be otherwise is rather unsubstatiated. Draft-ietf-radext-design-08.txt doesn't do better, if actually being misguided in some of these aspects. It would help all if you could be a bit more constructive...=20 -Woj. >=20 > > The odd one out is probably the IPv6-Route-Option-Preference in=20 > > draft-lourdelet, which has an rfc4191 derived 2 bit signed=20 > integer. No=20 > > problem in changing that to a simple signed integer, while=20 > restricting=20 > > the values. >=20 > RADIUS has no support for signed integers. See: >=20 > http://tools.ietf.org/html/draft-ietf-radext-design-08 >=20 > I suggest reading the document before posting any more=20 > confusion about data types in RADIUS. It describes the=20 > RADIUS data model, along with supported and not-supported data types. >=20 > > I'm still finding the issue rather nonsensical. Do you=20 > really mean to=20 > > say that the addition of an attribute, the tag, requires the=20 > > re-definition of each and every data type that radius has, eg "the=20 > > tagged 64-bit unsigned integer", etc? That's bizzarre at=20 > best... Why? >=20 > Because that's how RADIUS works. DHCP works the same way. =20 > As does DNS. As does SNMP. As does NTP. The list goes on... >=20 > In fact, *any* protocol that has bit-packing of data (as=20 > opposed to text encoding like FTP or SMTP) has pretty much=20 > fixed data types. You can't change the interpretation of a=20 > "32-bit integer", because its meaning is already defined. >=20 > Try updating your C compiler to interpret "uint32_t" as=20 > "struct foo". > See how many third-party programs compile without error. =20 > Those programs make assumptions base on the definitions of=20 > the data types. Changing the data types means that the=20 > assumptions are no longer valid, and the programs no longer=20 > work as intended. >=20 > I'm surprised that this behavior is novel to you. Binary=20 > packed protocols have worked this way for a *long* time. >=20 > Alan DeKok. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Oct 7 05: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 DBECF3A6A6C for ; Wed, 7 Oct 2009 05:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.571 X-Spam-Level: X-Spam-Status: No, score=-8.571 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, 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 rzFzcbsvvMPc for ; Wed, 7 Oct 2009 05:26:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF7013A6A7F for ; Wed, 7 Oct 2009 05:26:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvVXa-000LXH-Tx for radiusext-data0@psg.com; Wed, 07 Oct 2009 12:22:46 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvVXL-000LVl-Qp for radiusext@ops.ietf.org; Wed, 07 Oct 2009 12:22:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=1777; q=dns/txt; s=amsiport01001; t=1254918151; x=1256127751; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20IPv6|Date:=20Wed,=207=20Oct=202009=2014 :22:21=20+0200|Message-ID:=20|To:=20"David=20B.=20Ne lson"=20,=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20 quoted-printable|In-Reply-To:=20<30B10043-1F22-4AD6-8246- 2F80DFA081AE@elbrysnetworks.com>|References:=20=20=20=20=20<9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetw orks.com>=20<4ACB5A24.1000400@deployingradius.com>=20=20=20<4ACB 9EBB.9010304@deployingradius.com>=20=20<30B10043-1F2 2-4AD6-8246-2F80DFA081AE@elbrysnetworks.com>; bh=iuYpqn1D3EgmwxfStpiZM9wfpQ4EBEJegOQOOLK0Qds=; b=o16Kca36TJdUvxJMBzBK+5r6EckFk6M2pfVSV4uIOrL/aSxNx5zqFM2L 3s30wdrrZXVRF9vrZgfn9mILFiDKNfZ2AXfKqLA2RhLb4x0OTqKRfU3mb 73J1QPcdG8CEyMeRfHrTy7LCTxb6OXs/G7UOQHwTtwCaK2F813u01QufU k=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=wdec@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8AAHslzEqQ/uCLe2dsb2JhbACafQEBFiQGoTqIYwE2jn4Ggk+BW4FYgk0 X-IronPort-AV: E=Sophos;i="4.44,519,1249257600"; d="scan'208";a="51182276" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2009 12:22:29 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n97CMTiv024353; Wed, 7 Oct 2009 14:22:29 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n97CMTs6020926; Wed, 7 Oct 2009 12:22:29 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 14:22:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Date: Wed, 7 Oct 2009 14:22:21 +0200 Message-ID: In-Reply-To: <30B10043-1F22-4AD6-8246-2F80DFA081AE@elbrysnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Thread-Index: AcpGzXc2JsOFHpNBQbmdU/TJ3dfUnwAeqIhQ References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> <30B10043-1F22-4AD6-8246-2F80DFA081AE@elbrysnetworks.com> From: "Wojciech Dec (wdec)" To: "David B. Nelson" , X-OriginalArrivalTime: 07 Oct 2009 12:22:29.0063 (UTC) FILETIME=[D6370D70:01CA4748] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1777; t=1254918149; x=1255782149; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20IPv6 |Sender:=20; bh=iuYpqn1D3EgmwxfStpiZM9wfpQ4EBEJegOQOOLK0Qds=; b=AilQUvISKMqCEvURBNo6yDBFGqBoe8vK2SKEeQV+AHVCQ7NqQeyDYGeZq4 4rcptgpBRQe7pAdBZ/HmdXZOQA0+fve9P/CBaGWIDgH+vTdkrPoH+Lczl2vC ihJYNtF5+S; Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson > Sent: 06 October 2009 23:39 > To: radiusext@ops.ietf.org > Subject: Re: IPv6 >=20 >=20 > On Oct 6, 2009, at 5:14 PM, Wojciech Dec (wdec) wrote: >=20 > > That same RFC 2865, in section 5, states: > > > > string 1-253 octets containing binary data (values 0 through > > 255 decimal, inclusive). Strings of length zero (0) > > MUST NOT be sent; omit the entire attribute instead. > > > > With that, Ipv6 Prefix, Route options,=20 > Auth-IPv6-Prefix-User-ID, etc=20 > > would be pretty much covered by using the string term. >=20 > With all due respect, the String data type is just a string of =20 > undistinguished octets. While you may conceptually overlay=20 > it with a =20 > structure, i.e define sub-fields, that action creates a new=20 > data type. In other words, the String type is just a string.=20 > You may lament the fact that RADIUS, as defined in RFCs up=20 > through 2865, has no method to formally define structured=20 > data, but the fact is that it has none. Sure, that's fair. The point I was making is that with the string definition above, passing an IPv6 prefix (or anything else up to 255 bytes really) did not require any new data-type and in terms of say the IPv6-prefix. Furthermore rfc2868 provides plenty of precedent for structured attributes with "String", if one wants, eg Tunnel-Password. -Woj. >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Oct 7 06:02: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 912963A6934 for ; Wed, 7 Oct 2009 06:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[AWL=-0.376, 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 cCurBW0mOEwp for ; Wed, 7 Oct 2009 06:02:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 24A343A68EA for ; Wed, 7 Oct 2009 06:02:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvW9B-000PWf-3u for radiusext-data0@psg.com; Wed, 07 Oct 2009 13:01:37 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvW91-000PVl-2J for radiusext@ops.ietf.org; Wed, 07 Oct 2009 13:01:34 +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 E907512344AA; Wed, 7 Oct 2009 15:01:25 +0200 (CEST) Message-ID: <4ACC9125.2070206@deployingradius.com> Date: Wed, 07 Oct 2009 15:01:25 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" CC: Bernard Aboba , "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: IPv6 References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> <4ACBB7C1.2000900@deployingradius.com> <4ACC5B0B.9060906@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Wojciech Dec (wdec) wrote: > So a number of points: Draft-lourdelet clearly defins NEW Attributes NOT > changing existing attributes and the draft does not propose anything for > which there isn't a precedent (see rfc2868, rfc3162). I think we're really talking about different things. I keep trying to explain that the draft is doing something *new*. You keep claiming it isn't. > Overall, thanks for educating me, but perhaps you should take a step > back: In draft-lourdelet we're defining the on-the-wire format of these > new attributes. The data-type used for internal bindings of these > attributes is an implementation detail, which you (and perhaps others) > appear to make a business of the Radext WG (it seems that while new to > Radext, I haven't been missing out on much fun after all). The "implementation detail" you're arguing about is discussed in the design guidelines document. It's something that comes up in this WG, and in others. Implementation details are relevant, and cannot be dismissed with a wave of the hand. > Now, even if that were justfiied, with a definition of "string" like the > one above you have no right to claim that a "string" data-type cannot be > used for sending an arbitrary sequence of 1-255 octets of/in whatever > encoding. I think you have a problem reading my messages. I didn't claim the "string" type wasn't suitable for sending arbitrary strings. I said that you couldn't have it both ways: (1) claim that it's an attribute with a strongly typed definition (tag + integer), and (2) claim that it's also an arbitrary sequence of octets. It's about consistency. I like it. You're not following it. >> Otherwise... please suggest how implementations can do the >> impossible, and encode these new attributes using a novel >> format, without adding a new encoding method. > > Uhm, for the IPv6-Prefix attribute one could have one of the following > abstract definitions (all of them with no new exotic data-types other > than those likely already used) > > struct IPv6-Prefix { uint8_t tag; uint8_t prefix-length; uint128_t > prefix; }; Please point out where the "struct" type is defined in the RADIUS specifications. You can't. It isn't defined anywhere. You invented it, and claimed that it can be used in RADIUS, and that it's just an "implementation detail". It's not. If this was Diameter, this would be possible. Diameter defines a grouped attribute, which can be used to group arbitrary other attributes (i.e. data types) into a "struct" like object. > May I suggest that once more you're confusing on-the-wire format with > internal data-type representation. Uh... the internal data types represent at *least* the on-the-wire format. If they didn't, the data types couldn't be encoded onto the wire. > It would seem that according to you > each attribute in Radius with some internal structure not seen > previoulsy is effectively a new data-type Don't blame me. That would appear to be the consensus of this WG, as written in the design guidelines document. > and that this needs to be > enforced by the Radius specs. I'll call these non-atomic-data-types to > differentiate from what I consider common atomic data-types that rely on > common types/units of data (unit 32, etc). It's from the perspective of > non-atomic-data-types that draft-lourdelet *may* indeed be seen to call > for something new. It "may* but *it doesn't have* because that's again > all up to *implementation detail*. Ignoring implementation details won't make them go away. This draft *gratuitously* introduces new data types where existing ones could be re-used. That's not an implementation detail: it's bad design. > All this shows how pointless is defining the protocol *and* such > non-atomic-data-type implementation specifics at the same time. The > protocol spec should not go into implementation specifics and your > argument around why it should be otherwise is rather unsubstatiated. Strange. I could have sworn I was writing messages explaining my position. Did you read them? RADIUS servers have historically been been driven by data dictionaries. See Section 2 of the design guidelines document. This isn't an "implementation detail". It is billions of dollars of equipment in hundreds of thousands of sites. Some implementations have simple dictionary support, others support complex dictionaries. But this "implementation detail" needs to be taken into account when writing new specifications. > Draft-ietf-radext-design-08.txt doesn't do better, if actually being > misguided in some of these aspects. I suggest that you post a separate review of the document. It's clear that you have valuable input which could make the document better. > It would help all if you could be a bit more constructive... By all means. Simple specifications that leverage existing implementations are good. Specifications that follow historical practices are usually a good idea, too. I am encouraging good practice. Part of this involves pointing out bad practices, and explaining why they're bad. If you think this is not constructive, I suggest you avoid peer review entirely. 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 Oct 7 06:06:26 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 78E543A67A4 for ; Wed, 7 Oct 2009 06:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.217 X-Spam-Level: X-Spam-Status: No, score=-0.217 tagged_above=-999 required=5 tests=[AWL=0.220, 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 GdD1vGRwyiF1 for ; Wed, 7 Oct 2009 06:06:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AD31C3A63CB for ; Wed, 7 Oct 2009 06:06:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvWCt-000PxQ-Tf for radiusext-data0@psg.com; Wed, 07 Oct 2009 13:05:27 +0000 Received: from [76.96.30.48] (helo=QMTA05.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvWCj-000PvG-8U for radiusext@ops.ietf.org; Wed, 07 Oct 2009 13:05:25 +0000 Received: from OMTA20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id pos21c0041smiN4A5p5H9K; Wed, 07 Oct 2009 13:05:17 +0000 Received: from gwzPC ([124.120.219.195]) by OMTA20.emeryville.ca.mail.comcast.net with comcast id pp4q1c0024DYhCU8gp4uxF; Wed, 07 Oct 2009 13:05:09 +0000 From: "Glen Zorn" To: "'Alan DeKok'" , "'Wojciech Dec \(wdec\)'" Cc: "'Bernard Aboba'" , "'David B. Nelson'" , References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> <4ACBB7C1.2000900@deployingradius.com> <4ACC5B0B.9060906@deployingradius.com> In-Reply-To: <4ACC5B0B.9060906@deployingradius.com> Subject: RE: IPv6 Date: Wed, 7 Oct 2009 20:04:41 +0700 Message-ID: <006601ca474e$c69e3a40$53daaec0$@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: AcpHLsmc1qj/Np5hT0+XmdHjb2uPVQAG+8iA Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok [mailto://aland@deployingradius.com] writes: > Wojciech Dec (wdec) wrote: > > Guess someone forgot to add a character encoding set limitation to > the > > definition of "string" above. Without it, any sequence of 1-253 > octets > > falls neatly under the "a string". > > Is this a joke? > > Here's a short explanation, as it's clear you are completely > unfamiliar with RADIUS. Well, _someone_ is... > > RADIUS attributes are typed. In your mind, perhaps; in the real world (where RFC 2865 exists), one may read page after page without ever seeing an attribute "typed". A brief example: 5.4. NAS-IP-Address Description This Attribute indicates the identifying IP Address of the NAS which is requesting authentication of the user, and SHOULD be unique to the NAS within the scope of the RADIUS server. NAS-IP- Address is only used in Access-Request packets. Either NAS-IP- Address or NAS-Identifier MUST be present in an Access-Request packet. Note that NAS-IP-Address MUST NOT be used to select the shared secret used to authenticate the request. The source IP address of the Access-Request packet MUST be used to select the shared secret. A summary of the NAS-IP-Address Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 for NAS-IP-Address. Length 6 Address The Address field is four octets. 5.5. NAS-Port Description This Attribute indicates the physical port number of the NAS which is authenticating the user. It is only used in Access-Request packets. Note that this is using "port" in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD be present in an Access-Request packet, if the NAS differentiates among its ports. A summary of the NAS-Port Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 5 for NAS-Port. Length 6 Value The Value field is four octets. 5.6. Service-Type Description This Attribute indicates the type of service the user has requested, or the type of service to be provided. It MAY be used in both Access-Request and Access-Accept packets. A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead. A summary of the Service-Type Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 6 for Service-Type. Length 6 Value The Value field is four octets. 1 Login 2 Framed 3 Callback Login 4 Callback Framed 5 Outbound 6 Administrative 7 NAS Prompt 8 Authenticate Only 9 Callback NAS Prompt 10 Call Check 11 Callback Administrative The service types are defined as follows when used in an Access- Accept. When used in an Access-Request, they MAY be considered to be a hint to the RADIUS server that the NAS has reason to believe the user would prefer the kind of service indicated, but the server is not required to honor the hint. Login The user should be connected to a host. Framed A Framed Protocol should be started for the User, such as PPP or SLIP. Callback Login The user should be disconnected and called back, then connected to a host. Callback Framed The user should be disconnected and called back, then a Framed Protocol should be started for the User, such as PPP or SLIP. Outbound The user should be granted access to outgoing devices. Administrative The user should be granted access to the administrative interface to the NAS from which privileged commands can be executed. NAS Prompt The user should be provided a command prompt on the NAS from which non-privileged commands can be executed. Authenticate Only Only Authentication is requested, and no authorization information needs to be returned in the Access-Accept (typically used by proxy servers rather than the NAS itself). Callback NAS Prompt The user should be disconnected and called back, then provided a command prompt on the NAS from which non-privileged commands can be executed. Call Check Used by the NAS in an Access-Request packet to indicate that a call is being received and that the RADIUS server should send back an Access-Accept to answer the call, or an Access-Reject to not accept the call, typically based on the Called-Station-Id or Calling-Station-Id attributes. It is recommended that such Access-Requests use the value of Calling-Station-Id as the value of the User-Name. Callback Administrative The user should be disconnected and called back, then granted access to the administrative interface to the NAS from which privileged commands can be executed. 5.7. Framed-Protocol Description This Attribute indicates the framing to be used for framed access. It MAY be used in both Access-Request and Access-Accept packets. A summary of the Framed-Protocol Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 7 for Framed-Protocol. Length 6 Value The Value field is four octets. 1 PPP 2 SLIP 3 AppleTalk Remote Access Protocol (ARAP) 4 Gandalf proprietary SingleLink/MultiLink protocol 5 Xylogics proprietary IPX/SLIP 6 X.75 Synchronous 5.8. Framed-IP-Address Description This Attribute indicates the address to be configured for the user. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that address, but the server is not required to honor the hint. A summary of the Framed-IP-Address Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8 for Framed-IP-Address. Length 6 Address The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS Should allow the user to select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates that the NAS should select an address for the user (e.g. Assigned from a pool of addresses kept by the NAS). Other valid values indicate that the NAS should use that value as the user's IP address. > The list of types is small. Each type > is statically defined in an RFC. In what RFC is the "8-bit Tag + 24-bit Integer" "data type" defined? That's easy, none. The fact that some implementations _treat_ it as a "data type" doesn't make it so, since there are other ways to implement a tag. > RADIUS implementations use these > definitions to determine how to manipulate the attributes (parse, > print, > wire-encode, wire-decode). The types cannot be changed, because they > have existing definitions. Defining new encoding/decode means defining > new types... because you can't encode the OLD type in a NEW way, and > you > can't encode the NEW type in the OLD way. > > Otherwise... please suggest how implementations can do the > impossible, > and encode these new attributes using a novel format, without adding a > new encoding method. > > > That said, rfc 3162 clearly already > > has a "call it whatever you want" data-type for "Framed-IPv6-Prefix", > > which happens to be the same type of data as in the IPv6-Prefix in > > draft-lourdelet. > > Absolute nonsense. Framed-IPv6-Prefix has a different on-the-wire > format than IPv6-prefix. Therefore, they are different data types. Alan, who's spouting nonsense here? Are you claiming that entire attributes are "data types" now? > > The odd one out is probably the IPv6-Route-Option-Preference in > > draft-lourdelet, which has an rfc4191 derived 2 bit signed integer. > No > > problem in changing that to a simple signed integer, while > restricting > > the values. > > RADIUS has no support for signed integers. See: > > http://tools.ietf.org/html/draft-ietf-radext-design-08 > > I suggest reading the document before posting any more confusion > about > data types in RADIUS. It describes the DeKok > data model, along with > supported and not-supported data types. ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Oct 7 06:10: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 757033A6922 for ; Wed, 7 Oct 2009 06:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.863 X-Spam-Level: X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[AWL=-0.368, 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 vdWAR1+cPJpn for ; Wed, 7 Oct 2009 06:10:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7A4993A6808 for ; Wed, 7 Oct 2009 06:10:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvWFr-0000Gn-RM for radiusext-data0@psg.com; Wed, 07 Oct 2009 13:08:31 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvWFi-0000FF-JF for radiusext@ops.ietf.org; Wed, 07 Oct 2009 13:08:30 +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 964F412344AA; Wed, 7 Oct 2009 15:08:21 +0200 (CEST) Message-ID: <4ACC92C5.7030905@deployingradius.com> Date: Wed, 07 Oct 2009 15:08:21 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" CC: "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: IPv6 References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> <30B10043-1F22-4AD6-8246-2F80DFA081AE@elbrysnetworks.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Wojciech Dec (wdec) wrote: > Sure, that's fair. The point I was making is that with the string > definition above, passing an IPv6 prefix (or anything else up to 255 > bytes really) did not require any new data-type and in terms of say the > IPv6-prefix. From the design guidelines document: If the RADIUS Server simply passes the contents of an attribute to some non-RADIUS portion of the network, then the data is opaque, and SHOULD be defined to be of type String. A concrete way of judging this requirement is whether or not the attribute definition in the RADIUS document contains delineated fields for sub-parts of the data. If those fields need to be delineated in RADIUS, then the data is not opaque, and it SHOULD be separated into individual RADIUS attributes. > Furthermore rfc2868 provides plenty of precedent for > structured attributes with "String", if one wants, eg Tunnel-Password. From the design guidelines document: As can be seen in Appendix B, most of the existing complex attributes involve authentication or security functionality. Supporting this functionality requires code changes on both the RADIUS client and server, regardless of the attribute format. As a result, in most cases, the use of complex attributes to represent these methods is acceptable, and does not create additional interoperability or deployment issues. All of these arguments are familiar, and have been hashed through in detail in this WG. There are good reasons for the current behavior. The document explains that *changes* in behavior need good reasons, too. 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 Oct 7 06:22: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 273EE3A6AA3 for ; Wed, 7 Oct 2009 06:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[AWL=-0.360, 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 v2K3ddRNhD5R for ; Wed, 7 Oct 2009 06:22:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0FAEA3A6A93 for ; Wed, 7 Oct 2009 06:22:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvWSI-0001cg-LQ for radiusext-data0@psg.com; Wed, 07 Oct 2009 13:21:22 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvWS9-0001bd-AA for radiusext@ops.ietf.org; Wed, 07 Oct 2009 13:21:20 +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 3795112344AA; Wed, 7 Oct 2009 15:21:12 +0200 (CEST) Message-ID: <4ACC95C7.9020600@deployingradius.com> Date: Wed, 07 Oct 2009 15:21:11 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: "'Wojciech Dec (wdec)'" , 'Bernard Aboba' , "'David B. Nelson'" , radiusext@ops.ietf.org Subject: Re: IPv6 References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> <4ACBB7C1.2000900@deployingradius.com> <4ACC5B0B.9060906@deployingradius.com> <006601ca474e$c69e3a40$53daaec0$@net> In-Reply-To: <006601ca474e$c69e3a40$53daaec0$@net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote: > Alan DeKok [mailto://aland@deployingradius.com] writes: >> RADIUS attributes are typed. > > In your mind, perhaps; in the real world (where RFC 2865 exists), one may > read page after page without ever seeing an attribute "typed". Ah... the RFC 2486 definition that the NAS-IP-Address attribute is an "ipv4 address" is just there for joviality. It can really be anything you want. Or, as the design guidelines document says: Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does not define a formal data definition language. A handful of basic data types are provided, and a data type is associated with an attribute when the attribute is defined. >> The list of types is small. Each type >> is statically defined in an RFC. > > In what RFC is the "8-bit Tag + 24-bit Integer" "data type" defined? That's > easy, none. The fact that some implementations _treat_ it as a "data type" > doesn't make it so, since there are other ways to implement a tag. Strange. I was talking about the protocol, and the definition of attributes. Having done some minor programming from time to time, I am aware of the difference between wire encoding and data structures internal to an implementation. Would you be happier if I said "there are a limited number of data formats that are encoded/decoded on the wire" ? Maybe that would make it clearer that I am talking about the protocol. New formats require new encoders/decoders. Is that controversial? Re-using existing formats is usually good. Is that controversial? 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 Oct 7 06:31: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 21DCE28C161 for ; Wed, 7 Oct 2009 06:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.248 X-Spam-Level: X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[AWL=0.189, 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 K1W3jMkg5Lq5 for ; Wed, 7 Oct 2009 06:31:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 21A8228C19C for ; Wed, 7 Oct 2009 06:31:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvWbB-0002cw-EP for radiusext-data0@psg.com; Wed, 07 Oct 2009 13:30:33 +0000 Received: from [76.96.62.16] (helo=QMTA01.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvWb1-0002bD-UG for radiusext@ops.ietf.org; Wed, 07 Oct 2009 13:30:31 +0000 Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA01.westchester.pa.mail.comcast.net with comcast id pmn01c0040mv7h051pWPvk; Wed, 07 Oct 2009 13:30:23 +0000 Received: from gwzPC ([124.120.219.195]) by OMTA11.westchester.pa.mail.comcast.net with comcast id ppW91c00J4DYhCU3XpWDP6; Wed, 07 Oct 2009 13:30:21 +0000 From: "Glen Zorn" To: "'David B. Nelson'" Cc: References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> <30B10043-1F22-4AD6-8246-2F80DFA081AE@elbrysnetworks.com> In-Reply-To: <30B10043-1F22-4AD6-8246-2F80DFA081AE@elbrysnetworks.com> Subject: RE: IPv6 Date: Wed, 7 Oct 2009 20:30:00 +0700 Message-ID: <006a01ca4752$4bdd38c0$e397aa40$@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: AcpGzdNBVc79f+CoQrqhM8bxoDWDIwAgQQiw Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: David B. Nelson [mailto://dnelson@elbrysnetworks.com]: > > That same RFC 2865, in section 5, states: > > > > string 1-253 octets containing binary data (values 0 through > > 255 decimal, inclusive). Strings of length zero (0) > > MUST NOT be sent; omit the entire attribute instead. > > > > With that, Ipv6 Prefix, Route options, Auth-IPv6-Prefix-User-ID, etc > > would be pretty much covered by using the string term. > > With all due respect, the String data type is just a string of > undistinguished octets. Reference, please (don't tell me you've adopted the DeKok method of just making it up as you go, as you please!). > While you may conceptually overlay it with a > structure, i.e define sub-fields, that action creates a new data > type. In other words, the String type is just a string. You may > lament the fact that RADIUS, as defined in RFCs up through 2865, has > no method to formally define structured data, but the fact is that it > has none. There are a number of problems with this little fantasy (along with the idea that so-called "complex" attributes are not a "traditional" RADIUS data type), among them that a) RFC 2548 contains oodles of "structured data" in _very_ widely implemented and deployed attributes, b) RFC 2865 itself contains "structured data" in the CHAP-Password attribute and c) RFC 2868 (which was published the same day as 2865 -- in fact it was delayed in the queue to let 2865 go first), again, has lots of "complex" attributes and, for that matter, structured data. You may lament the fact that RADIUS has methods to define "structured data" and even try to write it out of history (as Alan apparently wishes to) but the fact is that it does. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Oct 7 07:09: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 3E4073A69C7 for ; Wed, 7 Oct 2009 07:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[AWL=0.165, 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 4aQIeSzq82XX for ; Wed, 7 Oct 2009 07:09:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD0993A6874 for ; Wed, 7 Oct 2009 07:09:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvXAg-0006nQ-3h for radiusext-data0@psg.com; Wed, 07 Oct 2009 14:07:14 +0000 Received: from [76.96.27.212] (helo=QMTA14.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvXAW-0006mT-9N for radiusext@ops.ietf.org; Wed, 07 Oct 2009 14:07:12 +0000 Received: from OMTA24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id pq3C1c00A1zF43QAEq74UX; Wed, 07 Oct 2009 14:07:04 +0000 Received: from gwzPC ([124.120.219.195]) by OMTA24.emeryville.ca.mail.comcast.net with comcast id pqBd1c00H4DYhCU8kqBhT1; Wed, 07 Oct 2009 14:11:57 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'Wojciech Dec \(wdec\)'" , "'Bernard Aboba'" , "'David B. Nelson'" , References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> <4ACBB7C1.2000900@deployingradius.com> <4ACC5B0B.9060906@deployingradius.com> <006601ca474e$c69e3a40$53daaec0$@net> <4ACC95C7.9020600@deployingradius.com> In-Reply-To: <4ACC95C7.9020600@deployingradius.com> Subject: RE: IPv6 Date: Wed, 7 Oct 2009 21:06:32 +0700 Message-ID: <007401ca4757$6b408dc0$41c1a940$@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: AcpHUQxuUiRuqaBzQAqptbbIvID9fwAAkAaA Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > > Alan DeKok [mailto://aland@deployingradius.com] writes: > >> RADIUS attributes are typed. > > > > In your mind, perhaps; in the real world (where RFC 2865 exists), one > may > > read page after page without ever seeing an attribute "typed". > > Ah... the RFC 2486 definition that the NAS-IP-Address attribute is an > "ipv4 address" is just there for joviality. Must be a typo -- RFC 2486 nowhere mentions the NAS-IP-Address attribute & doesn't contain the (case-folded) string "IPv4". What are you actually talking about? > It can really be anything > you want. This is how RFC 2865 defines the attribute: 5.4. NAS-IP-Address Description This Attribute indicates the identifying IP Address of the NAS which is requesting authentication of the user, and SHOULD be unique to the NAS within the scope of the RADIUS server. NAS-IP- Address is only used in Access-Request packets. Either NAS-IP- Address or NAS-Identifier MUST be present in an Access-Request packet. Note that NAS-IP-Address MUST NOT be used to select the shared secret used to authenticate the request. The source IP address of the Access-Request packet MUST be used to select the shared secret. A summary of the NAS-IP-Address Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 for NAS-IP-Address. Length 6 Address The Address field is four octets. That's all, "four octets". Note that the "Address" data type is defined previously in the document but it's not used here. Could be a "string" of length 4, could be an "Integer", could be an "Address". This may seem frivolous, but it's related to David's comments in another message: it actually doesn't matter what the data type is because everybody _knows_ that it's an IPv4 address -- we are 'conceptually overlaying' the 4 octet field with a contiguous sub-field interpreted as an IPv4 address. The same thing happens all over the place in RFC 2865 and if David is correct then the "data" fields in probably half the attributes defined therein are unique data types. > > Or, as the design guidelines document says: > > Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does > not define a formal data definition language. A handful of basic > data types are provided, and a data type is associated with an > attribute when the attribute is defined. But that's not true, either - a single counterexample would suffice & I've already given half a dozen. > > >> The list of types is small. Each type > >> is statically defined in an RFC. > > > > In what RFC is the "8-bit Tag + 24-bit Integer" "data type" defined? > That's > > easy, none. The fact that some implementations _treat_ it as a "data > type" > > doesn't make it so, since there are other ways to implement a tag. > > Strange. I was talking about the protocol, and the definition of > attributes. Having done some minor programming from time to time, I just want to note that I deserve MAJOR style points for letting that one pass ;-). > I am > aware of the difference between wire encoding and data structures > internal to an implementation. > > Would you be happier if I said "there are a limited number of data > formats that are encoded/decoded on the wire" ? Maybe that would make > it clearer that I am talking about the protocol. I'd be happier if you didn't use the same term to name two entirely different things. > > New formats require new encoders/decoders. Is that controversial? > > Re-using existing formats is usually good. Is that controversial? Both those statements seem implementation-specific to me. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Oct 7 08:58:22 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 E8F1028C18C for ; Wed, 7 Oct 2009 08:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[AWL=-0.352, 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 SVdyD05-H0WQ for ; Wed, 7 Oct 2009 08:58:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA7CB28C1A4 for ; Wed, 7 Oct 2009 08:58:21 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvYsO-000Kvs-I1 for radiusext-data0@psg.com; Wed, 07 Oct 2009 15:56:28 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvYs9-000Ktu-7r for radiusext@ops.ietf.org; Wed, 07 Oct 2009 15:56:21 +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 A1BC612344AA; Wed, 7 Oct 2009 17:56:11 +0200 (CEST) Message-ID: <4ACCBA1B.20302@deployingradius.com> Date: Wed, 07 Oct 2009 17:56:11 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: "'Wojciech Dec (wdec)'" , 'Bernard Aboba' , "'David B. Nelson'" , radiusext@ops.ietf.org Subject: Re: IPv6 References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> <4ACBB7C1.2000900@deployingradius.com> <4ACC5B0B.9060906@deployingradius.com> <006601ca474e$c69e3a40$53daaec0$@net> <4ACC95C7.9020600@deployingradius.com> <007401ca4757$6b408dc0$41c1a940$@net> In-Reply-To: <007401ca4757$6b408dc0$41c1a940$@net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote: > Alan DeKok [mailto:aland@deployingradius.com] writes: >> Ah... the RFC 2486 definition that the NAS-IP-Address attribute is an >> "ipv4 address" is just there for joviality. > > Must be a typo -- RFC 2486 nowhere mentions the NAS-IP-Address attribute & > doesn't contain the (case-folded) string "IPv4". What are you actually > talking about? You're right. It defines a 32-bit IP address that is completely unrelated to IPv4. > That's all, "four octets". Note that the "Address" data type is defined > previously in the document but it's not used here. Could be a "string" of > length 4, could be an "Integer", could be an "Address". This may seem > frivolous, but it's related to David's comments in another message: it > actually doesn't matter what the data type is because everybody _knows_ that > it's an IPv4 address -- we are 'conceptually overlaying' the 4 octet field > with a contiguous sub-field interpreted as an IPv4 address. Of course. Just like we're conceptually overlaying "octets", where there are really groups of "0" and "1" bits. At some point this abstraction becomes absurd. > The same thing > happens all over the place in RFC 2865 and if David is correct then the > "data" fields in probably half the attributes defined therein are unique > data types. See my previous audit of RFC and vendor attributes posted to this list. About 95% use the simple standard data types. (IP address, integer, text, etc. but not string) >> Or, as the design guidelines document says: >> >> Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does >> not define a formal data definition language. A handful of basic >> data types are provided, and a data type is associated with an >> attribute when the attribute is defined. > > But that's not true, either - a single counterexample would suffice & I've > already given half a dozen. See my previous audit of RFC and vendor attributes posted to this list. There are 8 common data types. That's "a handful". And 95% of attributes use this "handful". I think the confusion here is I'm talking about real-world, imprecise, imperfect practice. So "common use" means "95%". And "a handful" means "8". You're arguing from a point of perfection. Because ONE attribute is of a unique complex type, it means that any attempt to use standard types is useless. OK... let's give up trying to re-use common types. Let's define novel on-the-wire encodings for every single new attribute. That will really accelerate the progress of documents in this WG! >> New formats require new encoders/decoders. Is that controversial? >> >> Re-using existing formats is usually good. Is that controversial? > > Both those statements seem implementation-specific to me. I welcome an implementation which can encode and decode novel formats with zero changes to the software (binaries, config files, dictionaries, etc.) That's some kind of magic bean you're selling. 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 Oct 7 09:32:20 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 4BB0A3A6930 for ; Wed, 7 Oct 2009 09:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=0.147, 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 3trUQS1buuKX for ; Wed, 7 Oct 2009 09:32:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 46DE43A6902 for ; Wed, 7 Oct 2009 09:32:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvZO2-000OGL-Q7 for radiusext-data0@psg.com; Wed, 07 Oct 2009 16:29:10 +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 1MvZNs-000OF0-SY for radiusext@ops.ietf.org; Wed, 07 Oct 2009 16:29:08 +0000 Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA05.westchester.pa.mail.comcast.net with comcast id pn6r1c0030EZKEL55sV0ck; Wed, 07 Oct 2009 16:29:00 +0000 Received: from gwzPC ([124.120.219.195]) by OMTA01.westchester.pa.mail.comcast.net with comcast id psUe1c00B4DYhCU3MsUifm; Wed, 07 Oct 2009 16:28:58 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'Wojciech Dec \(wdec\)'" , "'Bernard Aboba'" , "'David B. Nelson'" , References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> <4ACBB7C1.2000900@deployingradius.com> <4ACC5B0B.9060906@deployingradius.com> <006601ca474e$c69e3a40$53daaec0$@net> <4ACC95C7.9020600@deployingradius.com> <007401ca4757$6b408dc0$41c1a940$@net> <4ACCBA1B.20302@deployingradius.com> In-Reply-To: <4ACCBA1B.20302@deployingradius.com> Subject: RE: IPv6 Date: Wed, 7 Oct 2009 23:28:27 +0700 Message-ID: <00af01ca476b$3f842ca0$be8c85e0$@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: AcpHZrRCgIE85/AHQLSMbK8ko7NBwwAA1H4g Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok [mailto:aland@deployingradius.com] writes: ... > I think the confusion here is I'm talking about real-world, > imprecise, > imperfect practice. So "common use" means "95%". And "a handful" > means > "8". > > You're arguing from a point of perfection. No, I'm arguing what the standards _actually_ say, while you are arguing what you _want_ them to say. > Because ONE attribute is > of a unique complex type, it means that any attempt to use standard > types is useless. It's hardly just one, but the point is that "complex" types are as standard as any other of those either specifically defined in RFCs or those that were not (like 64-bit integers) of which you apparently approve. ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Oct 7 09:50:45 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 3F10528C270 for ; Wed, 7 Oct 2009 09:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.125 X-Spam-Level: X-Spam-Status: No, score=0.125 tagged_above=-999 required=5 tests=[AWL=0.619, 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 P8hac5HZTest for ; Wed, 7 Oct 2009 09:50:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 39ED528C1EA for ; Wed, 7 Oct 2009 09:50:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvZgi-000194-SY for radiusext-data0@psg.com; Wed, 07 Oct 2009 16:48:28 +0000 Received: from [65.55.116.14] (helo=blu0-omc1-s3.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvZgX-00016F-A6 for radiusext@ops.ietf.org; Wed, 07 Oct 2009 16:48:24 +0000 Received: from BLU137-W31 ([65.55.116.9]) by blu0-omc1-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 09:48:16 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_0e467691-9943-4753-8f2f-5a6f915bf0f4_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Virtual interim discussion of the IPv6 document Date: Wed, 7 Oct 2009 09:48:16 -0700 Importance: Normal In-Reply-To: <4ACCBA1B.20302@deployingradius.com> References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> <4ACBB7C1.2000900@deployingradius.com> <4ACC5B0B.9060906@deployingradius.com> <006601ca474e$c69e3a40$53daaec0$@net> <4ACC95C7.9020600@deployingradius.com> <007401ca4757$6b408dc0$41c1a940$@net> <4ACCBA1B.20302@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 Oct 2009 16:48:16.0965 (UTC) FILETIME=[F7E7C750:01CA476D] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_0e467691-9943-4753-8f2f-5a6f915bf0f4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have reserved time on the October 13 Virtual Interim agenda for discussi= on of the IPv6 document.=20 In order to structure the discussion=2C I would like to solicit presentatio= ns relating to the following aspects: a. Broadband Forum requirements for IPv6 over PPP support b. Pros and Cons of potential encoding approaches 1. Use of Extended Attributes tagging mechanism 2. RA string encoding 3. Definition of new tagged data types Do we have volunteers for these presentations? =20 In order to make the slides available in time=2C I'd like get all presentat= ion materials by October 11.=20 = --_0e467691-9943-4753-8f2f-5a6f915bf0f4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have reserved time on the October 13 Virtual Interim agenda for discussi= on of the IPv6 document.

In order to structure the discussion=2C I = would like to solicit presentations relating to the following aspects:
<= br>a. Broadband Forum requirements for IPv6 over PPP support
b. Pros and= Cons of potential encoding approaches
 =3B  =3B 1. =3B Use = of Extended Attributes tagging mechanism
 =3B =3B =3B 2.&nbs= p=3B RA string encoding
 =3B =3B =3B 3. =3B Definition o= f new tagged data types

Do we have volunteers for these presentation= s? =3B

In order to make the slides available in time=2C I'd lik= e get all presentation materials by October 11.
= --_0e467691-9943-4753-8f2f-5a6f915bf0f4_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Oct 7 11:28: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 C82323A69EB for ; Wed, 7 Oct 2009 11:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.884 X-Spam-Level: X-Spam-Status: No, score=-0.884 tagged_above=-999 required=5 tests=[AWL=-0.389, 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 IEdgARP9lL3J for ; Wed, 7 Oct 2009 11:28:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D213E3A6929 for ; Wed, 7 Oct 2009 11:28:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvbDV-000Bo9-LG for radiusext-data0@psg.com; Wed, 07 Oct 2009 18:26:25 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MvbDM-000BmU-0j for radiusext@ops.ietf.org; Wed, 07 Oct 2009 18:26:23 +0000 Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 4326712344AA; Wed, 7 Oct 2009 20:26:14 +0200 (CEST) Message-ID: <4ACCDD45.7080907@deployingradius.com> Date: Wed, 07 Oct 2009 20:26:13 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: "'Wojciech Dec (wdec)'" , 'Bernard Aboba' , "'David B. Nelson'" , radiusext@ops.ietf.org Subject: Re: IPv6 References: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> <4ACB5A24.1000400@deployingradius.com> <4ACB9EBB.9010304@deployingradius.com> <4ACBB7C1.2000900@deployingradius.com> <4ACC5B0B.9060906@deployingradius.com> <006601ca474e$c69e3a40$53daaec0$@net> <4ACC95C7.9020600@deployingradius.com> <007401ca4757$6b408dc0$41c1a940$@net> <4ACCBA1B.20302@deployingradius.com> <00af01ca476b$3f842ca0$be8c85e0$@net> In-Reply-To: <00af01ca476b$3f842ca0$be8c85e0$@net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote: > No, I'm arguing what the standards _actually_ say, while you are arguing > what you _want_ them to say. I can't recall making statements about what I want the standards to say. Perhaps you could point to one of my messages which says that? >> Because ONE attribute is >> of a unique complex type, it means that any attempt to use standard >> types is useless. > > It's hardly just one, but the point is that "complex" types are as standard > as any other of those either specifically defined in RFCs or those that were > not (like 64-bit integers) of which you apparently approve. Ah. Like the "standard" attributes defined in RFC 2548, which is "Category: Informational". In case you haven't read my messages, I'm *not* objecting to complex types. I'm objecting to the *gratuitous* use of complex types. 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 Oct 12 01:19:50 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 DC8E63A6857 for ; Mon, 12 Oct 2009 01:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=0.358, 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 DCIPRJSQGaWX for ; Mon, 12 Oct 2009 01:19:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0BB293A635F for ; Mon, 12 Oct 2009 01:19:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxG3l-0007FI-QJ for radiusext-data0@psg.com; Mon, 12 Oct 2009 08:15:13 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxG3b-0007E4-G6 for radiusext@ops.ietf.org; Mon, 12 Oct 2009 08:15:11 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id EC14E3A683C; Mon, 12 Oct 2009 01:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-design-09.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091012081501.EC14E3A683C@core3.amsl.com> Date: Mon, 12 Oct 2009 01:15:01 -0700 (PDT) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Design Guidelines Author(s) : G. Weber, A. DeKok Filename : draft-ietf-radext-design-09.txt Pages : 37 Date : 2009-10-12 This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-design-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-12010734.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Oct 12 02:38:00 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 8177928C150 for ; Mon, 12 Oct 2009 02:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.919 X-Spam-Level: * X-Spam-Status: No, score=1.919 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 DOS6IJCB6XPs for ; Mon, 12 Oct 2009 02:37:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF0CF28C149 for ; Mon, 12 Oct 2009 02:37:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxHI0-000EC3-BB for radiusext-data0@psg.com; Mon, 12 Oct 2009 09:34:00 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxHHq-000EAC-EC for radiusext@ops.ietf.org; Mon, 12 Oct 2009 09:33:58 +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 27C1D1234520; Mon, 12 Oct 2009 11:33:49 +0200 (CEST) Message-ID: <4AD2F7FC.9060103@deployingradius.com> Date: Mon, 12 Oct 2009 11:33:48 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: REMINDER: RADEXT WG Last Call on Status Server document (part 1) References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > Here is my review. > > Abstract ... > How about something more along the lines of the RFC 5176 abstract? Looks good to me. > Not sure the history is necessarily correct (e.g. I believe that the RADIUS Working Group was formed earlier). > In any case, it is probably best to focus on the purpose of this document. How about this? OK. I've added it with some minor edits. > I am not sure that the use of the term "Home Server" here adds clarity. The definition of proxy from > RFC 2607 might be more applicable: Added. I've updated the document to use "RADIUS Proxy" and "RADIUS Server" throughout. > I think this document needs an applicability section, to explain potential differences between > this specification and existing implementations, as well as why it is being published as Informational, > as opposed to Experimental or Standards Track. Suggest the following: I agree. > RFC 2865 Section 2.6 strongly discourages the use of keep-alives. > From reading this section, I am unclear whether the intent is to refute the > arguments made there, or to articulate how the uses of Status-Server > defined here go beyond those of the "test RADIUS request" described > in RFC 2865. The idea is to state that the Status-Server does not conflict with the RFC2865 mandate against Keep-Alives. I'll re-word the text. > Overall, I wonder whether some of the introductory material in Section 4.3 > might be removed from that section and instead be revised and presented > in this section. For example: Very likely, yes. > Sections 2.1-2.2 > > I find these sections puzzling, because they suggest alternatives to the Status-Server packet > that do not serve the same function. They explain why Status-Server was chosen. I can update the titles && re-word the text slightly to make this more clear. > Section 2.3 ... > While the Status-Server packet format was not defined in RFC 2865, it was implemented by Ascend and > other vendors. As far as I know, a number of deployments did use NAS and RADIUS servers from different > vendors so that "implementation-specific definitions" would indeed have resulted in interoperability > problems. > > In any case, as I understand it, the goal of this work item is to document existing implementations of > the Status-Server extension, correct? Yes. > Section 2.3.1 ... > Given that the Status-Server packet is not forwardable, this section is a bit > confusing. Also, I'm not clear how useful the diagram is. > I'd suggest focusing on the basics of the exchange: Ok. Looks good to me. I've added text on Accounting-Message, and re-worded things a bit. > BTW, I'm curious as to whether a Status-Server packet can be sent to the address > and port (3799) of a DAS, and if so, what the appropriate response is. That was discussed and rejected earlier. This document talks about currently implemented uses of Status-Server. > Section 2.3.2 > > The Status-Server packet MUST contain a Message-Authenticator > attribute for security. > > Given that implementations exist that did not support Message-Authenticator, my suggestion is that this > become a SHOULD. I'm wary of this one. I would say that new implementations MUST use Message-Authenticator. Making it a "SHOULD" means that a lot of people will ignore it. 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 Oct 12 02:55:13 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 144E93A68A5 for ; Mon, 12 Oct 2009 02:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.012 X-Spam-Level: ** X-Spam-Status: No, score=2.012 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, 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 hNcL4538Tzo2 for ; Mon, 12 Oct 2009 02:55:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EA5C33A68E7 for ; Mon, 12 Oct 2009 02:55:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxHZW-000GIe-9v for radiusext-data0@psg.com; Mon, 12 Oct 2009 09:52:06 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxHZM-000GGY-4F for radiusext@ops.ietf.org; Mon, 12 Oct 2009 09:52:03 +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 05D6E1234520; Mon, 12 Oct 2009 11:51:54 +0200 (CEST) Message-ID: <4AD2FC3A.80806@deployingradius.com> Date: Mon, 12 Oct 2009 11:51:54 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: REMINDER: RADEXT WG Last Call on Status Server document (part 2) References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: .. > [BA] Can you provide a section reference for the Tw timer? Done. ... > [BA] I think a bit more explanation would be helpful here. Traditional "failover" algorithms have > depended on use of Access-Request packets. Unfortunately, these techniques can lead a client to failover > in circumstances where there is nothing wrong with the primary proxy. So in reading the first paragraph, > I'm unclear what is being advocated, precisely. For example, is it being advocated that a Status-Server > packet be sent to the primary proxy after a number of Access-Requests do not receive a response? That > would help determine whether the primary proxy was the issue in the first place. If it is not the issue > (e.g. primary proxy responds), then sending Status-Server packets to the primary proxy would seem > pointless. OK. I've added some text to the document that will hopefully clarify this. > Section 4.4 > > The point that Status-Server packets are non-forwardable is quite central to the document, so it would > be a good idea to make the point earlier. That is addressed in the updates from the previous message. > Section 4.5 > > 4.5. Realm Routing ... > > [BA] What mechanism? Since Status-Server packets are non-forwardable, there no concept of a destination > realm, right? Yes. I've clarified the wording in the first paragraph. > Overall, I think this section might be retitled "Limitations of Status-Server" because that is really the > main focus. OK. > On reading this section, the thought did occur to me that in the cause where Status-Server indicated > a downstream failure that "per-realm" failover might make sense. For example, if the primary could > reach realm A but not B, there is no point in failing over all Requests to the secondary, just those > for realm B. Of course, it is also possible that a fault in a downstream node that prevented > reaching realm A (e.g. a failure in a server for realm A) might subsequently be corrected, so that > realm A might become reachable again. It's a good idea. I'm not sure if any client or server supports that behavior, however. > Section 5 > > Recommend including a row for User-Name, which presumably would have all 0s in it (e.g. User-Name is not used > in Status-Server packets, right?). The first paragraph says: Attributes other than the ones listed below SHOULD NOT be found in a Status-Server packet. I think that covers it. > What is the purpose of VSAs in Status-Server packets or Access-Responses? To permit future vendor extensions, as with normal RADIUS. 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 Oct 12 03:19: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 D08BF3A67E6 for ; Mon, 12 Oct 2009 03:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.247 X-Spam-Level: X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[AWL=0.353, 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 SC3QOVuODmgo for ; Mon, 12 Oct 2009 03:19:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E947D3A68EA for ; Mon, 12 Oct 2009 03:19:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxHvz-000IRw-KM for radiusext-data0@psg.com; Mon, 12 Oct 2009 10:15:19 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxHvk-000IQR-3T for radiusext@ops.ietf.org; Mon, 12 Oct 2009 10:15:17 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id A110C28C154; Mon, 12 Oct 2009 03:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-status-server-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091012101501.A110C28C154@core3.amsl.com> Date: Mon, 12 Oct 2009 03:15:01 -0700 (PDT) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol Author(s) : A. DeKok Filename : draft-ietf-radext-status-server-05.txt Pages : 23 Date : 2009-10-12 This document describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-status-server-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-12030024.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Oct 12 07:56: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 0C3F23A69C9 for ; Mon, 12 Oct 2009 07:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.688 X-Spam-Level: * X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_20=-0.74, 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 xnpTMg+OxzBg for ; Mon, 12 Oct 2009 07:56:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 139D43A69CC for ; Mon, 12 Oct 2009 07:56:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxMFO-000LBW-Kl for radiusext-data0@psg.com; Mon, 12 Oct 2009 14:51:38 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxMFF-000LA6-2w for radiusext@ops.ietf.org; Mon, 12 Oct 2009 14:51:36 +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 AEB1B1234520; Mon, 12 Oct 2009 16:51:27 +0200 (CEST) Message-ID: <4AD3426F.5030108@deployingradius.com> Date: Mon, 12 Oct 2009 16:51:27 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: REMINDER: Call for adoption of "RADIUS over TCP" as a RADEXT WG Work Item References: <4AA6C0B2.8040404@venaas.com> <4AB204BE.3090305@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > How about this? > > "Deployment experience with RADIUS over TLS indicates that it is > most useful for inter-server communication, such as inter-domain > communication between proxies. These situations benefit from > the confidentiality and ciphersuite negotiation that can be provided > by TLS. Since TLS is already widely available within the operating > systems used by proxies, implementation barriers are low. ... OK. I've added it with minor re-wording in places. 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 Oct 12 07:58: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 8E8313A67AB for ; Mon, 12 Oct 2009 07:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_20=-0.74, 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 RebmJkuvPCvH for ; Mon, 12 Oct 2009 07:58:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C52A03A69B5 for ; Mon, 12 Oct 2009 07:58:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxMHh-000LVs-0u for radiusext-data0@psg.com; Mon, 12 Oct 2009 14:54:01 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxMHK-000LSa-R9 for radiusext@ops.ietf.org; Mon, 12 Oct 2009 14:53:50 +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 259071234520 for ; Mon, 12 Oct 2009 16:53:38 +0200 (CEST) Message-ID: <4AD342F1.3080109@deployingradius.com> Date: Mon, 12 Oct 2009 16:53:37 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: 'radext mailing list' Subject: Refresh of the drafts X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: I've refreshed all of my current drafts, and will post slides later today. 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 Oct 12 08:03:01 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 460763A694A for ; Mon, 12 Oct 2009 08:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=0.349, 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 pS3buohkVs16 for ; Mon, 12 Oct 2009 08:03:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C66B28C1EA for ; Mon, 12 Oct 2009 08:02:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxMNh-000MNr-LU for radiusext-data0@psg.com; Mon, 12 Oct 2009 15:00:13 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxMNX-000MLX-Am for radiusext@ops.ietf.org; Mon, 12 Oct 2009 15:00:11 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 464563A68F4; Mon, 12 Oct 2009 08:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-tcp-transport-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091012150001.464563A68F4@core3.amsl.com> Date: Mon, 12 Oct 2009 08:00: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 : RADIUS Over TCP Author(s) : A. DeKok Filename : draft-ietf-radext-tcp-transport-04.txt Pages : 18 Date : 2009-10-12 The Remote Authentication Dial In User Server (RADIUS) Protocol has traditionally used the User Datagram Protocol (UDP) as it's underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (TCP), in order to address transport issues related to RADIUS over TLS [RTLS]. It is not intended to define TCP as a transport protocol for RADIUS in the absence of TLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-tcp-transport-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-tcp-transport-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-12075257.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Oct 12 11:46:13 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 E704A3A696D for ; Mon, 12 Oct 2009 11:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 EqMfUEeovQma for ; Mon, 12 Oct 2009 11:46:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A046F3A695E for ; Mon, 12 Oct 2009 11:46:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxPnN-000KJb-O0 for radiusext-data0@psg.com; Mon, 12 Oct 2009 18:38:57 +0000 Received: from [65.55.116.12] (helo=blu0-omc1-s1.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxPn5-000KI5-CL for radiusext@ops.ietf.org; Mon, 12 Oct 2009 18:38:51 +0000 Received: from BLU137-W3 ([65.55.116.7]) by blu0-omc1-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 11:38:39 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_7da9945b-7ff9-4824-bf84-5e34e4538670_" X-Originating-IP: [131.107.0.83] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RADEXT Virtual Interim Agenda - Take 3 Date: Mon, 12 Oct 2009 11:38:38 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2009 18:38:39.0428 (UTC) FILETIME=[37443040:01CA4B6B] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_7da9945b-7ff9-4824-bf84-5e34e4538670_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is the current state of the RADEXT Virtual Interim Agenda. If you are= n't on the agenda and would like to be=2C or if you are on the agenda and h= aven't sent slides=2C please send email to me IMMEDIATELY.=20 =20 RADEXT WG Virtual Interim Agenda =20 Chairs: Bernard Aboba bernard_aboba@hotmail.com David Nelson d.b.nelson@comcast.net =20 Tuesday=2C October 13=2C 2009 =20 8 AM - 10 AM PDT (11:00 - 13:00 EDT) =20 RADEXT Issues list =20 http://www.drizzle.com/~aboba/RADEXT/ =20 Agenda Slides http://www.drizzle.com/~aboba/RADEXT/oct_virtual_interim/ =20 Strawman Agenda =20 8:00 AM - 8:20 AM Preliminaries Jabber scribe Agenda Bash Document Status=20 =20 Documents completing IETF Last Call (10 minutes) =20 8:20 AM - 8:30 AM Design Guidelines=2C Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-design =20 Documents Completing WG Last Call (20 minutes) =20 8:30 AM - 8:40 AM Status-Server=2C Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-status-server =20 8:40 AM - 8:50 AM RADIUS over TCP=2C Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp-transport =20 Under Consideration for Adoption (40 minutes) =20 8:50 AM - 9:00 AM RADIUS over DTLS=2C Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-dekok-radext-dtls =20 9:00 AM - 9:10 AM RADIUS Attributes for IEEE 802 Networks=2C Bernard Aboba = (10 minutes) http://tools.ietf.org/html/draft-aboba-radext-wlan =20 9:10 AM - 9:40 AM IPv6 Attribute Design Issues=2C Hannes Tschofenig (20 min= utes) http://tools.ietf.org/html/draft-lourdelet-ipv6-access = --_7da9945b-7ff9-4824-bf84-5e34e4538670_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is the current state of the RADEXT Virtual Interim Agenda. =3B If = you aren't on the agenda and would like to be=2C or if you are on the agend= a and haven't sent slides=2C please send email to me IMMEDIATELY.
 =3B
RADEXT WG Virtual Interim Agenda
 =3B
Chairs: Bernard Aboba bernard_= aboba@hotmail.com
David Nelson d.b.nelson@comcast.n= et
 =3B
Tuesday=2C October 13=2C 2009
 =3B
8 AM - 10 AM PDT (11:00 - 13:00 EDT)
 =3B
RADEXT Issues list
 =3B
http://www.drizzle.com/~a= boba/RADEXT/
 =3B
Agenda Slides
http:= //www.drizzle.com/~aboba/RADEXT/oct_virtual_interim/
 =3B
Strawman Agenda
 =3B
8:00 AM - 8:20 AM Preliminaries
Jabber scribe
Agenda Bash
Document Status
 =3B
Documents completing IETF Last Call (10 minutes)
 =3B
8:20 AM - 8:30 AM Design Guidelines=2C Alan DeKok (10 minutes)
http://tool= s.ietf.org/html/draft-ietf-radext-design
 =3B
Documents Completing WG Last Call (20 minutes)
 =3B
8:30 AM - 8:40 AM Status-Server=2C Alan DeKok (10 minutes)
http= ://tools.ietf.org/html/draft-ietf-radext-status-server
 =3B
8:40 AM - 8:50 AM RADIUS over TCP=2C Alan DeKok (10 minutes)
http= ://tools.ietf.org/html/draft-ietf-radext-tcp-transport
 =3B
Under Consideration for Adoption (40 minutes)
 =3B
8:50 AM - 9:00 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools= .ietf.org/html/draft-dekok-radext-dtls
 =3B
9:00 AM - 9:10 AM RADIUS Attributes for IEEE 802 Networks=2C Bernard Aboba = (10 minutes)
http://tools= .ietf.org/html/draft-aboba-radext-wlan
 =3B
9:10 AM - 9:40 AM IPv6 Attribute Design Issues=2C Hannes Tschofenig (20 min= utes)
http://t= ools.ietf.org/html/draft-lourdelet-ipv6-access
 = --_7da9945b-7ff9-4824-bf84-5e34e4538670_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Oct 12 12:04:21 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 A3B993A682C for ; Mon, 12 Oct 2009 12:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.197 X-Spam-Level: ** X-Spam-Status: No, score=2.197 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_OBFU_SPLIT_HR2=0.183] 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 fDtvJq7vzWlV for ; Mon, 12 Oct 2009 12:04:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16D413A6883 for ; Mon, 12 Oct 2009 12:04:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxQ8h-000MKW-4K for radiusext-data0@psg.com; Mon, 12 Oct 2009 19:00:59 +0000 Received: from [65.55.111.171] (helo=blu0-omc4-s32.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxQ8Y-000MJw-0g for radiusext@ops.ietf.org; Mon, 12 Oct 2009 19:00:57 +0000 Received: from BLU137-DS2 ([65.55.111.137]) by blu0-omc4-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 12:00:49 -0700 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "Bernard Aboba" , Subject: RADEXT WG Virtual Interim Date: Mon, 12 Oct 2009 12:00:48 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aco9XF3MpP4HhcMSSL29JYsB/rI9DQOEfEsQ Content-Language: en-us X-OriginalArrivalTime: 12 Oct 2009 19:00:49.0115 (UTC) FILETIME=[4FD252B0:01CA4B6E] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN="Bernard Aboba";RSVP=TRUE:mailto:bernarda@microsoft.com ATTENDEE;CN=radiusext@ops.ietf.org;RSVP=TRUE:mailto:radiusext@ops.ietf.org CLASS:PUBLIC CREATED:20091012T190047Z DESCRIPTION:When: Tuesday\, October 13\, 2009 8:00 AM-10:00 AM (UTC-08:00) Pacific Time (US & Canada).\nWhere: Teleconference\n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~* ~*~*~*\n\nMeeting agenda:\nhttp://www.drizzle.com/~aboba/RADEXT/oct_virtua l_interim/oct-virtual-interim.txt\n\n\nMeeting slides:\nhttp://www.drizzle .com/~aboba/RADEXT/oct_virtual_interim/\n\n=============================== =========================================\nBernard Aboba has invited you t o attend an online meeting.\nJoin the meeting \n\nMake sure the Office Live Meeting client is installed bef ore the meeting:\n* I am connecting from outside the Microsoft network \n AUDIO INFORMATION \n To join a meeting from your phone\, dial in using the foll owing information:\n Phone: +18883203585 [English]\n Phone: +14257063500 [English]\n Find a local phone number for your region \n\n Conference ID: 9182049\n Passcode: Passcode is not required.\n Note: If you have an account on this corporate network\, use your PIN to join. Have you set your PIN? \n TROUBLESHOOTING \n Unable to join the meeting? Start Office Live Me eting and join the meeting with the following information:\n Meeting ID: 63840ffb128647eca56d51898b461c42\n Entry Code: 6650\n Location: meet:sip :bernarda@microsoft.com\;gruu\;opaque=app:conf:focus:id:63840ffb128647eca5 6d51898b461c42%3Fconf-key=6650\n\n If you still cannot enter the meeting\, contact support:\n* Inside the Microsoft network \n* Ou tside the Microsoft network \n NOTICE \n Office Live Mee ting can be used to record meetings. By participating in this meeting\, yo u agree that your communications may be monitored or recorded at any time during the meeting.\n \n \n\n\n\n -+-----+-----+-----+-----+-----+-----+-- ---+-----+-\n \n\n Bernard Aboba has invited you to attend an online meeti ng using Microsoft® Office Communications Server.\n Join the meeting \n\n Make sure the Office Live Meetin g client is installed before the meeting:\n* I am connecting from inside t he Microsoft network \n* I am connecting from outside the Microsoft network \n AUDIO INFORMATION \n To join a meeting from your phone\, dial in using the foll owing information:\n Phone: +18883203585 [English]\n Phone: +14257063500 [English]\n Find a local phone number for your region \n\n Conference ID: 9182049\n Passcode: Passcode is not required.\n Note: If you have an account on this corporate network\, use your PIN to join. Have you set your PIN? \n TROUBLESHOOTING \n Unable to join the meeting? Start Office Live Me eting and join the meeting with the following information:\n Meeting ID: 63840ffb128647eca56d51898b461c42\n Entry Code: 6650\n Location: meet:sip :bernarda@microsoft.com\;gruu\;opaque=app:conf:focus:id:63840ffb128647eca5 6d51898b461c42%3Fconf-key=6650\n\n If you still cannot enter the meeting\, contact support:\n* Inside the Microsoft network \n* Ou tside the Microsoft network \nNOTICE \nOffice Live Meeti ng can be used to record meetings. By participating in this meeting\, you agree that your communications may be monitored or recorded at any time du ring the meeting.\n\nALTERNATE ARRANGEMENTS\n\nIn event of emergency\, we have reserved a DimDim teleconference # and Web conferencing facility:\n Phone #: 702-473-3463\n Passcode: 226220\n Web conferencing: http:// webmeeting.dimdim.com/portal/JoinForm.action?meetingRoomName=aboba&email=b ernard_aboba@hotmail.com&displayName=bernard_aboba&asPresenter=false\n\n\n \n\n\n DTEND:20091013T170000Z DTSTAMP:20091012T190047Z DTSTART:20091013T150000Z LAST-MODIFIED:20091012T190047Z LOCATION:Teleconference ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:1 SUMMARY;LANGUAGE=en-us:RADEXT WG Virtual Interim TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000207BF5BC213DCA01000000000000000 01000000000B361B47DA51743AEADC01A3297B0F7 X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Tuesday\, October 13\, 2009 8:00 AM-10:00 AM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: Teleconference

\n\n

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

\n\n

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

\n\n

Meeting agenda:

\n\n

http://www.drizzle.com/~aboba/RADEXT/oct _virtual_interim/oct-virtual-interim.txt

\n
\n\n

Meeting slides:

\n\n

http://www.drizzle.com/~aboba/RADEXT/oct _virtual_interim/

\ n\n

\n\n

================================================================= =======

\n\n

Bernard Aboba has invited you to attend an online meeting.

\n\n

Join the meeting

\n\n

Make sure the Office Live Meeting client is installed before the meetin g:

\n
    \n\n

    AUDIO INFORMATION

    \n\n

    To joi n a meeting from your phone\, dial in using the following information:

    \n\n

     \; \; \;  \; \; \; \; Phone: \; +18883203 585 [English]

    \n\n

     \;&n bsp\; \; \; \; \; \; Phone:  \; +14257063500 [English]

    \n\n

     \; \; \; \; \; \; \; Find a local phone number for your region

    \n\n

     \; \; \; \; \; \; \; Conference ID: \; 9182049

    \n\n

     \; \; \; \; \; \; \; Passcode: \; \; \; \; \;  \; Passcode is not required.

    \n\n

     \; \; \; \; \; \; \; Note: If you have an account on this corporate network\, use your PIN to join. Have you set your PIN?

    \n\n

    TROUBLESHOOTING

    \n\n

    Unable to join t he meeting? \; Start Office Live Meeting and join the meeting with the following information:

    \n\n

     \; \; \; \; \; \; \; Meeting ID: \; \; \; \; 63840ffb128647eca56d51898b461c 42

    \n\n

     \; \; \ ; \; \; \; \; Entry Code: \ ; \; \; \; 6650

    \n\n

     \; \; \; \; \; \; \; Location: \; \; \; \; \; \;< SPAN LANG="en-us"> meet:sip:bernarda@microsoft.co m\;gruu\;opaque=app:conf:focus:id:63840ffb128647eca56d51898b461c42%3Fconf- key=6650

    \n\n

    If you still cannot ent er the meeting\, contact support:

    \n\n\ n

    NOTICE

    \n\n

    Office Live Meeting can be used to record meetings. By participating in this meeting\, you agree t hat your communications may be monitored or recorded at any time during th e meeting.

    \n\n

    \n \n

    \n
    \n
    \n\n

    -+-----+-----+-----+-----+-----+-----+-----+-----+-

    \n\n

    \n\n

    Bernard Aboba has invited you to attend an online meeting using Microsoft® Office Communications Server.

    \n\n

    Join the meeting

    \n\n

    Make sure the Office Live Meeting client is installed before the meeting:

    \n\n\n

    AUDIO INFORMATION

    \n\n

    To join a meeting from your phone\, dial in using the following informati on:

    \n\n

     \; \;  \; \; \; \; \; Phone: \; +1 8883203585 [English]

    \n\n

    &n bsp\; \; \; \; \; \; \; Phone: \; +14257063500 [English]

    \n\n

     \; \; \; \; \; \; \; Find a local phone number for your reg ion

    \n\n

     \; \; \; \; \; \; \; Conference ID: \; 9182049

    \n\n< P DIR=LTR> \; \; \; \; \; \;&nb sp\; Passcode: \; \; \; \;  \; \; Passcode is not required.

    \n\n

     \; \; \; \; \; \; \; Note: If you have an account on this corporate network\, u se your PIN to join. H ave you set your PIN?< /P>\n\n

    < FONT COLOR="#004D80" FACE="Tahoma">TROUBLESHOOTING

    \n\n

    Unable to join the meeting? \; Start Office Live Meeting and join the meeting w ith the following information:

    \n\n

     \; \; \; \; \; \; \; Meeting ID: \; \; \; \; 63840ffb128647eca56d518 98b461c42

    \n\n

     \; \ ; \; \; \; \; \; Entry Code : \; \; \; \; 6650

    \n\n

     \; \; \; \; \; \; \; Location: \; \; \; \; \; \;< /SPAN> meet:sip:bernarda@micro soft.com\;gruu\;opaque=app:conf:focus:id:63840ffb128647eca56d51898b461c42% 3Fconf-key=6650

    \n\ n

    If you still can not enter the meeting\, contact support:

    \n\n
\n

NOTICE

\n\n

Office Live Meeting can be used to record meetings. By participating in this meeting\, you agree that your communications may be monitored or recorded at any ti me during the meeting.

\n\n

AL TERNATE ARRANGEMENTS

\n\n

In event of emergency\, we have reserved a DimDim teleconference # and Web conferencing facility:

\n\n

 \; \; Phone #: \; 702-473- 3463

\n\n

 \; \; Passcode: 226220

\n\n

< SPAN LANG="en-us"> \; \; Web conferenci ng: http://webmeeting.dimdim.com/porta l/JoinForm.action?meetingRoomName=aboba&\;email=bernard_aboba@hotmail.c om&\;displayName=bernard_aboba&\;asPresenter=false

\n
\n
\n\n

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTSEQTIME:20090924T213026Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Oct 12 16:38: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 740A53A682E for ; Mon, 12 Oct 2009 16:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.785 X-Spam-Level: * X-Spam-Status: No, score=1.785 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_50=0.001, 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 iMd3-QHwC-LV for ; Mon, 12 Oct 2009 16:38:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 73CB73A677E for ; Mon, 12 Oct 2009 16:38:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxUP0-000IER-3h for radiusext-data0@psg.com; Mon, 12 Oct 2009 23:34:06 +0000 Received: from [65.55.116.47] (helo=blu0-omc1-s36.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxUOq-000ICo-FS for radiusext@ops.ietf.org; Mon, 12 Oct 2009 23:34:04 +0000 Received: from BLU137-DS2 ([65.55.116.7]) by blu0-omc1-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 16:33:56 -0700 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Subject: RADEXT WG Virtual Interm, October 13, 2009 Date: Mon, 12 Oct 2009 16:33:55 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_056E_01CA4B59.CA8DBEA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpLlGc0bXtmY76ARuyDAadeKBwuygAAAdhQ Content-Language: en-us X-OriginalArrivalTime: 12 Oct 2009 23:33:56.0282 (UTC) FILETIME=[775591A0:01CA4B94] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_056E_01CA4B59.CA8DBEA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The RADEXT WG Virtual Interim is taking place tomorrow, October 13, 2009 from 8 AM PDT to 10 AM PDT. Here is a link to the agenda and teleconference parameters for the meeting: http://www.drizzle.com/~aboba/RADEXT/oct_virtual_interim/oct-virtual-interim .txt Slide presentations for the meeting are available here: http://www.drizzle.com/~aboba/RADEXT/oct_virtual_interim/ ------=_NextPart_000_056E_01CA4B59.CA8DBEA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The RADEXT WG Virtual Interim is taking place = tomorrow, October 13, 2009 from 8 AM PDT to 10 AM PDT. 

 

Here is a link to the agenda and teleconference = parameters for the meeting:

http://www.drizzle.com/~aboba/RADEXT/oct_virtual_interim= /oct-virtual-interim.txt

 

Slide presentations for the meeting are available = here:

http://www.drizzle.com/~aboba/RADEXT/oct_virtual_interim/

 

 

 

------=_NextPart_000_056E_01CA4B59.CA8DBEA0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 13 12:41:35 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 EE2CB28C2C0 for ; Tue, 13 Oct 2009 12:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.31 X-Spam-Level: * X-Spam-Status: No, score=1.31 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_05=-1.11, 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 fm3Iyp-prBgg for ; Tue, 13 Oct 2009 12:41:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6CF5528C342 for ; Tue, 13 Oct 2009 12:41:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mxn9O-0003VJ-Gz for radiusext-data0@psg.com; Tue, 13 Oct 2009 19:35:14 +0000 Received: from [65.55.116.12] (helo=blu0-omc1-s1.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mxn97-0003Tu-EZ for radiusext@ops.ietf.org; Tue, 13 Oct 2009 19:35:06 +0000 Received: from BLU137-W14 ([65.55.116.7]) by blu0-omc1-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 12:34:57 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_538042d2-1b43-4715-b19f-edf438b88c70_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Draft RADEXT Virtual Interim Minutes Date: Tue, 13 Oct 2009 12:34:57 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 13 Oct 2009 19:34:57.0276 (UTC) FILETIME=[3F08A3C0:01CA4C3C] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_538042d2-1b43-4715-b19f-edf438b88c70_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is a draft of the RADEXT WG Virtual Interim Minutes.=20 Please take a look at these minutes and add/edit/correct as necessary.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Minutes of the RADEXT WG Virtual Interim October 13=2C 2009 Design Guidelines Alan: -09 has been submitted. This includes a number of clarifications with respect to tags=2C VSA formats=2C simple versus complex types. =20 There are no MUSTs or MUST NOTs in the document. Guidelines try to encourage good practice=2C but should not be followed slavishly.=20 Dan: Jari has cleared his discuss. So the document could be sent to the RFC Editor for publication immediately. =20 Bernard: Not clear that the document is ready.=20 There are still two open issues from IETF last call: Issues 313 and 314.=20 Issue 313 concerns the "security exemption". Does this apply to any attrib= ute relating to security or authentication? There was confusion on this point during the review of the PKMv1 document.=20 For user authentication or RADIUS security attributes there is computation= =20 involved: the client has to compute something and the server has to verify= =2C or vice-versa. If an attribute relates to security (e.g. sending a certifi= cate)=20 but there is no computation=2C does the exemption still apply? In that case=2C it might have been possible to use the String type=2C but a complex attribute would require new code on both the client a= nd server.=20 Issue 314 was filed by Hannes. It was to be followed by specific text to a= ddress the concerns=2C but this wasn't provided. Hannes: The state of the art has advanced. In some designs addition of co= de is no longer a big issue=2C scripts can be plugged in. Also=2C parsers have i= mproved=2C and could enable complex attributes to be supported automatically.=20 So are we locking ourselves into the past?=20 David Nelson: Many RADIUS server implementations utilize a data dictionary= . This allows administrators to add the definition of a new attribute without havi= ng to upgrade the server. If an attribute doesn't have to require a server upgra= de=2C that is probably a good thing. =20 Bernard: There are a lot of legacy RADIUS servers out there that implement the data dictionary model described in RFC 2865. For those implementation= s=2C the data dictionary provides benefits. It can save administrators time and money=2C allowing them to support a new attribute immediately without w= aiting for a RADIUS server upgrade.=20 David Nelson: It is also possible to use opaque attributes=2C where the da= ta is not parsed by RADIUS but by some other component. Those attributes are sent to and from a plugin. =20 Dan Romascanu: There is also the question of whether normative language is= being used in the same way as described in RFC 2119. =20 Do we need to update the draft?=20 Bernard Aboba: How about an RFC Editor note?=20 Dan: That would be easier.=20 David Nelson: I think it would be best to get the document published and t= hen see how well it works in the real world. Bernard: So far=2C we've used it in reviewing two documents=2C the PKMv1 d= ocument=2C and the IPv6 access document. In both cases=2C there was confusion about how the g= uidelines applied that required clarifications in the text. So the "real world" experience i= s not so good.=20 That's why the document has taken so long to finish.=20 =20 Bernard: Alan -- can you take the action item to work with Dan on addressin= g the RFC 2119 issue as well as proposing an RFC Editor note to address issue 313?=20 Status Server Alan: This draft was revised. An applicability subsection was added. The= re were some terminology changes. =20 David Nelson: Does this document just describe what has been deployed=2C o= r does it also describe how Status-Server is used in RADSEC? Alan: It is focused on what has been implemented. The RADSEC document use= s Status-Server as an RFC 3539 Watchdog=2C but that is covered in the RADSEC document.=20 Bernard: Status-Server was originally implemented by Ascend in their concen= trators.=20 Alan: It was subsequently implemented in RADIATOR and FreeRADIUS. =20 Bernard: It would be good if we could get some additional reviewers to loo= k at whether the document accurately describes their implementations. This isn't a stan= dards-track document=3B its job is just to describe what has been implemented. Do we = have any volunteers: David Nelson: I will take a look at it.=20 RADIUS over TCP Alan: We added text to the applicability section. We're now using the ter= m "RADIUS over TLS" instead of a vendor's product name (RADSEC). We also added text on the head-of-line= blocking issue. =20 Bernard: As I recall=2C Magnus (Transport AD) raised this issue initially.= What can be done to address this=20 issue other than opening multiple TCP connections? Alan: Nothing. Dan: What is the issue specifically? Alan: If a packet is lost=2C then all traffic that was intended to travel = on the TCP connection has to wait until the data at the head-of-the-line is acknowledged. This isn't an= issue with UDP.=20 Hannes: One of the reasons we created the SCTP transport for Diameter was = to address the head-of-line blocking issue. But SCTP has not been widely implemented. Alan: For those that are interested=2C FreeRADIUS now supports RADIUS over = TCP=2C so you can play with it. Bernard: Does the latest revision address Issues 315 and 316? Alan: Yes. Bernard: OK. If there are no open issues=2C then we could do another WG la= st call. RADIUS over DTLS Alan: RDTLS has been implemented in Stefan's RADSEC Proxy. I am implement= ing it as well.=20 This draft was not revised.=20 David Nelson: Isn't this draft expired? What is the status? Alan: It is not expired. =20 Bernard: We issued a call for interest. Only one or two people responded.= There are no open issues at the moment. We need more reviews. IEEE 802 Attributes Dan Romascanu: Is this document only about WLAN attributes or wired IEEE 8= 02 attributes as well? Are the attributes usable on multiple technologies?=20 Bernard: A number of the attributes are specific to a technology. For exam= ple=2C there are attributes that relate to IEEE 802.11r specifically. There are also attributes that r= elate to IEEE 802.1X-REV.=20 Joe Salowey: IEEE 802.1X-REV does apply to wireless=2C but there are aspec= ts (such as announcements) that were only meant to be implemented on wired networks. =20 Bernard: At one point we had attributes specific to IEEE 802.11s=2C but th= e security model changed=2C so we removed them. =20 David Nelson: What is the status of the document? Bernard Aboba: IEEE 802.1X-REV has completed Sponsor Ballot. We were wait= ing until the resolution of Sponsor Ballot comments to align the document with IEEE 802.1X-REV.=20 Joe Salowey: IEEE 802.1X-REV is now going into recirculation ballot. So it= is a good time to look at it again.=20 Bernard Aboba: The document is referenced in Appendix E of IEEE 802.1X-REV= . But it is not a normative dependency.=20 Joe Salowey: Now that IEEE 802.1X-REV has settled down=2C I will review th= e document again=2C to see what changes may be needed.=20 Bernard Aboba: After Joe is done with his review=2C what are the next step= s? =20 Dan Romascanu: For a standards track document=2C it can either be a WG wor= k item=2C or an AD sponsored document. I would prefer a WG work item. Bernard: There was a call for interest in November 2007=2C but it never co= mpleted. So the document has been in limbo for almost two years now.=20 David Nelson: Did anyone respond to the call? Bernard Aboba: Some people responded=2C yes.=20 David Nelson: I was waiting for IEEE 802.1 to send their requirements.=20 Bernard Aboba: IEEE 802.1 provided their review of -08 in July 2008. That= is now up on the liaison archive. David Nelson: We can either send the document to the RFC Editor or run a qu= ick WG last call on it=2C once it is aligned with IEEE 802.1X-REV.=20 IPv6 Attribute Design Considerations Hannes: This document initially did not have much interest=2C then there w= as a lot of discussion on the list due to interest from the Broadband Forum. There are a number of ways = to address the review from Alan. The document utilizes a tagging scheme similar to=2C but not exactly= the same as RFC 2868. The authors did not want to depend on Extended Attributes since it has not been= progressing (and is now expired). =20 Bernard: It seems like many of the attributes that are tagged relate to a = router advertisement=2C correct? Hannes: That is my understanding.=20 Bernard: One of the objections to the current scheme is that it creates mu= ltiple new tagged data types.=20 A new attribute is needed for each element of the RA that needs to be expre= ssed. It occurred to me that it might actually be easier to define an opaque blob that carries much of (= or the entire) RA. =20 David Nelson: It seems like the lack of progress on Extended Attributes is = creating a problem. Design Guidelines says that the RFC 2868 tagging scheme isn't suitable for generic= use. But it doesn't make a recommendation. If we don't get Extended Attributes done=2C then we will= be creating a problem.=20 After finishing Design Guidelines=2C it seems like this needs to be our #2 = priority.=20 Bernard: Agreed. To be clear though=2C this document does not currently d= epend on Extended Attributes.=20 Question: If Extended Attributes were further along=2C would this document= use it?=20 David Miles: I don't think so. =20 David Nelson: It seems like there are a number of use cases here=2C and th= ey are not clearly described.=20 Bernard: Previous documents have had very well defined uses cases. RFC 31= 62 supports address auto- configuration. RFC 4818 supports DHCPv6 Prefix Delegation. This document = supports multiple modes=2C and that is confusing.=20 David Miles: In looking at the attribute list=2C there are a set of attrib= utes relating to router advertisements that require tagging=2C but another set of attributes like IPv6-Address and= IPv6-DNS-Server-Address that do not.=20 Would it make sense to split the document into two parts=2C one focusing on= DHCPv6=2C and the other one on router advertisements?=20 Bernard Aboba: Yes=2C I think this would help. David Nelson: Which attributes are you interested in? David Miles: For the Broadband Forum=2C IPv6-Address is of the most immedia= te interest. IPv6-DNS-Server-Address=20 is relevant but isn't as important since in most cases name resolution is b= eing handled over IPv4.=20 Bernard Aboba: If that is what you need=2C then focusing on that would ena= ble things to go forward much more quickly. Can you put a document together that focuses on that?=20 David Miles: There is already a document that does that.=20 David Nelson: Which one?=20 David Miles: http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-0= 0 Bernard Aboba: Yes=2C that document just handles the attributes you are in= terested in. However=2C it confused the WG because it only talked about DHCPv6 and RADIUS=2C but did not talk a= bout authentication. RADIUS is spoken between a RADIUS client and server. So if the RADIUS client is also= a DHCPv6 server=2C then it makes sense. But if the DHCPv6 server is separate=2C then it's not clear how it = works. Does the NAS pass the RADIUS attributes to the DHCPv6 server=2C and if so=2C how? Is there authe= ntication going on between the DHCPv6 server and the RADIUS server? If there are no authentication attrib= utes is this a Call Check=2C or is it changing the RADIUS protocol in some way? =20 David Miles: I can include material on the Broadband Forum scenarios. If = I work with Benoit to create an -01 with that additional material would that help? Bernard Aboba: Yes=2C it would help a great deal.=20 Summary/Wrapup Bernard: At the last virtual interim=2C the feedback on DimDim was not ver= y positive. So we tried LiveMeeting this time. How did it work for people= ?=20 Dan Romascanu: The conference bridge was fine.=20 Alan DeKok: I could not use the web conferencing software=2C it was only a= vailable on Windows.=20 Dan Romascanu: It required me to install additional software (Outlook addi= n). That is a big deal.=20 Bernard Aboba: DimDim also required a software install. Though it support= ed more platforms.=20 David Nelson: Having a teleconference bridge=2C Jabber and slides is fine.= =20 David Miles: As long as the slides don't get too long or there are too ma= ny people in the meeting. Otherwise it's easy to lose your place.=20 Bernard Aboba: They had a session on WebEx at IETF 75=2C in the Working Gr= oup Chairs meeting. I asked the Secretariat if we could get access=2C but = didn't get a response. So it was either DimDim or LiveMeeting.=20 Dan Romascanu: I will inquire about the availability of WebEx.=20 Bernard: Let's talk about the plans for IETF 76. The RADEXT WG is not curre= ntly scheduled to meet at IETF 76. We have just completed the Virtual Inte= rim=2C and=20 IETF 76 is in just a few weeks.=20 Dan Romascanu: Who is attending? David Nelson: I will not attend.=20 Bernard: No Alan DeKok: No Hannes: Yes Dan Romascanu: There are disadvantages to not holding a meeting at IETF 76= . You will miss the opportunity to interact with the community=2C particul= arly participants from Asia. =20 It would be good to have a representative at IETF 76. Hannes is very busy= =2C but perhaps you can find someone to represent RADEXT.=20 Bernard: If there is WebEx available=2C we could participate remotely.=20 Dan Romascanu: I will look into supporting WebEx at the OPS Area Meeting. = There are cost concerns.=20 = --_538042d2-1b43-4715-b19f-edf438b88c70_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Here is a draft of the RAD= EXT WG Virtual Interim Minutes.

Please take a look at these minutes= and add/edit/correct as necessary.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Minutes of the RADEXT WG Virtual In= terim
October 13=2C 2009

Design Guidelines

Alan: =3B -= 09 has been submitted. =3B This includes a number of clarifications
= with respect to tags=2C VSA formats=2C simple versus complex types. =3B=
There are no MUSTs or MUST NOTs in the document. =3B Guidelines tr= y to
encourage good practice=2C but should not be followed slavishly.
Dan: Jari has cleared his discuss. =3B So the document could be s= ent to the
RFC Editor for publication immediately. =3B

Berna= rd: =3B Not clear that the document is ready.
There are still two o= pen issues from IETF last call: Issues 313 and 314.

Issue 313 conce= rns the "security exemption". =3B Does this apply to any attribute
r= elating to security or authentication? =3B There was confusion on this = point
during the review of the PKMv1 document.

For user authenti= cation or RADIUS security attributes there is computation
involved:&nbs= p=3B the client has to compute something and the server has to verify=2Cor vice-versa. =3B If an attribute relates to security (e.g. sending a= certificate)
but there is no computation=2C does the exemption still a= pply?
In that case=2C it might have been possible to use the String
t= ype=2C but a complex attribute would require new code on both the client an= d server.

Issue 314 was filed by Hannes. =3B It was to be follo= wed by specific text to address the
concerns=2C but this wasn't provided= .

Hannes: =3B The state of the art has advanced. =3B In some= designs addition of code is
no longer a big issue=2C scripts can be plu= gged in. =3B Also=2C parsers have improved=2C
and could enable compl= ex attributes to be supported automatically.
So are we locking ourselve= s into the past?

David Nelson: =3B Many RADIUS server implement= ations utilize a data dictionary. =3B This
allows administrators to = add the definition of a new attribute without having to
upgrade the serv= er. =3B If an attribute doesn't have to require a server upgrade=2C tha= t
is probably a good thing. =3B

Bernard: =3B There are a= lot of legacy RADIUS servers out there that implement
the data dictiona= ry =3B model described in RFC 2865. =3B For those implementations= =2C
the data dictionary provides benefits. =3B It can save administr= ators time
and money=2C allowing them to support a new attribute immedia= tely without waiting for
a RADIUS server upgrade.

David Nelson:&= nbsp=3B It is also possible to use opaque attributes=2C where the data
i= s not parsed by RADIUS but by some other component. =3B Those attribute= s
are sent to and from a plugin. =3B

Dan Romascanu: =3B = There is also the question of whether normative language is being used
i= n the same way as described in RFC 2119. =3B

Do we need to upda= te the draft?

Bernard Aboba: =3B How about an RFC Editor note? =
Dan: =3B That would be easier.

David Nelson: =3B I thin= k it would be best to get the document published and then see how
well i= t works in the real world.

Bernard: =3B So far=2C we've used it = in reviewing two documents=2C the PKMv1 document=2C and the
IPv6 access = document. =3B In both cases=2C there was confusion about how the guidel= ines applied
that required clarifications in the text. =3B So the "r= eal world" experience is not so good.
That's why the document has taken= so long to finish.
 =3B
Bernard: Alan -- can you take the actio= n item to work with Dan on addressing the RFC 2119 issue
as well as prop= osing an RFC Editor note to address issue 313?

Status Server
Alan: =3B This draft was revised. =3B An applicability subsection = was added. =3B There were some
terminology changes. =3B

= David Nelson: =3B Does this document just describe what has been deploy= ed=2C or does it also
describe how Status-Server is used in RADSEC?
<= br>Alan: =3B It is focused on what has been implemented. =3B The RA= DSEC document uses Status-Server
as an RFC 3539 Watchdog=2C but that is = covered in the RADSEC document.

Bernard: Status-Server was original= ly implemented by Ascend in their concentrators.

Alan: =3B It w= as subsequently implemented in RADIATOR and FreeRADIUS. =3B

Ber= nard: =3B It would be good if we could get some additional reviewers to= look at whether
the document accurately describes their implementations= . =3B This isn't a standards-track
document=3B its job is just to de= scribe what has been implemented. =3B =3B Do we have any
volunte= ers:

David Nelson: =3B I will take a look at it.

RADIUS = over TCP

Alan: =3B We added text to the applicability section.&n= bsp=3B We're now using the term "RADIUS over TLS" instead
of a vendor's = product name (RADSEC). We also added text on the head-of-line blocking issu= e. =3B
Bernard: =3B As I recall=2C Magnus (Transport AD) raised= this issue initially. What can be done to address this
issue other tha= n opening multiple TCP connections?
Alan: =3B Nothing.
Dan: = =3B What is the issue specifically?
Alan: =3B If a packet is lost=2C= then all traffic that was intended to travel on the TCP connection has to<= br>wait until the data at the head-of-the-line is acknowledged. =3B Thi= s isn't an issue with UDP.
Hannes: =3B One of the reasons we create= d the SCTP transport for Diameter was to address the head-of-line
blocki= ng issue. =3B But SCTP has not been widely implemented.
Alan: For th= ose that are interested=2C FreeRADIUS now supports RADIUS over TCP=2C so yo= u can play with it.
Bernard: Does the latest revision address Issues 315= and 316?
Alan: =3B Yes.
Bernard: OK. =3B If there are no ope= n issues=2C then we could do another WG last call.

RADIUS over DTLS<= br>
Alan: =3B RDTLS has been implemented in Stefan's RADSEC Proxy.&n= bsp=3B I am implementing it as well.
This draft was not revised.
Da= vid Nelson: Isn't this draft expired? =3B What is the status?
Alan:&= nbsp=3B It is not expired. =3B
Bernard: =3B We issued a call fo= r interest. =3B Only one or two people responded. =3B There are no<= br>open issues at the moment. =3B We need more reviews.

IEEE 802= Attributes

Dan Romascanu: =3B Is this document only about WLAN = attributes or wired IEEE 802 attributes as well? =3B Are
the attribu= tes usable on multiple technologies?
Bernard: A number of the attribute= s are specific to a technology. =3B For example=2C there are attributes=
that relate to IEEE 802.11r specifically. =3B There are also attrib= utes that relate to IEEE 802.1X-REV.
Joe Salowey: =3B IEEE 802.1X-R= EV does apply to wireless=2C but there are aspects (such as announcements)<= br>that were only meant to be implemented on wired networks. =3B
Be= rnard: =3B At one point we had attributes specific to IEEE 802.11s=2C b= ut the security model changed=2C so
we removed them. =3B
David N= elson: =3B What is the status of the document?
Bernard Aboba: = =3B IEEE 802.1X-REV has completed Sponsor Ballot. =3B We were waiting u= ntil the resolution of
Sponsor Ballot comments to align the document wit= h IEEE 802.1X-REV.
Joe Salowey: IEEE 802.1X-REV is now going into recir= culation ballot. =3B So it is a good time to look at
it again.
B= ernard Aboba: =3B The document is referenced in Appendix E of IEEE 802.= 1X-REV. =3B But it is not a normative
dependency.
Joe Salowey:&n= bsp=3B Now that IEEE 802.1X-REV has settled down=2C I will review the docum= ent again=2C to see what
changes may be needed.
Bernard Aboba: = =3B After Joe is done with his review=2C what are the next steps? =3B <= br>Dan Romascanu: =3B For a standards track document=2C it can either b= e a WG work item=2C or an AD sponsored
document. =3B I would prefer = a WG work item.
Bernard: =3B There was a call for interest in Novemb= er 2007=2C but it never completed. =3B So the document has
been in l= imbo for almost two years now.
David Nelson: Did anyone respond to the = call?
Bernard Aboba: =3B Some people responded=2C yes.
David Nel= son: =3B I was waiting for IEEE 802.1 to send their requirements.
B= ernard Aboba: =3B IEEE 802.1 provided their review of -08 in July 2008.=  =3B That is now up on the liaison archive.
David Nelson: We can eit= her send the document to the RFC Editor or run a quick WG last call on it= =2C once
it is aligned with IEEE 802.1X-REV.

IPv6 Attribute Desi= gn Considerations

Hannes: =3B This document initially did not ha= ve much interest=2C then there was a lot of discussion on the
list due t= o interest from the Broadband Forum. =3B There are a number of ways to = address the review from
Alan. =3B The document utilizes a tagging sc= heme similar to=2C but not exactly the same as RFC 2868. =3B The
aut= hors did not want to depend on Extended Attributes since it has not been pr= ogressing (and is now
expired). =3B

Bernard: =3B It seem= s like many of the attributes that are tagged relate to a router advertisem= ent=2C correct?
Hannes: =3B That is my understanding.
Bernard:&n= bsp=3B One of the objections to the current scheme is that it creates multi= ple new tagged data types.
A new attribute is needed for each element o= f the RA that needs to be expressed. =3B It occurred to me that
it m= ight actually be easier to define an opaque blob that carries much of (or t= he entire) RA. =3B

David Nelson: It seems like the lack of prog= ress on Extended Attributes is creating a problem. =3B Design
Guidel= ines says that the RFC 2868 tagging scheme isn't suitable for generic use.&= nbsp=3B But it doesn't make
a recommendation. =3B If we don't get Ex= tended Attributes done=2C then we will be creating a problem.
After fin= ishing Design Guidelines=2C it seems like this needs to be our #2 priority.=

Bernard: =3B Agreed. =3B To be clear though=2C this docume= nt does not currently depend on Extended Attributes.
Question: =3B = If Extended Attributes were further along=2C would this document use it?
David Miles: =3B I don't think so. =3B

David Nelson:&= nbsp=3B It seems like there are a number of use cases here=2C and they are = not clearly described.
Bernard: =3B Previous documents have had ver= y well defined uses cases. =3B RFC 3162 supports address auto-
confi= guration. =3B RFC 4818 supports DHCPv6 Prefix Delegation. =3B This = document supports multiple modes=2C
and that is confusing.

David= Miles: =3B In looking at the attribute list=2C there are a set of attr= ibutes relating to router advertisements
that require tagging=2C but ano= ther set of attributes like IPv6-Address and IPv6-DNS-Server-Address that d= o not.
Would it make sense to split the document into two parts=2C one = focusing on DHCPv6=2C and
the other one on router advertisements?
Bernard Aboba: Yes=2C I think this would help.

David Nelson: = =3B Which attributes are you interested in?

David Miles: For the Bro= adband Forum=2C IPv6-Address is of the most immediate interest. =3B IPv= 6-DNS-Server-Address
is relevant but isn't as important since in most c= ases name resolution is being handled over IPv4.

Bernard Aboba:&nbs= p=3B If that is what you need=2C then focusing on that would enable things = to go forward much more
quickly. =3B Can you put a document together= that focuses on that?

David Miles: =3B There is already a docu= ment that does that.

David Nelson: =3B Which one?

David= Miles: =3B http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp= -00

Bernard Aboba: =3B Yes=2C that document just handles the att= ributes you are interested in. =3B However=2C it confused
the WG bec= ause it only talked about DHCPv6 and RADIUS=2C but did not talk about authe= ntication. =3B RADIUS is
spoken between a RADIUS client and server.&= nbsp=3B So if the RADIUS client is also a DHCPv6 server=2C then it makessense. =3B But if the DHCPv6 server is separate=2C then it's not clear= how it works. =3B Does the NAS pass the
RADIUS attributes to the DH= CPv6 server=2C and if so=2C how? =3B Is there authentication going on b= etween the
DHCPv6 server and the RADIUS server? =3B If there are no = authentication attributes is this a Call Check=2C
or is it changing the = RADIUS protocol in some way? =3B

David Miles: =3B I can inc= lude material on the Broadband Forum scenarios. =3B If I work with Beno= it to create
an -01 with that additional material would that help?
Bernard Aboba: =3B Yes=2C it would help a great deal.

Summary= /Wrapup

Bernard: =3B At the last virtual interim=2C the feedback= on DimDim was not very positive. =3B So we tried LiveMeeting this time= . =3B How did it work for people?
Dan Romascanu: The conference bri= dge was fine.
Alan DeKok: =3B I could not use the web conferencing = software=2C it was only available on Windows.
Dan Romascanu: =3B It= required me to install additional software (Outlook addin). =3B That i= s a big deal.
Bernard Aboba: =3B DimDim also required a software in= stall. =3B Though it supported more platforms.
David Nelson: = =3B Having a teleconference bridge=2C Jabber and slides is fine.
David = Miles: =3B As long as the slides don't get too long =3B or there ar= e too many people in the meeting. =3B Otherwise it's easy to lose your = place.
Bernard Aboba: =3B They had a session on WebEx at IETF 75=2C= in the Working Group Chairs meeting. =3B I asked the Secretariat if we= could get access=2C but didn't get a response. =3B So it was
either= DimDim or LiveMeeting.
Dan Romascanu: =3B I will inquire about the= availability of WebEx.

Bernard: Let's talk about the plans for IET= F 76. The RADEXT WG is not currently scheduled to meet at IETF 76. =3B = We have just completed the Virtual Interim=2C and
IETF 76 is in just a = few weeks.
Dan Romascanu: =3B Who is attending?
David Nelson:&nb= sp=3B I will not attend.
Bernard: No
Alan DeKok: No
Hannes: YesDan Romascanu: =3B There are disadvantages to not holding a meeting a= t IETF 76. =3B You will miss the opportunity to interact with the commu= nity=2C particularly participants from Asia. =3B
It would be good t= o have a representative at IETF 76. =3B Hannes is very busy=2C but perh= aps you can find someone to represent RADEXT.
Bernard: =3B If there= is WebEx available=2C we could participate remotely.
Dan Romascanu:&nb= sp=3B I will look into supporting WebEx at the OPS Area Meeting. =3B Th= ere are cost concerns.

<= tbody>

= --_538042d2-1b43-4715-b19f-edf438b88c70_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 13 13:13: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 E94963A684A for ; Tue, 13 Oct 2009 13:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[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 Xy-5ckkHI730 for ; Tue, 13 Oct 2009 13:13:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0C84F3A68A0 for ; Tue, 13 Oct 2009 13:13:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxnV4-0005n1-LW for radiusext-data0@psg.com; Tue, 13 Oct 2009 19:57:38 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxnUo-0005kG-O3 for radiusext@ops.ietf.org; Tue, 13 Oct 2009 19:57:36 +0000 Received: (qmail 31448 invoked from network); 13 Oct 2009 19:57:20 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 13 Oct 2009 19:57:20 -0000 Message-Id: <88AFD982-0104-4612-A955-EA20FB70CE7A@elbrysnetworks.com> From: "David B. Nelson" To: radiusext@ops.ietf.org In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-4-131250442 Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Draft RADEXT Virtual Interim Minutes Date: Tue, 13 Oct 2009 15:57:20 -0400 References: X-Mailer: Apple Mail (2.936) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --Apple-Mail-4-131250442 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 13, 2009, at 3:34 PM, Bernard Aboba wrote: > > Here is a draft of the RADEXT WG Virtual Interim Minutes. > > Please take a look at these minutes and add/edit/correct as necessary. > > > > Status Server > > Alan: This draft was revised. An applicability subsection was > added. There were some > terminology changes. > > David Nelson: Does this document just describe what has been > deployed, or does it also > describe how Status-Server is used in RADSEC? > > Alan: It is focused on what has been implemented. The RADSEC > document uses Status-Server > as an RFC 3539 Watchdog, but that is covered in the RADSEC document. > > Bernard: Status-Server was originally implemented by Ascend in their > concentrators. > > Alan: It was subsequently implemented in RADIATOR and FreeRADIUS. > > Bernard: It would be good if we could get some additional reviewers > to look at whether > the document accurately describes their implementations. This isn't > a standards-track > document; its job is just to describe what has been implemented. > Do we have any > volunteers: > > David Nelson: I will take a look at it. In clarification, I will review the document for clarity and coherency, but I'm not an expert on what exactly was implemented in terms of the Status-Server feature, so I won't be able to comment on the accuracy with which the draft reflects deployments. --Apple-Mail-4-131250442 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 13, 2009, = at 3:34 PM, Bernard Aboba wrote:


Here is a draft of = the RADEXT WG Virtual Interim Minutes. 

Please take a look = at these minutes and add/edit/correct as necessary. 

<snip>

S= tatus Server

Alan:  This draft was revised.  An = applicability subsection was added.  There were some
terminology = changes.  

David Nelson:  = Does this document just describe what has been deployed, or does it = also
describe how Status-Server is used in RADSEC?

Alan:  = It is focused on what has been implemented.  The RADSEC document = uses Status-Server
as an RFC 3539 Watchdog, but that is covered in = the RADSEC document. 

Bernard: = Status-Server was originally implemented by Ascend in their = concentrators. 

Alan:  It was = subsequently implemented in RADIATOR and FreeRADIUS.  

Bernard:  It = would be good if we could get some additional reviewers to look at = whether
the document accurately describes their = implementations.  This isn't a standards-track
document; its job = is just to describe what has been implemented.   Do we have = any
volunteers:

David Nelson:  I will take a look at = it. 


In clarification, I will review the = document for clarity and coherency, but I'm not an expert on what = exactly was implemented in terms of the Status-Server feature, so I = won't be able to comment on the accuracy with which the draft reflects = deployments.


= --Apple-Mail-4-131250442-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 13 16:28:54 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 4EC863A6861 for ; Tue, 13 Oct 2009 16:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.803 X-Spam-Level: * X-Spam-Status: No, score=1.803 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_50=0.001, 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 6bRgElduouNR for ; Tue, 13 Oct 2009 16:28:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E02B23A6810 for ; Tue, 13 Oct 2009 16:28:50 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mxqdk-000PpE-VA for radiusext-data0@psg.com; Tue, 13 Oct 2009 23:18:48 +0000 Received: from [65.55.111.88] (helo=blu0-omc2-s13.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mxqdb-000PoQ-ML for radiusext@ops.ietf.org; Tue, 13 Oct 2009 23:18:47 +0000 Received: from BLU137-DS7 ([65.55.111.72]) by blu0-omc2-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 16:18:39 -0700 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'David B. Nelson'" , References: <88AFD982-0104-4612-A955-EA20FB70CE7A@elbrysnetworks.com> In-Reply-To: <88AFD982-0104-4612-A955-EA20FB70CE7A@elbrysnetworks.com> Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Tue, 13 Oct 2009 16:18:38 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01CA4C20.D2668900" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpMQagUopb6jkuKSKS0ZBK48RQ8tgAGbDVg Content-Language: en-us X-OriginalArrivalTime: 13 Oct 2009 23:18:39.0488 (UTC) FILETIME=[7F4BA800:01CA4C5B] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0049_01CA4C20.D2668900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David Nelson said: "In clarification, I will review the document for clarity and coherency, but I'm not an expert on what exactly was implemented in terms of the Status-Server feature, so I won't be able to comment on the accuracy with which the draft reflects deployments." Right. I will clarify the minutes to that effect. Ideally we would like some implementers as reviewers to address the accuracy issue. ------=_NextPart_000_0049_01CA4C20.D2668900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David Nelson said:

 

“In = clarification, I will review the document for clarity and coherency, but I'm not an expert on = what exactly was implemented in terms of the Status-Server feature, so I = won't be able to comment on the accuracy with which the draft reflects = deployments.”

 

Right.  I will clarify the minutes to that = effect.  Ideally we would like some implementers as reviewers to address the accuracy = issue. 

 

 

------=_NextPart_000_0049_01CA4C20.D2668900-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 13 23:08: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 A82CA28C0DD for ; Tue, 13 Oct 2009 23:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.183 X-Spam-Level: X-Spam-Status: No, score=0.183 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619, 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 VbQxVY0lMRFJ for ; Tue, 13 Oct 2009 23:07:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF88728C0F5 for ; Tue, 13 Oct 2009 23:07:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mxwwa-000CBP-Fg for radiusext-data0@psg.com; Wed, 14 Oct 2009 06:02:40 +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 1MxwwE-000C8w-Ol for radiusext@ops.ietf.org; Wed, 14 Oct 2009 06:02:32 +0000 Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA11.westchester.pa.mail.comcast.net with comcast id sVvE1c0070xGWP85BW2KA5; Wed, 14 Oct 2009 06:02:19 +0000 Received: from gwzPC ([124.120.219.62]) by OMTA12.westchester.pa.mail.comcast.net with comcast id sW231c0011MNGH03YW27TG; Wed, 14 Oct 2009 06:02:16 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , References: In-Reply-To: Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Wed, 14 Oct 2009 13:01:57 +0700 Message-ID: <020e01ca4c93$dd969fe0$98c3dfa0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020F_01CA4CCE.89F577E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpMPSTxkUWT8iYvRoWwk97zOuN1jAAVqV5A 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_020F_01CA4CCE.89F577E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't see a list of attendees. From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Wednesday, October 14, 2009 2:35 AM To: radiusext@ops.ietf.org Subject: Draft RADEXT Virtual Interim Minutes Here is a draft of the RADEXT WG Virtual Interim Minutes. Please take a look at these minutes and add/edit/correct as necessary. =============================================== Minutes of the RADEXT WG Virtual Interim October 13, 2009 Design Guidelines Alan: -09 has been submitted. This includes a number of clarifications with respect to tags, VSA formats, simple versus complex types. There are no MUSTs or MUST NOTs in the document. Guidelines try to encourage good practice, but should not be followed slavishly. Dan: Jari has cleared his discuss. So the document could be sent to the RFC Editor for publication immediately. Bernard: Not clear that the document is ready. There are still two open issues from IETF last call: Issues 313 and 314. Issue 313 concerns the "security exemption". Does this apply to any attribute relating to security or authentication? There was confusion on this point during the review of the PKMv1 document. For user authentication or RADIUS security attributes there is computation involved: the client has to compute something and the server has to verify, or vice-versa. If an attribute relates to security (e.g. sending a certificate) but there is no computation, does the exemption still apply? In that case, it might have been possible to use the String type, but a complex attribute would require new code on both the client and server. Issue 314 was filed by Hannes. It was to be followed by specific text to address the concerns, but this wasn't provided. Hannes: The state of the art has advanced. In some designs addition of code is no longer a big issue, scripts can be plugged in. Also, parsers have improved, and could enable complex attributes to be supported automatically. So are we locking ourselves into the past? David Nelson: Many RADIUS server implementations utilize a data dictionary. This allows administrators to add the definition of a new attribute without having to upgrade the server. If an attribute doesn't have to require a server upgrade, that is probably a good thing. Bernard: There are a lot of legacy RADIUS servers out there that implement the data dictionary model described in RFC 2865. For those implementations, the data dictionary provides benefits. It can save administrators time and money, allowing them to support a new attribute immediately without waiting for a RADIUS server upgrade. David Nelson: It is also possible to use opaque attributes, where the data is not parsed by RADIUS but by some other component. Those attributes are sent to and from a plugin. Dan Romascanu: There is also the question of whether normative language is being used in the same way as described in RFC 2119. Do we need to update the draft? Bernard Aboba: How about an RFC Editor note? Dan: That would be easier. David Nelson: I think it would be best to get the document published and then see how well it works in the real world. Bernard: So far, we've used it in reviewing two documents, the PKMv1 document, and the IPv6 access document. In both cases, there was confusion about how the guidelines applied that required clarifications in the text. So the "real world" experience is not so good. That's why the document has taken so long to finish. Bernard: Alan -- can you take the action item to work with Dan on addressing the RFC 2119 issue as well as proposing an RFC Editor note to address issue 313? Status Server Alan: This draft was revised. An applicability subsection was added. There were some terminology changes. David Nelson: Does this document just describe what has been deployed, or does it also describe how Status-Server is used in RADSEC? Alan: It is focused on what has been implemented. The RADSEC document uses Status-Server as an RFC 3539 Watchdog, but that is covered in the RADSEC document. Bernard: Status-Server was originally implemented by Ascend in their concentrators. Alan: It was subsequently implemented in RADIATOR and FreeRADIUS. Bernard: It would be good if we could get some additional reviewers to look at whether the document accurately describes their implementations. This isn't a standards-track document; its job is just to describe what has been implemented. Do we have any volunteers: David Nelson: I will take a look at it. RADIUS over TCP Alan: We added text to the applicability section. We're now using the term "RADIUS over TLS" instead of a vendor's product name (RADSEC). We also added text on the head-of-line blocking issue. Bernard: As I recall, Magnus (Transport AD) raised this issue initially. What can be done to address this issue other than opening multiple TCP connections? Alan: Nothing. Dan: What is the issue specifically? Alan: If a packet is lost, then all traffic that was intended to travel on the TCP connection has to wait until the data at the head-of-the-line is acknowledged. This isn't an issue with UDP. Hannes: One of the reasons we created the SCTP transport for Diameter was to address the head-of-line blocking issue. But SCTP has not been widely implemented. Alan: For those that are interested, FreeRADIUS now supports RADIUS over TCP, so you can play with it. Bernard: Does the latest revision address Issues 315 and 316? Alan: Yes. Bernard: OK. If there are no open issues, then we could do another WG last call. RADIUS over DTLS Alan: RDTLS has been implemented in Stefan's RADSEC Proxy. I am implementing it as well. This draft was not revised. David Nelson: Isn't this draft expired? What is the status? Alan: It is not expired. Bernard: We issued a call for interest. Only one or two people responded. There are no open issues at the moment. We need more reviews. IEEE 802 Attributes Dan Romascanu: Is this document only about WLAN attributes or wired IEEE 802 attributes as well? Are the attributes usable on multiple technologies? Bernard: A number of the attributes are specific to a technology. For example, there are attributes that relate to IEEE 802.11r specifically. There are also attributes that relate to IEEE 802.1X-REV. Joe Salowey: IEEE 802.1X-REV does apply to wireless, but there are aspects (such as announcements) that were only meant to be implemented on wired networks. Bernard: At one point we had attributes specific to IEEE 802.11s, but the security model changed, so we removed them. David Nelson: What is the status of the document? Bernard Aboba: IEEE 802.1X-REV has completed Sponsor Ballot. We were waiting until the resolution of Sponsor Ballot comments to align the document with IEEE 802.1X-REV. Joe Salowey: IEEE 802.1X-REV is now going into recirculation ballot. So it is a good time to look at it again. Bernard Aboba: The document is referenced in Appendix E of IEEE 802.1X-REV. But it is not a normative dependency. Joe Salowey: Now that IEEE 802.1X-REV has settled down, I will review the document again, to see what changes may be needed. Bernard Aboba: After Joe is done with his review, what are the next steps? Dan Romascanu: For a standards track document, it can either be a WG work item, or an AD sponsored document. I would prefer a WG work item. Bernard: There was a call for interest in November 2007, but it never completed. So the document has been in limbo for almost two years now. David Nelson: Did anyone respond to the call? Bernard Aboba: Some people responded, yes. David Nelson: I was waiting for IEEE 802.1 to send their requirements. Bernard Aboba: IEEE 802.1 provided their review of -08 in July 2008. That is now up on the liaison archive. David Nelson: We can either send the document to the RFC Editor or run a quick WG last call on it, once it is aligned with IEEE 802.1X-REV. IPv6 Attribute Design Considerations Hannes: This document initially did not have much interest, then there was a lot of discussion on the list due to interest from the Broadband Forum. There are a number of ways to address the review from Alan. The document utilizes a tagging scheme similar to, but not exactly the same as RFC 2868. The authors did not want to depend on Extended Attributes since it has not been progressing (and is now expired). Bernard: It seems like many of the attributes that are tagged relate to a router advertisement, correct? Hannes: That is my understanding. Bernard: One of the objections to the current scheme is that it creates multiple new tagged data types. A new attribute is needed for each element of the RA that needs to be expressed. It occurred to me that it might actually be easier to define an opaque blob that carries much of (or the entire) RA. David Nelson: It seems like the lack of progress on Extended Attributes is creating a problem. Design Guidelines says that the RFC 2868 tagging scheme isn't suitable for generic use. But it doesn't make a recommendation. If we don't get Extended Attributes done, then we will be creating a problem. After finishing Design Guidelines, it seems like this needs to be our #2 priority. Bernard: Agreed. To be clear though, this document does not currently depend on Extended Attributes. Question: If Extended Attributes were further along, would this document use it? David Miles: I don't think so. David Nelson: It seems like there are a number of use cases here, and they are not clearly described. Bernard: Previous documents have had very well defined uses cases. RFC 3162 supports address auto- configuration. RFC 4818 supports DHCPv6 Prefix Delegation. This document supports multiple modes, and that is confusing. David Miles: In looking at the attribute list, there are a set of attributes relating to router advertisements that require tagging, but another set of attributes like IPv6-Address and IPv6-DNS-Server-Address that do not. Would it make sense to split the document into two parts, one focusing on DHCPv6, and the other one on router advertisements? Bernard Aboba: Yes, I think this would help. David Nelson: Which attributes are you interested in? David Miles: For the Broadband Forum, IPv6-Address is of the most immediate interest. IPv6-DNS-Server-Address is relevant but isn't as important since in most cases name resolution is being handled over IPv4. Bernard Aboba: If that is what you need, then focusing on that would enable things to go forward much more quickly. Can you put a document together that focuses on that? David Miles: There is already a document that does that. David Nelson: Which one? David Miles: http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00 Bernard Aboba: Yes, that document just handles the attributes you are interested in. However, it confused the WG because it only talked about DHCPv6 and RADIUS, but did not talk about authentication. RADIUS is spoken between a RADIUS client and server. So if the RADIUS client is also a DHCPv6 server, then it makes sense. But if the DHCPv6 server is separate, then it's not clear how it works. Does the NAS pass the RADIUS attributes to the DHCPv6 server, and if so, how? Is there authentication going on between the DHCPv6 server and the RADIUS server? If there are no authentication attributes is this a Call Check, or is it changing the RADIUS protocol in some way? David Miles: I can include material on the Broadband Forum scenarios. If I work with Benoit to create an -01 with that additional material would that help? Bernard Aboba: Yes, it would help a great deal. Summary/Wrapup Bernard: At the last virtual interim, the feedback on DimDim was not very positive. So we tried LiveMeeting this time. How did it work for people? Dan Romascanu: The conference bridge was fine. Alan DeKok: I could not use the web conferencing software, it was only available on Windows. Dan Romascanu: It required me to install additional software (Outlook addin). That is a big deal. Bernard Aboba: DimDim also required a software install. Though it supported more platforms. David Nelson: Having a teleconference bridge, Jabber and slides is fine. David Miles: As long as the slides don't get too long or there are too many people in the meeting. Otherwise it's easy to lose your place. Bernard Aboba: They had a session on WebEx at IETF 75, in the Working Group Chairs meeting. I asked the Secretariat if we could get access, but didn't get a response. So it was either DimDim or LiveMeeting. Dan Romascanu: I will inquire about the availability of WebEx. Bernard: Let's talk about the plans for IETF 76. The RADEXT WG is not currently scheduled to meet at IETF 76. We have just completed the Virtual Interim, and IETF 76 is in just a few weeks. Dan Romascanu: Who is attending? David Nelson: I will not attend. Bernard: No Alan DeKok: No Hannes: Yes Dan Romascanu: There are disadvantages to not holding a meeting at IETF 76. You will miss the opportunity to interact with the community, particularly participants from Asia. It would be good to have a representative at IETF 76. Hannes is very busy, but perhaps you can find someone to represent RADEXT. Bernard: If there is WebEx available, we could participate remotely. Dan Romascanu: I will look into supporting WebEx at the OPS Area Meeting. There are cost concerns. ------=_NextPart_000_020F_01CA4CCE.89F577E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t see a list of = attendees.

 

From:= owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On = Behalf Of Bernard Aboba
Sent: Wednesday, October 14, 2009 2:35 AM
To: radiusext@ops.ietf.org
Subject: Draft RADEXT Virtual Interim = Minutes

 


Here is a draft of the RADEXT WG Virtual Interim Minutes.

Please take a look at these minutes and add/edit/correct as necessary. =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Minutes of the RADEXT WG Virtual Interim
October 13, 2009

Design Guidelines

Alan:  -09 has been submitted.  This includes a number of clarifications
with respect to tags, VSA formats, simple versus complex types.  =
There are no MUSTs or MUST NOTs in the document.  Guidelines try = to
encourage good practice, but should not be followed slavishly.

Dan: Jari has cleared his discuss.  So the document could be sent = to the
RFC Editor for publication immediately. 

Bernard:  Not clear that the document is ready.
There are still two open issues from IETF last call: Issues 313 and 314. =

Issue 313 concerns the "security exemption".  Does this = apply to any attribute
relating to security or authentication?  There was confusion on = this point
during the review of the PKMv1 document.

For user authentication or RADIUS security attributes there is = computation
involved:  the client has to compute something and the server has = to verify,
or vice-versa.  If an attribute relates to security (e.g. sending a certificate)
but there is no computation, does the exemption still apply?
In that case, it might have been possible to use the String
type, but a complex attribute would require new code on both the client = and server.

Issue 314 was filed by Hannes.  It was to be followed by specific = text to address the
concerns, but this wasn't provided.

Hannes:  The state of the art has advanced.  In some designs = addition of code is
no longer a big issue, scripts can be plugged in.  Also, parsers = have improved,
and could enable complex attributes to be supported automatically.
So are we locking ourselves into the past?

David Nelson:  Many RADIUS server implementations utilize a data dictionary.  This
allows administrators to add the definition of a new attribute without = having to
upgrade the server.  If an attribute doesn't have to require a = server upgrade, that
is probably a good thing. 

Bernard:  There are a lot of legacy RADIUS servers out there that implement
the data dictionary  model described in RFC 2865.  For those = implementations,
the data dictionary provides benefits.  It can save administrators = time
and money, allowing them to support a new attribute immediately without = waiting for
a RADIUS server upgrade.

David Nelson:  It is also possible to use opaque attributes, where = the data
is not parsed by RADIUS but by some other component.  Those = attributes
are sent to and from a plugin. 

Dan Romascanu:  There is also the question of whether normative = language is being used
in the same way as described in RFC 2119. 

Do we need to update the draft?

Bernard Aboba:  How about an RFC Editor note?
Dan:  That would be easier.

David Nelson:  I think it would be best to get the document = published and then see how
well it works in the real world.

Bernard:  So far, we've used it in reviewing two documents, the = PKMv1 document, and the
IPv6 access document.  In both cases, there was confusion about how = the guidelines applied
that required clarifications in the text.  So the "real = world" experience is not so good.
That's why the document has taken so long to finish.
 
Bernard: Alan -- can you take the action item to work with Dan on = addressing the RFC 2119 issue
as well as proposing an RFC Editor note to address issue 313?

Status Server

Alan:  This draft was revised.  An applicability subsection = was added.  There were some
terminology changes. 

David Nelson:  Does this document just describe what has been = deployed, or does it also
describe how Status-Server is used in RADSEC?

Alan:  It is focused on what has been implemented.  The RADSEC document uses Status-Server
as an RFC 3539 Watchdog, but that is covered in the RADSEC document. =

Bernard: Status-Server was originally implemented by Ascend in their concentrators.

Alan:  It was subsequently implemented in RADIATOR and = FreeRADIUS. 

Bernard:  It would be good if we could get some additional = reviewers to look at whether
the document accurately describes their implementations.  This = isn't a standards-track
document; its job is just to describe what has been = implemented.   Do we have any
volunteers:

David Nelson:  I will take a look at it.

RADIUS over TCP

Alan:  We added text to the applicability section.  We're now = using the term "RADIUS over TLS" instead
of a vendor's product name (RADSEC). We also added text on the = head-of-line blocking issue. 
Bernard:  As I recall, Magnus (Transport AD) raised this issue = initially. What can be done to address this
issue other than opening multiple TCP connections?
Alan:  Nothing.
Dan:  What is the issue specifically?
Alan:  If a packet is lost, then all traffic that was intended to = travel on the TCP connection has to
wait until the data at the head-of-the-line is acknowledged.  This = isn't an issue with UDP.
Hannes:  One of the reasons we created the SCTP transport for = Diameter was to address the head-of-line
blocking issue.  But SCTP has not been widely implemented.
Alan: For those that are interested, FreeRADIUS now supports RADIUS over = TCP, so you can play with it.
Bernard: Does the latest revision address Issues 315 and 316?
Alan:  Yes.
Bernard: OK.  If there are no open issues, then we could do another = WG last call.

RADIUS over DTLS

Alan:  RDTLS has been implemented in Stefan's RADSEC Proxy.  I = am implementing it as well.
This draft was not revised.
David Nelson: Isn't this draft expired?  What is the status?
Alan:  It is not expired. 
Bernard:  We issued a call for interest.  Only one or two = people responded.  There are no
open issues at the moment.  We need more reviews.

IEEE 802 Attributes

Dan Romascanu:  Is this document only about WLAN attributes or = wired IEEE 802 attributes as well?  Are
the attributes usable on multiple technologies?
Bernard: A number of the attributes are specific to a technology.  = For example, there are attributes
that relate to IEEE 802.11r specifically.  There are also = attributes that relate to IEEE 802.1X-REV.
Joe Salowey:  IEEE 802.1X-REV does apply to wireless, but there are aspects (such as announcements)
that were only meant to be implemented on wired networks. 
Bernard:  At one point we had attributes specific to IEEE 802.11s, = but the security model changed, so
we removed them. 
David Nelson:  What is the status of the document?
Bernard Aboba:  IEEE 802.1X-REV has completed Sponsor Ballot.  = We were waiting until the resolution of
Sponsor Ballot comments to align the document with IEEE 802.1X-REV.
Joe Salowey: IEEE 802.1X-REV is now going into recirculation = ballot.  So it is a good time to look at
it again.
Bernard Aboba:  The document is referenced in Appendix E of IEEE 802.1X-REV.  But it is not a normative
dependency.
Joe Salowey:  Now that IEEE 802.1X-REV has settled down, I will = review the document again, to see what
changes may be needed.
Bernard Aboba:  After Joe is done with his review, what are the = next steps? 
Dan Romascanu:  For a standards track document, it can either be a = WG work item, or an AD sponsored
document.  I would prefer a WG work item.
Bernard:  There was a call for interest in November 2007, but it = never completed.  So the document has
been in limbo for almost two years now.
David Nelson: Did anyone respond to the call?
Bernard Aboba:  Some people responded, yes.
David Nelson:  I was waiting for IEEE 802.1 to send their = requirements.
Bernard Aboba:  IEEE 802.1 provided their review of -08 in July 2008.  That is now up on the liaison archive.
David Nelson: We can either send the document to the RFC Editor or run a = quick WG last call on it, once
it is aligned with IEEE 802.1X-REV.

IPv6 Attribute Design Considerations

Hannes:  This document initially did not have much interest, then = there was a lot of discussion on the
list due to interest from the Broadband Forum.  There are a number = of ways to address the review from
Alan.  The document utilizes a tagging scheme similar to, but not = exactly the same as RFC 2868.  The
authors did not want to depend on Extended Attributes since it has not = been progressing (and is now
expired). 

Bernard:  It seems like many of the attributes that are tagged = relate to a router advertisement, correct?
Hannes:  That is my understanding.
Bernard:  One of the objections to the current scheme is that it = creates multiple new tagged data types.
A new attribute is needed for each element of the RA that needs to be expressed.  It occurred to me that
it might actually be easier to define an opaque blob that carries much = of (or the entire) RA. 

David Nelson: It seems like the lack of progress on Extended Attributes = is creating a problem.  Design
Guidelines says that the RFC 2868 tagging scheme isn't suitable for = generic use.  But it doesn't make
a recommendation.  If we don't get Extended Attributes done, then = we will be creating a problem.
After finishing Design Guidelines, it seems like this needs to be our #2 priority.

Bernard:  Agreed.  To be clear though, this document does not currently depend on Extended Attributes.
Question:  If Extended Attributes were further along, would this = document use it?

David Miles:  I don't think so. 

David Nelson:  It seems like there are a number of use cases here, = and they are not clearly described.
Bernard:  Previous documents have had very well defined uses = cases.  RFC 3162 supports address auto-
configuration.  RFC 4818 supports DHCPv6 Prefix Delegation.  = This document supports multiple modes,
and that is confusing.

David Miles:  In looking at the attribute list, there are a set of attributes relating to router advertisements
that require tagging, but another set of attributes like IPv6-Address = and IPv6-DNS-Server-Address that do not.
Would it make sense to split the document into two parts, one focusing = on DHCPv6, and
the other one on router advertisements?

Bernard Aboba: Yes, I think this would help.

David Nelson:  Which attributes are you interested in?

David Miles: For the Broadband Forum, IPv6-Address is of the most = immediate interest.  IPv6-DNS-Server-Address
is relevant but isn't as important since in most cases name resolution = is being handled over IPv4.

Bernard Aboba:  If that is what you need, then focusing on that = would enable things to go forward much more
quickly.  Can you put a document together that focuses on that? =

David Miles:  There is already a document that does that.

David Nelson:  Which one?

David Miles:  http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00

Bernard Aboba:  Yes, that document just handles the attributes you = are interested in.  However, it confused
the WG because it only talked about DHCPv6 and RADIUS, but did not talk = about authentication.  RADIUS is
spoken between a RADIUS client and server.  So if the RADIUS client = is also a DHCPv6 server, then it makes
sense.  But if the DHCPv6 server is separate, then it's not clear = how it works.  Does the NAS pass the
RADIUS attributes to the DHCPv6 server, and if so, how?  Is there authentication going on between the
DHCPv6 server and the RADIUS server?  If there are no = authentication attributes is this a Call Check,
or is it changing the RADIUS protocol in some way? 

David Miles:  I can include material on the Broadband Forum scenarios.  If I work with Benoit to create
an -01 with that additional material would that help?

Bernard Aboba:  Yes, it would help a great deal.

Summary/Wrapup

Bernard:  At the last virtual interim, the feedback on DimDim was = not very positive.  So we tried LiveMeeting this time.  How did it work = for people?
Dan Romascanu: The conference bridge was fine.
Alan DeKok:  I could not use the web conferencing software, it was = only available on Windows.
Dan Romascanu:  It required me to install additional software = (Outlook addin).  That is a big deal.
Bernard Aboba:  DimDim also required a software install.  = Though it supported more platforms.
David Nelson:  Having a teleconference bridge, Jabber and slides is = fine.
David Miles:  As long as the slides don't get too long  or = there are too many people in the meeting.  Otherwise it's easy to lose your = place.
Bernard Aboba:  They had a session on WebEx at IETF 75, in the = Working Group Chairs meeting.  I asked the Secretariat if we could get = access, but didn't get a response.  So it was
either DimDim or LiveMeeting.
Dan Romascanu:  I will inquire about the availability of WebEx. =

Bernard: Let's talk about the plans for IETF 76. The RADEXT WG is not = currently scheduled to meet at IETF 76.  We have just completed the Virtual = Interim, and
IETF 76 is in just a few weeks.
Dan Romascanu:  Who is attending?
David Nelson:  I will not attend.
Bernard: No
Alan DeKok: No
Hannes: Yes
Dan Romascanu:  There are disadvantages to not holding a meeting at = IETF 76.  You will miss the opportunity to interact with the community, particularly participants from Asia. 
It would be good to have a representative at IETF 76.  Hannes is = very busy, but perhaps you can find someone to represent RADEXT.
Bernard:  If there is WebEx available, we could participate = remotely.
Dan Romascanu:  I will look into supporting WebEx at the OPS Area Meeting.  There are cost concerns.

 

------=_NextPart_000_020F_01CA4CCE.89F577E0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 20 06:31:26 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 D75233A67CF for ; Tue, 20 Oct 2009 06:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.596 X-Spam-Level: X-Spam-Status: No, score=0.596 tagged_above=-999 required=5 tests=[AWL=1.091, 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 PECpajJTOXvB for ; Tue, 20 Oct 2009 06:31:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B12693A677D for ; Tue, 20 Oct 2009 06:31:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0Ee9-000FmW-At for radiusext-data0@psg.com; Tue, 20 Oct 2009 13:21:05 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0EVb-000EzZ-Ke for radiusext@ops.ietf.org; Tue, 20 Oct 2009 13:16:15 +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 5493E1234604 for ; Tue, 20 Oct 2009 14:36:49 +0200 (CEST) Message-ID: <4ADDAEE1.7040405@deployingradius.com> Date: Tue, 20 Oct 2009 14:36:49 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: 'radext mailing list' Subject: Last comments on design guidelines document X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: The following text should be added to the document during the RFC editor process, as suggested in the call last week: 1) Note on "MUST" and "MUST NOT" in the text. Section 1.3, before the final paragraph, add the following new sentence: The suggestions given below specify no mandatory behavior on new implementations. The uses of "MUST" and "MUST NOT" in this document are limited to (a) requirements to follow the IETF process for IETF standards, and (b) quotes from other documents. The advice in this document applies to attributes used to encode ... 2) Notes on attributes for authentication and security. Section A.2.2. Current text: * That a RADIUS server and/or client is expected to parse? i.e. A type that cannot be treated as opaque data (Section A.1.3) Replacement text: * That a RADIUS server and/or client is expected to parse, validate, or create the contents of via a computation? i.e. A type that cannot be treated as opaque data (Section A.1.3) Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 20 15:28: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 1CD0A3A67B8 for ; Tue, 20 Oct 2009 15:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=0.450, 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 yjTBcc4O9Ys8 for ; Tue, 20 Oct 2009 15:28:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2936E3A66B4 for ; Tue, 20 Oct 2009 15:28:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0N6s-000Nwp-VR for radiusext-data0@psg.com; Tue, 20 Oct 2009 22:23:18 +0000 Received: from [65.55.111.79] (helo=blu0-omc2-s4.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0N46-000NlO-LN for radiusext@ops.ietf.org; Tue, 20 Oct 2009 22:22:05 +0000 Received: from BLU137-DS6 ([65.55.111.71]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 15:20:26 -0700 X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Alan DeKok'" , "'radext mailing list'" References: <4ADDAEE1.7040405@deployingradius.com> In-Reply-To: <4ADDAEE1.7040405@deployingradius.com> Subject: RE: Last comments on design guidelines document Date: Tue, 20 Oct 2009 15:20:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpRibOoYFafSfX/T2ueCSfEgaljRQARoN7w Content-Language: en-us X-OriginalArrivalTime: 20 Oct 2009 22:20:26.0173 (UTC) FILETIME=[860256D0:01CA51D3] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok said: " The following text should be added to the document during the RFC editor process, as suggested in the call last week: 1) Note on "MUST" and "MUST NOT" in the text. Section 1.3, before the final paragraph, add the following new sentence: The suggestions given below specify no mandatory behavior on new implementations. The uses of "MUST" and "MUST NOT" in this document are limited to (a) requirements to follow the IETF process for IETF standards, and (b) quotes from other documents. The advice in this document applies to attributes used to encode ..." [BA] They don't specify mandatory behavior in existing implementations either, correct? How about this? "The uses of "MUST" and "MUST NOT" in this document are limited to (a) requirements to follow the IETF process for IETF standards, and (b) quotes from other documents. As a result, the use of MUST and MUST NOT in this document does not prescribe mandatory behavior within implementations." Alan also said: "2) Notes on attributes for authentication and security. Section A.2.2. Current text: * That a RADIUS server and/or client is expected to parse? i.e. A type that cannot be treated as opaque data (Section A.1.3) Replacement text: * That a RADIUS server and/or client is expected to parse, validate, or create the contents of via a computation? i.e. A type that cannot be treated as opaque data (Section A.1.3)" [BA] Doesn't this still leave the broad authentication/security exemption in place? The third bullet still says: " * for purposes other than authentication or security?" Also, the text in Section 2.1.3 remains unchanged: " As a result, the introduction of new complex data types within RADIUS attribute specifications SHOULD be avoided, except in the case of complex attributes involving authentication or security functionality." My understanding was that the security/authentication exemption was considered too broad. How about this? In Section 2.1.3, change the text to the following: "As a result, the introduction of new complex data types within RADIUS attribute specifications SHOULD be avoided. A potential exception to this recommendation occurs for attributes that inherently require code changes on both the client and server. For example, as described in Appendix B, complex attributes have been used in situations involving authentication and security attributes that need to be dynamically computed and verified." A suggestion for the text in Section A.2.2: " A.2.2. Complex Data Types Does the attribute: * define a complex data type that a RADIUS server and/or client is expected to parse? (i.e. a type that cannot be treated as opaque data (Section A.1.3). * involve functionality that could be implemented without code changes on both the client and server? (i.e. a type that doesn't require dynamic computation and verification, such as authentication or security attributes) If so, this data type SHOULD be replaced with simpler types, as discussed above in Appendix A.2.1. Also see Section 2.1.3 for a discussion of why complex types are problematic. " -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 20 15:43:55 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 2A4A128C10E for ; Tue, 20 Oct 2009 15:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.858 X-Spam-Level: X-Spam-Status: No, score=0.858 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_20=-0.74, 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 kz4aiEcRzvML for ; Tue, 20 Oct 2009 15:43:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 357113A6863 for ; Tue, 20 Oct 2009 15:43:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0NON-000Pn4-Qx for radiusext-data0@psg.com; Tue, 20 Oct 2009 22:41:23 +0000 Received: from [65.55.116.36] (helo=blu0-omc1-s25.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0NOD-000Pjh-Jl for radiusext@ops.ietf.org; Tue, 20 Oct 2009 22:41:21 +0000 Received: from BLU137-W11 ([65.55.116.8]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 15:41:13 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_aa4d3713-89ec-4984-b8f1-5c7d76f2d7b6_" X-Originating-IP: [131.107.0.75] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RADEXT WG meeting plans at IETF 76 & 77 Date: Tue, 20 Oct 2009 15:41:13 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2009 22:41:13.0271 (UTC) FILETIME=[6D566470:01CA51D6] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_aa4d3713-89ec-4984-b8f1-5c7d76f2d7b6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As you have noticed=2C the RADEXT WG is not scheduled to meet at IETF 76. = We are planning to meet at IETF 77=2C and will also be likely to schedule = another Virtual Interim between now and then.=20 In between the recent October 13 Virtual Interim and IETF 77=2C our goals a= re to: a. Publish the Design Guidelines document as an RFC=2C including hammering = out the text of any required RFC Editor notes=3B=20 b. Address all outstanding issues on the Extended Attributes document=2C in order to ready it for submission to the IESG for consideration as a Proposed Standard=3B=20 c. Address all outstanding issues on the RADSEC=2C RADIUS over TCP and Stat= us-Server documents=2C and initiate and complete a final RADEXT WG last cal= l on them=3B d. Revise the IEEE 802 attributes=2C RADIUS over DTLS and IPv6 Access documents=2C and run and conclude a Call for Adoption on them=3B To meet these ambitious goals=2C I would strongly urge authors of the above= documents with outstanding issues to send proposed changes to the list=2C = so that we can get feedback on them and ready revised documents for submiss= ion by the deadline.=20 = --_aa4d3713-89ec-4984-b8f1-5c7d76f2d7b6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As you have noticed=2C the RADEXT WG is not scheduled to meet at IETF 76.&n= bsp=3B =3B We are planning to meet at IETF 77=2C and will also be likel= y to schedule another Virtual Interim between now and then.

In betw= een the recent October 13 Virtual Interim and IETF 77=2C our goals are to:<= br>
a. Publish the Design Guidelines document as an RFC=2C including ham= mering out the text of any required RFC Editor notes=3B

b. Address = all outstanding issues on the Extended Attributes document=2C in order to ready it for submission to the IESG for consideration as a Proposed Standard=3B

c. Address all outstanding issues on the RADSE= C=2C RADIUS over TCP and Status-Server documents=2C and initiate and comple= te a final RADEXT WG last call on them=3B

d. Revise the IEEE 802 att= ributes=2C RADIUS over DTLS and IPv6 Access documents=2C and run and conclude a Call for Adoption on them=3B

To = meet these ambitious goals=2C I would strongly urge authors of the above do= cuments with outstanding issues to send proposed changes to the list=2C so = that we can get feedback on them and ready revised documents for submission= by the deadline.
=

<= /td>
= --_aa4d3713-89ec-4984-b8f1-5c7d76f2d7b6_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Oct 21 05:38:22 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 17A813A6A33 for ; Wed, 21 Oct 2009 05:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.378 X-Spam-Level: X-Spam-Status: No, score=0.378 tagged_above=-999 required=5 tests=[AWL=0.873, 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 Iccuda5vnNRa for ; Wed, 21 Oct 2009 05:38:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E7F563A686C for ; Wed, 21 Oct 2009 05:38:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0aM3-000JWG-Gc for radiusext-data0@psg.com; Wed, 21 Oct 2009 12:31:51 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0aM1-000JVh-C6 for radiusext@ops.ietf.org; Wed, 21 Oct 2009 12:31:49 +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 23E5E1234604; Wed, 21 Oct 2009 14:31:47 +0200 (CEST) Message-ID: <4ADEFF31.8060507@deployingradius.com> Date: Wed, 21 Oct 2009 14:31:45 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: 'radext mailing list' Subject: Re: Last comments on design guidelines document References: <4ADDAEE1.7040405@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > [BA] They don't specify mandatory behavior in existing implementations > either, correct? How about this? Yes, that is correct. > "The uses of "MUST" and "MUST NOT" in this > document are limited to (a) requirements to follow the IETF process > for IETF standards, and (b) quotes from other documents. As a result, > the use of MUST and MUST NOT in this document does not prescribe > mandatory behavior within implementations." OK. Looks good to me. > Alan also said: > > "2) Notes on attributes for authentication and security. Section A.2.2. > Current text: > > * That a RADIUS server and/or client is expected to parse? > i.e. A type that cannot be treated as opaque data (Section A.1.3) > > Replacement text: > > * That a RADIUS server and/or client is expected to parse, validate, > or create the contents of via a computation? > i.e. A type that cannot be treated as opaque data (Section A.1.3)" > > [BA] Doesn't this still leave the broad authentication/security exemption in > place? Hmm... maybe we could simply delete the third bullet. > The third bullet still says: > > " * for purposes other than authentication or security?" Yes. It's probably better to remove that exemption, and instead to rely on the "computation" text above. > Also, the text in Section 2.1.3 remains unchanged: > > " As a > result, the introduction of new complex data types within RADIUS > attribute specifications SHOULD be avoided, except in the case of > complex attributes involving authentication or security > functionality." > > My understanding was that the security/authentication exemption was > considered too broad. How about this? Yes. > In Section 2.1.3, change the text to the following: > > "As a result, the introduction of new complex data types within RADIUS > attribute specifications SHOULD be avoided. A potential exception to > this recommendation occurs for attributes that inherently require > code changes on both the client and server. For example, as described > in Appendix B, complex attributes have been used in situations > involving authentication and security attributes that need to be > dynamically computed and verified." That looks good to me. > A suggestion for the text in Section A.2.2: > > " A.2.2. Complex Data Types > > Does the attribute: > > * define a complex data type that a RADIUS server and/or client > is expected to parse? (i.e. a type that cannot be treated as > opaque data (Section A.1.3). > > * involve functionality that could be implemented without code > changes on both the client and server? (i.e. a type that > doesn't require dynamic computation and verification, such > as authentication or security attributes) > > If so, this data type SHOULD be replaced with simpler types, as > discussed above in Appendix A.2.1. Also see Section 2.1.3 for a > discussion of why complex types are problematic. OK. I think that's clearer. 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 Oct 22 03:52: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 6964E28C107 for ; Thu, 22 Oct 2009 03:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.054 X-Spam-Level: X-Spam-Status: No, score=-1.054 tagged_above=-999 required=5 tests=[AWL=-0.617, 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 r4sZIViXhhQ8 for ; Thu, 22 Oct 2009 03:52:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D5B83A68B5 for ; Thu, 22 Oct 2009 03:52:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0vC7-000LBw-Gj for radiusext-data0@psg.com; Thu, 22 Oct 2009 10:46:59 +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 1N0vC3-000LBZ-R6 for radiusext@ops.ietf.org; Thu, 22 Oct 2009 10:46:57 +0000 Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA03.westchester.pa.mail.comcast.net with comcast id vmb61c00316LCl053mmvRr; Thu, 22 Oct 2009 10:46:55 +0000 Received: from gwzPC ([124.120.154.21]) by OMTA06.westchester.pa.mail.comcast.net with comcast id vmmf1c0040Txz8k3SmmiJX; Thu, 22 Oct 2009 10:46:53 +0000 From: "Glen Zorn" To: "'Adrian Farrel'" Cc: , References: <007101ca52fb$cd428c80$67c7a580$@net> In-Reply-To: Subject: RE: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Date: Thu, 22 Oct 2009 17:46:28 +0700 Message-ID: <008201ca5304$f1d6a0f0$d583e2d0$@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: AcpS/tYPlWw4VswqTYmsAl/rgQ4eCQABG5lQ Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Adrian Farrel [mailto:Adrian.Farrel@huawei.com] writes: > Hi Glen, > > Second of your Issue tracker emails to arrive today. And more to come ;-). > Is there any > specific > action you are asking from the IESG, or is this for info? Yes, I would request the termination of IESG review and return of this terribly flawed document to the WG. I realize that it's pretty late in the process, but it seems clear to me (and I hope, given the content of the messages you mention above) that, despite all the Last Calls, etc., no one has read this draft really carefully (I know that I hadn't); that, alone, should keep it off the RFC Editor's queue until it is fixed. ... -- to 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 Oct 22 03:52: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 7BF5328C107 for ; Thu, 22 Oct 2009 03:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.981 X-Spam-Level: X-Spam-Status: No, score=-103.981 tagged_above=-999 required=5 tests=[AWL=2.618, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lijC23ekyv0X for ; Thu, 22 Oct 2009 03:52:27 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id A71463A68FA for ; Thu, 22 Oct 2009 03:52:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0vEL-000LTZ-QY for radiusext-data0@psg.com; Thu, 22 Oct 2009 10:49:17 +0000 Received: from [76.96.30.24] (helo=QMTA02.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0vEK-000LSo-0p for radiusext@ops.ietf.org; Thu, 22 Oct 2009 10:49:16 +0000 Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id vmnB1c0030cQ2SLA2mpGs4; Thu, 22 Oct 2009 10:49:16 +0000 Received: from gwzPC ([124.120.154.21]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id vmp41c0040Txz8k8Wmp8St; Thu, 22 Oct 2009 10:49:14 +0000 From: "Glen Zorn" To: Subject: FW: ISSUE: Inappropriate use of RFC 2119 key word and misleading references Date: Thu, 22 Oct 2009 17:48:55 +0700 Message-ID: <008401ca5305$4622fb40$d268f1c0$@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: AcpTAtRQDXFeoTmGRyyf0ys3ODVk+gAAmJ9g Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: -----Original Message----- From: Glen Zorn [mailto:gwz@net-zen.net] Sent: Thursday, October 22, 2009 5:32 PM To: 'radiusext@ops.ietf.org' Cc: 'radext-chairs@ietf.org'; 'iesg@ietf.org'; 'Alan DeKok'; gdweber@gmail.com Subject: ISSUE: Inappropriate use of RFC 2119 key word and misleading references Description of issue: Misleading references and invention of integer64 data type Submitter name: Glen Zorn Submitter email address: gwz@net-zen.net Date first submitted: 22 October 2009 Document: draft-ietf-radext-design-09 Comment type: T Priority: S Section: 2.1.1 Rationale/Explanation of issue: The relevant section of the draft in question says: The integer64 type is used for the ARAP- Challenge-Response Attribute defined in [RFC2869] Section 5.15, and the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in length, but denotes it as type String. Given that attributes of type IPv6 address, IPv6 prefix, and integer64 are already in use, it is RECOMMENDED that RADIUS server implementations include support for these additional basic types, in addition to the types defined in [RFC2865]. This is what RFC 2869 says about the Value field of the APAP-Challenge-Response Attribute: Value The Value field contains an 8 octet response to the dial-in client's challenge. The RADIUS server calculates this value by taking the dial-in client's challenge from the high order 8 octets of the ARAP-Password attribute and performing DES encryption on this value with the authenticating user's password as the key. If the user's password is less than 8 octets in length, the password is padded at the end with NULL octets to a length of 8 before using it as a key. If one takes the word "integer" as having its normal meaning it is obvious that far from defining a 64-bit integer data type the only thing that the ARAP-Challenge-Response attribute has in common with a 64-bit integer is its length. The same is true, in spades, for the Framed-Interface-Id Attribute: the attribute was designed to carry the Interface-Identifier IPCOv6 option (RFC 2472). Glancing at section 4.1 of that document (it's too long to quote here) makes it abundantly clear that the Interface-Id field of the Framed-Interface-Id attribute was designed not as an integer but as a specially formatted octet string. Neither RFC 2869 nor RFC 3162 uses the term "integer64", for good reason; interestingly, RFC 2869 _does_ define data types, but "integer64" is not among the types defined (again, for good reason). Therefore, it is technically incorrect to claim that either of the referenced RFCs defines an "integer64" data type. Requested change: Given that the "integer64" data type has never in fact been defined by any RFC, either all mention of it must be removed from this draft or the text changed to make clear that it is an invention of the author. -- to 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 Oct 22 03:52: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 A32B33A69A7 for ; Thu, 22 Oct 2009 03:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.424 X-Spam-Level: X-Spam-Status: No, score=-1.424 tagged_above=-999 required=5 tests=[AWL=-0.987, 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 veCue0lySW-S for ; Thu, 22 Oct 2009 03:52:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A0A6F28C107 for ; Thu, 22 Oct 2009 03:52:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0vE2-000LQB-A3 for radiusext-data0@psg.com; Thu, 22 Oct 2009 10:48:58 +0000 Received: from [76.96.27.228] (helo=QMTA15.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0vE0-000LPq-8p for radiusext@ops.ietf.org; Thu, 22 Oct 2009 10:48:56 +0000 Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA15.emeryville.ca.mail.comcast.net with comcast id vmof1c0010vp7WLAFmoweo; Thu, 22 Oct 2009 10:48:56 +0000 Received: from gwzPC ([124.120.154.21]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id vmoi1c0040Txz8k8RmomLr; Thu, 22 Oct 2009 10:48:54 +0000 From: "Glen Zorn" To: Subject: FW: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Date: Thu, 22 Oct 2009 17:48:31 +0700 Message-ID: <008301ca5305$39d5b850$ad8128f0$@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: AcpS+8fZPfiibd76Sb+T5zJdBncaRwACV5YQ Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: -----Original Message----- From: Glen Zorn [mailto:gwz@net-zen.net] Sent: Thursday, October 22, 2009 4:41 PM To: 'radiusext@ops.ietf.org' Cc: 'iesg@ietf.org' Subject: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Description of issue: The definition of RADIUS IPv6 "data types" arbitrary and unjustified Submitter name: Glen Zorn Submitter email address: gwz@net-zen.net Date first submitted: 22 October 2009 Document: draft-ietf-radext-design-09 Comment type: T Priority: S Section: 2.1.1 Rationale/Explanation of issue: The section in question states: In addition to these data types, follow-on RADIUS specifications define attributes using the following additional types: IPv6 address 128 bit value, in network byte order. IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 128 bits of value, in network byte order. integer64 64 bit unsigned value, in network byte order This type has also been used to represent an IPv6 interface identifier. Examples of the IPv6 address type include NAS-IPv6-Address defined in [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, and in [RFC4818] Section 3. The integer64 type is used for the ARAP- Challenge-Response Attribute defined in [RFC2869] Section 5.15, and the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in length, but denotes it as type String. Given that attributes of type IPv6 address, IPv6 prefix, and integer64 are already in use, it is RECOMMENDED that RADIUS server implementations include support for these additional basic types, in addition to the types defined in [RFC2865]. However, simply examining the references shows that none of the RFCs cited define _any_ "data types". The claim made is arbitrary and unjustified; essentially, the author is inventing the "data types" out of thin air. Requested change: Either delete the entire section or modify it to be a more reasonable and justified _description_ of formats that have been previously used in RADIUS to carry quantities related to IPv6, rather than using irrelevant references to attempt to justify the _prescription_ of future behavior. -- to 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 Oct 22 05:49: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 E31933A6858 for ; Thu, 22 Oct 2009 05:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[AWL=0.473, 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 ehrV4qiEw0Up for ; Thu, 22 Oct 2009 05:49:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C60313A67A8 for ; Thu, 22 Oct 2009 05:49:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0x3x-000CLG-25 for radiusext-data0@psg.com; Thu, 22 Oct 2009 12:46:41 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0x3v-000CKF-4a for radiusext@ops.ietf.org; Thu, 22 Oct 2009 12:46:39 +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 4603D1234604; Thu, 22 Oct 2009 14:46:37 +0200 (CEST) Message-ID: <4AE0542C.4030909@deployingradius.com> Date: Thu, 22 Oct 2009 14:46:36 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org, IESG IESG Subject: Re: FW: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified References: <008301ca5305$39d5b850$ad8128f0$@net> In-Reply-To: <008301ca5305$39d5b850$ad8128f0$@net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote: > However, simply examining the references shows that none of the RFCs cited > define _any_ "data types". Unfortunately, I know how to use "grep". $ grep "data type" rfc2865.txt ... The format of the value field is one of five data types. Note standard Attributes do not use this data type but it is ... That was difficult. Now let's read the document in more detail to see what it says. From RFC 2865 Section 5, Page 25: The format of the value field is one of five data types. Note that type "text" is a subset of type "string". It goes on to name the five data types, and give definitions for each one. These data types are then used in the attribute definitions in RFC 2865, and in other RADIUS RFCs. In addition, this text is taken from RFC 2058, which was written over a decade ago, and says: The format of the value field is one of four data types. Of course, that isn't the whole story. To highlight the irony (or hypocrisy), these data types are used by you in RFCs that you either authored or co-authored: RFC 2548 RFC 2867 RFC 2868 RFC 3162 > Requested change: > Either delete the entire section or modify it to be a more reasonable and > justified _description_ of formats that have been previously used in RADIUS > to carry quantities related to IPv6, rather than using irrelevant references > to attempt to justify the _prescription_ of future behavior. This issue should be rejected out of hand. The concept of "data types" goes back to the beginning of RADIUS, and was part of the original protocol specification. 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 Oct 22 06:04:46 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 9D2833A6A02 for ; Thu, 22 Oct 2009 06:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=0.251, 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 vnJ54JedtMK3 for ; Thu, 22 Oct 2009 06:04:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 993C23A68F7 for ; Thu, 22 Oct 2009 06:04:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0xHb-000EmV-Rl for radiusext-data0@psg.com; Thu, 22 Oct 2009 13:00:48 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0xHX-000EjX-An for radiusext@ops.ietf.org; Thu, 22 Oct 2009 13:00:43 +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 430061234604; Thu, 22 Oct 2009 15:00:42 +0200 (CEST) Message-ID: <4AE05779.6000605@deployingradius.com> Date: Thu, 22 Oct 2009 15:00:41 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org, IESG IESG Subject: Re: FW: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> In-Reply-To: <4AE0542C.4030909@deployingradius.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok wrote: > Glen Zorn wrote: >> However, simply examining the references shows that none of the RFCs cited >> define _any_ "data types". And to fore-stall any discussion about IPv6... the RFCs referenced *do* define RADIUS "value" fields that carry IPv6 addresses. Since RFC 2865 defines the "value" field of attributes to carry "data types", and the IPv6 RFC you co-authored lists the "value" field as carrying an IPv6 address, the only possible conclusion is that you have personally created and defined the "ipv6 address" data type. The alternative is to conclude that the document you wrote specifying the "value" field as an "IPv6 Address" does not, in fact, specify any data type for that field. i.e. The statement that the field is an "Ipv6 address", and the definition of it as "Address of 16 octets" should instead be interpreted to mean "string of undistinguished octets with no obvious meaning". The only possible way to conclude that IPv6 data types don't exist in RADIUS is to disown the documents that you wrote. I expect that you will therefore shortly file errata for those RFCs, withdrawing all statements that the "value" field of IPv6 attributes have any meaning. I expect that you will, of course, also re-name the attributes at the same time. For example, "NAS-IPv6-Address" should be renamed as "NAS-String-Of-No-Meaning". 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 Oct 22 06:54: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 DA4F43A69EA for ; Thu, 22 Oct 2009 06:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=-0.859, 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 QcOhqesf2-D4 for ; Thu, 22 Oct 2009 06:54:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D13AC3A6947 for ; Thu, 22 Oct 2009 06:54:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0y3Q-000Lkn-3x for radiusext-data0@psg.com; Thu, 22 Oct 2009 13:50:12 +0000 Received: from [76.96.30.80] (helo=QMTA08.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0y3N-000LkH-OC for radiusext@ops.ietf.org; Thu, 22 Oct 2009 13:50:10 +0000 Received: from OMTA21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id vpYY1c0041u4NiLA8pqAUm; Thu, 22 Oct 2009 13:50:10 +0000 Received: from gwzPC ([124.120.154.21]) by OMTA21.emeryville.ca.mail.comcast.net with comcast id vppq1c00A0Txz8k8hppvLx; Thu, 22 Oct 2009 13:50:07 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: , "'IESG IESG'" References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> In-Reply-To: <4AE0542C.4030909@deployingradius.com> Subject: RE: FW: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Date: Thu, 22 Oct 2009 20:49:39 +0700 Message-ID: <00ad01ca531e$8a5bd980$9f138c80$@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: AcpTFbRtp5XrAYQqTlSPH+Oof/8n0gABwgng Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok [mailto:aland@deployingradius.com] writes: > > However, simply examining the references shows that none of the RFCs > cited > > define _any_ "data types". > > Unfortunately, I know how to use "grep". Even more unfortunately, you don't seem to know how to read. The original message read "However, simply examining the references shows that none of the RFCs cited define _any_ "data types", the "RFCs cited" being 3162, 2869, 4818 & 4675 but not 2865. Please start making sense. > > $ grep "data type" rfc2865.txt > ... > The format of the value field is one of five data types. Note > standard Attributes do not use this data type but it is > ... > > That was difficult. Now let's read the document in more detail to > see > what it says. From RFC 2865 Section 5, Page 25: > > > The format of the value field is one of five data types. Note > that type "text" is a subset of type "string". > > > It goes on to name the five data types, and give definitions for each > one. These data types are then used in the attribute definitions in > RFC > 2865, and in other RADIUS RFCs. Show us. I've already given multiple counter-examples from RFC 2865; can you just show one? > > In addition, this text is taken from RFC 2058, which was written over > a decade ago, and says: > > > The format of the value field is one of four data types. > > > Of course, that isn't the whole story. To highlight the irony (or > hypocrisy), these data types are used by you in RFCs that you either > authored or co-authored: > > RFC 2548 > RFC 2867 > RFC 2868 > RFC 3162 > > > Requested change: > > Either delete the entire section or modify it to be a more reasonable > and > > justified _description_ of formats that have been previously used in > RADIUS > > to carry quantities related to IPv6, rather than using irrelevant > references > > to attempt to justify the _prescription_ of future behavior. > > This issue should be rejected out of hand. The concept of "data > types" goes back to the beginning of RADIUS, and was part of the > original protocol specification. The data types in question are "IPv6 address", "IPv6 prefix" and "integer64". These do not exist as "data types" in any existing RFC. If you can't make sense, at least pay attention. > > 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 Oct 22 07:25:01 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 7EBD43A68D5 for ; Thu, 22 Oct 2009 07:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=-0.788, 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 FMX6Ng2eG-Hz for ; Thu, 22 Oct 2009 07:25:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 665EF3A688C for ; Thu, 22 Oct 2009 07:25:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0yXv-00007Y-N8 for radiusext-data0@psg.com; Thu, 22 Oct 2009 14:21:43 +0000 Received: from [76.96.27.243] (helo=QMTA13.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0yXr-00007C-OF for radiusext@ops.ietf.org; Thu, 22 Oct 2009 14:21:41 +0000 Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id vp3P1c00117UAYkADqMguX; Thu, 22 Oct 2009 14:21:40 +0000 Received: from gwzPC ([124.120.154.21]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id vqMP1c0030Txz8k8ZqMT0N; Thu, 22 Oct 2009 14:21:38 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: , "'IESG IESG'" References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> <4AE05779.6000605@deployingradius.com> In-Reply-To: <4AE05779.6000605@deployingradius.com> Subject: RE: FW: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Date: Thu, 22 Oct 2009 21:21:11 +0700 Message-ID: <00b401ca5322$f16a00d0$d43e0270$@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: AcpTF6wWh/tb+NItRECdMTFP/9PF0gAB2Tcw Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok [mailto:aland@deployingradius.com] writes: > Alan DeKok wrote: > > Glen Zorn wrote: > >> However, simply examining the references shows that none of the RFCs > cited > >> define _any_ "data types". > > And to fore-stall any discussion about IPv6... By all means, since that was the subject of the comment. > the RFCs referenced > *do* define RADIUS "value" fields that carry IPv6 addresses. > > Since RFC 2865 defines the "value" field of attributes to carry "data > types", Indeed it does, in section 5. More specifically, it says "The format of the value field is one of five data types." Which of the five is "IPv6 Address"? (It also ignores this statement almost entirely, as do the majority of RADIUS RFCs.) > and the IPv6 RFC you co-authored lists the "value" field as > carrying an IPv6 address, the only possible conclusion is that you have > personally created and defined the "ipv6 address" data type. Let me see if I've got this straight: I, and my co-authors, were actually _inventing_ new RADIUS data types but were just too stupid to know it; further, it was OK back then to "invent" new RADIUS data types back then (because you have given your stamp of approval) but now & forevermore it's bad because you say so. > > The alternative is to conclude that the document you wrote specifying > the "value" field as an "IPv6 Address" does not, in fact, specify any > data type for that field. There is another, less anal-retentive alternative: that the string of octets does, in fact, represent an IPv6 address. That's it, and that's pretty much what the RFC says. > > i.e. The statement that the field is an "Ipv6 address", and the > definition of it as "Address of 16 octets" RFC 3126 does not contain those words. > should instead be > interpreted > to mean "string of undistinguished octets with no obvious meaning". > > The only possible way to conclude that IPv6 data types don't exist in > RADIUS is to disown the documents that you wrote. I expect that you > will therefore shortly file errata for those RFCs, withdrawing all > statements that the "value" field of IPv6 attributes have any meaning. OK, so what is the "data type" of the Login-IPv6-Host Attribute? > > I expect that you will, of course, also re-name the attributes at the > same time. For example, "NAS-IPv6-Address" should be renamed as > "NAS-String-Of-No-Meaning". > > 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 Oct 22 07:40:06 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 484F03A6858 for ; Thu, 22 Oct 2009 07:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.069 X-Spam-Level: X-Spam-Status: No, score=-0.069 tagged_above=-999 required=5 tests=[AWL=0.426, 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 M-otJ9+XepiQ for ; Thu, 22 Oct 2009 07:40:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 096FF3A679C for ; Thu, 22 Oct 2009 07:40:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0ymF-00033j-M8 for radiusext-data0@psg.com; Thu, 22 Oct 2009 14:36:31 +0000 Received: from [65.55.111.157] (helo=blu0-omc4-s18.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0ymD-00032N-AM for radiusext@ops.ietf.org; Thu, 22 Oct 2009 14:36:29 +0000 Received: from BLU137-DS2 ([65.55.111.137]) by blu0-omc4-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 07:36:28 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Glen Zorn'" , References: <008401ca5305$4622fb40$d268f1c0$@net> In-Reply-To: <008401ca5305$4622fb40$d268f1c0$@net> Subject: RE: ISSUE: Inappropriate use of RFC 2119 key word and misleading references Date: Thu, 22 Oct 2009 07:36:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpTAtRQDXFeoTmGRyyf0ys3ODVk+gAAmJ9gAAeq/tA= Content-Language: en-us X-OriginalArrivalTime: 22 Oct 2009 14:36:28.0540 (UTC) FILETIME=[0A5023C0:01CA5325] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn said: "Glancing at section 4.1 of that document (it's too long to quote here) makes it abundantly clear that the Interface-Id field of the Framed-Interface-Id attribute was designed not as an integer but as a specially formatted octet string. Neither RFC 2869 nor RFC 3162 uses the term "integer64", for good reason; interestingly, RFC 2869 _does_ define data types, but "integer64" is not among the types defined (again, for good reason). Therefore, it is technically incorrect to claim that either of the referenced RFCs defines an "integer64" data type." Requested change: Given that the "integer64" data type has never in fact been defined by any RFC, either all mention of it must be removed from this draft or the text changed to make clear that it is an invention of the author. [BA] How about this? In Section 2.1.1 change: " IPv6 address 128 bit value, in network byte order. IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 128 bits of value, in network byte order. integer64 64 bit unsigned value, in network byte order This type has also been used to represent an IPv6 interface identifier. Examples of the IPv6 address type include NAS-IPv6-Address defined in [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, and in [RFC4818] Section 3. The integer64 type is used for the ARAP- Challenge-Response Attribute defined in [RFC2869] Section 5.15, and the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in length, but denotes it as type String. Given that attributes of type IPv6 address, IPv6 prefix, and integer64 are already in use, it is RECOMMENDED that RADIUS server implementations include support for these additional basic types, in addition to the types defined in [RFC2865]. " To: " IPv6 address 128 bit value, in network byte order. IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 128 bits of value, in network byte order. Interface ID 64 bit octet string, in network byte order, used to represent an IPv6 Interface identifier. Examples of the IPv6 address type include NAS-IPv6-Address defined in [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, and in [RFC4818] Section 3. The Interface ID type is used for the the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in length, but denotes it as type String. Given that attributes of type IPv6 address, IPv6 prefix, and Interface ID are already in use, it is recommended that RADIUS server implementations include support for these additional basic types, in addition to the types defined in [RFC2865]. " -- to 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 Oct 22 07:49:59 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 702943A6993 for ; Thu, 22 Oct 2009 07:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[AWL=0.110, 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 qPE48em-ZX9D for ; Thu, 22 Oct 2009 07:49:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D67B23A6950 for ; Thu, 22 Oct 2009 07:49:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0ywh-0004fd-Cd for radiusext-data0@psg.com; Thu, 22 Oct 2009 14:47:19 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0ywf-0004fD-CI for radiusext@ops.ietf.org; Thu, 22 Oct 2009 14:47:17 +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 06F1F1234604; Thu, 22 Oct 2009 16:47:15 +0200 (CEST) Message-ID: <4AE07073.5030900@deployingradius.com> Date: Thu, 22 Oct 2009 16:47:15 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org, 'IESG IESG' Subject: Re: FW: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> <4AE05779.6000605@deployingradius.com> <00b401ca5322$f16a00d0$d43e0270$@net> In-Reply-To: <00b401ca5322$f16a00d0$d43e0270$@net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote > There is another, less anal-retentive alternative: that the string of octets > does, in fact, represent an IPv6 address. That's it, and that's pretty much > what the RFC says. a) fix RFC 3162 to use the RFC 2865 data types or b) agree that IPv6 data types were defined by you in RADIUS. You seem to have chosen (b). Therefore, your objection that the "guidelines" document invents the IPv6 address data type has been withdrawn. 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 Oct 22 07:50:13 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 85C1D3A6A70 for ; Thu, 22 Oct 2009 07:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.089 X-Spam-Level: X-Spam-Status: No, score=-0.089 tagged_above=-999 required=5 tests=[AWL=0.406, 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 odp9w0MIyumd for ; Thu, 22 Oct 2009 07:50:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A8CBE3A6993 for ; Thu, 22 Oct 2009 07:50:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0ywV-0004do-TQ for radiusext-data0@psg.com; Thu, 22 Oct 2009 14:47:07 +0000 Received: from [65.55.111.161] (helo=blu0-omc4-s22.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0ywT-0004dL-K5 for radiusext@ops.ietf.org; Thu, 22 Oct 2009 14:47:05 +0000 Received: from BLU137-DS4 ([65.55.111.137]) by blu0-omc4-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 07:47:05 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Glen Zorn'" , "'Alan DeKok'" CC: References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> <4AE05779.6000605@deployingradius.com> <00b401ca5322$f16a00d0$d43e0270$@net> In-Reply-To: <00b401ca5322$f16a00d0$d43e0270$@net> Subject: RE: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Date: Thu, 22 Oct 2009 07:47:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpTF6wWh/tb+NItRECdMTFP/9PF0gAB2TcwAAG1bYA= Content-Language: en-us X-OriginalArrivalTime: 22 Oct 2009 14:47:05.0450 (UTC) FILETIME=[85F0E4A0:01CA5326] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn said: "There is another, less anal-retentive alternative: that the string of octets does, in fact, represent an IPv6 address. That's it, and that's pretty much what the RFC says." If that were the case, why didn't the document use the term "String" in defining the NAS-IPv6-Address and Login-IPv6-Host attributes instead of "Address"? -- to 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 Oct 22 07:54:54 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 AF88D3A68AD for ; Thu, 22 Oct 2009 07:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.101, 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 dzApmxD6hfM7 for ; Thu, 22 Oct 2009 07:54:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B8BAD3A688C for ; Thu, 22 Oct 2009 07:54:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0z12-0005IZ-FU for radiusext-data0@psg.com; Thu, 22 Oct 2009 14:51:48 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N0z10-0005ID-6l for radiusext@ops.ietf.org; Thu, 22 Oct 2009 14:51:46 +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 27F7B1234604; Thu, 22 Oct 2009 16:51:45 +0200 (CEST) Message-ID: <4AE07181.3010600@deployingradius.com> Date: Thu, 22 Oct 2009 16:51:45 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: 'Glen Zorn' , radiusext@ops.ietf.org Subject: Re: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> <4AE05779.6000605@deployingradius.com> <00b401ca5322$f16a00d0$d43e0270$@net> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > Glen Zorn said: > > "There is another, less anal-retentive alternative: that the string of > octets > does, in fact, represent an IPv6 address. That's it, and that's pretty much > what the RFC says." > > If that were the case, why didn't the document use the term "String" in > defining the NAS-IPv6-Address and Login-IPv6-Host attributes instead of > "Address"? I've filed an errata against RFC 3162 to clarify this point. Either RFC 3162 is wrong, and those attributes are of type "string", OR Glen's objection to the guidelines document is wrong, and RFC 3162 defines an IPv6 address type. 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 Oct 22 14:07: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 153CF28C143 for ; Thu, 22 Oct 2009 14:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.147 X-Spam-Level: X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[AWL=-0.709, 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 5O7fbzuYsQW3 for ; Thu, 22 Oct 2009 14:07:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A0B028C101 for ; Thu, 22 Oct 2009 14:07:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N14pH-0001Ds-QR for radiusext-data0@psg.com; Thu, 22 Oct 2009 21:04:03 +0000 Received: from [76.96.62.16] (helo=QMTA01.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N14pD-0001D9-AG for radiusext@ops.ietf.org; Thu, 22 Oct 2009 21:04:00 +0000 Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA01.westchester.pa.mail.comcast.net with comcast id vlaL1c00416LCl051ldqqe; Thu, 22 Oct 2009 09:37:50 +0000 Received: from gwzPC ([124.120.154.21]) by OMTA06.westchester.pa.mail.comcast.net with comcast id vldU1c0060Txz8k3SldYR9; Thu, 22 Oct 2009 09:37:48 +0000 From: "Glen Zorn" To: Cc: Subject: FW: ISSUE: Inappropriate usage of RFC 2119 key words Date: Thu, 22 Oct 2009 16:37:18 +0700 Message-ID: <007001ca52fb$4bb36f40$e31a4dc0$@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: AcpS2fN5gpPJrIQ8RhKVKVK2iSAGaAAISLEg Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: -----Original Message----- From: Glen Zorn [mailto:gwz@net-zen.net] Sent: Thursday, October 22, 2009 12:39 PM To: 'radiusext@ops.ietf.org' Cc: 'iesg@ietf.org' Subject: ISSUE: Inappropriate usage of RFC 2119 key words Description of issue: Inappropriate usage of RFC 2119 key words Submitter name: Glen Zorn Submitter email address: gwz@net-zen.net Date first submitted: 22 October 2009 Document: draft-ietf-radext-design-09 Comment type: T Priority: S Section: 2.1.1 Rationale/Explanation of issue: Section 6 of RFC 2119 states: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. The section of the draft in question says: It is worth noting that since RADIUS only supports unsigned integers of 32 or 64 bits, attributes using signed integer data types or unsigned integer types of other sizes will require code changes, and SHOULD be avoided. It is difficult to see how either harm or interoperability problems could arise from correctly implemented code changes; indeed, this appears to be a classic case of the use of RFC 2119 keywords to "try to impose a particular method on implementors where the method is not required for interoperability". Requested change: Since the only rationale offered for the prohibition is the spurious one of avoiding code changes (something that is certainly implementation-specific), the section should be removed altogether. -- to 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 Oct 22 23:02: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 611DD3A6955 for ; Thu, 22 Oct 2009 23:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji-oAV6PpZ07 for ; Thu, 22 Oct 2009 23:02:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 53F2C3A6774 for ; Thu, 22 Oct 2009 23:02:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1D96-000B2o-VL for radiusext-data0@psg.com; Fri, 23 Oct 2009 05:57:05 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1D94-000B2Z-3H for radiusext@ops.ietf.org; Fri, 23 Oct 2009 05:57:02 +0000 Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id DF55C1234604; Fri, 23 Oct 2009 07:56:57 +0200 (CEST) Message-ID: <4AE145A9.2090006@deployingradius.com> Date: Fri, 23 Oct 2009 07:56:57 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org, radext-chairs@ietf.org Subject: Re: FW: ISSUE: Inappropriate usage of RFC 2119 key words References: <007001ca52fb$4bb36f40$e31a4dc0$@net> In-Reply-To: <007001ca52fb$4bb36f40$e31a4dc0$@net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote: > The section of the draft in question says: > > It is worth noting that since RADIUS only supports unsigned integers > of 32 or 64 bits, attributes using signed integer data types or > unsigned integer types of other sizes will require code changes, and > SHOULD be avoided. > > It is difficult to see how either harm or interoperability problems could > arise from correctly implemented code changes; indeed, this appears to be a > classic case of the use of RFC 2119 keywords to "try to impose a particular > method on implementors where the method is not required for > interoperability". I welcome suggestions for how implementations can *meaningfully* interoperate when they have different interpretations for an attribute. i.e. one defines an attribute to be "signed 24-bit integer counter, little endian", and the other doesn't support that data type. None of the meanings of the novel integer type (e.g. counter) can be used by the second implementation. It can only treat the field as "string of undistinguished octets". Therefore, they cannot be said to inter-operate according to the definition of the attribute. The alternative is to interpret "inter-operate" as "sends / receives opaque data without agreeing on the format, meaning, or processing of that data". If that is our definition of the word, then we can say that DHCP inter-operates with RADIUS. And the term loses all meaning. > Requested change: > Since the only rationale offered for the prohibition is the spurious one of > avoiding code changes (something that is certainly implementation-specific), > the section should be removed altogether. This issue should be rejected. RADIUS specifications define format, meaning, interpretations, and processing requirements for attributes. Two implementations that disagree about an attribute can inter-operate at the RADIUS level by exchanging RADIUS packets. They cannot be said have interoperable implementations of the attribute. 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 Fri Oct 23 07:31:20 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 0CAA73A687A for ; Fri, 23 Oct 2009 07:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.085 X-Spam-Level: X-Spam-Status: No, score=-0.085 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 6z5cuDO28+9l for ; Fri, 23 Oct 2009 07:31:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F23783A6824 for ; Fri, 23 Oct 2009 07:31:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1L6n-0000gn-UE for radiusext-data0@psg.com; Fri, 23 Oct 2009 14:27:13 +0000 Received: from [65.55.111.141] (helo=blu0-omc4-s2.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1L6l-0000fv-TI for radiusext@ops.ietf.org; Fri, 23 Oct 2009 14:27:11 +0000 Received: from BLU137-W16 ([65.55.111.137]) by blu0-omc4-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 04:15:00 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_1ce7a2f8-53c5-48a6-869a-615ee6068a6d_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Glen Zorn , "radiusext@ops.ietf.org" CC: Subject: RE: ISSUE: Inappropriate usage of RFC 2119 key words Date: Fri, 23 Oct 2009 04:15:00 -0700 Importance: Normal In-Reply-To: <007001ca52fb$4bb36f40$e31a4dc0$@net> References: <007001ca52fb$4bb36f40$e31a4dc0$@net> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Oct 2009 11:15:00.0452 (UTC) FILETIME=[0FAA0A40:01CA53D2] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_1ce7a2f8-53c5-48a6-869a-615ee6068a6d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Glen Zorn said: > It is worth noting that since RADIUS only supports unsigned integers > of 32 or 64 bits=2C attributes using signed integer data types or > unsigned integer types of other sizes will require code changes=2C and > SHOULD be avoided. >=20 > It is difficult to see how either harm or interoperability problems could > arise from correctly implemented code changes=3B indeed=2C this appears t= o be a > classic case of the use of RFC 2119 keywords to "try to impose a particul= ar > method on implementers where the method is not required for > interoperability". The issue being described here is not one between RADIUS clients and servers that implement the attribute=2C but rather between a RADIUS client that implements the attribute and a RADIUS server that does not support the attribute or the new type.=20 If instead of using an unsigned 32 bit integer=2C an 8=2C 16 or 24 bit inte= ger=20 is used or a signed integer=2C then existing RADIUS servers will not be abl= e=20 to support the newly defined data type without a code change. =20 While existing RADIUS servers could send the newly defined types as a=20 String=2C this would force network administrators to enter the attributes i= n=20 hex form. This would be likely to cause errors in configuration=2C particu= larly in the case of signed integers.=20 However=2C an issue has been raised about whether RADIUS does in fact support 64-bit integers=2C or whether the data types used in previous attributes were either special types (e.g. Interface ID) or 64-bit octet strings.=20 If WG consensus is that RADIUS does not today support 64-bit integers=2C the choices would be as follows: 1. Recommend the addition of the 64-bit integer data type to implementations=3B=20 2. Remove the reference to 64-bit integers in the above paragraph.=20 = --_1ce7a2f8-53c5-48a6-869a-615ee6068a6d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Glen Zorn said:

>=3B It is worth noting that since RADIUS only = supports unsigned integers
>=3B of 32 or 64 bits=2C attributes usin= g signed integer data types or
>=3B unsigned integer types of other= sizes will require code changes=2C and
>=3B SHOULD be avoided.
= >=3B
>=3B It is difficult to see how either harm or interoperabilit= y problems could
>=3B arise from correctly implemented code changes=3B= indeed=2C this appears to be a
>=3B classic case of the use of RFC 21= 19 keywords to "try to impose a particular
>=3B method on implementers= where the method is not required for
>=3B interoperability".

T= he issue being described here is not one between RADIUS clients and
serv= ers that implement the attribute=2C but rather between
a RADIUS client t= hat implements the attribute and a RADIUS server
that does not support t= he attribute or the new type.

If instead of using an unsigned 32 bi= t integer=2C an 8=2C 16 or 24 bit integer
is used or a signed integer= =2C then existing RADIUS servers will not be able
to support the newly = defined data type without a code change. =3B
While existing RADIUS = servers could send the newly defined types as a
String=2C this would fo= rce network administrators to enter the attributes in
hex form. =3B= This would be likely to cause errors in configuration=2C particularly
i= n the case of signed integers.

However=2C an issue has been raised = about whether RADIUS does in fact
support 64-bit integers=2C or whether = the data types used in previous
attributes were either special types (e.= g. Interface ID) or 64-bit
octet strings.

If WG consensus is tha= t RADIUS does not today support 64-bit
integers=2C the choices would be = as follows:

1. Recommend the addition of the 64-bit integer data typ= e to
implementations=3B

2. Remove the reference to 64-bit intege= rs in the above paragraph.
= --_1ce7a2f8-53c5-48a6-869a-615ee6068a6d_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Oct 23 07:31:59 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 043FA3A683E for ; Fri, 23 Oct 2009 07:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.546 X-Spam-Level: X-Spam-Status: No, score=-9.546 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 E+y4V961kfMf for ; Fri, 23 Oct 2009 07:31:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 64BAE3A67D9 for ; Fri, 23 Oct 2009 07:31:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1L5x-0000TZ-GR for radiusext-data0@psg.com; Fri, 23 Oct 2009 14:26:21 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1L5W-0000JU-Te for radiusext@ops.ietf.org; Fri, 23 Oct 2009 14:25:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=9469; q=dns/txt; s=amsiport01001; t=1256307955; x=1257517555; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20Draft=20RADEXT=20Virtual=20Interim=20Mi nutes|Date:=20Fri,=2023=20Oct=202009=2016:23:07=20+0200 |Message-ID:=20|To:=20"Bernard=20Aboba"=20,=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20; bh=WP07eRoDzBc4g7ub2PAmr7bJfx+X5Fk7krwE/Akl4Zw=; b=lDI2N1y0VZKTH5Wg5poqAhMZcaqTbQK6XyjBNO9YeEdhmTEE9fn8sp6u kkGpr99xoy9CLWVToIvspQGPm0GElk4S8HMQJklE1grAEM8Ii8O4m/5SO 3XeT+qOCcg2mqgLw5eAX70kDuntgPZSW6oa/Pa25zvCHtyc3dMnE+yEDI g=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAAAOdY4UqQ/uCWe2dsb2JhbACCJC+YWQEBFiQGpSaYN4Q/BIFd X-IronPort-AV: E=Sophos;i="4.44,612,1249257600"; d="scan'208,217";a="52623521" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Oct 2009 14:23:43 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9NENhZm022710; Fri, 23 Oct 2009 14:23:43 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 16:23:43 +0200 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_01CA53EC.6C72D115" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 16:23:07 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: AcpMPHD8WLDMgt0UT9+7DTS5wYhD3QHiZLLw References: From: "Wojciech Dec (wdec)" To: "Bernard Aboba" , X-OriginalArrivalTime: 23 Oct 2009 14:23:43.0118 (UTC) FILETIME=[6C7FC2E0:01CA53EC] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA53EC.6C72D115 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, =20 with reference to the minutes below, I would like to post some observations and ask for clarifications: Draft-lourdelet-radext-ipv6-access-01 was the result of merging at least two drafts that had IPv6 as a common theme. This merger was done based on suggestion by the WG as well as your opinion (IETF74) that the WG was overloaded with drafts. Below you appear to steer towards a path that to go back to two drafts since in a single draft some of the proposals would definitely be lost.=20 Now, it's rather unfortunate that at neither IETF 75 nor at the interim meeting below the authors of draft-lourdelet-radext-ipv6-access-01 were heard but that the discussion on the draft happened anyway with conclusions reached. This seems a rather unorthodox way to proceed and has likely been the cause of even more confusion.=20 We're currently planning on a two draft approach, pretty much reverting to the state prior to the "merged draft", along with changes to rid of any datatype issues (fingers crossed) and additional explanatory text. Before we proceed on this path, which to some may seem to be yet another goose chase, could you confirm that this is also your expectation? =20 In addition to the above, at various points it has been claimed that a) there is "little interest" in the WG in this work and/or b) that outstanding comments have not been addressed. Regarding the "lack of interest", this also seems to be a rather odd claim given the array of authors on the drafts, the people offering to review and those having direct discussions on the WG mailer. Are you now convinced of "interest"? In terms of "outstanding comments", with the exception of the datatype debacle, it would be appreciated if you could point to ones that were not addressed. =20 Thanks, Woj. =20 =20 =20 ---snip---=20 =20 IPv6 Attribute Design Considerations Hannes: This document initially did not have much interest, then there was a lot of discussion on the list due to interest from the Broadband Forum. There are a number of ways to address the review from Alan. The document utilizes a tagging scheme similar to, but not exactly the same as RFC 2868. The authors did not want to depend on Extended Attributes since it has not been progressing (and is now expired). =20 Bernard: It seems like many of the attributes that are tagged relate to a router advertisement, correct? Hannes: That is my understanding.=20 Bernard: One of the objections to the current scheme is that it creates multiple new tagged data types.=20 A new attribute is needed for each element of the RA that needs to be expressed. It occurred to me that it might actually be easier to define an opaque blob that carries much of (or the entire) RA. =20 David Nelson: It seems like the lack of progress on Extended Attributes is creating a problem. Design Guidelines says that the RFC 2868 tagging scheme isn't suitable for generic use. But it doesn't make a recommendation. If we don't get Extended Attributes done, then we will be creating a problem.=20 After finishing Design Guidelines, it seems like this needs to be our #2 priority.=20 ---snip---=20 ------_=_NextPart_001_01CA53EC.6C72D115 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
with=20 reference to the minutes below, I would like to post some observations = and ask=20 for clarifications:
Draft-lourdelet-radext-ipv6-access-01 was the result of = merging at=20 least two drafts that had IPv6 as a common theme. This merger was done = based on=20 suggestion by the WG as well as your opinion (IETF74) that the WG was = overloaded=20 with drafts. Below you appear to steer towards a path that to go back = to =20 two drafts since in a single draft some of the proposals would = definitely=20 be lost.
Now,=20 it's rather unfortunate that at neither IETF 75 nor at the interim = meeting below=20 the authors of draft-lourdelet-radext-ipv6-access-01 were heard but that = the=20 discussion on the draft happened anyway with conclusions reached. This = seems a=20 rather unorthodox way to proceed and has likely been the cause of=20 even more confusion.
We're=20 currently planning on a two draft approach, pretty much reverting to the = state=20 prior to the "merged draft", along with changes to rid of any datatype = issues=20 (fingers crossed) and additional explanatory text. Before we proceed on = this=20 path, which to some may seem to be yet another goose chase, could = you=20 confirm that this is also your expectation?
 
In=20 addition to the above, at various points it has been claimed = that a) there=20 is "little interest" in the WG in this work and/or b) that outstanding = comments=20 have not been addressed.
Regarding the "lack of interest", this also seems to = be a rather=20 odd claim given the array of authors on the drafts, the people = offering to=20 review and those having direct discussions on the WG mailer. Are you now = convinced of "interest"?
In terms=20 of "outstanding comments", with the exception of the datatype = debacle, it=20 would be appreciated if you could point to ones that were not=20 addressed.
 
Thanks,
Woj.
 
 
 
---snip--- 
 
IPv6=20 Attribute Design Considerations

Hannes:  This document = initially did=20 not have much interest, then there was a lot of discussion on = the
list due to=20 interest from the Broadband Forum.  There are a number of ways to = address=20 the review from
Alan.  The document utilizes a tagging scheme = similar=20 to, but not exactly the same as RFC 2868.  The
authors did not = want to=20 depend on Extended Attributes since it has not been progressing (and is=20 now
expired). 

Bernard:  It seems like many of the=20 attributes that are tagged relate to a router advertisement,=20 correct?
Hannes:  That is my understanding.
Bernard:  = One of=20 the objections to the current scheme is that it creates multiple new = tagged data=20 types.
A new attribute is needed for each element of the RA that = needs to be=20 expressed.  It occurred to me that
it might actually be easier = to define=20 an opaque blob that carries much of (or the entire) RA.  =

David=20 Nelson: It seems like the lack of progress on Extended Attributes is = creating a=20 problem.  Design
Guidelines says that the RFC 2868 tagging = scheme isn't=20 suitable for generic use.  But it doesn't make
a = recommendation. =20 If we don't get Extended Attributes done, then we will be creating a = problem.=20
After finishing Design Guidelines, it seems like this needs to be = our #2=20 priority.

---snip--- 
------_=_NextPart_001_01CA53EC.6C72D115-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Oct 23 08:30:36 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 85E0D28C13D for ; Fri, 23 Oct 2009 08:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kk5yYYHMhCMh for ; Fri, 23 Oct 2009 08:30:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 85C7A3A688C for ; Fri, 23 Oct 2009 08:30:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1M2X-000Cwe-RJ for radiusext-data0@psg.com; Fri, 23 Oct 2009 15:26:53 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1M2W-000Cw4-0m for radiusext@ops.ietf.org; Fri, 23 Oct 2009 15:26:52 +0000 Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 45C5B1234604; Fri, 23 Oct 2009 17:26:50 +0200 (CEST) Message-ID: <4AE1CB39.4070605@deployingradius.com> Date: Fri, 23 Oct 2009 17:26:49 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Draft RADEXT Virtual Interim Minutes References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Wojciech Dec (wdec) wrote: > In terms of "outstanding comments", with the exception of the datatype > debacle, it would be appreciated if you could point to ones that were > not addressed. The datatype "debacle" can be more correctly described as: Me: Here's a review that results in no functional changes, but allows the specification to fit within the RADIUS data model, and to be deployed with minimum code changes You: We change nothing. 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 Fri Oct 23 08:52:20 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 D58563A6821 for ; Fri, 23 Oct 2009 08:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.157 X-Spam-Level: X-Spam-Status: No, score=0.157 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, 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 Lr1--ew1tDFm for ; Fri, 23 Oct 2009 08:52:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D90F3A659C for ; Fri, 23 Oct 2009 08:52:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1MND-000Gks-Pz for radiusext-data0@psg.com; Fri, 23 Oct 2009 15:48:15 +0000 Received: from [65.55.116.94] (helo=blu0-omc3-s19.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1MNA-000Gjw-VH for radiusext@ops.ietf.org; Fri, 23 Oct 2009 15:48:13 +0000 Received: from BLU137-W12 ([65.55.116.73]) by blu0-omc3-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 08:48:12 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_86defa2b-e7b3-4c55-a3e2-147fb6bd90e3_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , "radiusext@ops.ietf.org" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 08:48:12 -0700 Importance: Normal In-Reply-To: References: X-OriginalArrivalTime: 23 Oct 2009 15:48:12.0978 (UTC) FILETIME=[3A5F0120:01CA53F8] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: MIME-Version: 1.0 --_86defa2b-e7b3-4c55-a3e2-147fb6bd90e3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In looking through the WG minutes=2C I do not see much support for the asse= rtions you make below.=20 =20 The minutes of IETF 73 in Minneapolis (see http://www.ietf.org/proceedings/= 73/minutes/radext.txt) indicate that the WG gave significant negative feedb= ack on both drafts presented. The "next steps" were for the drafts to inco= rporate WG feedback and address the concerns. The idea of a merger was br= ought up (not by me)=2C but was not indicated in the next steps for advanc= ement. =20 =20 The minutes of IETF 74 shows that the presenter did not show up (see http:/= /www.ietf.org/proceedings/74/minutes/radext.htm).=20 =20 The minutes of IETF 75 (see http://www.ietf.org/proceedings/75/minutes/rade= xt.txt) disclose that the the document http://tools.ietf.org/html/draft-lou= rdelet-radext-ipv6-access was presented=2C and garnered some of the same ne= gative feedback as had earlier versions. =20 =20 While the authors did not attend the virtual interim=2C we did have attenda= nce from people with a concrete interest in a subset of the functionality. = It was David Miles who made the suggestion for the WG to consider http://t= ools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00 as the way forward= =2C and who also proposed addressing the feedback that had been obtained fr= om the WG at IETF 73 and 75.=20 =20 =20 =20 Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri=2C 23 Oct 2009 16:23:07 +0200 From: wdec@cisco.com To: bernard_aboba@hotmail.com=3B radiusext@ops.ietf.org Bernard=2C =20 with reference to the minutes below=2C I would like to post some observatio= ns and ask for clarifications: Draft-lourdelet-radext-ipv6-access-01 was the result of merging at least tw= o drafts that had IPv6 as a common theme. This merger was done based on sug= gestion by the WG as well as your opinion (IETF74) that the WG was overload= ed with drafts. Below you appear to steer towards a path that to go back to= two drafts since in a single draft some of the proposals would definitely= be lost.=20 Now=2C it's rather unfortunate that at neither IETF 75 nor at the interim m= eeting below the authors of draft-lourdelet-radext-ipv6-access-01 were hear= d but that the discussion on the draft happened anyway with conclusions rea= ched. This seems a rather unorthodox way to proceed and has likely been the= cause of even more confusion.=20 We're currently planning on a two draft approach=2C pretty much reverting t= o the state prior to the "merged draft"=2C along with changes to rid of any= datatype issues (fingers crossed) and additional explanatory text. Before = we proceed on this path=2C which to some may seem to be yet another goose c= hase=2C could you confirm that this is also your expectation? =20 In addition to the above=2C at various points it has been claimed that a) t= here is "little interest" in the WG in this work and/or b) that outstanding= comments have not been addressed. Regarding the "lack of interest"=2C this also seems to be a rather odd clai= m given the array of authors on the drafts=2C the people offering to review= and those having direct discussions on the WG mailer. Are you now convince= d of "interest"? In terms of "outstanding comments"=2C with the exception of the datatype de= bacle=2C it would be appreciated if you could point to ones that were not a= ddressed. =20 Thanks=2C Woj. =20 =20 =20 ---snip---=20 =20 IPv6 Attribute Design Considerations Hannes: This document initially did not have much interest=2C then there w= as a lot of discussion on the list due to interest from the Broadband Forum. There are a number of ways = to address the review from Alan. The document utilizes a tagging scheme similar to=2C but not exactly= the same as RFC 2868. The authors did not want to depend on Extended Attributes since it has not been= progressing (and is now expired). =20 Bernard: It seems like many of the attributes that are tagged relate to a = router advertisement=2C correct? Hannes: That is my understanding.=20 Bernard: One of the objections to the current scheme is that it creates mu= ltiple new tagged data types.=20 A new attribute is needed for each element of the RA that needs to be expre= ssed. It occurred to me that it might actually be easier to define an opaque blob that carries much of (= or the entire) RA. =20 David Nelson: It seems like the lack of progress on Extended Attributes is = creating a problem. Design Guidelines says that the RFC 2868 tagging scheme isn't suitable for generic= use. But it doesn't make a recommendation. If we don't get Extended Attributes done=2C then we will= be creating a problem.=20 After finishing Design Guidelines=2C it seems like this needs to be our #2 = priority.=20 ---snip--- = --_86defa2b-e7b3-4c55-a3e2-147fb6bd90e3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In looking through the WG minutes=2C I do not see much support for the asse= rtions you make below.
 =3B
The minutes of IETF 73 in Minneapolis (see http://www.ietf.org/proceedings/73/minute= s/radext.txt) indicate that the WG gave =3Bsignificant negative&nbs= p=3Bfeedback on both drafts presented. =3B The "next steps" were for th= e drafts to incorporate WG feedback and address the concerns. =3B = =3B The idea of a merger was brought up (not by =3B me)=2C but was not = indicated =3Bin the =3Bnext steps for advancement. =3B
 =3B
The minutes of IETF 74 shows that the presenter did not show up (see http://www.ietf= .org/proceedings/74/minutes/radext.htm).
 =3B
The minutes of IETF 75 (see http://www.ietf.org/proceedings/75/minutes/radext.txt) disclose that the the document http://tools.ietf.org/html/draft-lourdelet= -radext-ipv6-access was presented=2C and garnered some of the same nega= tive feedback as had earlier versions. =3B
 =3B
While the authors did not attend the virtual interim=2C we did have attenda= nce from people with a concrete interest in a subset of the functionality.&= nbsp=3B It was David Miles who made the suggestion for the WG to consider <= A href=3D"http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00">h= ttp://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00 as the wa= y forward=2C and who also proposed addressing the feedback that had been ob= tained from the WG at IETF 73 and 75.
 =3B
 =3B



 =3B
Subject: RE: Draft RADEXT Virtual Interim Minutes
Date: Fri=2C 23 Oct 20= 09 16:23:07 +0200
From: wdec@cisco.com
To: bernard_aboba@hotmail.com= =3B radiusext@ops.ietf.org

Bernard=2C
&nbs= p=3B
with reference to the minutes below=2C I would like to post some o= bservations and ask for clarifications:
Draft-lourdelet-radext-ipv6-access-01 was the result of merging at= least two drafts that had IPv6 as a common theme. This merger was done bas= ed on suggestion by the WG as well as your opinion (IETF74) that the WG was= overloaded with drafts. Below you appear to steer towards a path that to g= o back to =3B two drafts since in a single draft =3Bsome of the pro= posals would definitely be lost.
Now=2C it's rather unfortunate that at neither IETF 75 nor at the = interim meeting below the authors of draft-lourdelet-radext-ipv6-access-01 = were heard but that the discussion on the draft happened anyway with conclu= sions reached. This seems a rather unorthodox way to =3Bproceed and has= likely been the cause of even =3Bmore confusion.
We're currently planning on a two draft approach=2C pretty much re= verting to the state prior to the "merged draft"=2C along with changes to r= id of any datatype issues (fingers crossed) and additional explanatory text= . Before we proceed on this path=2C which to some =3Bmay seem to be yet= another goose chase=2C could you confirm that this is also your expectatio= n?
 =3B
In addition to the above=2C at various points it has been claimed = that =3Ba) there is "little interest" in the WG in this work and/or b) = that outstanding comments have not been addressed.
Regarding the "lack of interest"=2C this also =3Bseems to be a= rather odd claim =3Bgiven the array of authors on the drafts=2C the pe= ople offering to review and those having direct discussions on the WG maile= r. Are you now convinced of "interest"?
In terms of "outstanding comments"=2C with the exception of the da= tatype debacle=2C =3Bit would be appreciated if you could point to ones= that were not addressed.
 =3B
Thanks=2C
Woj.
 =3B
 =3B
&nbs= p=3B
---snip--- = =3B
 =3B
IPv6 Attribute Design Considerations

Hannes: =3B This do= cument initially did not have much interest=2C then there was a lot of disc= ussion on the
list due to interest from the Broadband Forum. =3B The= re are a number of ways to address the review from
Alan. =3B The doc= ument utilizes a tagging scheme similar to=2C but not exactly the same as R= FC 2868. =3B The
authors did not want to depend on Extended Attribut= es since it has not been progressing (and is now
expired). =3B
<= BR>Bernard: =3B It seems like many of the attributes that are tagged re= late to a router advertisement=2C correct?
Hannes: =3B That is my un= derstanding.
Bernard: =3B One of the objections to the current sche= me is that it creates multiple new tagged data types.
A new attribute i= s needed for each element of the RA that needs to be expressed. =3B It = occurred to me that
it might actually be easier to define an opaque blob= that carries much of (or the entire) RA. =3B

David Nelson: It = seems like the lack of progress on Extended Attributes is creating a proble= m. =3B Design
Guidelines says that the RFC 2868 tagging scheme isn't= suitable for generic use. =3B But it doesn't make
a recommendation.=  =3B If we don't get Extended Attributes done=2C then we will be creati= ng a problem.
After finishing Design Guidelines=2C it seems like this n= eeds to be our #2 priority.

---snip--- =3B
= --_86defa2b-e7b3-4c55-a3e2-147fb6bd90e3_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Oct 23 09:25:17 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 5B2B13A67F4 for ; Fri, 23 Oct 2009 09:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ANyScTPP2sFM for ; Fri, 23 Oct 2009 09:25:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 602453A680E for ; Fri, 23 Oct 2009 09:25:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1MtT-000MIp-DV for radiusext-data0@psg.com; Fri, 23 Oct 2009 16:21:35 +0000 Received: from web111408.mail.gq1.yahoo.com ([67.195.15.174]) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1MtQ-000MI8-Rg for radiusext@ops.ietf.org; Fri, 23 Oct 2009 16:21:33 +0000 Received: (qmail 29422 invoked by uid 60001); 23 Oct 2009 16:21:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1256314891; bh=9/XzY9C1iEx4iwuowX3MCImRrsUcoSe/AVsE/SB/qUg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=egyA5V1PBQsZmiIAr9dGPWZUzBbsfXM9OTFVm+uNh3FEHsHb0i2xC9RrKZpdHBbjIxxzwKXmnvcE58z93pZrF5gRzDqEZdav8y+xf7i2abFG52srbefNG6kvsiqTQ+YMDGxGJ40/13je/MIUsnMj3ewagLw1mtuI0JRWo7OyG9w= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pH/laM5JSUz67HgJD60SGFdICYEYkJoHtAhWA4gLjj6mGoBrCi7B4vP0J+mj1RAuFqptXxZEipbCkb25DnO1FsLgY3dln5htamennauUEV4rgZMoXiw6Wrdd9EnFuA1R78u/MXgWJc/gWIaHTCCMtYjAt1Gq1qfAlIDRrvQugOs=; Message-ID: <540408.29377.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: LtnweGIVM1lS80pEDIGCfg0lLatRXfLEdiQhsq335nesm8Qv.hctU7E.55ccpNF.NG5jEOuN0Kgyih1.E78f7eOeWkjq5L6I4jD5J6rWNk_ksHG0dBio7O.A4dwEuVtu27F_g0Hs_EiIgVloxAuebbdvYM2d5hwBTr3O6SGjTupzzNRI6r8KrNDnrxWWFfN22YAaH03hWH.DJsQ22s_EIF.Er_RWoC1tgzN_jDuO04UqUwMpa4w2z8jMg0BNHTPBVF19KLiDrJ4YKpl8BiXoXutHDQjoUvzFZJeXF5MnWHwW.96EK8pwq_iDi9VKhcPwm1eV7zhAc18GG5cl2y6g7GUD2DelPpnX91y3w4_e1t2DG6t4ljGlRSc- Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Fri, 23 Oct 2009 09:21:31 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.361.3 References: <4AE1CB39.4070605@deployingradius.com> Date: Fri, 23 Oct 2009 09:21:31 -0700 (PDT) From: Behcet Sarikaya Reply-To: Behcet Sarikaya Subject: Re: Draft RADEXT Virtual Interim Minutes To: Alan DeKok , "Wojciech Dec \(wdec\)" Cc: Bernard Aboba , radiusext@ops.ietf.org In-Reply-To: <4AE1CB39.4070605@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi Alan,=0A=A0 In fact, before the Interim call we had made a revision to a= ddress all of your concerns and made=A0 the specification to fit within the= RADIUS data model, and to be deployed with minimum code changes as you wis= hed.=0A=0AGlen was expected to attend the call and state this. But I think = he got sick and couldn't attend. =0ASigh.=0A=0AI wish Glen a quick recovery= .=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----=0A> From= : Alan DeKok =0A> To: Wojciech Dec (wdec) =0A> Cc: Bernard Aboba ; radiusext@ops= .ietf.org=0A> Sent: Fri, October 23, 2009 10:26:49 AM=0A> Subject: Re: Draf= t RADEXT Virtual Interim Minutes=0A> =0A> Wojciech Dec (wdec) wrote:=0A> > = In terms of "outstanding comments", with the exception of the datatype=0A> = > debacle, it would be appreciated if you could point to ones that were=0A>= > not addressed.=0A> =0A> =A0 The datatype "debacle" can be more correctly= described as:=0A> =0A> Me: Here's a review that results in no functional c= hanges, but allows=0A> the specification to fit within the RADIUS data mode= l, and to be=0A> deployed with minimum code changes=0A> =0A> You: We change= nothing.=0A> =0A> =A0 Alan DeKok.=0A> =0A> --=0A> to unsubscribe send a me= ssage to radiusext-request@ops.ietf.org with=0A> the word 'unsubscribe' in = a single line as the message text body.=0A> archive: =0A=0A=0A=0A -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Oct 23 09:31:10 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 139A53A67FB for ; Fri, 23 Oct 2009 09:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.351, 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 Rgwnlc+k440x for ; Fri, 23 Oct 2009 09:31:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 341643A67F4 for ; Fri, 23 Oct 2009 09:31:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1N0d-000NKQ-7m for radiusext-data0@psg.com; Fri, 23 Oct 2009 16:28:59 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1N0b-000NJw-56 for radiusext@ops.ietf.org; Fri, 23 Oct 2009 16:28:57 +0000 Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 946BE1234604; Fri, 23 Oct 2009 18:28:55 +0200 (CEST) Message-ID: <4AE1D9C6.2070807@deployingradius.com> Date: Fri, 23 Oct 2009 18:28:54 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behcet Sarikaya CC: "Wojciech Dec (wdec)" , Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Draft RADEXT Virtual Interim Minutes References: <4AE1CB39.4070605@deployingradius.com> <540408.29377.qm@web111408.mail.gq1.yahoo.com> In-Reply-To: <540408.29377.qm@web111408.mail.gq1.yahoo.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Behcet Sarikaya wrote: > Hi Alan, > In fact, before the Interim call we had made a revision to address all of your concerns and made the specification to fit within the RADIUS data model, and to be deployed with minimum code changes as you wished. I hadn't seen that revision. My comments were directed to the discussion on this list, and not about anything else. I believe that the functionality defined in the document is useful. I have no major concern with 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 Fri Oct 23 10:23:19 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 AD53F3A6819 for ; Fri, 23 Oct 2009 10:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.336 X-Spam-Level: X-Spam-Status: No, score=-9.336 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 R0vbaBfwHppC for ; Fri, 23 Oct 2009 10:23:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E051F3A6784 for ; Fri, 23 Oct 2009 10:23:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1NmW-0004ZD-0W for radiusext-data0@psg.com; Fri, 23 Oct 2009 17:18:28 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1NmQ-0004Yu-Hy for radiusext@ops.ietf.org; Fri, 23 Oct 2009 17:18:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=25624; q=dns/txt; s=amsiport01001; t=1256318302; x=1257527902; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20Draft=20RADEXT=20Virtual=20Interim=20Mi nutes|Date:=20Fri,=2023=20Oct=202009=2019:18:15=20+0200 |Message-ID:=20|To:=20"Bernard=20Aboba"=20,=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20=20; bh=o7u1WO4KLL3mTIue2h7SToSa2S5t8HH0LcSDwKV2FIM=; b=p41pXSqsqzY/fcplsgdBuhhats2LJ+eyQ25xQCVbjTko3GWZYOQguD4u s0Hg4pOYnPl0Mz/X9fKHlhkHFYkX5+caeM/6qEqZi+d/fR48Z00JanypD zo9MtOOLDV9UpSdCO42HzVmfD6/vSQR8kaRYnn/F2D7e8sPvhowf5Lpy6 A=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8AAOqB4UqQ/uCWe2dsb2JhbACCJS6NDotMAQEWJAalPpg1hD8EgV0 X-IronPort-AV: E=Sophos;i="4.44,613,1249257600"; d="scan'208,217";a="52639048" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Oct 2009 17:18:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9NHIKBC008264; Fri, 23 Oct 2009 17:18:20 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 19:18:20 +0200 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_01CA5404.D18DFD31" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 19:18:15 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxA References: From: "Wojciech Dec (wdec)" To: "Bernard Aboba" , X-OriginalArrivalTime: 23 Oct 2009 17:18:20.0714 (UTC) FILETIME=[D1A208A0:01CA5404] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5404.D18DFD31 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Unfortunately your mail did not answer my direct questions, which are aimed at moving forward. =20 In terms of your initative to look backward and dissect the minutes, perhaps you should also take into consideration the progress of the draft. We have: =20 IETF 72;=20 =20 http://www.ietf.org/old/2009/proceedings/08jul/minutes/radext.txt =20 Introduces draft-lourdelet-radext-ipv6-dhcp-00 - Advice given for doing a rfc3162bis =20 IETF 73; =20 Merged rfc3162bis draft presented. Additionally remarks passed about the WG being overloaded with drafts. Preference expressed for non rfc3162bis approach =20 IETF74 states: =20 draft-lourdelet-radext-ipv6-access introduced. (Just 3 attributes) =20 RADIUS attributes for IPv6 Access Networks, Benoit Lourdelet http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access =20 a. Chair: Document is currently in review for acceptance as a WG work item. Only one review so far, which indicates that the document is not yet ready. Please review the document and send comments to the list!=20 b. Problem statement - RFC3162 needs additions to accommodate IPv6 production networks. Feedback is coming in from actual deployments. Need flexibility.=20 c. IPv6 DNS location needs to be configured on a subscriber basis - wholesale, VPN.=20 d. Implementation can happen in DHCP and SLAAC.=20 e. Review of requirements - individual IPv6 addresses must be offered to the subscriber as concatenation of prefix and interface id attributes does not cover all cases.=20 f. More specific routes should be transmitted to the subscriber - multi-homing, multiple attachments - see draft-dec-dhcpv6-route-option-01.=20 g. Prefix lifetimes must be configured on a prefix basis.=20 h. Glen Zorn: New attributes should be added - No objection to do this from the WG.=20 The above feedback led to changes to the draft, like introducing "lifetimes". At this point however the draft seems to have been OK'ed in principle by the WG, and there was no evidence of the draft having "same negative feedback as had earlier versions" ... =20 =20 IETF75: =20 Discussion had, without presenter, who happened to be there and reportedly did try to present... =20 Redext virtual meeting: =20 Discussion had, without any of the authors. In the runup, emails asking for clarification went unanswered. =20 Now, in terms of your note below (I quote "we did have attendance from people with a concrete interest in a subset of the functionality"), it appears to be some kind of consensus call, which is another rather unorthodox development given all of the previous record. =20 -Woj. =20 =20 =20 =20 ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 23 October 2009 17:48 To: Wojciech Dec (wdec); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 In looking through the WG minutes, I do not see much support for the assertions you make below.=20 =20 The minutes of IETF 73 in Minneapolis (see http://www.ietf.org/proceedings/73/minutes/radext.txt) indicate that the WG gave significant negative feedback on both drafts presented. The "next steps" were for the drafts to incorporate WG feedback and address the concerns. The idea of a merger was brought up (not by me), but was not indicated in the next steps for advancement. =20 =20 The minutes of IETF 74 shows that the presenter did not show up (see http://www.ietf.org/proceedings/74/minutes/radext.htm).=20 =20 The minutes of IETF 75 (see http://www.ietf.org/proceedings/75/minutes/radext.txt) disclose that the the document http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access was presented, and garnered some of the same negative feedback as had earlier versions. =20 =20 While the authors did not attend the virtual interim, we did have attendance from people with a concrete interest in a subset of the functionality. It was David Miles who made the suggestion for the WG to consider http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00 as the way forward, and who also proposed addressing the feedback that had been obtained from the WG at IETF 73 and 75.=20 =20 =20 =09 =09 =09 =20 =09 ________________________________ Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 16:23:07 +0200 From: wdec@cisco.com To: bernard_aboba@hotmail.com; radiusext@ops.ietf.org =09 =09 Bernard, =20 with reference to the minutes below, I would like to post some observations and ask for clarifications: Draft-lourdelet-radext-ipv6-access-01 was the result of merging at least two drafts that had IPv6 as a common theme. This merger was done based on suggestion by the WG as well as your opinion (IETF74) that the WG was overloaded with drafts. Below you appear to steer towards a path that to go back to two drafts since in a single draft some of the proposals would definitely be lost.=20 Now, it's rather unfortunate that at neither IETF 75 nor at the interim meeting below the authors of draft-lourdelet-radext-ipv6-access-01 were heard but that the discussion on the draft happened anyway with conclusions reached. This seems a rather unorthodox way to proceed and has likely been the cause of even more confusion.=20 We're currently planning on a two draft approach, pretty much reverting to the state prior to the "merged draft", along with changes to rid of any datatype issues (fingers crossed) and additional explanatory text. Before we proceed on this path, which to some may seem to be yet another goose chase, could you confirm that this is also your expectation? =20 In addition to the above, at various points it has been claimed that a) there is "little interest" in the WG in this work and/or b) that outstanding comments have not been addressed. Regarding the "lack of interest", this also seems to be a rather odd claim given the array of authors on the drafts, the people offering to review and those having direct discussions on the WG mailer. Are you now convinced of "interest"? In terms of "outstanding comments", with the exception of the datatype debacle, it would be appreciated if you could point to ones that were not addressed. =20 Thanks, Woj. =20 =20 =20 ---snip---=20 =09 IPv6 Attribute Design Considerations =09 Hannes: This document initially did not have much interest, then there was a lot of discussion on the list due to interest from the Broadband Forum. There are a number of ways to address the review from Alan. The document utilizes a tagging scheme similar to, but not exactly the same as RFC 2868. The authors did not want to depend on Extended Attributes since it has not been progressing (and is now expired). =20 =09 Bernard: It seems like many of the attributes that are tagged relate to a router advertisement, correct? Hannes: That is my understanding.=20 Bernard: One of the objections to the current scheme is that it creates multiple new tagged data types.=20 A new attribute is needed for each element of the RA that needs to be expressed. It occurred to me that it might actually be easier to define an opaque blob that carries much of (or the entire) RA. =20 =09 David Nelson: It seems like the lack of progress on Extended Attributes is creating a problem. Design Guidelines says that the RFC 2868 tagging scheme isn't suitable for generic use. But it doesn't make a recommendation. If we don't get Extended Attributes done, then we will be creating a problem.=20 After finishing Design Guidelines, it seems like this needs to be our #2 priority.=20 =09 ---snip---=20 ------_=_NextPart_001_01CA5404.D18DFD31 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Unfortunately your mail did not answer my direct questions, = which are=20 aimed at moving forward.
 
In terms=20 of your initative to look backward and dissect the minutes, perhaps = you=20 should also take into consideration the progress of the draft. We=20 have:
 
IETF 72;=20
 
http://www.ietf.org/old/2009/proceedings/08jul/minutes/radext.txt
 
Introduces draft-lourdelet-radext-ipv6-dhcp-00 - Advice = given for=20 doing a rfc3162bis
 
IETF=20 73;
 
Merged=20 rfc3162bis draft presented. Additionally remarks passed about the WG = being=20 overloaded with drafts.
Preference expressed for non rfc3162bis = approach
 
IETF74=20 states:
 
draft-lourdelet-radext-ipv6-access=20 introduced. (Just 3 attributes)
 
RADIUS attributes for IPv6 = Access=20 Networks, Benoit Lourdelet http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-acces= s
  1. Chair:=20 Document is currently in review for acceptance as a WG work = item. =20 Only one review so far, which indicates that the document is = not yet=20 ready.  Please review the document and send comments = to the=20 list!=20
  2. Problem=20 statement – RFC3162 needs additions to accommodate IPv6 = production networks.=20 Feedback is coming in from actual deployments. Need=20 flexibility.=20
  3. IPv6 DNS=20 location needs to be configured on a subscriber basis – = wholesale,=20 VPN.=20
  4. Implementation can happen in DHCP and=20 SLAAC.=20
  5. Review of=20 requirements – individual IPv6 addresses must be offered to the = subscriber as=20 concatenation of prefix and interface id attributes does not cover all = cases.=20
  6. More=20 specific routes should be transmitted to the subscriber – = multi-homing,=20 multiple attachments – see=20 draft-dec-dhcpv6-route-option-01.=20
  7. Prefix=20 lifetimes must be configured on a prefix = basis.=20
  8. Glen Zorn:=20 New attributes should be added – No objection to do this from = the WG.=20
The above feedback led to = changes to=20 the draft, like introducing "lifetimes".=20 At this point however the = draft seems=20 to have been OK'ed in principle by the WG, and there was no = evidence of the=20 draft having "same negative feedback as had earlier=20 versions" ...
 
 
IETF75:
 
Discussion had, = without=20 presenter, who happened to be there and reportedly did try to=20 present...
 
Redext virtual=20 meeting:
 
Discussion had, without = any of the=20 authors. In the runup, emails asking for clarification went=20 unanswered.
 
Now, in terms = of your note=20 below (I quote "we did have=20 attendance from people with a concrete interest in a subset of the=20 functionality"), it appears to be some kind of consensus call,=20 which is another rather unorthodox development given all of = the=20 previous record.
 
-Woj.
 
 
 
 

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: 23 October 2009=20 17:48
To: Wojciech Dec (wdec);=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

In looking through the WG minutes, I do not see much = support for=20 the assertions you make below.
 
The minutes of IETF 73 in = Minneapolis (see http://www= .ietf.org/proceedings/73/minutes/radext.txt)=20 indicate that the WG gave significant negative feedback on = both=20 drafts presented.  The "next steps" were for the drafts to = incorporate WG=20 feedback and address the concerns.   The idea of a merger = was=20 brought up (not by  me), but was not indicated in = the next=20 steps for advancement. 
 
The minutes of IETF 74 = shows that=20 the presenter did not show up (see http://www= .ietf.org/proceedings/74/minutes/radext.htm).=20
 
The minutes of IETF 75 (see http://www= .ietf.org/proceedings/75/minutes/radext.txt)=20 disclose that the the document ht= tp://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access=20 was presented, and garnered some of the same negative feedback as had = earlier=20 versions. 
 
While the authors did not attend the = virtual=20 interim, we did have attendance from people with a concrete interest = in a=20 subset of the functionality.  It was David Miles who made the = suggestion=20 for the WG to consider h= ttp://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00=20 as the way forward, and who also proposed addressing the feedback that = had=20 been obtained from the WG at IETF 73 and 75.=20
 
 



 
Subject: RE: Draft RADEXT Virtual Interim Minutes
Date: Fri, 23 Oct = 2009=20 16:23:07 +0200
From: wdec@cisco.com
To: = bernard_aboba@hotmail.com;=20 radiusext@ops.ietf.org

Bernard,
 
with reference to the minutes below, I would like to post = some=20 observations and ask for clarifications:
Draft-lourdelet-radext-ipv6-access-01 was the result of = merging at=20 least two drafts that had IPv6 as a common theme. This merger was done = based=20 on suggestion by the WG as well as your opinion (IETF74) that the WG = was=20 overloaded with drafts. Below you appear to steer towards a path that = to go=20 back to  two drafts since in a single draft some of the = proposals=20 would definitely be lost.
Now, it's rather unfortunate that at neither IETF 75 nor = at the=20 interim meeting below the authors of = draft-lourdelet-radext-ipv6-access-01=20 were heard but that the discussion on the draft happened anyway with=20 conclusions reached. This seems a rather unorthodox way = to proceed and=20 has likely been the cause of even more confusion. =
We're currently planning on a two draft approach, pretty = much=20 reverting to the state prior to the "merged draft", along with changes = to rid=20 of any datatype issues (fingers crossed) and additional explanatory = text.=20 Before we proceed on this path, which to some may seem to be yet = another=20 goose chase, could you confirm that this is also your=20 expectation?
 
In=20 addition to the above, at various points it has been claimed = that a)=20 there is "little interest" in the WG in this work and/or b) that = outstanding=20 comments have not been addressed.
Regarding the "lack of interest", this also seems to = be a=20 rather odd claim given the array of authors on the drafts, the = people=20 offering to review and those having direct discussions on the WG = mailer. Are=20 you now convinced of "interest"?
In=20 terms of "outstanding comments", with the exception of the datatype=20 debacle, it would be appreciated if you could point to ones that = were not=20 addressed.
 
Thanks,
Woj.
 
 
 
---snip--- 

IPv6=20 Attribute Design Considerations

Hannes:  This document = initially=20 did not have much interest, then there was a lot of discussion on = the
list=20 due to interest from the Broadband Forum.  There are a number of = ways to=20 address the review from
Alan.  The document utilizes a tagging = scheme=20 similar to, but not exactly the same as RFC 2868.  The
authors = did not=20 want to depend on Extended Attributes since it has not been = progressing (and=20 is now
expired). 

Bernard:  It seems like many of = the=20 attributes that are tagged relate to a router advertisement,=20 correct?
Hannes:  That is my understanding.
Bernard:  = One of=20 the objections to the current scheme is that it creates multiple new = tagged=20 data types.
A new attribute is needed for each element of the RA = that=20 needs to be expressed.  It occurred to me that
it might = actually be=20 easier to define an opaque blob that carries much of (or the entire) = RA. =20

David Nelson: It seems like the lack of progress on Extended=20 Attributes is creating a problem.  Design
Guidelines says that = the RFC=20 2868 tagging scheme isn't suitable for generic use.  But it = doesn't=20 make
a recommendation.  If we don't get Extended Attributes = done, then=20 we will be creating a problem.
After finishing Design Guidelines, = it seems=20 like this needs to be our #2 priority.

---snip--- 
------_=_NextPart_001_01CA5404.D18DFD31-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Oct 23 11:11:41 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 642EE3A6965 for ; Fri, 23 Oct 2009 11:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.127 X-Spam-Level: X-Spam-Status: No, score=-0.127 tagged_above=-999 required=5 tests=[AWL=0.368, 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 zvg6RYwBm19S for ; Fri, 23 Oct 2009 11:11:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7AD0E3A691A for ; Fri, 23 Oct 2009 11:11:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1OYA-000AMP-2Z for radiusext-data0@psg.com; Fri, 23 Oct 2009 18:07:42 +0000 Received: from [65.55.111.85] (helo=blu0-omc2-s10.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1OY8-000AMD-5r for radiusext@ops.ietf.org; Fri, 23 Oct 2009 18:07:40 +0000 Received: from BLU137-DS6 ([65.55.111.71]) by blu0-omc2-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 11:07:39 -0700 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Alan DeKok'" , "'Wojciech Dec \(wdec\)'" CC: References: <4AE1CB39.4070605@deployingradius.com> In-Reply-To: <4AE1CB39.4070605@deployingradius.com> Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 11:07:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpT9T5A21YeUFY6RNutUQ1ruzje2AAFj0WQ Content-Language: en-us X-OriginalArrivalTime: 23 Oct 2009 18:07:40.0034 (UTC) FILETIME=[B5866E20:01CA540B] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Wojciech Dec (wdec) wrote: > In terms of "outstanding comments", with the exception of the datatype > debacle, it would be appreciated if you could point to ones that were > not addressed. Please read the minutes of the RADEXT WG meetings (such as IETF 73) at which the draft has been discussed. There was quite a bit of feedback presented at those meetings, most of which has been addressed. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Oct 23 11:24:54 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 EA8853A68CC for ; Fri, 23 Oct 2009 11:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.159 X-Spam-Level: * X-Spam-Status: No, score=1.159 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_50=0.001, 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 mlG3bgxMRLXT for ; Fri, 23 Oct 2009 11:24:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B0223A6844 for ; Fri, 23 Oct 2009 11:24:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1OmE-000CJ2-DT for radiusext-data0@psg.com; Fri, 23 Oct 2009 18:22:14 +0000 Received: from [65.55.116.76] (helo=blu0-omc3-s1.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1OmC-000CIG-1I for radiusext@ops.ietf.org; Fri, 23 Oct 2009 18:22:12 +0000 Received: from BLU137-DS2 ([65.55.116.74]) by blu0-omc3-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 11:22:11 -0700 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Wojciech Dec \(wdec\)'" , References: In-Reply-To: Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 11:22:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0308_01CA53D3.1008D6A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxAAAQa5/A= Content-Language: en-us X-OriginalArrivalTime: 23 Oct 2009 18:22:11.0989 (UTC) FILETIME=[BD403450:01CA540D] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0308_01CA53D3.1008D6A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Wojcejech said: "At this point however the draft seems to have been OK'ed in principle by the WG, and there was no evidence of the draft having "same negative feedback as had earlier versions" ..." In looking through the minutes of the WG meetings I don't see any indications that the draft was accepted as a WG work item. Within RADEXT WG, adoption requires a formal consensus call, which was subsequently held (with insufficient interest being displayed so far). The IETF 73 minutes do provide an indication of the overall reaction to the document, which included objections both in principle and with respect to the specifics. I can post the individual comments made as Issues if you like. At the Virtual Interim, David Miles proposed an approach for overcoming those objections and moving the document forward. ------=_NextPart_000_0308_01CA53D3.1008D6A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wojcejech said:

 

“At this point however the draft seems to have been = OK'ed in principle by the WG, and there was no evidence of the draft = having "same negative feedback as had earlier versions" ...”

 

In looking through the minutes of the WG meetings I = don’t see any indications that the draft was accepted as a WG work item. =    

 

Within RADEXT WG, adoption requires a formal consensus = call, which was subsequently held (with insufficient interest being displayed = so far).

 

The IETF 73 minutes do provide an indication of the = overall reaction to the document, which included objections both in principle and with = respect to the specifics.

 

I can post the individual comments made as Issues if you = like.

 

At the Virtual Interim, David Miles proposed an approach = for overcoming those objections and moving the document forward. =

 

 

 

 

 

 =

------=_NextPart_000_0308_01CA53D3.1008D6A0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Oct 23 11:37: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 C9AAB3A6978 for ; Fri, 23 Oct 2009 11:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.105 X-Spam-Level: X-Spam-Status: No, score=-0.105 tagged_above=-999 required=5 tests=[AWL=0.390, 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 v6QGQVKD+w0N for ; Fri, 23 Oct 2009 11:37:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D47383A6856 for ; Fri, 23 Oct 2009 11:37:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1Ox2-000DkF-UV for radiusext-data0@psg.com; Fri, 23 Oct 2009 18:33:24 +0000 Received: from [65.55.111.92] (helo=blu0-omc2-s17.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1Ox1-000Djw-7k for radiusext@ops.ietf.org; Fri, 23 Oct 2009 18:33:23 +0000 Received: from BLU137-DS2 ([65.55.111.72]) by blu0-omc2-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 11:33:22 -0700 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Alan DeKok'" CC: References: <4AE1CB39.4070605@deployingradius.com> In-Reply-To: Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 11:33:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpT9T5A21YeUFY6RNutUQ1ruzje2AAFj0WQAADwWWA= Content-Language: en-us X-OriginalArrivalTime: 23 Oct 2009 18:33:22.0760 (UTC) FILETIME=[4D0FBC80:01CA540F] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Wojciech Dec (wdec) wrote: > In terms of "outstanding comments", with the exception of the datatype > debacle, it would be appreciated if you could point to ones that were > not addressed. Please read the minutes of the RADEXT WG meetings (such as IETF 73) at which the draft has been discussed. There was quite a bit of feedback presented at those meetings, most of which has not been addressed. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Oct 23 11:39:27 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 C4A413A6856 for ; Fri, 23 Oct 2009 11:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.195 X-Spam-Level: X-Spam-Status: No, score=-9.195 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 SqaI1scklut3 for ; Fri, 23 Oct 2009 11:39:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 015693A6844 for ; Fri, 23 Oct 2009 11:39:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1Ozj-000E9W-PX for radiusext-data0@psg.com; Fri, 23 Oct 2009 18:36:11 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1Ozg-000E9G-DW for radiusext@ops.ietf.org; Fri, 23 Oct 2009 18:36:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=11938; q=dns/txt; s=amsiport01001; t=1256322968; x=1257532568; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20Draft=20RADEXT=20Virtual=20Interim=20Mi nutes|Date:=20Fri,=2023=20Oct=202009=2020:35:58=20+0200 |Message-ID:=20|To:=20"Bernard=20Aboba"=20,=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20=20=20=20; bh=QMJqGWrVzpBSvTwLmcbrmLKl0lOs3WkybTb8Xb+nQBo=; b=EvcTr1zgGXABkRnfV5CxbO0tr9VKf0b1dFjgzuW+jRvnjGmIlg7t5TRX QLhSRcKv3n4y/28v2MaMPFGj1YyggR/ujyBDmeg/4unm/JQVql/RjSKga 32CHNh7BNZGWwLoYfx/Db9RWjDvcLfFs/5IEsBccGbhB6CrsBW3aMo7Zn w=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8AAKuU4UqQ/uCWe2dsb2JhbACCKCuNDotMAQEWJAaldZg2hD8E X-IronPort-AV: E=Sophos;i="4.44,613,1249257600"; d="scan'208,217";a="52642467" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Oct 2009 18:36:06 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9NIa675020019; Fri, 23 Oct 2009 18:36:06 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 20:36:06 +0200 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_01CA540F.AE7D66CF" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 20:35:58 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxAAAQa5/AAAMdz4A== References: From: "Wojciech Dec (wdec)" To: "Bernard Aboba" , X-OriginalArrivalTime: 23 Oct 2009 18:36:06.0356 (UTC) FILETIME=[AE928140:01CA540F] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA540F.AE7D66CF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 23 October 2009 20:22 To: Wojciech Dec (wdec); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 Wojcejech said: =20 "At this point however the draft seems to have been OK'ed in principle by the WG, and there was no evidence of the draft having "same negative feedback as had earlier versions" ..." =20 In looking through the minutes of the WG meetings I don't see any indications that the draft was accepted as a WG work item. =20 =20 Within RADEXT WG, adoption requires a formal consensus call, which was subsequently held (with insufficient interest being displayed so far).=20 =20 The IETF 73 minutes do provide an indication of the overall reaction to the document, which included objections both in principle and with respect to the specifics.=20 =20 I can post the individual comments made as Issues if you like.=20 =20 At the Virtual Interim, David Miles proposed an approach for overcoming those objections and moving the document forward. =20 =20 Woj> As per my earlier mail(s): - could you confirm that what my mail outlined in terms of moving forward is also your expectation?=20 - Are you now convinced of "interest"? (and if not, or partially, then on what grounds given the rather abundant amount of contributors, reviewers, discussion?) - could you point out (summarise) the issues that were not addressed? =20 Thanks. =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01CA540F.AE7D66CF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: 23 October 2009=20 20:22
To: Wojciech Dec (wdec);=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

Wojcejech=20 said:

 

“At this = point=20 however the draft seems to have been OK'ed in principle by the = WG, and=20 there was no evidence of the draft having "same negative feedback as = had=20 earlier versions" ...”

 

In=20 looking through the minutes of the WG meetings I don’t see any = indications=20 that the draft was accepted as a WG work item.=20    

 

Within=20 RADEXT WG, adoption requires a formal consensus call, which was = subsequently=20 held (with insufficient interest being displayed so far).=20

 

The=20 IETF 73 minutes do provide an indication of the overall reaction to = the=20 document, which included objections both in principle and with respect = to the=20 specifics.

 

I=20 can post the individual comments made as Issues if you like.=20

 

At=20 the Virtual Interim, David Miles proposed an approach for overcoming = those=20 objections and moving the document forward.  

 

Woj> As per=20 my earlier mail(s):

- could you confirm that what my mail outlined = in terms of=20 moving forward is also your=20 expectation? 

- Are you now convinced of = "interest"? (and if=20 not, or partially, then on what grounds given the rather abundant = amount of=20 contributors, reviewers, discussion?)

- could you=20 point out (summarise) the issues that were not=20 addressed?

 

Thanks.

 

 

 

 

 

 

------_=_NextPart_001_01CA540F.AE7D66CF-- -- to 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 Oct 24 05:22: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 8A56A3A6832 for ; Sat, 24 Oct 2009 05:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hofUjq5WRtgg for ; Sat, 24 Oct 2009 05:22:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D14F3A67F8 for ; Sat, 24 Oct 2009 05:22:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1fYU-000Fx0-RX for radiusext-data0@psg.com; Sat, 24 Oct 2009 12:17:10 +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 1N1fYR-000Fwc-MF for radiusext@ops.ietf.org; Sat, 24 Oct 2009 12:17:09 +0000 Received: from OMTA16.westchester.pa.mail.comcast.net ([76.96.62.88]) by QMTA02.westchester.pa.mail.comcast.net with comcast id wbs11c0011uE5Es52cH7jn; Sat, 24 Oct 2009 12:17:07 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA16.westchester.pa.mail.comcast.net with comcast id wcRB1c0084H2mdz3ccRBgq; Sat, 24 Oct 2009 12:25:11 +0000 From: "Dave Nelson" To: References: Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sat, 24 Oct 2009 08:17:11 -0400 Message-ID: <18B576169E2241A5AF24D33D4C5B8870@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxAAAQa5/AAAMdz4AAk/y3g Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Wojciech Dec writes... > - Are you now convinced of "interest"? (and if not, or > partially, then on what grounds given the rather abundant > amount of contributors, reviewers, discussion?) The level of interest required to accept a work item in the RADEXT WG is, as you say, an "abundant" number of reviewers, not including the authors. There is no hard rule, but half a dozen would be a good threshold. The success of any WG in producing quality documents is tied to the number of members that are willing to actively review and comment upon the drafts. Of course, it also depends upon the authors providing timely and responsive revisions. I haven't taken a count recently, but excluding authors, I'm not sure I'd use the term "abundant" to describe the number of independent reviewers. -- to 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 Oct 24 06:13: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 7B8883A68DD for ; Sat, 24 Oct 2009 06:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.056 X-Spam-Level: X-Spam-Status: No, score=-1.056 tagged_above=-999 required=5 tests=[AWL=-0.619, 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 mlyi-kbjHjAW for ; Sat, 24 Oct 2009 06:13:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9369B3A68B5 for ; Sat, 24 Oct 2009 06:13:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1gN9-000MIS-8b for radiusext-data0@psg.com; Sat, 24 Oct 2009 13:09:31 +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 1N1gN6-000MHz-5S for radiusext@ops.ietf.org; Sat, 24 Oct 2009 13:09:29 +0000 Received: from OMTA24.westchester.pa.mail.comcast.net ([76.96.62.76]) by QMTA04.westchester.pa.mail.comcast.net with comcast id wc271c0031ei1Bg54d9UUf; Sat, 24 Oct 2009 13:09:28 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA24.westchester.pa.mail.comcast.net with comcast id wdGC1c00J0BTMe43kdGGWA; Sat, 24 Oct 2009 13:16:26 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: , "'IESG IESG'" References: <007001ca52fb$4bb36f40$e31a4dc0$@net> <4AE145A9.2090006@deployingradius.com> In-Reply-To: <4AE145A9.2090006@deployingradius.com> Subject: RE: FW: ISSUE: Inappropriate usage of RFC 2119 key words Date: Sat, 24 Oct 2009 20:08:59 +0700 Message-ID: <039501ca54ab$2f6fb030$8e4f1090$@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: AcpTpaSdqvnDTebiR0WSt5sagsHmkwBBHLaw Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok [mailto:aland@deployingradius.com] writes: > > The section of the draft in question says: > > > > It is worth noting that since RADIUS only supports unsigned > integers > > of 32 or 64 bits, attributes using signed integer data types or > > unsigned integer types of other sizes will require code changes, > and > > SHOULD be avoided. > > > > It is difficult to see how either harm or interoperability problems > could > > arise from correctly implemented code changes; indeed, this appears > to be a > > classic case of the use of RFC 2119 keywords to "try to impose a > particular > > method on implementors where the method is not required for > > interoperability". > > I welcome suggestions for how implementations can *meaningfully* > interoperate when they have different interpretations for an attribute. What, if anything, do you imagine that has to do with my comment? ... -- to 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 Oct 24 07:35: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 425A73A67AC for ; Sat, 24 Oct 2009 07:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.088 X-Spam-Level: * X-Spam-Status: No, score=1.088 tagged_above=-999 required=5 tests=[AWL=-0.832, BAYES_40=-0.185, 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 AhAgf523BoaM for ; Sat, 24 Oct 2009 07:35:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 40F123A672E for ; Sat, 24 Oct 2009 07:35:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1hee-0004eE-9B for radiusext-data0@psg.com; Sat, 24 Oct 2009 14:31:40 +0000 Received: from [65.55.116.34] (helo=blu0-omc1-s23.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1heb-0004db-SM for radiusext@ops.ietf.org; Sat, 24 Oct 2009 14:31:37 +0000 Received: from BLU137-W17 ([65.55.116.7]) by blu0-omc1-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Oct 2009 07:31:37 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_034685e4-7f5c-446c-a5d5-822a8ae37984_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: 64-bit Unsigned Integer? Date: Sat, 24 Oct 2009 07:31:37 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 24 Oct 2009 14:31:37.0509 (UTC) FILETIME=[B1ABD550:01CA54B6] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_034685e4-7f5c-446c-a5d5-822a8ae37984_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Glen has brought up the question of whether existing RADIUS server implementations in fact support 64-bit unsigned integers=2C or whether they implement attributes such as Interface-ID as 64-bit octet Strings=2C or specially formatted types.=20 If you are aware of how existing implementations behave=2C please reply to this message.=20 = --_034685e4-7f5c-446c-a5d5-822a8ae37984_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Glen has brought up the question of whether existing RADIUS server
imple= mentations in fact support 64-bit unsigned integers=2C or whether
they i= mplement attributes such as Interface-ID as 64-bit octet Strings=2C
or s= pecially formatted types.

If you are aware of how existing implemen= tations behave=2C please
reply to this message.



= = --_034685e4-7f5c-446c-a5d5-822a8ae37984_-- -- to 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 Oct 24 08:47:33 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 ECF6D28C0F0 for ; Sat, 24 Oct 2009 08:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1GdXnBNSBHZ for ; Sat, 24 Oct 2009 08:47:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31FCA3A6831 for ; Sat, 24 Oct 2009 08:47:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1imo-000CdI-Nk for radiusext-data0@psg.com; Sat, 24 Oct 2009 15:44:10 +0000 Received: from [76.96.27.211] (helo=QMTA11.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1iml-000Cd1-DG for radiusext@ops.ietf.org; Sat, 24 Oct 2009 15:44:08 +0000 Received: from OMTA20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id wfFv1c0011smiN4ABfj65B; Sat, 24 Oct 2009 15:43:08 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA20.emeryville.ca.mail.comcast.net with comcast id wfjf1c0010BTMe48gfjjxj; Sat, 24 Oct 2009 15:43:57 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: References: In-Reply-To: Subject: RE: 64-bit Unsigned Integer? Date: Sat, 24 Oct 2009 22:43:25 +0700 Message-ID: <03ab01ca54c0$c5208fe0$4f61afa0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03AC_01CA54FB.717F67E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpUt1CDAs5YKsv1QZWynI8IOQ6+KQACPFyg 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_03AC_01CA54FB.717F67E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Glen has brought up the question of whether existing RADIUS server implementations in fact support 64-bit unsigned integers, or whether they implement attributes such as Interface-ID as 64-bit octet Strings, or specially formatted types. If you are aware of how existing implementations behave, please reply to this message. I'm wondering when it was decided (& who made the decision) that if an implementation doesn't follow the standard, it's the standard that's broken & not the implementation. ------=_NextPart_000_03AC_01CA54FB.717F67E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Glen has brought up the question of = whether existing RADIUS server
implementations in fact support 64-bit unsigned integers, or whether
they implement attributes such as Interface-ID as 64-bit octet = Strings,
or specially formatted types.

If you are aware of how existing implementations behave, please
reply to this message.

I’m wondering = when it was decided (& who made  the decision) that if an = implementation doesn’t follow the standard, it’s the standard that’s broken & = not the implementation…



 

------=_NextPart_000_03AC_01CA54FB.717F67E0-- -- to 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 Oct 24 12:13:11 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 B48D43A68C3 for ; Sat, 24 Oct 2009 12:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVPQfc-Rwx5g for ; Sat, 24 Oct 2009 12:13:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D3A263A6844 for ; Sat, 24 Oct 2009 12:13:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1m0I-0008GF-Px for radiusext-data0@psg.com; Sat, 24 Oct 2009 19:10:18 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1m0G-0008Fx-Tw for radiusext@ops.ietf.org; Sat, 24 Oct 2009 19:10:17 +0000 Received: from Thor.local (port-83-236-138-242.static.qsc.de [83.236.138.242]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 25D851234604; Sat, 24 Oct 2009 21:10:16 +0200 (CEST) Message-ID: <4AE35117.3050409@deployingradius.com> Date: Sat, 24 Oct 2009 21:10:15 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: 'Bernard Aboba' , radiusext@ops.ietf.org Subject: Re: 64-bit Unsigned Integer? References: <03ab01ca54c0$c5208fe0$4f61afa0$@net> In-Reply-To: <03ab01ca54c0$c5208fe0$4f61afa0$@net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote: > Glen has brought up the question of whether existing RADIUS server > implementations in fact support 64-bit unsigned integers, or whether > they implement attributes such as Interface-ID as 64-bit octet Strings, > or specially formatted types. > > If you are aware of how existing implementations behave, please > reply to this message. > > I’m wondering when it was decided (& who made the decision) that if an > implementation doesn’t follow the standard, it’s the standard that’s > broken & not the implementation… What, if anything, do you imagine that has to do with Bernards comment? Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Oct 24 12:13:14 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 2EFD53A68C3 for ; Sat, 24 Oct 2009 12:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb+vnTyVF9e2 for ; Sat, 24 Oct 2009 12:13:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4F22A3A6844 for ; Sat, 24 Oct 2009 12:13:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1lzD-000882-12 for radiusext-data0@psg.com; Sat, 24 Oct 2009 19:09:11 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1lzA-00087b-Rl for radiusext@ops.ietf.org; Sat, 24 Oct 2009 19:09:09 +0000 Received: from Thor.local (port-83-236-138-242.static.qsc.de [83.236.138.242]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 145011234604; Sat, 24 Oct 2009 21:09:07 +0200 (CEST) Message-ID: <4AE350D2.70606@deployingradius.com> Date: Sat, 24 Oct 2009 21:09:06 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org, 'IESG IESG' Subject: Re: FW: ISSUE: Inappropriate usage of RFC 2119 key words References: <007001ca52fb$4bb36f40$e31a4dc0$@net> <4AE145A9.2090006@deployingradius.com> <039501ca54ab$2f6fb030$8e4f1090$@net> In-Reply-To: <039501ca54ab$2f6fb030$8e4f1090$@net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote: > Alan DeKok [mailto:aland@deployingradius.com] writes: .. >> I welcome suggestions for how implementations can *meaningfully* >> interoperate when they have different interpretations for an attribute. > > What, if anything, do you imagine that has to do with my comment? It's a complex logic chain, explained in my previous message. The suggestion that specifications SHOULD re-use existing data types means that implementations can re-use those data types for new specifications. Since the data types are already inter-operable, adding new attributes of the same data type means a high likelihood of inter-operability. Or... we give up on the idea of data types (as has been insinuated here), and new specs do whatever they want. Since the old implementations don't know about those new data types, they won't implement them, and the systems won't be inter-operable. And to repeat: Yes, they will be able to exchange RADIUS packets. No, they will not be able to agree on the format, meaning, interpretations, and processing requirements for attributes. e.g. An implementation that doesn't support Message-Authenticator cannot be meaningfully said to be interoperable with another one that requires Message-Authenticator for EAP sessions. RADIUS has had attribute interoperability problems for over a decade. Why are there still questions about it? Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Oct 24 12:58:02 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 E8A183A6948 for ; Sat, 24 Oct 2009 12:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=0.404, 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 1NtDG3WM0ANz for ; Sat, 24 Oct 2009 12:57:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BAACA3A6947 for ; Sat, 24 Oct 2009 12:57:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1mhC-000Cz4-DA for radiusext-data0@psg.com; Sat, 24 Oct 2009 19:54:38 +0000 Received: from [65.55.111.146] (helo=blu0-omc4-s7.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1mh9-000Cyr-J8 for radiusext@ops.ietf.org; Sat, 24 Oct 2009 19:54:35 +0000 Received: from BLU137-DS1 ([65.55.111.137]) by blu0-omc4-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Oct 2009 12:54:35 -0700 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Glen Zorn'" CC: References: <03ab01ca54c0$c5208fe0$4f61afa0$@net> In-Reply-To: <03ab01ca54c0$c5208fe0$4f61afa0$@net> Subject: RE: 64-bit Unsigned Integer? Date: Sat, 24 Oct 2009 12:54:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_038E_01CA54A9.22D3EA00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpUt1CDAs5YKsv1QZWynI8IOQ6+KQACPFygAAh3fOA= Content-Language: en-us X-OriginalArrivalTime: 24 Oct 2009 19:54:35.0250 (UTC) FILETIME=[CFB47520:01CA54E3] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_038E_01CA54A9.22D3EA00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Glen Zorn said: "I'm wondering when it was decided (& who made the decision) that if an implementation doesn't follow the standard, it's the standard that's broken & not the implementation." There are several issues that have been brought up: 1. What does RFC 3162 say about the type of the Interface-ID attribute? The current Design Guidelines document asserts it is an 64-bit unsigned integer. As you pointed out, this does not appear to be supported by the text of RFC 3162. 2. Should the Design Guidelines document recommend that implementations support the 64-bit unsigned integer type? a. Because it is currently supported? b. For some other reason? The question you have raised doesn't seem relevant to either of the two above questions. From: Glen Zorn [mailto:glenzorn@comcast.net] Sent: Saturday, October 24, 2009 8:43 AM To: 'Bernard Aboba' Cc: radiusext@ops.ietf.org Subject: RE: 64-bit Unsigned Integer? Glen has brought up the question of whether existing RADIUS server implementations in fact support 64-bit unsigned integers, or whether they implement attributes such as Interface-ID as 64-bit octet Strings, or specially formatted types. If you are aware of how existing implementations behave, please reply to this message. I'm wondering when it was decided (& who made the decision) that if an implementation doesn't follow the standard, it's the standard that's broken & not the implementation. ------=_NextPart_000_038E_01CA54A9.22D3EA00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Glen Zorn said:

 

“I’m wondering when it was decided (& who made  the decision) that = if an implementation doesn’t follow the standard, it’s the = standard that’s broken & not the = implementation…”

There are several = issues that have been brought up:

1.       = What does RFC 3162 say about the type of the Interface-ID attribute? The = current Design Guidelines document asserts it is an 64-bit unsigned integer. =   As you pointed out, this does not appear to be supported by the text of RFC = 3162.

2.       = Should the Design Guidelines document recommend that implementations support = the 64-bit unsigned integer type?

a.       Because it is currently supported?

b.      For some other reason?

The question you have = raised doesn’t seem relevant to either of the two above questions.  =

 

 

From:= Glen Zorn [mailto:glenzorn@comcast.net]
Sent: Saturday, October 24, 2009 8:43 AM
To: 'Bernard Aboba'
Cc: radiusext@ops.ietf.org
Subject: RE: 64-bit Unsigned Integer?

 

Glen has brought up the question of = whether existing RADIUS server
implementations in fact support 64-bit unsigned integers, or whether
they implement attributes such as Interface-ID as 64-bit octet = Strings,
or specially formatted types.

If you are aware of how existing implementations behave, please
reply to this message.

I’m wondering = when it was decided (& who made  the decision) that if an = implementation doesn’t follow the standard, it’s the standard that’s = broken & not the implementation…

 

 

------=_NextPart_000_038E_01CA54A9.22D3EA00-- -- to 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 Oct 24 17:15: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 3E4FA3A6849 for ; Sat, 24 Oct 2009 17:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[AWL=0.386, 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 xZZzV+NAWIo0 for ; Sat, 24 Oct 2009 17:15:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 346DF3A67B8 for ; Sat, 24 Oct 2009 17:15:04 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1qar-0006op-EE for radiusext-data0@psg.com; Sun, 25 Oct 2009 00:04:21 +0000 Received: from [65.55.116.23] (helo=blu0-omc1-s12.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1qaf-0006nT-8X for radiusext@ops.ietf.org; Sun, 25 Oct 2009 00:04:09 +0000 Received: from BLU137-DS2 ([65.55.116.7]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Oct 2009 17:03:42 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: CC: "'IESG IESG'" References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> In-Reply-To: <4AE0542C.4030909@deployingradius.com> Subject: Proposed Resolution of Issue #320: REJECT Date: Sat, 24 Oct 2009 17:03:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQ Content-Language: en-us X-OriginalArrivalTime: 25 Oct 2009 00:03:42.0938 (UTC) FILETIME=[9D38A3A0:01CA5506] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok said: " This issue should be rejected out of hand. The concept of "data types" goes back to the beginning of RADIUS, and was part of the original protocol specification." Given that the Design Guidelines document has already been approved for publication by the IESG, the bar for making changes is extremely high. In this case, that bar does not appear to have been reached. RFC 3162 defines several attributes as being of type "address". Since the addresses in question were IPv6 addresses, and RFC 2865 utilizes the IPv4 address type for similar attributes within IPv4, it is not much of a stretch to conclude that RFC 3162 defines the IPv6 address type. Therefore I would propose that Issue 320 be resolved as REJECT. -- to 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 Oct 24 19:16:36 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 7E2323A691A for ; Sat, 24 Oct 2009 19:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.968 X-Spam-Level: X-Spam-Status: No, score=-0.968 tagged_above=-999 required=5 tests=[AWL=-0.531, 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 viqnYVb3xj8P for ; Sat, 24 Oct 2009 19:16:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 577123A67B2 for ; Sat, 24 Oct 2009 19:16:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1sZq-0007zm-TG for radiusext-data0@psg.com; Sun, 25 Oct 2009 02:11:26 +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 1N1sZo-0007zH-8h for radiusext@ops.ietf.org; Sun, 25 Oct 2009 02:11:24 +0000 Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA11.westchester.pa.mail.comcast.net with comcast id wpyM1c00D0QuhwU5BqBPKS; Sun, 25 Oct 2009 02:11:23 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA02.westchester.pa.mail.comcast.net with comcast id wqB71c0020BTMe43NqBB6J; Sun, 25 Oct 2009 02:11:21 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'Bernard Aboba'" , References: <03ab01ca54c0$c5208fe0$4f61afa0$@net> <4AE35117.3050409@deployingradius.com> In-Reply-To: <4AE35117.3050409@deployingradius.com> Subject: RE: 64-bit Unsigned Integer? Date: Sun, 25 Oct 2009 09:10:51 +0700 Message-ID: <042101ca5518$69a49410$3cedbc30$@net> 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: AcpU3aB0pp37hQWfR8Wmzcu0IbMhgwAOQBzQ Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > > Glen has brought up the question of whether existing RADIUS server > > implementations in fact support 64-bit unsigned integers, or whether > > they implement attributes such as Interface-ID as 64-bit octet > Strings, > > or specially formatted types. > > > > If you are aware of how existing implementations behave, please > > reply to this message. > > > > I=E2=80=99m wondering when it was decided (& who made the decision) = that if > an > > implementation doesn=E2=80=99t follow the standard, it=E2=80=99s the = standard that=E2=80=99s > > broken & not the implementation=E2=80=A6 >=20 > What, if anything, do you imagine that has to do with Bernards > comment? It's quite simple: he didn=E2=80=99t request discussion of my assertions = regarding the technical content of the documents themselves (I expect = that those would be uncontroversial) but about the interpretation of = those documents by developers. It would seem clear that at least one = implementation has it completely wrong, however, so asking "how existing = implementations behave" is tantamount to subjecting the standards to the = implementations thereof. >=20 > Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Oct 24 19:56:10 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 4164C3A67D2 for ; Sat, 24 Oct 2009 19:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[AWL=-0.532, 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 XKCy+fCMX4Jv for ; Sat, 24 Oct 2009 19:56:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 334CC3A67B2 for ; Sat, 24 Oct 2009 19:56:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1tDm-000Bk9-Mp for radiusext-data0@psg.com; Sun, 25 Oct 2009 02:52:42 +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 1N1tDj-000BjT-O3 for radiusext@ops.ietf.org; Sun, 25 Oct 2009 02:52:40 +0000 Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA07.westchester.pa.mail.comcast.net with comcast id wqqP1c0020EZKEL57qsg0t; Sun, 25 Oct 2009 02:52:40 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA01.westchester.pa.mail.comcast.net with comcast id wqsP1c00E0BTMe43MqsTyr; Sun, 25 Oct 2009 02:52:38 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: , "'IESG IESG'" References: <007001ca52fb$4bb36f40$e31a4dc0$@net> <4AE145A9.2090006@deployingradius.com> <039501ca54ab$2f6fb030$8e4f1090$@net> <4AE350D2.70606@deployingradius.com> In-Reply-To: <4AE350D2.70606@deployingradius.com> Subject: RE: FW: ISSUE: Inappropriate usage of RFC 2119 key words Date: Sun, 25 Oct 2009 09:52:08 +0700 Message-ID: <042801ca551e$2d7d32c0$88779840$@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: AcpU3gsmP1ytkr1BTPi+3Ci5mKEPjgAO72YQ Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > Glen Zorn wrote: > > Alan DeKok [mailto:aland@deployingradius.com] writes: > .. > >> I welcome suggestions for how implementations can *meaningfully* > >> interoperate when they have different interpretations for an > attribute. > > > > What, if anything, do you imagine that has to do with my comment? > > It's a complex logic chain, explained in my previous message. > > The suggestion that specifications SHOULD re-use existing data types > means that implementations can re-use those data types for new > specifications. Since the data types are already inter-operable, > adding > new attributes of the same data type means a high likelihood of > inter-operability. > > Or... we give up on the idea of data types (as has been insinuated > here), Nothing is being insinuated: AFAICT, the only justification for most of the prescriptions in the draft is that to so otherwise requires code changes in some implementations. My rather clear question was "What harm does a correctly implemented code change have do to interoperability?" I think that the answer is obvious (none), which may explain your need to avoid answering it at all costs ;-). > and new specs do whatever they want. Since the old > implementations don't know about those new data types, they won't > implement them, and the systems won't be inter-operable. Without changes to code (or in a more reasonable system, to a (auxiliary) dictionary). > > And to repeat: Yes, they will be able to exchange RADIUS packets. > No, > they will not be able to agree on the format, meaning, interpretations, > and processing requirements for attributes. > > e.g. An implementation that doesn't support Message-Authenticator > cannot be meaningfully said to be interoperable with another one that > requires Message-Authenticator for EAP sessions. Excellent example! Section 3.1 of RFC 3579 says "the Message-Authenticator attribute MUST be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets containing an EAP-Message attribute". So you seem to be saying that the fact that an implementation that is compliant with RFC 3579 won't interoperate with one that isn't compliant is, amazingly, a bug rather than a feature! > > RADIUS has had attribute interoperability problems for over a decade. If so, isn't the answer to require more detailed and specific attribute definitions rather than attempting to homogenize everything (often inappropriately, as I pointed out with the "integer64" concoction)? ... -- to 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 Oct 24 20:01: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 82C903A67D4 for ; Sat, 24 Oct 2009 20:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.937 X-Spam-Level: X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2nrcsAIcn7S for ; Sat, 24 Oct 2009 20:01:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BC0283A6870 for ; Sat, 24 Oct 2009 20:01:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1tJr-000CLk-4U for radiusext-data0@psg.com; Sun, 25 Oct 2009 02:58:59 +0000 Received: from [76.96.62.16] (helo=QMTA01.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1tJo-000CK1-Le for radiusext@ops.ietf.org; Sun, 25 Oct 2009 02:58:57 +0000 Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA01.westchester.pa.mail.comcast.net with comcast id wqyc1c0020QuhwU51qywp6; Sun, 25 Oct 2009 02:58:56 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA02.westchester.pa.mail.comcast.net with comcast id wqyi1c00D0BTMe43NqymK4; Sun, 25 Oct 2009 02:58:54 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: References: <03ab01ca54c0$c5208fe0$4f61afa0$@net> In-Reply-To: Subject: RE: 64-bit Unsigned Integer? Date: Sun, 25 Oct 2009 09:58:27 +0700 Message-ID: <042901ca551f$0da959f0$28fc0dd0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_042A_01CA5559.BA0831F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpUt1CDAs5YKsv1QZWynI8IOQ6+KQACPFygAAh3fOAADw1oMA== 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_042A_01CA5559.BA0831F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes: Glen Zorn said: "I'm wondering when it was decided (& who made the decision) that if an implementation doesn't follow the standard, it's the standard that's broken & not the implementation." There are several issues that have been brought up: 1. What does RFC 3162 say about the type of the Interface-ID attribute? The current Design Guidelines document asserts it is an 64-bit unsigned integer. As you pointed out, this does not appear to be supported by the text of RFC 3162. 2. Should the Design Guidelines document recommend that implementations support the 64-bit unsigned integer type? a. Because it is currently supported? b. For some other reason? The question you have raised doesn't seem relevant to either of the two above questions. It's not. However, neither is the question of how "existing implementations behave", unless we are now basing BCPs upon the vagaries of (possibly brain-dead) developers rather than published standards. ------=_NextPart_000_042A_01CA5559.BA0831F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes:
Glen Zorn said:

 

“I’m = wondering when it was decided (& who made  the decision) that if an implementation doesn’t follow the standard, it’s the = standard that’s broken & not the = implementation…”

There are several = issues that have been brought up:

1.       = What does RFC 3162 say about the type of the Interface-ID attribute? The = current Design Guidelines document asserts it is an 64-bit unsigned integer.   As you pointed out, this does not appear to be supported by = the text of RFC 3162.

2.       = Should the Design Guidelines document recommend that implementations support = the 64-bit unsigned integer type?

a.       Because it is currently supported?

b.      For some other reason?

The question you have = raised doesn’t seem relevant to either of the two above questions.  =

It’s = not.  However, neither is the question of how “existing implementations = behave”, unless we are now basing BCPs upon the vagaries of (possibly brain-dead) developers rather than published standards.  =  

------=_NextPart_000_042A_01CA5559.BA0831F0-- -- to 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 Oct 24 20:59: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 B21E33A6887 for ; Sat, 24 Oct 2009 20:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.626 X-Spam-Level: X-Spam-Status: No, score=-0.626 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_42=0.6, 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 DrHpQqiw5mlB for ; Sat, 24 Oct 2009 20:59:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9AE363A685E for ; Sat, 24 Oct 2009 20:59:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1uDm-000HKn-Rc for radiusext-data0@psg.com; Sun, 25 Oct 2009 03:56:46 +0000 Received: from [76.96.62.56] (helo=QMTA06.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1uDk-000HKV-M0 for radiusext@ops.ietf.org; Sun, 25 Oct 2009 03:56:44 +0000 Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA06.westchester.pa.mail.comcast.net with comcast id wrty1c0060cZkys56rvd1N; Sun, 25 Oct 2009 03:55:37 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA10.westchester.pa.mail.comcast.net with comcast id wrwV1c0020BTMe43WrwZaR; Sun, 25 Oct 2009 03:56:42 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , Cc: "'IESG IESG'" References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> In-Reply-To: Subject: RE: Proposed Resolution of Issue #320: REJECT Date: Sun, 25 Oct 2009 10:56:13 +0700 Message-ID: <043401ca5527$21188120$63498360$@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: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQAAcoEIA= Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba [mailto://bernard_aboba@hotmail.com] writes: > Alan DeKok said: > > " This issue should be rejected out of hand. The concept of "data > types" goes back to the beginning of RADIUS, and was part of the > original protocol specification." > > Given that the Design Guidelines document has already been approved for > publication by the IESG, In actual point of fact, this assertion is incorrect: the Issue Tracker shows that the draft in question is in the state "IESG Evaluation", sub-state "AD Followup"; this does not translate to "approved for publication". In fact, the description of the "AD Followup" sub-state suggests that the resolution of issues is no longer up to the WG Chairs: "A generic substate indicating that the shepherding AD has the action item to determine appropriate next steps. In particular, the appropriate steps (and the corresponding next state or substate) depend entirely on the nature of the issues that were raised and can only be decided with active involvement of the shepherding AD." > the bar for making changes is extremely high. I'm sorry, I would have thought that the bar for publication of a document as an RFC would have been considerably higher. > > In this case, that bar does not appear to have been reached. > RFC 3162 defines several attributes as being of type "address". Where? The expected phrase would be "is of type address" or something similar, which doesn't appear in the document. It does, however, _name_ a single attribute as "NAS-IPv6-Address but that is stated simp0ly to be "16 octets". Furthermore, the description of the Login-IPv6-Host attribute (one of the attributes which draft-ietf-radext-design-09 cites as justification for an "IPv6 Address" data type) specifies special meanings for 2 values of the "Address" field. Do all "IPv6 Address" data types have the same semantics? If not, then draft-ietf-radext-design-09 is in error. > Since the addresses in question were IPv6 addresses, and RFC 2865 > utilizes the IPv4 address type for similar attributes within IPv4, Hmm. The practice of making bald assertions of opinion without basis in fact seems to be contagious ;-). As many people have noted over the years, although RFC2865 defines the "address" data type, no attributes are defined to be of type "address" in that document. > it is not much of a stretch to conclude that RFC 3162 defines the > IPv6 address type. One can conclude virtually anything if one begins with a false premise... > > Therefore I would propose that Issue 320 be resolved as REJECT. > > > > > > > > > -- > to 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 Sat Oct 24 21:44: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 C47263A6906 for ; Sat, 24 Oct 2009 21:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.887 X-Spam-Level: X-Spam-Status: No, score=-0.887 tagged_above=-999 required=5 tests=[AWL=-0.450, 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 y1fZYzTo0KJw for ; Sat, 24 Oct 2009 21:44:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB0C63A6405 for ; Sat, 24 Oct 2009 21:44:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1uuU-000Kut-Uk for radiusext-data0@psg.com; Sun, 25 Oct 2009 04:40:54 +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 1N1uuR-000KuY-T9 for radiusext@ops.ietf.org; Sun, 25 Oct 2009 04:40:52 +0000 Received: from OMTA21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA03.westchester.pa.mail.comcast.net with comcast id wsZq1c0031ZXKqc53sgsHY; Sun, 25 Oct 2009 04:40:52 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA21.westchester.pa.mail.comcast.net with comcast id wsnG1c0040BTMe43hsnLhP; Sun, 25 Oct 2009 04:47:28 +0000 From: "Glen Zorn" To: "'Dave Nelson'" , References: <18B576169E2241A5AF24D33D4C5B8870@NEWTON603> In-Reply-To: <18B576169E2241A5AF24D33D4C5B8870@NEWTON603> Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun, 25 Oct 2009 11:40:22 +0700 Message-ID: <043e01ca552d$4ae150d0$e0a3f270$@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: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxAAAQa5/AAAMdz4AAk/y3gACIVHaA= Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Dave Nelson [mailto://d.b.nelson@comcast.net] writes: ... > > - Are you now convinced of "interest"? (and if not, or > > partially, then on what grounds given the rather abundant > > amount of contributors, reviewers, discussion?) > > The level of interest required to accept a work item in the RADEXT WG > is, as > you say, an "abundant" number of reviewers, not including the authors. > There is no hard rule, but half a dozen would be a good threshold. Not counting the authors, 19 individuals have posted on _any_ topic on this list this year; discounting IESG members and WG Chairs (official and de facto) brings the number down to 13, most of whom sent only one or two messages (mostly regarding their own drafts). So it sounds like you are saying that about half the active WG members have to sign up to review the draft, is that correct? It's interesting how high the bar is set in this case given that apparently _no one_ has ever actually reviewed draft-ietf-radext-design (currently being emphatically pushed for publication despite the number of egregious technical errors discovered upon a reasonably close reading thereof). ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 01:00: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 83F093A689A for ; Sun, 25 Oct 2009 01:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[AWL=0.374, 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 0AjPn9JOmSxK for ; Sun, 25 Oct 2009 01:00:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 574B33A6897 for ; Sun, 25 Oct 2009 01:00:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1xyM-000B5T-77 for radiusext-data0@psg.com; Sun, 25 Oct 2009 07:57:06 +0000 Received: from [65.55.111.97] (helo=blu0-omc2-s22.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1xyJ-000B5F-SP for radiusext@ops.ietf.org; Sun, 25 Oct 2009 07:57:03 +0000 Received: from BLU137-DS2 ([65.55.111.72]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 00:57:03 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Alan DeKok'" , References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> In-Reply-To: <4AE0542C.4030909@deployingradius.com> Subject: RE: Data Types defined in RFC 2865 Date: Sun, 25 Oct 2009 00:57:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgCL9BjQ Content-Language: en-us X-OriginalArrivalTime: 25 Oct 2009 07:57:03.0869 (UTC) FILETIME=[BD7ECAD0:01CA5548] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok said: " It goes on to name the five data types, and give definitions for each one. These data types are then used in the attribute definitions in RFC 2865, and in other RADIUS RFCs." Section 5 is unambiguous on this point: " The format of the value field is one of five data types. Note that type "text" is a subset of type "string". text 1-253 octets containing UTF-8 encoded 10646 [7] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead. string 1-253 octets containing binary data (values 0 through 255 decimal, inclusive). Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. address 32 bit value, most significant octet first. integer 32 bit unsigned value, most significant octet first. time 32 bit unsigned value, most significant octet first -- seconds since 00:00:00 UTC, January 1, 1970. The standard Attributes do not use this data type but it is presented here for possible use in future attributes. " Moreover, within the value field of each attribute, RFC 2865 includes the data type: a. "String" for type string. b. "Address" for type address c. "Value" for type integer d. "Text" for type text No attributes of type time are defined in RFC 2865 or 2866. Looking at other RADIUS RFCs, the inclusion of the data type within the value field is less consistent. For example, RFC 2867, includes a type of "Lost" in Section 4.2 for Acct-Tunnel-Packets-Lost (4 octets). It seems likely that this attribute was intended as type integer, rather than a "lost" data type. In RFC 2869, the term "Value" is used in the value field for attributes that are not integers (e.g. ARAP-Challenge-Response in Section 5.15). RFC 3162 seems closer to the conventions of RFC 2865 & 2866, although the "Address" type used is 16 rather than 4 octets in size (IPv6 vs. IPv4). -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 01:29:00 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 0C56C3A6897 for ; Sun, 25 Oct 2009 01:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_05=-1.11, 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 nEAkfTF660Wi for ; Sun, 25 Oct 2009 01:28:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D0F603A68C1 for ; Sun, 25 Oct 2009 01:28:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1yQh-000Dac-C3 for radiusext-data0@psg.com; Sun, 25 Oct 2009 08:26:23 +0000 Received: from [65.55.116.12] (helo=blu0-omc1-s1.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1yQf-000DaK-CO for radiusext@ops.ietf.org; Sun, 25 Oct 2009 08:26:21 +0000 Received: from BLU137-DS2 ([65.55.116.7]) by blu0-omc1-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 01:26:20 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Subject: Proposed Resolution of Issue 319: Accept in principle Date: Sun, 25 Oct 2009 01:26:23 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CA5512.2A62A2C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpVCQbN9frlusrGQ3C4EJ7P9brrDQAQ8V7w Content-Language: en-us X-OriginalArrivalTime: 25 Oct 2009 08:26:20.0848 (UTC) FILETIME=[D4BC8300:01CA554C] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_000B_01CA5512.2A62A2C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This issue relates to the question of whether existing RADIUS RFCs have defined the unsigned integer64 data type. The contention is that attributes such as ARAP-Challenge-Response (RFC 2869) were in fact defined as 8 octet String attributes, not unsigned integer64. Similarly, the contention is that the Interface-ID attribute was also not defined as an unsigned integer64. While the bar for making changes to the Design Guidelines document is very high, this issue is one which could potentially result in an Errata being filed and approved. A proposed resolution to this issue is available below: http://ops.ietf.org/lists/radiusext/2009/msg00546.html The resolution of this question depends in part on an understanding of the type of the Interface-ID attribute. Potential candidates (integer64 seems to have been disqualified) include 8 octet String or Interface ID (variant of 8 octet String). Another sub-question that needs to be resolved is whether the implementation advice given in the document (for RADIUS implementations to support the unsigned integer 64 data type) is justified if it is determined that this data type is not in fact used by any existing RADIUS attribute. If you have comments on the proposed resolution nor any of the sub-questions, please post your opinions to the list. ------=_NextPart_000_000B_01CA5512.2A62A2C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This issue relates to the question of whether = existing RADIUS RFCs have defined the unsigned integer64

data type.   The contention is that = attributes such as ARAP-Challenge-Response (RFC 2869) were in fact

defined as 8 octet String attributes, not unsigned integer64.   Similarly, the contention is that = the

Interface-ID attribute was also not defined as an = unsigned integer64.  

 

While the bar for making changes to the Design = Guidelines document is very high, this issue is one

which could potentially result in an Errata being = filed and approved.

 

A proposed resolution to this issue is available = below:

http://op= s.ietf.org/lists/radiusext/2009/msg00546.html

 

The resolution of this question depends in part on = an understanding of the type of

the Interface-ID attribute.  Potential = candidates (integer64 seems to have been disqualified) include

8 octet String or Interface ID (variant of 8 octet = String).

 

Another sub-question that needs to be resolved is = whether the implementation advice given in the

document (for RADIUS implementations to support the = unsigned integer 64 data type) is justified

if it is determined that this data type is not in = fact used by any existing RADIUS attribute.

 

If you have comments on the proposed resolution nor = any of the sub-questions, please post your

opinions to the list.

 

 

 

 

 

 

 

 

------=_NextPart_000_000B_01CA5512.2A62A2C0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 01:29:10 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 BBD3F3A68C1 for ; Sun, 25 Oct 2009 01:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[AWL=0.374, 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 Ers684r0JCZf for ; Sun, 25 Oct 2009 01:29:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E505C3A6897 for ; Sun, 25 Oct 2009 01:29:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1yQy-000DcL-Py for radiusext-data0@psg.com; Sun, 25 Oct 2009 08:26:40 +0000 Received: from [65.55.116.36] (helo=blu0-omc1-s25.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N1yQx-000Dbz-20 for radiusext@ops.ietf.org; Sun, 25 Oct 2009 08:26:39 +0000 Received: from BLU137-DS2 ([65.55.116.8]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 01:26:38 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Subject: Proposed Resolution of Issue #318: REJECT Date: Sun, 25 Oct 2009 01:26:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQAABKTkAAEYxFQA== Content-Language: en-us X-OriginalArrivalTime: 25 Oct 2009 08:26:38.0502 (UTC) FILETIME=[DF424C60:01CA554C] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok said: "This issue should be rejected. RADIUS specifications define format, meaning, interpretations, and processing requirements for attributes. Two implementations that disagree about an attribute can inter-operate at the RADIUS level by exchanging RADIUS packets. They cannot be said have interoperable implementations of the attribute." Given that the Design Guidelines document has already been approved for publication by the IESG, the bar for making changes is extremely high. In this case, that bar does not appear to have been reached. The assertion is that interoperability issues cannot be created by a mismatch of RADIUS data types and therefore that normative language cannot be used. While it is possible for any RADIUS attribute to be expressed as a String of octets, configuration of attributes in Hex is both inconvenient and error prone. Moreover, if an attribute requires computation of any kind, then a mismatch in the data type will result the data being misinterpreted, with unpredictable results. Therefore the text in question would appear to meet the RFC 2119 bar. The proposed resolution of Issue 318 is REJECT. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 03:32:37 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 E35C03A67D1 for ; Sun, 25 Oct 2009 03:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[AWL=-0.927, 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 U5t3C6y5wSbT for ; Sun, 25 Oct 2009 03:32:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BF6203A68C1 for ; Sun, 25 Oct 2009 03:32:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N20KJ-000PKK-Qv for radiusext-data0@psg.com; Sun, 25 Oct 2009 10:27:55 +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 1N20KH-000PIr-9s for radiusext@ops.ietf.org; Sun, 25 Oct 2009 10:27:53 +0000 X-IronPort-AV: E=Sophos;i="4.44,620,1249272000"; d="scan'208";a="161287968" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Oct 2009 06:27:49 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 25 Oct 2009 06:27:49 -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: FW: [Technical Errata Reported] RFC3162 (1923) Date: Sun, 25 Oct 2009 11:27:28 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Technical Errata Reported] RFC3162 (1923) Thread-Index: AcpTGoLKB9OFGKn+Sk+vijhLAU4nRwCQoQHA From: "Romascanu, Dan (Dan)" To: "radext mailing list" Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: RADEXT WG, Please advise on the Technical Errata below.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of RFC Errata System Sent: Thursday, October 22, 2009 3:19 PM To: bernarda@microsoft.com; gwz@cisco.com; iesg@iesg.org Cc: aland@freeradius.org; rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC3162 (1923) The following errata report has been submitted for RFC3162, "RADIUS and IPv6". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D3162&eid=3D1923 -------------------------------------- Type: Technical Reported by: Alan DeKok Section: 2.1 Original Text ------------- Address The Address field is 16 octets. Corrected Text -------------- String The field is 16 octets Notes ----- As Glen notes in: http://ops.ietf.org/lists/radiusext/2009/msg00540.html Using "ipv6 address" for a data type in RADIUS is wrong. RFC 3162 (among others Glen wrote) contradict his current position. Those documents use data types for the "value" field of RADIUS attributes that have not been defined in RFC 2865. As such, they should either: a) make it clear that they define a new data type, and be marked as "Updates: 2865" or b) use the data types in RFC 2865. Or even better, maintain an internally consistent set of beliefs, and leave RFC 3162 alone. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC3162 (draft-aboba-radius-ipv6-10) -------------------------------------- Title : RADIUS and IPv6 Publication Date : August 2001 Author(s) : B. Aboba, G. Zorn, D. Mitton Category : PROPOSED STANDARD Source : Legacy Area : Legacy Stream : IETF Verifying Party : IESG -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 03:34:13 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 C095B3A67D1 for ; Sun, 25 Oct 2009 03:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=-0.898, 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 GJizV1lztYV1 for ; Sun, 25 Oct 2009 03:34:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC7BF3A68C1 for ; Sun, 25 Oct 2009 03:34:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N20OW-000Pkv-J3 for radiusext-data0@psg.com; Sun, 25 Oct 2009 10:32:16 +0000 Received: from [198.152.13.100] (helo=co300216-co-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N20OU-000Pkg-Lf for radiusext@ops.ietf.org; Sun, 25 Oct 2009 10:32:14 +0000 X-IronPort-AV: E=Sophos;i="4.44,620,1249272000"; d="scan'208";a="188060524" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 Oct 2009 06:32:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Oct 2009 06:32:12 -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: Pending errata for RADEXT Date: Sun, 25 Oct 2009 11:31:56 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Pending errata for RADEXT Thread-Index: AcpVXmAki+iuaexKQ1amgu88RsIZGA== From: "Romascanu, Dan (Dan)" To: "radext mailing list" Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: RADEXT WG,=20 There are a number of pending errata related to RADIUS that I have asked recommendation in the past for the WG. Please process and advice how for resolutions on these errata. Some of them are rather simple, some other may require some more thought.=20 The IDs (in the order of their occurrences in the tracker) are: 1607, 420, 1469, 753, 1848, 1849, 1850, 867, 1407.=20 Thanks and Regards, 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 Oct 25 07:39:42 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 45B9B3A6916 for ; Sun, 25 Oct 2009 07:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=-0.458, 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 od7xTk1EXg+m for ; Sun, 25 Oct 2009 07:39:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BEC843A6858 for ; Sun, 25 Oct 2009 07:39:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N24Bn-000PKx-F0 for radiusext-data0@psg.com; Sun, 25 Oct 2009 14:35:23 +0000 Received: from [76.96.27.212] (helo=QMTA14.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N24Bk-000PKR-UX for radiusext@ops.ietf.org; Sun, 25 Oct 2009 14:35:21 +0000 Received: from OMTA17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id x2XP1c0011afHeLAE2bMdD; Sun, 25 Oct 2009 14:35:21 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA17.emeryville.ca.mail.comcast.net with comcast id x2b11c0010BTMe48d2b7qP; Sun, 25 Oct 2009 14:35:19 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: , "'IESG IESG'" References: In-Reply-To: Subject: RE: Proposed Resolution of Issue #318: REJECT Date: Sun, 25 Oct 2009 21:34:42 +0700 Message-ID: <048601ca5580$560df2d0$0229d870$@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: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQAABKTkAAEYxFQAAMs9dA Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba [mailto://bernard_aboba@hotmail.com] writes: > Alan DeKok said: > > "This issue should be rejected. > > RADIUS specifications define format, meaning, interpretations, and > processing requirements for attributes. Two implementations that > disagree about an attribute can inter-operate at the RADIUS level by > exchanging RADIUS packets. They cannot be said have interoperable > implementations of the attribute." > > Given that the Design Guidelines document has already been approved for > publication by the IESG, I hate to repeat myself, but this statement is STILL FALSE. > the bar for making changes is extremely high. > > In this case, that bar does not appear to have been reached. > > The assertion is that interoperability issues cannot be created by a > mismatch of RADIUS data types and therefore that normative language > cannot be used. That may be Alan's assertion, but it's not mine. My assertion is that correctly implemented code changes (maybe that's asking too much?) do not effect interoperability, nor does requiring such cause harm. ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 07:54: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 83CE328C0F4 for ; Sun, 25 Oct 2009 07:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=-0.438, 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 Qcw9NxWHmMNZ for ; Sun, 25 Oct 2009 07:54:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B9F293A6933 for ; Sun, 25 Oct 2009 07:54:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N24RU-0001BM-1d for radiusext-data0@psg.com; Sun, 25 Oct 2009 14:51:36 +0000 Received: from [76.96.30.16] (helo=QMTA01.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N24RR-0001Ar-A2 for radiusext@ops.ietf.org; Sun, 25 Oct 2009 14:51:33 +0000 Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id x2Y81c00417UAYkA12rNCW; Sun, 25 Oct 2009 14:51:22 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id x2rH1c0030BTMe48Z2rNn0; Sun, 25 Oct 2009 14:51:31 +0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" Cc: "'radext mailing list'" References: In-Reply-To: Subject: RE: [Technical Errata Reported] RFC3162 (1923) Date: Sun, 25 Oct 2009 21:50:59 +0700 Message-ID: <048701ca5582$99a97710$ccfc6530$@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: AcpTGoLKB9OFGKn+Sk+vijhLAU4nRwCQoQHAAAk1baA= Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > RADEXT WG, > > Please advise on the Technical Errata below. The idea that the formal data type (if any) of a field in a RADIUS attribute can be changed by changing the name of the field is so bizarre as to be almost unbelievable. Even if it wasn't so incredibly BASIC, the idea is not supported by any explicit text in any RADIUS-related RFC. ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 08:02: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 1378B3A697F for ; Sun, 25 Oct 2009 08:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[AWL=0.063, 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 Qp23ajXOSzlZ for ; Sun, 25 Oct 2009 08:02:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 29F463A68DD for ; Sun, 25 Oct 2009 08:02:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N24ZR-000274-9t for radiusext-data0@psg.com; Sun, 25 Oct 2009 14:59:49 +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 1N24ZP-00026o-08 for radiusext@ops.ietf.org; Sun, 25 Oct 2009 14:59:47 +0000 Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA11.westchester.pa.mail.comcast.net with comcast id x2sB1c0020bG4ec5B2zn9k; Sun, 25 Oct 2009 14:59:47 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA03.westchester.pa.mail.comcast.net with comcast id x2zm1c0064H2mdz3P2zmPF; Sun, 25 Oct 2009 14:59:47 +0000 From: "Dave Nelson" To: Cc: "'IESG IESG'" References: <048601ca5580$560df2d0$0229d870$@net> Subject: RE: Proposed Resolution of Issue #318: REJECT Date: Sun, 25 Oct 2009 10:59:52 -0400 Message-ID: <8F84EE704D0F419AB406F5E658B4E37B@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <048601ca5580$560df2d0$0229d870$@net> Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQAABKTkAAEYxFQAAMs9dAAACs5yA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn writes... > My assertion is that correctly implemented code changes (maybe > that's asking too much?) do not effect interoperability, nor > does requiring such cause harm. Your assertion is that correctly implemented code changes at both the client and server ends of a client-server protocol implementation would not affect interoperability. True, as far as it goes. The point that is being addressed in the RADIUS Design Guidelines is that *requiring* code changes on the sever side, when a data dictionary change alone would suffice, is harmful to interoperability, or at least forces maintainers of server implementations to make code changes they would not otherwise have to make. The guidelines discourage attribute design choices that would force a code change on RADIUS servers when no such change would be required with a more "traditional" choice of attribute design. I suspect you don't attach much value (or even credence) to this data-driven model on the server side, but many in the RADIUS community do. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 08:05: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 798E13A6842 for ; Sun, 25 Oct 2009 08:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.883 X-Spam-Level: X-Spam-Status: No, score=-0.883 tagged_above=-999 required=5 tests=[AWL=-0.446, 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 hYyVGriZyiul for ; Sun, 25 Oct 2009 08:05:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 84EDD3A681B for ; Sun, 25 Oct 2009 08:05:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N24da-0002cK-8i for radiusext-data0@psg.com; Sun, 25 Oct 2009 15:04:06 +0000 Received: from [76.96.27.227] (helo=QMTA12.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N24dY-0002bx-1L for radiusext@ops.ietf.org; Sun, 25 Oct 2009 15:04:04 +0000 Received: from OMTA21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by QMTA12.emeryville.ca.mail.comcast.net with comcast id x2l01c0021u4NiLAC3448S; Sun, 25 Oct 2009 15:04:04 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA21.emeryville.ca.mail.comcast.net with comcast id x33h1c0060BTMe48h33n5G; Sun, 25 Oct 2009 15:04:02 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: "'Alan DeKok'" , , "'IESG IESG'" References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> In-Reply-To: Subject: RE: Data Types defined in RFC 2865 Date: Sun, 25 Oct 2009 22:03:23 +0700 Message-ID: <048b01ca5584$591087a0$0b3196e0$@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: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgCL9BjQAAHOdUA= Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba [mailto://Bernard_aboba@hotmail.com] writes: > " It goes on to name the five data types, and give definitions for > each > one. These data types are then used in the attribute definitions in > RFC > 2865, and in other RADIUS RFCs." > > Section 5 is unambiguous on this point: > > " The format of the value field is one of five data types. Note > that type "text" is a subset of type "string". > > text 1-253 octets containing UTF-8 encoded 10646 [7] > characters. Text of length zero (0) MUST NOT be sent; > omit the entire attribute instead. > > string 1-253 octets containing binary data (values 0 through > 255 decimal, inclusive). Strings of length zero (0) > MUST NOT be sent; omit the entire attribute instead. > > address 32 bit value, most significant octet first. > > integer 32 bit unsigned value, most significant octet first. > > time 32 bit unsigned value, most significant octet first -- > seconds since 00:00:00 UTC, January 1, 1970. The > standard Attributes do not use this data type but it is > presented here for possible use in future attributes. > " > > Moreover, within the value field of each attribute, RFC 2865 includes > the > data type: > > a. "String" for type string. > b. "Address" for type address Is a netmask considered an address? > c. "Value" for type integer Wow, I am really amazed! I don't know how many times I've read that RFC & never noticed the apparently 1-1 correlation between naming the "Value" field of an attribute "Value" and the contents of that field being an integer (though with special "flag" values sometimes). I'm really very impressed, but does that really qualify as "unambiguous"? > d. "Text" for type text > > No attributes of type time are defined in RFC 2865 or 2866. > > Looking at other RADIUS RFCs, the inclusion of the data type within the > value field is less consistent. > > For example, RFC 2867, includes a type of "Lost" in Section 4.2 for > Acct-Tunnel-Packets-Lost (4 octets). It seems likely that this > attribute > was intended as type integer, rather than a "lost" data type. Actually, it seems much more likely to me that the field was named descriptively (I know it's insane, but then Alan DeKok wasn't around to show us the True Way ;-). Additionally, in 2866, the "Value" field of the Acct-Multi-Session-Id attribute is named "String", but its contents are specified as UTF-8 encoded 10646 characters (the definition of the "text" type). > > In RFC 2869, the term "Value" is used in the value field for attributes > that > are not integers (e.g. ARAP-Challenge-Response in Section 5.15). > > RFC 3162 seems closer to the conventions of RFC 2865 & 2866, although > the > "Address" type used is 16 rather than 4 octets in size (IPv6 vs. IPv4). So am I to understand that, despite the multitude of counterexamples and the lack of any explicit text even suggesting such in any RADIUS-related RFC, you are claiming that the name of the V field in the TLV construct denotes a formal data type (a thing apparently known only to some secret society holding the same "internally consistent belief system" (thought police, anyone? ;-)? ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 08:29:06 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 2BF1D28C0F4 for ; Sun, 25 Oct 2009 08:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.863 X-Spam-Level: X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[AWL=-0.426, 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 a2GHJY84YTdC for ; Sun, 25 Oct 2009 08:29:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 256A83A692A for ; Sun, 25 Oct 2009 08:29:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N24yq-0004qo-R8 for radiusext-data0@psg.com; Sun, 25 Oct 2009 15:26:04 +0000 Received: from [76.96.62.80] (helo=QMTA08.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N24yn-0004qS-71 for radiusext@ops.ietf.org; Sun, 25 Oct 2009 15:26:02 +0000 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA08.westchester.pa.mail.comcast.net with comcast id x3AP1c0061GhbT8583R4pt; Sun, 25 Oct 2009 15:25:04 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA07.westchester.pa.mail.comcast.net with comcast id x3Rh1c0020BTMe43T3Rm8D; Sun, 25 Oct 2009 15:25:59 +0000 From: "Glen Zorn" To: "'Dave Nelson'" , Cc: "'IESG IESG'" References: <048601ca5580$560df2d0$0229d870$@net> <8F84EE704D0F419AB406F5E658B4E37B@NEWTON603> In-Reply-To: <8F84EE704D0F419AB406F5E658B4E37B@NEWTON603> Subject: RE: Proposed Resolution of Issue #318: REJECT Date: Sun, 25 Oct 2009 22:25:23 +0700 Message-ID: <048f01ca5587$69ecc130$3dc64390$@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: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQAABKTkAAEYxFQAAMs9dAAACs5yAAAKY6kA== Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Dave Nelson [mailto://d.b.nelson@comcast.net] writes: > Glen Zorn writes... > > > My assertion is that correctly implemented code changes (maybe > > that's asking too much?) do not effect interoperability, nor > > does requiring such cause harm. > > Your assertion is that correctly implemented code changes at both the > client > and server ends of a client-server protocol implementation would not > affect > interoperability. True, as far as it goes. The point that is being > addressed in the RADIUS Design Guidelines is that *requiring* code > changes > on the sever side, when a data dictionary change alone would suffice, > is > harmful to interoperability, or at least forces maintainers of server > implementations to make code changes they would not otherwise have to > make. This claim is valid only for some (primitive) implementations. I am currently running a RADIUS server (w/a nice GUI, no less) that will handle any length of integer, signed or unsigned, (not to mention arbitrary "complex" attributes) with only a dictionary change or two. It's hardly rocket science to build a flexible, data-driven parser and I'm actually personally offended by the attempt to standardize this kind of weak design. > The guidelines discourage attribute design choices that would force a > code > change on RADIUS servers when no such change would be required with a > more > "traditional" choice of attribute design. > > I suspect you don't attach much value (or even credence) to this data- > driven > model on the server side, but many in the RADIUS community do. In fact I hold the idea in great esteem; what I disvalue is the idea that data-driven models have to be implementable by below-average high-school kids. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 08:38: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 6B11D28C0FE for ; Sun, 25 Oct 2009 08:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.676 X-Spam-Level: X-Spam-Status: No, score=-0.676 tagged_above=-999 required=5 tests=[AWL=-0.239, 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 JBSDO5CFykDL for ; Sun, 25 Oct 2009 08:38:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9045E28C0F8 for ; Sun, 25 Oct 2009 08:38:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N258I-0005rW-Lj for radiusext-data0@psg.com; Sun, 25 Oct 2009 15:35:50 +0000 Received: from [76.96.59.212] (helo=QMTA14.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N258G-0005rI-97 for radiusext@ops.ietf.org; Sun, 25 Oct 2009 15:35:48 +0000 Received: from OMTA21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA14.westchester.pa.mail.comcast.net with comcast id x1Uz1c0021ZXKqc5E3boEu; Sun, 25 Oct 2009 15:35:48 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA21.westchester.pa.mail.comcast.net with comcast id x3iT1c0094H2mdz3h3iTu8; Sun, 25 Oct 2009 15:42:27 +0000 From: "Dave Nelson" To: Cc: "'IESG IESG'" References: <048601ca5580$560df2d0$0229d870$@net> <8F84EE704D0F419AB406F5E658B4E37B@NEWTON603> <048f01ca5587$69ecc130$3dc64390$@net> Subject: RE: Proposed Resolution of Issue #318: REJECT Date: Sun, 25 Oct 2009 11:35:54 -0400 Message-ID: <77AEC2179BCC41458BF54596AFE12794@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <048f01ca5587$69ecc130$3dc64390$@net> Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQAABKTkAAEYxFQAAMs9dAAACs5yAAAKY6kAAA1kuA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn writes... > > I suspect you don't attach much value (or even credence) > > to this data-driven model on the server side, but many in > > the RADIUS community do. > > In fact I hold the idea in great esteem; what I disvalue is > the idea that data-driven models have to be implementable by > below-average high-school kids. There is no need for you to be so dismissive of, and insulting to, your colleagues, who form the rough consensus on this issue. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 08:52: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 8D24B3A6810 for ; Sun, 25 Oct 2009 08:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[AWL=-0.339, 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 p55OgqRbHflQ for ; Sun, 25 Oct 2009 08:52:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1AD9D3A68A3 for ; Sun, 25 Oct 2009 08:52:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N25Lx-0007MB-BM for radiusext-data0@psg.com; Sun, 25 Oct 2009 15:49:57 +0000 Received: from [76.96.62.17] (helo=QMTA10.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N25Lt-0007Lh-H4 for radiusext@ops.ietf.org; Sun, 25 Oct 2009 15:49:54 +0000 Received: from OMTA16.westchester.pa.mail.comcast.net ([76.96.62.88]) by QMTA10.westchester.pa.mail.comcast.net with comcast id x1FB1c0041uE5Es5A3ptoe; Sun, 25 Oct 2009 15:49:53 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA16.westchester.pa.mail.comcast.net with comcast id x3y11c0044H2mdz3c3y1yB; Sun, 25 Oct 2009 15:58:01 +0000 From: "Dave Nelson" To: Cc: "'IESG IESG'" References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> <048b01ca5584$591087a0$0b3196e0$@net> Subject: RE: Data Types defined in RFC 2865 Date: Sun, 25 Oct 2009 11:49:59 -0400 Message-ID: <2C5E8C11AE78494CB14CA6C1D32D3B13@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <048b01ca5584$591087a0$0b3196e0$@net> Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgCL9BjQAAHOdUAADquKsA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn writes... > So am I to understand that, despite the multitude of counterexamples > and the lack of any explicit text even suggesting such in any RADIUS- > related RFC, you are claiming that the name of the V field in the TLV > construct denotes a formal data type (a thing apparently known only to > some secret society holding the same "internally consistent belief > system" (thought police, anyone? ;-)? Well, your previous posting claiming to be able to implement an advanced server implementation that intuits the syntax of a data model from the data stream itself notwithstanding, RADIUS *has* a formal, written data model. Many implementations rely on it. It's a very simple data model. I think this extended discussion of what constitutes a "formal" definition of a new data type in the data model constitutes "protocol lawyering", a debate about form without any substance. In seeking to debunk some of these data model additions, you are apparently attempting to build a case for the precedence of using the RADIUS String data type to contain non-self-describing data structures. This has been a point of debate in the RADEXT WG for several years. The WG consensus is captured in the Design Guidelines draft. The String data type should be used for actual strings, or for opaque blobs of binary data, for use in some other protocol component, e.g. EAP. There are specific exemptions to this recommendation that are spelled out in the draft. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 09:59: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 344043A688D for ; Sun, 25 Oct 2009 09:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[AWL=-0.434, 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 M6BecBILmei8 for ; Sun, 25 Oct 2009 09:59:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 264D73A688C for ; Sun, 25 Oct 2009 09:59:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N26OB-000EdN-06 for radiusext-data0@psg.com; Sun, 25 Oct 2009 16:56:19 +0000 Received: from [76.96.30.17] (helo=QMTA10.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N26O6-000Ecz-TG for radiusext@ops.ietf.org; Sun, 25 Oct 2009 16:56:15 +0000 Received: from OMTA23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id x4vu1c0011wfjNsAA4wFaX; Sun, 25 Oct 2009 16:56:15 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA23.emeryville.ca.mail.comcast.net with comcast id x53m1c0090BTMe48j53ros; Sun, 25 Oct 2009 17:04:02 +0000 From: "Glen Zorn" To: "'Dave Nelson'" , Cc: "'IESG IESG'" References: <048601ca5580$560df2d0$0229d870$@net> <8F84EE704D0F419AB406F5E658B4E37B@NEWTON603> <048f01ca5587$69ecc130$3dc64390$@net> <77AEC2179BCC41458BF54596AFE12794@NEWTON603> In-Reply-To: <77AEC2179BCC41458BF54596AFE12794@NEWTON603> Subject: RE: Proposed Resolution of Issue #318: REJECT Date: Sun, 25 Oct 2009 23:55:39 +0700 Message-ID: <04ca01ca5594$04d3a360$0e7aea20$@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: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQAABKTkAAEYxFQAAMs9dAAACs5yAAAKY6kAAA1kuAAAKpBWA= Content-Language: en-us x-cr-hashedpuzzle: AUBf AiPQ BtLT EWuA Fjsz HKz8 HwNo MEsL OGve QgCN RDTu R4KB R5jJ Sr43 bKoh bUoa;3;ZAAuAGIALgBuAGUAbABzAG8AbgBAAGMAbwBtAGMAYQBzAHQALgBuAGUAdAA7AGkAZQBzAGcAQABpAGUAdABmAC4AbwByAGcAOwByAGEAZABpAHUAcwBlAHgAdABAAG8AcABzAC4AaQBlAHQAZgAuAG8AcgBnAA==;Sosha1_v1;7;{6C4864E4-736B-4067-B2C0-16E88804B07C};ZwBsAGUAbgB6AG8AcgBuAEAAYwBvAG0AYwBhAHMAdAAuAG4AZQB0AA==;Sun, 25 Oct 2009 16:55:32 GMT;UgBFADoAIABQAHIAbwBwAG8AcwBlAGQAIABSAGUAcwBvAGwAdQB0AGkAbwBuACAAbwBmACAASQBzAHMAdQBlACAAIwAzADEAOAA6ACAAUgBFAEoARQBDAFQA x-cr-puzzleid: {6C4864E4-736B-4067-B2C0-16E88804B07C} Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > Glen Zorn writes... > > > > I suspect you don't attach much value (or even credence) > > > to this data-driven model on the server side, but many in > > > the RADIUS community do. > > > > In fact I hold the idea in great esteem; what I disvalue is > > the idea that data-driven models have to be implementable by > > below-average high-school kids. > > There is no need for you to be so dismissive of, and insulting to, your > colleagues, who form the rough consensus on this issue. If you would be kind enough to read my comment, you will see that I said nothing whatsoever about my colleagues, let alone anything insulting or dismissive. The fact is, however, (as Hannes has also pointed out) that the processing model assumed in the Design Guidelines draft is simplistic and limited, if not outright primitive. If you wish to believe that that fact makes the promoters of the model simplistic, limited and primitive as well, that is your choice but I said nothing of the sort. > > > -- > to 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 Sun Oct 25 10:34:18 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 13B7B28C110 for ; Sun, 25 Oct 2009 10:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[AWL=-0.440, 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 EK1rd2b6iiN3 for ; Sun, 25 Oct 2009 10:34:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E179228C10F for ; Sun, 25 Oct 2009 10:34:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N26wZ-000IXP-R7 for radiusext-data0@psg.com; Sun, 25 Oct 2009 17:31:51 +0000 Received: from [76.96.27.227] (helo=QMTA12.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N26wU-000IX5-9r for radiusext@ops.ietf.org; Sun, 25 Oct 2009 17:31:47 +0000 Received: from OMTA17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by QMTA12.emeryville.ca.mail.comcast.net with comcast id x5Mh1c0051afHeLAC5XnPY; Sun, 25 Oct 2009 17:31:47 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA17.emeryville.ca.mail.comcast.net with comcast id x5XP1c0090BTMe48d5XTX8; Sun, 25 Oct 2009 17:31:44 +0000 From: "Glen Zorn" To: "'Dave Nelson'" , Cc: "'IESG IESG'" References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> <048b01ca5584$591087a0$0b3196e0$@net> <2C5E8C11AE78494CB14CA6C1D32D3B13@NEWTON603> In-Reply-To: <2C5E8C11AE78494CB14CA6C1D32D3B13@NEWTON603> Subject: RE: Data Types defined in RFC 2865 Date: Mon, 26 Oct 2009 00:31:05 +0700 Message-ID: <04d101ca5598$fb1a8690$f14f93b0$@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: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgCL9BjQAAHOdUAADquKsAADM2FQ Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Dave Nelson [mailto://d.b.nelson@comcast.net] writes: > Glen Zorn writes... > > > So am I to understand that, despite the multitude of counterexamples > > and the lack of any explicit text even suggesting such in any RADIUS- > > related RFC, you are claiming that the name of the V field in the TLV > > construct denotes a formal data type (a thing apparently known only > to > > some secret society holding the same "internally consistent belief > > system" (thought police, anyone? ;-)? > > Well, your previous posting claiming to be able to implement an > advanced > server implementation Actually, I didn't claim to be able to implement it myself, nor to have done so, The server I have was done by people a _lot_ smarter than me. > that intuits the syntax of a data model from the > data > stream itself notwithstanding, Isn't that the definition of a data-driven parser? > RADIUS *has* a formal, written data > model. > Many implementations rely on it. It's a very simple data model. So simple and so unnecessary (probably why it is so rarely used). One of the beauties of the TLV format is that the type completely defines the value. > > I think this extended discussion of what constitutes a "formal" > definition > of a new data type in the data model constitutes "protocol lawyering", > a > debate about form without any substance. OK, then how do you know the data type of a new attribute? Is the Value field of the Login-IPv6-Host attribute of type "IPv6 address"? If so, do _all_ attributes of type "IPv6 address" assign special meaning to the values 0 & 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF? If not, then it's mot of type "IPv6 address" is it? A set of formal data types without any way to distinguish between them is useless, except for use as a bludgeon. If you really want to develop a real data model for RADIUS, shouldn't it clarify the protocol operation instead of muddying it? > > In seeking to debunk some of these data model additions, you are > apparently > attempting to build a case for the precedence of using the RADIUS > String > data type to contain non-self-describing data structures. Not at all. As I mentioned above, RADIUS attributes are completely defined by the Type and the description. > This has > been a > point of debate in the RADEXT WG for several years. The WG consensus > is > captured in the Design Guidelines draft. "Consensus" in this WG is, quite frankly, a joke. > The String data type should > be > used for actual strings, or for opaque blobs of binary data, for use in > some > other protocol component, e.g. EAP. There are specific exemptions to > this > recommendation that are spelled out in the draft. > > > > -- > to 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 Sun Oct 25 13:53:55 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 C1E0228C179 for ; Sun, 25 Oct 2009 13:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.132 X-Spam-Level: X-Spam-Status: No, score=-0.132 tagged_above=-999 required=5 tests=[AWL=0.362, 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 foUISjS+GOIL for ; Sun, 25 Oct 2009 13:53:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 33DAB28C173 for ; Sun, 25 Oct 2009 13:53:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2A2N-000Ew2-28 for radiusext-data0@psg.com; Sun, 25 Oct 2009 20:50:03 +0000 Received: from [65.55.116.101] (helo=blu0-omc3-s26.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2A2I-000Euo-TW for radiusext@ops.ietf.org; Sun, 25 Oct 2009 20:49:59 +0000 Received: from BLU137-W7 ([65.55.116.74]) by blu0-omc3-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 13:49:58 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_96ab7bc3-c9f1-4ab0-9777-16d78db17038_" X-Originating-IP: [70.58.72.16] From: Bernard Aboba To: "dromasca@avaya.com" , "radiusext@ops.ietf.org" Subject: RE: [Technical Errata Reported] RFC3162 (1923) Date: Sun, 25 Oct 2009 13:49:59 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 25 Oct 2009 20:49:58.0728 (UTC) FILETIME=[B710B480:01CA55B4] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_96ab7bc3-c9f1-4ab0-9777-16d78db17038_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking for myself without my chair hat on=2C I am not sympathetic to this= errata.=20 RFC 3162 uses the type "Address" in a context that makes it fairly clear th= at it is talking about a new data type for IPv6 addresses=2C rather than th= e existing IPv4 address type defined in RFC 2865. =20 Previous RADIUS RFCs did not "Update: RFC 2865" when introducing new data t= ypes=2C so I don't believe that this was required in RFC 3162 or any other = document.=20 There are other instances in RFC 3162 we have been discussing=2C where the = data type used may not be clear (such as Interface-ID)=2C but this specific= instance doesn't seem ambiguous.=20 > Subject: FW: [Technical Errata Reported] RFC3162 (1923) > Date: Sun=2C 25 Oct 2009 11:27:28 +0100 > From: dromasca@avaya.com > To: radiusext@ops.ietf.org >=20 > RADEXT WG=2C >=20 > Please advise on the Technical Errata below.=20 >=20 > Thanks and Regards=2C >=20 > Dan >=20 >=20 >=20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > RFC Errata System > Sent: Thursday=2C October 22=2C 2009 3:19 PM > To: bernarda@microsoft.com=3B gwz@cisco.com=3B iesg@iesg.org > Cc: aland@freeradius.org=3B rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC3162 (1923) >=20 >=20 > The following errata report has been submitted for RFC3162=2C "RADIUS and > IPv6". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3162&eid=3D1923 >=20 > -------------------------------------- > Type: Technical > Reported by: Alan DeKok >=20 > Section: 2.1 >=20 > Original Text > ------------- > Address >=20 > The Address field is 16 octets. >=20 > Corrected Text > -------------- > String >=20 > The field is 16 octets >=20 > Notes > ----- > As Glen notes in: >=20 > http://ops.ietf.org/lists/radiusext/2009/msg00540.html >=20 > Using "ipv6 address" for a data type in RADIUS is wrong. >=20 > RFC 3162 (among others Glen wrote) contradict his current position. > Those documents use data types for the "value" field of RADIUS > attributes that have not been defined in RFC 2865. As such=2C they shoul= d > either: >=20 > a) make it clear that they define a new data type=2C and be marked as > "Updates: 2865" >=20 > or >=20 > b) use the data types in RFC 2865. >=20 > Or even better=2C maintain an internally consistent set of beliefs=2C a= nd > leave RFC 3162 alone. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary=2C please use > "Reply All" to discuss whether it should be verified or rejected. When a > decision is reached=2C the verifying party (IESG) can log in to change th= e > status and edit the report=2C if necessary.=20 >=20 > -------------------------------------- > RFC3162 (draft-aboba-radius-ipv6-10) > -------------------------------------- > Title : RADIUS and IPv6 > Publication Date : August 2001 > Author(s) : B. Aboba=2C G. Zorn=2C D. Mitton > Category : PROPOSED STANDARD > Source : Legacy > Area : Legacy > Stream : IETF > Verifying Party : IESG >=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: = --_96ab7bc3-c9f1-4ab0-9777-16d78db17038_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking for myself without my chair hat on=2C I am not sympathetic to this= errata.

RFC 3162 uses the type "Address" in a context that makes i= t fairly clear that it is talking about a new data type for IPv6 addresses= =2C rather than the existing IPv4 address type defined in RFC 2865. =3B=

Previous RADIUS RFCs did not "Update: RFC 2865" when introducing n= ew data types=2C so I don't believe that this was required in RFC 3162 or a= ny other document.

There are other instances in RFC 3162 we have be= en discussing=2C where the data type used may not be clear (such as Interfa= ce-ID)=2C but this specific instance doesn't seem ambiguous.

>=3B= Subject: FW: [Technical Errata Reported] RFC3162 (1923)
>=3B Date: Su= n=2C 25 Oct 2009 11:27:28 +0100
>=3B From: dromasca@avaya.com
>= =3B To: radiusext@ops.ietf.org
>=3B
>=3B RADEXT WG=2C
>=3B =
>=3B Please advise on the Technical Errata below.
>=3B
>= =3B Thanks and Regards=2C
>=3B
>=3B Dan
>=3B
>=3B >=3B
>=3B -----Original Message-----
>=3B From: iesg-bounces@= ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of
>=3B RFC Errata S= ystem
>=3B Sent: Thursday=2C October 22=2C 2009 3:19 PM
>=3B To: = bernarda@microsoft.com=3B gwz@cisco.com=3B iesg@iesg.org
>=3B Cc: alan= d@freeradius.org=3B rfc-editor@rfc-editor.org
>=3B Subject: [Technical= Errata Reported] RFC3162 (1923)
>=3B
>=3B
>=3B The follow= ing errata report has been submitted for RFC3162=2C "RADIUS and
>=3B I= Pv6".
>=3B
>=3B --------------------------------------
>=3B= You may review the report below and at:
>=3B http://www.rfc-editor.or= g/errata_search.php?rfc=3D3162&=3Beid=3D1923
>=3B
>=3B ------= --------------------------------
>=3B Type: Technical
>=3B Report= ed by: Alan DeKok <=3Baland@freeradius.org>=3B
>=3B
>=3B Sec= tion: 2.1
>=3B
>=3B Original Text
>=3B -------------
>= =3B Address
>=3B
>=3B The Address field is 16 octets.>=3B
>=3B Corrected Text
>=3B --------------
>=3B Strin= g
>=3B
>=3B The field is 16 octets
>=3B
>=3B Notes<= br>>=3B -----
>=3B As Glen notes in:
>=3B
>=3B http://ops= .ietf.org/lists/radiusext/2009/msg00540.html
>=3B
>=3B Using "ip= v6 address" for a data type in RADIUS is wrong.
>=3B
>=3B RFC 31= 62 (among others Glen wrote) contradict his current position.
>=3B Tho= se documents use data types for the "value" field of RADIUS
>=3B attri= butes that have not been defined in RFC 2865. As such=2C they should
&g= t=3B either:
>=3B
>=3B a) make it clear that they define a new d= ata type=2C and be marked as
>=3B "Updates: 2865"
>=3B
>=3B= or
>=3B
>=3B b) use the data types in RFC 2865.
>=3B >=3B Or even better=2C maintain an internally consistent set of belief= s=2C and
>=3B leave RFC 3162 alone.
>=3B
>=3B Instructions:=
>=3B -------------
>=3B This errata is currently posted as "Repo= rted". If necessary=2C please use
>=3B "Reply All" to discuss whether = it should be verified or rejected. When a
>=3B decision is reached=2C = the verifying party (IESG) can log in to change the
>=3B status and ed= it the report=2C if necessary.
>=3B
>=3B ----------------------= ----------------
>=3B RFC3162 (draft-aboba-radius-ipv6-10)
>=3B -= -------------------------------------
>=3B Title : RADIU= S and IPv6
>=3B Publication Date : August 2001
>=3B Author(s) = : B. Aboba=2C G. Zorn=2C D. Mitton
>=3B Category = : PROPOSED STANDARD
>=3B Source : Legacy
>=3B Area = : Legacy
>=3B Stream : IETF
>=3B Verif= ying Party : IESG
>=3B
>=3B --
>=3B to unsubscribe send= a message to radiusext-request@ops.ietf.org with
>=3B the word 'unsub= scribe' in a single line as the message text body.
>=3B archive: <= =3Bhttp://psg.com/lists/radiusext/>=3B
= --_96ab7bc3-c9f1-4ab0-9777-16d78db17038_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 14:13:36 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 0C64328C14A for ; Sun, 25 Oct 2009 14:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.138 X-Spam-Level: X-Spam-Status: No, score=0.138 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, 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 7UixkKGY8+9u for ; Sun, 25 Oct 2009 14:13:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B2C328C156 for ; Sun, 25 Oct 2009 14:13:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2AMz-000Hdt-7h for radiusext-data0@psg.com; Sun, 25 Oct 2009 21:11:21 +0000 Received: from [65.55.111.167] (helo=blu0-omc4-s28.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2AMv-000Hdh-7p for radiusext@ops.ietf.org; Sun, 25 Oct 2009 21:11:17 +0000 Received: from BLU137-W34 ([65.55.111.136]) by blu0-omc4-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 14:11:16 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f3e1fb29-a23f-41db-8e6e-753a4f190924_" X-Originating-IP: [70.58.72.16] From: Bernard Aboba To: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: RE: Data Types defined in RFC 2865 Date: Sun, 25 Oct 2009 14:11:16 -0700 Importance: Normal In-Reply-To: <2C5E8C11AE78494CB14CA6C1D32D3B13@NEWTON603> References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> <048b01ca5584$591087a0$0b3196e0$@net> X-OriginalArrivalTime: 25 Oct 2009 21:11:16.0680 (UTC) FILETIME=[B0C8B480:01CA55B7] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: <2C5E8C11AE78494CB14CA6C1D32D3B13@NEWTON603> MIME-Version: 1.0 --_f3e1fb29-a23f-41db-8e6e-753a4f190924_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David Nelson said:=20 > In seeking to debunk some of these data model additions=2C you are appare= ntly > attempting to build a case for the precedence of using the RADIUS String > data type to contain non-self-describing data structures. This has been = a > point of debate in the RADEXT WG for several years. The WG consensus is > captured in the Design Guidelines draft. The String data type should be > used for actual strings=2C or for opaque blobs of binary data=2C for use = in some > other protocol component=2C e.g. EAP. There are specific exemptions to t= his > recommendation that are spelled out in the draft. In many ways=2C this argument has long been Overtaken By Events (OBE). RAD= IUS is what it is=2C and very widely deployed protocol. The Design Guidelines = only attempts to describe RADIUS as it is=2C not what it should become.=20 The job of defining what RADIUS could become is the task of the Extended Attributes document. Given that all IESG DISCUSSes have been cleared=2C it's now time for the WG to get past these (largely irrelevant) arguments and move on.=20 = --_f3e1fb29-a23f-41db-8e6e-753a4f190924_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David Nelson said:

>=3B In seeking to debunk some of these data m= odel additions=2C you are apparently
>=3B attempting to build a case f= or the precedence of using the RADIUS String
>=3B data type to contain= non-self-describing data structures. This has been a
>=3B point of d= ebate in the RADEXT WG for several years. The WG consensus is
>=3B ca= ptured in the Design Guidelines draft. The String data type should be
&= gt=3B used for actual strings=2C or for opaque blobs of binary data=2C for = use in some
>=3B other protocol component=2C e.g. EAP. There are spec= ific exemptions to this
>=3B recommendation that are spelled out in th= e draft.

In many ways=2C this argument has long been Overtaken By Ev= ents (OBE). =3B RADIUS
is what it is=2C and very widely deployed pro= tocol. =3B The Design Guidelines only
attempts to describe RADIUS as= it is=2C not what it should become.

The job of defining what RADIU= S could become is the task of the Extended
Attributes document. =3B = Given that all IESG DISCUSSes have been cleared=2C
it's now time for the= WG to get past these (largely irrelevant) arguments
and move on.
= = --_f3e1fb29-a23f-41db-8e6e-753a4f190924_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 20:57: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 C439D3A6891 for ; Sun, 25 Oct 2009 20:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_05=-1.11, 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 A7TvL-HwEaRb for ; Sun, 25 Oct 2009 20:57:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A32B73A687D for ; Sun, 25 Oct 2009 20:57:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2GeC-000IGM-19 for radiusext-data0@psg.com; Mon, 26 Oct 2009 03:53:32 +0000 Received: from [65.55.116.109] (helo=blu0-omc3-s34.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2Ge9-000IG5-V9 for radiusext@ops.ietf.org; Mon, 26 Oct 2009 03:53:30 +0000 Received: from BLU137-W25 ([65.55.116.74]) by blu0-omc3-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 20:53:29 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_2d154e22-ba97-45e5-9c7f-cd7a6bca6ff1_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: "dromasca@avaya.com" , "radiusext@ops.ietf.org" Subject: Re: Pending Errata for RADEXT Date: Sun, 25 Oct 2009 20:53:29 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 26 Oct 2009 03:53:29.0483 (UTC) FILETIME=[E10E35B0:01CA55EF] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_2d154e22-ba97-45e5-9c7f-cd7a6bca6ff1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking only for myself=2C the follow errata look reasonable and should be= accepted: 420 867 1407 The following errata relate to problems with RFC 4282 which were uncovered = in the IDNAbis effort. While the nature of the problems is pointed out in = the IDNAbis documents which have just completed IETF last call=2C the solut= ions will require substantial revisions to RFC 4282 which can only be accom= plished in a -bis document. Therefore these errata should probably either = be classified as "pending update" or rejected: 1848=2C 1849=2C 1850 Pending errata for RADEXT To: "radext mailing list" Subject: Pending errata f= or RADEXTFrom: "Romascanu=2C Dan (Dan)" Date: Sun=2C 25= Oct 2009 11:31:56 +0100 RADEXT WG=2C=20 There are a number of pending errata related to RADIUS that I have asked recommendation in the past for the WG. Please process and advice how for resolutions on these errata. Some of them are rather simple=2C some other may require some more thought.=20 The IDs (in the order of their occurrences in the tracker) are: 1607=2C 420=2C 1469=2C 753=2C 1848=2C 1849=2C 1850=2C 867=2C 1407.=20 Thanks and Regards=2C Dan = --_2d154e22-ba97-45e5-9c7f-cd7a6bca6ff1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking only for myself=2C the follow errata look reasonable and should be= accepted:

420
867
1407

The following errata relate to = problems with RFC 4282 which were uncovered in the IDNAbis effort. =3B = While the nature of the problems is pointed out in the IDNAbis documents wh= ich have just completed IETF last call=2C the solutions will require substa= ntial revisions to RFC 4282 which can only be accomplished in a -bis docume= nt. =3B Therefore these errata should probably either be classified as = "pending update" or rejected:

1848=2C 1849=2C 1850






Pending errata for RADEXT

RADEXT WG=2C 

There are a number of pending errata related to R=
ADIUS that I have asked
recommendation in the past for the WG. Please pr=
ocess and advice how for
resolutions on these errata. Some of them are r=
ather simple=2C some other
may require some more thought. 

The ID=
s (in the order of their occurrences in the tracker) are: 1607=2C
420=2C=
 1469=2C 753=2C 1848=2C 1849=2C 1850=2C 867=2C 1407. 

Thanks and Reg=
ards=2C

Dan

<= tbody>

= --_2d154e22-ba97-45e5-9c7f-cd7a6bca6ff1_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 21:27: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 146C328C1E4 for ; Sun, 25 Oct 2009 21:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.728 X-Spam-Level: X-Spam-Status: No, score=-0.728 tagged_above=-999 required=5 tests=[AWL=-0.291, 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 uguCu0pi7PWt for ; Sun, 25 Oct 2009 21:27:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 333D53A683C for ; Sun, 25 Oct 2009 21:27:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2H8y-000L4A-7m for radiusext-data0@psg.com; Mon, 26 Oct 2009 04:25:20 +0000 Received: from [76.96.62.16] (helo=QMTA01.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2H8v-000L3l-Tw for radiusext@ops.ietf.org; Mon, 26 Oct 2009 04:25:18 +0000 Received: from OMTA23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA01.westchester.pa.mail.comcast.net with comcast id xGFp1c0021c6gX851GRJeH; Mon, 26 Oct 2009 04:25:18 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA23.westchester.pa.mail.comcast.net with comcast id xGY01c0064H2mdz3jGY02l; Mon, 26 Oct 2009 04:32:01 +0000 From: "Dave Nelson" To: , References: Subject: RE: Pending Errata for RADEXT Date: Mon, 26 Oct 2009 00:25:24 -0400 Message-ID: <2D201A0818854A5E8B886C8A5A3E2B08@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpV8HECVpuir9h5SIqBwN+2W+tXqQAA5i/g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba writes... > Speaking only for myself, the follow errata look reasonable > and should be accepted: > > 420 > 867 > 1407 I concur on 867 and 1407. I have no opinion on 420. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 22:15:43 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 365A33A68CD for ; Sun, 25 Oct 2009 22:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.863 X-Spam-Level: X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wonnZZxo-Q8O for ; Sun, 25 Oct 2009 22:15:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3623B3A67A5 for ; Sun, 25 Oct 2009 22:15:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2HrY-000OxQ-1x for radiusext-data0@psg.com; Mon, 26 Oct 2009 05:11:24 +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 1N2HrU-000OwP-GR for radiusext@ops.ietf.org; Mon, 26 Oct 2009 05:11:21 +0000 Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA03.westchester.pa.mail.comcast.net with comcast id xHAX1c0010QuhwU53HBLmq; Mon, 26 Oct 2009 05:11:20 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA02.westchester.pa.mail.comcast.net with comcast id xHB41c0010BTMe43NHB8Ae; Mon, 26 Oct 2009 05:11:18 +0000 From: "Glen Zorn" To: Cc: "'Bernard Aboba'" , References: In-Reply-To: Subject: RE: Pending Errata for RADEXT Date: Mon, 26 Oct 2009 12:11:01 +0700 Message-ID: <003701ca55fa$be3c5390$3ab4fab0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01CA5635.6A9B2B90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpV8ILktolxKwEJQ2ePwvpP/DT/WQAB5zQw 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_0038_01CA5635.6A9B2B90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard Aboba ]mailto://bernard_aboba@hotmail.com] writes: From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Monday, October 26, 2009 10:53 AM To: dromasca@avaya.com; radiusext@ops.ietf.org Subject: Re: Pending Errata for RADEXT Speaking only for myself, the follow errata look reasonable and should be accepted: 420 Agree. 867 Agree. 1407 Agree. The following errata relate to problems with RFC 4282 which were uncovered in the IDNAbis effort. While the nature of the problems is pointed out in the IDNAbis documents which have just completed IETF last call, the solutions will require substantial revisions to RFC 4282 which can only be accomplished in a -bis document. Therefore these errata should probably either be classified as "pending update" or rejected: 1848, 1849, 1850 I think that all three of these should be rejected. Although there may be a point to 1849, the notes point to an I-D, not an RFC, which itself does not suggest site-specific handling of bidirectional character sets. 1848 may make some sense (leaving aside the pompous declaration that "Much of RFC 4282 is simply wrong") but 1850 is pure nonsense, as I pointed out at some length awhile back. Pending errata for RADEXT _____ * To: "radext mailing list" > * Subject: Pending errata for RADEXT * From: "Romascanu, Dan (Dan)" > * Date: Sun, 25 Oct 2009 11:31:56 +0100 _____ RADEXT WG, There are a number of pending errata related to RADIUS that I have asked recommendation in the past for the WG. Please process and advice how for resolutions on these errata. Some of them are rather simple, some other may require some more thought. The IDs (in the order of their occurrences in the tracker) are: 1607, 420, 1469, 753, 1848, 1849, 1850, 867, 1407. Thanks and Regards, Dan ------=_NextPart_000_0038_01CA5635.6A9B2B90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bernard Aboba ]mailto://bernard_aboba@hotmai= l.com] writes:

 

From:= = owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard = Aboba
Sent: Monday, October 26, 2009 10:53 AM
To: dromasca@avaya.com; radiusext@ops.ietf.org
Subject: Re: Pending Errata for RADEXT

 

Speaking only for myself, the follow = errata look reasonable and should be accepted:

420

Agree.


867

Agree.


1407

Agree.


The following errata relate to problems with RFC 4282 which were = uncovered in the IDNAbis effort.  While the nature of the problems is pointed = out in the IDNAbis documents which have just completed IETF last call, the = solutions will require substantial revisions to RFC 4282 which can only be = accomplished in a -bis document.  Therefore these errata should probably either = be classified as "pending update" or rejected:

1848, 1849, 1850

I think that all = three of these should be rejected.  Although there may be a point to 1849, = the notes point to an I-D, not an RFC, which itself does not suggest = site-specific handling of bidirectional character sets.  1848 may make some sense (leaving aside the pompous declaration that “Much of RFC 4282 is = simply wrong”) but 1850 is pure nonsense, as I pointed out at some length = awhile back.








Pending errata = for RADEXT

RADEXT WG, 



There are a number of pending errata related to RADIUS that I have =
asked

recommendation in the past for the WG. Please process and advice how =
for

resolutions on these errata. Some of them are rather simple, some =
other

may require some more thought. 



The IDs (in the order of their occurrences in the tracker) are: =
1607,

420, 1469, 753, 1848, 1849, 1850, 867, 1407. 



Thanks and Regards,



Dan

 =

 

------=_NextPart_000_0038_01CA5635.6A9B2B90-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Oct 25 23:08: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 10C923A6951 for ; Sun, 25 Oct 2009 23:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAqhZMOFml4q for ; Sun, 25 Oct 2009 23:08:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6EC643A68AD for ; Sun, 25 Oct 2009 23:08:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2Iil-0003et-2e for radiusext-data0@psg.com; Mon, 26 Oct 2009 06:06:23 +0000 Received: from [76.96.30.56] (helo=QMTA06.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2Iih-0003eR-Uq for radiusext@ops.ietf.org; Mon, 26 Oct 2009 06:06:20 +0000 Received: from OMTA19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id xJ5B1c0041eYJf8A6J6LNb; Mon, 26 Oct 2009 06:06:20 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA19.emeryville.ca.mail.comcast.net with comcast id xJ641c0020BTMe401J68Fz; Mon, 26 Oct 2009 06:06:18 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , "'David B. Nelson'" Cc: References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> <048b01ca5584$591087a0$0b3196e0$@net> In-Reply-To: Subject: RE: Data Types defined in RFC 2865 Date: Mon, 26 Oct 2009 13:06:00 +0700 Message-ID: <004e01ca5602$6d635470$4829fd50$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01CA563D.19C22C70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpVuAdmLIA8U5HkQnKSErnx27A84wAQ5m8g 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_004F_01CA563D.19C22C70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard Aboba [mailto://bernard_aboba@hotmail.com] writes: David Nelson said: > In seeking to debunk some of these data model additions, you are apparently > attempting to build a case for the precedence of using the RADIUS String > data type to contain non-self-describing data structures. This has been a > point of debate in the RADEXT WG for several years. The WG consensus is > captured in the Design Guidelines draft. The String data type should be > used for actual strings, or for opaque blobs of binary data, for use in some > other protocol component, e.g. EAP. There are specific exemptions to this > recommendation that are spelled out in the draft. In many ways, this argument has long been Overtaken By Events (OBE). RADIUS is what it is, and very widely deployed protocol. The Design Guidelines only attempts to describe RADIUS as it is, not what it should become. OK, so now I'm completely confused. If the purpose of the document isn't to give guidance regarding the design of future attributes, what is it? Aside from that, even as a description of RADIUS "as it is" the document fails, since it denigrates without justification (aside from the spurious "code change" argument) the so-called "complex" attributes that have been part of RADIUS for almost a decade. . ------=_NextPart_000_004F_01CA563D.19C22C70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

David Nelson said:

> In seeking to debunk some of these data model additions, you are apparently
> attempting to build a case for the precedence of using the RADIUS = String
> data type to contain non-self-describing data structures. This has = been a
> point of debate in the RADEXT WG for several years. The WG = consensus is
> captured in the Design Guidelines draft. The String data type = should be
> used for actual strings, or for opaque blobs of binary data, for = use in some
> other protocol component, e.g. EAP. There are specific exemptions = to this
> recommendation that are spelled out in the draft.

In many ways, this argument has long been Overtaken By Events = (OBE).  RADIUS
is what it is, and very widely deployed protocol.  The Design = Guidelines only
attempts to describe RADIUS as it is, not what it should become.

 

OK, so now I’m completely confused.  If the = purpose of the document isn’t to give guidance regarding the design of = future attributes, what is it?  Aside from that, even as a description of = RADIUS “as it is” the document fails, since it denigrates without = justification (aside from the spurious “code change” argument) the = so-called “complex” attributes that have been part of RADIUS for almost a decade.

…

------=_NextPart_000_004F_01CA563D.19C22C70-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Oct 26 01:33:55 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 E41FA3A6906 for ; Mon, 26 Oct 2009 01:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.364 X-Spam-Level: X-Spam-Status: No, score=-1.364 tagged_above=-999 required=5 tests=[AWL=-0.870, 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 FNREEfGHrw-I for ; Mon, 26 Oct 2009 01:33:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7A3C93A6774 for ; Mon, 26 Oct 2009 01:33:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2Kws-000G9K-VM for radiusext-data0@psg.com; Mon, 26 Oct 2009 08:29:06 +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 1N2Kwp-000G8z-WF for radiusext@ops.ietf.org; Mon, 26 Oct 2009 08:29:04 +0000 X-IronPort-AV: E=Sophos;i="4.44,625,1249272000"; d="scan'208,217";a="161330713" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Oct 2009 04:29:00 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Oct 2009 04:28:59 -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_01CA5616.5147CC54" Subject: RE: [Technical Errata Reported] RFC3162 (1923) Date: Mon, 26 Oct 2009 09:28:40 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Technical Errata Reported] RFC3162 (1923) Thread-Index: AcpVtLxbL7pfjWfkRZKmBhrfVdKt+wAYW9GQ References: 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_01CA5616.5147CC54 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on the opinions expressed by you and Glen, do I hear a consensus to reject this errata?=20 =20 Dan =20 ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Sunday, October 25, 2009 10:50 PM To: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: [Technical Errata Reported] RFC3162 (1923) =09 =09 Speaking for myself without my chair hat on, I am not sympathetic to this errata.=20 =09 RFC 3162 uses the type "Address" in a context that makes it fairly clear that it is talking about a new data type for IPv6 addresses, rather than the existing IPv4 address type defined in RFC 2865. =20 =09 Previous RADIUS RFCs did not "Update: RFC 2865" when introducing new data types, so I don't believe that this was required in RFC 3162 or any other document.=20 =09 There are other instances in RFC 3162 we have been discussing, where the data type used may not be clear (such as Interface-ID), but this specific instance doesn't seem ambiguous.=20 =09 > Subject: FW: [Technical Errata Reported] RFC3162 (1923) > Date: Sun, 25 Oct 2009 11:27:28 +0100 > From: dromasca@avaya.com > To: radiusext@ops.ietf.org >=20 > RADEXT WG, >=20 > Please advise on the Technical Errata below.=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > RFC Errata System > Sent: Thursday, October 22, 2009 3:19 PM > To: bernarda@microsoft.com; gwz@cisco.com; iesg@iesg.org > Cc: aland@freeradius.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC3162 (1923) >=20 >=20 > The following errata report has been submitted for RFC3162, "RADIUS and > IPv6". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3162&eid=3D1923 >=20 > -------------------------------------- > Type: Technical > Reported by: Alan DeKok >=20 > Section: 2.1 >=20 > Original Text > ------------- > Address >=20 > The Address field is 16 octets. >=20 > Corrected Text > -------------- > String >=20 > The field is 16 octets >=20 > Notes > ----- > As Glen notes in: >=20 > http://ops.ietf.org/lists/radiusext/2009/msg00540.html >=20 > Using "ipv6 address" for a data type in RADIUS is wrong. >=20 > RFC 3162 (among others Glen wrote) contradict his current position. > Those documents use data types for the "value" field of RADIUS > attributes that have not been defined in RFC 2865. As such, they should > either: >=20 > a) make it clear that they define a new data type, and be marked as > "Updates: 2865" >=20 > or >=20 > b) use the data types in RFC 2865. >=20 > Or even better, maintain an internally consistent set of beliefs, and > leave RFC 3162 alone. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please use > "Reply All" to discuss whether it should be verified or rejected. When a > decision is reached, the verifying party (IESG) can log in to change the > status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC3162 (draft-aboba-radius-ipv6-10) > -------------------------------------- > Title : RADIUS and IPv6 > Publication Date : August 2001 > Author(s) : B. Aboba, G. Zorn, D. Mitton > Category : PROPOSED STANDARD > Source : Legacy > Area : Legacy > Stream : IETF > Verifying Party : IESG >=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: =09 ------_=_NextPart_001_01CA5616.5147CC54 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Based on the=20 opinions expressed by you and Glen, do I hear a consensus to reject this = errata?=20
 
Dan
 

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: Sunday, October = 25, 2009=20 10:50 PM
To: Romascanu, Dan (Dan);=20 radiusext@ops.ietf.org
Subject: RE: [Technical Errata = Reported]=20 RFC3162 (1923)

Speaking for myself without my chair hat on, I am not = sympathetic=20 to this errata.

RFC 3162 uses the type "Address" in a context = that=20 makes it fairly clear that it is talking about a new data type for = IPv6=20 addresses, rather than the existing IPv4 address type defined in RFC=20 2865. 

Previous RADIUS RFCs did not "Update: RFC 2865" = when=20 introducing new data types, so I don't believe that this was required = in RFC=20 3162 or any other document.

There are other instances in RFC = 3162 we=20 have been discussing, where the data type used may not be clear (such = as=20 Interface-ID), but this specific instance doesn't seem ambiguous. =

>=20 Subject: FW: [Technical Errata Reported] RFC3162 (1923)
> Date: = Sun, 25=20 Oct 2009 11:27:28 +0100
> From: dromasca@avaya.com
> To:=20 radiusext@ops.ietf.org
>
> RADEXT WG,
>
> = Please=20 advise on the Technical Errata below.
>
> Thanks and=20 Regards,
>
> Dan
>
>
>
> = -----Original=20 Message-----
> From: iesg-bounces@ietf.org=20 [mailto:iesg-bounces@ietf.org] On Behalf Of
> RFC Errata = System
>=20 Sent: Thursday, October 22, 2009 3:19 PM
> To: = bernarda@microsoft.com;=20 gwz@cisco.com; iesg@iesg.org
> Cc: aland@freeradius.org;=20 rfc-editor@rfc-editor.org
> Subject: [Technical Errata Reported] = RFC3162=20 (1923)
>
>
> The following errata report has been=20 submitted for RFC3162, "RADIUS and
> IPv6".
>
>=20 --------------------------------------
> You may review the = report below=20 and at:
>=20 = http://www.rfc-editor.org/errata_search.php?rfc=3D3162&eid=3D1923
= >=20
> --------------------------------------
> Type:=20 Technical
> Reported by: Alan DeKok = <aland@freeradius.org>
>=20
> Section: 2.1
>
> Original Text
>=20 -------------
> Address
>
> The Address field is 16 = octets.
>
> Corrected Text
> --------------
> = String
>
> The field is 16 octets
>
> = Notes
>=20 -----
> As Glen notes in:
>
>=20 http://ops.ietf.org/lists/radiusext/2009/msg00540.html
> =
> Using=20 "ipv6 address" for a data type in RADIUS is wrong.
>
> = RFC 3162=20 (among others Glen wrote) contradict his current position.
> = Those=20 documents use data types for the "value" field of RADIUS
> = attributes=20 that have not been defined in RFC 2865. As such, they should
>=20 either:
>
> a) make it clear that they define a new data = type,=20 and be marked as
> "Updates: 2865"
>
> or
> =
>=20 b) use the data types in RFC 2865.
>
> Or even better, = maintain=20 an internally consistent set of beliefs, and
> leave RFC 3162=20 alone.
>
> Instructions:
> -------------
> = This=20 errata is currently posted as "Reported". If necessary, please = use
>=20 "Reply All" to discuss whether it should be verified or rejected. When = a
> decision is reached, the verifying party (IESG) can log in = to change=20 the
> status and edit the report, if necessary.
> =
>=20 --------------------------------------
> RFC3162=20 (draft-aboba-radius-ipv6-10)
>=20 --------------------------------------
> Title : RADIUS and = IPv6
>=20 Publication Date : August 2001
> Author(s) : B. Aboba, G. Zorn, = D.=20 Mitton
> Category : PROPOSED STANDARD
> Source : = Legacy
>=20 Area : Legacy
> Stream : IETF
> Verifying Party : = IESG
>=20
> --
> to unsubscribe send a message to=20 radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in = a single=20 line as the message text body.
> archive:=20 <http://psg.com/lists/radiusext/>
------_=_NextPart_001_01CA5616.5147CC54-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Oct 26 06:01:35 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 DC55E28C0E1 for ; Mon, 26 Oct 2009 06:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.838 X-Spam-Level: X-Spam-Status: No, score=-0.838 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dLtsLCuGuNY for ; Mon, 26 Oct 2009 06:01:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 333553A6860 for ; Mon, 26 Oct 2009 06:01:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2P8B-000G6s-7d for radiusext-data0@psg.com; Mon, 26 Oct 2009 12:57:03 +0000 Received: from [76.96.30.40] (helo=QMTA04.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2P89-000G6d-3W for radiusext@ops.ietf.org; Mon, 26 Oct 2009 12:57:01 +0000 Received: from OMTA23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id xQeT1c0071wfjNsA4Qx1H6; Mon, 26 Oct 2009 12:57:01 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA23.emeryville.ca.mail.comcast.net with comcast id xR4c1c00B0BTMe48jR4hng; Mon, 26 Oct 2009 13:04:51 +0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" Cc: "'Bernard Aboba'" , References: In-Reply-To: Subject: RE: [Technical Errata Reported] RFC3162 (1923) Date: Mon, 26 Oct 2009 19:56:40 +0700 Message-ID: <021b01ca563b$cba0e960$62e2bc20$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_021C_01CA5676.77FFC160" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpVtLxbL7pfjWfkRZKmBhrfVdKt+wAYW9GQAAk0CCA= 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_021C_01CA5676.77FFC160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dan Romascanu [mailto://dromasca@avaya.com] writes: Based on the opinions expressed by you and Glen, do I hear a consensus to reject this errata? I think that Bernard & I agree that it should be rejected, though for different reasons. Whether that makes a consensus is a matter of opinion, I suppose. Dan . ------=_NextPart_000_021C_01CA5676.77FFC160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan Romascanu [mailto://dromasca@avaya.com] = writes:

Based on the opinions expressed by you and Glen, do I hear a consensus to reject this errata?

I think that Bernard & I agree that it should be = rejected, though for different reasons.  Whether that makes a consensus is a matter = of opinion, I suppose.

 

Dan=

 =

…

------=_NextPart_000_021C_01CA5676.77FFC160-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Oct 26 06:08:12 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 173C028C0E8 for ; Mon, 26 Oct 2009 06:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.358 X-Spam-Level: X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5 tests=[AWL=-0.864, 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 znWQ80yhxtth for ; Mon, 26 Oct 2009 06:08:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B3DE13A67FD for ; Mon, 26 Oct 2009 06:08:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2PGl-000H4U-VY for radiusext-data0@psg.com; Mon, 26 Oct 2009 13:05:55 +0000 Received: from [198.152.13.100] (helo=co300216-co-outbound.net.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2PGj-000H4G-MX for radiusext@ops.ietf.org; Mon, 26 Oct 2009 13:05:53 +0000 X-IronPort-AV: E=Sophos;i="4.44,625,1249272000"; d="scan'208,217";a="188132177" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Oct 2009 09:05:52 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Oct 2009 09:05:51 -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_01CA563D.074131B2" Subject: RE: [Technical Errata Reported] RFC3162 (1923) Date: Mon, 26 Oct 2009 14:05:44 +0100 Message-ID: In-Reply-To: <021b01ca563b$cba0e960$62e2bc20$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Technical Errata Reported] RFC3162 (1923) Thread-Index: AcpVtLxbL7pfjWfkRZKmBhrfVdKt+wAYW9GQAAk0CCAAAHFRgA== References: <021b01ca563b$cba0e960$62e2bc20$@net> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" Cc: "Bernard Aboba" , Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA563D.074131B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Of course.=20 =20 The reasons will be listed in the motivation. If somebody disagrees with the reasons exposed I expect comments on this.=20 =20 Dan =20 ________________________________ From: Glen Zorn [mailto:glenzorn@comcast.net]=20 Sent: Monday, October 26, 2009 2:57 PM To: Romascanu, Dan (Dan) Cc: 'Bernard Aboba'; radiusext@ops.ietf.org Subject: RE: [Technical Errata Reported] RFC3162 (1923) =09 =09 Dan Romascanu [mailto://dromasca@avaya.com] writes: =09 =09 Based on the opinions expressed by you and Glen, do I hear a consensus to reject this errata?=20 I think that Bernard & I agree that it should be rejected, though for different reasons. Whether that makes a consensus is a matter of opinion, I suppose. =20 Dan =20 ... ------_=_NextPart_001_01CA563D.074131B2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Of=20 course.
 
The reasons will be listed in the motivation. If = somebody=20 disagrees with the reasons exposed I expect comments on this.=20
 
Dan
 

From: Glen Zorn = [mailto:glenzorn@comcast.net]=20
Sent: Monday, October 26, 2009 2:57 PM
To: = Romascanu, Dan=20 (Dan)
Cc: 'Bernard Aboba'; = radiusext@ops.ietf.org
Subject:=20 RE: [Technical Errata Reported] RFC3162 (1923)

Dan=20 Romascanu [mailto://dromasca@avaya.com]=20 writes:

Based=20 on the opinions expressed by you and Glen, do I hear a consensus to = reject=20 this errata?

I=20 think that Bernard & I agree that it should be rejected, though = for=20 different reasons.  Whether that makes a consensus is a matter of = opinion, I suppose.

 

Dan

 

…

------_=_NextPart_001_01CA563D.074131B2-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Oct 26 06:14:37 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 A11CF28B56A for ; Mon, 26 Oct 2009 06:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzkHpbuRwC0T for ; Mon, 26 Oct 2009 06:14:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 349893A68ED for ; Mon, 26 Oct 2009 06:14:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2PMm-000HbP-EO for radiusext-data0@psg.com; Mon, 26 Oct 2009 13:12:08 +0000 Received: from [76.96.27.228] (helo=QMTA15.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2PMj-000HbB-B1 for radiusext@ops.ietf.org; Mon, 26 Oct 2009 13:12:05 +0000 Received: from OMTA18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by QMTA15.emeryville.ca.mail.comcast.net with comcast id xR2P1c0041bwxycAFRC5pB; Mon, 26 Oct 2009 13:12:05 +0000 Received: from gwzPC ([124.120.217.8]) by OMTA18.emeryville.ca.mail.comcast.net with comcast id xRJb1c0060BTMe48eRJkyV; Mon, 26 Oct 2009 13:18:58 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , "David Mitton" Cc: , References: In-Reply-To: Subject: RE: [Technical Errata Reported] RFC3162 (1923) Date: Mon, 26 Oct 2009 20:11:11 +0700 Message-ID: <023801ca563d$e5c3d210$b14b7630$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0239_01CA5678.9222AA10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpVtUd4ezxCS4JnSO27M+JW7DGFywAhpbpw 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_0239_01CA5678.9222AA10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard Aboba [mailto://bernard_aboba@hotmail.com]: writes: Speaking for myself without my chair hat on, I am not sympathetic to this errata. RFC 3162 uses the type "Address" in a context that makes it fairly clear that it is talking about a new data type for IPv6 addresses, rather than the existing IPv4 address type defined in RFC 2865. OK, just to satisfy my own mind, were you guys aware at the time that we were "defining a new RADIUS data type"? I know that I wasn't: I just thought that, gosh, "Address" is a good thing to call a field that holds an address. I don't recall any conversation about it amongst us (or in the WG) at the time; was it just so obvious that it didn't even bear mention? Put another way, am I the only moron on the planet that was completely unaware of the "Da Vinci Code" aspects of the RADIUS RFCs (esp. 2865)? Previous RADIUS RFCs did not "Update: RFC 2865" when introducing new data types, so I don't believe that this was required in RFC 3162 or any other document. Actually, had I understood that we were, in fact, altering the set of RADIUS data types at the time I probably would have suggested updating 2865. There are other instances in RFC 3162 we have been discussing, where the data type used may not be clear (such as Interface-ID), but this specific instance doesn't seem ambiguous. . ------=_NextPart_000_0239_01CA5678.9222AA10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

Speaking for myself without my chair hat on, I am not sympathetic to this errata. =

RFC 3162 uses the type "Address" in a context that makes it = fairly clear that it is talking about a new data type for IPv6 addresses, = rather than the existing IPv4 address type defined in RFC 2865. 
OK, just to satisfy my own mind, were you guys aware at = the time that we were “defining a new RADIUS data type”?  I know = that I wasn’t: I just thought that, gosh, “Address” is a good = thing to call a field that holds an address.  I don’t recall any conversation about it amongst us (or in the WG) at the time; was it just = so obvious that it didn’t even bear mention?  Put another way, = am I the only moron on the planet that was completely unaware of the “Da = Vinci Code” aspects of the RADIUS RFCs (esp. 2865)?
Previous RADIUS RFCs did not "Update: RFC 2865" when introducing new = data types, so I don't believe that this was required in RFC 3162 or any = other document.
Actually, had I understood that we were, in fact, = altering the set of RADIUS data types at the time I probably would have suggested = updating 2865…
There are other instances in RFC 3162 we have been discussing, where the data = type used may not be clear (such as Interface-ID), but this specific instance doesn't seem ambiguous.
…

------=_NextPart_000_0239_01CA5678.9222AA10-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Oct 26 07:27: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 E2F2D3A67A3 for ; Mon, 26 Oct 2009 07:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.141 X-Spam-Level: X-Spam-Status: No, score=0.141 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, 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 n1CgQrF8knlq for ; Mon, 26 Oct 2009 07:27:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27B0E3A68ED for ; Mon, 26 Oct 2009 07:27:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2QU0-0000CM-Ml for radiusext-data0@psg.com; Mon, 26 Oct 2009 14:23:40 +0000 Received: from [65.55.111.147] (helo=blu0-omc4-s8.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2QTy-0000Bv-9c for radiusext@ops.ietf.org; Mon, 26 Oct 2009 14:23:38 +0000 Received: from BLU137-W11 ([65.55.111.135]) by blu0-omc4-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 07:23:37 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_922eec67-a767-4c76-b4a1-567f8c4cb414_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Glen Zorn , "David B. Nelson" CC: "radiusext@ops.ietf.org" Subject: RE: Data Types defined in RFC 2865 Date: Mon, 26 Oct 2009 07:23:38 -0700 Importance: Normal In-Reply-To: <004e01ca5602$6d635470$4829fd50$@net> References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> <048b01ca5584$591087a0$0b3196e0$@net> X-OriginalArrivalTime: 26 Oct 2009 14:23:37.0712 (UTC) FILETIME=[E8841F00:01CA5647] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: <004e01ca5602$6d635470$4829fd50$@net> MIME-Version: 1.0 --_922eec67-a767-4c76-b4a1-567f8c4cb414_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Glen said: "Aside from that=2C even as a description of RADIUS =93as it is=94 the document fails=2C since it denigrates without justification (aside from the spurious =93code change=94 argument) the so-called =93compl= ex=94 attributes that have been part of RADIUS for almost a decade." The original goal was just to describe the complex attributes=2C not to den= igrate them. What specific text is problematic?=20 =85 = --_922eec67-a767-4c76-b4a1-567f8c4cb414_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Glen said:

"Aside from that=2C even as a description of RADIUS =93as it is=94 the document fails=2C since it denigrates without justification (aside from the spurious =93code change=94 argument) the so-called =93compl= ex=94 attributes that have been part of RADIUS for almost a decade."

The o= riginal goal was just to describe the complex attributes=2C not to denigrat= e them. =3B What specific text is problematic?
=85


= --_922eec67-a767-4c76-b4a1-567f8c4cb414_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Oct 26 13:47:31 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 50BB828C36B for ; Mon, 26 Oct 2009 13:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.032 X-Spam-Level: * X-Spam-Status: No, score=1.032 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, 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 ggmE3NOODpef for ; Mon, 26 Oct 2009 13:47:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7113428C354 for ; Mon, 26 Oct 2009 13:47:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2WQ1-000GPG-7r for radiusext-data0@psg.com; Mon, 26 Oct 2009 20:43:57 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2WPy-000GOm-Q6 for radiusext@ops.ietf.org; Mon, 26 Oct 2009 20:43:54 +0000 Received: from Thor.local (unknown [74.198.12.3]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 3752F123432F; Mon, 26 Oct 2009 21:43:50 +0100 (CET) Message-ID: <4AE60A00.6040209@deployingradius.com> Date: Mon, 26 Oct 2009 16:43:44 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: 'Dave Nelson' , radiusext@ops.ietf.org, 'IESG IESG' Subject: Re: Proposed Resolution of Issue #318: REJECT References: <048601ca5580$560df2d0$0229d870$@net> <8F84EE704D0F419AB406F5E658B4E37B@NEWTON603> <048f01ca5587$69ecc130$3dc64390$@net> <77AEC2179BCC41458BF54596AFE12794@NEWTON603> <04ca01ca5594$04d3a360$0e7aea20$@net> In-Reply-To: <04ca01ca5594$04d3a360$0e7aea20$@net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote: ... >>> In fact I hold the idea in great esteem; what I disvalue is >>> the idea that data-driven models have to be implementable by >>> below-average high-school kids. ... > If you would be kind enough to read my comment, you will see that I said > nothing whatsoever about my colleagues, let alone anything insulting or > dismissive. Nonsense. In case you had missed the major shift in software of the last 20 years, many world-class software products are written *without* a budget. i.e. Open Source projects, among others. Your comments are insulting to me personally, and to any number of people whose customers demand something *other* than "what Glen wants". > The fact is, however, (as Hannes has also pointed out) that > the processing model assumed in the Design Guidelines draft is simplistic > and limited, if not outright primitive. If you wish to believe that that > fact makes the promoters of the model simplistic, limited and primitive as > well, that is your choice but I said nothing of the sort. Your statement was the equivalent of "have you stopped beating your wife yet". It's insulting, dismissed, and damned well *intended* to be insulting and dismissive. 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 Oct 26 13:49: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 965C53A67CC for ; Mon, 26 Oct 2009 13:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.558 X-Spam-Level: * X-Spam-Status: No, score=1.558 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, 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 YvyZiV6y9WFS for ; Mon, 26 Oct 2009 13:49:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C9B073A6781 for ; Mon, 26 Oct 2009 13:49:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2WTM-000GmN-DZ for radiusext-data0@psg.com; Mon, 26 Oct 2009 20:47:24 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2WTK-000Gm8-0g for radiusext@ops.ietf.org; Mon, 26 Oct 2009 20:47:22 +0000 Received: from Thor.local (unknown [74.198.12.3]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 663FE123432F; Mon, 26 Oct 2009 21:47:20 +0100 (CET) Message-ID: <4AE60AD3.1070401@deployingradius.com> Date: Mon, 26 Oct 2009 16:47:15 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "dromasca@avaya.com" , "radiusext@ops.ietf.org" Subject: Re: [Technical Errata Reported] RFC3162 (1923) References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > Speaking for myself without my chair hat on, I am not sympathetic to > this errata. Neither am I, quite frankly. But it gives Glen a choice that is difficult to make: a) fix RFC 3162 to use the RFC 2865 data types or b) agree that IPv6 data types were defined by him in RADIUS, and that the design guidelines document doesn't "invent" that type I'm tired of specious and internally inconsistent arguments. I would like to make progress without being accused of thinking I'm god, or of inventing decade-old RADIUS traditions. 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 Oct 26 13:52: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 945B23A69BB for ; Mon, 26 Oct 2009 13:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.733 X-Spam-Level: * X-Spam-Status: No, score=1.733 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, 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 H7cZYOkUkty1 for ; Mon, 26 Oct 2009 13:52:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD99C3A67CC for ; Mon, 26 Oct 2009 13:52:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2WVT-000GyO-0f for radiusext-data0@psg.com; Mon, 26 Oct 2009 20:49:35 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2WVQ-000Gy3-Oh for radiusext@ops.ietf.org; Mon, 26 Oct 2009 20:49:33 +0000 Received: from Thor.local (unknown [74.198.12.3]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 477C1123432F; Mon, 26 Oct 2009 21:49:31 +0100 (CET) Message-ID: <4AE60B58.5080102@deployingradius.com> Date: Mon, 26 Oct 2009 16:49:28 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "dromasca@avaya.com" , "radiusext@ops.ietf.org" Subject: Re: Pending Errata for RADEXT References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > The following errata relate to problems with RFC 4282 which were > uncovered in the IDNAbis effort. While the nature of the problems is > pointed out in the IDNAbis documents which have just completed IETF last > call, the solutions will require substantial revisions to RFC 4282 which > can only be accomplished in a -bis document. Therefore these errata > should probably either be classified as "pending update" or rejected: > > 1848, 1849, 1850 I would suggest "pending update". 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 Oct 26 14:17:04 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 7EDA228C38E for ; Mon, 26 Oct 2009 14:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.821 X-Spam-Level: * X-Spam-Status: No, score=1.821 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, 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 XtYGhJtwXFYe for ; Mon, 26 Oct 2009 14:17:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6293528C376 for ; Mon, 26 Oct 2009 14:17:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2Wtf-000JVw-1J for radiusext-data0@psg.com; Mon, 26 Oct 2009 21:14:35 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2Wtc-000JVd-B5 for radiusext@ops.ietf.org; Mon, 26 Oct 2009 21:14:32 +0000 Received: from Thor.local (unknown [74.198.12.3]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 9AF8B123432F; Mon, 26 Oct 2009 22:14:30 +0100 (CET) Message-ID: <4AE61133.7050203@deployingradius.com> Date: Mon, 26 Oct 2009 17:14:27 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: "'Romascanu, Dan \(Dan\)'" , 'radext mailing list' Subject: Re: [Technical Errata Reported] RFC3162 (1923) References: <048701ca5582$99a97710$ccfc6530$@net> In-Reply-To: <048701ca5582$99a97710$ccfc6530$@net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote: >> RADEXT WG, >> >> Please advise on the Technical Errata below. > > The idea that the formal data type (if any) of a field in a RADIUS attribute > can be changed by changing the name of the field is so bizarre That it could only have been invented by Glen. > as to be > almost unbelievable. Even if it wasn't so incredibly BASIC, the idea is not > supported by any explicit text in any RADIUS-related RFC. RFC 2865 defines "address" as "32 bit value, most significant octet first.". RFC 3162 uses "address" to define a field as "The Address field is 16 octets.". The two statements disagree by the most naive reading of the definitions. The only way to claim that the RFC 3162 "Address" is compatible with the RFC 2865 "Address" is to assert that "4 == 16". But, of course, that would be too obviously delusional. So that isn't the best way to "refute" the errata. Instead, the best way is to completely misconstrue the errata, and claim that the discussion is about something else entirely! If you're trying to maintain a *sane* position, then a 16 octet "address" field is obviously incompatible with the definition of a 4-octet address field. The sane solution would be to: a) create a *new* definition of "ipv6 address" that is different from the 4-octet "address" field for IPv4 addresses,, or b) use the RFC 2865 type "string" for something that doesn't meet the "4 octet" definition of the "address" field. My prediction is that Glen will claim that there is no conflict. This is as much as admitting that he believes "4 == 16". 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 Oct 26 15:11: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 0CEA928C181 for ; Mon, 26 Oct 2009 15:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.733 X-Spam-Level: * X-Spam-Status: No, score=1.733 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, 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 EXtldeEQ9w2m for ; Mon, 26 Oct 2009 15:11:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ED63D28C2C6 for ; Mon, 26 Oct 2009 15:11:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2Xko-000PRy-08 for radiusext-data0@psg.com; Mon, 26 Oct 2009 22:09:30 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2Xkl-000PRe-Hf for radiusext@ops.ietf.org; Mon, 26 Oct 2009 22:09:27 +0000 Received: from Thor.local (unknown [74.198.12.3]) by liberty.deployingradius.com (Postfix) with ESMTPSA id B8939123432F; Mon, 26 Oct 2009 23:09:25 +0100 (CET) Message-ID: <4AE61E13.80906@deployingradius.com> Date: Mon, 26 Oct 2009 18:09:23 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: 'Dave Nelson' , radiusext@ops.ietf.org, 'IESG IESG' Subject: Re: Data Types defined in RFC 2865 References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> <048b01ca5584$591087a0$0b3196e0$@net> <2C5E8C11AE78494CB14CA6C1D32D3B13@NEWTON603> <04d101ca5598$fb1a8690$f14f93b0$@net> In-Reply-To: <04d101ca5598$fb1a8690$f14f93b0$@net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote: > OK, then how do you know the data type of a new attribute? Is the Value > field of the Login-IPv6-Host attribute of type "IPv6 address"? If so, do > _all_ attributes of type "IPv6 address" assign special meaning to the values > 0 & 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF? If not, then it's mot of type "IPv6 > address" is it? We can solve this problem by noting how it was solved in RFC 2865. As Glen keeps pointing out, the RFCs are definitive, and much better than anything anyone can come up with today. RFC 2865 defines an "address" type of 4 octets. This address type is used for NAS-IP-Address, which has no values of special meaning. The *exact same* address type is used for Framed-IP-Address, which *does* have values with special meaning. We can conclude: a) The Elder Gods were wrong: NAS-IP-Address and Framed-IP-Address are really of different types b) the Elder Gods were right: NAS-IP-Address and Framed-IP-Address are of the same type. If (a), then we need to issue an update to RFC 2865, correcting its flaws. (And possibly burning the Elder Gods at the stake for being wrong.) If (b), then we can follow the example of the Elder Gods, and believe that NAS-IPv6-Address, and Login-IPv6-Host are of the same type: IPv6 address. 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 Oct 26 15:52: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 30DDF3A6949 for ; Mon, 26 Oct 2009 15:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.783 X-Spam-Level: * X-Spam-Status: No, score=1.783 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, 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 MR2A8+SnwkKr for ; Mon, 26 Oct 2009 15:52:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 20F603A692E for ; Mon, 26 Oct 2009 15:52:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2YOl-0003PS-Ad for radiusext-data0@psg.com; Mon, 26 Oct 2009 22:50:47 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2YOi-0003PF-47 for radiusext@ops.ietf.org; Mon, 26 Oct 2009 22:50:44 +0000 Received: from Thor.local (unknown [74.198.12.5]) by liberty.deployingradius.com (Postfix) with ESMTPSA id A0ED4123432F; Mon, 26 Oct 2009 23:50:42 +0100 (CET) Message-ID: <4AE627BD.3080202@deployingradius.com> Date: Mon, 26 Oct 2009 18:50:37 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Data Types defined in RFC 2865 References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: ... > Moreover, within the value field of each attribute, RFC 2865 includes the > data type: > > a. "String" for type string. > b. "Address" for type address > c. "Value" for type integer > d. "Text" for type text These are issues of inconsistency and terminology in the RFCs. The RFCs have always used "address" for IPv4 addresses. Pretty much every implementation I've seen uses "ipaddr" as the name of that data type. Similarly with other data types. Where they are simple and often re-used, implementations define names that are *different* from the RFCs. e.g. "ipv6addr", and "ifid" for IPv6 address, and Interface Id. > No attributes of type time are defined in RFC 2865 or 2866. > > Looking at other RADIUS RFCs, the inclusion of the data type within the > value field is less consistent. Which is the source of the current discussion. If the documents had followed the practice of RFC 2865, they could have contained a section describing the data types that they were defining. They failed to do that, so we now have curious claims about addresses being IPv6... and not IPv6, all at the same time. (Depending on which argument best suits the current message, consistency be damned.) > For example, RFC 2867, includes a type of "Lost" in Section 4.2 for > Acct-Tunnel-Packets-Lost (4 octets). It seems likely that this attribute > was intended as type integer, rather than a "lost" data type. The implementations I know of use the type "integer" for this attribute. > In RFC 2869, the term "Value" is used in the value field for attributes that > are not integers (e.g. ARAP-Challenge-Response in Section 5.15). Agreed. > RFC 3162 seems closer to the conventions of RFC 2865 & 2866, although the > "Address" type used is 16 rather than 4 octets in size (IPv6 vs. IPv4). Which is to even the most naive reader, not the same as the "address" field defined in RFC 2865. Hence my recent errata. However, everyone "knows" that the Address type in RFC 3162 refers to IPv6 address. The only disagreement is the message-by-message reasoning of Glen, where it *is* an IPv6 address in one message, and simultaneously *not* a new IPv6 address in another. Personally, it matters less to me whether we call it "Address", or "IPv6 address", or "magic fairy dust". All I want is a consistent definition, so that I can talk about it without someone accusing me of inventing the definition. I would ask for a definition from Glen, but it's clear that his definitions are contradictory. 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 Oct 26 19:19:46 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 510413A6824 for ; Mon, 26 Oct 2009 19:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.815 X-Spam-Level: X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[AWL=-0.378, 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 dFS3EJaGmY8U for ; Mon, 26 Oct 2009 19:19:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 472053A6907 for ; Mon, 26 Oct 2009 19:19:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2bbO-0009Bb-G4 for radiusext-data0@psg.com; Tue, 27 Oct 2009 02:16:02 +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 1N2bbL-0009BO-Q6 for radiusext@ops.ietf.org; Tue, 27 Oct 2009 02:16:00 +0000 Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA03.westchester.pa.mail.comcast.net with comcast id xS4K1c0A40vyq2s53eFzXX; Tue, 27 Oct 2009 02:15:59 +0000 Received: from gwzPC ([124.120.219.221]) by OMTA05.westchester.pa.mail.comcast.net with comcast id xeFh1c00A4nC9zQ3ReFlfp; Tue, 27 Oct 2009 02:15:57 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'Dave Nelson'" , , "'IESG IESG'" References: <048601ca5580$560df2d0$0229d870$@net> <8F84EE704D0F419AB406F5E658B4E37B@NEWTON603> <048f01ca5587$69ecc130$3dc64390$@net> <77AEC2179BCC41458BF54596AFE12794@NEWTON603> <04ca01ca5594$04d3a360$0e7aea20$@net> <4AE60A00.6040209@deployingradius.com> In-Reply-To: <4AE60A00.6040209@deployingradius.com> Subject: RE: Proposed Resolution of Issue #318: REJECT Date: Tue, 27 Oct 2009 09:15:34 +0700 Message-ID: <048001ca56ab$67ead500$37c07f00$@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: AcpWfQitEzqQD5dJR6W/5JAq1a6AJAAKbK6Q Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > ... > >>> In fact I hold the idea in great esteem; what I disvalue is > >>> the idea that data-driven models have to be implementable by > >>> below-average high-school kids. > ... > > If you would be kind enough to read my comment, you will see that I > said > > nothing whatsoever about my colleagues, let alone anything insulting > or > > dismissive. > > Nonsense. In case you had missed the major shift in software of the > last 20 years, many world-class software products are written *without* > a budget. i.e. Open Source projects, among others. Do you ever read what you write? I really wish you would, since the rest of us have to. I didn't say anything about budgets. > > Your comments are insulting to me personally, and to any number of > people whose customers demand something *other* than "what Glen wants". My sincerest apologies to all those customers who demand limited and simplistic designs. I really had no idea. > > > The fact is, however, (as Hannes has also pointed out) that > > the processing model assumed in the Design Guidelines draft is > simplistic > > and limited, if not outright primitive. If you wish to believe that > that > > fact makes the promoters of the model simplistic, limited and > primitive as > > well, that is your choice but I said nothing of the sort. > > Your statement was the equivalent of "have you stopped beating your > wife yet". > > It's insulting, dismissed, and damned well *intended* to be insulting > and dismissive. Thank you for interpreting my intentions for me. > > Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 27 07:21: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 BBAFD3A6A0C for ; Tue, 27 Oct 2009 07:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.841 X-Spam-Level: X-Spam-Status: No, score=0.841 tagged_above=-999 required=5 tests=[AWL=0.717, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_SORBS_WEB=0.619, 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 WD2SYPcd+9Mf for ; Tue, 27 Oct 2009 07:21:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AECDC3A68FB for ; Tue, 27 Oct 2009 07:21:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2msb-0008HP-Tv for radiusext-data0@psg.com; Tue, 27 Oct 2009 14:18:33 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2msZ-0008H4-H1 for radiusext@ops.ietf.org; Tue, 27 Oct 2009 14:18:31 +0000 Received: from Thor.local (unknown [74.198.12.5]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 66BFC123432F; Tue, 27 Oct 2009 15:18:29 +0100 (CET) Message-ID: <4AE70131.9010807@deployingradius.com> Date: Tue, 27 Oct 2009 10:18:25 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: 'Dave Nelson' , radiusext@ops.ietf.org Subject: Re: Proposed Resolution of Issue #318: REJECT References: <048601ca5580$560df2d0$0229d870$@net> <8F84EE704D0F419AB406F5E658B4E37B@NEWTON603> <048f01ca5587$69ecc130$3dc64390$@net> <77AEC2179BCC41458BF54596AFE12794@NEWTON603> <04ca01ca5594$04d3a360$0e7aea20$@net> <4AE60A00.6040209@deployingradius.com> <048001ca56ab$67ead500$37c07f00$@net> In-Reply-To: <048001ca56ab$67ead500$37c07f00$@net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote: > Do you ever read what you write? I really wish you would, since the rest of > us have to. I didn't say anything about budgets. Of course not. The best kind of argument is to make a claim based on insinuation, and then deny that you made any such insinuation. You insulted everyone who made an implementation choice based on limited time and/or money. >> Your comments are insulting to me personally, and to any number of >> people whose customers demand something *other* than "what Glen wants". > > My sincerest apologies to all those customers who demand limited and > simplistic designs. I really had no idea. The reality is that many customers are *happy* with the status of many RADIUS dictionary implementations. Their priorities are *new* features that make business sense for them. Instead of facing that fact, you dismiss the customers as "demanding limited and simplistic designs", and you dismiss the implementors as "below-average high-school kids" for making decisions based on limited time/money budgets. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 27 07:31: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 27B263A6859 for ; Tue, 27 Oct 2009 07:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.346 X-Spam-Level: * X-Spam-Status: No, score=1.346 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, 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 t8m0umPA4A2j for ; Tue, 27 Oct 2009 07:31:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 498883A6783 for ; Tue, 27 Oct 2009 07:31:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2n2d-0009Rf-4E for radiusext-data0@psg.com; Tue, 27 Oct 2009 14:28:55 +0000 Received: from [65.55.111.95] (helo=blu0-omc2-s20.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2n2a-0009RF-U4 for radiusext@ops.ietf.org; Tue, 27 Oct 2009 14:28:53 +0000 Received: from BLU137-W6 ([65.55.111.73]) by blu0-omc2-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 07:28:51 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_0ed70672-20c7-42da-a985-b491fb0b9403_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Alan DeKok CC: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: RE: Proposed Resolution of Issue #318: REJECT Date: Tue, 27 Oct 2009 07:28:52 -0700 Importance: Normal In-Reply-To: <4AE70131.9010807@deployingradius.com> References: <048601ca5580$560df2d0$0229d870$@net> <8F84EE704D0F419AB406F5E658B4E37B@NEWTON603> <048f01ca5587$69ecc130$3dc64390$@net> <77AEC2179BCC41458BF54596AFE12794@NEWTON603> <04ca01ca5594$04d3a360$0e7aea20$@net> <4AE60A00.6040209@deployingradius.com> <048001ca56ab$67ead500$37c07f00$@net> X-OriginalArrivalTime: 27 Oct 2009 14:28:51.0958 (UTC) FILETIME=[CE3C0160:01CA5711] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: <4AE70131.9010807@deployingradius.com> MIME-Version: 1.0 --_0ed70672-20c7-42da-a985-b491fb0b9403_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Instead of facing that fact=2C you dismiss the customers as "demanding > limited and simplistic designs"=2C and you dismiss the implementors as > "below-average high-school kids" for making decisions based on limited > time/money budgets. Indeed. The dictionary has *huge* value to real customers. They *hate* ha= ving to do upgrades just to get support for new attributes. These customer= s aren't stupid=2C or simplistic. = --_0ed70672-20c7-42da-a985-b491fb0b9403_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B Instead of facing that fact=2C you dismiss the customers as "deman= ding
>=3B limited and simplistic designs"=2C and you dismiss the imple= mentors as
>=3B "below-average high-school kids" for making decisions = based on limited
>=3B time/money budgets.

Indeed. =3B The d= ictionary has *huge* value to real customers. =3B They *hate* having to= do upgrades just to get support for new attributes. =3B These customer= s aren't stupid=2C or simplistic.

= --_0ed70672-20c7-42da-a985-b491fb0b9403_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 27 07:35:12 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 17AB228B56A for ; Tue, 27 Oct 2009 07:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.761 X-Spam-Level: X-Spam-Status: No, score=0.761 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_SORBS_WEB=0.619, 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 O-Qt0gchUGg5 for ; Tue, 27 Oct 2009 07:35:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4C79D3A6885 for ; Tue, 27 Oct 2009 07:35:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2n6u-0009y1-OD for radiusext-data0@psg.com; Tue, 27 Oct 2009 14:33:20 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2n6r-0009xg-Tm for radiusext@ops.ietf.org; Tue, 27 Oct 2009 14:33:18 +0000 Received: from Thor.local (unknown [74.198.12.5]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 70349123432F; Tue, 27 Oct 2009 15:33:16 +0100 (CET) Message-ID: <4AE704A4.1080800@deployingradius.com> Date: Tue, 27 Oct 2009 10:33:08 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: 'Bernard Aboba' , radiusext@ops.ietf.org Subject: Re: Proposed Resolution of Issue #320: REJECT References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> <043401ca5527$21188120$63498360$@net> In-Reply-To: <043401ca5527$21188120$63498360$@net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Glen Zorn wrote: > Hmm. The practice of making bald assertions of opinion without basis in > fact seems to be contagious ;-). As many people have noted over the years, > although RFC2865 defines the "address" data type, no attributes are defined > to be of type "address" in that document. This statement is a bald-faced lie. From RFC 2865: ... address 32 bit value, most significant octet first. ... 5.4. NAS-IP-Address ... Address The Address field is four octets. Other attributes use the "Address" type, too. The only way to make your statement true is to claim that the "address" data type define on page 25 is not, in fact, the "Address" data type used in Section 5.4. When you make statements that can be refuted by reading the RFCs, it's as much as admitting that your opinions have no basis in reality. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 27 14:11:55 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 85BA33A680F for ; Tue, 27 Oct 2009 14:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.133 X-Spam-Level: X-Spam-Status: No, score=0.133 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, 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 UN3Vsg1m98yw for ; Tue, 27 Oct 2009 14:11:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 24F763A67AA for ; Tue, 27 Oct 2009 14:11:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2tFV-000NWc-Iz for radiusext-data0@psg.com; Tue, 27 Oct 2009 21:06:37 +0000 Received: from [65.55.116.23] (helo=blu0-omc1-s12.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2tFN-000NW5-So for radiusext@ops.ietf.org; Tue, 27 Oct 2009 21:06:30 +0000 Received: from BLU137-W27 ([65.55.116.8]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 14:06:29 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_430324dc-950c-4e07-9b17-a098a8817343_" X-Originating-IP: [131.107.0.69] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Civility and the RADEXT WG Date: Tue, 27 Oct 2009 14:06:29 -0700 Importance: Normal In-Reply-To: <4AE704A4.1080800@deployingradius.com> References: <008301ca5305$39d5b850$ad8128f0$@net> <4AE0542C.4030909@deployingradius.com> <043401ca5527$21188120$63498360$@net> X-OriginalArrivalTime: 27 Oct 2009 21:06:29.0439 (UTC) FILETIME=[5A66B4F0:01CA5749] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: <4AE704A4.1080800@deployingradius.com> MIME-Version: 1.0 --_430324dc-950c-4e07-9b17-a098a8817343_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Given the tone of recent conversation=2C putting "Civility" and "RADEXT WG"= in the same sentence=2C let alone next to each other=2C may seem incongruo= us.=20 Yet=2C civility within the IETF is an essential ingredient that allows the = organization to continue to function.=20 This does not represent a constraint on the technical arguments that can be= made. If you have an opinion on a technical matter that you'd like to sh= are with WG participants=2C by all means speak up.=20 Personalizing the arguments is where we draw the line. =20 "I disagree with your line of reasoning because..." is fundamentally diffe= rent from "If you don't agree with me=2C you are a moron."=20 The former is acceptable behavior among WG participants. The latter is not= .=20 To quote from Wikipedia: "Incivility consists of personal attacks=2C rudeness=2C and aggressive beha= viours that disrupt the project and lead to unproductive stress and conflic= t... a few=2C minor=2C isolated incidents of incivility are not in themselv= es a major concern. A behavioral pattern of incivility is disruptive and unacceptable... if it rises to the level of harassment or egregious person= al attacks. A single act of incivility can also cross the line if it is sev= ere enough: for instance=2C extreme verbal abuse or profanity directed at a= nother contributor=2C or a threat against another person... In general=2C be understanding and non-retaliatory in dealing with incivili= ty. If others are uncivil=2C be understanding (people do say things when they get upset) rather than judgemental=2C and do not respond in kind. If necessary=2C point out gently that you think the comment might be considered uncivil=2C and make it clear that you want to move on and focus on the content issue. Bear in mind that... standards vary. Consider t= oo the option of ignoring isolated examples of incivility=2C and simply moving forward ... O= nly take things to dispute resolution (see below) if there is an ongoing pr= oblem you can't resolve. This policy is not a weapon to use against other contributors." = --_430324dc-950c-4e07-9b17-a098a8817343_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Given the tone of recent conversation=2C putting "Civility" and "RADEXT WG"= in the same sentence=2C let alone next to each other=2C may seem incongruo= us.

Yet=2C civility within the IETF is an essential ingredient that= allows the organization to continue to function.

This does not rep= resent a constraint on the technical arguments that can be made. =3B&nb= sp=3B If you have an opinion on a technical matter that you'd like to share= with WG participants=2C by all means speak up.

Personalizing the a= rguments is where we draw the line. =3B

"I disagree with your l= ine of reasoning because..." =3B is fundamentally different from "If yo= u don't agree with me=2C you are a moron."

The former is acceptable= behavior among WG participants. =3B The latter is not.

To quot= e from Wikipedia:

"Incivility consists of personal attacks=2C rudeness=2C and aggre= ssive behaviours that disrupt the project and lead to unproductive stress a= nd conflict... a few=2C minor=2C isolated incidents of incivility are not i= n themselves a major concern. A behavioral pattern of incivility is disruptive and unacceptable... =3B if it rises to the level of haras= sment or egregious personal attacks= . A single act of incivility can also cross the line if it is severe en= ough: for instance=2C extreme verbal abuse or profanity directed at a= nother contributor=2C or a threat against another person...

In gener= al=2C be understanding and non-retaliatory in dealing with incivility. If others are uncivil=2C be understanding (people do say things when they get upset) rather than judgemental=2C and do not respond in kind. If necessary=2C point out gently that you think the comment might be considered uncivil=2C and make it clear that you want to move on and focus on the content issue. Bear in mind that... standards vary. Consider t= oo the option of ignoring isolated examples of incivility=2C and simply moving forward ... O= nly take things to dispute= resolution (see below) if there is an ongoing problem you can't resolv= e.
This policy is not a weapon to use against other contributors."


=


= --_430324dc-950c-4e07-9b17-a098a8817343_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 27 15:31:19 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 7568E3A696C for ; Tue, 27 Oct 2009 15:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.57 X-Spam-Level: * X-Spam-Status: No, score=1.57 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, 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 qs6SBYToRMXV for ; Tue, 27 Oct 2009 15:31:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23B2A3A6873 for ; Tue, 27 Oct 2009 15:31:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2uWo-0003uk-9I for radiusext-data0@psg.com; Tue, 27 Oct 2009 22:28:34 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2uWl-0003uN-Ec for radiusext@ops.ietf.org; Tue, 27 Oct 2009 22:28:31 +0000 Received: from Thor.local (unknown [74.198.12.4]) by liberty.deployingradius.com (Postfix) with ESMTPSA id C0BED123432F for ; Tue, 27 Oct 2009 23:28:29 +0100 (CET) Message-ID: <4AE77409.7050905@deployingradius.com> Date: Tue, 27 Oct 2009 18:28:25 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: 'radext mailing list' Subject: Inconsistencies between RFCs and implementations X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: As has been noted recently, RADIUS implementations are largely inconsistent with the RFCs. To summarize: RFC 2865 defines an "address" data type for IPv4 addresses. Going back to the original Livingston server, pretty much every implementation calls this data type "ipv4addr". Even within RFC 2865, the upper-case "Address" name is used to define attributes, instead of using the "address" name given earlier in the document. RFC 3162 uses the "Address" data type for IPv6 address. This contradicts the definition of "address" in RFC 2865. Most implementations have chose to resolve the ambiguity by calling this data type "ipv6addr". RFC 3162 uses the name "Interface-Id" to describe interface Id's. This data type (if it is a data type) is not otherwise described anywhere in that document. Many implementations have chosen to resolve the ambiguity by calling this data type "ifid". RFC 2867 uses the name "Lost" to describe the data type of Acct-Tunnel-Packets-Lost. This data type (if it is a data type) is not otherwise described anywhere in that document. Many implementations have chosen to resolve the ambiguity by defining the attribute as an "integer" data type. RFC 2058 and RFC 2138 did not differentiate between textual and binary data. This clarification was made in RFC 2865, by creating the "text" type. Some implementations made this clarification prior to RFC 2865 being published, and may not have chosen the same names. RFC 2868 defines "tags". However, for non-integer attributes, the type "String" is used, rather than "text", even when the data is clearly meant to be textual (e.g. Tunnel-Server-Endpoint). Some implementations have chosen to arbitrarily classify these attributes using the RFC 2865 definitions "text" and "string", independent of the RFC 2868 definitions. Some implementations have instead created new data types such as "tagged-string", and "tagged-integer". These inconsistencies and ambiguities were not addressed in RFC 5080 (Issues and fixes). That document would arguably have been a good place to resolve these issues. The fact that the implementations disagree so clearly with the RFCs, and so consistently with the RFCs, show that there are major ambiguities that need to be resolved. Either the RFCs are wrong, or the implementations are wrong. They can't both be correct. The goal of the guidelines document is to clarify these issues, as part of recommending best practices for RADIUS specifications. However, it would seem that updating a RADIUS data model would be inappropriate for a BCP document. As such, I suggest splitting the document into two. One will define the RADIUS data model, be standards track, and explicitly update the previous RFCs to clarify the above contradictions. The other will be the remainder of the guidelines document, which gives only guidelines. The "data model" document will define the RADIUS data model. It will give names and definitions for RADIUS data types, in line with the names and definitions given in RFC 2865. It will define *new* types, where this WG believes that existing types are contradictory or inadequate. It will contain a detailed review of each and every RADIUS attribute defined in any specification. It will specify the new types for each attribute. This document will take 3-4 years to finish, of course. We will likely have to delay the design guidelines document, as it will use the data model document as a normative reference. Or, we can perform minor updates to the existing guidelines document (e.g. replacing integer64 with interface-id), and publish it. If the WG decides to split the guidelines document, then I would suggest finding another editor for the data type document. I am willing to finish the guidelines document, but it may be best if I avoided the data type 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 Tue Oct 27 20:50: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 AC11D3A68C6 for ; Tue, 27 Oct 2009 20:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 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 IMPoDg110jAm for ; Tue, 27 Oct 2009 20:50:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 284173A66B4 for ; Tue, 27 Oct 2009 20:50:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2zSa-0006KI-IQ for radiusext-data0@psg.com; Wed, 28 Oct 2009 03:44:32 +0000 Received: from [65.55.111.94] (helo=blu0-omc2-s19.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2zSY-0006J6-Dr for radiusext@ops.ietf.org; Wed, 28 Oct 2009 03:44:30 +0000 Received: from BLU137-DS5 ([65.55.111.73]) by blu0-omc2-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 20:44:29 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Alan DeKok'" , "'radext mailing list'" References: <4AE77409.7050905@deployingradius.com> In-Reply-To: <4AE77409.7050905@deployingradius.com> Subject: RE: Inconsistencies between RFCs and implementations Date: Tue, 27 Oct 2009 20:44:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpXVUqqyFRdlmV0R66WuO50a/NukgAJ1WHg Content-Language: en-us X-OriginalArrivalTime: 28 Oct 2009 03:44:29.0601 (UTC) FILETIME=[F4164110:01CA5780] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Alan DeKok said: " As has been noted recently, RADIUS implementations are largely inconsistent with the RFCs." [BA] Actually, I think that it would be more accurate to say that RADIUS RFCs after RFC 2865-2869 did not consistently utilize the same conventions to describe data typing, namely to include the data type in the value field. " RFC 2865 defines an "address" data type for IPv4 addresses. Going back to the original Livingston server, pretty much every implementation calls this data type "ipv4addr". Even within RFC 2865, the upper-case "Address" name is used to define attributes, instead of using the "address" name given earlier in the document. RFC 3162 uses the "Address" data type for IPv6 address. This contradicts the definition of "address" in RFC 2865. Most implementations have chose to resolve the ambiguity by calling this data type "ipv6addr"." [BA] Neither of these cases seems particularly difficult. " RFC 3162 uses the name "Interface-Id" to describe interface Id's. This data type (if it is a data type) is not otherwise described anywhere in that document. Many implementations have chosen to resolve the ambiguity by calling this data type "ifid". [BA] I could see Interface-ID being implemented as a special type (if IPv6 address notation were used), or alternatively as an octet string. However, I do agree with Glen that integer64 is unlikely. " RFC 2867 uses the name "Lost" to describe the data type of Acct-Tunnel-Packets-Lost. This data type (if it is a data type) is not otherwise described anywhere in that document. Many implementations have chosen to resolve the ambiguity by defining the attribute as an "integer" data type." [BA] That seems reasonable to me. The value in question is in fact an unsigned number of 32-bits. RFC 2868 defines "tags". However, for non-integer attributes, the type "String" is used, rather than "text", even when the data is clearly meant to be textual (e.g. Tunnel-Server-Endpoint). Some implementations have chosen to arbitrarily classify these attributes using the RFC 2865 definitions "text" and "string", independent of the RFC 2868 definitions. Some implementations have instead created new data types such as "tagged-string", and "tagged-integer". [BA] Either way, the RFC 2868 tagging scheme is what it is, and this is now widely implemented. " The goal of the guidelines document is to clarify these issues, as part of recommending best practices for RADIUS specifications. However, it would seem that updating a RADIUS data model would be inappropriate for a BCP document." [BA] The goal of the guidelines document is just to provide guidelines for RADIUS attribute design. Early on, WG consensus was that the document should not advocate major changes in existing practice, but merely describe what has been done in the past. As long as the description of past practice is accurate and the guidelines are sensible and representative of WG consensus, then the guidelines document has done its job. It is not necessary for the guidelines document to address every potential inconsistency in the RADIUS specifications. For example, in situations where a reasonable person might interpret the documents differently, it is acceptable to point out the ambiguity and leave it at that. " As such, I suggest splitting the document into two. One will define the RADIUS data model, be standards track, and explicitly update the previous RFCs to clarify the above contradictions. The other will be the remainder of the guidelines document, which gives only guidelines." [BA] Since the guidelines document is just a BCP, it shouldn't be updating existing standards. So when you say the "remainder of the guidelines document" this makes me wonder what part of the guidelines document lies outside the appropriate role of a BCP. "It will define *new* types, where this WG believes that existing types are contradictory or inadequate." [BA] During prior WG discussion, there was a general aversion to a large scale remake of the RADIUS data model (e.g. attempts to converge the model with Diameter). However, the addition of some modest enhancements might be within the scope of the Extended Attributes document. "It will contain a detailed review of each and every RADIUS attribute defined in any specification. It will specify the new types for each attribute." [BA] As you have noted, in many cases implementers have come to the same conclusion about the data types intended for use with attributes. There are a few isolated cases (which we have been discussing) where implementations may differ, but I'm not sure that this is widespread enough to justify such a major effort. " Or, we can perform minor updates to the existing guidelines document (e.g. replacing integer64 with interface-id), and publish it." [BA] My preference would be for minor updates, with the goal of addressing the outstanding issues. Where the specifications are genuinely ambiguous about the types being defined, the document can state that, but can leave resolution to the future. Assuming we restrict additional work to that scope, what remaining changes do we need to make? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 27 22:07:06 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 C02633A69E9 for ; Tue, 27 Oct 2009 22:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.157 X-Spam-Level: X-Spam-Status: No, score=-0.157 tagged_above=-999 required=5 tests=[AWL=0.337, 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 NVlFmABk-vGj for ; Tue, 27 Oct 2009 22:07:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B2843A6A11 for ; Tue, 27 Oct 2009 22:07:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N30h5-0009UO-7D for radiusext-data0@psg.com; Wed, 28 Oct 2009 05:03:35 +0000 Received: from [65.55.116.17] (helo=blu0-omc1-s6.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N30gy-0009Rj-Tu for radiusext@ops.ietf.org; Wed, 28 Oct 2009 05:03:29 +0000 Received: from BLU137-W28 ([65.55.116.7]) by blu0-omc1-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 22:03:28 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_73755604-6d67-4681-8c73-fde910139b2b_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Appendix A Revisions required for consistency with proposed Issue 319 resolution Date: Tue, 27 Oct 2009 22:03:28 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 28 Oct 2009 05:03:28.0764 (UTC) FILETIME=[FCD923C0:01CA578B] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_73755604-6d67-4681-8c73-fde910139b2b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In looking through Appendix A=2C there are some sections that are inconsist= ent with the revisions proposed in Issue 319: * Section A.1.1 refers to the integer64 data type=2C and does not include m= ention the potential Interface-Id type.=20 Does the data fit within the existing RADIUS data model=2C as outlined below? =20 could be clarified by changing it to: =20 Does the data fit within the basic data types described in Section 2.1.1= =2C as outlined below?=20 * Section A.2 says: All data types other than the ones described above in Appendix A.1 SHOULD NOT be used. This section describes in detail a number of data types that are NOT RECOMMENDED in new RADIUS specifications. Where possible=2C replacement data types are suggested. To make it clear that existing complex types are not being deprecated=2C th= e text might be changed to say "described in Appendix A.1 and Appendix B" * Section A.2.1 mentions integer64 data types. =20 * The advice on authentication security attributes needs to be sync'd up wi= th the new proposed text.=20 * The advice on a 16-bit type field is inconsistent with the recently revis= ed text.=20 * Section A.2.2 might say "define a complex type not described in Appendix = B which..." = --_73755604-6d67-4681-8c73-fde910139b2b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In looking through Appendix A=2C there are some sections that are inconsist= ent with the revisions proposed in Issue 319:

* Section A.1.1 refers= to the integer64 data type=2C and does not include mention the potential I= nterface-Id type. 
   Does the data fit within th=
e existing RADIUS data model=2C as outlined
   below?  

could be =
clarified by changing it to:
   
   Does the data fit within the basi=
c data types described in Section 2.1.1=2C
   as outlined below? 
* Section A.2 says:

   All data types other than the ones described=
 above in Appendix A.1
   SHOULD NOT be used.  This section des=
cribes in detail a number of
   data types that are NOT RECOMMENDED in n=
ew RADIUS specifications.
   Where possible=2C replacement data types ar=
e suggested.

To make it clear that existing complex types are not be=
ing deprecated=2C the text might be changed to say "described in Appendix A=
.1 and Appendix B"


* Section A.2.1 mentions integer64 data types=
.   

* The advice on authentication security attributes needs to be =
sync'd up with the new proposed text. 

* The advice on a 16-bit type=
 field is inconsistent with the recently revised text. 

* Section A.=
2.2 might say "define a complex type not described in Appendix B which..."<=
br>









= --_73755604-6d67-4681-8c73-fde910139b2b_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Oct 27 22:11: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 1BF803A6852 for ; Tue, 27 Oct 2009 22:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.165 X-Spam-Level: X-Spam-Status: No, score=-0.165 tagged_above=-999 required=5 tests=[AWL=0.329, 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 0+E4U9lkv3cj for ; Tue, 27 Oct 2009 22:11:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 12C803A69F7 for ; Tue, 27 Oct 2009 22:11:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N30mQ-000Be3-2u for radiusext-data0@psg.com; Wed, 28 Oct 2009 05:09:06 +0000 Received: from [65.55.116.42] (helo=blu0-omc1-s31.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N30mN-000BcT-Ju for radiusext@ops.ietf.org; Wed, 28 Oct 2009 05:09:03 +0000 Received: from BLU137-DS3 ([65.55.116.7]) by blu0-omc1-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 22:09:02 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'radext mailing list'" Subject: Revised Resolution to Issue 319 Date: Tue, 27 Oct 2009 22:09:05 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0148_01CA5752.198AEBF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpXiKUKth96wIkkTuCJkzobOU4biwAA/nKA Content-Language: en-us X-OriginalArrivalTime: 28 Oct 2009 05:09:02.0832 (UTC) FILETIME=[C3F7DF00:01CA578C] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0148_01CA5752.198AEBF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In looking at the text of Sections 2 and 2.1.1, I would propose to make the following changes in Section 2 and 2.1.1 to resolve Issue 319. Required changes in Appendix A will following in a separate post. 2. RADIUS Data Model The Remote Authentication Dial In User Service (RADIUS) defined in [RFC2865 ] and [RFC2866 ] uses elements known as attributes in order to represent authentication, authorization and accounting data. Unlike SNMP, first defined in [RFC1157 ] and [RFC1155 ], RADIUS does not define a formal data definition language. The data type of RADIUS attributes is not transported on the wire. Rather, the data type of a RADIUS attribute is fixed when that attribute is defined. Based on the RADIUS attribute type code, RADIUS clients and servers can determine the data type based on pre- configured entries within a data dictionary. Two distinct attribute spaces are defined: the standard space, and a Vendor-Specific space. Attributes in the standard space generally are composed of a type, length, value (TLV) triplet, although complex attributes have also been defined. The Vendor-Specific space is encapsulated within a single attribute type (Vendor-Specific Attribute). The format of this space is defined by individual vendors, but the same TLV encoding used by the standard space is recommended in [RFC2865] Section 5.26. The similarity between attribute formats has enabled implementations to leverage common parsing functionality, although in some cases the attributes in the Vendor-Specific space have begun to diverge from the common format. 2.1.1. Basic Data Types defined in RFC 2865 [RFC2865] and [RFC2866] utilize data types defined in [RFC2865] Section 5, which states the following: The format of the value field is one of five data types. Note that type "text" is a subset of type "string". text 1-253 octets containing UTF-8 encoded 10646 [RFC3629 ] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead. string 1-253 octets containing binary data (values 0 through 255 decimal, inclusive). Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. address 32 bit value, most significant octet first. integer 32 bit unsigned value, most significant octet first. time 32 bit unsigned value, most significant octet first -- seconds since 00:00:00 UTC, January 1, 1970. The standard Attributes do not use this data type but it is presented here for possible use in future attributes. In addition to the data types defined in [RFC2865], subsequent RADIUS specifications defined attributes using additional basic data types. Since these specifications did not explicitly define new data types as was done in [RFC2865], nor did they consistently indicate the format of the value field using the same conventions as [RFC2865], in some cases the intended data type is ambiguous and may not be consistent among different implementations. It is out of the scope of this document to resolve all potential ambiguities within existing RADIUS specifications. However in order to prevent future ambiguities, it is recommended that future RADIUS attribute specifications explicitly define newly created data types at the beginning of the document, and indicate clearly the data type to be used for each attribute. [RFC3162] utilizes but does not explicitly define the following data types: IPv6 address 128 bit value, in network byte order. IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 128 bits of value, in network byte order. Examples of the IPv6 address type include NAS-IPv6-Address defined in [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, and in [RFC4818] Section 3. While the Framed-Interface-Id attribute defined in [RFC3162] Section 2.2 included a value field of 8 octets, the data type was not explicitly indicated, and therefore there is controversy over whether the format of this attribute was intended to be an 8 octet String or whether a special Interface-Id type was intended. Given that attributes of type IPv6 address and IPv6 prefix are already in use, it is RECOMMENDED that RADIUS server implementations include support for these additional basic types, in addition to the types defined in [RFC2865 ]. Where the intent is to represent a specific IPv6 address, the IPv6 address type SHOULD be used. Although it is possible to use the IPv6 IPv6 Prefix type with a prefix length of 128 to represent an IPv6 address, this usage is NOT RECOMMENDED. Implementations supporting the Framed-Interface-Id attribute may select a data type of their choosing (most likely an 8 octet String or a special Interface-Id data type). It is worth noting that since RADIUS only supports unsigned integers of 32 bits, attributes using signed integer data types or unsigned integer types of other sizes will require code changes, and SHOULD be avoided. For [RFC2865 ] RADIUS VSAs, the length limitation of the String and Text types is 247 octets instead of 253 octets, due to the additional overhead of the Vendor-Specific Attribute. ------=_NextPart_000_0148_01CA5752.198AEBF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In looking at the text = of Sections 2 and 2.1.1, I would propose to make the following changes in Section 2 = and 2.1.1 to resolve Issue 319.

Required changes in = Appendix A will following in a separate post.

 

2.  RADIUS Data = Model

 
 
  =
 The Remote Authentication Dial In User Service (RADIUS) defined =
in
   [RFC2865] and [RFC2866] uses elements known as attributes in =
order to
   represent authentication, =
authorization and accounting =
data.
 
   =
Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS =
does
   not define a formal data =
definition language.  
   The =
data type of RADIUS attributes is not transported on the =
wire.
   Rather, the data type of a =
RADIUS attribute is fixed when that
  =
 attribute is defined.  Based on the RADIUS attribute type =
code,
   RADIUS clients and servers can =
determine the data type based on pre-
   =
configured entries within a data =
dictionary.
 
  =
 Two distinct attribute spaces are defined: the standard space, and =
a
   Vendor-Specific space.  =
Attributes in the standard space =
generally
   are composed of a type, =
length, value (TLV) triplet, although =
complex
   attributes have also been =
defined.  The Vendor-Specific space =
is
   encapsulated within a single =
attribute type (Vendor-Specific
   =
Attribute).  The format of this space is defined by =
individual
   vendors, but the same TLV =
encoding used by the standard space is
   =
recommended in [RFC2865] =
Section 5.26.  The similarity =
between
   attribute formats has enabled =
implementations to leverage common
   =
parsing functionality, although in some cases the attributes in =
the
   Vendor-Specific space have begun =
to diverge from the common format.

2.1.1.  Basic Data Types defined in = RFC 2865

   [RFC2865] =
and [RFC2866] utilize data types defined in [RFC2865] =

   Section 5, which states the =
following:
 
  &=
nbsp;   The format of the value field is one of five data =
types.  Note
      =
that type "text" is a subset of type =
"string".
 
&nbs=
p;     text      1-253 =
octets containing UTF-8 encoded 10646 [RFC3629]
    &n=
bsp;           =
characters.  Text of length zero (0) MUST NOT be =
sent;
       &nbs=
p;        omit the entire attribute =
instead.
 
  &nb=
sp;   string    1-253 octets containing binary =
data (values 0 =
through
       &n=
bsp;        255 decimal, =
inclusive).  Strings of length zero =
(0)
        =
        MUST NOT be sent; omit the =
entire attribute =
instead.
 
  &nb=
sp;   address   32 bit value, most significant octet =
first.
 
   =
;   integer   32 bit unsigned value, most =
significant octet =
first.
 
   =
;   time      32 bit unsigned value, =
most significant octet first =
--
        &=
nbsp;       seconds since 00:00:00 UTC, =
January 1, 1970.  =
The
        =
        standard Attributes do not =
use this data type but it =
is
        &=
nbsp;       presented here for possible =
use in future =
attributes.
 
  =
 In addition to the data types defined in [RFC2865], subsequent RADIUS =

   specifications defined =
attributes using additional basic data types.  =
Since
   these specifications did not =
explicitly define new data types as =
was
   done in [RFC2865], nor did they =
consistently indicate the format of the =
value
   field using the same conventions =
as [RFC2865], in some cases the =
intended
   data type is ambiguous and =
may not be consistent among different
   =
implementations.  =

 
   It is out =
of the scope of this document to resolve all potential ambiguities =

   within existing RADIUS =
specifications.  However in order to prevent =
future
   ambiguities, it is recommended =
that future RADIUS attribute specifications =

   explicitly define newly created =
data types at the beginning of the document, =

   and indicate clearly the data =
type to be used for each attribute. =

 
   [RFC3162] =
utilizes but does not explicitly define the following data types: =

 
   IPv6 =
address   128 bit value, in network byte =
order.
   IPv6 prefix    8 =
bits of reserved, 8 bits of prefix length, up =
to
        &=
nbsp;         128 bits of value, =
in network byte =
order.
 
   =
Examples of the IPv6 address type include NAS-IPv6-Address defined =
in
   [RFC3162] =
Section 2.1 and Login-IPv6-Host defined in [RFC3162]
   =
Section 2.4.  The IPv6 prefix type is used in [RFC3162] =
Section 2.3,
   and in [RFC4818] =
Section 3. =

 
   While the =
Framed-Interface-Id attribute defined in [RFC3162] Section =
2.2
   included a value field of 8 =
octets, the data type was not =
explicitly
   indicated, and therefore =
there is controversy over whether the =
format
   of this attribute was intended =
to be an 8 octet String or whether a
   =
special Interface-Id type was intended. =
 
 
   =
Given that attributes of type IPv6 address and IPv6 prefix are =
already
   in use, it is RECOMMENDED that =
RADIUS server implementations include support for =

   these additional basic types, in =
addition to the types defined in [RFC2865].
   Where =
the intent is to represent a specific IPv6 address, the =
IPv6
   address type SHOULD be =
used.  Although it is possible to use the =
IPv6
   IPv6 Prefix type with a prefix =
length of 128 to represent an IPv6
   =
address, this usage is NOT RECOMMENDED.  Implementations =
supporting
   the Framed-Interface-Id =
attribute may select a data type of =
their
   choosing (most likely an 8 octet =
String or a special Interface-Id =

   data type). =
 
 
   It =
is worth noting that since RADIUS only supports unsigned =
integers
   of 32 bits, attributes using =
signed integer data types or
   unsigned =
integer types of other sizes will require code changes, =
and
   SHOULD be =
avoided.
 
   =
For [RFC2865] RADIUS VSAs, the length limitation of =
the String and
   Text types is 247 =
octets instead of 253 octets, due to the =
additional
   overhead of the =
Vendor-Specific Attribute.

 

------=_NextPart_000_0148_01CA5752.198AEBF0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Oct 28 03:32:31 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 929443A67B6 for ; Wed, 28 Oct 2009 03:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.385 X-Spam-Level: X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[AWL=-0.890, 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 g9bElcg5+Dc7 for ; Wed, 28 Oct 2009 03:32:30 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E190028C0DF for ; Wed, 28 Oct 2009 03:32:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N35j0-00024k-TI for radiusext-data0@psg.com; Wed, 28 Oct 2009 10:25:54 +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 1N35iR-0001pY-8r for radiusext@ops.ietf.org; Wed, 28 Oct 2009 10:25:19 +0000 X-IronPort-AV: E=Sophos;i="4.44,639,1249272000"; d="scan'208";a="178415878" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 28 Oct 2009 06:25:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Oct 2009 06:25:10 -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: FW: WG Review: Recharter of Handover Keying (hokey) Date: Wed, 28 Oct 2009 11:24:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Handover Keying (hokey) Thread-Index: AcpXSI4gdwuwlXVZRzCWaWO5/ULIAgAcD0kQ From: "Romascanu, Dan (Dan)" To: , , , , , Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, October 27, 2009 11:00 PM To: new-work@ietf.org Subject: WG Review: Recharter of Handover Keying (hokey)=20 A modified charter has been submitted for the Handover Keying (hokey) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, November 3, 2009. Handover Keying (hokey) ------------------------ Last Modified: 2009-10-19 Chair(s): Glen Zorn Tina Tsou (Ting ZOU) =20 Security Area Director(s): Tim Polk Pasi Eronen =20 Security Area Advisor: Tim Polk =20 Mailing Lists: General Discussion: hokey@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hokey Archive: http://www.ietf.org/mail-archive/web/hokey/current/maillist.html Description of Working Group: A mobile device has to re-authenticate each time it changes its point of attachment to the network. When it goes through the full procedure of authentication it creates a series of ruptures, during which the medium cannot flow. This results in a poor user experience during handover. However, it is possible to shorten the time it takes to re-authenticate by reusing the key information developed during the initial authentication. The Handover Keying Working Group is concerned with developing procedures for key reuse and delivery, while respecting good security practice. The Handover Keying Working Group has already done work on this subject, but it has not yet developed the complete set of procedures, protocols, and changes needed for different security environment scenarios and situations. The solutions specified by the HOKEY WG fall into several categories, based on timing and mechanism. The authentication and key management may occur before handoff, when latency is much less critical. Alternatively, authentication and key management can occur as part of the handoff, where latency is critical. Solutions should reduce or eliminate the number of referrals to AAA servers, and solutions should avoid re-executing lengthy EAP method exchanges. This may be accomplished by providing new mechanisms for cryptographic keying material in combination with a protocol for the timely delivery of appropriate keys to the appropriate entities. Solutions are expected to include "handover keying," "low-latency re-authentication," and "pre-authentication" or "early authentication". All solution categories are useful, each supporting different scenarios. The HOKEY WG may provide multiple solutions, each addressing a different scenario. Solutions specified by the HOKEY WG must: 1) Be responsive to handover and re-authentication latency performance objectives within a mobile wireless access network. 2) Fulfill the requirements in RFC 4962 and RFC 5247. 3) Be independent of the access-technology. Any key hierarchy topology or protocol defined must be independent of EAP lower layers. The protocols may require additional support from the EAP lower layers that use it. 4) Accommodate inter-technology heterogeneous handover and roaming. 5) Not require changes to EAP methods. Any extensions defined to EAP must not cause changes to existing EAP methods. In specifying an access-technology-independent solution, media independent guidelines for SDOs may also be needed to explain how the keying material and signaling can be employed in a specific access technology. HOKEY WG Deliverables =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) A specification of Local Domain Name Discovery for ERP. Currently the use of DHCP mechanisms to request the local domain name is unspecified. There are other useful scenarios that need to be addressed. Lower layer announcement for local domain name is unspecified. Ambiguity with using initial full EAP exchange for re-authentication needs to be clarified. Additional re-authentication scenarios, for which there is interest, need to be addressed. 2) A specification of Early Authentication solutions. These include use of EAP to pre-establish authenticated keying material on a target authenticator prior to arrival of the peer. 3) A specification for a Hokey architecture Document. It includes deployment of ERP and EAP early authentication protocol in the mobile environment. There are various useful scenarios that need to be addressed. This specification and the revision of RFC5296 should be conducted in parallel. 4) Assistance to the 802.21a group in specifying the integration of EAP pre-authentication with IEEE 802.21a. The Hokey Working Group shall perform tasks that are complementary to and do not duplicate work being done in IEEE 802.21a. 6) A specification for NAS-Authenticator interaction. NAS interaction can be used to release resources in the old NAS and achieve faster initiation of authentication. Related work in external SDOs on authenticator/NAS interaction for re-authentication may be taken into consideration. 7) A revision of RFC 5296 to eliminate unnecessary references to the home server. 8) Assistance to the radext and dime Working Groups in developing AAA support for handoff keying. Goals and Milestones: Nov 2009 First draft on Local Domain Name Discovery for ERP Nov 2009 First draft on Early Authentication solutions Mar 2010 First draft on Hokey architecture Mar 2010 First draft on NAS-Authenticator Interaction Jul 2010 First draft on revision of RFC 5296 Mar 2011 Submit the Local Domain Name Discovery for ERP draft to IESG Mar 2011 Submit the Early Authentication solutions draft to IESG Jul 2011 Submit the NAS-Authenticator Interaction draft to IESG Nov 2011 Submit the Hokey architecture draft to IESG Nov 2011 Submit the revision of RFC 5296 to IESG Mar 2012 Re-charter or shut down WG -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Oct 28 06:59:04 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 741D23A68A7 for ; Wed, 28 Oct 2009 06:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.61 X-Spam-Level: * X-Spam-Status: No, score=1.61 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, 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 cl3ssoi7eIjn for ; Wed, 28 Oct 2009 06:59:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8AD423A6782 for ; Wed, 28 Oct 2009 06:59:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N38zF-0005LG-TA for radiusext-data0@psg.com; Wed, 28 Oct 2009 13:54:53 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N38zD-0005Ji-0o for radiusext@ops.ietf.org; Wed, 28 Oct 2009 13:54:51 +0000 Received: from Thor.local (unknown [74.198.12.3]) by liberty.deployingradius.com (Postfix) with ESMTPSA id F3B57123432F; Wed, 28 Oct 2009 14:54:48 +0100 (CET) Message-ID: <4AE84D23.5030301@deployingradius.com> Date: Wed, 28 Oct 2009 09:54:43 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: 'radext mailing list' Subject: Re: Inconsistencies between RFCs and implementations References: <4AE77409.7050905@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > [BA] Since the guidelines document is just a BCP, it shouldn't be > updating existing standards. So when you say the "remainder of the > guidelines document" this makes me wonder what part of the guidelines > document lies outside the appropriate role of a BCP. Creating a RADIUS data model could arguably be outside of the role of a BCP. However, pointing out that one exists would likely be within the role of a BCP. > [BA] During prior WG discussion, there was a general aversion to a large > scale remake of the RADIUS data model (e.g. attempts to converge the model > with Diameter). However, the addition of some modest enhancements might > be within the scope of the Extended Attributes document. I would suggest codifying the data model, rather than remaking it. The data model has already largely been codified in the implementations. If these are wrong, then we could say that no RADIUS implementations exist. If they are right, then documenting what the implementations have done would remake nothing. > [BA] My preference would be for minor updates, with the goal of > addressing the outstanding issues. Where the specifications are > genuinely ambiguous about the types being defined, the document can > state that, but can leave resolution to the future. > > Assuming we restrict additional work to that scope, what remaining > changes do we need to make? We need to change integer64 -> ifid, or something similar. We need to achieve WG consensus that the current document reflects current practice, and that the current practice is acceptable. I suggest also adding a sentence or two describing the implicit versus explicit nature of the RADIUS data model, and the failure of RFC 3162 et. al. to follow the "data type definition" framework shown in RFC 2865. 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 Fri Oct 30 11:24:21 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 0BD6A3A6808 for ; Fri, 30 Oct 2009 11:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0B0Zbaf3Bir for ; Fri, 30 Oct 2009 11:24:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C5B413A6872 for ; Fri, 30 Oct 2009 11:24:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3w5F-000K81-JN for radiusext-data0@psg.com; Fri, 30 Oct 2009 18:20:21 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3w54-000K2S-Hb for radiusext@ops.ietf.org; Fri, 30 Oct 2009 18:20:10 +0000 Message-ID: <4AEB2E57.7040007@deployingradius.com> Date: Fri, 30 Oct 2009 14:20:07 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: 'radext mailing list' Subject: Re: Revised Resolution to Issue 319 References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > In looking at the text of Sections 2 and 2.1.1, I would propose to make > the following changes in Section 2 and 2.1.1 to resolve Issue 319. > > Required changes in Appendix A will following in a separate post. I've re-worked both Section 2 and Appendix A to address these concerns. A proposed version is available online at: http://git.freeradius.org/draft-ietf-radext-design-10.txt 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 Fri Oct 30 12:20:45 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 20CED3A68D5 for ; Fri, 30 Oct 2009 12:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.173 X-Spam-Level: X-Spam-Status: No, score=-0.173 tagged_above=-999 required=5 tests=[AWL=0.322, 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 OHAdnOZ9gGoR for ; Fri, 30 Oct 2009 12:20:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 083973A6842 for ; Fri, 30 Oct 2009 12:20:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3wy1-000Jqh-On for radiusext-data0@psg.com; Fri, 30 Oct 2009 19:16:57 +0000 Received: from [65.55.111.89] (helo=blu0-omc2-s14.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3wxz-000Jpp-Js for radiusext@ops.ietf.org; Fri, 30 Oct 2009 19:16:55 +0000 Received: from BLU137-DS7 ([65.55.111.72]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 12:16:54 -0700 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Alan DeKok'" CC: "'radext mailing list'" References: <4AEB2E57.7040007@deployingradius.com> In-Reply-To: <4AEB2E57.7040007@deployingradius.com> Subject: RE: Revised Resolution to Issue 319 Date: Fri, 30 Oct 2009 12:16:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpZjkmwUnpnYRVMROiwHhmCEyFohQABhdmA Content-Language: en-us X-OriginalArrivalTime: 30 Oct 2009 19:16:54.0919 (UTC) FILETIME=[8AEBD170:01CA5995] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: A few comments: Section A.1.1 states: " The following data also qualifies as "simple data types": * Attributes grouped into a logical container, using the [RFC2868] tagging mechanism. This approach is NOT RECOMMENDED (see Section 2.1.2), but is permissible where the alternatives are worse." However, Section A.2.1 states: " * Tagged data types as described in [RFC2868]. These data types SHOULD NOT be used in new specifications." These two paragraphs appear to be in conflict; suggest deletion of the A.2.1 text. Section A.2 states: " All data types other than the ones described above in Appendix A.1 and Appendix B SHOULD NOT be used. This section describes in detail a number of data types that are NOT RECOMMENDED in new RADIUS specifications." Similarly, Section A.2.2 states: " Does the attribute: * define a complex data type not described in Appendix B," However, Section A.2.1 states: " * Complex data structures defined only within RADIUS. SHOULD NOT be used. This recommendation does not apply to new attributes for authentication or security, as described below in Section A.2.2." Recommendation is to delete the material in Section A.2.1 or sync it with A.2. -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok Sent: Friday, October 30, 2009 11:20 AM To: Bernard Aboba Cc: 'radext mailing list' Subject: Re: Revised Resolution to Issue 319 Bernard Aboba wrote: > In looking at the text of Sections 2 and 2.1.1, I would propose to make > the following changes in Section 2 and 2.1.1 to resolve Issue 319. > > Required changes in Appendix A will following in a separate post. I've re-worked both Section 2 and Appendix A to address these concerns. A proposed version is available online at: http://git.freeradius.org/draft-ietf-radext-design-10.txt Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Oct 30 12:33: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 1EAF03A686B for ; Fri, 30 Oct 2009 12:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8NqdP8r8CIO for ; Fri, 30 Oct 2009 12:33:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 493A83A68DD for ; Fri, 30 Oct 2009 12:33:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3xCD-000Pn8-Ho for radiusext-data0@psg.com; Fri, 30 Oct 2009 19:31:37 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3xCB-000Pm6-9N for radiusext@ops.ietf.org; Fri, 30 Oct 2009 19:31:35 +0000 Message-ID: <4AEB3F12.1040704@deployingradius.com> Date: Fri, 30 Oct 2009 15:31:30 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: 'radext mailing list' Subject: Re: Revised Resolution to Issue 319 References: <4AEB2E57.7040007@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > These two paragraphs appear to be in conflict; suggest deletion of the A.2.1 > text. OK. > Recommendation is to delete the material in Section A.2.1 or sync it with > A.2. Deleting the material seems to be the simplest approach. 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 Fri Oct 30 13:52: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 853A83A6820 for ; Fri, 30 Oct 2009 13:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.121 X-Spam-Level: * X-Spam-Status: No, score=1.121 tagged_above=-999 required=5 tests=[AWL=-0.985, BAYES_50=0.001, 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 cDr9jLHVU1yh for ; Fri, 30 Oct 2009 13:52:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7239F3A63EC for ; Fri, 30 Oct 2009 13:52:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3yPs-0003Id-PA for radiusext-data0@psg.com; Fri, 30 Oct 2009 20:49:48 +0000 Received: from [65.55.116.23] (helo=blu0-omc1-s12.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3yPk-0003Dw-6B for radiusext@ops.ietf.org; Fri, 30 Oct 2009 20:49:40 +0000 Received: from BLU137-W29 ([65.55.116.8]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 13:49:39 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_09c9763e-3146-496e-afc9-62fbf6478837_" X-Originating-IP: [131.107.0.82] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Issue 323: Use of a Product Name Date: Fri, 30 Oct 2009 13:49:39 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 30 Oct 2009 20:49:39.0610 (UTC) FILETIME=[7FBC47A0:01CA59A2] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_09c9763e-3146-496e-afc9-62fbf6478837_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HTML clipboardIssue 323: Use of a Product Name Submitter name: Bernard Aboba =20 Submitter email address: bernard_aboba@hotmail.com=20 Date first submitted: October 30=2C 2009 =20 Reference:=20 Document:=20 RADSEC=2C Status-Server=2C RADIUS over DTLS=20 Comment type: E =20 Priority: S =20 Section: Various =20 Rationale/Explanation of issue: "RADSEC" is the name of a commercial product. I would suggest that the=20 term "RADIUS over TLS" or RTLS be used instead to describe the protocol.=20 = --_09c9763e-3146-496e-afc9-62fbf6478837_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
HTML clipboardIssue 323: Use of =3B a Produ= ct Name
Submitter name: =3B Bernard Aboba =3B
Submitter email address: bernard_aboba@hotmail.com
Date first submitted: October 30=2C 2009 =3B
Reference: =3B
Document:=20 RADSEC=2C Status-Server=2C RADIUS over DTLS=20
Comment type: E =3B
Priority: S =3B
Section: =3B Various =3B
Rationale/Explanation of issue:


"RADSEC" is the name of a commercial product. =3B I would suggest that = the=20 term "RADIUS over TLS" or RTLS be used instead to describe the protocol.


=
=
= --_09c9763e-3146-496e-afc9-62fbf6478837_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Oct 30 21:59:21 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 C84C53A681B for ; Fri, 30 Oct 2009 21:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.051 X-Spam-Level: * X-Spam-Status: No, score=1.051 tagged_above=-999 required=5 tests=[AWL=-0.874, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, 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 NGf4uwhoK42G for ; Fri, 30 Oct 2009 21:59:21 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9DD933A672F for ; Fri, 30 Oct 2009 21:59:20 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N45z2-000Hjt-NO for radiusext-data0@psg.com; Sat, 31 Oct 2009 04:54:36 +0000 Received: from [65.55.111.94] (helo=blu0-omc2-s19.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N45yy-000HiL-Uj for radiusext@ops.ietf.org; Sat, 31 Oct 2009 04:54:33 +0000 Received: from BLU137-W18 ([65.55.111.73]) by blu0-omc2-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 21:54:32 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_ad0e8667-4fbb-4cb9-bbf3-c5cc99ecadd9_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Alan DeKok , "radiusext@ops.ietf.org" Subject: RE: Revised Resolution to Issue 319 Date: Fri, 30 Oct 2009 21:54:32 -0700 Importance: Normal In-Reply-To: <4AEBA161.3010607@deployingradius.com> References: <4AEB2E57.7040007@deployingradius.com> <4AEB42AB.8090505@deployingradius.com> X-OriginalArrivalTime: 31 Oct 2009 04:54:32.0270 (UTC) FILETIME=[3C4FE6E0:01CA59E6] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: <4AEBA161.3010607@deployingradius.com> MIME-Version: 1.0 --_ad0e8667-4fbb-4cb9-bbf3-c5cc99ecadd9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In Section 1.3: The uses of "MUST" and "MUST NOT" in this document are limited to (a) requirements to follow the IETF process for IETF standards=2C and (b) quotes from other documents. As a result=2C the use of MUST and MUST NOT in this document does not prescribe new mandatory behavior within implementations. Wasn't this to have gone in Section 1.2? Section 2.1.1 states: While the Framed-Interface-Id attribute defined in [RFC3162] Section 2.2 included a value field of 8 octets=2C the data type was not explicitly indicated=2C and therefore there is controversy over whether the format of this attribute was intended to be an 8 octet String or whether a special Interface-Id type was intended. . . . Implementations supporting the Framed-Interface-Id attribute may select a data type of their choosing (most likely an 8 octet String or a special Interface-Id data type). Yet Section A.1.1 says: * Interface-Id (8 octets in network byte order) Should this say:=20 =20 * Interface-Id (8 octet string in network byte order) =20 = --_ad0e8667-4fbb-4cb9-bbf3-c5cc99ecadd9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In Section 1.3:

   The uses of "MUST" and "MUST NOT" in this do=
cument are limited to (a)
   requirements to follow the IETF process for=
 IETF standards=2C and (b)
   quotes from other documents.  As a result=
=2C the use of MUST and MUST
   NOT in this document does not prescribe =
new mandatory behavior within
   implementations.
Wasn't this t= o have gone in Section 1.2?

Section 2.1.1 states:

   Whi=
le the Framed-Interface-Id attribute defined in [RFC3162] Section
   2.2=
 included a value field of 8 octets=2C the data type was not
   explicit=
ly indicated=2C and therefore there is controversy over whether
   the f=
ormat of this attribute was intended to be an 8 octet String or
   wheth=
er a special Interface-Id type was intended.

   . . .

   Impl=
ementations supporting the Framed-Interface-Id
   attribute may select a=
 data type of their choosing (most likely an 8
   octet String or a spec=
ial Interface-Id data type).

Yet Section A.1.1 says:

&n= bsp=3B =3B =3B =3B =3B * Interface-Id (8 octets in network = byte order)

Should this say: 
 
 =3B =3B =3B =
* Interface-Id (8 octet string in network byte order)




  =

= --_ad0e8667-4fbb-4cb9-bbf3-c5cc99ecadd9_-- -- to 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, 31 Oct 2009 04:55:37 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_ad0e8667-4fbb-4cb9-bbf3-c5cc99ecadd9_" From: Bernard Aboba To: Alan DeKok , "radiusext@ops.ietf.org" Subject: RE: Revised Resolution to Issue 319 Date: Fri, 30 Oct 2009 21:54:32 -0700 <4AEBA161.3010607@deployingradius.com> MIME-Version: 1.0 --_ad0e8667-4fbb-4cb9-bbf3-c5cc99ecadd9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In Section 1.3: The uses of "MUST" and "MUST NOT" in this document are limited to (a) requirements to follow the IETF process for IETF standards=2C and (b) quotes from other documents. As a result=2C the use of MUST and MUST NOT in this document does not prescribe new mandatory behavior within implementations. Wasn't this to have gone in Section 1.2? Section 2.1.1 states: While the Framed-Interface-Id attribute defined in [RFC3162] Section 2.2 included a value field of 8 octets=2C the data type was not explicitly indicated=2C and therefore there is controversy over whether the format of this attribute was intended to be an 8 octet String or whether a special Interface-Id type was intended. . . . Implementations supporting the Framed-Interface-Id attribute may select a data type of their choosing (most likely an 8 octet String or a special Interface-Id data type). Yet Section A.1.1 says: * Interface-Id (8 octets in network byte order) Should this say:=20 =20 * Interface-Id (8 octet string in network byte order) =20 = --_ad0e8667-4fbb-4cb9-bbf3-c5cc99ecadd9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In Section 1.3:

   The uses of "MUST" and "MUST NOT" in this do=
cument are limited to (a)
   requirements to follow the IETF process for=
 IETF standards=2C and (b)
   quotes from other documents.  As a result=
=2C the use of MUST and MUST
   NOT in this document does not prescribe =
new mandatory behavior within
   implementations.
Wasn't this t= o have gone in Section 1.2?

Section 2.1.1 states:

   Whi=
le the Framed-Interface-Id attribute defined in [RFC3162] Section
   2.2=
 included a value field of 8 octets=2C the data type was not
   explicit=
ly indicated=2C and therefore there is controversy over whether
   the f=
ormat of this attribute was intended to be an 8 octet String or
   wheth=
er a special Interface-Id type was intended.

   . . .

   Impl=
ementations supporting the Framed-Interface-Id
   attribute may select a=
 data type of their choosing (most likely an 8
   octet String or a spec=
ial Interface-Id data type).

Yet Section A.1.1 says:

&n= bsp=3B =3B =3B =3B =3B * Interface-Id (8 octets in network = byte order)

Should this say: 
 
 =3B =3B =3B =
* Interface-Id (8 octet string in network byte order)




  =

= --_ad0e8667-4fbb-4cb9-bbf3-c5cc99ecadd9_-- -- to 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, 30 Oct 2009 20:50:28 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_09c9763e-3146-496e-afc9-62fbf6478837_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Issue 323: Use of a Product Name Date: Fri, 30 Oct 2009 13:49:39 -0700 MIME-Version: 1.0 --_09c9763e-3146-496e-afc9-62fbf6478837_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HTML clipboardIssue 323: Use of a Product Name Submitter name: Bernard Aboba =20 Submitter email address: bernard_aboba@hotmail.com=20 Date first submitted: October 30=2C 2009 =20 Reference:=20 Document:=20 RADSEC=2C Status-Server=2C RADIUS over DTLS=20 Comment type: E =20 Priority: S =20 Section: Various =20 Rationale/Explanation of issue: "RADSEC" is the name of a commercial product. I would suggest that the=20 term "RADIUS over TLS" or RTLS be used instead to describe the protocol.=20 = --_09c9763e-3146-496e-afc9-62fbf6478837_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
HTML clipboardIssue 323: Use of =3B a Produ= ct Name
Submitter name: =3B Bernard Aboba =3B
Submitter email address: bernard_aboba@hotmail.com
Date first submitted: October 30=2C 2009 =3B
Reference: =3B
Document:=20 RADSEC=2C Status-Server=2C RADIUS over DTLS=20
Comment type: E =3B
Priority: S =3B
Section: =3B Various =3B
Rationale/Explanation of issue:


"RADSEC" is the name of a commercial product. =3B I would suggest that = the=20 term "RADIUS over TLS" or RTLS be used instead to describe the protocol.


=
=
= --_09c9763e-3146-496e-afc9-62fbf6478837_-- -- to 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, 30 Oct 2009 19:32:03 +0000 Message-ID: <4AEB3F12.1040704@deployingradius.com> Date: Fri, 30 Oct 2009 15:31:30 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: 'radext mailing list' Subject: Re: Revised Resolution to Issue 319 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > These two paragraphs appear to be in conflict; suggest deletion of the A.2.1 > text. OK. > Recommendation is to delete the material in Section A.2.1 or sync it with > A.2. Deleting the material seems to be the simplest approach. 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: Fri, 30 Oct 2009 19:17:19 +0000 Message-ID: From: "Bernard Aboba" To: "'Alan DeKok'" CC: "'radext mailing list'" Subject: RE: Revised Resolution to Issue 319 Date: Fri, 30 Oct 2009 12:16:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpZjkmwUnpnYRVMROiwHhmCEyFohQABhdmA Content-Language: en-us A few comments: Section A.1.1 states: " The following data also qualifies as "simple data types": * Attributes grouped into a logical container, using the [RFC2868] tagging mechanism. This approach is NOT RECOMMENDED (see Section 2.1.2), but is permissible where the alternatives are worse." However, Section A.2.1 states: " * Tagged data types as described in [RFC2868]. These data types SHOULD NOT be used in new specifications." These two paragraphs appear to be in conflict; suggest deletion of the A.2.1 text. Section A.2 states: " All data types other than the ones described above in Appendix A.1 and Appendix B SHOULD NOT be used. This section describes in detail a number of data types that are NOT RECOMMENDED in new RADIUS specifications." Similarly, Section A.2.2 states: " Does the attribute: * define a complex data type not described in Appendix B," However, Section A.2.1 states: " * Complex data structures defined only within RADIUS. SHOULD NOT be used. This recommendation does not apply to new attributes for authentication or security, as described below in Section A.2.2." Recommendation is to delete the material in Section A.2.1 or sync it with A.2. -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok Sent: Friday, October 30, 2009 11:20 AM To: Bernard Aboba Cc: 'radext mailing list' Subject: Re: Revised Resolution to Issue 319 Bernard Aboba wrote: > In looking at the text of Sections 2 and 2.1.1, I would propose to make > the following changes in Section 2 and 2.1.1 to resolve Issue 319. > > Required changes in Appendix A will following in a separate post. I've re-worked both Section 2 and Appendix A to address these concerns. A proposed version is available online at: http://git.freeradius.org/draft-ietf-radext-design-10.txt Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 30 Oct 2009 18:21:18 +0000 Message-ID: <4AEB2E57.7040007@deployingradius.com> Date: Fri, 30 Oct 2009 14:20:07 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: 'radext mailing list' Subject: Re: Revised Resolution to Issue 319 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > In looking at the text of Sections 2 and 2.1.1, I would propose to make > the following changes in Section 2 and 2.1.1 to resolve Issue 319. > > Required changes in Appendix A will following in a separate post. I've re-worked both Section 2 and Appendix A to address these concerns. A proposed version is available online at: http://git.freeradius.org/draft-ietf-radext-design-10.txt 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, 28 Oct 2009 13:55:32 +0000 Message-ID: <4AE84D23.5030301@deployingradius.com> Date: Wed, 28 Oct 2009 09:54:43 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: 'radext mailing list' Subject: Re: Inconsistencies between RFCs and implementations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > [BA] Since the guidelines document is just a BCP, it shouldn't be > updating existing standards. So when you say the "remainder of the > guidelines document" this makes me wonder what part of the guidelines > document lies outside the appropriate role of a BCP. Creating a RADIUS data model could arguably be outside of the role of a BCP. However, pointing out that one exists would likely be within the role of a BCP. > [BA] During prior WG discussion, there was a general aversion to a large > scale remake of the RADIUS data model (e.g. attempts to converge the model > with Diameter). However, the addition of some modest enhancements might > be within the scope of the Extended Attributes document. I would suggest codifying the data model, rather than remaking it. The data model has already largely been codified in the implementations. If these are wrong, then we could say that no RADIUS implementations exist. If they are right, then documenting what the implementations have done would remake nothing. > [BA] My preference would be for minor updates, with the goal of > addressing the outstanding issues. Where the specifications are > genuinely ambiguous about the types being defined, the document can > state that, but can leave resolution to the future. > > Assuming we restrict additional work to that scope, what remaining > changes do we need to make? We need to change integer64 -> ifid, or something similar. We need to achieve WG consensus that the current document reflects current practice, and that the current practice is acceptable. I suggest also adding a sentence or two describing the implicit versus explicit nature of the RADIUS data model, and the failure of RFC 3162 et. al. to follow the "data type definition" framework shown in RFC 2865. 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, 28 Oct 2009 10:26:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: WG Review: Recharter of Handover Keying (hokey) Date: Wed, 28 Oct 2009 11:24:54 +0100 Message-ID: Thread-Topic: WG Review: Recharter of Handover Keying (hokey) Thread-Index: AcpXSI4gdwuwlXVZRzCWaWO5/ULIAgAcD0kQ From: "Romascanu, Dan (Dan)" To: , , , , , =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, October 27, 2009 11:00 PM To: new-work@ietf.org Subject: WG Review: Recharter of Handover Keying (hokey)=20 A modified charter has been submitted for the Handover Keying (hokey) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, November 3, 2009. Handover Keying (hokey) ------------------------ Last Modified: 2009-10-19 Chair(s): Glen Zorn Tina Tsou (Ting ZOU) =20 Security Area Director(s): Tim Polk Pasi Eronen =20 Security Area Advisor: Tim Polk =20 Mailing Lists: General Discussion: hokey@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hokey Archive: http://www.ietf.org/mail-archive/web/hokey/current/maillist.html Description of Working Group: A mobile device has to re-authenticate each time it changes its point of attachment to the network. When it goes through the full procedure of authentication it creates a series of ruptures, during which the medium cannot flow. This results in a poor user experience during handover. However, it is possible to shorten the time it takes to re-authenticate by reusing the key information developed during the initial authentication. The Handover Keying Working Group is concerned with developing procedures for key reuse and delivery, while respecting good security practice. The Handover Keying Working Group has already done work on this subject, but it has not yet developed the complete set of procedures, protocols, and changes needed for different security environment scenarios and situations. The solutions specified by the HOKEY WG fall into several categories, based on timing and mechanism. The authentication and key management may occur before handoff, when latency is much less critical. Alternatively, authentication and key management can occur as part of the handoff, where latency is critical. Solutions should reduce or eliminate the number of referrals to AAA servers, and solutions should avoid re-executing lengthy EAP method exchanges. This may be accomplished by providing new mechanisms for cryptographic keying material in combination with a protocol for the timely delivery of appropriate keys to the appropriate entities. Solutions are expected to include "handover keying," "low-latency re-authentication," and "pre-authentication" or "early authentication". All solution categories are useful, each supporting different scenarios. The HOKEY WG may provide multiple solutions, each addressing a different scenario. Solutions specified by the HOKEY WG must: 1) Be responsive to handover and re-authentication latency performance objectives within a mobile wireless access network. 2) Fulfill the requirements in RFC 4962 and RFC 5247. 3) Be independent of the access-technology. Any key hierarchy topology or protocol defined must be independent of EAP lower layers. The protocols may require additional support from the EAP lower layers that use it. 4) Accommodate inter-technology heterogeneous handover and roaming. 5) Not require changes to EAP methods. Any extensions defined to EAP must not cause changes to existing EAP methods. In specifying an access-technology-independent solution, media independent guidelines for SDOs may also be needed to explain how the keying material and signaling can be employed in a specific access technology. HOKEY WG Deliverables =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) A specification of Local Domain Name Discovery for ERP. Currently the use of DHCP mechanisms to request the local domain name is unspecified. There are other useful scenarios that need to be addressed. Lower layer announcement for local domain name is unspecified. Ambiguity with using initial full EAP exchange for re-authentication needs to be clarified. Additional re-authentication scenarios, for which there is interest, need to be addressed. 2) A specification of Early Authentication solutions. These include use of EAP to pre-establish authenticated keying material on a target authenticator prior to arrival of the peer. 3) A specification for a Hokey architecture Document. It includes deployment of ERP and EAP early authentication protocol in the mobile environment. There are various useful scenarios that need to be addressed. This specification and the revision of RFC5296 should be conducted in parallel. 4) Assistance to the 802.21a group in specifying the integration of EAP pre-authentication with IEEE 802.21a. The Hokey Working Group shall perform tasks that are complementary to and do not duplicate work being done in IEEE 802.21a. 6) A specification for NAS-Authenticator interaction. NAS interaction can be used to release resources in the old NAS and achieve faster initiation of authentication. Related work in external SDOs on authenticator/NAS interaction for re-authentication may be taken into consideration. 7) A revision of RFC 5296 to eliminate unnecessary references to the home server. 8) Assistance to the radext and dime Working Groups in developing AAA support for handoff keying. Goals and Milestones: Nov 2009 First draft on Local Domain Name Discovery for ERP Nov 2009 First draft on Early Authentication solutions Mar 2010 First draft on Hokey architecture Mar 2010 First draft on NAS-Authenticator Interaction Jul 2010 First draft on revision of RFC 5296 Mar 2011 Submit the Local Domain Name Discovery for ERP draft to IESG Mar 2011 Submit the Early Authentication solutions draft to IESG Jul 2011 Submit the NAS-Authenticator Interaction draft to IESG Nov 2011 Submit the Hokey architecture draft to IESG Nov 2011 Submit the revision of RFC 5296 to IESG Mar 2012 Re-charter or shut down WG -- to 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, 28 Oct 2009 05:09:20 +0000 Message-ID: From: "Bernard Aboba" To: "'radext mailing list'" Subject: Revised Resolution to Issue 319 Date: Tue, 27 Oct 2009 22:09:05 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0148_01CA5752.198AEBF0" Thread-Index: AcpXiKUKth96wIkkTuCJkzobOU4biwAA/nKA Content-Language: en-us ------=_NextPart_000_0148_01CA5752.198AEBF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In looking at the text of Sections 2 and 2.1.1, I would propose to make the following changes in Section 2 and 2.1.1 to resolve Issue 319. Required changes in Appendix A will following in a separate post. 2. RADIUS Data Model The Remote Authentication Dial In User Service (RADIUS) defined in [RFC2865 ] and [RFC2866 ] uses elements known as attributes in order to represent authentication, authorization and accounting data. Unlike SNMP, first defined in [RFC1157 ] and [RFC1155 ], RADIUS does not define a formal data definition language. The data type of RADIUS attributes is not transported on the wire. Rather, the data type of a RADIUS attribute is fixed when that attribute is defined. Based on the RADIUS attribute type code, RADIUS clients and servers can determine the data type based on pre- configured entries within a data dictionary. Two distinct attribute spaces are defined: the standard space, and a Vendor-Specific space. Attributes in the standard space generally are composed of a type, length, value (TLV) triplet, although complex attributes have also been defined. The Vendor-Specific space is encapsulated within a single attribute type (Vendor-Specific Attribute). The format of this space is defined by individual vendors, but the same TLV encoding used by the standard space is recommended in [RFC2865] Section 5.26. The similarity between attribute formats has enabled implementations to leverage common parsing functionality, although in some cases the attributes in the Vendor-Specific space have begun to diverge from the common format. 2.1.1. Basic Data Types defined in RFC 2865 [RFC2865] and [RFC2866] utilize data types defined in [RFC2865] Section 5, which states the following: The format of the value field is one of five data types. Note that type "text" is a subset of type "string". text 1-253 octets containing UTF-8 encoded 10646 [RFC3629 ] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead. string 1-253 octets containing binary data (values 0 through 255 decimal, inclusive). Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. address 32 bit value, most significant octet first. integer 32 bit unsigned value, most significant octet first. time 32 bit unsigned value, most significant octet first -- seconds since 00:00:00 UTC, January 1, 1970. The standard Attributes do not use this data type but it is presented here for possible use in future attributes. In addition to the data types defined in [RFC2865], subsequent RADIUS specifications defined attributes using additional basic data types. Since these specifications did not explicitly define new data types as was done in [RFC2865], nor did they consistently indicate the format of the value field using the same conventions as [RFC2865], in some cases the intended data type is ambiguous and may not be consistent among different implementations. It is out of the scope of this document to resolve all potential ambiguities within existing RADIUS specifications. However in order to prevent future ambiguities, it is recommended that future RADIUS attribute specifications explicitly define newly created data types at the beginning of the document, and indicate clearly the data type to be used for each attribute. [RFC3162] utilizes but does not explicitly define the following data types: IPv6 address 128 bit value, in network byte order. IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 128 bits of value, in network byte order. Examples of the IPv6 address type include NAS-IPv6-Address defined in [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, and in [RFC4818] Section 3. While the Framed-Interface-Id attribute defined in [RFC3162] Section 2.2 included a value field of 8 octets, the data type was not explicitly indicated, and therefore there is controversy over whether the format of this attribute was intended to be an 8 octet String or whether a special Interface-Id type was intended. Given that attributes of type IPv6 address and IPv6 prefix are already in use, it is RECOMMENDED that RADIUS server implementations include support for these additional basic types, in addition to the types defined in [RFC2865 ]. Where the intent is to represent a specific IPv6 address, the IPv6 address type SHOULD be used. Although it is possible to use the IPv6 IPv6 Prefix type with a prefix length of 128 to represent an IPv6 address, this usage is NOT RECOMMENDED. Implementations supporting the Framed-Interface-Id attribute may select a data type of their choosing (most likely an 8 octet String or a special Interface-Id data type). It is worth noting that since RADIUS only supports unsigned integers of 32 bits, attributes using signed integer data types or unsigned integer types of other sizes will require code changes, and SHOULD be avoided. For [RFC2865 ] RADIUS VSAs, the length limitation of the String and Text types is 247 octets instead of 253 octets, due to the additional overhead of the Vendor-Specific Attribute. ------=_NextPart_000_0148_01CA5752.198AEBF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In looking at the text = of Sections 2 and 2.1.1, I would propose to make the following changes in Section 2 = and 2.1.1 to resolve Issue 319.

Required changes in = Appendix A will following in a separate post.

 

2.  RADIUS Data = Model

 
 
  =
 The Remote Authentication Dial In User Service (RADIUS) defined =
in
   [RFC2865] and [RFC2866] uses elements known as attributes in =
order to
   represent authentication, =
authorization and accounting =
data.
 
   =
Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS =
does
   not define a formal data =
definition language.  
   The =
data type of RADIUS attributes is not transported on the =
wire.
   Rather, the data type of a =
RADIUS attribute is fixed when that
  =
 attribute is defined.  Based on the RADIUS attribute type =
code,
   RADIUS clients and servers can =
determine the data type based on pre-
   =
configured entries within a data =
dictionary.
 
  =
 Two distinct attribute spaces are defined: the standard space, and =
a
   Vendor-Specific space.  =
Attributes in the standard space =
generally
   are composed of a type, =
length, value (TLV) triplet, although =
complex
   attributes have also been =
defined.  The Vendor-Specific space =
is
   encapsulated within a single =
attribute type (Vendor-Specific
   =
Attribute).  The format of this space is defined by =
individual
   vendors, but the same TLV =
encoding used by the standard space is
   =
recommended in [RFC2865] =
Section 5.26.  The similarity =
between
   attribute formats has enabled =
implementations to leverage common
   =
parsing functionality, although in some cases the attributes in =
the
   Vendor-Specific space have begun =
to diverge from the common format.

2.1.1.  Basic Data Types defined in = RFC 2865

   [RFC2865] =
and [RFC2866] utilize data types defined in [RFC2865] =

   Section 5, which states the =
following:
 
  &=
nbsp;   The format of the value field is one of five data =
types.  Note
      =
that type "text" is a subset of type =
"string".
 
&nbs=
p;     text      1-253 =
octets containing UTF-8 encoded 10646 [RFC3629]
    &n=
bsp;           =
characters.  Text of length zero (0) MUST NOT be =
sent;
       &nbs=
p;        omit the entire attribute =
instead.
 
  &nb=
sp;   string    1-253 octets containing binary =
data (values 0 =
through
       &n=
bsp;        255 decimal, =
inclusive).  Strings of length zero =
(0)
        =
        MUST NOT be sent; omit the =
entire attribute =
instead.
 
  &nb=
sp;   address   32 bit value, most significant octet =
first.
 
   =
;   integer   32 bit unsigned value, most =
significant octet =
first.
 
   =
;   time      32 bit unsigned value, =
most significant octet first =
--
        &=
nbsp;       seconds since 00:00:00 UTC, =
January 1, 1970.  =
The
        =
        standard Attributes do not =
use this data type but it =
is
        &=
nbsp;       presented here for possible =
use in future =
attributes.
 
  =
 In addition to the data types defined in [RFC2865], subsequent RADIUS =

   specifications defined =
attributes using additional basic data types.  =
Since
   these specifications did not =
explicitly define new data types as =
was
   done in [RFC2865], nor did they =
consistently indicate the format of the =
value
   field using the same conventions =
as [RFC2865], in some cases the =
intended
   data type is ambiguous and =
may not be consistent among different
   =
implementations.  =

 
   It is out =
of the scope of this document to resolve all potential ambiguities =

   within existing RADIUS =
specifications.  However in order to prevent =
future
   ambiguities, it is recommended =
that future RADIUS attribute specifications =

   explicitly define newly created =
data types at the beginning of the document, =

   and indicate clearly the data =
type to be used for each attribute. =

 
   [RFC3162] =
utilizes but does not explicitly define the following data types: =

 
   IPv6 =
address   128 bit value, in network byte =
order.
   IPv6 prefix    8 =
bits of reserved, 8 bits of prefix length, up =
to
        &=
nbsp;         128 bits of value, =
in network byte =
order.
 
   =
Examples of the IPv6 address type include NAS-IPv6-Address defined =
in
   [RFC3162] =
Section 2.1 and Login-IPv6-Host defined in [RFC3162]
   =
Section 2.4.  The IPv6 prefix type is used in [RFC3162] =
Section 2.3,
   and in [RFC4818] =
Section 3. =

 
   While the =
Framed-Interface-Id attribute defined in [RFC3162] Section =
2.2
   included a value field of 8 =
octets, the data type was not =
explicitly
   indicated, and therefore =
there is controversy over whether the =
format
   of this attribute was intended =
to be an 8 octet String or whether a
   =
special Interface-Id type was intended. =
 
 
   =
Given that attributes of type IPv6 address and IPv6 prefix are =
already
   in use, it is RECOMMENDED that =
RADIUS server implementations include support for =

   these additional basic types, in =
addition to the types defined in [RFC2865].
   Where =
the intent is to represent a specific IPv6 address, the =
IPv6
   address type SHOULD be =
used.  Although it is possible to use the =
IPv6
   IPv6 Prefix type with a prefix =
length of 128 to represent an IPv6
   =
address, this usage is NOT RECOMMENDED.  Implementations =
supporting
   the Framed-Interface-Id =
attribute may select a data type of =
their
   choosing (most likely an 8 octet =
String or a special Interface-Id =

   data type). =
 
 
   It =
is worth noting that since RADIUS only supports unsigned =
integers
   of 32 bits, attributes using =
signed integer data types or
   unsigned =
integer types of other sizes will require code changes, =
and
   SHOULD be =
avoided.
 
   =
For [RFC2865] RADIUS VSAs, the length limitation of =
the String and
   Text types is 247 =
octets instead of 253 octets, due to the =
additional
   overhead of the =
Vendor-Specific Attribute.

 

------=_NextPart_000_0148_01CA5752.198AEBF0-- -- to 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, 28 Oct 2009 05:04:16 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_73755604-6d67-4681-8c73-fde910139b2b_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Appendix A Revisions required for consistency with proposed Issue 319 resolution Date: Tue, 27 Oct 2009 22:03:28 -0700 MIME-Version: 1.0 --_73755604-6d67-4681-8c73-fde910139b2b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In looking through Appendix A=2C there are some sections that are inconsist= ent with the revisions proposed in Issue 319: * Section A.1.1 refers to the integer64 data type=2C and does not include m= ention the potential Interface-Id type.=20 Does the data fit within the existing RADIUS data model=2C as outlined below? =20 could be clarified by changing it to: =20 Does the data fit within the basic data types described in Section 2.1.1= =2C as outlined below?=20 * Section A.2 says: All data types other than the ones described above in Appendix A.1 SHOULD NOT be used. This section describes in detail a number of data types that are NOT RECOMMENDED in new RADIUS specifications. Where possible=2C replacement data types are suggested. To make it clear that existing complex types are not being deprecated=2C th= e text might be changed to say "described in Appendix A.1 and Appendix B" * Section A.2.1 mentions integer64 data types. =20 * The advice on authentication security attributes needs to be sync'd up wi= th the new proposed text.=20 * The advice on a 16-bit type field is inconsistent with the recently revis= ed text.=20 * Section A.2.2 might say "define a complex type not described in Appendix = B which..." = --_73755604-6d67-4681-8c73-fde910139b2b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In looking through Appendix A=2C there are some sections that are inconsist= ent with the revisions proposed in Issue 319:

* Section A.1.1 refers= to the integer64 data type=2C and does not include mention the potential I= nterface-Id type. 
   Does the data fit within th=
e existing RADIUS data model=2C as outlined
   below?  

could be =
clarified by changing it to:
   
   Does the data fit within the basi=
c data types described in Section 2.1.1=2C
   as outlined below? 
* Section A.2 says:

   All data types other than the ones described=
 above in Appendix A.1
   SHOULD NOT be used.  This section des=
cribes in detail a number of
   data types that are NOT RECOMMENDED in n=
ew RADIUS specifications.
   Where possible=2C replacement data types ar=
e suggested.

To make it clear that existing complex types are not be=
ing deprecated=2C the text might be changed to say "described in Appendix A=
.1 and Appendix B"


* Section A.2.1 mentions integer64 data types=
.   

* The advice on authentication security attributes needs to be =
sync'd up with the new proposed text. 

* The advice on a 16-bit type=
 field is inconsistent with the recently revised text. 

* Section A.=
2.2 might say "define a complex type not described in Appendix B which..."<=
br>









= --_73755604-6d67-4681-8c73-fde910139b2b_-- -- to 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, 28 Oct 2009 03:46:55 +0000 Message-ID: From: "Bernard Aboba" To: "'Alan DeKok'" , "'radext mailing list'" Subject: RE: Inconsistencies between RFCs and implementations Date: Tue, 27 Oct 2009 20:44:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpXVUqqyFRdlmV0R66WuO50a/NukgAJ1WHg Content-Language: en-us Alan DeKok said: " As has been noted recently, RADIUS implementations are largely inconsistent with the RFCs." [BA] Actually, I think that it would be more accurate to say that RADIUS RFCs after RFC 2865-2869 did not consistently utilize the same conventions to describe data typing, namely to include the data type in the value field. " RFC 2865 defines an "address" data type for IPv4 addresses. Going back to the original Livingston server, pretty much every implementation calls this data type "ipv4addr". Even within RFC 2865, the upper-case "Address" name is used to define attributes, instead of using the "address" name given earlier in the document. RFC 3162 uses the "Address" data type for IPv6 address. This contradicts the definition of "address" in RFC 2865. Most implementations have chose to resolve the ambiguity by calling this data type "ipv6addr"." [BA] Neither of these cases seems particularly difficult. " RFC 3162 uses the name "Interface-Id" to describe interface Id's. This data type (if it is a data type) is not otherwise described anywhere in that document. Many implementations have chosen to resolve the ambiguity by calling this data type "ifid". [BA] I could see Interface-ID being implemented as a special type (if IPv6 address notation were used), or alternatively as an octet string. However, I do agree with Glen that integer64 is unlikely. " RFC 2867 uses the name "Lost" to describe the data type of Acct-Tunnel-Packets-Lost. This data type (if it is a data type) is not otherwise described anywhere in that document. Many implementations have chosen to resolve the ambiguity by defining the attribute as an "integer" data type." [BA] That seems reasonable to me. The value in question is in fact an unsigned number of 32-bits. RFC 2868 defines "tags". However, for non-integer attributes, the type "String" is used, rather than "text", even when the data is clearly meant to be textual (e.g. Tunnel-Server-Endpoint). Some implementations have chosen to arbitrarily classify these attributes using the RFC 2865 definitions "text" and "string", independent of the RFC 2868 definitions. Some implementations have instead created new data types such as "tagged-string", and "tagged-integer". [BA] Either way, the RFC 2868 tagging scheme is what it is, and this is now widely implemented. " The goal of the guidelines document is to clarify these issues, as part of recommending best practices for RADIUS specifications. However, it would seem that updating a RADIUS data model would be inappropriate for a BCP document." [BA] The goal of the guidelines document is just to provide guidelines for RADIUS attribute design. Early on, WG consensus was that the document should not advocate major changes in existing practice, but merely describe what has been done in the past. As long as the description of past practice is accurate and the guidelines are sensible and representative of WG consensus, then the guidelines document has done its job. It is not necessary for the guidelines document to address every potential inconsistency in the RADIUS specifications. For example, in situations where a reasonable person might interpret the documents differently, it is acceptable to point out the ambiguity and leave it at that. " As such, I suggest splitting the document into two. One will define the RADIUS data model, be standards track, and explicitly update the previous RFCs to clarify the above contradictions. The other will be the remainder of the guidelines document, which gives only guidelines." [BA] Since the guidelines document is just a BCP, it shouldn't be updating existing standards. So when you say the "remainder of the guidelines document" this makes me wonder what part of the guidelines document lies outside the appropriate role of a BCP. "It will define *new* types, where this WG believes that existing types are contradictory or inadequate." [BA] During prior WG discussion, there was a general aversion to a large scale remake of the RADIUS data model (e.g. attempts to converge the model with Diameter). However, the addition of some modest enhancements might be within the scope of the Extended Attributes document. "It will contain a detailed review of each and every RADIUS attribute defined in any specification. It will specify the new types for each attribute." [BA] As you have noted, in many cases implementers have come to the same conclusion about the data types intended for use with attributes. There are a few isolated cases (which we have been discussing) where implementations may differ, but I'm not sure that this is widespread enough to justify such a major effort. " Or, we can perform minor updates to the existing guidelines document (e.g. replacing integer64 with interface-id), and publish it." [BA] My preference would be for minor updates, with the goal of addressing the outstanding issues. Where the specifications are genuinely ambiguous about the types being defined, the document can state that, but can leave resolution to the future. Assuming we restrict additional work to that scope, what remaining changes do we need to make? -- to 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, 27 Oct 2009 22:29:18 +0000 Message-ID: <4AE77409.7050905@deployingradius.com> Date: Tue, 27 Oct 2009 18:28:25 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: 'radext mailing list' Subject: Inconsistencies between RFCs and implementations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As has been noted recently, RADIUS implementations are largely inconsistent with the RFCs. To summarize: RFC 2865 defines an "address" data type for IPv4 addresses. Going back to the original Livingston server, pretty much every implementation calls this data type "ipv4addr". Even within RFC 2865, the upper-case "Address" name is used to define attributes, instead of using the "address" name given earlier in the document. RFC 3162 uses the "Address" data type for IPv6 address. This contradicts the definition of "address" in RFC 2865. Most implementations have chose to resolve the ambiguity by calling this data type "ipv6addr". RFC 3162 uses the name "Interface-Id" to describe interface Id's. This data type (if it is a data type) is not otherwise described anywhere in that document. Many implementations have chosen to resolve the ambiguity by calling this data type "ifid". RFC 2867 uses the name "Lost" to describe the data type of Acct-Tunnel-Packets-Lost. This data type (if it is a data type) is not otherwise described anywhere in that document. Many implementations have chosen to resolve the ambiguity by defining the attribute as an "integer" data type. RFC 2058 and RFC 2138 did not differentiate between textual and binary data. This clarification was made in RFC 2865, by creating the "text" type. Some implementations made this clarification prior to RFC 2865 being published, and may not have chosen the same names. RFC 2868 defines "tags". However, for non-integer attributes, the type "String" is used, rather than "text", even when the data is clearly meant to be textual (e.g. Tunnel-Server-Endpoint). Some implementations have chosen to arbitrarily classify these attributes using the RFC 2865 definitions "text" and "string", independent of the RFC 2868 definitions. Some implementations have instead created new data types such as "tagged-string", and "tagged-integer". These inconsistencies and ambiguities were not addressed in RFC 5080 (Issues and fixes). That document would arguably have been a good place to resolve these issues. The fact that the implementations disagree so clearly with the RFCs, and so consistently with the RFCs, show that there are major ambiguities that need to be resolved. Either the RFCs are wrong, or the implementations are wrong. They can't both be correct. The goal of the guidelines document is to clarify these issues, as part of recommending best practices for RADIUS specifications. However, it would seem that updating a RADIUS data model would be inappropriate for a BCP document. As such, I suggest splitting the document into two. One will define the RADIUS data model, be standards track, and explicitly update the previous RFCs to clarify the above contradictions. The other will be the remainder of the guidelines document, which gives only guidelines. The "data model" document will define the RADIUS data model. It will give names and definitions for RADIUS data types, in line with the names and definitions given in RFC 2865. It will define *new* types, where this WG believes that existing types are contradictory or inadequate. It will contain a detailed review of each and every RADIUS attribute defined in any specification. It will specify the new types for each attribute. This document will take 3-4 years to finish, of course. We will likely have to delay the design guidelines document, as it will use the data model document as a normative reference. Or, we can perform minor updates to the existing guidelines document (e.g. replacing integer64 with interface-id), and publish it. If the WG decides to split the guidelines document, then I would suggest finding another editor for the data type document. I am willing to finish the guidelines document, but it may be best if I avoided the data type 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: Tue, 27 Oct 2009 21:07:28 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_430324dc-950c-4e07-9b17-a098a8817343_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Civility and the RADEXT WG Date: Tue, 27 Oct 2009 14:06:29 -0700 <4AE704A4.1080800@deployingradius.com> MIME-Version: 1.0 --_430324dc-950c-4e07-9b17-a098a8817343_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Given the tone of recent conversation=2C putting "Civility" and "RADEXT WG"= in the same sentence=2C let alone next to each other=2C may seem incongruo= us.=20 Yet=2C civility within the IETF is an essential ingredient that allows the = organization to continue to function.=20 This does not represent a constraint on the technical arguments that can be= made. If you have an opinion on a technical matter that you'd like to sh= are with WG participants=2C by all means speak up.=20 Personalizing the arguments is where we draw the line. =20 "I disagree with your line of reasoning because..." is fundamentally diffe= rent from "If you don't agree with me=2C you are a moron."=20 The former is acceptable behavior among WG participants. The latter is not= .=20 To quote from Wikipedia: "Incivility consists of personal attacks=2C rudeness=2C and aggressive beha= viours that disrupt the project and lead to unproductive stress and conflic= t... a few=2C minor=2C isolated incidents of incivility are not in themselv= es a major concern. A behavioral pattern of incivility is disruptive and unacceptable... if it rises to the level of harassment or egregious person= al attacks. A single act of incivility can also cross the line if it is sev= ere enough: for instance=2C extreme verbal abuse or profanity directed at a= nother contributor=2C or a threat against another person... In general=2C be understanding and non-retaliatory in dealing with incivili= ty. If others are uncivil=2C be understanding (people do say things when they get upset) rather than judgemental=2C and do not respond in kind. If necessary=2C point out gently that you think the comment might be considered uncivil=2C and make it clear that you want to move on and focus on the content issue. Bear in mind that... standards vary. Consider t= oo the option of ignoring isolated examples of incivility=2C and simply moving forward ... O= nly take things to dispute resolution (see below) if there is an ongoing pr= oblem you can't resolve. This policy is not a weapon to use against other contributors." = --_430324dc-950c-4e07-9b17-a098a8817343_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Given the tone of recent conversation=2C putting "Civility" and "RADEXT WG"= in the same sentence=2C let alone next to each other=2C may seem incongruo= us.

Yet=2C civility within the IETF is an essential ingredient that= allows the organization to continue to function.

This does not rep= resent a constraint on the technical arguments that can be made. =3B&nb= sp=3B If you have an opinion on a technical matter that you'd like to share= with WG participants=2C by all means speak up.

Personalizing the a= rguments is where we draw the line. =3B

"I disagree with your l= ine of reasoning because..." =3B is fundamentally different from "If yo= u don't agree with me=2C you are a moron."

The former is acceptable= behavior among WG participants. =3B The latter is not.

To quot= e from Wikipedia:

"Incivility consists of personal attacks=2C rudeness=2C and aggre= ssive behaviours that disrupt the project and lead to unproductive stress a= nd conflict... a few=2C minor=2C isolated incidents of incivility are not i= n themselves a major concern. A behavioral pattern of incivility is disruptive and unacceptable... =3B if it rises to the level of haras= sment or egregious personal attacks= . A single act of incivility can also cross the line if it is severe en= ough: for instance=2C extreme verbal abuse or profanity directed at a= nother contributor=2C or a threat against another person...

In gener= al=2C be understanding and non-retaliatory in dealing with incivility. If others are uncivil=2C be understanding (people do say things when they get upset) rather than judgemental=2C and do not respond in kind. If necessary=2C point out gently that you think the comment might be considered uncivil=2C and make it clear that you want to move on and focus on the content issue. Bear in mind that... standards vary. Consider t= oo the option of ignoring isolated examples of incivility=2C and simply moving forward ... O= nly take things to dispute= resolution (see below) if there is an ongoing problem you can't resolv= e.
This policy is not a weapon to use against other contributors."


=


= --_430324dc-950c-4e07-9b17-a098a8817343_-- -- to 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, 27 Oct 2009 14:33:31 +0000 Message-ID: <4AE704A4.1080800@deployingradius.com> Date: Tue, 27 Oct 2009 10:33:08 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: 'Bernard Aboba' , radiusext@ops.ietf.org Subject: Re: Proposed Resolution of Issue #320: REJECT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > Hmm. The practice of making bald assertions of opinion without basis in > fact seems to be contagious ;-). As many people have noted over the years, > although RFC2865 defines the "address" data type, no attributes are defined > to be of type "address" in that document. This statement is a bald-faced lie. From RFC 2865: ... address 32 bit value, most significant octet first. ... 5.4. NAS-IP-Address ... Address The Address field is four octets. Other attributes use the "Address" type, too. The only way to make your statement true is to claim that the "address" data type define on page 25 is not, in fact, the "Address" data type used in Section 5.4. When you make statements that can be refuted by reading the RFCs, it's as much as admitting that your opinions have no basis in reality. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 27 Oct 2009 14:29:07 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_0ed70672-20c7-42da-a985-b491fb0b9403_" From: Bernard Aboba To: Alan DeKok CC: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: RE: Proposed Resolution of Issue #318: REJECT Date: Tue, 27 Oct 2009 07:28:52 -0700 <4AE70131.9010807@deployingradius.com> MIME-Version: 1.0 --_0ed70672-20c7-42da-a985-b491fb0b9403_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Instead of facing that fact=2C you dismiss the customers as "demanding > limited and simplistic designs"=2C and you dismiss the implementors as > "below-average high-school kids" for making decisions based on limited > time/money budgets. Indeed. The dictionary has *huge* value to real customers. They *hate* ha= ving to do upgrades just to get support for new attributes. These customer= s aren't stupid=2C or simplistic. = --_0ed70672-20c7-42da-a985-b491fb0b9403_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B Instead of facing that fact=2C you dismiss the customers as "deman= ding
>=3B limited and simplistic designs"=2C and you dismiss the imple= mentors as
>=3B "below-average high-school kids" for making decisions = based on limited
>=3B time/money budgets.

Indeed. =3B The d= ictionary has *huge* value to real customers. =3B They *hate* having to= do upgrades just to get support for new attributes. =3B These customer= s aren't stupid=2C or simplistic.

= --_0ed70672-20c7-42da-a985-b491fb0b9403_-- -- to 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, 27 Oct 2009 14:19:27 +0000 Message-ID: <4AE70131.9010807@deployingradius.com> Date: Tue, 27 Oct 2009 10:18:25 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: 'Dave Nelson' , radiusext@ops.ietf.org Subject: Re: Proposed Resolution of Issue #318: REJECT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > Do you ever read what you write? I really wish you would, since the rest of > us have to. I didn't say anything about budgets. Of course not. The best kind of argument is to make a claim based on insinuation, and then deny that you made any such insinuation. You insulted everyone who made an implementation choice based on limited time and/or money. >> Your comments are insulting to me personally, and to any number of >> people whose customers demand something *other* than "what Glen wants". > > My sincerest apologies to all those customers who demand limited and > simplistic designs. I really had no idea. The reality is that many customers are *happy* with the status of many RADIUS dictionary implementations. Their priorities are *new* features that make business sense for them. Instead of facing that fact, you dismiss the customers as "demanding limited and simplistic designs", and you dismiss the implementors as "below-average high-school kids" for making decisions based on limited time/money budgets. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 27 Oct 2009 02:16:57 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'Dave Nelson'" , , "'IESG IESG'" Subject: RE: Proposed Resolution of Issue #318: REJECT Date: Tue, 27 Oct 2009 09:15:34 +0700 Message-ID: <048001ca56ab$67ead500$37c07f00$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpWfQitEzqQD5dJR6W/5JAq1a6AJAAKbK6Q Content-Language: en-us Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > ... > >>> In fact I hold the idea in great esteem; what I disvalue is > >>> the idea that data-driven models have to be implementable by > >>> below-average high-school kids. > ... > > If you would be kind enough to read my comment, you will see that I > said > > nothing whatsoever about my colleagues, let alone anything insulting > or > > dismissive. > > Nonsense. In case you had missed the major shift in software of the > last 20 years, many world-class software products are written *without* > a budget. i.e. Open Source projects, among others. Do you ever read what you write? I really wish you would, since the rest of us have to. I didn't say anything about budgets. > > Your comments are insulting to me personally, and to any number of > people whose customers demand something *other* than "what Glen wants". My sincerest apologies to all those customers who demand limited and simplistic designs. I really had no idea. > > > The fact is, however, (as Hannes has also pointed out) that > > the processing model assumed in the Design Guidelines draft is > simplistic > > and limited, if not outright primitive. If you wish to believe that > that > > fact makes the promoters of the model simplistic, limited and > primitive as > > well, that is your choice but I said nothing of the sort. > > Your statement was the equivalent of "have you stopped beating your > wife yet". > > It's insulting, dismissed, and damned well *intended* to be insulting > and dismissive. Thank you for interpreting my intentions for me. > > 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, 26 Oct 2009 22:51:16 +0000 Message-ID: <4AE627BD.3080202@deployingradius.com> Date: Mon, 26 Oct 2009 18:50:37 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Data Types defined in RFC 2865 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: ... > Moreover, within the value field of each attribute, RFC 2865 includes the > data type: > > a. "String" for type string. > b. "Address" for type address > c. "Value" for type integer > d. "Text" for type text These are issues of inconsistency and terminology in the RFCs. The RFCs have always used "address" for IPv4 addresses. Pretty much every implementation I've seen uses "ipaddr" as the name of that data type. Similarly with other data types. Where they are simple and often re-used, implementations define names that are *different* from the RFCs. e.g. "ipv6addr", and "ifid" for IPv6 address, and Interface Id. > No attributes of type time are defined in RFC 2865 or 2866. > > Looking at other RADIUS RFCs, the inclusion of the data type within the > value field is less consistent. Which is the source of the current discussion. If the documents had followed the practice of RFC 2865, they could have contained a section describing the data types that they were defining. They failed to do that, so we now have curious claims about addresses being IPv6... and not IPv6, all at the same time. (Depending on which argument best suits the current message, consistency be damned.) > For example, RFC 2867, includes a type of "Lost" in Section 4.2 for > Acct-Tunnel-Packets-Lost (4 octets). It seems likely that this attribute > was intended as type integer, rather than a "lost" data type. The implementations I know of use the type "integer" for this attribute. > In RFC 2869, the term "Value" is used in the value field for attributes that > are not integers (e.g. ARAP-Challenge-Response in Section 5.15). Agreed. > RFC 3162 seems closer to the conventions of RFC 2865 & 2866, although the > "Address" type used is 16 rather than 4 octets in size (IPv6 vs. IPv4). Which is to even the most naive reader, not the same as the "address" field defined in RFC 2865. Hence my recent errata. However, everyone "knows" that the Address type in RFC 3162 refers to IPv6 address. The only disagreement is the message-by-message reasoning of Glen, where it *is* an IPv6 address in one message, and simultaneously *not* a new IPv6 address in another. Personally, it matters less to me whether we call it "Address", or "IPv6 address", or "magic fairy dust". All I want is a consistent definition, so that I can talk about it without someone accusing me of inventing the definition. I would ask for a definition from Glen, but it's clear that his definitions are contradictory. 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, 26 Oct 2009 22:10:00 +0000 Message-ID: <4AE61E13.80906@deployingradius.com> Date: Mon, 26 Oct 2009 18:09:23 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: 'Dave Nelson' , radiusext@ops.ietf.org, 'IESG IESG' Subject: Re: Data Types defined in RFC 2865 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > OK, then how do you know the data type of a new attribute? Is the Value > field of the Login-IPv6-Host attribute of type "IPv6 address"? If so, do > _all_ attributes of type "IPv6 address" assign special meaning to the values > 0 & 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF? If not, then it's mot of type "IPv6 > address" is it? We can solve this problem by noting how it was solved in RFC 2865. As Glen keeps pointing out, the RFCs are definitive, and much better than anything anyone can come up with today. RFC 2865 defines an "address" type of 4 octets. This address type is used for NAS-IP-Address, which has no values of special meaning. The *exact same* address type is used for Framed-IP-Address, which *does* have values with special meaning. We can conclude: a) The Elder Gods were wrong: NAS-IP-Address and Framed-IP-Address are really of different types b) the Elder Gods were right: NAS-IP-Address and Framed-IP-Address are of the same type. If (a), then we need to issue an update to RFC 2865, correcting its flaws. (And possibly burning the Elder Gods at the stake for being wrong.) If (b), then we can follow the example of the Elder Gods, and believe that NAS-IPv6-Address, and Login-IPv6-Host are of the same type: IPv6 address. 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, 26 Oct 2009 21:14:56 +0000 Message-ID: <4AE61133.7050203@deployingradius.com> Date: Mon, 26 Oct 2009 17:14:27 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: "'Romascanu, Dan \(Dan\)'" , 'radext mailing list' Subject: Re: [Technical Errata Reported] RFC3162 (1923) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: >> RADEXT WG, >> >> Please advise on the Technical Errata below. > > The idea that the formal data type (if any) of a field in a RADIUS attribute > can be changed by changing the name of the field is so bizarre That it could only have been invented by Glen. > as to be > almost unbelievable. Even if it wasn't so incredibly BASIC, the idea is not > supported by any explicit text in any RADIUS-related RFC. RFC 2865 defines "address" as "32 bit value, most significant octet first.". RFC 3162 uses "address" to define a field as "The Address field is 16 octets.". The two statements disagree by the most naive reading of the definitions. The only way to claim that the RFC 3162 "Address" is compatible with the RFC 2865 "Address" is to assert that "4 == 16". But, of course, that would be too obviously delusional. So that isn't the best way to "refute" the errata. Instead, the best way is to completely misconstrue the errata, and claim that the discussion is about something else entirely! If you're trying to maintain a *sane* position, then a 16 octet "address" field is obviously incompatible with the definition of a 4-octet address field. The sane solution would be to: a) create a *new* definition of "ipv6 address" that is different from the 4-octet "address" field for IPv4 addresses,, or b) use the RFC 2865 type "string" for something that doesn't meet the "4 octet" definition of the "address" field. My prediction is that Glen will claim that there is no conflict. This is as much as admitting that he believes "4 == 16". 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, 26 Oct 2009 20:49:45 +0000 Message-ID: <4AE60B58.5080102@deployingradius.com> Date: Mon, 26 Oct 2009 16:49:28 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "dromasca@avaya.com" , "radiusext@ops.ietf.org" Subject: Re: Pending Errata for RADEXT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > The following errata relate to problems with RFC 4282 which were > uncovered in the IDNAbis effort. While the nature of the problems is > pointed out in the IDNAbis documents which have just completed IETF last > call, the solutions will require substantial revisions to RFC 4282 which > can only be accomplished in a -bis document. Therefore these errata > should probably either be classified as "pending update" or rejected: > > 1848, 1849, 1850 I would suggest "pending update". 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, 26 Oct 2009 20:47:39 +0000 Message-ID: <4AE60AD3.1070401@deployingradius.com> Date: Mon, 26 Oct 2009 16:47:15 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "dromasca@avaya.com" , "radiusext@ops.ietf.org" Subject: Re: [Technical Errata Reported] RFC3162 (1923) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Speaking for myself without my chair hat on, I am not sympathetic to > this errata. Neither am I, quite frankly. But it gives Glen a choice that is difficult to make: a) fix RFC 3162 to use the RFC 2865 data types or b) agree that IPv6 data types were defined by him in RADIUS, and that the design guidelines document doesn't "invent" that type I'm tired of specious and internally inconsistent arguments. I would like to make progress without being accused of thinking I'm god, or of inventing decade-old RADIUS traditions. 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, 26 Oct 2009 20:44:45 +0000 Message-ID: <4AE60A00.6040209@deployingradius.com> Date: Mon, 26 Oct 2009 16:43:44 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: 'Dave Nelson' , radiusext@ops.ietf.org, 'IESG IESG' Subject: Re: Proposed Resolution of Issue #318: REJECT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: ... >>> In fact I hold the idea in great esteem; what I disvalue is >>> the idea that data-driven models have to be implementable by >>> below-average high-school kids. ... > If you would be kind enough to read my comment, you will see that I said > nothing whatsoever about my colleagues, let alone anything insulting or > dismissive. Nonsense. In case you had missed the major shift in software of the last 20 years, many world-class software products are written *without* a budget. i.e. Open Source projects, among others. Your comments are insulting to me personally, and to any number of people whose customers demand something *other* than "what Glen wants". > The fact is, however, (as Hannes has also pointed out) that > the processing model assumed in the Design Guidelines draft is simplistic > and limited, if not outright primitive. If you wish to believe that that > fact makes the promoters of the model simplistic, limited and primitive as > well, that is your choice but I said nothing of the sort. Your statement was the equivalent of "have you stopped beating your wife yet". It's insulting, dismissed, and damned well *intended* to be insulting and dismissive. 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, 26 Oct 2009 14:24:16 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_922eec67-a767-4c76-b4a1-567f8c4cb414_" From: Bernard Aboba To: Glen Zorn , "David B. Nelson" CC: "radiusext@ops.ietf.org" Subject: RE: Data Types defined in RFC 2865 Date: Mon, 26 Oct 2009 07:23:38 -0700 <004e01ca5602$6d635470$4829fd50$@net> MIME-Version: 1.0 --_922eec67-a767-4c76-b4a1-567f8c4cb414_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Glen said: "Aside from that=2C even as a description of RADIUS =93as it is=94 the document fails=2C since it denigrates without justification (aside from the spurious =93code change=94 argument) the so-called =93compl= ex=94 attributes that have been part of RADIUS for almost a decade." The original goal was just to describe the complex attributes=2C not to den= igrate them. What specific text is problematic?=20 =85 = --_922eec67-a767-4c76-b4a1-567f8c4cb414_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Glen said:

"Aside from that=2C even as a description of RADIUS =93as it is=94 the document fails=2C since it denigrates without justification (aside from the spurious =93code change=94 argument) the so-called =93compl= ex=94 attributes that have been part of RADIUS for almost a decade."

The o= riginal goal was just to describe the complex attributes=2C not to denigrat= e them. =3B What specific text is problematic?
=85


= --_922eec67-a767-4c76-b4a1-567f8c4cb414_-- -- to 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, 26 Oct 2009 13:12:22 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , "David Mitton" Cc: , Subject: RE: [Technical Errata Reported] RFC3162 (1923) Date: Mon, 26 Oct 2009 20:11:11 +0700 Message-ID: <023801ca563d$e5c3d210$b14b7630$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0239_01CA5678.9222AA10" Thread-Index: AcpVtUd4ezxCS4JnSO27M+JW7DGFywAhpbpw Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_0239_01CA5678.9222AA10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard Aboba [mailto://bernard_aboba@hotmail.com]: writes: Speaking for myself without my chair hat on, I am not sympathetic to this errata. RFC 3162 uses the type "Address" in a context that makes it fairly clear that it is talking about a new data type for IPv6 addresses, rather than the existing IPv4 address type defined in RFC 2865. OK, just to satisfy my own mind, were you guys aware at the time that we were "defining a new RADIUS data type"? I know that I wasn't: I just thought that, gosh, "Address" is a good thing to call a field that holds an address. I don't recall any conversation about it amongst us (or in the WG) at the time; was it just so obvious that it didn't even bear mention? Put another way, am I the only moron on the planet that was completely unaware of the "Da Vinci Code" aspects of the RADIUS RFCs (esp. 2865)? Previous RADIUS RFCs did not "Update: RFC 2865" when introducing new data types, so I don't believe that this was required in RFC 3162 or any other document. Actually, had I understood that we were, in fact, altering the set of RADIUS data types at the time I probably would have suggested updating 2865. There are other instances in RFC 3162 we have been discussing, where the data type used may not be clear (such as Interface-ID), but this specific instance doesn't seem ambiguous. . ------=_NextPart_000_0239_01CA5678.9222AA10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

Speaking for myself without my chair hat on, I am not sympathetic to this errata. =

RFC 3162 uses the type "Address" in a context that makes it = fairly clear that it is talking about a new data type for IPv6 addresses, = rather than the existing IPv4 address type defined in RFC 2865. 
OK, just to satisfy my own mind, were you guys aware at = the time that we were “defining a new RADIUS data type”?  I know = that I wasn’t: I just thought that, gosh, “Address” is a good = thing to call a field that holds an address.  I don’t recall any conversation about it amongst us (or in the WG) at the time; was it just = so obvious that it didn’t even bear mention?  Put another way, = am I the only moron on the planet that was completely unaware of the “Da = Vinci Code” aspects of the RADIUS RFCs (esp. 2865)?
Previous RADIUS RFCs did not "Update: RFC 2865" when introducing new = data types, so I don't believe that this was required in RFC 3162 or any = other document.
Actually, had I understood that we were, in fact, = altering the set of RADIUS data types at the time I probably would have suggested = updating 2865…
There are other instances in RFC 3162 we have been discussing, where the data = type used may not be clear (such as Interface-ID), but this specific instance doesn't seem ambiguous.
…

------=_NextPart_000_0239_01CA5678.9222AA10-- -- to 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, 26 Oct 2009 13:06:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA563D.074131B2" Subject: RE: [Technical Errata Reported] RFC3162 (1923) Date: Mon, 26 Oct 2009 14:05:44 +0100 Message-ID: Thread-Topic: [Technical Errata Reported] RFC3162 (1923) Thread-Index: AcpVtLxbL7pfjWfkRZKmBhrfVdKt+wAYW9GQAAk0CCAAAHFRgA== From: "Romascanu, Dan (Dan)" To: "Glen Zorn" Cc: "Bernard Aboba" , This is a multi-part message in MIME format. ------_=_NextPart_001_01CA563D.074131B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Of course.=20 =20 The reasons will be listed in the motivation. If somebody disagrees with the reasons exposed I expect comments on this.=20 =20 Dan =20 ________________________________ From: Glen Zorn [mailto:glenzorn@comcast.net]=20 Sent: Monday, October 26, 2009 2:57 PM To: Romascanu, Dan (Dan) Cc: 'Bernard Aboba'; radiusext@ops.ietf.org Subject: RE: [Technical Errata Reported] RFC3162 (1923) =09 =09 Dan Romascanu [mailto://dromasca@avaya.com] writes: =09 =09 Based on the opinions expressed by you and Glen, do I hear a consensus to reject this errata?=20 I think that Bernard & I agree that it should be rejected, though for different reasons. Whether that makes a consensus is a matter of opinion, I suppose. =20 Dan =20 ... ------_=_NextPart_001_01CA563D.074131B2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Of=20 course.
 
The reasons will be listed in the motivation. If = somebody=20 disagrees with the reasons exposed I expect comments on this.=20
 
Dan
 

From: Glen Zorn = [mailto:glenzorn@comcast.net]=20
Sent: Monday, October 26, 2009 2:57 PM
To: = Romascanu, Dan=20 (Dan)
Cc: 'Bernard Aboba'; = radiusext@ops.ietf.org
Subject:=20 RE: [Technical Errata Reported] RFC3162 (1923)

Dan=20 Romascanu [mailto://dromasca@avaya.com]=20 writes:

Based=20 on the opinions expressed by you and Glen, do I hear a consensus to = reject=20 this errata?

I=20 think that Bernard & I agree that it should be rejected, though = for=20 different reasons.  Whether that makes a consensus is a matter of = opinion, I suppose.

 

Dan

 

…

------_=_NextPart_001_01CA563D.074131B2-- -- to 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, 26 Oct 2009 12:57:48 +0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" Cc: "'Bernard Aboba'" , Subject: RE: [Technical Errata Reported] RFC3162 (1923) Date: Mon, 26 Oct 2009 19:56:40 +0700 Message-ID: <021b01ca563b$cba0e960$62e2bc20$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_021C_01CA5676.77FFC160" Thread-Index: AcpVtLxbL7pfjWfkRZKmBhrfVdKt+wAYW9GQAAk0CCA= Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_021C_01CA5676.77FFC160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dan Romascanu [mailto://dromasca@avaya.com] writes: Based on the opinions expressed by you and Glen, do I hear a consensus to reject this errata? I think that Bernard & I agree that it should be rejected, though for different reasons. Whether that makes a consensus is a matter of opinion, I suppose. Dan . ------=_NextPart_000_021C_01CA5676.77FFC160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan Romascanu [mailto://dromasca@avaya.com] = writes:

Based on the opinions expressed by you and Glen, do I hear a consensus to reject this errata?

I think that Bernard & I agree that it should be = rejected, though for different reasons.  Whether that makes a consensus is a matter = of opinion, I suppose.

 

Dan=

 =

…

------=_NextPart_000_021C_01CA5676.77FFC160-- -- to 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, 26 Oct 2009 08:29:53 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5616.5147CC54" Subject: RE: [Technical Errata Reported] RFC3162 (1923) Date: Mon, 26 Oct 2009 09:28:40 +0100 Message-ID: Thread-Topic: [Technical Errata Reported] RFC3162 (1923) Thread-Index: AcpVtLxbL7pfjWfkRZKmBhrfVdKt+wAYW9GQ From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5616.5147CC54 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on the opinions expressed by you and Glen, do I hear a consensus to reject this errata?=20 =20 Dan =20 ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Sunday, October 25, 2009 10:50 PM To: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: [Technical Errata Reported] RFC3162 (1923) =09 =09 Speaking for myself without my chair hat on, I am not sympathetic to this errata.=20 =09 RFC 3162 uses the type "Address" in a context that makes it fairly clear that it is talking about a new data type for IPv6 addresses, rather than the existing IPv4 address type defined in RFC 2865. =20 =09 Previous RADIUS RFCs did not "Update: RFC 2865" when introducing new data types, so I don't believe that this was required in RFC 3162 or any other document.=20 =09 There are other instances in RFC 3162 we have been discussing, where the data type used may not be clear (such as Interface-ID), but this specific instance doesn't seem ambiguous.=20 =09 > Subject: FW: [Technical Errata Reported] RFC3162 (1923) > Date: Sun, 25 Oct 2009 11:27:28 +0100 > From: dromasca@avaya.com > To: radiusext@ops.ietf.org >=20 > RADEXT WG, >=20 > Please advise on the Technical Errata below.=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > RFC Errata System > Sent: Thursday, October 22, 2009 3:19 PM > To: bernarda@microsoft.com; gwz@cisco.com; iesg@iesg.org > Cc: aland@freeradius.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC3162 (1923) >=20 >=20 > The following errata report has been submitted for RFC3162, "RADIUS and > IPv6". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3162&eid=3D1923 >=20 > -------------------------------------- > Type: Technical > Reported by: Alan DeKok >=20 > Section: 2.1 >=20 > Original Text > ------------- > Address >=20 > The Address field is 16 octets. >=20 > Corrected Text > -------------- > String >=20 > The field is 16 octets >=20 > Notes > ----- > As Glen notes in: >=20 > http://ops.ietf.org/lists/radiusext/2009/msg00540.html >=20 > Using "ipv6 address" for a data type in RADIUS is wrong. >=20 > RFC 3162 (among others Glen wrote) contradict his current position. > Those documents use data types for the "value" field of RADIUS > attributes that have not been defined in RFC 2865. As such, they should > either: >=20 > a) make it clear that they define a new data type, and be marked as > "Updates: 2865" >=20 > or >=20 > b) use the data types in RFC 2865. >=20 > Or even better, maintain an internally consistent set of beliefs, and > leave RFC 3162 alone. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please use > "Reply All" to discuss whether it should be verified or rejected. When a > decision is reached, the verifying party (IESG) can log in to change the > status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC3162 (draft-aboba-radius-ipv6-10) > -------------------------------------- > Title : RADIUS and IPv6 > Publication Date : August 2001 > Author(s) : B. Aboba, G. Zorn, D. Mitton > Category : PROPOSED STANDARD > Source : Legacy > Area : Legacy > Stream : IETF > Verifying Party : IESG >=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: =09 ------_=_NextPart_001_01CA5616.5147CC54 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Based on the=20 opinions expressed by you and Glen, do I hear a consensus to reject this = errata?=20
 
Dan
 

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: Sunday, October = 25, 2009=20 10:50 PM
To: Romascanu, Dan (Dan);=20 radiusext@ops.ietf.org
Subject: RE: [Technical Errata = Reported]=20 RFC3162 (1923)

Speaking for myself without my chair hat on, I am not = sympathetic=20 to this errata.

RFC 3162 uses the type "Address" in a context = that=20 makes it fairly clear that it is talking about a new data type for = IPv6=20 addresses, rather than the existing IPv4 address type defined in RFC=20 2865. 

Previous RADIUS RFCs did not "Update: RFC 2865" = when=20 introducing new data types, so I don't believe that this was required = in RFC=20 3162 or any other document.

There are other instances in RFC = 3162 we=20 have been discussing, where the data type used may not be clear (such = as=20 Interface-ID), but this specific instance doesn't seem ambiguous. =

>=20 Subject: FW: [Technical Errata Reported] RFC3162 (1923)
> Date: = Sun, 25=20 Oct 2009 11:27:28 +0100
> From: dromasca@avaya.com
> To:=20 radiusext@ops.ietf.org
>
> RADEXT WG,
>
> = Please=20 advise on the Technical Errata below.
>
> Thanks and=20 Regards,
>
> Dan
>
>
>
> = -----Original=20 Message-----
> From: iesg-bounces@ietf.org=20 [mailto:iesg-bounces@ietf.org] On Behalf Of
> RFC Errata = System
>=20 Sent: Thursday, October 22, 2009 3:19 PM
> To: = bernarda@microsoft.com;=20 gwz@cisco.com; iesg@iesg.org
> Cc: aland@freeradius.org;=20 rfc-editor@rfc-editor.org
> Subject: [Technical Errata Reported] = RFC3162=20 (1923)
>
>
> The following errata report has been=20 submitted for RFC3162, "RADIUS and
> IPv6".
>
>=20 --------------------------------------
> You may review the = report below=20 and at:
>=20 = http://www.rfc-editor.org/errata_search.php?rfc=3D3162&eid=3D1923
= >=20
> --------------------------------------
> Type:=20 Technical
> Reported by: Alan DeKok = <aland@freeradius.org>
>=20
> Section: 2.1
>
> Original Text
>=20 -------------
> Address
>
> The Address field is 16 = octets.
>
> Corrected Text
> --------------
> = String
>
> The field is 16 octets
>
> = Notes
>=20 -----
> As Glen notes in:
>
>=20 http://ops.ietf.org/lists/radiusext/2009/msg00540.html
> =
> Using=20 "ipv6 address" for a data type in RADIUS is wrong.
>
> = RFC 3162=20 (among others Glen wrote) contradict his current position.
> = Those=20 documents use data types for the "value" field of RADIUS
> = attributes=20 that have not been defined in RFC 2865. As such, they should
>=20 either:
>
> a) make it clear that they define a new data = type,=20 and be marked as
> "Updates: 2865"
>
> or
> =
>=20 b) use the data types in RFC 2865.
>
> Or even better, = maintain=20 an internally consistent set of beliefs, and
> leave RFC 3162=20 alone.
>
> Instructions:
> -------------
> = This=20 errata is currently posted as "Reported". If necessary, please = use
>=20 "Reply All" to discuss whether it should be verified or rejected. When = a
> decision is reached, the verifying party (IESG) can log in = to change=20 the
> status and edit the report, if necessary.
> =
>=20 --------------------------------------
> RFC3162=20 (draft-aboba-radius-ipv6-10)
>=20 --------------------------------------
> Title : RADIUS and = IPv6
>=20 Publication Date : August 2001
> Author(s) : B. Aboba, G. Zorn, = D.=20 Mitton
> Category : PROPOSED STANDARD
> Source : = Legacy
>=20 Area : Legacy
> Stream : IETF
> Verifying Party : = IESG
>=20
> --
> to unsubscribe send a message to=20 radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in = a single=20 line as the message text body.
> archive:=20 <http://psg.com/lists/radiusext/>
------_=_NextPart_001_01CA5616.5147CC54-- -- to 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, 26 Oct 2009 06:06:55 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , "'David B. Nelson'" Cc: Subject: RE: Data Types defined in RFC 2865 Date: Mon, 26 Oct 2009 13:06:00 +0700 Message-ID: <004e01ca5602$6d635470$4829fd50$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01CA563D.19C22C70" Thread-Index: AcpVuAdmLIA8U5HkQnKSErnx27A84wAQ5m8g Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_004F_01CA563D.19C22C70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard Aboba [mailto://bernard_aboba@hotmail.com] writes: David Nelson said: > In seeking to debunk some of these data model additions, you are apparently > attempting to build a case for the precedence of using the RADIUS String > data type to contain non-self-describing data structures. This has been a > point of debate in the RADEXT WG for several years. The WG consensus is > captured in the Design Guidelines draft. The String data type should be > used for actual strings, or for opaque blobs of binary data, for use in some > other protocol component, e.g. EAP. There are specific exemptions to this > recommendation that are spelled out in the draft. In many ways, this argument has long been Overtaken By Events (OBE). RADIUS is what it is, and very widely deployed protocol. The Design Guidelines only attempts to describe RADIUS as it is, not what it should become. OK, so now I'm completely confused. If the purpose of the document isn't to give guidance regarding the design of future attributes, what is it? Aside from that, even as a description of RADIUS "as it is" the document fails, since it denigrates without justification (aside from the spurious "code change" argument) the so-called "complex" attributes that have been part of RADIUS for almost a decade. . ------=_NextPart_000_004F_01CA563D.19C22C70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

David Nelson said:

> In seeking to debunk some of these data model additions, you are apparently
> attempting to build a case for the precedence of using the RADIUS = String
> data type to contain non-self-describing data structures. This has = been a
> point of debate in the RADEXT WG for several years. The WG = consensus is
> captured in the Design Guidelines draft. The String data type = should be
> used for actual strings, or for opaque blobs of binary data, for = use in some
> other protocol component, e.g. EAP. There are specific exemptions = to this
> recommendation that are spelled out in the draft.

In many ways, this argument has long been Overtaken By Events = (OBE).  RADIUS
is what it is, and very widely deployed protocol.  The Design = Guidelines only
attempts to describe RADIUS as it is, not what it should become.

 

OK, so now I’m completely confused.  If the = purpose of the document isn’t to give guidance regarding the design of = future attributes, what is it?  Aside from that, even as a description of = RADIUS “as it is” the document fails, since it denigrates without = justification (aside from the spurious “code change” argument) the = so-called “complex” attributes that have been part of RADIUS for almost a decade.

…

------=_NextPart_000_004F_01CA563D.19C22C70-- -- to 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, 26 Oct 2009 05:12:01 +0000 From: "Glen Zorn" To: Cc: "'Bernard Aboba'" , Subject: RE: Pending Errata for RADEXT Date: Mon, 26 Oct 2009 12:11:01 +0700 Message-ID: <003701ca55fa$be3c5390$3ab4fab0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01CA5635.6A9B2B90" Thread-Index: AcpV8ILktolxKwEJQ2ePwvpP/DT/WQAB5zQw Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_0038_01CA5635.6A9B2B90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard Aboba ]mailto://bernard_aboba@hotmail.com] writes: From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Monday, October 26, 2009 10:53 AM To: dromasca@avaya.com; radiusext@ops.ietf.org Subject: Re: Pending Errata for RADEXT Speaking only for myself, the follow errata look reasonable and should be accepted: 420 Agree. 867 Agree. 1407 Agree. The following errata relate to problems with RFC 4282 which were uncovered in the IDNAbis effort. While the nature of the problems is pointed out in the IDNAbis documents which have just completed IETF last call, the solutions will require substantial revisions to RFC 4282 which can only be accomplished in a -bis document. Therefore these errata should probably either be classified as "pending update" or rejected: 1848, 1849, 1850 I think that all three of these should be rejected. Although there may be a point to 1849, the notes point to an I-D, not an RFC, which itself does not suggest site-specific handling of bidirectional character sets. 1848 may make some sense (leaving aside the pompous declaration that "Much of RFC 4282 is simply wrong") but 1850 is pure nonsense, as I pointed out at some length awhile back. Pending errata for RADEXT _____ * To: "radext mailing list" > * Subject: Pending errata for RADEXT * From: "Romascanu, Dan (Dan)" > * Date: Sun, 25 Oct 2009 11:31:56 +0100 _____ RADEXT WG, There are a number of pending errata related to RADIUS that I have asked recommendation in the past for the WG. Please process and advice how for resolutions on these errata. Some of them are rather simple, some other may require some more thought. The IDs (in the order of their occurrences in the tracker) are: 1607, 420, 1469, 753, 1848, 1849, 1850, 867, 1407. Thanks and Regards, Dan ------=_NextPart_000_0038_01CA5635.6A9B2B90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bernard Aboba ]mailto://bernard_aboba@hotmai= l.com] writes:

 

From:= = owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard = Aboba
Sent: Monday, October 26, 2009 10:53 AM
To: dromasca@avaya.com; radiusext@ops.ietf.org
Subject: Re: Pending Errata for RADEXT

 

Speaking only for myself, the follow = errata look reasonable and should be accepted:

420

Agree.


867

Agree.


1407

Agree.


The following errata relate to problems with RFC 4282 which were = uncovered in the IDNAbis effort.  While the nature of the problems is pointed = out in the IDNAbis documents which have just completed IETF last call, the = solutions will require substantial revisions to RFC 4282 which can only be = accomplished in a -bis document.  Therefore these errata should probably either = be classified as "pending update" or rejected:

1848, 1849, 1850

I think that all = three of these should be rejected.  Although there may be a point to 1849, = the notes point to an I-D, not an RFC, which itself does not suggest = site-specific handling of bidirectional character sets.  1848 may make some sense (leaving aside the pompous declaration that “Much of RFC 4282 is = simply wrong”) but 1850 is pure nonsense, as I pointed out at some length = awhile back.








Pending errata = for RADEXT

RADEXT WG, 



There are a number of pending errata related to RADIUS that I have =
asked

recommendation in the past for the WG. Please process and advice how =
for

resolutions on these errata. Some of them are rather simple, some =
other

may require some more thought. 



The IDs (in the order of their occurrences in the tracker) are: =
1607,

420, 1469, 753, 1848, 1849, 1850, 867, 1407. 



Thanks and Regards,



Dan

 =

 

------=_NextPart_000_0038_01CA5635.6A9B2B90-- -- to 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, 26 Oct 2009 04:25:50 +0000 From: "Dave Nelson" To: , Subject: RE: Pending Errata for RADEXT Date: Mon, 26 Oct 2009 00:25:24 -0400 Message-ID: <2D201A0818854A5E8B886C8A5A3E2B08@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcpV8HECVpuir9h5SIqBwN+2W+tXqQAA5i/g Bernard Aboba writes... > Speaking only for myself, the follow errata look reasonable > and should be accepted: > > 420 > 867 > 1407 I concur on 867 and 1407. I have no opinion on 420. -- to 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, 26 Oct 2009 03:54:58 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_2d154e22-ba97-45e5-9c7f-cd7a6bca6ff1_" From: Bernard Aboba To: "dromasca@avaya.com" , "radiusext@ops.ietf.org" Subject: Re: Pending Errata for RADEXT Date: Sun, 25 Oct 2009 20:53:29 -0700 MIME-Version: 1.0 --_2d154e22-ba97-45e5-9c7f-cd7a6bca6ff1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking only for myself=2C the follow errata look reasonable and should be= accepted: 420 867 1407 The following errata relate to problems with RFC 4282 which were uncovered = in the IDNAbis effort. While the nature of the problems is pointed out in = the IDNAbis documents which have just completed IETF last call=2C the solut= ions will require substantial revisions to RFC 4282 which can only be accom= plished in a -bis document. Therefore these errata should probably either = be classified as "pending update" or rejected: 1848=2C 1849=2C 1850 Pending errata for RADEXT To: "radext mailing list" Subject: Pending errata f= or RADEXTFrom: "Romascanu=2C Dan (Dan)" Date: Sun=2C 25= Oct 2009 11:31:56 +0100 RADEXT WG=2C=20 There are a number of pending errata related to RADIUS that I have asked recommendation in the past for the WG. Please process and advice how for resolutions on these errata. Some of them are rather simple=2C some other may require some more thought.=20 The IDs (in the order of their occurrences in the tracker) are: 1607=2C 420=2C 1469=2C 753=2C 1848=2C 1849=2C 1850=2C 867=2C 1407.=20 Thanks and Regards=2C Dan = --_2d154e22-ba97-45e5-9c7f-cd7a6bca6ff1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking only for myself=2C the follow errata look reasonable and should be= accepted:

420
867
1407

The following errata relate to = problems with RFC 4282 which were uncovered in the IDNAbis effort. =3B = While the nature of the problems is pointed out in the IDNAbis documents wh= ich have just completed IETF last call=2C the solutions will require substa= ntial revisions to RFC 4282 which can only be accomplished in a -bis docume= nt. =3B Therefore these errata should probably either be classified as = "pending update" or rejected:

1848=2C 1849=2C 1850






Pending errata for RADEXT

RADEXT WG=2C 

There are a number of pending errata related to R=
ADIUS that I have asked
recommendation in the past for the WG. Please pr=
ocess and advice how for
resolutions on these errata. Some of them are r=
ather simple=2C some other
may require some more thought. 

The ID=
s (in the order of their occurrences in the tracker) are: 1607=2C
420=2C=
 1469=2C 753=2C 1848=2C 1849=2C 1850=2C 867=2C 1407. 

Thanks and Reg=
ards=2C

Dan

<= tbody>

= --_2d154e22-ba97-45e5-9c7f-cd7a6bca6ff1_-- -- to 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, 25 Oct 2009 21:12:01 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_f3e1fb29-a23f-41db-8e6e-753a4f190924_" From: Bernard Aboba To: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: RE: Data Types defined in RFC 2865 Date: Sun, 25 Oct 2009 14:11:16 -0700 <2C5E8C11AE78494CB14CA6C1D32D3B13@NEWTON603> MIME-Version: 1.0 --_f3e1fb29-a23f-41db-8e6e-753a4f190924_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David Nelson said:=20 > In seeking to debunk some of these data model additions=2C you are appare= ntly > attempting to build a case for the precedence of using the RADIUS String > data type to contain non-self-describing data structures. This has been = a > point of debate in the RADEXT WG for several years. The WG consensus is > captured in the Design Guidelines draft. The String data type should be > used for actual strings=2C or for opaque blobs of binary data=2C for use = in some > other protocol component=2C e.g. EAP. There are specific exemptions to t= his > recommendation that are spelled out in the draft. In many ways=2C this argument has long been Overtaken By Events (OBE). RAD= IUS is what it is=2C and very widely deployed protocol. The Design Guidelines = only attempts to describe RADIUS as it is=2C not what it should become.=20 The job of defining what RADIUS could become is the task of the Extended Attributes document. Given that all IESG DISCUSSes have been cleared=2C it's now time for the WG to get past these (largely irrelevant) arguments and move on.=20 = --_f3e1fb29-a23f-41db-8e6e-753a4f190924_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David Nelson said:

>=3B In seeking to debunk some of these data m= odel additions=2C you are apparently
>=3B attempting to build a case f= or the precedence of using the RADIUS String
>=3B data type to contain= non-self-describing data structures. This has been a
>=3B point of d= ebate in the RADEXT WG for several years. The WG consensus is
>=3B ca= ptured in the Design Guidelines draft. The String data type should be
&= gt=3B used for actual strings=2C or for opaque blobs of binary data=2C for = use in some
>=3B other protocol component=2C e.g. EAP. There are spec= ific exemptions to this
>=3B recommendation that are spelled out in th= e draft.

In many ways=2C this argument has long been Overtaken By Ev= ents (OBE). =3B RADIUS
is what it is=2C and very widely deployed pro= tocol. =3B The Design Guidelines only
attempts to describe RADIUS as= it is=2C not what it should become.

The job of defining what RADIU= S could become is the task of the Extended
Attributes document. =3B = Given that all IESG DISCUSSes have been cleared=2C
it's now time for the= WG to get past these (largely irrelevant) arguments
and move on.
= = --_f3e1fb29-a23f-41db-8e6e-753a4f190924_-- -- to 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, 25 Oct 2009 20:51:15 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_96ab7bc3-c9f1-4ab0-9777-16d78db17038_" From: Bernard Aboba To: "dromasca@avaya.com" , "radiusext@ops.ietf.org" Subject: RE: [Technical Errata Reported] RFC3162 (1923) Date: Sun, 25 Oct 2009 13:49:59 -0700 MIME-Version: 1.0 --_96ab7bc3-c9f1-4ab0-9777-16d78db17038_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking for myself without my chair hat on=2C I am not sympathetic to this= errata.=20 RFC 3162 uses the type "Address" in a context that makes it fairly clear th= at it is talking about a new data type for IPv6 addresses=2C rather than th= e existing IPv4 address type defined in RFC 2865. =20 Previous RADIUS RFCs did not "Update: RFC 2865" when introducing new data t= ypes=2C so I don't believe that this was required in RFC 3162 or any other = document.=20 There are other instances in RFC 3162 we have been discussing=2C where the = data type used may not be clear (such as Interface-ID)=2C but this specific= instance doesn't seem ambiguous.=20 > Subject: FW: [Technical Errata Reported] RFC3162 (1923) > Date: Sun=2C 25 Oct 2009 11:27:28 +0100 > From: dromasca@avaya.com > To: radiusext@ops.ietf.org >=20 > RADEXT WG=2C >=20 > Please advise on the Technical Errata below.=20 >=20 > Thanks and Regards=2C >=20 > Dan >=20 >=20 >=20 > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > RFC Errata System > Sent: Thursday=2C October 22=2C 2009 3:19 PM > To: bernarda@microsoft.com=3B gwz@cisco.com=3B iesg@iesg.org > Cc: aland@freeradius.org=3B rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC3162 (1923) >=20 >=20 > The following errata report has been submitted for RFC3162=2C "RADIUS and > IPv6". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3162&eid=3D1923 >=20 > -------------------------------------- > Type: Technical > Reported by: Alan DeKok >=20 > Section: 2.1 >=20 > Original Text > ------------- > Address >=20 > The Address field is 16 octets. >=20 > Corrected Text > -------------- > String >=20 > The field is 16 octets >=20 > Notes > ----- > As Glen notes in: >=20 > http://ops.ietf.org/lists/radiusext/2009/msg00540.html >=20 > Using "ipv6 address" for a data type in RADIUS is wrong. >=20 > RFC 3162 (among others Glen wrote) contradict his current position. > Those documents use data types for the "value" field of RADIUS > attributes that have not been defined in RFC 2865. As such=2C they shoul= d > either: >=20 > a) make it clear that they define a new data type=2C and be marked as > "Updates: 2865" >=20 > or >=20 > b) use the data types in RFC 2865. >=20 > Or even better=2C maintain an internally consistent set of beliefs=2C a= nd > leave RFC 3162 alone. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary=2C please use > "Reply All" to discuss whether it should be verified or rejected. When a > decision is reached=2C the verifying party (IESG) can log in to change th= e > status and edit the report=2C if necessary.=20 >=20 > -------------------------------------- > RFC3162 (draft-aboba-radius-ipv6-10) > -------------------------------------- > Title : RADIUS and IPv6 > Publication Date : August 2001 > Author(s) : B. Aboba=2C G. Zorn=2C D. Mitton > Category : PROPOSED STANDARD > Source : Legacy > Area : Legacy > Stream : IETF > Verifying Party : IESG >=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: = --_96ab7bc3-c9f1-4ab0-9777-16d78db17038_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking for myself without my chair hat on=2C I am not sympathetic to this= errata.

RFC 3162 uses the type "Address" in a context that makes i= t fairly clear that it is talking about a new data type for IPv6 addresses= =2C rather than the existing IPv4 address type defined in RFC 2865. =3B=

Previous RADIUS RFCs did not "Update: RFC 2865" when introducing n= ew data types=2C so I don't believe that this was required in RFC 3162 or a= ny other document.

There are other instances in RFC 3162 we have be= en discussing=2C where the data type used may not be clear (such as Interfa= ce-ID)=2C but this specific instance doesn't seem ambiguous.

>=3B= Subject: FW: [Technical Errata Reported] RFC3162 (1923)
>=3B Date: Su= n=2C 25 Oct 2009 11:27:28 +0100
>=3B From: dromasca@avaya.com
>= =3B To: radiusext@ops.ietf.org
>=3B
>=3B RADEXT WG=2C
>=3B =
>=3B Please advise on the Technical Errata below.
>=3B
>= =3B Thanks and Regards=2C
>=3B
>=3B Dan
>=3B
>=3B >=3B
>=3B -----Original Message-----
>=3B From: iesg-bounces@= ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of
>=3B RFC Errata S= ystem
>=3B Sent: Thursday=2C October 22=2C 2009 3:19 PM
>=3B To: = bernarda@microsoft.com=3B gwz@cisco.com=3B iesg@iesg.org
>=3B Cc: alan= d@freeradius.org=3B rfc-editor@rfc-editor.org
>=3B Subject: [Technical= Errata Reported] RFC3162 (1923)
>=3B
>=3B
>=3B The follow= ing errata report has been submitted for RFC3162=2C "RADIUS and
>=3B I= Pv6".
>=3B
>=3B --------------------------------------
>=3B= You may review the report below and at:
>=3B http://www.rfc-editor.or= g/errata_search.php?rfc=3D3162&=3Beid=3D1923
>=3B
>=3B ------= --------------------------------
>=3B Type: Technical
>=3B Report= ed by: Alan DeKok <=3Baland@freeradius.org>=3B
>=3B
>=3B Sec= tion: 2.1
>=3B
>=3B Original Text
>=3B -------------
>= =3B Address
>=3B
>=3B The Address field is 16 octets.>=3B
>=3B Corrected Text
>=3B --------------
>=3B Strin= g
>=3B
>=3B The field is 16 octets
>=3B
>=3B Notes<= br>>=3B -----
>=3B As Glen notes in:
>=3B
>=3B http://ops= .ietf.org/lists/radiusext/2009/msg00540.html
>=3B
>=3B Using "ip= v6 address" for a data type in RADIUS is wrong.
>=3B
>=3B RFC 31= 62 (among others Glen wrote) contradict his current position.
>=3B Tho= se documents use data types for the "value" field of RADIUS
>=3B attri= butes that have not been defined in RFC 2865. As such=2C they should
&g= t=3B either:
>=3B
>=3B a) make it clear that they define a new d= ata type=2C and be marked as
>=3B "Updates: 2865"
>=3B
>=3B= or
>=3B
>=3B b) use the data types in RFC 2865.
>=3B >=3B Or even better=2C maintain an internally consistent set of belief= s=2C and
>=3B leave RFC 3162 alone.
>=3B
>=3B Instructions:=
>=3B -------------
>=3B This errata is currently posted as "Repo= rted". If necessary=2C please use
>=3B "Reply All" to discuss whether = it should be verified or rejected. When a
>=3B decision is reached=2C = the verifying party (IESG) can log in to change the
>=3B status and ed= it the report=2C if necessary.
>=3B
>=3B ----------------------= ----------------
>=3B RFC3162 (draft-aboba-radius-ipv6-10)
>=3B -= -------------------------------------
>=3B Title : RADIU= S and IPv6
>=3B Publication Date : August 2001
>=3B Author(s) = : B. Aboba=2C G. Zorn=2C D. Mitton
>=3B Category = : PROPOSED STANDARD
>=3B Source : Legacy
>=3B Area = : Legacy
>=3B Stream : IETF
>=3B Verif= ying Party : IESG
>=3B
>=3B --
>=3B to unsubscribe send= a message to radiusext-request@ops.ietf.org with
>=3B the word 'unsub= scribe' in a single line as the message text body.
>=3B archive: <= =3Bhttp://psg.com/lists/radiusext/>=3B
= --_96ab7bc3-c9f1-4ab0-9777-16d78db17038_-- -- to 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, 25 Oct 2009 17:32:32 +0000 From: "Glen Zorn" To: "'Dave Nelson'" , Cc: "'IESG IESG'" Subject: RE: Data Types defined in RFC 2865 Date: Mon, 26 Oct 2009 00:31:05 +0700 Message-ID: <04d101ca5598$fb1a8690$f14f93b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgCL9BjQAAHOdUAADquKsAADM2FQ Content-Language: en-us Dave Nelson [mailto://d.b.nelson@comcast.net] writes: > Glen Zorn writes... > > > So am I to understand that, despite the multitude of counterexamples > > and the lack of any explicit text even suggesting such in any RADIUS- > > related RFC, you are claiming that the name of the V field in the TLV > > construct denotes a formal data type (a thing apparently known only > to > > some secret society holding the same "internally consistent belief > > system" (thought police, anyone? ;-)? > > Well, your previous posting claiming to be able to implement an > advanced > server implementation Actually, I didn't claim to be able to implement it myself, nor to have done so, The server I have was done by people a _lot_ smarter than me. > that intuits the syntax of a data model from the > data > stream itself notwithstanding, Isn't that the definition of a data-driven parser? > RADIUS *has* a formal, written data > model. > Many implementations rely on it. It's a very simple data model. So simple and so unnecessary (probably why it is so rarely used). One of the beauties of the TLV format is that the type completely defines the value. > > I think this extended discussion of what constitutes a "formal" > definition > of a new data type in the data model constitutes "protocol lawyering", > a > debate about form without any substance. OK, then how do you know the data type of a new attribute? Is the Value field of the Login-IPv6-Host attribute of type "IPv6 address"? If so, do _all_ attributes of type "IPv6 address" assign special meaning to the values 0 & 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF? If not, then it's mot of type "IPv6 address" is it? A set of formal data types without any way to distinguish between them is useless, except for use as a bludgeon. If you really want to develop a real data model for RADIUS, shouldn't it clarify the protocol operation instead of muddying it? > > In seeking to debunk some of these data model additions, you are > apparently > attempting to build a case for the precedence of using the RADIUS > String > data type to contain non-self-describing data structures. Not at all. As I mentioned above, RADIUS attributes are completely defined by the Type and the description. > This has > been a > point of debate in the RADEXT WG for several years. The WG consensus > is > captured in the Design Guidelines draft. "Consensus" in this WG is, quite frankly, a joke. > The String data type should > be > used for actual strings, or for opaque blobs of binary data, for use in > some > other protocol component, e.g. EAP. There are specific exemptions to > this > recommendation that are spelled out in the draft. > > > > -- > to 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: Sun, 25 Oct 2009 16:57:17 +0000 From: "Glen Zorn" To: "'Dave Nelson'" , Cc: "'IESG IESG'" Subject: RE: Proposed Resolution of Issue #318: REJECT Date: Sun, 25 Oct 2009 23:55:39 +0700 Message-ID: <04ca01ca5594$04d3a360$0e7aea20$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQAABKTkAAEYxFQAAMs9dAAACs5yAAAKY6kAAA1kuAAAKpBWA= Content-Language: en-us > Glen Zorn writes... > > > > I suspect you don't attach much value (or even credence) > > > to this data-driven model on the server side, but many in > > > the RADIUS community do. > > > > In fact I hold the idea in great esteem; what I disvalue is > > the idea that data-driven models have to be implementable by > > below-average high-school kids. > > There is no need for you to be so dismissive of, and insulting to, your > colleagues, who form the rough consensus on this issue. If you would be kind enough to read my comment, you will see that I said nothing whatsoever about my colleagues, let alone anything insulting or dismissive. The fact is, however, (as Hannes has also pointed out) that the processing model assumed in the Design Guidelines draft is simplistic and limited, if not outright primitive. If you wish to believe that that fact makes the promoters of the model simplistic, limited and primitive as well, that is your choice but I said nothing of the sort. > > > -- > to 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: Sun, 25 Oct 2009 15:50:45 +0000 From: "Dave Nelson" To: Cc: "'IESG IESG'" Subject: RE: Data Types defined in RFC 2865 Date: Sun, 25 Oct 2009 11:49:59 -0400 Message-ID: <2C5E8C11AE78494CB14CA6C1D32D3B13@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgCL9BjQAAHOdUAADquKsA== Glen Zorn writes... > So am I to understand that, despite the multitude of counterexamples > and the lack of any explicit text even suggesting such in any RADIUS- > related RFC, you are claiming that the name of the V field in the TLV > construct denotes a formal data type (a thing apparently known only to > some secret society holding the same "internally consistent belief > system" (thought police, anyone? ;-)? Well, your previous posting claiming to be able to implement an advanced server implementation that intuits the syntax of a data model from the data stream itself notwithstanding, RADIUS *has* a formal, written data model. Many implementations rely on it. It's a very simple data model. I think this extended discussion of what constitutes a "formal" definition of a new data type in the data model constitutes "protocol lawyering", a debate about form without any substance. In seeking to debunk some of these data model additions, you are apparently attempting to build a case for the precedence of using the RADIUS String data type to contain non-self-describing data structures. This has been a point of debate in the RADEXT WG for several years. The WG consensus is captured in the Design Guidelines draft. The String data type should be used for actual strings, or for opaque blobs of binary data, for use in some other protocol component, e.g. EAP. There are specific exemptions to this recommendation that are spelled out in the draft. -- to 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, 25 Oct 2009 15:36:34 +0000 From: "Dave Nelson" To: Cc: "'IESG IESG'" Subject: RE: Proposed Resolution of Issue #318: REJECT Date: Sun, 25 Oct 2009 11:35:54 -0400 Message-ID: <77AEC2179BCC41458BF54596AFE12794@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQAABKTkAAEYxFQAAMs9dAAACs5yAAAKY6kAAA1kuA Glen Zorn writes... > > I suspect you don't attach much value (or even credence) > > to this data-driven model on the server side, but many in > > the RADIUS community do. > > In fact I hold the idea in great esteem; what I disvalue is > the idea that data-driven models have to be implementable by > below-average high-school kids. There is no need for you to be so dismissive of, and insulting to, your colleagues, who form the rough consensus on this issue. -- to 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, 25 Oct 2009 15:26:45 +0000 From: "Glen Zorn" To: "'Dave Nelson'" , Cc: "'IESG IESG'" Subject: RE: Proposed Resolution of Issue #318: REJECT Date: Sun, 25 Oct 2009 22:25:23 +0700 Message-ID: <048f01ca5587$69ecc130$3dc64390$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQAABKTkAAEYxFQAAMs9dAAACs5yAAAKY6kA== Content-Language: en-us Dave Nelson [mailto://d.b.nelson@comcast.net] writes: > Glen Zorn writes... > > > My assertion is that correctly implemented code changes (maybe > > that's asking too much?) do not effect interoperability, nor > > does requiring such cause harm. > > Your assertion is that correctly implemented code changes at both the > client > and server ends of a client-server protocol implementation would not > affect > interoperability. True, as far as it goes. The point that is being > addressed in the RADIUS Design Guidelines is that *requiring* code > changes > on the sever side, when a data dictionary change alone would suffice, > is > harmful to interoperability, or at least forces maintainers of server > implementations to make code changes they would not otherwise have to > make. This claim is valid only for some (primitive) implementations. I am currently running a RADIUS server (w/a nice GUI, no less) that will handle any length of integer, signed or unsigned, (not to mention arbitrary "complex" attributes) with only a dictionary change or two. It's hardly rocket science to build a flexible, data-driven parser and I'm actually personally offended by the attempt to standardize this kind of weak design. > The guidelines discourage attribute design choices that would force a > code > change on RADIUS servers when no such change would be required with a > more > "traditional" choice of attribute design. > > I suspect you don't attach much value (or even credence) to this data- > driven > model on the server side, but many in the RADIUS community do. In fact I hold the idea in great esteem; what I disvalue is the idea that data-driven models have to be implementable by below-average high-school kids. -- to 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, 25 Oct 2009 15:04:32 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: "'Alan DeKok'" , , "'IESG IESG'" Subject: RE: Data Types defined in RFC 2865 Date: Sun, 25 Oct 2009 22:03:23 +0700 Message-ID: <048b01ca5584$591087a0$0b3196e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgCL9BjQAAHOdUA= Content-Language: en-us Bernard Aboba [mailto://Bernard_aboba@hotmail.com] writes: > " It goes on to name the five data types, and give definitions for > each > one. These data types are then used in the attribute definitions in > RFC > 2865, and in other RADIUS RFCs." > > Section 5 is unambiguous on this point: > > " The format of the value field is one of five data types. Note > that type "text" is a subset of type "string". > > text 1-253 octets containing UTF-8 encoded 10646 [7] > characters. Text of length zero (0) MUST NOT be sent; > omit the entire attribute instead. > > string 1-253 octets containing binary data (values 0 through > 255 decimal, inclusive). Strings of length zero (0) > MUST NOT be sent; omit the entire attribute instead. > > address 32 bit value, most significant octet first. > > integer 32 bit unsigned value, most significant octet first. > > time 32 bit unsigned value, most significant octet first -- > seconds since 00:00:00 UTC, January 1, 1970. The > standard Attributes do not use this data type but it is > presented here for possible use in future attributes. > " > > Moreover, within the value field of each attribute, RFC 2865 includes > the > data type: > > a. "String" for type string. > b. "Address" for type address Is a netmask considered an address? > c. "Value" for type integer Wow, I am really amazed! I don't know how many times I've read that RFC & never noticed the apparently 1-1 correlation between naming the "Value" field of an attribute "Value" and the contents of that field being an integer (though with special "flag" values sometimes). I'm really very impressed, but does that really qualify as "unambiguous"? > d. "Text" for type text > > No attributes of type time are defined in RFC 2865 or 2866. > > Looking at other RADIUS RFCs, the inclusion of the data type within the > value field is less consistent. > > For example, RFC 2867, includes a type of "Lost" in Section 4.2 for > Acct-Tunnel-Packets-Lost (4 octets). It seems likely that this > attribute > was intended as type integer, rather than a "lost" data type. Actually, it seems much more likely to me that the field was named descriptively (I know it's insane, but then Alan DeKok wasn't around to show us the True Way ;-). Additionally, in 2866, the "Value" field of the Acct-Multi-Session-Id attribute is named "String", but its contents are specified as UTF-8 encoded 10646 characters (the definition of the "text" type). > > In RFC 2869, the term "Value" is used in the value field for attributes > that > are not integers (e.g. ARAP-Challenge-Response in Section 5.15). > > RFC 3162 seems closer to the conventions of RFC 2865 & 2866, although > the > "Address" type used is 16 rather than 4 octets in size (IPv6 vs. IPv4). So am I to understand that, despite the multitude of counterexamples and the lack of any explicit text even suggesting such in any RADIUS-related RFC, you are claiming that the name of the V field in the TLV construct denotes a formal data type (a thing apparently known only to some secret society holding the same "internally consistent belief system" (thought police, anyone? ;-)? ... -- to 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, 25 Oct 2009 15:00:17 +0000 From: "Dave Nelson" To: Cc: "'IESG IESG'" Subject: RE: Proposed Resolution of Issue #318: REJECT Date: Sun, 25 Oct 2009 10:59:52 -0400 Message-ID: <8F84EE704D0F419AB406F5E658B4E37B@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQAABKTkAAEYxFQAAMs9dAAACs5yA= Glen Zorn writes... > My assertion is that correctly implemented code changes (maybe > that's asking too much?) do not effect interoperability, nor > does requiring such cause harm. Your assertion is that correctly implemented code changes at both the client and server ends of a client-server protocol implementation would not affect interoperability. True, as far as it goes. The point that is being addressed in the RADIUS Design Guidelines is that *requiring* code changes on the sever side, when a data dictionary change alone would suffice, is harmful to interoperability, or at least forces maintainers of server implementations to make code changes they would not otherwise have to make. The guidelines discourage attribute design choices that would force a code change on RADIUS servers when no such change would be required with a more "traditional" choice of attribute design. I suspect you don't attach much value (or even credence) to this data-driven model on the server side, but many in the RADIUS community do. -- to 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, 25 Oct 2009 14:52:11 +0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" Cc: "'radext mailing list'" Subject: RE: [Technical Errata Reported] RFC3162 (1923) Date: Sun, 25 Oct 2009 21:50:59 +0700 Message-ID: <048701ca5582$99a97710$ccfc6530$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTGoLKB9OFGKn+Sk+vijhLAU4nRwCQoQHAAAk1baA= Content-Language: en-us > RADEXT WG, > > Please advise on the Technical Errata below. The idea that the formal data type (if any) of a field in a RADIUS attribute can be changed by changing the name of the field is so bizarre as to be almost unbelievable. Even if it wasn't so incredibly BASIC, the idea is not supported by any explicit text in any RADIUS-related RFC. ... -- to 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, 25 Oct 2009 14:36:38 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: , "'IESG IESG'" Subject: RE: Proposed Resolution of Issue #318: REJECT Date: Sun, 25 Oct 2009 21:34:42 +0700 Message-ID: <048601ca5580$560df2d0$0229d870$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQAABKTkAAEYxFQAAMs9dA Content-Language: en-us Bernard Aboba [mailto://bernard_aboba@hotmail.com] writes: > Alan DeKok said: > > "This issue should be rejected. > > RADIUS specifications define format, meaning, interpretations, and > processing requirements for attributes. Two implementations that > disagree about an attribute can inter-operate at the RADIUS level by > exchanging RADIUS packets. They cannot be said have interoperable > implementations of the attribute." > > Given that the Design Guidelines document has already been approved for > publication by the IESG, I hate to repeat myself, but this statement is STILL FALSE. > the bar for making changes is extremely high. > > In this case, that bar does not appear to have been reached. > > The assertion is that interoperability issues cannot be created by a > mismatch of RADIUS data types and therefore that normative language > cannot be used. That may be Alan's assertion, but it's not mine. My assertion is that correctly implemented code changes (maybe that's asking too much?) do not effect interoperability, nor does requiring such cause harm. ... -- to 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, 25 Oct 2009 10:32:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Pending errata for RADEXT Date: Sun, 25 Oct 2009 11:31:56 +0100 Message-ID: Thread-Topic: Pending errata for RADEXT Thread-Index: AcpVXmAki+iuaexKQ1amgu88RsIZGA== From: "Romascanu, Dan (Dan)" To: "radext mailing list" RADEXT WG,=20 There are a number of pending errata related to RADIUS that I have asked recommendation in the past for the WG. Please process and advice how for resolutions on these errata. Some of them are rather simple, some other may require some more thought.=20 The IDs (in the order of their occurrences in the tracker) are: 1607, 420, 1469, 753, 1848, 1849, 1850, 867, 1407.=20 Thanks and Regards, 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: Sun, 25 Oct 2009 10:28:52 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [Technical Errata Reported] RFC3162 (1923) Date: Sun, 25 Oct 2009 11:27:28 +0100 Message-ID: Thread-Topic: [Technical Errata Reported] RFC3162 (1923) Thread-Index: AcpTGoLKB9OFGKn+Sk+vijhLAU4nRwCQoQHA From: "Romascanu, Dan (Dan)" To: "radext mailing list" RADEXT WG, Please advise on the Technical Errata below.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of RFC Errata System Sent: Thursday, October 22, 2009 3:19 PM To: bernarda@microsoft.com; gwz@cisco.com; iesg@iesg.org Cc: aland@freeradius.org; rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC3162 (1923) The following errata report has been submitted for RFC3162, "RADIUS and IPv6". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D3162&eid=3D1923 -------------------------------------- Type: Technical Reported by: Alan DeKok Section: 2.1 Original Text ------------- Address The Address field is 16 octets. Corrected Text -------------- String The field is 16 octets Notes ----- As Glen notes in: http://ops.ietf.org/lists/radiusext/2009/msg00540.html Using "ipv6 address" for a data type in RADIUS is wrong. RFC 3162 (among others Glen wrote) contradict his current position. Those documents use data types for the "value" field of RADIUS attributes that have not been defined in RFC 2865. As such, they should either: a) make it clear that they define a new data type, and be marked as "Updates: 2865" or b) use the data types in RFC 2865. Or even better, maintain an internally consistent set of beliefs, and leave RFC 3162 alone. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC3162 (draft-aboba-radius-ipv6-10) -------------------------------------- Title : RADIUS and IPv6 Publication Date : August 2001 Author(s) : B. Aboba, G. Zorn, D. Mitton Category : PROPOSED STANDARD Source : Legacy Area : Legacy Stream : IETF Verifying Party : IESG -- to 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, 25 Oct 2009 08:27:05 +0000 Message-ID: From: "Bernard Aboba" To: Subject: Proposed Resolution of Issue #318: REJECT Date: Sun, 25 Oct 2009 01:26:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQAABKTkAAEYxFQA== Content-Language: en-us Alan DeKok said: "This issue should be rejected. RADIUS specifications define format, meaning, interpretations, and processing requirements for attributes. Two implementations that disagree about an attribute can inter-operate at the RADIUS level by exchanging RADIUS packets. They cannot be said have interoperable implementations of the attribute." Given that the Design Guidelines document has already been approved for publication by the IESG, the bar for making changes is extremely high. In this case, that bar does not appear to have been reached. The assertion is that interoperability issues cannot be created by a mismatch of RADIUS data types and therefore that normative language cannot be used. While it is possible for any RADIUS attribute to be expressed as a String of octets, configuration of attributes in Hex is both inconvenient and error prone. Moreover, if an attribute requires computation of any kind, then a mismatch in the data type will result the data being misinterpreted, with unpredictable results. Therefore the text in question would appear to meet the RFC 2119 bar. The proposed resolution of Issue 318 is REJECT. -- to 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, 25 Oct 2009 08:27:01 +0000 Message-ID: From: "Bernard Aboba" To: Subject: Proposed Resolution of Issue 319: Accept in principle Date: Sun, 25 Oct 2009 01:26:23 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CA5512.2A62A2C0" Thread-Index: AcpVCQbN9frlusrGQ3C4EJ7P9brrDQAQ8V7w Content-Language: en-us ------=_NextPart_000_000B_01CA5512.2A62A2C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This issue relates to the question of whether existing RADIUS RFCs have defined the unsigned integer64 data type. The contention is that attributes such as ARAP-Challenge-Response (RFC 2869) were in fact defined as 8 octet String attributes, not unsigned integer64. Similarly, the contention is that the Interface-ID attribute was also not defined as an unsigned integer64. While the bar for making changes to the Design Guidelines document is very high, this issue is one which could potentially result in an Errata being filed and approved. A proposed resolution to this issue is available below: http://ops.ietf.org/lists/radiusext/2009/msg00546.html The resolution of this question depends in part on an understanding of the type of the Interface-ID attribute. Potential candidates (integer64 seems to have been disqualified) include 8 octet String or Interface ID (variant of 8 octet String). Another sub-question that needs to be resolved is whether the implementation advice given in the document (for RADIUS implementations to support the unsigned integer 64 data type) is justified if it is determined that this data type is not in fact used by any existing RADIUS attribute. If you have comments on the proposed resolution nor any of the sub-questions, please post your opinions to the list. ------=_NextPart_000_000B_01CA5512.2A62A2C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This issue relates to the question of whether = existing RADIUS RFCs have defined the unsigned integer64

data type.   The contention is that = attributes such as ARAP-Challenge-Response (RFC 2869) were in fact

defined as 8 octet String attributes, not unsigned integer64.   Similarly, the contention is that = the

Interface-ID attribute was also not defined as an = unsigned integer64.  

 

While the bar for making changes to the Design = Guidelines document is very high, this issue is one

which could potentially result in an Errata being = filed and approved.

 

A proposed resolution to this issue is available = below:

http://op= s.ietf.org/lists/radiusext/2009/msg00546.html

 

The resolution of this question depends in part on = an understanding of the type of

the Interface-ID attribute.  Potential = candidates (integer64 seems to have been disqualified) include

8 octet String or Interface ID (variant of 8 octet = String).

 

Another sub-question that needs to be resolved is = whether the implementation advice given in the

document (for RADIUS implementations to support the = unsigned integer 64 data type) is justified

if it is determined that this data type is not in = fact used by any existing RADIUS attribute.

 

If you have comments on the proposed resolution nor = any of the sub-questions, please post your

opinions to the list.

 

 

 

 

 

 

 

 

------=_NextPart_000_000B_01CA5512.2A62A2C0-- -- to 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, 25 Oct 2009 07:58:14 +0000 Message-ID: From: "Bernard Aboba" To: "'Alan DeKok'" , Subject: RE: Data Types defined in RFC 2865 Date: Sun, 25 Oct 2009 00:57:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgCL9BjQ Content-Language: en-us Alan DeKok said: " It goes on to name the five data types, and give definitions for each one. These data types are then used in the attribute definitions in RFC 2865, and in other RADIUS RFCs." Section 5 is unambiguous on this point: " The format of the value field is one of five data types. Note that type "text" is a subset of type "string". text 1-253 octets containing UTF-8 encoded 10646 [7] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead. string 1-253 octets containing binary data (values 0 through 255 decimal, inclusive). Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. address 32 bit value, most significant octet first. integer 32 bit unsigned value, most significant octet first. time 32 bit unsigned value, most significant octet first -- seconds since 00:00:00 UTC, January 1, 1970. The standard Attributes do not use this data type but it is presented here for possible use in future attributes. " Moreover, within the value field of each attribute, RFC 2865 includes the data type: a. "String" for type string. b. "Address" for type address c. "Value" for type integer d. "Text" for type text No attributes of type time are defined in RFC 2865 or 2866. Looking at other RADIUS RFCs, the inclusion of the data type within the value field is less consistent. For example, RFC 2867, includes a type of "Lost" in Section 4.2 for Acct-Tunnel-Packets-Lost (4 octets). It seems likely that this attribute was intended as type integer, rather than a "lost" data type. In RFC 2869, the term "Value" is used in the value field for attributes that are not integers (e.g. ARAP-Challenge-Response in Section 5.15). RFC 3162 seems closer to the conventions of RFC 2865 & 2866, although the "Address" type used is 16 rather than 4 octets in size (IPv6 vs. IPv4). -- to 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, 25 Oct 2009 04:41:36 +0000 From: "Glen Zorn" To: "'Dave Nelson'" , Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun, 25 Oct 2009 11:40:22 +0700 Message-ID: <043e01ca552d$4ae150d0$e0a3f270$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxAAAQa5/AAAMdz4AAk/y3gACIVHaA= Content-Language: en-us Dave Nelson [mailto://d.b.nelson@comcast.net] writes: ... > > - Are you now convinced of "interest"? (and if not, or > > partially, then on what grounds given the rather abundant > > amount of contributors, reviewers, discussion?) > > The level of interest required to accept a work item in the RADEXT WG > is, as > you say, an "abundant" number of reviewers, not including the authors. > There is no hard rule, but half a dozen would be a good threshold. Not counting the authors, 19 individuals have posted on _any_ topic on this list this year; discounting IESG members and WG Chairs (official and de facto) brings the number down to 13, most of whom sent only one or two messages (mostly regarding their own drafts). So it sounds like you are saying that about half the active WG members have to sign up to review the draft, is that correct? It's interesting how high the bar is set in this case given that apparently _no one_ has ever actually reviewed draft-ietf-radext-design (currently being emphatically pushed for publication despite the number of egregious technical errors discovered upon a reasonably close reading thereof). ... -- to 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, 25 Oct 2009 03:57:40 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , Cc: "'IESG IESG'" Subject: RE: Proposed Resolution of Issue #320: REJECT Date: Sun, 25 Oct 2009 10:56:13 +0700 Message-ID: <043401ca5527$21188120$63498360$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQAAcoEIA= Content-Language: en-us Bernard Aboba [mailto://bernard_aboba@hotmail.com] writes: > Alan DeKok said: > > " This issue should be rejected out of hand. The concept of "data > types" goes back to the beginning of RADIUS, and was part of the > original protocol specification." > > Given that the Design Guidelines document has already been approved for > publication by the IESG, In actual point of fact, this assertion is incorrect: the Issue Tracker shows that the draft in question is in the state "IESG Evaluation", sub-state "AD Followup"; this does not translate to "approved for publication". In fact, the description of the "AD Followup" sub-state suggests that the resolution of issues is no longer up to the WG Chairs: "A generic substate indicating that the shepherding AD has the action item to determine appropriate next steps. In particular, the appropriate steps (and the corresponding next state or substate) depend entirely on the nature of the issues that were raised and can only be decided with active involvement of the shepherding AD." > the bar for making changes is extremely high. I'm sorry, I would have thought that the bar for publication of a document as an RFC would have been considerably higher. > > In this case, that bar does not appear to have been reached. > RFC 3162 defines several attributes as being of type "address". Where? The expected phrase would be "is of type address" or something similar, which doesn't appear in the document. It does, however, _name_ a single attribute as "NAS-IPv6-Address but that is stated simp0ly to be "16 octets". Furthermore, the description of the Login-IPv6-Host attribute (one of the attributes which draft-ietf-radext-design-09 cites as justification for an "IPv6 Address" data type) specifies special meanings for 2 values of the "Address" field. Do all "IPv6 Address" data types have the same semantics? If not, then draft-ietf-radext-design-09 is in error. > Since the addresses in question were IPv6 addresses, and RFC 2865 > utilizes the IPv4 address type for similar attributes within IPv4, Hmm. The practice of making bald assertions of opinion without basis in fact seems to be contagious ;-). As many people have noted over the years, although RFC2865 defines the "address" data type, no attributes are defined to be of type "address" in that document. > it is not much of a stretch to conclude that RFC 3162 defines the > IPv6 address type. One can conclude virtually anything if one begins with a false premise... > > Therefore I would propose that Issue 320 be resolved as REJECT. > > > > > > > > > -- > to 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: Sun, 25 Oct 2009 02:59:26 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: Subject: RE: 64-bit Unsigned Integer? Date: Sun, 25 Oct 2009 09:58:27 +0700 Message-ID: <042901ca551f$0da959f0$28fc0dd0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_042A_01CA5559.BA0831F0" Thread-Index: AcpUt1CDAs5YKsv1QZWynI8IOQ6+KQACPFygAAh3fOAADw1oMA== Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_042A_01CA5559.BA0831F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes: Glen Zorn said: "I'm wondering when it was decided (& who made the decision) that if an implementation doesn't follow the standard, it's the standard that's broken & not the implementation." There are several issues that have been brought up: 1. What does RFC 3162 say about the type of the Interface-ID attribute? The current Design Guidelines document asserts it is an 64-bit unsigned integer. As you pointed out, this does not appear to be supported by the text of RFC 3162. 2. Should the Design Guidelines document recommend that implementations support the 64-bit unsigned integer type? a. Because it is currently supported? b. For some other reason? The question you have raised doesn't seem relevant to either of the two above questions. It's not. However, neither is the question of how "existing implementations behave", unless we are now basing BCPs upon the vagaries of (possibly brain-dead) developers rather than published standards. ------=_NextPart_000_042A_01CA5559.BA0831F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes:
Glen Zorn said:

 

“I’m = wondering when it was decided (& who made  the decision) that if an implementation doesn’t follow the standard, it’s the = standard that’s broken & not the = implementation…”

There are several = issues that have been brought up:

1.       = What does RFC 3162 say about the type of the Interface-ID attribute? The = current Design Guidelines document asserts it is an 64-bit unsigned integer.   As you pointed out, this does not appear to be supported by = the text of RFC 3162.

2.       = Should the Design Guidelines document recommend that implementations support = the 64-bit unsigned integer type?

a.       Because it is currently supported?

b.      For some other reason?

The question you have = raised doesn’t seem relevant to either of the two above questions.  =

It’s = not.  However, neither is the question of how “existing implementations = behave”, unless we are now basing BCPs upon the vagaries of (possibly brain-dead) developers rather than published standards.  =  

------=_NextPart_000_042A_01CA5559.BA0831F0-- -- to 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, 25 Oct 2009 02:53:20 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: , "'IESG IESG'" Subject: RE: FW: ISSUE: Inappropriate usage of RFC 2119 key words Date: Sun, 25 Oct 2009 09:52:08 +0700 Message-ID: <042801ca551e$2d7d32c0$88779840$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpU3gsmP1ytkr1BTPi+3Ci5mKEPjgAO72YQ Content-Language: en-us > Glen Zorn wrote: > > Alan DeKok [mailto:aland@deployingradius.com] writes: > .. > >> I welcome suggestions for how implementations can *meaningfully* > >> interoperate when they have different interpretations for an > attribute. > > > > What, if anything, do you imagine that has to do with my comment? > > It's a complex logic chain, explained in my previous message. > > The suggestion that specifications SHOULD re-use existing data types > means that implementations can re-use those data types for new > specifications. Since the data types are already inter-operable, > adding > new attributes of the same data type means a high likelihood of > inter-operability. > > Or... we give up on the idea of data types (as has been insinuated > here), Nothing is being insinuated: AFAICT, the only justification for most of the prescriptions in the draft is that to so otherwise requires code changes in some implementations. My rather clear question was "What harm does a correctly implemented code change have do to interoperability?" I think that the answer is obvious (none), which may explain your need to avoid answering it at all costs ;-). > and new specs do whatever they want. Since the old > implementations don't know about those new data types, they won't > implement them, and the systems won't be inter-operable. Without changes to code (or in a more reasonable system, to a (auxiliary) dictionary). > > And to repeat: Yes, they will be able to exchange RADIUS packets. > No, > they will not be able to agree on the format, meaning, interpretations, > and processing requirements for attributes. > > e.g. An implementation that doesn't support Message-Authenticator > cannot be meaningfully said to be interoperable with another one that > requires Message-Authenticator for EAP sessions. Excellent example! Section 3.1 of RFC 3579 says "the Message-Authenticator attribute MUST be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets containing an EAP-Message attribute". So you seem to be saying that the fact that an implementation that is compliant with RFC 3579 won't interoperate with one that isn't compliant is, amazingly, a bug rather than a feature! > > RADIUS has had attribute interoperability problems for over a decade. If so, isn't the answer to require more detailed and specific attribute definitions rather than attempting to homogenize everything (often inappropriately, as I pointed out with the "integer64" concoction)? ... -- to 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, 25 Oct 2009 02:12:54 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'Bernard Aboba'" , Subject: RE: 64-bit Unsigned Integer? Date: Sun, 25 Oct 2009 09:10:51 +0700 Message-ID: <042101ca5518$69a49410$3cedbc30$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thread-Index: AcpU3aB0pp37hQWfR8Wmzcu0IbMhgwAOQBzQ Content-Language: en-us Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > > Glen has brought up the question of whether existing RADIUS server > > implementations in fact support 64-bit unsigned integers, or whether > > they implement attributes such as Interface-ID as 64-bit octet > Strings, > > or specially formatted types. > > > > If you are aware of how existing implementations behave, please > > reply to this message. > > > > I=E2=80=99m wondering when it was decided (& who made the decision) = that if > an > > implementation doesn=E2=80=99t follow the standard, it=E2=80=99s the = standard that=E2=80=99s > > broken & not the implementation=E2=80=A6 >=20 > What, if anything, do you imagine that has to do with Bernards > comment? It's quite simple: he didn=E2=80=99t request discussion of my assertions = regarding the technical content of the documents themselves (I expect = that those would be uncontroversial) but about the interpretation of = those documents by developers. It would seem clear that at least one = implementation has it completely wrong, however, so asking "how existing = implementations behave" is tantamount to subjecting the standards to the = implementations thereof. >=20 > 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, 25 Oct 2009 00:10:12 +0000 Message-ID: From: "Bernard Aboba" To: CC: "'IESG IESG'" Subject: Proposed Resolution of Issue #320: REJECT Date: Sat, 24 Oct 2009 17:03:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTFjgnLmKY/1hqR+yy4EJ3df1CAgB70gAQ Content-Language: en-us Alan DeKok said: " This issue should be rejected out of hand. The concept of "data types" goes back to the beginning of RADIUS, and was part of the original protocol specification." Given that the Design Guidelines document has already been approved for publication by the IESG, the bar for making changes is extremely high. In this case, that bar does not appear to have been reached. RFC 3162 defines several attributes as being of type "address". Since the addresses in question were IPv6 addresses, and RFC 2865 utilizes the IPv4 address type for similar attributes within IPv4, it is not much of a stretch to conclude that RFC 3162 defines the IPv6 address type. Therefore I would propose that Issue 320 be resolved as REJECT. -- to 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, 24 Oct 2009 19:55:17 +0000 Message-ID: From: "Bernard Aboba" To: "'Glen Zorn'" CC: Subject: RE: 64-bit Unsigned Integer? Date: Sat, 24 Oct 2009 12:54:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_038E_01CA54A9.22D3EA00" Thread-Index: AcpUt1CDAs5YKsv1QZWynI8IOQ6+KQACPFygAAh3fOA= Content-Language: en-us ------=_NextPart_000_038E_01CA54A9.22D3EA00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Glen Zorn said: "I'm wondering when it was decided (& who made the decision) that if an implementation doesn't follow the standard, it's the standard that's broken & not the implementation." There are several issues that have been brought up: 1. What does RFC 3162 say about the type of the Interface-ID attribute? The current Design Guidelines document asserts it is an 64-bit unsigned integer. As you pointed out, this does not appear to be supported by the text of RFC 3162. 2. Should the Design Guidelines document recommend that implementations support the 64-bit unsigned integer type? a. Because it is currently supported? b. For some other reason? The question you have raised doesn't seem relevant to either of the two above questions. From: Glen Zorn [mailto:glenzorn@comcast.net] Sent: Saturday, October 24, 2009 8:43 AM To: 'Bernard Aboba' Cc: radiusext@ops.ietf.org Subject: RE: 64-bit Unsigned Integer? Glen has brought up the question of whether existing RADIUS server implementations in fact support 64-bit unsigned integers, or whether they implement attributes such as Interface-ID as 64-bit octet Strings, or specially formatted types. If you are aware of how existing implementations behave, please reply to this message. I'm wondering when it was decided (& who made the decision) that if an implementation doesn't follow the standard, it's the standard that's broken & not the implementation. ------=_NextPart_000_038E_01CA54A9.22D3EA00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Glen Zorn said:

 

“I’m wondering when it was decided (& who made  the decision) that = if an implementation doesn’t follow the standard, it’s the = standard that’s broken & not the = implementation…”

There are several = issues that have been brought up:

1.       = What does RFC 3162 say about the type of the Interface-ID attribute? The = current Design Guidelines document asserts it is an 64-bit unsigned integer. =   As you pointed out, this does not appear to be supported by the text of RFC = 3162.

2.       = Should the Design Guidelines document recommend that implementations support = the 64-bit unsigned integer type?

a.       Because it is currently supported?

b.      For some other reason?

The question you have = raised doesn’t seem relevant to either of the two above questions.  =

 

 

From:= Glen Zorn [mailto:glenzorn@comcast.net]
Sent: Saturday, October 24, 2009 8:43 AM
To: 'Bernard Aboba'
Cc: radiusext@ops.ietf.org
Subject: RE: 64-bit Unsigned Integer?

 

Glen has brought up the question of = whether existing RADIUS server
implementations in fact support 64-bit unsigned integers, or whether
they implement attributes such as Interface-ID as 64-bit octet = Strings,
or specially formatted types.

If you are aware of how existing implementations behave, please
reply to this message.

I’m wondering = when it was decided (& who made  the decision) that if an = implementation doesn’t follow the standard, it’s the standard that’s = broken & not the implementation…

 

 

------=_NextPart_000_038E_01CA54A9.22D3EA00-- -- to 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, 24 Oct 2009 19:10:40 +0000 Message-ID: <4AE35117.3050409@deployingradius.com> Date: Sat, 24 Oct 2009 21:10:15 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: 'Bernard Aboba' , radiusext@ops.ietf.org Subject: Re: 64-bit Unsigned Integer? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Glen Zorn wrote: > Glen has brought up the question of whether existing RADIUS server > implementations in fact support 64-bit unsigned integers, or whether > they implement attributes such as Interface-ID as 64-bit octet Strings, > or specially formatted types. > > If you are aware of how existing implementations behave, please > reply to this message. > > I’m wondering when it was decided (& who made the decision) that if an > implementation doesn’t follow the standard, it’s the standard that’s > broken & not the implementation… What, if anything, do you imagine that has to do with Bernards comment? 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: Sat, 24 Oct 2009 19:10:17 +0000 Message-ID: <4AE350D2.70606@deployingradius.com> Date: Sat, 24 Oct 2009 21:09:06 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org, 'IESG IESG' Subject: Re: FW: ISSUE: Inappropriate usage of RFC 2119 key words Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > Alan DeKok [mailto:aland@deployingradius.com] writes: .. >> I welcome suggestions for how implementations can *meaningfully* >> interoperate when they have different interpretations for an attribute. > > What, if anything, do you imagine that has to do with my comment? It's a complex logic chain, explained in my previous message. The suggestion that specifications SHOULD re-use existing data types means that implementations can re-use those data types for new specifications. Since the data types are already inter-operable, adding new attributes of the same data type means a high likelihood of inter-operability. Or... we give up on the idea of data types (as has been insinuated here), and new specs do whatever they want. Since the old implementations don't know about those new data types, they won't implement them, and the systems won't be inter-operable. And to repeat: Yes, they will be able to exchange RADIUS packets. No, they will not be able to agree on the format, meaning, interpretations, and processing requirements for attributes. e.g. An implementation that doesn't support Message-Authenticator cannot be meaningfully said to be interoperable with another one that requires Message-Authenticator for EAP sessions. RADIUS has had attribute interoperability problems for over a decade. Why are there still questions about it? 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: Sat, 24 Oct 2009 15:45:06 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: Subject: RE: 64-bit Unsigned Integer? Date: Sat, 24 Oct 2009 22:43:25 +0700 Message-ID: <03ab01ca54c0$c5208fe0$4f61afa0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03AC_01CA54FB.717F67E0" Thread-Index: AcpUt1CDAs5YKsv1QZWynI8IOQ6+KQACPFyg Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_03AC_01CA54FB.717F67E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Glen has brought up the question of whether existing RADIUS server implementations in fact support 64-bit unsigned integers, or whether they implement attributes such as Interface-ID as 64-bit octet Strings, or specially formatted types. If you are aware of how existing implementations behave, please reply to this message. I'm wondering when it was decided (& who made the decision) that if an implementation doesn't follow the standard, it's the standard that's broken & not the implementation. ------=_NextPart_000_03AC_01CA54FB.717F67E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Glen has brought up the question of = whether existing RADIUS server
implementations in fact support 64-bit unsigned integers, or whether
they implement attributes such as Interface-ID as 64-bit octet = Strings,
or specially formatted types.

If you are aware of how existing implementations behave, please
reply to this message.

I’m wondering = when it was decided (& who made  the decision) that if an = implementation doesn’t follow the standard, it’s the standard that’s broken & = not the implementation…



 

------=_NextPart_000_03AC_01CA54FB.717F67E0-- -- to 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, 24 Oct 2009 14:32:33 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_034685e4-7f5c-446c-a5d5-822a8ae37984_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: 64-bit Unsigned Integer? Date: Sat, 24 Oct 2009 07:31:37 -0700 MIME-Version: 1.0 --_034685e4-7f5c-446c-a5d5-822a8ae37984_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Glen has brought up the question of whether existing RADIUS server implementations in fact support 64-bit unsigned integers=2C or whether they implement attributes such as Interface-ID as 64-bit octet Strings=2C or specially formatted types.=20 If you are aware of how existing implementations behave=2C please reply to this message.=20 = --_034685e4-7f5c-446c-a5d5-822a8ae37984_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Glen has brought up the question of whether existing RADIUS server
imple= mentations in fact support 64-bit unsigned integers=2C or whether
they i= mplement attributes such as Interface-ID as 64-bit octet Strings=2C
or s= pecially formatted types.

If you are aware of how existing implemen= tations behave=2C please
reply to this message.



= = --_034685e4-7f5c-446c-a5d5-822a8ae37984_-- -- to 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, 24 Oct 2009 13:11:03 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: , "'IESG IESG'" Subject: RE: FW: ISSUE: Inappropriate usage of RFC 2119 key words Date: Sat, 24 Oct 2009 20:08:59 +0700 Message-ID: <039501ca54ab$2f6fb030$8e4f1090$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTpaSdqvnDTebiR0WSt5sagsHmkwBBHLaw Content-Language: en-us Alan DeKok [mailto:aland@deployingradius.com] writes: > > The section of the draft in question says: > > > > It is worth noting that since RADIUS only supports unsigned > integers > > of 32 or 64 bits, attributes using signed integer data types or > > unsigned integer types of other sizes will require code changes, > and > > SHOULD be avoided. > > > > It is difficult to see how either harm or interoperability problems > could > > arise from correctly implemented code changes; indeed, this appears > to be a > > classic case of the use of RFC 2119 keywords to "try to impose a > particular > > method on implementors where the method is not required for > > interoperability". > > I welcome suggestions for how implementations can *meaningfully* > interoperate when they have different interpretations for an attribute. What, if anything, do you imagine that has to do with my comment? ... -- to 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, 24 Oct 2009 12:18:47 +0000 From: "Dave Nelson" To: Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sat, 24 Oct 2009 08:17:11 -0400 Message-ID: <18B576169E2241A5AF24D33D4C5B8870@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxAAAQa5/AAAMdz4AAk/y3g Wojciech Dec writes... > - Are you now convinced of "interest"? (and if not, or > partially, then on what grounds given the rather abundant > amount of contributors, reviewers, discussion?) The level of interest required to accept a work item in the RADEXT WG is, as you say, an "abundant" number of reviewers, not including the authors. There is no hard rule, but half a dozen would be a good threshold. The success of any WG in producing quality documents is tied to the number of members that are willing to actively review and comment upon the drafts. Of course, it also depends upon the authors providing timely and responsive revisions. I haven't taken a count recently, but excluding authors, I'm not sure I'd use the term "abundant" to describe the number of independent reviewers. -- to 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, 23 Oct 2009 18:36:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=11938; q=dns/txt; s=amsiport01001; t=1256322968; x=1257532568; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20Draft=20RADEXT=20Virtual=20Interim=20Mi nutes|Date:=20Fri,=2023=20Oct=202009=2020:35:58=20+0200 |Message-ID:=20|To:=20"Bernard=20Aboba"=20,=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20=20=20=20; bh=QMJqGWrVzpBSvTwLmcbrmLKl0lOs3WkybTb8Xb+nQBo=; b=EvcTr1zgGXABkRnfV5CxbO0tr9VKf0b1dFjgzuW+jRvnjGmIlg7t5TRX QLhSRcKv3n4y/28v2MaMPFGj1YyggR/ujyBDmeg/4unm/JQVql/RjSKga 32CHNh7BNZGWwLoYfx/Db9RWjDvcLfFs/5IEsBccGbhB6CrsBW3aMo7Zn w=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA540F.AE7D66CF" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 20:35:58 +0200 Message-ID: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxAAAQa5/AAAMdz4A== From: "Wojciech Dec (wdec)" To: "Bernard Aboba" , This is a multi-part message in MIME format. ------_=_NextPart_001_01CA540F.AE7D66CF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 23 October 2009 20:22 To: Wojciech Dec (wdec); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 Wojcejech said: =20 "At this point however the draft seems to have been OK'ed in principle by the WG, and there was no evidence of the draft having "same negative feedback as had earlier versions" ..." =20 In looking through the minutes of the WG meetings I don't see any indications that the draft was accepted as a WG work item. =20 =20 Within RADEXT WG, adoption requires a formal consensus call, which was subsequently held (with insufficient interest being displayed so far).=20 =20 The IETF 73 minutes do provide an indication of the overall reaction to the document, which included objections both in principle and with respect to the specifics.=20 =20 I can post the individual comments made as Issues if you like.=20 =20 At the Virtual Interim, David Miles proposed an approach for overcoming those objections and moving the document forward. =20 =20 Woj> As per my earlier mail(s): - could you confirm that what my mail outlined in terms of moving forward is also your expectation?=20 - Are you now convinced of "interest"? (and if not, or partially, then on what grounds given the rather abundant amount of contributors, reviewers, discussion?) - could you point out (summarise) the issues that were not addressed? =20 Thanks. =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01CA540F.AE7D66CF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: 23 October 2009=20 20:22
To: Wojciech Dec (wdec);=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

Wojcejech=20 said:

 

“At this = point=20 however the draft seems to have been OK'ed in principle by the = WG, and=20 there was no evidence of the draft having "same negative feedback as = had=20 earlier versions" ...”

 

In=20 looking through the minutes of the WG meetings I don’t see any = indications=20 that the draft was accepted as a WG work item.=20    

 

Within=20 RADEXT WG, adoption requires a formal consensus call, which was = subsequently=20 held (with insufficient interest being displayed so far).=20

 

The=20 IETF 73 minutes do provide an indication of the overall reaction to = the=20 document, which included objections both in principle and with respect = to the=20 specifics.

 

I=20 can post the individual comments made as Issues if you like.=20

 

At=20 the Virtual Interim, David Miles proposed an approach for overcoming = those=20 objections and moving the document forward.  

 

Woj> As per=20 my earlier mail(s):

- could you confirm that what my mail outlined = in terms of=20 moving forward is also your=20 expectation? 

- Are you now convinced of = "interest"? (and if=20 not, or partially, then on what grounds given the rather abundant = amount of=20 contributors, reviewers, discussion?)

- could you=20 point out (summarise) the issues that were not=20 addressed?

 

Thanks.

 

 

 

 

 

 

------_=_NextPart_001_01CA540F.AE7D66CF-- -- to 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, 23 Oct 2009 18:33:50 +0000 Message-ID: From: "Bernard Aboba" To: "'Alan DeKok'" CC: Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 11:33:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpT9T5A21YeUFY6RNutUQ1ruzje2AAFj0WQAADwWWA= Content-Language: en-us Wojciech Dec (wdec) wrote: > In terms of "outstanding comments", with the exception of the datatype > debacle, it would be appreciated if you could point to ones that were > not addressed. Please read the minutes of the RADEXT WG meetings (such as IETF 73) at which the draft has been discussed. There was quite a bit of feedback presented at those meetings, most of which has not been addressed. -- to 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, 23 Oct 2009 18:22:39 +0000 Message-ID: From: "Bernard Aboba" To: "'Wojciech Dec \(wdec\)'" , Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 11:22:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0308_01CA53D3.1008D6A0" Thread-Index: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxAAAQa5/A= Content-Language: en-us ------=_NextPart_000_0308_01CA53D3.1008D6A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Wojcejech said: "At this point however the draft seems to have been OK'ed in principle by the WG, and there was no evidence of the draft having "same negative feedback as had earlier versions" ..." In looking through the minutes of the WG meetings I don't see any indications that the draft was accepted as a WG work item. Within RADEXT WG, adoption requires a formal consensus call, which was subsequently held (with insufficient interest being displayed so far). The IETF 73 minutes do provide an indication of the overall reaction to the document, which included objections both in principle and with respect to the specifics. I can post the individual comments made as Issues if you like. At the Virtual Interim, David Miles proposed an approach for overcoming those objections and moving the document forward. ------=_NextPart_000_0308_01CA53D3.1008D6A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wojcejech said:

 

“At this point however the draft seems to have been = OK'ed in principle by the WG, and there was no evidence of the draft = having "same negative feedback as had earlier versions" ...”

 

In looking through the minutes of the WG meetings I = don’t see any indications that the draft was accepted as a WG work item. =    

 

Within RADEXT WG, adoption requires a formal consensus = call, which was subsequently held (with insufficient interest being displayed = so far).

 

The IETF 73 minutes do provide an indication of the = overall reaction to the document, which included objections both in principle and with = respect to the specifics.

 

I can post the individual comments made as Issues if you = like.

 

At the Virtual Interim, David Miles proposed an approach = for overcoming those objections and moving the document forward. =

 

 

 

 

 

 =

------=_NextPart_000_0308_01CA53D3.1008D6A0-- -- to 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, 23 Oct 2009 18:09:18 +0000 Message-ID: From: "Bernard Aboba" To: "'Alan DeKok'" , "'Wojciech Dec \(wdec\)'" CC: Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 11:07:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpT9T5A21YeUFY6RNutUQ1ruzje2AAFj0WQ Content-Language: en-us Wojciech Dec (wdec) wrote: > In terms of "outstanding comments", with the exception of the datatype > debacle, it would be appreciated if you could point to ones that were > not addressed. Please read the minutes of the RADEXT WG meetings (such as IETF 73) at which the draft has been discussed. There was quite a bit of feedback presented at those meetings, most of which has been addressed. -- to 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, 23 Oct 2009 17:20:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=25624; q=dns/txt; s=amsiport01001; t=1256318302; x=1257527902; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20Draft=20RADEXT=20Virtual=20Interim=20Mi nutes|Date:=20Fri,=2023=20Oct=202009=2019:18:15=20+0200 |Message-ID:=20|To:=20"Bernard=20Aboba"=20,=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20=20; bh=o7u1WO4KLL3mTIue2h7SToSa2S5t8HH0LcSDwKV2FIM=; b=p41pXSqsqzY/fcplsgdBuhhats2LJ+eyQ25xQCVbjTko3GWZYOQguD4u s0Hg4pOYnPl0Mz/X9fKHlhkHFYkX5+caeM/6qEqZi+d/fR48Z00JanypD zo9MtOOLDV9UpSdCO42HzVmfD6/vSQR8kaRYnn/F2D7e8sPvhowf5Lpy6 A=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5404.D18DFD31" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 19:18:15 +0200 Message-ID: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxA From: "Wojciech Dec (wdec)" To: "Bernard Aboba" , This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5404.D18DFD31 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Unfortunately your mail did not answer my direct questions, which are aimed at moving forward. =20 In terms of your initative to look backward and dissect the minutes, perhaps you should also take into consideration the progress of the draft. We have: =20 IETF 72;=20 =20 http://www.ietf.org/old/2009/proceedings/08jul/minutes/radext.txt =20 Introduces draft-lourdelet-radext-ipv6-dhcp-00 - Advice given for doing a rfc3162bis =20 IETF 73; =20 Merged rfc3162bis draft presented. Additionally remarks passed about the WG being overloaded with drafts. Preference expressed for non rfc3162bis approach =20 IETF74 states: =20 draft-lourdelet-radext-ipv6-access introduced. (Just 3 attributes) =20 RADIUS attributes for IPv6 Access Networks, Benoit Lourdelet http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access =20 a. Chair: Document is currently in review for acceptance as a WG work item. Only one review so far, which indicates that the document is not yet ready. Please review the document and send comments to the list!=20 b. Problem statement - RFC3162 needs additions to accommodate IPv6 production networks. Feedback is coming in from actual deployments. Need flexibility.=20 c. IPv6 DNS location needs to be configured on a subscriber basis - wholesale, VPN.=20 d. Implementation can happen in DHCP and SLAAC.=20 e. Review of requirements - individual IPv6 addresses must be offered to the subscriber as concatenation of prefix and interface id attributes does not cover all cases.=20 f. More specific routes should be transmitted to the subscriber - multi-homing, multiple attachments - see draft-dec-dhcpv6-route-option-01.=20 g. Prefix lifetimes must be configured on a prefix basis.=20 h. Glen Zorn: New attributes should be added - No objection to do this from the WG.=20 The above feedback led to changes to the draft, like introducing "lifetimes". At this point however the draft seems to have been OK'ed in principle by the WG, and there was no evidence of the draft having "same negative feedback as had earlier versions" ... =20 =20 IETF75: =20 Discussion had, without presenter, who happened to be there and reportedly did try to present... =20 Redext virtual meeting: =20 Discussion had, without any of the authors. In the runup, emails asking for clarification went unanswered. =20 Now, in terms of your note below (I quote "we did have attendance from people with a concrete interest in a subset of the functionality"), it appears to be some kind of consensus call, which is another rather unorthodox development given all of the previous record. =20 -Woj. =20 =20 =20 =20 ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 23 October 2009 17:48 To: Wojciech Dec (wdec); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 In looking through the WG minutes, I do not see much support for the assertions you make below.=20 =20 The minutes of IETF 73 in Minneapolis (see http://www.ietf.org/proceedings/73/minutes/radext.txt) indicate that the WG gave significant negative feedback on both drafts presented. The "next steps" were for the drafts to incorporate WG feedback and address the concerns. The idea of a merger was brought up (not by me), but was not indicated in the next steps for advancement. =20 =20 The minutes of IETF 74 shows that the presenter did not show up (see http://www.ietf.org/proceedings/74/minutes/radext.htm).=20 =20 The minutes of IETF 75 (see http://www.ietf.org/proceedings/75/minutes/radext.txt) disclose that the the document http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access was presented, and garnered some of the same negative feedback as had earlier versions. =20 =20 While the authors did not attend the virtual interim, we did have attendance from people with a concrete interest in a subset of the functionality. It was David Miles who made the suggestion for the WG to consider http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00 as the way forward, and who also proposed addressing the feedback that had been obtained from the WG at IETF 73 and 75.=20 =20 =20 =09 =09 =09 =20 =09 ________________________________ Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 16:23:07 +0200 From: wdec@cisco.com To: bernard_aboba@hotmail.com; radiusext@ops.ietf.org =09 =09 Bernard, =20 with reference to the minutes below, I would like to post some observations and ask for clarifications: Draft-lourdelet-radext-ipv6-access-01 was the result of merging at least two drafts that had IPv6 as a common theme. This merger was done based on suggestion by the WG as well as your opinion (IETF74) that the WG was overloaded with drafts. Below you appear to steer towards a path that to go back to two drafts since in a single draft some of the proposals would definitely be lost.=20 Now, it's rather unfortunate that at neither IETF 75 nor at the interim meeting below the authors of draft-lourdelet-radext-ipv6-access-01 were heard but that the discussion on the draft happened anyway with conclusions reached. This seems a rather unorthodox way to proceed and has likely been the cause of even more confusion.=20 We're currently planning on a two draft approach, pretty much reverting to the state prior to the "merged draft", along with changes to rid of any datatype issues (fingers crossed) and additional explanatory text. Before we proceed on this path, which to some may seem to be yet another goose chase, could you confirm that this is also your expectation? =20 In addition to the above, at various points it has been claimed that a) there is "little interest" in the WG in this work and/or b) that outstanding comments have not been addressed. Regarding the "lack of interest", this also seems to be a rather odd claim given the array of authors on the drafts, the people offering to review and those having direct discussions on the WG mailer. Are you now convinced of "interest"? In terms of "outstanding comments", with the exception of the datatype debacle, it would be appreciated if you could point to ones that were not addressed. =20 Thanks, Woj. =20 =20 =20 ---snip---=20 =09 IPv6 Attribute Design Considerations =09 Hannes: This document initially did not have much interest, then there was a lot of discussion on the list due to interest from the Broadband Forum. There are a number of ways to address the review from Alan. The document utilizes a tagging scheme similar to, but not exactly the same as RFC 2868. The authors did not want to depend on Extended Attributes since it has not been progressing (and is now expired). =20 =09 Bernard: It seems like many of the attributes that are tagged relate to a router advertisement, correct? Hannes: That is my understanding.=20 Bernard: One of the objections to the current scheme is that it creates multiple new tagged data types.=20 A new attribute is needed for each element of the RA that needs to be expressed. It occurred to me that it might actually be easier to define an opaque blob that carries much of (or the entire) RA. =20 =09 David Nelson: It seems like the lack of progress on Extended Attributes is creating a problem. Design Guidelines says that the RFC 2868 tagging scheme isn't suitable for generic use. But it doesn't make a recommendation. If we don't get Extended Attributes done, then we will be creating a problem.=20 After finishing Design Guidelines, it seems like this needs to be our #2 priority.=20 =09 ---snip---=20 ------_=_NextPart_001_01CA5404.D18DFD31 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Unfortunately your mail did not answer my direct questions, = which are=20 aimed at moving forward.
 
In terms=20 of your initative to look backward and dissect the minutes, perhaps = you=20 should also take into consideration the progress of the draft. We=20 have:
 
IETF 72;=20
 
http://www.ietf.org/old/2009/proceedings/08jul/minutes/radext.txt
 
Introduces draft-lourdelet-radext-ipv6-dhcp-00 - Advice = given for=20 doing a rfc3162bis
 
IETF=20 73;
 
Merged=20 rfc3162bis draft presented. Additionally remarks passed about the WG = being=20 overloaded with drafts.
Preference expressed for non rfc3162bis = approach
 
IETF74=20 states:
 
draft-lourdelet-radext-ipv6-access=20 introduced. (Just 3 attributes)
 
RADIUS attributes for IPv6 = Access=20 Networks, Benoit Lourdelet http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-acces= s
  1. Chair:=20 Document is currently in review for acceptance as a WG work = item. =20 Only one review so far, which indicates that the document is = not yet=20 ready.  Please review the document and send comments = to the=20 list!=20
  2. Problem=20 statement – RFC3162 needs additions to accommodate IPv6 = production networks.=20 Feedback is coming in from actual deployments. Need=20 flexibility.=20
  3. IPv6 DNS=20 location needs to be configured on a subscriber basis – = wholesale,=20 VPN.=20
  4. Implementation can happen in DHCP and=20 SLAAC.=20
  5. Review of=20 requirements – individual IPv6 addresses must be offered to the = subscriber as=20 concatenation of prefix and interface id attributes does not cover all = cases.=20
  6. More=20 specific routes should be transmitted to the subscriber – = multi-homing,=20 multiple attachments – see=20 draft-dec-dhcpv6-route-option-01.=20
  7. Prefix=20 lifetimes must be configured on a prefix = basis.=20
  8. Glen Zorn:=20 New attributes should be added – No objection to do this from = the WG.=20
The above feedback led to = changes to=20 the draft, like introducing "lifetimes".=20 At this point however the = draft seems=20 to have been OK'ed in principle by the WG, and there was no = evidence of the=20 draft having "same negative feedback as had earlier=20 versions" ...
 
 
IETF75:
 
Discussion had, = without=20 presenter, who happened to be there and reportedly did try to=20 present...
 
Redext virtual=20 meeting:
 
Discussion had, without = any of the=20 authors. In the runup, emails asking for clarification went=20 unanswered.
 
Now, in terms = of your note=20 below (I quote "we did have=20 attendance from people with a concrete interest in a subset of the=20 functionality"), it appears to be some kind of consensus call,=20 which is another rather unorthodox development given all of = the=20 previous record.
 
-Woj.
 
 
 
 

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: 23 October 2009=20 17:48
To: Wojciech Dec (wdec);=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

In looking through the WG minutes, I do not see much = support for=20 the assertions you make below.
 
The minutes of IETF 73 in = Minneapolis (see http://www= .ietf.org/proceedings/73/minutes/radext.txt)=20 indicate that the WG gave significant negative feedback on = both=20 drafts presented.  The "next steps" were for the drafts to = incorporate WG=20 feedback and address the concerns.   The idea of a merger = was=20 brought up (not by  me), but was not indicated in = the next=20 steps for advancement. 
 
The minutes of IETF 74 = shows that=20 the presenter did not show up (see http://www= .ietf.org/proceedings/74/minutes/radext.htm).=20
 
The minutes of IETF 75 (see http://www= .ietf.org/proceedings/75/minutes/radext.txt)=20 disclose that the the document ht= tp://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access=20 was presented, and garnered some of the same negative feedback as had = earlier=20 versions. 
 
While the authors did not attend the = virtual=20 interim, we did have attendance from people with a concrete interest = in a=20 subset of the functionality.  It was David Miles who made the = suggestion=20 for the WG to consider h= ttp://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00=20 as the way forward, and who also proposed addressing the feedback that = had=20 been obtained from the WG at IETF 73 and 75.=20
 
 



 
Subject: RE: Draft RADEXT Virtual Interim Minutes
Date: Fri, 23 Oct = 2009=20 16:23:07 +0200
From: wdec@cisco.com
To: = bernard_aboba@hotmail.com;=20 radiusext@ops.ietf.org

Bernard,
 
with reference to the minutes below, I would like to post = some=20 observations and ask for clarifications:
Draft-lourdelet-radext-ipv6-access-01 was the result of = merging at=20 least two drafts that had IPv6 as a common theme. This merger was done = based=20 on suggestion by the WG as well as your opinion (IETF74) that the WG = was=20 overloaded with drafts. Below you appear to steer towards a path that = to go=20 back to  two drafts since in a single draft some of the = proposals=20 would definitely be lost.
Now, it's rather unfortunate that at neither IETF 75 nor = at the=20 interim meeting below the authors of = draft-lourdelet-radext-ipv6-access-01=20 were heard but that the discussion on the draft happened anyway with=20 conclusions reached. This seems a rather unorthodox way = to proceed and=20 has likely been the cause of even more confusion. =
We're currently planning on a two draft approach, pretty = much=20 reverting to the state prior to the "merged draft", along with changes = to rid=20 of any datatype issues (fingers crossed) and additional explanatory = text.=20 Before we proceed on this path, which to some may seem to be yet = another=20 goose chase, could you confirm that this is also your=20 expectation?
 
In=20 addition to the above, at various points it has been claimed = that a)=20 there is "little interest" in the WG in this work and/or b) that = outstanding=20 comments have not been addressed.
Regarding the "lack of interest", this also seems to = be a=20 rather odd claim given the array of authors on the drafts, the = people=20 offering to review and those having direct discussions on the WG = mailer. Are=20 you now convinced of "interest"?
In=20 terms of "outstanding comments", with the exception of the datatype=20 debacle, it would be appreciated if you could point to ones that = were not=20 addressed.
 
Thanks,
Woj.
 
 
 
---snip--- 

IPv6=20 Attribute Design Considerations

Hannes:  This document = initially=20 did not have much interest, then there was a lot of discussion on = the
list=20 due to interest from the Broadband Forum.  There are a number of = ways to=20 address the review from
Alan.  The document utilizes a tagging = scheme=20 similar to, but not exactly the same as RFC 2868.  The
authors = did not=20 want to depend on Extended Attributes since it has not been = progressing (and=20 is now
expired). 

Bernard:  It seems like many of = the=20 attributes that are tagged relate to a router advertisement,=20 correct?
Hannes:  That is my understanding.
Bernard:  = One of=20 the objections to the current scheme is that it creates multiple new = tagged=20 data types.
A new attribute is needed for each element of the RA = that=20 needs to be expressed.  It occurred to me that
it might = actually be=20 easier to define an opaque blob that carries much of (or the entire) = RA. =20

David Nelson: It seems like the lack of progress on Extended=20 Attributes is creating a problem.  Design
Guidelines says that = the RFC=20 2868 tagging scheme isn't suitable for generic use.  But it = doesn't=20 make
a recommendation.  If we don't get Extended Attributes = done, then=20 we will be creating a problem.
After finishing Design Guidelines, = it seems=20 like this needs to be our #2 priority.

---snip--- 
------_=_NextPart_001_01CA5404.D18DFD31-- -- to 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, 23 Oct 2009 16:29:19 +0000 Message-ID: <4AE1D9C6.2070807@deployingradius.com> Date: Fri, 23 Oct 2009 18:28:54 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Behcet Sarikaya CC: "Wojciech Dec (wdec)" , Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Draft RADEXT Virtual Interim Minutes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Behcet Sarikaya wrote: > Hi Alan, > In fact, before the Interim call we had made a revision to address all of your concerns and made the specification to fit within the RADIUS data model, and to be deployed with minimum code changes as you wished. I hadn't seen that revision. My comments were directed to the discussion on this list, and not about anything else. I believe that the functionality defined in the document is useful. I have no major concern with 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: Fri, 23 Oct 2009 16:23:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1256314891; bh=9/XzY9C1iEx4iwuowX3MCImRrsUcoSe/AVsE/SB/qUg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=egyA5V1PBQsZmiIAr9dGPWZUzBbsfXM9OTFVm+uNh3FEHsHb0i2xC9RrKZpdHBbjIxxzwKXmnvcE58z93pZrF5gRzDqEZdav8y+xf7i2abFG52srbefNG6kvsiqTQ+YMDGxGJ40/13je/MIUsnMj3ewagLw1mtuI0JRWo7OyG9w= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pH/laM5JSUz67HgJD60SGFdICYEYkJoHtAhWA4gLjj6mGoBrCi7B4vP0J+mj1RAuFqptXxZEipbCkb25DnO1FsLgY3dln5htamennauUEV4rgZMoXiw6Wrdd9EnFuA1R78u/MXgWJc/gWIaHTCCMtYjAt1Gq1qfAlIDRrvQugOs=; Message-ID: <540408.29377.qm@web111408.mail.gq1.yahoo.com> Date: Fri, 23 Oct 2009 09:21:31 -0700 (PDT) From: Behcet Sarikaya Reply-To: Behcet Sarikaya Subject: Re: Draft RADEXT Virtual Interim Minutes To: Alan DeKok , "Wojciech Dec \(wdec\)" Cc: Bernard Aboba , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alan,=0A=A0 In fact, before the Interim call we had made a revision to a= ddress all of your concerns and made=A0 the specification to fit within the= RADIUS data model, and to be deployed with minimum code changes as you wis= hed.=0A=0AGlen was expected to attend the call and state this. But I think = he got sick and couldn't attend. =0ASigh.=0A=0AI wish Glen a quick recovery= .=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----=0A> From= : Alan DeKok =0A> To: Wojciech Dec (wdec) =0A> Cc: Bernard Aboba ; radiusext@ops= .ietf.org=0A> Sent: Fri, October 23, 2009 10:26:49 AM=0A> Subject: Re: Draf= t RADEXT Virtual Interim Minutes=0A> =0A> Wojciech Dec (wdec) wrote:=0A> > = In terms of "outstanding comments", with the exception of the datatype=0A> = > debacle, it would be appreciated if you could point to ones that were=0A>= > not addressed.=0A> =0A> =A0 The datatype "debacle" can be more correctly= described as:=0A> =0A> Me: Here's a review that results in no functional c= hanges, but allows=0A> the specification to fit within the RADIUS data mode= l, and to be=0A> deployed with minimum code changes=0A> =0A> You: We change= nothing.=0A> =0A> =A0 Alan DeKok.=0A> =0A> --=0A> to unsubscribe send a me= ssage to radiusext-request@ops.ietf.org with=0A> the word 'unsubscribe' in = a single line as the message text body.=0A> archive: =0A=0A=0A=0A -- to 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, 23 Oct 2009 15:49:12 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_86defa2b-e7b3-4c55-a3e2-147fb6bd90e3_" From: Bernard Aboba To: , "radiusext@ops.ietf.org" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 08:48:12 -0700 MIME-Version: 1.0 --_86defa2b-e7b3-4c55-a3e2-147fb6bd90e3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In looking through the WG minutes=2C I do not see much support for the asse= rtions you make below.=20 =20 The minutes of IETF 73 in Minneapolis (see http://www.ietf.org/proceedings/= 73/minutes/radext.txt) indicate that the WG gave significant negative feedb= ack on both drafts presented. The "next steps" were for the drafts to inco= rporate WG feedback and address the concerns. The idea of a merger was br= ought up (not by me)=2C but was not indicated in the next steps for advanc= ement. =20 =20 The minutes of IETF 74 shows that the presenter did not show up (see http:/= /www.ietf.org/proceedings/74/minutes/radext.htm).=20 =20 The minutes of IETF 75 (see http://www.ietf.org/proceedings/75/minutes/rade= xt.txt) disclose that the the document http://tools.ietf.org/html/draft-lou= rdelet-radext-ipv6-access was presented=2C and garnered some of the same ne= gative feedback as had earlier versions. =20 =20 While the authors did not attend the virtual interim=2C we did have attenda= nce from people with a concrete interest in a subset of the functionality. = It was David Miles who made the suggestion for the WG to consider http://t= ools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00 as the way forward= =2C and who also proposed addressing the feedback that had been obtained fr= om the WG at IETF 73 and 75.=20 =20 =20 =20 Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri=2C 23 Oct 2009 16:23:07 +0200 From: wdec@cisco.com To: bernard_aboba@hotmail.com=3B radiusext@ops.ietf.org Bernard=2C =20 with reference to the minutes below=2C I would like to post some observatio= ns and ask for clarifications: Draft-lourdelet-radext-ipv6-access-01 was the result of merging at least tw= o drafts that had IPv6 as a common theme. This merger was done based on sug= gestion by the WG as well as your opinion (IETF74) that the WG was overload= ed with drafts. Below you appear to steer towards a path that to go back to= two drafts since in a single draft some of the proposals would definitely= be lost.=20 Now=2C it's rather unfortunate that at neither IETF 75 nor at the interim m= eeting below the authors of draft-lourdelet-radext-ipv6-access-01 were hear= d but that the discussion on the draft happened anyway with conclusions rea= ched. This seems a rather unorthodox way to proceed and has likely been the= cause of even more confusion.=20 We're currently planning on a two draft approach=2C pretty much reverting t= o the state prior to the "merged draft"=2C along with changes to rid of any= datatype issues (fingers crossed) and additional explanatory text. Before = we proceed on this path=2C which to some may seem to be yet another goose c= hase=2C could you confirm that this is also your expectation? =20 In addition to the above=2C at various points it has been claimed that a) t= here is "little interest" in the WG in this work and/or b) that outstanding= comments have not been addressed. Regarding the "lack of interest"=2C this also seems to be a rather odd clai= m given the array of authors on the drafts=2C the people offering to review= and those having direct discussions on the WG mailer. Are you now convince= d of "interest"? In terms of "outstanding comments"=2C with the exception of the datatype de= bacle=2C it would be appreciated if you could point to ones that were not a= ddressed. =20 Thanks=2C Woj. =20 =20 =20 ---snip---=20 =20 IPv6 Attribute Design Considerations Hannes: This document initially did not have much interest=2C then there w= as a lot of discussion on the list due to interest from the Broadband Forum. There are a number of ways = to address the review from Alan. The document utilizes a tagging scheme similar to=2C but not exactly= the same as RFC 2868. The authors did not want to depend on Extended Attributes since it has not been= progressing (and is now expired). =20 Bernard: It seems like many of the attributes that are tagged relate to a = router advertisement=2C correct? Hannes: That is my understanding.=20 Bernard: One of the objections to the current scheme is that it creates mu= ltiple new tagged data types.=20 A new attribute is needed for each element of the RA that needs to be expre= ssed. It occurred to me that it might actually be easier to define an opaque blob that carries much of (= or the entire) RA. =20 David Nelson: It seems like the lack of progress on Extended Attributes is = creating a problem. Design Guidelines says that the RFC 2868 tagging scheme isn't suitable for generic= use. But it doesn't make a recommendation. If we don't get Extended Attributes done=2C then we will= be creating a problem.=20 After finishing Design Guidelines=2C it seems like this needs to be our #2 = priority.=20 ---snip--- = --_86defa2b-e7b3-4c55-a3e2-147fb6bd90e3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In looking through the WG minutes=2C I do not see much support for the asse= rtions you make below.
 =3B
The minutes of IETF 73 in Minneapolis (see http://www.ietf.org/proceedings/73/minute= s/radext.txt) indicate that the WG gave =3Bsignificant negative&nbs= p=3Bfeedback on both drafts presented. =3B The "next steps" were for th= e drafts to incorporate WG feedback and address the concerns. =3B = =3B The idea of a merger was brought up (not by =3B me)=2C but was not = indicated =3Bin the =3Bnext steps for advancement. =3B
 =3B
The minutes of IETF 74 shows that the presenter did not show up (see http://www.ietf= .org/proceedings/74/minutes/radext.htm).
 =3B
The minutes of IETF 75 (see http://www.ietf.org/proceedings/75/minutes/radext.txt) disclose that the the document http://tools.ietf.org/html/draft-lourdelet= -radext-ipv6-access was presented=2C and garnered some of the same nega= tive feedback as had earlier versions. =3B
 =3B
While the authors did not attend the virtual interim=2C we did have attenda= nce from people with a concrete interest in a subset of the functionality.&= nbsp=3B It was David Miles who made the suggestion for the WG to consider <= A href=3D"http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00">h= ttp://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00 as the wa= y forward=2C and who also proposed addressing the feedback that had been ob= tained from the WG at IETF 73 and 75.
 =3B
 =3B



 =3B
Subject: RE: Draft RADEXT Virtual Interim Minutes
Date: Fri=2C 23 Oct 20= 09 16:23:07 +0200
From: wdec@cisco.com
To: bernard_aboba@hotmail.com= =3B radiusext@ops.ietf.org

Bernard=2C
&nbs= p=3B
with reference to the minutes below=2C I would like to post some o= bservations and ask for clarifications:
Draft-lourdelet-radext-ipv6-access-01 was the result of merging at= least two drafts that had IPv6 as a common theme. This merger was done bas= ed on suggestion by the WG as well as your opinion (IETF74) that the WG was= overloaded with drafts. Below you appear to steer towards a path that to g= o back to =3B two drafts since in a single draft =3Bsome of the pro= posals would definitely be lost.
Now=2C it's rather unfortunate that at neither IETF 75 nor at the = interim meeting below the authors of draft-lourdelet-radext-ipv6-access-01 = were heard but that the discussion on the draft happened anyway with conclu= sions reached. This seems a rather unorthodox way to =3Bproceed and has= likely been the cause of even =3Bmore confusion.
We're currently planning on a two draft approach=2C pretty much re= verting to the state prior to the "merged draft"=2C along with changes to r= id of any datatype issues (fingers crossed) and additional explanatory text= . Before we proceed on this path=2C which to some =3Bmay seem to be yet= another goose chase=2C could you confirm that this is also your expectatio= n?
 =3B
In addition to the above=2C at various points it has been claimed = that =3Ba) there is "little interest" in the WG in this work and/or b) = that outstanding comments have not been addressed.
Regarding the "lack of interest"=2C this also =3Bseems to be a= rather odd claim =3Bgiven the array of authors on the drafts=2C the pe= ople offering to review and those having direct discussions on the WG maile= r. Are you now convinced of "interest"?
In terms of "outstanding comments"=2C with the exception of the da= tatype debacle=2C =3Bit would be appreciated if you could point to ones= that were not addressed.
 =3B
Thanks=2C
Woj.
 =3B
 =3B
&nbs= p=3B
---snip--- = =3B
 =3B
IPv6 Attribute Design Considerations

Hannes: =3B This do= cument initially did not have much interest=2C then there was a lot of disc= ussion on the
list due to interest from the Broadband Forum. =3B The= re are a number of ways to address the review from
Alan. =3B The doc= ument utilizes a tagging scheme similar to=2C but not exactly the same as R= FC 2868. =3B The
authors did not want to depend on Extended Attribut= es since it has not been progressing (and is now
expired). =3B
<= BR>Bernard: =3B It seems like many of the attributes that are tagged re= late to a router advertisement=2C correct?
Hannes: =3B That is my un= derstanding.
Bernard: =3B One of the objections to the current sche= me is that it creates multiple new tagged data types.
A new attribute i= s needed for each element of the RA that needs to be expressed. =3B It = occurred to me that
it might actually be easier to define an opaque blob= that carries much of (or the entire) RA. =3B

David Nelson: It = seems like the lack of progress on Extended Attributes is creating a proble= m. =3B Design
Guidelines says that the RFC 2868 tagging scheme isn't= suitable for generic use. =3B But it doesn't make
a recommendation.=  =3B If we don't get Extended Attributes done=2C then we will be creati= ng a problem.
After finishing Design Guidelines=2C it seems like this n= eeds to be our #2 priority.

---snip--- =3B
= --_86defa2b-e7b3-4c55-a3e2-147fb6bd90e3_-- -- to 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, 23 Oct 2009 15:28:56 +0000 Message-ID: <4AE1CB39.4070605@deployingradius.com> Date: Fri, 23 Oct 2009 17:26:49 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Draft RADEXT Virtual Interim Minutes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wojciech Dec (wdec) wrote: > In terms of "outstanding comments", with the exception of the datatype > debacle, it would be appreciated if you could point to ones that were > not addressed. The datatype "debacle" can be more correctly described as: Me: Here's a review that results in no functional changes, but allows the specification to fit within the RADIUS data model, and to be deployed with minimum code changes You: We change nothing. 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: Fri, 23 Oct 2009 14:28:15 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_1ce7a2f8-53c5-48a6-869a-615ee6068a6d_" From: Bernard Aboba To: Glen Zorn , "radiusext@ops.ietf.org" CC: Subject: RE: ISSUE: Inappropriate usage of RFC 2119 key words Date: Fri, 23 Oct 2009 04:15:00 -0700 MIME-Version: 1.0 --_1ce7a2f8-53c5-48a6-869a-615ee6068a6d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Glen Zorn said: > It is worth noting that since RADIUS only supports unsigned integers > of 32 or 64 bits=2C attributes using signed integer data types or > unsigned integer types of other sizes will require code changes=2C and > SHOULD be avoided. >=20 > It is difficult to see how either harm or interoperability problems could > arise from correctly implemented code changes=3B indeed=2C this appears t= o be a > classic case of the use of RFC 2119 keywords to "try to impose a particul= ar > method on implementers where the method is not required for > interoperability". The issue being described here is not one between RADIUS clients and servers that implement the attribute=2C but rather between a RADIUS client that implements the attribute and a RADIUS server that does not support the attribute or the new type.=20 If instead of using an unsigned 32 bit integer=2C an 8=2C 16 or 24 bit inte= ger=20 is used or a signed integer=2C then existing RADIUS servers will not be abl= e=20 to support the newly defined data type without a code change. =20 While existing RADIUS servers could send the newly defined types as a=20 String=2C this would force network administrators to enter the attributes i= n=20 hex form. This would be likely to cause errors in configuration=2C particu= larly in the case of signed integers.=20 However=2C an issue has been raised about whether RADIUS does in fact support 64-bit integers=2C or whether the data types used in previous attributes were either special types (e.g. Interface ID) or 64-bit octet strings.=20 If WG consensus is that RADIUS does not today support 64-bit integers=2C the choices would be as follows: 1. Recommend the addition of the 64-bit integer data type to implementations=3B=20 2. Remove the reference to 64-bit integers in the above paragraph.=20 = --_1ce7a2f8-53c5-48a6-869a-615ee6068a6d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Glen Zorn said:

>=3B It is worth noting that since RADIUS only = supports unsigned integers
>=3B of 32 or 64 bits=2C attributes usin= g signed integer data types or
>=3B unsigned integer types of other= sizes will require code changes=2C and
>=3B SHOULD be avoided.
= >=3B
>=3B It is difficult to see how either harm or interoperabilit= y problems could
>=3B arise from correctly implemented code changes=3B= indeed=2C this appears to be a
>=3B classic case of the use of RFC 21= 19 keywords to "try to impose a particular
>=3B method on implementers= where the method is not required for
>=3B interoperability".

T= he issue being described here is not one between RADIUS clients and
serv= ers that implement the attribute=2C but rather between
a RADIUS client t= hat implements the attribute and a RADIUS server
that does not support t= he attribute or the new type.

If instead of using an unsigned 32 bi= t integer=2C an 8=2C 16 or 24 bit integer
is used or a signed integer= =2C then existing RADIUS servers will not be able
to support the newly = defined data type without a code change. =3B
While existing RADIUS = servers could send the newly defined types as a
String=2C this would fo= rce network administrators to enter the attributes in
hex form. =3B= This would be likely to cause errors in configuration=2C particularly
i= n the case of signed integers.

However=2C an issue has been raised = about whether RADIUS does in fact
support 64-bit integers=2C or whether = the data types used in previous
attributes were either special types (e.= g. Interface ID) or 64-bit
octet strings.

If WG consensus is tha= t RADIUS does not today support 64-bit
integers=2C the choices would be = as follows:

1. Recommend the addition of the 64-bit integer data typ= e to
implementations=3B

2. Remove the reference to 64-bit intege= rs in the above paragraph.
= --_1ce7a2f8-53c5-48a6-869a-615ee6068a6d_-- -- to 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, 23 Oct 2009 14:28:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=9469; q=dns/txt; s=amsiport01001; t=1256307955; x=1257517555; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20Draft=20RADEXT=20Virtual=20Interim=20Mi nutes|Date:=20Fri,=2023=20Oct=202009=2016:23:07=20+0200 |Message-ID:=20|To:=20"Bernard=20Aboba"=20,=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20; bh=WP07eRoDzBc4g7ub2PAmr7bJfx+X5Fk7krwE/Akl4Zw=; b=lDI2N1y0VZKTH5Wg5poqAhMZcaqTbQK6XyjBNO9YeEdhmTEE9fn8sp6u kkGpr99xoy9CLWVToIvspQGPm0GElk4S8HMQJklE1grAEM8Ii8O4m/5SO 3XeT+qOCcg2mqgLw5eAX70kDuntgPZSW6oa/Pa25zvCHtyc3dMnE+yEDI g=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA53EC.6C72D115" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 23 Oct 2009 16:23:07 +0200 Message-ID: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: AcpMPHD8WLDMgt0UT9+7DTS5wYhD3QHiZLLw From: "Wojciech Dec (wdec)" To: "Bernard Aboba" , This is a multi-part message in MIME format. ------_=_NextPart_001_01CA53EC.6C72D115 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, =20 with reference to the minutes below, I would like to post some observations and ask for clarifications: Draft-lourdelet-radext-ipv6-access-01 was the result of merging at least two drafts that had IPv6 as a common theme. This merger was done based on suggestion by the WG as well as your opinion (IETF74) that the WG was overloaded with drafts. Below you appear to steer towards a path that to go back to two drafts since in a single draft some of the proposals would definitely be lost.=20 Now, it's rather unfortunate that at neither IETF 75 nor at the interim meeting below the authors of draft-lourdelet-radext-ipv6-access-01 were heard but that the discussion on the draft happened anyway with conclusions reached. This seems a rather unorthodox way to proceed and has likely been the cause of even more confusion.=20 We're currently planning on a two draft approach, pretty much reverting to the state prior to the "merged draft", along with changes to rid of any datatype issues (fingers crossed) and additional explanatory text. Before we proceed on this path, which to some may seem to be yet another goose chase, could you confirm that this is also your expectation? =20 In addition to the above, at various points it has been claimed that a) there is "little interest" in the WG in this work and/or b) that outstanding comments have not been addressed. Regarding the "lack of interest", this also seems to be a rather odd claim given the array of authors on the drafts, the people offering to review and those having direct discussions on the WG mailer. Are you now convinced of "interest"? In terms of "outstanding comments", with the exception of the datatype debacle, it would be appreciated if you could point to ones that were not addressed. =20 Thanks, Woj. =20 =20 =20 ---snip---=20 =20 IPv6 Attribute Design Considerations Hannes: This document initially did not have much interest, then there was a lot of discussion on the list due to interest from the Broadband Forum. There are a number of ways to address the review from Alan. The document utilizes a tagging scheme similar to, but not exactly the same as RFC 2868. The authors did not want to depend on Extended Attributes since it has not been progressing (and is now expired). =20 Bernard: It seems like many of the attributes that are tagged relate to a router advertisement, correct? Hannes: That is my understanding.=20 Bernard: One of the objections to the current scheme is that it creates multiple new tagged data types.=20 A new attribute is needed for each element of the RA that needs to be expressed. It occurred to me that it might actually be easier to define an opaque blob that carries much of (or the entire) RA. =20 David Nelson: It seems like the lack of progress on Extended Attributes is creating a problem. Design Guidelines says that the RFC 2868 tagging scheme isn't suitable for generic use. But it doesn't make a recommendation. If we don't get Extended Attributes done, then we will be creating a problem.=20 After finishing Design Guidelines, it seems like this needs to be our #2 priority.=20 ---snip---=20 ------_=_NextPart_001_01CA53EC.6C72D115 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bernard,
 
with=20 reference to the minutes below, I would like to post some observations = and ask=20 for clarifications:
Draft-lourdelet-radext-ipv6-access-01 was the result of = merging at=20 least two drafts that had IPv6 as a common theme. This merger was done = based on=20 suggestion by the WG as well as your opinion (IETF74) that the WG was = overloaded=20 with drafts. Below you appear to steer towards a path that to go back = to =20 two drafts since in a single draft some of the proposals would = definitely=20 be lost.
Now,=20 it's rather unfortunate that at neither IETF 75 nor at the interim = meeting below=20 the authors of draft-lourdelet-radext-ipv6-access-01 were heard but that = the=20 discussion on the draft happened anyway with conclusions reached. This = seems a=20 rather unorthodox way to proceed and has likely been the cause of=20 even more confusion.
We're=20 currently planning on a two draft approach, pretty much reverting to the = state=20 prior to the "merged draft", along with changes to rid of any datatype = issues=20 (fingers crossed) and additional explanatory text. Before we proceed on = this=20 path, which to some may seem to be yet another goose chase, could = you=20 confirm that this is also your expectation?
 
In=20 addition to the above, at various points it has been claimed = that a) there=20 is "little interest" in the WG in this work and/or b) that outstanding = comments=20 have not been addressed.
Regarding the "lack of interest", this also seems to = be a rather=20 odd claim given the array of authors on the drafts, the people = offering to=20 review and those having direct discussions on the WG mailer. Are you now = convinced of "interest"?
In terms=20 of "outstanding comments", with the exception of the datatype = debacle, it=20 would be appreciated if you could point to ones that were not=20 addressed.
 
Thanks,
Woj.
 
 
 
---snip--- 
 
IPv6=20 Attribute Design Considerations

Hannes:  This document = initially did=20 not have much interest, then there was a lot of discussion on = the
list due to=20 interest from the Broadband Forum.  There are a number of ways to = address=20 the review from
Alan.  The document utilizes a tagging scheme = similar=20 to, but not exactly the same as RFC 2868.  The
authors did not = want to=20 depend on Extended Attributes since it has not been progressing (and is=20 now
expired). 

Bernard:  It seems like many of the=20 attributes that are tagged relate to a router advertisement,=20 correct?
Hannes:  That is my understanding.
Bernard:  = One of=20 the objections to the current scheme is that it creates multiple new = tagged data=20 types.
A new attribute is needed for each element of the RA that = needs to be=20 expressed.  It occurred to me that
it might actually be easier = to define=20 an opaque blob that carries much of (or the entire) RA.  =

David=20 Nelson: It seems like the lack of progress on Extended Attributes is = creating a=20 problem.  Design
Guidelines says that the RFC 2868 tagging = scheme isn't=20 suitable for generic use.  But it doesn't make
a = recommendation. =20 If we don't get Extended Attributes done, then we will be creating a = problem.=20
After finishing Design Guidelines, it seems like this needs to be = our #2=20 priority.

---snip--- 
------_=_NextPart_001_01CA53EC.6C72D115-- -- to 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, 23 Oct 2009 05:58:41 +0000 Message-ID: <4AE145A9.2090006@deployingradius.com> Date: Fri, 23 Oct 2009 07:56:57 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org, radext-chairs@ietf.org Subject: Re: FW: ISSUE: Inappropriate usage of RFC 2119 key words Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > The section of the draft in question says: > > It is worth noting that since RADIUS only supports unsigned integers > of 32 or 64 bits, attributes using signed integer data types or > unsigned integer types of other sizes will require code changes, and > SHOULD be avoided. > > It is difficult to see how either harm or interoperability problems could > arise from correctly implemented code changes; indeed, this appears to be a > classic case of the use of RFC 2119 keywords to "try to impose a particular > method on implementors where the method is not required for > interoperability". I welcome suggestions for how implementations can *meaningfully* interoperate when they have different interpretations for an attribute. i.e. one defines an attribute to be "signed 24-bit integer counter, little endian", and the other doesn't support that data type. None of the meanings of the novel integer type (e.g. counter) can be used by the second implementation. It can only treat the field as "string of undistinguished octets". Therefore, they cannot be said to inter-operate according to the definition of the attribute. The alternative is to interpret "inter-operate" as "sends / receives opaque data without agreeing on the format, meaning, or processing of that data". If that is our definition of the word, then we can say that DHCP inter-operates with RADIUS. And the term loses all meaning. > Requested change: > Since the only rationale offered for the prohibition is the spurious one of > avoiding code changes (something that is certainly implementation-specific), > the section should be removed altogether. This issue should be rejected. RADIUS specifications define format, meaning, interpretations, and processing requirements for attributes. Two implementations that disagree about an attribute can inter-operate at the RADIUS level by exchanging RADIUS packets. They cannot be said have interoperable implementations of the attribute. 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: Thu, 22 Oct 2009 21:05:08 +0000 From: "Glen Zorn" To: Cc: Subject: FW: ISSUE: Inappropriate usage of RFC 2119 key words Date: Thu, 22 Oct 2009 16:37:18 +0700 Message-ID: <007001ca52fb$4bb36f40$e31a4dc0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpS2fN5gpPJrIQ8RhKVKVK2iSAGaAAISLEg Content-Language: en-us -----Original Message----- From: Glen Zorn [mailto:gwz@net-zen.net] Sent: Thursday, October 22, 2009 12:39 PM To: 'radiusext@ops.ietf.org' Cc: 'iesg@ietf.org' Subject: ISSUE: Inappropriate usage of RFC 2119 key words Description of issue: Inappropriate usage of RFC 2119 key words Submitter name: Glen Zorn Submitter email address: gwz@net-zen.net Date first submitted: 22 October 2009 Document: draft-ietf-radext-design-09 Comment type: T Priority: S Section: 2.1.1 Rationale/Explanation of issue: Section 6 of RFC 2119 states: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. The section of the draft in question says: It is worth noting that since RADIUS only supports unsigned integers of 32 or 64 bits, attributes using signed integer data types or unsigned integer types of other sizes will require code changes, and SHOULD be avoided. It is difficult to see how either harm or interoperability problems could arise from correctly implemented code changes; indeed, this appears to be a classic case of the use of RFC 2119 keywords to "try to impose a particular method on implementors where the method is not required for interoperability". Requested change: Since the only rationale offered for the prohibition is the spurious one of avoiding code changes (something that is certainly implementation-specific), the section should be removed altogether. -- to 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, 22 Oct 2009 14:51:57 +0000 Message-ID: <4AE07181.3010600@deployingradius.com> Date: Thu, 22 Oct 2009 16:51:45 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: 'Glen Zorn' , radiusext@ops.ietf.org Subject: Re: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Glen Zorn said: > > "There is another, less anal-retentive alternative: that the string of > octets > does, in fact, represent an IPv6 address. That's it, and that's pretty much > what the RFC says." > > If that were the case, why didn't the document use the term "String" in > defining the NAS-IPv6-Address and Login-IPv6-Host attributes instead of > "Address"? I've filed an errata against RFC 3162 to clarify this point. Either RFC 3162 is wrong, and those attributes are of type "string", OR Glen's objection to the guidelines document is wrong, and RFC 3162 defines an IPv6 address type. 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: Thu, 22 Oct 2009 14:47:36 +0000 Message-ID: <4AE07073.5030900@deployingradius.com> Date: Thu, 22 Oct 2009 16:47:15 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org, 'IESG IESG' Subject: Re: FW: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote > There is another, less anal-retentive alternative: that the string of octets > does, in fact, represent an IPv6 address. That's it, and that's pretty much > what the RFC says. a) fix RFC 3162 to use the RFC 2865 data types or b) agree that IPv6 data types were defined by you in RADIUS. You seem to have chosen (b). Therefore, your objection that the "guidelines" document invents the IPv6 address data type has been withdrawn. 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: Thu, 22 Oct 2009 14:47:30 +0000 Message-ID: From: "Bernard Aboba" To: "'Glen Zorn'" , "'Alan DeKok'" CC: Subject: RE: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Date: Thu, 22 Oct 2009 07:47:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTF6wWh/tb+NItRECdMTFP/9PF0gAB2TcwAAG1bYA= Content-Language: en-us Glen Zorn said: "There is another, less anal-retentive alternative: that the string of octets does, in fact, represent an IPv6 address. That's it, and that's pretty much what the RFC says." If that were the case, why didn't the document use the term "String" in defining the NAS-IPv6-Address and Login-IPv6-Host attributes instead of "Address"? -- to 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, 22 Oct 2009 14:36:49 +0000 Message-ID: From: "Bernard Aboba" To: "'Glen Zorn'" , Subject: RE: ISSUE: Inappropriate use of RFC 2119 key word and misleading references Date: Thu, 22 Oct 2009 07:36:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTAtRQDXFeoTmGRyyf0ys3ODVk+gAAmJ9gAAeq/tA= Content-Language: en-us Glen Zorn said: "Glancing at section 4.1 of that document (it's too long to quote here) makes it abundantly clear that the Interface-Id field of the Framed-Interface-Id attribute was designed not as an integer but as a specially formatted octet string. Neither RFC 2869 nor RFC 3162 uses the term "integer64", for good reason; interestingly, RFC 2869 _does_ define data types, but "integer64" is not among the types defined (again, for good reason). Therefore, it is technically incorrect to claim that either of the referenced RFCs defines an "integer64" data type." Requested change: Given that the "integer64" data type has never in fact been defined by any RFC, either all mention of it must be removed from this draft or the text changed to make clear that it is an invention of the author. [BA] How about this? In Section 2.1.1 change: " IPv6 address 128 bit value, in network byte order. IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 128 bits of value, in network byte order. integer64 64 bit unsigned value, in network byte order This type has also been used to represent an IPv6 interface identifier. Examples of the IPv6 address type include NAS-IPv6-Address defined in [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, and in [RFC4818] Section 3. The integer64 type is used for the ARAP- Challenge-Response Attribute defined in [RFC2869] Section 5.15, and the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in length, but denotes it as type String. Given that attributes of type IPv6 address, IPv6 prefix, and integer64 are already in use, it is RECOMMENDED that RADIUS server implementations include support for these additional basic types, in addition to the types defined in [RFC2865]. " To: " IPv6 address 128 bit value, in network byte order. IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 128 bits of value, in network byte order. Interface ID 64 bit octet string, in network byte order, used to represent an IPv6 Interface identifier. Examples of the IPv6 address type include NAS-IPv6-Address defined in [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, and in [RFC4818] Section 3. The Interface ID type is used for the the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in length, but denotes it as type String. Given that attributes of type IPv6 address, IPv6 prefix, and Interface ID are already in use, it is recommended that RADIUS server implementations include support for these additional basic types, in addition to the types defined in [RFC2865]. " -- to 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, 22 Oct 2009 14:23:07 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: , "'IESG IESG'" Subject: RE: FW: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Date: Thu, 22 Oct 2009 21:21:11 +0700 Message-ID: <00b401ca5322$f16a00d0$d43e0270$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTF6wWh/tb+NItRECdMTFP/9PF0gAB2Tcw Content-Language: en-us Alan DeKok [mailto:aland@deployingradius.com] writes: > Alan DeKok wrote: > > Glen Zorn wrote: > >> However, simply examining the references shows that none of the RFCs > cited > >> define _any_ "data types". > > And to fore-stall any discussion about IPv6... By all means, since that was the subject of the comment. > the RFCs referenced > *do* define RADIUS "value" fields that carry IPv6 addresses. > > Since RFC 2865 defines the "value" field of attributes to carry "data > types", Indeed it does, in section 5. More specifically, it says "The format of the value field is one of five data types." Which of the five is "IPv6 Address"? (It also ignores this statement almost entirely, as do the majority of RADIUS RFCs.) > and the IPv6 RFC you co-authored lists the "value" field as > carrying an IPv6 address, the only possible conclusion is that you have > personally created and defined the "ipv6 address" data type. Let me see if I've got this straight: I, and my co-authors, were actually _inventing_ new RADIUS data types but were just too stupid to know it; further, it was OK back then to "invent" new RADIUS data types back then (because you have given your stamp of approval) but now & forevermore it's bad because you say so. > > The alternative is to conclude that the document you wrote specifying > the "value" field as an "IPv6 Address" does not, in fact, specify any > data type for that field. There is another, less anal-retentive alternative: that the string of octets does, in fact, represent an IPv6 address. That's it, and that's pretty much what the RFC says. > > i.e. The statement that the field is an "Ipv6 address", and the > definition of it as "Address of 16 octets" RFC 3126 does not contain those words. > should instead be > interpreted > to mean "string of undistinguished octets with no obvious meaning". > > The only possible way to conclude that IPv6 data types don't exist in > RADIUS is to disown the documents that you wrote. I expect that you > will therefore shortly file errata for those RFCs, withdrawing all > statements that the "value" field of IPv6 attributes have any meaning. OK, so what is the "data type" of the Login-IPv6-Host Attribute? > > I expect that you will, of course, also re-name the attributes at the > same time. For example, "NAS-IPv6-Address" should be renamed as > "NAS-String-Of-No-Meaning". > > 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: Thu, 22 Oct 2009 13:51:37 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: , "'IESG IESG'" Subject: RE: FW: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Date: Thu, 22 Oct 2009 20:49:39 +0700 Message-ID: <00ad01ca531e$8a5bd980$9f138c80$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTFbRtp5XrAYQqTlSPH+Oof/8n0gABwgng Content-Language: en-us Alan DeKok [mailto:aland@deployingradius.com] writes: > > However, simply examining the references shows that none of the RFCs > cited > > define _any_ "data types". > > Unfortunately, I know how to use "grep". Even more unfortunately, you don't seem to know how to read. The original message read "However, simply examining the references shows that none of the RFCs cited define _any_ "data types", the "RFCs cited" being 3162, 2869, 4818 & 4675 but not 2865. Please start making sense. > > $ grep "data type" rfc2865.txt > ... > The format of the value field is one of five data types. Note > standard Attributes do not use this data type but it is > ... > > That was difficult. Now let's read the document in more detail to > see > what it says. From RFC 2865 Section 5, Page 25: > > > The format of the value field is one of five data types. Note > that type "text" is a subset of type "string". > > > It goes on to name the five data types, and give definitions for each > one. These data types are then used in the attribute definitions in > RFC > 2865, and in other RADIUS RFCs. Show us. I've already given multiple counter-examples from RFC 2865; can you just show one? > > In addition, this text is taken from RFC 2058, which was written over > a decade ago, and says: > > > The format of the value field is one of four data types. > > > Of course, that isn't the whole story. To highlight the irony (or > hypocrisy), these data types are used by you in RFCs that you either > authored or co-authored: > > RFC 2548 > RFC 2867 > RFC 2868 > RFC 3162 > > > Requested change: > > Either delete the entire section or modify it to be a more reasonable > and > > justified _description_ of formats that have been previously used in > RADIUS > > to carry quantities related to IPv6, rather than using irrelevant > references > > to attempt to justify the _prescription_ of future behavior. > > This issue should be rejected out of hand. The concept of "data > types" goes back to the beginning of RADIUS, and was part of the > original protocol specification. The data types in question are "IPv6 address", "IPv6 prefix" and "integer64". These do not exist as "data types" in any existing RFC. If you can't make sense, at least pay attention. > > 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: Thu, 22 Oct 2009 13:01:08 +0000 Message-ID: <4AE05779.6000605@deployingradius.com> Date: Thu, 22 Oct 2009 15:00:41 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org, IESG IESG Subject: Re: FW: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Alan DeKok wrote: > Glen Zorn wrote: >> However, simply examining the references shows that none of the RFCs cited >> define _any_ "data types". And to fore-stall any discussion about IPv6... the RFCs referenced *do* define RADIUS "value" fields that carry IPv6 addresses. Since RFC 2865 defines the "value" field of attributes to carry "data types", and the IPv6 RFC you co-authored lists the "value" field as carrying an IPv6 address, the only possible conclusion is that you have personally created and defined the "ipv6 address" data type. The alternative is to conclude that the document you wrote specifying the "value" field as an "IPv6 Address" does not, in fact, specify any data type for that field. i.e. The statement that the field is an "Ipv6 address", and the definition of it as "Address of 16 octets" should instead be interpreted to mean "string of undistinguished octets with no obvious meaning". The only possible way to conclude that IPv6 data types don't exist in RADIUS is to disown the documents that you wrote. I expect that you will therefore shortly file errata for those RFCs, withdrawing all statements that the "value" field of IPv6 attributes have any meaning. I expect that you will, of course, also re-name the attributes at the same time. For example, "NAS-IPv6-Address" should be renamed as "NAS-String-Of-No-Meaning". 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: Thu, 22 Oct 2009 12:48:05 +0000 Message-ID: <4AE0542C.4030909@deployingradius.com> Date: Thu, 22 Oct 2009 14:46:36 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org, IESG IESG Subject: Re: FW: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > However, simply examining the references shows that none of the RFCs cited > define _any_ "data types". Unfortunately, I know how to use "grep". $ grep "data type" rfc2865.txt ... The format of the value field is one of five data types. Note standard Attributes do not use this data type but it is ... That was difficult. Now let's read the document in more detail to see what it says. From RFC 2865 Section 5, Page 25: The format of the value field is one of five data types. Note that type "text" is a subset of type "string". It goes on to name the five data types, and give definitions for each one. These data types are then used in the attribute definitions in RFC 2865, and in other RADIUS RFCs. In addition, this text is taken from RFC 2058, which was written over a decade ago, and says: The format of the value field is one of four data types. Of course, that isn't the whole story. To highlight the irony (or hypocrisy), these data types are used by you in RFCs that you either authored or co-authored: RFC 2548 RFC 2867 RFC 2868 RFC 3162 > Requested change: > Either delete the entire section or modify it to be a more reasonable and > justified _description_ of formats that have been previously used in RADIUS > to carry quantities related to IPv6, rather than using irrelevant references > to attempt to justify the _prescription_ of future behavior. This issue should be rejected out of hand. The concept of "data types" goes back to the beginning of RADIUS, and was part of the original protocol specification. 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: Thu, 22 Oct 2009 10:49:21 +0000 From: "Glen Zorn" To: Subject: FW: ISSUE: Inappropriate use of RFC 2119 key word and misleading references Date: Thu, 22 Oct 2009 17:48:55 +0700 Message-ID: <008401ca5305$4622fb40$d268f1c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpTAtRQDXFeoTmGRyyf0ys3ODVk+gAAmJ9g Content-Language: en-us -----Original Message----- From: Glen Zorn [mailto:gwz@net-zen.net] Sent: Thursday, October 22, 2009 5:32 PM To: 'radiusext@ops.ietf.org' Cc: 'radext-chairs@ietf.org'; 'iesg@ietf.org'; 'Alan DeKok'; gdweber@gmail.com Subject: ISSUE: Inappropriate use of RFC 2119 key word and misleading references Description of issue: Misleading references and invention of integer64 data type Submitter name: Glen Zorn Submitter email address: gwz@net-zen.net Date first submitted: 22 October 2009 Document: draft-ietf-radext-design-09 Comment type: T Priority: S Section: 2.1.1 Rationale/Explanation of issue: The relevant section of the draft in question says: The integer64 type is used for the ARAP- Challenge-Response Attribute defined in [RFC2869] Section 5.15, and the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in length, but denotes it as type String. Given that attributes of type IPv6 address, IPv6 prefix, and integer64 are already in use, it is RECOMMENDED that RADIUS server implementations include support for these additional basic types, in addition to the types defined in [RFC2865]. This is what RFC 2869 says about the Value field of the APAP-Challenge-Response Attribute: Value The Value field contains an 8 octet response to the dial-in client's challenge. The RADIUS server calculates this value by taking the dial-in client's challenge from the high order 8 octets of the ARAP-Password attribute and performing DES encryption on this value with the authenticating user's password as the key. If the user's password is less than 8 octets in length, the password is padded at the end with NULL octets to a length of 8 before using it as a key. If one takes the word "integer" as having its normal meaning it is obvious that far from defining a 64-bit integer data type the only thing that the ARAP-Challenge-Response attribute has in common with a 64-bit integer is its length. The same is true, in spades, for the Framed-Interface-Id Attribute: the attribute was designed to carry the Interface-Identifier IPCOv6 option (RFC 2472). Glancing at section 4.1 of that document (it's too long to quote here) makes it abundantly clear that the Interface-Id field of the Framed-Interface-Id attribute was designed not as an integer but as a specially formatted octet string. Neither RFC 2869 nor RFC 3162 uses the term "integer64", for good reason; interestingly, RFC 2869 _does_ define data types, but "integer64" is not among the types defined (again, for good reason). Therefore, it is technically incorrect to claim that either of the referenced RFCs defines an "integer64" data type. Requested change: Given that the "integer64" data type has never in fact been defined by any RFC, either all mention of it must be removed from this draft or the text changed to make clear that it is an invention of the author. -- to 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, 22 Oct 2009 10:49:03 +0000 From: "Glen Zorn" To: Subject: FW: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Date: Thu, 22 Oct 2009 17:48:31 +0700 Message-ID: <008301ca5305$39d5b850$ad8128f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpS+8fZPfiibd76Sb+T5zJdBncaRwACV5YQ Content-Language: en-us -----Original Message----- From: Glen Zorn [mailto:gwz@net-zen.net] Sent: Thursday, October 22, 2009 4:41 PM To: 'radiusext@ops.ietf.org' Cc: 'iesg@ietf.org' Subject: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Description of issue: The definition of RADIUS IPv6 "data types" arbitrary and unjustified Submitter name: Glen Zorn Submitter email address: gwz@net-zen.net Date first submitted: 22 October 2009 Document: draft-ietf-radext-design-09 Comment type: T Priority: S Section: 2.1.1 Rationale/Explanation of issue: The section in question states: In addition to these data types, follow-on RADIUS specifications define attributes using the following additional types: IPv6 address 128 bit value, in network byte order. IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to 128 bits of value, in network byte order. integer64 64 bit unsigned value, in network byte order This type has also been used to represent an IPv6 interface identifier. Examples of the IPv6 address type include NAS-IPv6-Address defined in [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, and in [RFC4818] Section 3. The integer64 type is used for the ARAP- Challenge-Response Attribute defined in [RFC2869] Section 5.15, and the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2. [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in length, but denotes it as type String. Given that attributes of type IPv6 address, IPv6 prefix, and integer64 are already in use, it is RECOMMENDED that RADIUS server implementations include support for these additional basic types, in addition to the types defined in [RFC2865]. However, simply examining the references shows that none of the RFCs cited define _any_ "data types". The claim made is arbitrary and unjustified; essentially, the author is inventing the "data types" out of thin air. Requested change: Either delete the entire section or modify it to be a more reasonable and justified _description_ of formats that have been previously used in RADIUS to carry quantities related to IPv6, rather than using irrelevant references to attempt to justify the _prescription_ of future behavior. -- to 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, 22 Oct 2009 10:48:23 +0000 From: "Glen Zorn" To: "'Adrian Farrel'" Cc: , Subject: RE: ISSUE: definition of RADIUS IPv6 "data types" arbitrary and unjustified Date: Thu, 22 Oct 2009 17:46:28 +0700 Message-ID: <008201ca5304$f1d6a0f0$d583e2d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpS/tYPlWw4VswqTYmsAl/rgQ4eCQABG5lQ Content-Language: en-us Adrian Farrel [mailto:Adrian.Farrel@huawei.com] writes: > Hi Glen, > > Second of your Issue tracker emails to arrive today. And more to come ;-). > Is there any > specific > action you are asking from the IESG, or is this for info? Yes, I would request the termination of IESG review and return of this terribly flawed document to the WG. I realize that it's pretty late in the process, but it seems clear to me (and I hope, given the content of the messages you mention above) that, despite all the Last Calls, etc., no one has read this draft really carefully (I know that I hadn't); that, alone, should keep it off the RFC Editor's queue until it is fixed. ... -- to 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, 21 Oct 2009 12:33:16 +0000 Message-ID: <4ADEFF31.8060507@deployingradius.com> Date: Wed, 21 Oct 2009 14:31:45 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: 'radext mailing list' Subject: Re: Last comments on design guidelines document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > [BA] They don't specify mandatory behavior in existing implementations > either, correct? How about this? Yes, that is correct. > "The uses of "MUST" and "MUST NOT" in this > document are limited to (a) requirements to follow the IETF process > for IETF standards, and (b) quotes from other documents. As a result, > the use of MUST and MUST NOT in this document does not prescribe > mandatory behavior within implementations." OK. Looks good to me. > Alan also said: > > "2) Notes on attributes for authentication and security. Section A.2.2. > Current text: > > * That a RADIUS server and/or client is expected to parse? > i.e. A type that cannot be treated as opaque data (Section A.1.3) > > Replacement text: > > * That a RADIUS server and/or client is expected to parse, validate, > or create the contents of via a computation? > i.e. A type that cannot be treated as opaque data (Section A.1.3)" > > [BA] Doesn't this still leave the broad authentication/security exemption in > place? Hmm... maybe we could simply delete the third bullet. > The third bullet still says: > > " * for purposes other than authentication or security?" Yes. It's probably better to remove that exemption, and instead to rely on the "computation" text above. > Also, the text in Section 2.1.3 remains unchanged: > > " As a > result, the introduction of new complex data types within RADIUS > attribute specifications SHOULD be avoided, except in the case of > complex attributes involving authentication or security > functionality." > > My understanding was that the security/authentication exemption was > considered too broad. How about this? Yes. > In Section 2.1.3, change the text to the following: > > "As a result, the introduction of new complex data types within RADIUS > attribute specifications SHOULD be avoided. A potential exception to > this recommendation occurs for attributes that inherently require > code changes on both the client and server. For example, as described > in Appendix B, complex attributes have been used in situations > involving authentication and security attributes that need to be > dynamically computed and verified." That looks good to me. > A suggestion for the text in Section A.2.2: > > " A.2.2. Complex Data Types > > Does the attribute: > > * define a complex data type that a RADIUS server and/or client > is expected to parse? (i.e. a type that cannot be treated as > opaque data (Section A.1.3). > > * involve functionality that could be implemented without code > changes on both the client and server? (i.e. a type that > doesn't require dynamic computation and verification, such > as authentication or security attributes) > > If so, this data type SHOULD be replaced with simpler types, as > discussed above in Appendix A.2.1. Also see Section 2.1.3 for a > discussion of why complex types are problematic. OK. I think that's clearer. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 20 Oct 2009 22:41:45 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_aa4d3713-89ec-4984-b8f1-5c7d76f2d7b6_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RADEXT WG meeting plans at IETF 76 & 77 Date: Tue, 20 Oct 2009 15:41:13 -0700 MIME-Version: 1.0 --_aa4d3713-89ec-4984-b8f1-5c7d76f2d7b6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As you have noticed=2C the RADEXT WG is not scheduled to meet at IETF 76. = We are planning to meet at IETF 77=2C and will also be likely to schedule = another Virtual Interim between now and then.=20 In between the recent October 13 Virtual Interim and IETF 77=2C our goals a= re to: a. Publish the Design Guidelines document as an RFC=2C including hammering = out the text of any required RFC Editor notes=3B=20 b. Address all outstanding issues on the Extended Attributes document=2C in order to ready it for submission to the IESG for consideration as a Proposed Standard=3B=20 c. Address all outstanding issues on the RADSEC=2C RADIUS over TCP and Stat= us-Server documents=2C and initiate and complete a final RADEXT WG last cal= l on them=3B d. Revise the IEEE 802 attributes=2C RADIUS over DTLS and IPv6 Access documents=2C and run and conclude a Call for Adoption on them=3B To meet these ambitious goals=2C I would strongly urge authors of the above= documents with outstanding issues to send proposed changes to the list=2C = so that we can get feedback on them and ready revised documents for submiss= ion by the deadline.=20 = --_aa4d3713-89ec-4984-b8f1-5c7d76f2d7b6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As you have noticed=2C the RADEXT WG is not scheduled to meet at IETF 76.&n= bsp=3B =3B We are planning to meet at IETF 77=2C and will also be likel= y to schedule another Virtual Interim between now and then.

In betw= een the recent October 13 Virtual Interim and IETF 77=2C our goals are to:<= br>
a. Publish the Design Guidelines document as an RFC=2C including ham= mering out the text of any required RFC Editor notes=3B

b. Address = all outstanding issues on the Extended Attributes document=2C in order to ready it for submission to the IESG for consideration as a Proposed Standard=3B

c. Address all outstanding issues on the RADSE= C=2C RADIUS over TCP and Status-Server documents=2C and initiate and comple= te a final RADEXT WG last call on them=3B

d. Revise the IEEE 802 att= ributes=2C RADIUS over DTLS and IPv6 Access documents=2C and run and conclude a Call for Adoption on them=3B

To = meet these ambitious goals=2C I would strongly urge authors of the above do= cuments with outstanding issues to send proposed changes to the list=2C so = that we can get feedback on them and ready revised documents for submission= by the deadline.
=

<= /td>
= --_aa4d3713-89ec-4984-b8f1-5c7d76f2d7b6_-- -- to 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, 20 Oct 2009 22:25:25 +0000 Message-ID: From: "Bernard Aboba" To: "'Alan DeKok'" , "'radext mailing list'" Subject: RE: Last comments on design guidelines document Date: Tue, 20 Oct 2009 15:20:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpRibOoYFafSfX/T2ueCSfEgaljRQARoN7w Content-Language: en-us Alan DeKok said: " The following text should be added to the document during the RFC editor process, as suggested in the call last week: 1) Note on "MUST" and "MUST NOT" in the text. Section 1.3, before the final paragraph, add the following new sentence: The suggestions given below specify no mandatory behavior on new implementations. The uses of "MUST" and "MUST NOT" in this document are limited to (a) requirements to follow the IETF process for IETF standards, and (b) quotes from other documents. The advice in this document applies to attributes used to encode ..." [BA] They don't specify mandatory behavior in existing implementations either, correct? How about this? "The uses of "MUST" and "MUST NOT" in this document are limited to (a) requirements to follow the IETF process for IETF standards, and (b) quotes from other documents. As a result, the use of MUST and MUST NOT in this document does not prescribe mandatory behavior within implementations." Alan also said: "2) Notes on attributes for authentication and security. Section A.2.2. Current text: * That a RADIUS server and/or client is expected to parse? i.e. A type that cannot be treated as opaque data (Section A.1.3) Replacement text: * That a RADIUS server and/or client is expected to parse, validate, or create the contents of via a computation? i.e. A type that cannot be treated as opaque data (Section A.1.3)" [BA] Doesn't this still leave the broad authentication/security exemption in place? The third bullet still says: " * for purposes other than authentication or security?" Also, the text in Section 2.1.3 remains unchanged: " As a result, the introduction of new complex data types within RADIUS attribute specifications SHOULD be avoided, except in the case of complex attributes involving authentication or security functionality." My understanding was that the security/authentication exemption was considered too broad. How about this? In Section 2.1.3, change the text to the following: "As a result, the introduction of new complex data types within RADIUS attribute specifications SHOULD be avoided. A potential exception to this recommendation occurs for attributes that inherently require code changes on both the client and server. For example, as described in Appendix B, complex attributes have been used in situations involving authentication and security attributes that need to be dynamically computed and verified." A suggestion for the text in Section A.2.2: " A.2.2. Complex Data Types Does the attribute: * define a complex data type that a RADIUS server and/or client is expected to parse? (i.e. a type that cannot be treated as opaque data (Section A.1.3). * involve functionality that could be implemented without code changes on both the client and server? (i.e. a type that doesn't require dynamic computation and verification, such as authentication or security attributes) If so, this data type SHOULD be replaced with simpler types, as discussed above in Appendix A.2.1. Also see Section 2.1.3 for a discussion of why complex types are problematic. " -- to 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, 20 Oct 2009 13:27:33 +0000 Message-ID: <4ADDAEE1.7040405@deployingradius.com> Date: Tue, 20 Oct 2009 14:36:49 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: 'radext mailing list' Subject: Last comments on design guidelines document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The following text should be added to the document during the RFC editor process, as suggested in the call last week: 1) Note on "MUST" and "MUST NOT" in the text. Section 1.3, before the final paragraph, add the following new sentence: The suggestions given below specify no mandatory behavior on new implementations. The uses of "MUST" and "MUST NOT" in this document are limited to (a) requirements to follow the IETF process for IETF standards, and (b) quotes from other documents. The advice in this document applies to attributes used to encode ... 2) Notes on attributes for authentication and security. Section A.2.2. Current text: * That a RADIUS server and/or client is expected to parse? i.e. A type that cannot be treated as opaque data (Section A.1.3) Replacement text: * That a RADIUS server and/or client is expected to parse, validate, or create the contents of via a computation? i.e. A type that cannot be treated as opaque data (Section A.1.3) 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, 14 Oct 2009 06:03:35 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Wed, 14 Oct 2009 13:01:57 +0700 Message-ID: <020e01ca4c93$dd969fe0$98c3dfa0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020F_01CA4CCE.89F577E0" Thread-Index: AcpMPSTxkUWT8iYvRoWwk97zOuN1jAAVqV5A Content-Language: en-us This is a multi-part message in MIME format. ------=_NextPart_000_020F_01CA4CCE.89F577E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't see a list of attendees. From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Wednesday, October 14, 2009 2:35 AM To: radiusext@ops.ietf.org Subject: Draft RADEXT Virtual Interim Minutes Here is a draft of the RADEXT WG Virtual Interim Minutes. Please take a look at these minutes and add/edit/correct as necessary. =============================================== Minutes of the RADEXT WG Virtual Interim October 13, 2009 Design Guidelines Alan: -09 has been submitted. This includes a number of clarifications with respect to tags, VSA formats, simple versus complex types. There are no MUSTs or MUST NOTs in the document. Guidelines try to encourage good practice, but should not be followed slavishly. Dan: Jari has cleared his discuss. So the document could be sent to the RFC Editor for publication immediately. Bernard: Not clear that the document is ready. There are still two open issues from IETF last call: Issues 313 and 314. Issue 313 concerns the "security exemption". Does this apply to any attribute relating to security or authentication? There was confusion on this point during the review of the PKMv1 document. For user authentication or RADIUS security attributes there is computation involved: the client has to compute something and the server has to verify, or vice-versa. If an attribute relates to security (e.g. sending a certificate) but there is no computation, does the exemption still apply? In that case, it might have been possible to use the String type, but a complex attribute would require new code on both the client and server. Issue 314 was filed by Hannes. It was to be followed by specific text to address the concerns, but this wasn't provided. Hannes: The state of the art has advanced. In some designs addition of code is no longer a big issue, scripts can be plugged in. Also, parsers have improved, and could enable complex attributes to be supported automatically. So are we locking ourselves into the past? David Nelson: Many RADIUS server implementations utilize a data dictionary. This allows administrators to add the definition of a new attribute without having to upgrade the server. If an attribute doesn't have to require a server upgrade, that is probably a good thing. Bernard: There are a lot of legacy RADIUS servers out there that implement the data dictionary model described in RFC 2865. For those implementations, the data dictionary provides benefits. It can save administrators time and money, allowing them to support a new attribute immediately without waiting for a RADIUS server upgrade. David Nelson: It is also possible to use opaque attributes, where the data is not parsed by RADIUS but by some other component. Those attributes are sent to and from a plugin. Dan Romascanu: There is also the question of whether normative language is being used in the same way as described in RFC 2119. Do we need to update the draft? Bernard Aboba: How about an RFC Editor note? Dan: That would be easier. David Nelson: I think it would be best to get the document published and then see how well it works in the real world. Bernard: So far, we've used it in reviewing two documents, the PKMv1 document, and the IPv6 access document. In both cases, there was confusion about how the guidelines applied that required clarifications in the text. So the "real world" experience is not so good. That's why the document has taken so long to finish. Bernard: Alan -- can you take the action item to work with Dan on addressing the RFC 2119 issue as well as proposing an RFC Editor note to address issue 313? Status Server Alan: This draft was revised. An applicability subsection was added. There were some terminology changes. David Nelson: Does this document just describe what has been deployed, or does it also describe how Status-Server is used in RADSEC? Alan: It is focused on what has been implemented. The RADSEC document uses Status-Server as an RFC 3539 Watchdog, but that is covered in the RADSEC document. Bernard: Status-Server was originally implemented by Ascend in their concentrators. Alan: It was subsequently implemented in RADIATOR and FreeRADIUS. Bernard: It would be good if we could get some additional reviewers to look at whether the document accurately describes their implementations. This isn't a standards-track document; its job is just to describe what has been implemented. Do we have any volunteers: David Nelson: I will take a look at it. RADIUS over TCP Alan: We added text to the applicability section. We're now using the term "RADIUS over TLS" instead of a vendor's product name (RADSEC). We also added text on the head-of-line blocking issue. Bernard: As I recall, Magnus (Transport AD) raised this issue initially. What can be done to address this issue other than opening multiple TCP connections? Alan: Nothing. Dan: What is the issue specifically? Alan: If a packet is lost, then all traffic that was intended to travel on the TCP connection has to wait until the data at the head-of-the-line is acknowledged. This isn't an issue with UDP. Hannes: One of the reasons we created the SCTP transport for Diameter was to address the head-of-line blocking issue. But SCTP has not been widely implemented. Alan: For those that are interested, FreeRADIUS now supports RADIUS over TCP, so you can play with it. Bernard: Does the latest revision address Issues 315 and 316? Alan: Yes. Bernard: OK. If there are no open issues, then we could do another WG last call. RADIUS over DTLS Alan: RDTLS has been implemented in Stefan's RADSEC Proxy. I am implementing it as well. This draft was not revised. David Nelson: Isn't this draft expired? What is the status? Alan: It is not expired. Bernard: We issued a call for interest. Only one or two people responded. There are no open issues at the moment. We need more reviews. IEEE 802 Attributes Dan Romascanu: Is this document only about WLAN attributes or wired IEEE 802 attributes as well? Are the attributes usable on multiple technologies? Bernard: A number of the attributes are specific to a technology. For example, there are attributes that relate to IEEE 802.11r specifically. There are also attributes that relate to IEEE 802.1X-REV. Joe Salowey: IEEE 802.1X-REV does apply to wireless, but there are aspects (such as announcements) that were only meant to be implemented on wired networks. Bernard: At one point we had attributes specific to IEEE 802.11s, but the security model changed, so we removed them. David Nelson: What is the status of the document? Bernard Aboba: IEEE 802.1X-REV has completed Sponsor Ballot. We were waiting until the resolution of Sponsor Ballot comments to align the document with IEEE 802.1X-REV. Joe Salowey: IEEE 802.1X-REV is now going into recirculation ballot. So it is a good time to look at it again. Bernard Aboba: The document is referenced in Appendix E of IEEE 802.1X-REV. But it is not a normative dependency. Joe Salowey: Now that IEEE 802.1X-REV has settled down, I will review the document again, to see what changes may be needed. Bernard Aboba: After Joe is done with his review, what are the next steps? Dan Romascanu: For a standards track document, it can either be a WG work item, or an AD sponsored document. I would prefer a WG work item. Bernard: There was a call for interest in November 2007, but it never completed. So the document has been in limbo for almost two years now. David Nelson: Did anyone respond to the call? Bernard Aboba: Some people responded, yes. David Nelson: I was waiting for IEEE 802.1 to send their requirements. Bernard Aboba: IEEE 802.1 provided their review of -08 in July 2008. That is now up on the liaison archive. David Nelson: We can either send the document to the RFC Editor or run a quick WG last call on it, once it is aligned with IEEE 802.1X-REV. IPv6 Attribute Design Considerations Hannes: This document initially did not have much interest, then there was a lot of discussion on the list due to interest from the Broadband Forum. There are a number of ways to address the review from Alan. The document utilizes a tagging scheme similar to, but not exactly the same as RFC 2868. The authors did not want to depend on Extended Attributes since it has not been progressing (and is now expired). Bernard: It seems like many of the attributes that are tagged relate to a router advertisement, correct? Hannes: That is my understanding. Bernard: One of the objections to the current scheme is that it creates multiple new tagged data types. A new attribute is needed for each element of the RA that needs to be expressed. It occurred to me that it might actually be easier to define an opaque blob that carries much of (or the entire) RA. David Nelson: It seems like the lack of progress on Extended Attributes is creating a problem. Design Guidelines says that the RFC 2868 tagging scheme isn't suitable for generic use. But it doesn't make a recommendation. If we don't get Extended Attributes done, then we will be creating a problem. After finishing Design Guidelines, it seems like this needs to be our #2 priority. Bernard: Agreed. To be clear though, this document does not currently depend on Extended Attributes. Question: If Extended Attributes were further along, would this document use it? David Miles: I don't think so. David Nelson: It seems like there are a number of use cases here, and they are not clearly described. Bernard: Previous documents have had very well defined uses cases. RFC 3162 supports address auto- configuration. RFC 4818 supports DHCPv6 Prefix Delegation. This document supports multiple modes, and that is confusing. David Miles: In looking at the attribute list, there are a set of attributes relating to router advertisements that require tagging, but another set of attributes like IPv6-Address and IPv6-DNS-Server-Address that do not. Would it make sense to split the document into two parts, one focusing on DHCPv6, and the other one on router advertisements? Bernard Aboba: Yes, I think this would help. David Nelson: Which attributes are you interested in? David Miles: For the Broadband Forum, IPv6-Address is of the most immediate interest. IPv6-DNS-Server-Address is relevant but isn't as important since in most cases name resolution is being handled over IPv4. Bernard Aboba: If that is what you need, then focusing on that would enable things to go forward much more quickly. Can you put a document together that focuses on that? David Miles: There is already a document that does that. David Nelson: Which one? David Miles: http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00 Bernard Aboba: Yes, that document just handles the attributes you are interested in. However, it confused the WG because it only talked about DHCPv6 and RADIUS, but did not talk about authentication. RADIUS is spoken between a RADIUS client and server. So if the RADIUS client is also a DHCPv6 server, then it makes sense. But if the DHCPv6 server is separate, then it's not clear how it works. Does the NAS pass the RADIUS attributes to the DHCPv6 server, and if so, how? Is there authentication going on between the DHCPv6 server and the RADIUS server? If there are no authentication attributes is this a Call Check, or is it changing the RADIUS protocol in some way? David Miles: I can include material on the Broadband Forum scenarios. If I work with Benoit to create an -01 with that additional material would that help? Bernard Aboba: Yes, it would help a great deal. Summary/Wrapup Bernard: At the last virtual interim, the feedback on DimDim was not very positive. So we tried LiveMeeting this time. How did it work for people? Dan Romascanu: The conference bridge was fine. Alan DeKok: I could not use the web conferencing software, it was only available on Windows. Dan Romascanu: It required me to install additional software (Outlook addin). That is a big deal. Bernard Aboba: DimDim also required a software install. Though it supported more platforms. David Nelson: Having a teleconference bridge, Jabber and slides is fine. David Miles: As long as the slides don't get too long or there are too many people in the meeting. Otherwise it's easy to lose your place. Bernard Aboba: They had a session on WebEx at IETF 75, in the Working Group Chairs meeting. I asked the Secretariat if we could get access, but didn't get a response. So it was either DimDim or LiveMeeting. Dan Romascanu: I will inquire about the availability of WebEx. Bernard: Let's talk about the plans for IETF 76. The RADEXT WG is not currently scheduled to meet at IETF 76. We have just completed the Virtual Interim, and IETF 76 is in just a few weeks. Dan Romascanu: Who is attending? David Nelson: I will not attend. Bernard: No Alan DeKok: No Hannes: Yes Dan Romascanu: There are disadvantages to not holding a meeting at IETF 76. You will miss the opportunity to interact with the community, particularly participants from Asia. It would be good to have a representative at IETF 76. Hannes is very busy, but perhaps you can find someone to represent RADEXT. Bernard: If there is WebEx available, we could participate remotely. Dan Romascanu: I will look into supporting WebEx at the OPS Area Meeting. There are cost concerns. ------=_NextPart_000_020F_01CA4CCE.89F577E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t see a list of = attendees.

 

From:= owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On = Behalf Of Bernard Aboba
Sent: Wednesday, October 14, 2009 2:35 AM
To: radiusext@ops.ietf.org
Subject: Draft RADEXT Virtual Interim = Minutes

 


Here is a draft of the RADEXT WG Virtual Interim Minutes.

Please take a look at these minutes and add/edit/correct as necessary. =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Minutes of the RADEXT WG Virtual Interim
October 13, 2009

Design Guidelines

Alan:  -09 has been submitted.  This includes a number of clarifications
with respect to tags, VSA formats, simple versus complex types.  =
There are no MUSTs or MUST NOTs in the document.  Guidelines try = to
encourage good practice, but should not be followed slavishly.

Dan: Jari has cleared his discuss.  So the document could be sent = to the
RFC Editor for publication immediately. 

Bernard:  Not clear that the document is ready.
There are still two open issues from IETF last call: Issues 313 and 314. =

Issue 313 concerns the "security exemption".  Does this = apply to any attribute
relating to security or authentication?  There was confusion on = this point
during the review of the PKMv1 document.

For user authentication or RADIUS security attributes there is = computation
involved:  the client has to compute something and the server has = to verify,
or vice-versa.  If an attribute relates to security (e.g. sending a certificate)
but there is no computation, does the exemption still apply?
In that case, it might have been possible to use the String
type, but a complex attribute would require new code on both the client = and server.

Issue 314 was filed by Hannes.  It was to be followed by specific = text to address the
concerns, but this wasn't provided.

Hannes:  The state of the art has advanced.  In some designs = addition of code is
no longer a big issue, scripts can be plugged in.  Also, parsers = have improved,
and could enable complex attributes to be supported automatically.
So are we locking ourselves into the past?

David Nelson:  Many RADIUS server implementations utilize a data dictionary.  This
allows administrators to add the definition of a new attribute without = having to
upgrade the server.  If an attribute doesn't have to require a = server upgrade, that
is probably a good thing. 

Bernard:  There are a lot of legacy RADIUS servers out there that implement
the data dictionary  model described in RFC 2865.  For those = implementations,
the data dictionary provides benefits.  It can save administrators = time
and money, allowing them to support a new attribute immediately without = waiting for
a RADIUS server upgrade.

David Nelson:  It is also possible to use opaque attributes, where = the data
is not parsed by RADIUS but by some other component.  Those = attributes
are sent to and from a plugin. 

Dan Romascanu:  There is also the question of whether normative = language is being used
in the same way as described in RFC 2119. 

Do we need to update the draft?

Bernard Aboba:  How about an RFC Editor note?
Dan:  That would be easier.

David Nelson:  I think it would be best to get the document = published and then see how
well it works in the real world.

Bernard:  So far, we've used it in reviewing two documents, the = PKMv1 document, and the
IPv6 access document.  In both cases, there was confusion about how = the guidelines applied
that required clarifications in the text.  So the "real = world" experience is not so good.
That's why the document has taken so long to finish.
 
Bernard: Alan -- can you take the action item to work with Dan on = addressing the RFC 2119 issue
as well as proposing an RFC Editor note to address issue 313?

Status Server

Alan:  This draft was revised.  An applicability subsection = was added.  There were some
terminology changes. 

David Nelson:  Does this document just describe what has been = deployed, or does it also
describe how Status-Server is used in RADSEC?

Alan:  It is focused on what has been implemented.  The RADSEC document uses Status-Server
as an RFC 3539 Watchdog, but that is covered in the RADSEC document. =

Bernard: Status-Server was originally implemented by Ascend in their concentrators.

Alan:  It was subsequently implemented in RADIATOR and = FreeRADIUS. 

Bernard:  It would be good if we could get some additional = reviewers to look at whether
the document accurately describes their implementations.  This = isn't a standards-track
document; its job is just to describe what has been = implemented.   Do we have any
volunteers:

David Nelson:  I will take a look at it.

RADIUS over TCP

Alan:  We added text to the applicability section.  We're now = using the term "RADIUS over TLS" instead
of a vendor's product name (RADSEC). We also added text on the = head-of-line blocking issue. 
Bernard:  As I recall, Magnus (Transport AD) raised this issue = initially. What can be done to address this
issue other than opening multiple TCP connections?
Alan:  Nothing.
Dan:  What is the issue specifically?
Alan:  If a packet is lost, then all traffic that was intended to = travel on the TCP connection has to
wait until the data at the head-of-the-line is acknowledged.  This = isn't an issue with UDP.
Hannes:  One of the reasons we created the SCTP transport for = Diameter was to address the head-of-line
blocking issue.  But SCTP has not been widely implemented.
Alan: For those that are interested, FreeRADIUS now supports RADIUS over = TCP, so you can play with it.
Bernard: Does the latest revision address Issues 315 and 316?
Alan:  Yes.
Bernard: OK.  If there are no open issues, then we could do another = WG last call.

RADIUS over DTLS

Alan:  RDTLS has been implemented in Stefan's RADSEC Proxy.  I = am implementing it as well.
This draft was not revised.
David Nelson: Isn't this draft expired?  What is the status?
Alan:  It is not expired. 
Bernard:  We issued a call for interest.  Only one or two = people responded.  There are no
open issues at the moment.  We need more reviews.

IEEE 802 Attributes

Dan Romascanu:  Is this document only about WLAN attributes or = wired IEEE 802 attributes as well?  Are
the attributes usable on multiple technologies?
Bernard: A number of the attributes are specific to a technology.  = For example, there are attributes
that relate to IEEE 802.11r specifically.  There are also = attributes that relate to IEEE 802.1X-REV.
Joe Salowey:  IEEE 802.1X-REV does apply to wireless, but there are aspects (such as announcements)
that were only meant to be implemented on wired networks. 
Bernard:  At one point we had attributes specific to IEEE 802.11s, = but the security model changed, so
we removed them. 
David Nelson:  What is the status of the document?
Bernard Aboba:  IEEE 802.1X-REV has completed Sponsor Ballot.  = We were waiting until the resolution of
Sponsor Ballot comments to align the document with IEEE 802.1X-REV.
Joe Salowey: IEEE 802.1X-REV is now going into recirculation = ballot.  So it is a good time to look at
it again.
Bernard Aboba:  The document is referenced in Appendix E of IEEE 802.1X-REV.  But it is not a normative
dependency.
Joe Salowey:  Now that IEEE 802.1X-REV has settled down, I will = review the document again, to see what
changes may be needed.
Bernard Aboba:  After Joe is done with his review, what are the = next steps? 
Dan Romascanu:  For a standards track document, it can either be a = WG work item, or an AD sponsored
document.  I would prefer a WG work item.
Bernard:  There was a call for interest in November 2007, but it = never completed.  So the document has
been in limbo for almost two years now.
David Nelson: Did anyone respond to the call?
Bernard Aboba:  Some people responded, yes.
David Nelson:  I was waiting for IEEE 802.1 to send their = requirements.
Bernard Aboba:  IEEE 802.1 provided their review of -08 in July 2008.  That is now up on the liaison archive.
David Nelson: We can either send the document to the RFC Editor or run a = quick WG last call on it, once
it is aligned with IEEE 802.1X-REV.

IPv6 Attribute Design Considerations

Hannes:  This document initially did not have much interest, then = there was a lot of discussion on the
list due to interest from the Broadband Forum.  There are a number = of ways to address the review from
Alan.  The document utilizes a tagging scheme similar to, but not = exactly the same as RFC 2868.  The
authors did not want to depend on Extended Attributes since it has not = been progressing (and is now
expired). 

Bernard:  It seems like many of the attributes that are tagged = relate to a router advertisement, correct?
Hannes:  That is my understanding.
Bernard:  One of the objections to the current scheme is that it = creates multiple new tagged data types.
A new attribute is needed for each element of the RA that needs to be expressed.  It occurred to me that
it might actually be easier to define an opaque blob that carries much = of (or the entire) RA. 

David Nelson: It seems like the lack of progress on Extended Attributes = is creating a problem.  Design
Guidelines says that the RFC 2868 tagging scheme isn't suitable for = generic use.  But it doesn't make
a recommendation.  If we don't get Extended Attributes done, then = we will be creating a problem.
After finishing Design Guidelines, it seems like this needs to be our #2 priority.

Bernard:  Agreed.  To be clear though, this document does not currently depend on Extended Attributes.
Question:  If Extended Attributes were further along, would this = document use it?

David Miles:  I don't think so. 

David Nelson:  It seems like there are a number of use cases here, = and they are not clearly described.
Bernard:  Previous documents have had very well defined uses = cases.  RFC 3162 supports address auto-
configuration.  RFC 4818 supports DHCPv6 Prefix Delegation.  = This document supports multiple modes,
and that is confusing.

David Miles:  In looking at the attribute list, there are a set of attributes relating to router advertisements
that require tagging, but another set of attributes like IPv6-Address = and IPv6-DNS-Server-Address that do not.
Would it make sense to split the document into two parts, one focusing = on DHCPv6, and
the other one on router advertisements?

Bernard Aboba: Yes, I think this would help.

David Nelson:  Which attributes are you interested in?

David Miles: For the Broadband Forum, IPv6-Address is of the most = immediate interest.  IPv6-DNS-Server-Address
is relevant but isn't as important since in most cases name resolution = is being handled over IPv4.

Bernard Aboba:  If that is what you need, then focusing on that = would enable things to go forward much more
quickly.  Can you put a document together that focuses on that? =

David Miles:  There is already a document that does that.

David Nelson:  Which one?

David Miles:  http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00

Bernard Aboba:  Yes, that document just handles the attributes you = are interested in.  However, it confused
the WG because it only talked about DHCPv6 and RADIUS, but did not talk = about authentication.  RADIUS is
spoken between a RADIUS client and server.  So if the RADIUS client = is also a DHCPv6 server, then it makes
sense.  But if the DHCPv6 server is separate, then it's not clear = how it works.  Does the NAS pass the
RADIUS attributes to the DHCPv6 server, and if so, how?  Is there authentication going on between the
DHCPv6 server and the RADIUS server?  If there are no = authentication attributes is this a Call Check,
or is it changing the RADIUS protocol in some way? 

David Miles:  I can include material on the Broadband Forum scenarios.  If I work with Benoit to create
an -01 with that additional material would that help?

Bernard Aboba:  Yes, it would help a great deal.

Summary/Wrapup

Bernard:  At the last virtual interim, the feedback on DimDim was = not very positive.  So we tried LiveMeeting this time.  How did it work = for people?
Dan Romascanu: The conference bridge was fine.
Alan DeKok:  I could not use the web conferencing software, it was = only available on Windows.
Dan Romascanu:  It required me to install additional software = (Outlook addin).  That is a big deal.
Bernard Aboba:  DimDim also required a software install.  = Though it supported more platforms.
David Nelson:  Having a teleconference bridge, Jabber and slides is = fine.
David Miles:  As long as the slides don't get too long  or = there are too many people in the meeting.  Otherwise it's easy to lose your = place.
Bernard Aboba:  They had a session on WebEx at IETF 75, in the = Working Group Chairs meeting.  I asked the Secretariat if we could get = access, but didn't get a response.  So it was
either DimDim or LiveMeeting.
Dan Romascanu:  I will inquire about the availability of WebEx. =

Bernard: Let's talk about the plans for IETF 76. The RADEXT WG is not = currently scheduled to meet at IETF 76.  We have just completed the Virtual = Interim, and
IETF 76 is in just a few weeks.
Dan Romascanu:  Who is attending?
David Nelson:  I will not attend.
Bernard: No
Alan DeKok: No
Hannes: Yes
Dan Romascanu:  There are disadvantages to not holding a meeting at = IETF 76.  You will miss the opportunity to interact with the community, particularly participants from Asia. 
It would be good to have a representative at IETF 76.  Hannes is = very busy, but perhaps you can find someone to represent RADEXT.
Bernard:  If there is WebEx available, we could participate = remotely.
Dan Romascanu:  I will look into supporting WebEx at the OPS Area Meeting.  There are cost concerns.

 

------=_NextPart_000_020F_01CA4CCE.89F577E0-- -- to 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, 13 Oct 2009 23:19:32 +0000 Message-ID: From: "Bernard Aboba" To: "'David B. Nelson'" , Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Tue, 13 Oct 2009 16:18:38 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01CA4C20.D2668900" Thread-Index: AcpMQagUopb6jkuKSKS0ZBK48RQ8tgAGbDVg Content-Language: en-us ------=_NextPart_000_0049_01CA4C20.D2668900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David Nelson said: "In clarification, I will review the document for clarity and coherency, but I'm not an expert on what exactly was implemented in terms of the Status-Server feature, so I won't be able to comment on the accuracy with which the draft reflects deployments." Right. I will clarify the minutes to that effect. Ideally we would like some implementers as reviewers to address the accuracy issue. ------=_NextPart_000_0049_01CA4C20.D2668900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David Nelson said:

 

“In = clarification, I will review the document for clarity and coherency, but I'm not an expert on = what exactly was implemented in terms of the Status-Server feature, so I = won't be able to comment on the accuracy with which the draft reflects = deployments.”

 

Right.  I will clarify the minutes to that = effect.  Ideally we would like some implementers as reviewers to address the accuracy = issue. 

 

 

------=_NextPart_000_0049_01CA4C20.D2668900-- -- to 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, 13 Oct 2009 19:57:58 +0000 Message-Id: <88AFD982-0104-4612-A955-EA20FB70CE7A@elbrysnetworks.com> From: "David B. Nelson" To: radiusext@ops.ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-4-131250442 Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Draft RADEXT Virtual Interim Minutes Date: Tue, 13 Oct 2009 15:57:20 -0400 --Apple-Mail-4-131250442 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 13, 2009, at 3:34 PM, Bernard Aboba wrote: > > Here is a draft of the RADEXT WG Virtual Interim Minutes. > > Please take a look at these minutes and add/edit/correct as necessary. > > > > Status Server > > Alan: This draft was revised. An applicability subsection was > added. There were some > terminology changes. > > David Nelson: Does this document just describe what has been > deployed, or does it also > describe how Status-Server is used in RADSEC? > > Alan: It is focused on what has been implemented. The RADSEC > document uses Status-Server > as an RFC 3539 Watchdog, but that is covered in the RADSEC document. > > Bernard: Status-Server was originally implemented by Ascend in their > concentrators. > > Alan: It was subsequently implemented in RADIATOR and FreeRADIUS. > > Bernard: It would be good if we could get some additional reviewers > to look at whether > the document accurately describes their implementations. This isn't > a standards-track > document; its job is just to describe what has been implemented. > Do we have any > volunteers: > > David Nelson: I will take a look at it. In clarification, I will review the document for clarity and coherency, but I'm not an expert on what exactly was implemented in terms of the Status-Server feature, so I won't be able to comment on the accuracy with which the draft reflects deployments. --Apple-Mail-4-131250442 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 13, 2009, = at 3:34 PM, Bernard Aboba wrote:


Here is a draft of = the RADEXT WG Virtual Interim Minutes. 

Please take a look = at these minutes and add/edit/correct as necessary. 

<snip>

S= tatus Server

Alan:  This draft was revised.  An = applicability subsection was added.  There were some
terminology = changes.  

David Nelson:  = Does this document just describe what has been deployed, or does it = also
describe how Status-Server is used in RADSEC?

Alan:  = It is focused on what has been implemented.  The RADSEC document = uses Status-Server
as an RFC 3539 Watchdog, but that is covered in = the RADSEC document. 

Bernard: = Status-Server was originally implemented by Ascend in their = concentrators. 

Alan:  It was = subsequently implemented in RADIATOR and FreeRADIUS.  

Bernard:  It = would be good if we could get some additional reviewers to look at = whether
the document accurately describes their = implementations.  This isn't a standards-track
document; its job = is just to describe what has been implemented.   Do we have = any
volunteers:

David Nelson:  I will take a look at = it. 


In clarification, I will review the = document for clarity and coherency, but I'm not an expert on what = exactly was implemented in terms of the Status-Server feature, so I = won't be able to comment on the accuracy with which the draft reflects = deployments.


= --Apple-Mail-4-131250442-- -- to 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, 13 Oct 2009 19:36:02 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_538042d2-1b43-4715-b19f-edf438b88c70_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Draft RADEXT Virtual Interim Minutes Date: Tue, 13 Oct 2009 12:34:57 -0700 MIME-Version: 1.0 --_538042d2-1b43-4715-b19f-edf438b88c70_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is a draft of the RADEXT WG Virtual Interim Minutes.=20 Please take a look at these minutes and add/edit/correct as necessary.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Minutes of the RADEXT WG Virtual Interim October 13=2C 2009 Design Guidelines Alan: -09 has been submitted. This includes a number of clarifications with respect to tags=2C VSA formats=2C simple versus complex types. =20 There are no MUSTs or MUST NOTs in the document. Guidelines try to encourage good practice=2C but should not be followed slavishly.=20 Dan: Jari has cleared his discuss. So the document could be sent to the RFC Editor for publication immediately. =20 Bernard: Not clear that the document is ready.=20 There are still two open issues from IETF last call: Issues 313 and 314.=20 Issue 313 concerns the "security exemption". Does this apply to any attrib= ute relating to security or authentication? There was confusion on this point during the review of the PKMv1 document.=20 For user authentication or RADIUS security attributes there is computation= =20 involved: the client has to compute something and the server has to verify= =2C or vice-versa. If an attribute relates to security (e.g. sending a certifi= cate)=20 but there is no computation=2C does the exemption still apply? In that case=2C it might have been possible to use the String type=2C but a complex attribute would require new code on both the client a= nd server.=20 Issue 314 was filed by Hannes. It was to be followed by specific text to a= ddress the concerns=2C but this wasn't provided. Hannes: The state of the art has advanced. In some designs addition of co= de is no longer a big issue=2C scripts can be plugged in. Also=2C parsers have i= mproved=2C and could enable complex attributes to be supported automatically.=20 So are we locking ourselves into the past?=20 David Nelson: Many RADIUS server implementations utilize a data dictionary= . This allows administrators to add the definition of a new attribute without havi= ng to upgrade the server. If an attribute doesn't have to require a server upgra= de=2C that is probably a good thing. =20 Bernard: There are a lot of legacy RADIUS servers out there that implement the data dictionary model described in RFC 2865. For those implementation= s=2C the data dictionary provides benefits. It can save administrators time and money=2C allowing them to support a new attribute immediately without w= aiting for a RADIUS server upgrade.=20 David Nelson: It is also possible to use opaque attributes=2C where the da= ta is not parsed by RADIUS but by some other component. Those attributes are sent to and from a plugin. =20 Dan Romascanu: There is also the question of whether normative language is= being used in the same way as described in RFC 2119. =20 Do we need to update the draft?=20 Bernard Aboba: How about an RFC Editor note?=20 Dan: That would be easier.=20 David Nelson: I think it would be best to get the document published and t= hen see how well it works in the real world. Bernard: So far=2C we've used it in reviewing two documents=2C the PKMv1 d= ocument=2C and the IPv6 access document. In both cases=2C there was confusion about how the g= uidelines applied that required clarifications in the text. So the "real world" experience i= s not so good.=20 That's why the document has taken so long to finish.=20 =20 Bernard: Alan -- can you take the action item to work with Dan on addressin= g the RFC 2119 issue as well as proposing an RFC Editor note to address issue 313?=20 Status Server Alan: This draft was revised. An applicability subsection was added. The= re were some terminology changes. =20 David Nelson: Does this document just describe what has been deployed=2C o= r does it also describe how Status-Server is used in RADSEC? Alan: It is focused on what has been implemented. The RADSEC document use= s Status-Server as an RFC 3539 Watchdog=2C but that is covered in the RADSEC document.=20 Bernard: Status-Server was originally implemented by Ascend in their concen= trators.=20 Alan: It was subsequently implemented in RADIATOR and FreeRADIUS. =20 Bernard: It would be good if we could get some additional reviewers to loo= k at whether the document accurately describes their implementations. This isn't a stan= dards-track document=3B its job is just to describe what has been implemented. Do we = have any volunteers: David Nelson: I will take a look at it.=20 RADIUS over TCP Alan: We added text to the applicability section. We're now using the ter= m "RADIUS over TLS" instead of a vendor's product name (RADSEC). We also added text on the head-of-line= blocking issue. =20 Bernard: As I recall=2C Magnus (Transport AD) raised this issue initially.= What can be done to address this=20 issue other than opening multiple TCP connections? Alan: Nothing. Dan: What is the issue specifically? Alan: If a packet is lost=2C then all traffic that was intended to travel = on the TCP connection has to wait until the data at the head-of-the-line is acknowledged. This isn't an= issue with UDP.=20 Hannes: One of the reasons we created the SCTP transport for Diameter was = to address the head-of-line blocking issue. But SCTP has not been widely implemented. Alan: For those that are interested=2C FreeRADIUS now supports RADIUS over = TCP=2C so you can play with it. Bernard: Does the latest revision address Issues 315 and 316? Alan: Yes. Bernard: OK. If there are no open issues=2C then we could do another WG la= st call. RADIUS over DTLS Alan: RDTLS has been implemented in Stefan's RADSEC Proxy. I am implement= ing it as well.=20 This draft was not revised.=20 David Nelson: Isn't this draft expired? What is the status? Alan: It is not expired. =20 Bernard: We issued a call for interest. Only one or two people responded.= There are no open issues at the moment. We need more reviews. IEEE 802 Attributes Dan Romascanu: Is this document only about WLAN attributes or wired IEEE 8= 02 attributes as well? Are the attributes usable on multiple technologies?=20 Bernard: A number of the attributes are specific to a technology. For exam= ple=2C there are attributes that relate to IEEE 802.11r specifically. There are also attributes that r= elate to IEEE 802.1X-REV.=20 Joe Salowey: IEEE 802.1X-REV does apply to wireless=2C but there are aspec= ts (such as announcements) that were only meant to be implemented on wired networks. =20 Bernard: At one point we had attributes specific to IEEE 802.11s=2C but th= e security model changed=2C so we removed them. =20 David Nelson: What is the status of the document? Bernard Aboba: IEEE 802.1X-REV has completed Sponsor Ballot. We were wait= ing until the resolution of Sponsor Ballot comments to align the document with IEEE 802.1X-REV.=20 Joe Salowey: IEEE 802.1X-REV is now going into recirculation ballot. So it= is a good time to look at it again.=20 Bernard Aboba: The document is referenced in Appendix E of IEEE 802.1X-REV= . But it is not a normative dependency.=20 Joe Salowey: Now that IEEE 802.1X-REV has settled down=2C I will review th= e document again=2C to see what changes may be needed.=20 Bernard Aboba: After Joe is done with his review=2C what are the next step= s? =20 Dan Romascanu: For a standards track document=2C it can either be a WG wor= k item=2C or an AD sponsored document. I would prefer a WG work item. Bernard: There was a call for interest in November 2007=2C but it never co= mpleted. So the document has been in limbo for almost two years now.=20 David Nelson: Did anyone respond to the call? Bernard Aboba: Some people responded=2C yes.=20 David Nelson: I was waiting for IEEE 802.1 to send their requirements.=20 Bernard Aboba: IEEE 802.1 provided their review of -08 in July 2008. That= is now up on the liaison archive. David Nelson: We can either send the document to the RFC Editor or run a qu= ick WG last call on it=2C once it is aligned with IEEE 802.1X-REV.=20 IPv6 Attribute Design Considerations Hannes: This document initially did not have much interest=2C then there w= as a lot of discussion on the list due to interest from the Broadband Forum. There are a number of ways = to address the review from Alan. The document utilizes a tagging scheme similar to=2C but not exactly= the same as RFC 2868. The authors did not want to depend on Extended Attributes since it has not been= progressing (and is now expired). =20 Bernard: It seems like many of the attributes that are tagged relate to a = router advertisement=2C correct? Hannes: That is my understanding.=20 Bernard: One of the objections to the current scheme is that it creates mu= ltiple new tagged data types.=20 A new attribute is needed for each element of the RA that needs to be expre= ssed. It occurred to me that it might actually be easier to define an opaque blob that carries much of (= or the entire) RA. =20 David Nelson: It seems like the lack of progress on Extended Attributes is = creating a problem. Design Guidelines says that the RFC 2868 tagging scheme isn't suitable for generic= use. But it doesn't make a recommendation. If we don't get Extended Attributes done=2C then we will= be creating a problem.=20 After finishing Design Guidelines=2C it seems like this needs to be our #2 = priority.=20 Bernard: Agreed. To be clear though=2C this document does not currently d= epend on Extended Attributes.=20 Question: If Extended Attributes were further along=2C would this document= use it?=20 David Miles: I don't think so. =20 David Nelson: It seems like there are a number of use cases here=2C and th= ey are not clearly described.=20 Bernard: Previous documents have had very well defined uses cases. RFC 31= 62 supports address auto- configuration. RFC 4818 supports DHCPv6 Prefix Delegation. This document = supports multiple modes=2C and that is confusing.=20 David Miles: In looking at the attribute list=2C there are a set of attrib= utes relating to router advertisements that require tagging=2C but another set of attributes like IPv6-Address and= IPv6-DNS-Server-Address that do not.=20 Would it make sense to split the document into two parts=2C one focusing on= DHCPv6=2C and the other one on router advertisements?=20 Bernard Aboba: Yes=2C I think this would help. David Nelson: Which attributes are you interested in? David Miles: For the Broadband Forum=2C IPv6-Address is of the most immedia= te interest. IPv6-DNS-Server-Address=20 is relevant but isn't as important since in most cases name resolution is b= eing handled over IPv4.=20 Bernard Aboba: If that is what you need=2C then focusing on that would ena= ble things to go forward much more quickly. Can you put a document together that focuses on that?=20 David Miles: There is already a document that does that.=20 David Nelson: Which one?=20 David Miles: http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-0= 0 Bernard Aboba: Yes=2C that document just handles the attributes you are in= terested in. However=2C it confused the WG because it only talked about DHCPv6 and RADIUS=2C but did not talk a= bout authentication. RADIUS is spoken between a RADIUS client and server. So if the RADIUS client is also= a DHCPv6 server=2C then it makes sense. But if the DHCPv6 server is separate=2C then it's not clear how it = works. Does the NAS pass the RADIUS attributes to the DHCPv6 server=2C and if so=2C how? Is there authe= ntication going on between the DHCPv6 server and the RADIUS server? If there are no authentication attrib= utes is this a Call Check=2C or is it changing the RADIUS protocol in some way? =20 David Miles: I can include material on the Broadband Forum scenarios. If = I work with Benoit to create an -01 with that additional material would that help? Bernard Aboba: Yes=2C it would help a great deal.=20 Summary/Wrapup Bernard: At the last virtual interim=2C the feedback on DimDim was not ver= y positive. So we tried LiveMeeting this time. How did it work for people= ?=20 Dan Romascanu: The conference bridge was fine.=20 Alan DeKok: I could not use the web conferencing software=2C it was only a= vailable on Windows.=20 Dan Romascanu: It required me to install additional software (Outlook addi= n). That is a big deal.=20 Bernard Aboba: DimDim also required a software install. Though it support= ed more platforms.=20 David Nelson: Having a teleconference bridge=2C Jabber and slides is fine.= =20 David Miles: As long as the slides don't get too long or there are too ma= ny people in the meeting. Otherwise it's easy to lose your place.=20 Bernard Aboba: They had a session on WebEx at IETF 75=2C in the Working Gr= oup Chairs meeting. I asked the Secretariat if we could get access=2C but = didn't get a response. So it was either DimDim or LiveMeeting.=20 Dan Romascanu: I will inquire about the availability of WebEx.=20 Bernard: Let's talk about the plans for IETF 76. The RADEXT WG is not curre= ntly scheduled to meet at IETF 76. We have just completed the Virtual Inte= rim=2C and=20 IETF 76 is in just a few weeks.=20 Dan Romascanu: Who is attending? David Nelson: I will not attend.=20 Bernard: No Alan DeKok: No Hannes: Yes Dan Romascanu: There are disadvantages to not holding a meeting at IETF 76= . You will miss the opportunity to interact with the community=2C particul= arly participants from Asia. =20 It would be good to have a representative at IETF 76. Hannes is very busy= =2C but perhaps you can find someone to represent RADEXT.=20 Bernard: If there is WebEx available=2C we could participate remotely.=20 Dan Romascanu: I will look into supporting WebEx at the OPS Area Meeting. = There are cost concerns.=20 = --_538042d2-1b43-4715-b19f-edf438b88c70_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Here is a draft of the RAD= EXT WG Virtual Interim Minutes.

Please take a look at these minutes= and add/edit/correct as necessary.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Minutes of the RADEXT WG Virtual In= terim
October 13=2C 2009

Design Guidelines

Alan: =3B -= 09 has been submitted. =3B This includes a number of clarifications
= with respect to tags=2C VSA formats=2C simple versus complex types. =3B=
There are no MUSTs or MUST NOTs in the document. =3B Guidelines tr= y to
encourage good practice=2C but should not be followed slavishly.
Dan: Jari has cleared his discuss. =3B So the document could be s= ent to the
RFC Editor for publication immediately. =3B

Berna= rd: =3B Not clear that the document is ready.
There are still two o= pen issues from IETF last call: Issues 313 and 314.

Issue 313 conce= rns the "security exemption". =3B Does this apply to any attribute
r= elating to security or authentication? =3B There was confusion on this = point
during the review of the PKMv1 document.

For user authenti= cation or RADIUS security attributes there is computation
involved:&nbs= p=3B the client has to compute something and the server has to verify=2Cor vice-versa. =3B If an attribute relates to security (e.g. sending a= certificate)
but there is no computation=2C does the exemption still a= pply?
In that case=2C it might have been possible to use the String
t= ype=2C but a complex attribute would require new code on both the client an= d server.

Issue 314 was filed by Hannes. =3B It was to be follo= wed by specific text to address the
concerns=2C but this wasn't provided= .

Hannes: =3B The state of the art has advanced. =3B In some= designs addition of code is
no longer a big issue=2C scripts can be plu= gged in. =3B Also=2C parsers have improved=2C
and could enable compl= ex attributes to be supported automatically.
So are we locking ourselve= s into the past?

David Nelson: =3B Many RADIUS server implement= ations utilize a data dictionary. =3B This
allows administrators to = add the definition of a new attribute without having to
upgrade the serv= er. =3B If an attribute doesn't have to require a server upgrade=2C tha= t
is probably a good thing. =3B

Bernard: =3B There are a= lot of legacy RADIUS servers out there that implement
the data dictiona= ry =3B model described in RFC 2865. =3B For those implementations= =2C
the data dictionary provides benefits. =3B It can save administr= ators time
and money=2C allowing them to support a new attribute immedia= tely without waiting for
a RADIUS server upgrade.

David Nelson:&= nbsp=3B It is also possible to use opaque attributes=2C where the data
i= s not parsed by RADIUS but by some other component. =3B Those attribute= s
are sent to and from a plugin. =3B

Dan Romascanu: =3B = There is also the question of whether normative language is being used
i= n the same way as described in RFC 2119. =3B

Do we need to upda= te the draft?

Bernard Aboba: =3B How about an RFC Editor note? =
Dan: =3B That would be easier.

David Nelson: =3B I thin= k it would be best to get the document published and then see how
well i= t works in the real world.

Bernard: =3B So far=2C we've used it = in reviewing two documents=2C the PKMv1 document=2C and the
IPv6 access = document. =3B In both cases=2C there was confusion about how the guidel= ines applied
that required clarifications in the text. =3B So the "r= eal world" experience is not so good.
That's why the document has taken= so long to finish.
 =3B
Bernard: Alan -- can you take the actio= n item to work with Dan on addressing the RFC 2119 issue
as well as prop= osing an RFC Editor note to address issue 313?

Status Server
Alan: =3B This draft was revised. =3B An applicability subsection = was added. =3B There were some
terminology changes. =3B

= David Nelson: =3B Does this document just describe what has been deploy= ed=2C or does it also
describe how Status-Server is used in RADSEC?
<= br>Alan: =3B It is focused on what has been implemented. =3B The RA= DSEC document uses Status-Server
as an RFC 3539 Watchdog=2C but that is = covered in the RADSEC document.

Bernard: Status-Server was original= ly implemented by Ascend in their concentrators.

Alan: =3B It w= as subsequently implemented in RADIATOR and FreeRADIUS. =3B

Ber= nard: =3B It would be good if we could get some additional reviewers to= look at whether
the document accurately describes their implementations= . =3B This isn't a standards-track
document=3B its job is just to de= scribe what has been implemented. =3B =3B Do we have any
volunte= ers:

David Nelson: =3B I will take a look at it.

RADIUS = over TCP

Alan: =3B We added text to the applicability section.&n= bsp=3B We're now using the term "RADIUS over TLS" instead
of a vendor's = product name (RADSEC). We also added text on the head-of-line blocking issu= e. =3B
Bernard: =3B As I recall=2C Magnus (Transport AD) raised= this issue initially. What can be done to address this
issue other tha= n opening multiple TCP connections?
Alan: =3B Nothing.
Dan: = =3B What is the issue specifically?
Alan: =3B If a packet is lost=2C= then all traffic that was intended to travel on the TCP connection has to<= br>wait until the data at the head-of-the-line is acknowledged. =3B Thi= s isn't an issue with UDP.
Hannes: =3B One of the reasons we create= d the SCTP transport for Diameter was to address the head-of-line
blocki= ng issue. =3B But SCTP has not been widely implemented.
Alan: For th= ose that are interested=2C FreeRADIUS now supports RADIUS over TCP=2C so yo= u can play with it.
Bernard: Does the latest revision address Issues 315= and 316?
Alan: =3B Yes.
Bernard: OK. =3B If there are no ope= n issues=2C then we could do another WG last call.

RADIUS over DTLS<= br>
Alan: =3B RDTLS has been implemented in Stefan's RADSEC Proxy.&n= bsp=3B I am implementing it as well.
This draft was not revised.
Da= vid Nelson: Isn't this draft expired? =3B What is the status?
Alan:&= nbsp=3B It is not expired. =3B
Bernard: =3B We issued a call fo= r interest. =3B Only one or two people responded. =3B There are no<= br>open issues at the moment. =3B We need more reviews.

IEEE 802= Attributes

Dan Romascanu: =3B Is this document only about WLAN = attributes or wired IEEE 802 attributes as well? =3B Are
the attribu= tes usable on multiple technologies?
Bernard: A number of the attribute= s are specific to a technology. =3B For example=2C there are attributes=
that relate to IEEE 802.11r specifically. =3B There are also attrib= utes that relate to IEEE 802.1X-REV.
Joe Salowey: =3B IEEE 802.1X-R= EV does apply to wireless=2C but there are aspects (such as announcements)<= br>that were only meant to be implemented on wired networks. =3B
Be= rnard: =3B At one point we had attributes specific to IEEE 802.11s=2C b= ut the security model changed=2C so
we removed them. =3B
David N= elson: =3B What is the status of the document?
Bernard Aboba: = =3B IEEE 802.1X-REV has completed Sponsor Ballot. =3B We were waiting u= ntil the resolution of
Sponsor Ballot comments to align the document wit= h IEEE 802.1X-REV.
Joe Salowey: IEEE 802.1X-REV is now going into recir= culation ballot. =3B So it is a good time to look at
it again.
B= ernard Aboba: =3B The document is referenced in Appendix E of IEEE 802.= 1X-REV. =3B But it is not a normative
dependency.
Joe Salowey:&n= bsp=3B Now that IEEE 802.1X-REV has settled down=2C I will review the docum= ent again=2C to see what
changes may be needed.
Bernard Aboba: = =3B After Joe is done with his review=2C what are the next steps? =3B <= br>Dan Romascanu: =3B For a standards track document=2C it can either b= e a WG work item=2C or an AD sponsored
document. =3B I would prefer = a WG work item.
Bernard: =3B There was a call for interest in Novemb= er 2007=2C but it never completed. =3B So the document has
been in l= imbo for almost two years now.
David Nelson: Did anyone respond to the = call?
Bernard Aboba: =3B Some people responded=2C yes.
David Nel= son: =3B I was waiting for IEEE 802.1 to send their requirements.
B= ernard Aboba: =3B IEEE 802.1 provided their review of -08 in July 2008.=  =3B That is now up on the liaison archive.
David Nelson: We can eit= her send the document to the RFC Editor or run a quick WG last call on it= =2C once
it is aligned with IEEE 802.1X-REV.

IPv6 Attribute Desi= gn Considerations

Hannes: =3B This document initially did not ha= ve much interest=2C then there was a lot of discussion on the
list due t= o interest from the Broadband Forum. =3B There are a number of ways to = address the review from
Alan. =3B The document utilizes a tagging sc= heme similar to=2C but not exactly the same as RFC 2868. =3B The
aut= hors did not want to depend on Extended Attributes since it has not been pr= ogressing (and is now
expired). =3B

Bernard: =3B It seem= s like many of the attributes that are tagged relate to a router advertisem= ent=2C correct?
Hannes: =3B That is my understanding.
Bernard:&n= bsp=3B One of the objections to the current scheme is that it creates multi= ple new tagged data types.
A new attribute is needed for each element o= f the RA that needs to be expressed. =3B It occurred to me that
it m= ight actually be easier to define an opaque blob that carries much of (or t= he entire) RA. =3B

David Nelson: It seems like the lack of prog= ress on Extended Attributes is creating a problem. =3B Design
Guidel= ines says that the RFC 2868 tagging scheme isn't suitable for generic use.&= nbsp=3B But it doesn't make
a recommendation. =3B If we don't get Ex= tended Attributes done=2C then we will be creating a problem.
After fin= ishing Design Guidelines=2C it seems like this needs to be our #2 priority.=

Bernard: =3B Agreed. =3B To be clear though=2C this docume= nt does not currently depend on Extended Attributes.
Question: =3B = If Extended Attributes were further along=2C would this document use it?
David Miles: =3B I don't think so. =3B

David Nelson:&= nbsp=3B It seems like there are a number of use cases here=2C and they are = not clearly described.
Bernard: =3B Previous documents have had ver= y well defined uses cases. =3B RFC 3162 supports address auto-
confi= guration. =3B RFC 4818 supports DHCPv6 Prefix Delegation. =3B This = document supports multiple modes=2C
and that is confusing.

David= Miles: =3B In looking at the attribute list=2C there are a set of attr= ibutes relating to router advertisements
that require tagging=2C but ano= ther set of attributes like IPv6-Address and IPv6-DNS-Server-Address that d= o not.
Would it make sense to split the document into two parts=2C one = focusing on DHCPv6=2C and
the other one on router advertisements?
Bernard Aboba: Yes=2C I think this would help.

David Nelson: = =3B Which attributes are you interested in?

David Miles: For the Bro= adband Forum=2C IPv6-Address is of the most immediate interest. =3B IPv= 6-DNS-Server-Address
is relevant but isn't as important since in most c= ases name resolution is being handled over IPv4.

Bernard Aboba:&nbs= p=3B If that is what you need=2C then focusing on that would enable things = to go forward much more
quickly. =3B Can you put a document together= that focuses on that?

David Miles: =3B There is already a docu= ment that does that.

David Nelson: =3B Which one?

David= Miles: =3B http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp= -00

Bernard Aboba: =3B Yes=2C that document just handles the att= ributes you are interested in. =3B However=2C it confused
the WG bec= ause it only talked about DHCPv6 and RADIUS=2C but did not talk about authe= ntication. =3B RADIUS is
spoken between a RADIUS client and server.&= nbsp=3B So if the RADIUS client is also a DHCPv6 server=2C then it makessense. =3B But if the DHCPv6 server is separate=2C then it's not clear= how it works. =3B Does the NAS pass the
RADIUS attributes to the DH= CPv6 server=2C and if so=2C how? =3B Is there authentication going on b= etween the
DHCPv6 server and the RADIUS server? =3B If there are no = authentication attributes is this a Call Check=2C
or is it changing the = RADIUS protocol in some way? =3B

David Miles: =3B I can inc= lude material on the Broadband Forum scenarios. =3B If I work with Beno= it to create
an -01 with that additional material would that help?
Bernard Aboba: =3B Yes=2C it would help a great deal.

Summary= /Wrapup

Bernard: =3B At the last virtual interim=2C the feedback= on DimDim was not very positive. =3B So we tried LiveMeeting this time= . =3B How did it work for people?
Dan Romascanu: The conference bri= dge was fine.
Alan DeKok: =3B I could not use the web conferencing = software=2C it was only available on Windows.
Dan Romascanu: =3B It= required me to install additional software (Outlook addin). =3B That i= s a big deal.
Bernard Aboba: =3B DimDim also required a software in= stall. =3B Though it supported more platforms.
David Nelson: = =3B Having a teleconference bridge=2C Jabber and slides is fine.
David = Miles: =3B As long as the slides don't get too long =3B or there ar= e too many people in the meeting. =3B Otherwise it's easy to lose your = place.
Bernard Aboba: =3B They had a session on WebEx at IETF 75=2C= in the Working Group Chairs meeting. =3B I asked the Secretariat if we= could get access=2C but didn't get a response. =3B So it was
either= DimDim or LiveMeeting.
Dan Romascanu: =3B I will inquire about the= availability of WebEx.

Bernard: Let's talk about the plans for IET= F 76. The RADEXT WG is not currently scheduled to meet at IETF 76. =3B = We have just completed the Virtual Interim=2C and
IETF 76 is in just a = few weeks.
Dan Romascanu: =3B Who is attending?
David Nelson:&nb= sp=3B I will not attend.
Bernard: No
Alan DeKok: No
Hannes: YesDan Romascanu: =3B There are disadvantages to not holding a meeting a= t IETF 76. =3B You will miss the opportunity to interact with the commu= nity=2C particularly participants from Asia. =3B
It would be good t= o have a representative at IETF 76. =3B Hannes is very busy=2C but perh= aps you can find someone to represent RADEXT.
Bernard: =3B If there= is WebEx available=2C we could participate remotely.
Dan Romascanu:&nb= sp=3B I will look into supporting WebEx at the OPS Area Meeting. =3B Th= ere are cost concerns.

<= tbody>

= --_538042d2-1b43-4715-b19f-edf438b88c70_-- -- to 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, 12 Oct 2009 23:34:48 +0000 Message-ID: From: "Bernard Aboba" To: Subject: RADEXT WG Virtual Interm, October 13, 2009 Date: Mon, 12 Oct 2009 16:33:55 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_056E_01CA4B59.CA8DBEA0" Thread-Index: AcpLlGc0bXtmY76ARuyDAadeKBwuygAAAdhQ Content-Language: en-us ------=_NextPart_000_056E_01CA4B59.CA8DBEA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The RADEXT WG Virtual Interim is taking place tomorrow, October 13, 2009 from 8 AM PDT to 10 AM PDT. Here is a link to the agenda and teleconference parameters for the meeting: http://www.drizzle.com/~aboba/RADEXT/oct_virtual_interim/oct-virtual-interim .txt Slide presentations for the meeting are available here: http://www.drizzle.com/~aboba/RADEXT/oct_virtual_interim/ ------=_NextPart_000_056E_01CA4B59.CA8DBEA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The RADEXT WG Virtual Interim is taking place = tomorrow, October 13, 2009 from 8 AM PDT to 10 AM PDT. 

 

Here is a link to the agenda and teleconference = parameters for the meeting:

http://www.drizzle.com/~aboba/RADEXT/oct_virtual_interim= /oct-virtual-interim.txt

 

Slide presentations for the meeting are available = here:

http://www.drizzle.com/~aboba/RADEXT/oct_virtual_interim/

 

 

 

------=_NextPart_000_056E_01CA4B59.CA8DBEA0-- -- to 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, 12 Oct 2009 19:01:18 +0000 Message-ID: From: "Bernard Aboba" To: "Bernard Aboba" , Subject: RADEXT WG Virtual Interim Date: Mon, 12 Oct 2009 12:00:48 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 8bit Thread-Index: Aco9XF3MpP4HhcMSSL29JYsB/rI9DQOEfEsQ Content-Language: en-us BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN="Bernard Aboba";RSVP=TRUE:mailto:bernarda@microsoft.com ATTENDEE;CN=radiusext@ops.ietf.org;RSVP=TRUE:mailto:radiusext@ops.ietf.org CLASS:PUBLIC CREATED:20091012T190047Z DESCRIPTION:When: Tuesday\, October 13\, 2009 8:00 AM-10:00 AM (UTC-08:00) Pacific Time (US & Canada).\nWhere: Teleconference\n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~* ~*~*~*\n\nMeeting agenda:\nhttp://www.drizzle.com/~aboba/RADEXT/oct_virtua l_interim/oct-virtual-interim.txt\n\n\nMeeting slides:\nhttp://www.drizzle .com/~aboba/RADEXT/oct_virtual_interim/\n\n=============================== =========================================\nBernard Aboba has invited you t o attend an online meeting.\nJoin the meeting \n\nMake sure the Office Live Meeting client is installed bef ore the meeting:\n* I am connecting from outside the Microsoft network \n AUDIO INFORMATION \n To join a meeting from your phone\, dial in using the foll owing information:\n Phone: +18883203585 [English]\n Phone: +14257063500 [English]\n Find a local phone number for your region \n\n Conference ID: 9182049\n Passcode: Passcode is not required.\n Note: If you have an account on this corporate network\, use your PIN to join. Have you set your PIN? \n TROUBLESHOOTING \n Unable to join the meeting? Start Office Live Me eting and join the meeting with the following information:\n Meeting ID: 63840ffb128647eca56d51898b461c42\n Entry Code: 6650\n Location: meet:sip :bernarda@microsoft.com\;gruu\;opaque=app:conf:focus:id:63840ffb128647eca5 6d51898b461c42%3Fconf-key=6650\n\n If you still cannot enter the meeting\, contact support:\n* Inside the Microsoft network \n* Ou tside the Microsoft network \n NOTICE \n Office Live Mee ting can be used to record meetings. By participating in this meeting\, yo u agree that your communications may be monitored or recorded at any time during the meeting.\n \n \n\n\n\n -+-----+-----+-----+-----+-----+-----+-- ---+-----+-\n \n\n Bernard Aboba has invited you to attend an online meeti ng using Microsoft® Office Communications Server.\n Join the meeting \n\n Make sure the Office Live Meetin g client is installed before the meeting:\n* I am connecting from inside t he Microsoft network \n* I am connecting from outside the Microsoft network \n AUDIO INFORMATION \n To join a meeting from your phone\, dial in using the foll owing information:\n Phone: +18883203585 [English]\n Phone: +14257063500 [English]\n Find a local phone number for your region \n\n Conference ID: 9182049\n Passcode: Passcode is not required.\n Note: If you have an account on this corporate network\, use your PIN to join. Have you set your PIN? \n TROUBLESHOOTING \n Unable to join the meeting? Start Office Live Me eting and join the meeting with the following information:\n Meeting ID: 63840ffb128647eca56d51898b461c42\n Entry Code: 6650\n Location: meet:sip :bernarda@microsoft.com\;gruu\;opaque=app:conf:focus:id:63840ffb128647eca5 6d51898b461c42%3Fconf-key=6650\n\n If you still cannot enter the meeting\, contact support:\n* Inside the Microsoft network \n* Ou tside the Microsoft network \nNOTICE \nOffice Live Meeti ng can be used to record meetings. By participating in this meeting\, you agree that your communications may be monitored or recorded at any time du ring the meeting.\n\nALTERNATE ARRANGEMENTS\n\nIn event of emergency\, we have reserved a DimDim teleconference # and Web conferencing facility:\n Phone #: 702-473-3463\n Passcode: 226220\n Web conferencing: http:// webmeeting.dimdim.com/portal/JoinForm.action?meetingRoomName=aboba&email=b ernard_aboba@hotmail.com&displayName=bernard_aboba&asPresenter=false\n\n\n \n\n\n DTEND:20091013T170000Z DTSTAMP:20091012T190047Z DTSTART:20091013T150000Z LAST-MODIFIED:20091012T190047Z LOCATION:Teleconference ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:1 SUMMARY;LANGUAGE=en-us:RADEXT WG Virtual Interim TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000207BF5BC213DCA01000000000000000 01000000000B361B47DA51743AEADC01A3297B0F7 X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Tuesday\, October 13\, 2009 8:00 AM-10:00 AM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: Teleconference

\n\n

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

\n\n

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

\n\n

Meeting agenda:

\n\n

http://www.drizzle.com/~aboba/RADEXT/oct _virtual_interim/oct-virtual-interim.txt

\n
\n\n

Meeting slides:

\n\n

http://www.drizzle.com/~aboba/RADEXT/oct _virtual_interim/

\ n\n

\n\n

================================================================= =======

\n\n

Bernard Aboba has invited you to attend an online meeting.

\n\n

Join the meeting

\n\n

Make sure the Office Live Meeting client is installed before the meetin g:

\n
    \n\n

    AUDIO INFORMATION

    \n\n

    To joi n a meeting from your phone\, dial in using the following information:

    \n\n

     \; \; \;  \; \; \; \; Phone: \; +18883203 585 [English]

    \n\n

     \;&n bsp\; \; \; \; \; \; Phone:  \; +14257063500 [English]

    \n\n

     \; \; \; \; \; \; \; Find a local phone number for your region

    \n\n

     \; \; \; \; \; \; \; Conference ID: \; 9182049

    \n\n

     \; \; \; \; \; \; \; Passcode: \; \; \; \; \;  \; Passcode is not required.

    \n\n

     \; \; \; \; \; \; \; Note: If you have an account on this corporate network\, use your PIN to join. Have you set your PIN?

    \n\n

    TROUBLESHOOTING

    \n\n

    Unable to join t he meeting? \; Start Office Live Meeting and join the meeting with the following information:

    \n\n

     \; \; \; \; \; \; \; Meeting ID: \; \; \; \; 63840ffb128647eca56d51898b461c 42

    \n\n

     \; \; \ ; \; \; \; \; Entry Code: \ ; \; \; \; 6650

    \n\n

     \; \; \; \; \; \; \; Location: \; \; \; \; \; \;< SPAN LANG="en-us"> meet:sip:bernarda@microsoft.co m\;gruu\;opaque=app:conf:focus:id:63840ffb128647eca56d51898b461c42%3Fconf- key=6650

    \n\n

    If you still cannot ent er the meeting\, contact support:

    \n\n\ n

    NOTICE

    \n\n

    Office Live Meeting can be used to record meetings. By participating in this meeting\, you agree t hat your communications may be monitored or recorded at any time during th e meeting.

    \n\n

    \n \n

    \n
    \n
    \n\n

    -+-----+-----+-----+-----+-----+-----+-----+-----+-

    \n\n

    \n\n

    Bernard Aboba has invited you to attend an online meeting using Microsoft® Office Communications Server.

    \n\n

    Join the meeting

    \n\n

    Make sure the Office Live Meeting client is installed before the meeting:

    \n\n\n

    AUDIO INFORMATION

    \n\n

    To join a meeting from your phone\, dial in using the following informati on:

    \n\n

     \; \;  \; \; \; \; \; Phone: \; +1 8883203585 [English]

    \n\n

    &n bsp\; \; \; \; \; \; \; Phone: \; +14257063500 [English]

    \n\n

     \; \; \; \; \; \; \; Find a local phone number for your reg ion

    \n\n

     \; \; \; \; \; \; \; Conference ID: \; 9182049

    \n\n< P DIR=LTR> \; \; \; \; \; \;&nb sp\; Passcode: \; \; \; \;  \; \; Passcode is not required.

    \n\n

     \; \; \; \; \; \; \; Note: If you have an account on this corporate network\, u se your PIN to join. H ave you set your PIN?< /P>\n\n

    < FONT COLOR="#004D80" FACE="Tahoma">TROUBLESHOOTING

    \n\n

    Unable to join the meeting? \; Start Office Live Meeting and join the meeting w ith the following information:

    \n\n

     \; \; \; \; \; \; \; Meeting ID: \; \; \; \; 63840ffb128647eca56d518 98b461c42

    \n\n

     \; \ ; \; \; \; \; \; Entry Code : \; \; \; \; 6650

    \n\n

     \; \; \; \; \; \; \; Location: \; \; \; \; \; \;< /SPAN> meet:sip:bernarda@micro soft.com\;gruu\;opaque=app:conf:focus:id:63840ffb128647eca56d51898b461c42% 3Fconf-key=6650

    \n\ n

    If you still can not enter the meeting\, contact support:

    \n\n
\n

NOTICE

\n\n

Office Live Meeting can be used to record meetings. By participating in this meeting\, you agree that your communications may be monitored or recorded at any ti me during the meeting.

\n\n

AL TERNATE ARRANGEMENTS

\n\n

In event of emergency\, we have reserved a DimDim teleconference # and Web conferencing facility:

\n\n

 \; \; Phone #: \; 702-473- 3463

\n\n

 \; \; Passcode: 226220

\n\n

< SPAN LANG="en-us"> \; \; Web conferenci ng: http://webmeeting.dimdim.com/porta l/JoinForm.action?meetingRoomName=aboba&\;email=bernard_aboba@hotmail.c om&\;displayName=bernard_aboba&\;asPresenter=false

\n
\n
\n\n

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTSEQTIME:20090924T213026Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 12 Oct 2009 18:40:01 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_7da9945b-7ff9-4824-bf84-5e34e4538670_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RADEXT Virtual Interim Agenda - Take 3 Date: Mon, 12 Oct 2009 11:38:38 -0700 MIME-Version: 1.0 --_7da9945b-7ff9-4824-bf84-5e34e4538670_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is the current state of the RADEXT Virtual Interim Agenda. If you are= n't on the agenda and would like to be=2C or if you are on the agenda and h= aven't sent slides=2C please send email to me IMMEDIATELY.=20 =20 RADEXT WG Virtual Interim Agenda =20 Chairs: Bernard Aboba bernard_aboba@hotmail.com David Nelson d.b.nelson@comcast.net =20 Tuesday=2C October 13=2C 2009 =20 8 AM - 10 AM PDT (11:00 - 13:00 EDT) =20 RADEXT Issues list =20 http://www.drizzle.com/~aboba/RADEXT/ =20 Agenda Slides http://www.drizzle.com/~aboba/RADEXT/oct_virtual_interim/ =20 Strawman Agenda =20 8:00 AM - 8:20 AM Preliminaries Jabber scribe Agenda Bash Document Status=20 =20 Documents completing IETF Last Call (10 minutes) =20 8:20 AM - 8:30 AM Design Guidelines=2C Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-design =20 Documents Completing WG Last Call (20 minutes) =20 8:30 AM - 8:40 AM Status-Server=2C Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-status-server =20 8:40 AM - 8:50 AM RADIUS over TCP=2C Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp-transport =20 Under Consideration for Adoption (40 minutes) =20 8:50 AM - 9:00 AM RADIUS over DTLS=2C Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-dekok-radext-dtls =20 9:00 AM - 9:10 AM RADIUS Attributes for IEEE 802 Networks=2C Bernard Aboba = (10 minutes) http://tools.ietf.org/html/draft-aboba-radext-wlan =20 9:10 AM - 9:40 AM IPv6 Attribute Design Issues=2C Hannes Tschofenig (20 min= utes) http://tools.ietf.org/html/draft-lourdelet-ipv6-access = --_7da9945b-7ff9-4824-bf84-5e34e4538670_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is the current state of the RADEXT Virtual Interim Agenda. =3B If = you aren't on the agenda and would like to be=2C or if you are on the agend= a and haven't sent slides=2C please send email to me IMMEDIATELY.
 =3B
RADEXT WG Virtual Interim Agenda
 =3B
Chairs: Bernard Aboba bernard_= aboba@hotmail.com
David Nelson d.b.nelson@comcast.n= et
 =3B
Tuesday=2C October 13=2C 2009
 =3B
8 AM - 10 AM PDT (11:00 - 13:00 EDT)
 =3B
RADEXT Issues list
 =3B
http://www.drizzle.com/~a= boba/RADEXT/
 =3B
Agenda Slides
http:= //www.drizzle.com/~aboba/RADEXT/oct_virtual_interim/
 =3B
Strawman Agenda
 =3B
8:00 AM - 8:20 AM Preliminaries
Jabber scribe
Agenda Bash
Document Status
 =3B
Documents completing IETF Last Call (10 minutes)
 =3B
8:20 AM - 8:30 AM Design Guidelines=2C Alan DeKok (10 minutes)
http://tool= s.ietf.org/html/draft-ietf-radext-design
 =3B
Documents Completing WG Last Call (20 minutes)
 =3B
8:30 AM - 8:40 AM Status-Server=2C Alan DeKok (10 minutes)
http= ://tools.ietf.org/html/draft-ietf-radext-status-server
 =3B
8:40 AM - 8:50 AM RADIUS over TCP=2C Alan DeKok (10 minutes)
http= ://tools.ietf.org/html/draft-ietf-radext-tcp-transport
 =3B
Under Consideration for Adoption (40 minutes)
 =3B
8:50 AM - 9:00 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools= .ietf.org/html/draft-dekok-radext-dtls
 =3B
9:00 AM - 9:10 AM RADIUS Attributes for IEEE 802 Networks=2C Bernard Aboba = (10 minutes)
http://tools= .ietf.org/html/draft-aboba-radext-wlan
 =3B
9:10 AM - 9:40 AM IPv6 Attribute Design Issues=2C Hannes Tschofenig (20 min= utes)
http://t= ools.ietf.org/html/draft-lourdelet-ipv6-access
 = --_7da9945b-7ff9-4824-bf84-5e34e4538670_-- -- to 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, 12 Oct 2009 15:00: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-tcp-transport-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091012150001.464563A68F4@core3.amsl.com> Date: Mon, 12 Oct 2009 08:00: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 : RADIUS Over TCP Author(s) : A. DeKok Filename : draft-ietf-radext-tcp-transport-04.txt Pages : 18 Date : 2009-10-12 The Remote Authentication Dial In User Server (RADIUS) Protocol has traditionally used the User Datagram Protocol (UDP) as it's underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (TCP), in order to address transport issues related to RADIUS over TLS [RTLS]. It is not intended to define TCP as a transport protocol for RADIUS in the absence of TLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-tcp-transport-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-tcp-transport-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-12075257.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 12 Oct 2009 14:54:40 +0000 Message-ID: <4AD342F1.3080109@deployingradius.com> Date: Mon, 12 Oct 2009 16:53:37 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: 'radext mailing list' Subject: Refresh of the drafts Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've refreshed all of my current drafts, and will post slides later today. 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, 12 Oct 2009 14:52:47 +0000 Message-ID: <4AD3426F.5030108@deployingradius.com> Date: Mon, 12 Oct 2009 16:51:27 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: REMINDER: Call for adoption of "RADIUS over TCP" as a RADEXT WG Work Item Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > How about this? > > "Deployment experience with RADIUS over TLS indicates that it is > most useful for inter-server communication, such as inter-domain > communication between proxies. These situations benefit from > the confidentiality and ciphersuite negotiation that can be provided > by TLS. Since TLS is already widely available within the operating > systems used by proxies, implementation barriers are low. ... OK. I've added it with minor re-wording in places. 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, 12 Oct 2009 10:15:40 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-status-server-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091012101501.A110C28C154@core3.amsl.com> Date: Mon, 12 Oct 2009 03:15:01 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol Author(s) : A. DeKok Filename : draft-ietf-radext-status-server-05.txt Pages : 23 Date : 2009-10-12 This document describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-status-server-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-12030024.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 12 Oct 2009 09:52:21 +0000 Message-ID: <4AD2FC3A.80806@deployingradius.com> Date: Mon, 12 Oct 2009 11:51:54 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: REMINDER: RADEXT WG Last Call on Status Server document (part 2) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: .. > [BA] Can you provide a section reference for the Tw timer? Done. ... > [BA] I think a bit more explanation would be helpful here. Traditional "failover" algorithms have > depended on use of Access-Request packets. Unfortunately, these techniques can lead a client to failover > in circumstances where there is nothing wrong with the primary proxy. So in reading the first paragraph, > I'm unclear what is being advocated, precisely. For example, is it being advocated that a Status-Server > packet be sent to the primary proxy after a number of Access-Requests do not receive a response? That > would help determine whether the primary proxy was the issue in the first place. If it is not the issue > (e.g. primary proxy responds), then sending Status-Server packets to the primary proxy would seem > pointless. OK. I've added some text to the document that will hopefully clarify this. > Section 4.4 > > The point that Status-Server packets are non-forwardable is quite central to the document, so it would > be a good idea to make the point earlier. That is addressed in the updates from the previous message. > Section 4.5 > > 4.5. Realm Routing ... > > [BA] What mechanism? Since Status-Server packets are non-forwardable, there no concept of a destination > realm, right? Yes. I've clarified the wording in the first paragraph. > Overall, I think this section might be retitled "Limitations of Status-Server" because that is really the > main focus. OK. > On reading this section, the thought did occur to me that in the cause where Status-Server indicated > a downstream failure that "per-realm" failover might make sense. For example, if the primary could > reach realm A but not B, there is no point in failing over all Requests to the secondary, just those > for realm B. Of course, it is also possible that a fault in a downstream node that prevented > reaching realm A (e.g. a failure in a server for realm A) might subsequently be corrected, so that > realm A might become reachable again. It's a good idea. I'm not sure if any client or server supports that behavior, however. > Section 5 > > Recommend including a row for User-Name, which presumably would have all 0s in it (e.g. User-Name is not used > in Status-Server packets, right?). The first paragraph says: Attributes other than the ones listed below SHOULD NOT be found in a Status-Server packet. I think that covers it. > What is the purpose of VSAs in Status-Server packets or Access-Responses? To permit future vendor extensions, as with normal RADIUS. 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, 12 Oct 2009 09:34:41 +0000 Message-ID: <4AD2F7FC.9060103@deployingradius.com> Date: Mon, 12 Oct 2009 11:33:48 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: REMINDER: RADEXT WG Last Call on Status Server document (part 1) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Here is my review. > > Abstract ... > How about something more along the lines of the RFC 5176 abstract? Looks good to me. > Not sure the history is necessarily correct (e.g. I believe that the RADIUS Working Group was formed earlier). > In any case, it is probably best to focus on the purpose of this document. How about this? OK. I've added it with some minor edits. > I am not sure that the use of the term "Home Server" here adds clarity. The definition of proxy from > RFC 2607 might be more applicable: Added. I've updated the document to use "RADIUS Proxy" and "RADIUS Server" throughout. > I think this document needs an applicability section, to explain potential differences between > this specification and existing implementations, as well as why it is being published as Informational, > as opposed to Experimental or Standards Track. Suggest the following: I agree. > RFC 2865 Section 2.6 strongly discourages the use of keep-alives. > From reading this section, I am unclear whether the intent is to refute the > arguments made there, or to articulate how the uses of Status-Server > defined here go beyond those of the "test RADIUS request" described > in RFC 2865. The idea is to state that the Status-Server does not conflict with the RFC2865 mandate against Keep-Alives. I'll re-word the text. > Overall, I wonder whether some of the introductory material in Section 4.3 > might be removed from that section and instead be revised and presented > in this section. For example: Very likely, yes. > Sections 2.1-2.2 > > I find these sections puzzling, because they suggest alternatives to the Status-Server packet > that do not serve the same function. They explain why Status-Server was chosen. I can update the titles && re-word the text slightly to make this more clear. > Section 2.3 ... > While the Status-Server packet format was not defined in RFC 2865, it was implemented by Ascend and > other vendors. As far as I know, a number of deployments did use NAS and RADIUS servers from different > vendors so that "implementation-specific definitions" would indeed have resulted in interoperability > problems. > > In any case, as I understand it, the goal of this work item is to document existing implementations of > the Status-Server extension, correct? Yes. > Section 2.3.1 ... > Given that the Status-Server packet is not forwardable, this section is a bit > confusing. Also, I'm not clear how useful the diagram is. > I'd suggest focusing on the basics of the exchange: Ok. Looks good to me. I've added text on Accounting-Message, and re-worded things a bit. > BTW, I'm curious as to whether a Status-Server packet can be sent to the address > and port (3799) of a DAS, and if so, what the appropriate response is. That was discussed and rejected earlier. This document talks about currently implemented uses of Status-Server. > Section 2.3.2 > > The Status-Server packet MUST contain a Message-Authenticator > attribute for security. > > Given that implementations exist that did not support Message-Authenticator, my suggestion is that this > become a SHOULD. I'm wary of this one. I would say that new implementations MUST use Message-Authenticator. Making it a "SHOULD" means that a lot of people will ignore it. 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, 12 Oct 2009 08:16:19 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-design-09.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091012081501.EC14E3A683C@core3.amsl.com> Date: Mon, 12 Oct 2009 01:15:01 -0700 (PDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Design Guidelines Author(s) : G. Weber, A. DeKok Filename : draft-ietf-radext-design-09.txt Pages : 37 Date : 2009-10-12 This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-design-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-12010734.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: Wed, 07 Oct 2009 18:27:00 +0000 Message-ID: <4ACCDD45.7080907@deployingradius.com> Date: Wed, 07 Oct 2009 20:26:13 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: "'Wojciech Dec (wdec)'" , 'Bernard Aboba' , "'David B. Nelson'" , radiusext@ops.ietf.org Subject: Re: IPv6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > No, I'm arguing what the standards _actually_ say, while you are arguing > what you _want_ them to say. I can't recall making statements about what I want the standards to say. Perhaps you could point to one of my messages which says that? >> Because ONE attribute is >> of a unique complex type, it means that any attempt to use standard >> types is useless. > > It's hardly just one, but the point is that "complex" types are as standard > as any other of those either specifically defined in RFCs or those that were > not (like 64-bit integers) of which you apparently approve. Ah. Like the "standard" attributes defined in RFC 2548, which is "Category: Informational". In case you haven't read my messages, I'm *not* objecting to complex types. I'm objecting to the *gratuitous* use of complex types. 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, 07 Oct 2009 16:48:50 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_0e467691-9943-4753-8f2f-5a6f915bf0f4_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Virtual interim discussion of the IPv6 document Date: Wed, 7 Oct 2009 09:48:16 -0700 MIME-Version: 1.0 --_0e467691-9943-4753-8f2f-5a6f915bf0f4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have reserved time on the October 13 Virtual Interim agenda for discussi= on of the IPv6 document.=20 In order to structure the discussion=2C I would like to solicit presentatio= ns relating to the following aspects: a. Broadband Forum requirements for IPv6 over PPP support b. Pros and Cons of potential encoding approaches 1. Use of Extended Attributes tagging mechanism 2. RA string encoding 3. Definition of new tagged data types Do we have volunteers for these presentations? =20 In order to make the slides available in time=2C I'd like get all presentat= ion materials by October 11.=20 = --_0e467691-9943-4753-8f2f-5a6f915bf0f4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have reserved time on the October 13 Virtual Interim agenda for discussi= on of the IPv6 document.

In order to structure the discussion=2C I = would like to solicit presentations relating to the following aspects:
<= br>a. Broadband Forum requirements for IPv6 over PPP support
b. Pros and= Cons of potential encoding approaches
 =3B  =3B 1. =3B Use = of Extended Attributes tagging mechanism
 =3B =3B =3B 2.&nbs= p=3B RA string encoding
 =3B =3B =3B 3. =3B Definition o= f new tagged data types

Do we have volunteers for these presentation= s? =3B

In order to make the slides available in time=2C I'd lik= e get all presentation materials by October 11.
= --_0e467691-9943-4753-8f2f-5a6f915bf0f4_-- -- to 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, 07 Oct 2009 16:29:30 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'Wojciech Dec \(wdec\)'" , "'Bernard Aboba'" , "'David B. Nelson'" , Subject: RE: IPv6 Date: Wed, 7 Oct 2009 23:28:27 +0700 Message-ID: <00af01ca476b$3f842ca0$be8c85e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpHZrRCgIE85/AHQLSMbK8ko7NBwwAA1H4g Content-Language: en-us Alan DeKok [mailto:aland@deployingradius.com] writes: ... > I think the confusion here is I'm talking about real-world, > imprecise, > imperfect practice. So "common use" means "95%". And "a handful" > means > "8". > > You're arguing from a point of perfection. No, I'm arguing what the standards _actually_ say, while you are arguing what you _want_ them to say. > Because ONE attribute is > of a unique complex type, it means that any attempt to use standard > types is useless. It's hardly just one, but the point is that "complex" types are as standard as any other of those either specifically defined in RFCs or those that were not (like 64-bit integers) of which you apparently approve. ... -- to 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, 07 Oct 2009 15:56:58 +0000 Message-ID: <4ACCBA1B.20302@deployingradius.com> Date: Wed, 07 Oct 2009 17:56:11 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: "'Wojciech Dec (wdec)'" , 'Bernard Aboba' , "'David B. Nelson'" , radiusext@ops.ietf.org Subject: Re: IPv6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > Alan DeKok [mailto:aland@deployingradius.com] writes: >> Ah... the RFC 2486 definition that the NAS-IP-Address attribute is an >> "ipv4 address" is just there for joviality. > > Must be a typo -- RFC 2486 nowhere mentions the NAS-IP-Address attribute & > doesn't contain the (case-folded) string "IPv4". What are you actually > talking about? You're right. It defines a 32-bit IP address that is completely unrelated to IPv4. > That's all, "four octets". Note that the "Address" data type is defined > previously in the document but it's not used here. Could be a "string" of > length 4, could be an "Integer", could be an "Address". This may seem > frivolous, but it's related to David's comments in another message: it > actually doesn't matter what the data type is because everybody _knows_ that > it's an IPv4 address -- we are 'conceptually overlaying' the 4 octet field > with a contiguous sub-field interpreted as an IPv4 address. Of course. Just like we're conceptually overlaying "octets", where there are really groups of "0" and "1" bits. At some point this abstraction becomes absurd. > The same thing > happens all over the place in RFC 2865 and if David is correct then the > "data" fields in probably half the attributes defined therein are unique > data types. See my previous audit of RFC and vendor attributes posted to this list. About 95% use the simple standard data types. (IP address, integer, text, etc. but not string) >> Or, as the design guidelines document says: >> >> Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does >> not define a formal data definition language. A handful of basic >> data types are provided, and a data type is associated with an >> attribute when the attribute is defined. > > But that's not true, either - a single counterexample would suffice & I've > already given half a dozen. See my previous audit of RFC and vendor attributes posted to this list. There are 8 common data types. That's "a handful". And 95% of attributes use this "handful". I think the confusion here is I'm talking about real-world, imprecise, imperfect practice. So "common use" means "95%". And "a handful" means "8". You're arguing from a point of perfection. Because ONE attribute is of a unique complex type, it means that any attempt to use standard types is useless. OK... let's give up trying to re-use common types. Let's define novel on-the-wire encodings for every single new attribute. That will really accelerate the progress of documents in this WG! >> New formats require new encoders/decoders. Is that controversial? >> >> Re-using existing formats is usually good. Is that controversial? > > Both those statements seem implementation-specific to me. I welcome an implementation which can encode and decode novel formats with zero changes to the software (binaries, config files, dictionaries, etc.) That's some kind of magic bean you're selling. 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, 07 Oct 2009 14:07:33 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'Wojciech Dec \(wdec\)'" , "'Bernard Aboba'" , "'David B. Nelson'" , Subject: RE: IPv6 Date: Wed, 7 Oct 2009 21:06:32 +0700 Message-ID: <007401ca4757$6b408dc0$41c1a940$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpHUQxuUiRuqaBzQAqptbbIvID9fwAAkAaA Content-Language: en-us Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > > Alan DeKok [mailto://aland@deployingradius.com] writes: > >> RADIUS attributes are typed. > > > > In your mind, perhaps; in the real world (where RFC 2865 exists), one > may > > read page after page without ever seeing an attribute "typed". > > Ah... the RFC 2486 definition that the NAS-IP-Address attribute is an > "ipv4 address" is just there for joviality. Must be a typo -- RFC 2486 nowhere mentions the NAS-IP-Address attribute & doesn't contain the (case-folded) string "IPv4". What are you actually talking about? > It can really be anything > you want. This is how RFC 2865 defines the attribute: 5.4. NAS-IP-Address Description This Attribute indicates the identifying IP Address of the NAS which is requesting authentication of the user, and SHOULD be unique to the NAS within the scope of the RADIUS server. NAS-IP- Address is only used in Access-Request packets. Either NAS-IP- Address or NAS-Identifier MUST be present in an Access-Request packet. Note that NAS-IP-Address MUST NOT be used to select the shared secret used to authenticate the request. The source IP address of the Access-Request packet MUST be used to select the shared secret. A summary of the NAS-IP-Address Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 for NAS-IP-Address. Length 6 Address The Address field is four octets. That's all, "four octets". Note that the "Address" data type is defined previously in the document but it's not used here. Could be a "string" of length 4, could be an "Integer", could be an "Address". This may seem frivolous, but it's related to David's comments in another message: it actually doesn't matter what the data type is because everybody _knows_ that it's an IPv4 address -- we are 'conceptually overlaying' the 4 octet field with a contiguous sub-field interpreted as an IPv4 address. The same thing happens all over the place in RFC 2865 and if David is correct then the "data" fields in probably half the attributes defined therein are unique data types. > > Or, as the design guidelines document says: > > Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does > not define a formal data definition language. A handful of basic > data types are provided, and a data type is associated with an > attribute when the attribute is defined. But that's not true, either - a single counterexample would suffice & I've already given half a dozen. > > >> The list of types is small. Each type > >> is statically defined in an RFC. > > > > In what RFC is the "8-bit Tag + 24-bit Integer" "data type" defined? > That's > > easy, none. The fact that some implementations _treat_ it as a "data > type" > > doesn't make it so, since there are other ways to implement a tag. > > Strange. I was talking about the protocol, and the definition of > attributes. Having done some minor programming from time to time, I just want to note that I deserve MAJOR style points for letting that one pass ;-). > I am > aware of the difference between wire encoding and data structures > internal to an implementation. > > Would you be happier if I said "there are a limited number of data > formats that are encoded/decoded on the wire" ? Maybe that would make > it clearer that I am talking about the protocol. I'd be happier if you didn't use the same term to name two entirely different things. > > New formats require new encoders/decoders. Is that controversial? > > Re-using existing formats is usually good. Is that controversial? Both those statements seem implementation-specific to me. -- to 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, 07 Oct 2009 13:30:45 +0000 From: "Glen Zorn" To: "'David B. Nelson'" Cc: Subject: RE: IPv6 Date: Wed, 7 Oct 2009 20:30:00 +0700 Message-ID: <006a01ca4752$4bdd38c0$e397aa40$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpGzdNBVc79f+CoQrqhM8bxoDWDIwAgQQiw Content-Language: en-us David B. Nelson [mailto://dnelson@elbrysnetworks.com]: > > That same RFC 2865, in section 5, states: > > > > string 1-253 octets containing binary data (values 0 through > > 255 decimal, inclusive). Strings of length zero (0) > > MUST NOT be sent; omit the entire attribute instead. > > > > With that, Ipv6 Prefix, Route options, Auth-IPv6-Prefix-User-ID, etc > > would be pretty much covered by using the string term. > > With all due respect, the String data type is just a string of > undistinguished octets. Reference, please (don't tell me you've adopted the DeKok method of just making it up as you go, as you please!). > While you may conceptually overlay it with a > structure, i.e define sub-fields, that action creates a new data > type. In other words, the String type is just a string. You may > lament the fact that RADIUS, as defined in RFCs up through 2865, has > no method to formally define structured data, but the fact is that it > has none. There are a number of problems with this little fantasy (along with the idea that so-called "complex" attributes are not a "traditional" RADIUS data type), among them that a) RFC 2548 contains oodles of "structured data" in _very_ widely implemented and deployed attributes, b) RFC 2865 itself contains "structured data" in the CHAP-Password attribute and c) RFC 2868 (which was published the same day as 2865 -- in fact it was delayed in the queue to let 2865 go first), again, has lots of "complex" attributes and, for that matter, structured data. You may lament the fact that RADIUS has methods to define "structured data" and even try to write it out of history (as Alan apparently wishes to) but the fact is that it does. -- to 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, 07 Oct 2009 13:21:37 +0000 Message-ID: <4ACC95C7.9020600@deployingradius.com> Date: Wed, 07 Oct 2009 15:21:11 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Glen Zorn CC: "'Wojciech Dec (wdec)'" , 'Bernard Aboba' , "'David B. Nelson'" , radiusext@ops.ietf.org Subject: Re: IPv6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > Alan DeKok [mailto://aland@deployingradius.com] writes: >> RADIUS attributes are typed. > > In your mind, perhaps; in the real world (where RFC 2865 exists), one may > read page after page without ever seeing an attribute "typed". Ah... the RFC 2486 definition that the NAS-IP-Address attribute is an "ipv4 address" is just there for joviality. It can really be anything you want. Or, as the design guidelines document says: Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does not define a formal data definition language. A handful of basic data types are provided, and a data type is associated with an attribute when the attribute is defined. >> The list of types is small. Each type >> is statically defined in an RFC. > > In what RFC is the "8-bit Tag + 24-bit Integer" "data type" defined? That's > easy, none. The fact that some implementations _treat_ it as a "data type" > doesn't make it so, since there are other ways to implement a tag. Strange. I was talking about the protocol, and the definition of attributes. Having done some minor programming from time to time, I am aware of the difference between wire encoding and data structures internal to an implementation. Would you be happier if I said "there are a limited number of data formats that are encoded/decoded on the wire" ? Maybe that would make it clearer that I am talking about the protocol. New formats require new encoders/decoders. Is that controversial? Re-using existing formats is usually good. Is that controversial? 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, 07 Oct 2009 13:08:55 +0000 Message-ID: <4ACC92C5.7030905@deployingradius.com> Date: Wed, 07 Oct 2009 15:08:21 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" CC: "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: IPv6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wojciech Dec (wdec) wrote: > Sure, that's fair. The point I was making is that with the string > definition above, passing an IPv6 prefix (or anything else up to 255 > bytes really) did not require any new data-type and in terms of say the > IPv6-prefix. From the design guidelines document: If the RADIUS Server simply passes the contents of an attribute to some non-RADIUS portion of the network, then the data is opaque, and SHOULD be defined to be of type String. A concrete way of judging this requirement is whether or not the attribute definition in the RADIUS document contains delineated fields for sub-parts of the data. If those fields need to be delineated in RADIUS, then the data is not opaque, and it SHOULD be separated into individual RADIUS attributes. > Furthermore rfc2868 provides plenty of precedent for > structured attributes with "String", if one wants, eg Tunnel-Password. From the design guidelines document: As can be seen in Appendix B, most of the existing complex attributes involve authentication or security functionality. Supporting this functionality requires code changes on both the RADIUS client and server, regardless of the attribute format. As a result, in most cases, the use of complex attributes to represent these methods is acceptable, and does not create additional interoperability or deployment issues. All of these arguments are familiar, and have been hashed through in detail in this WG. There are good reasons for the current behavior. The document explains that *changes* in behavior need good reasons, too. 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, 07 Oct 2009 13:05:36 +0000 From: "Glen Zorn" To: "'Alan DeKok'" , "'Wojciech Dec \(wdec\)'" Cc: "'Bernard Aboba'" , "'David B. Nelson'" , Subject: RE: IPv6 Date: Wed, 7 Oct 2009 20:04:41 +0700 Message-ID: <006601ca474e$c69e3a40$53daaec0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpHLsmc1qj/Np5hT0+XmdHjb2uPVQAG+8iA Content-Language: en-us Alan DeKok [mailto://aland@deployingradius.com] writes: > Wojciech Dec (wdec) wrote: > > Guess someone forgot to add a character encoding set limitation to > the > > definition of "string" above. Without it, any sequence of 1-253 > octets > > falls neatly under the "a string". > > Is this a joke? > > Here's a short explanation, as it's clear you are completely > unfamiliar with RADIUS. Well, _someone_ is... > > RADIUS attributes are typed. In your mind, perhaps; in the real world (where RFC 2865 exists), one may read page after page without ever seeing an attribute "typed". A brief example: 5.4. NAS-IP-Address Description This Attribute indicates the identifying IP Address of the NAS which is requesting authentication of the user, and SHOULD be unique to the NAS within the scope of the RADIUS server. NAS-IP- Address is only used in Access-Request packets. Either NAS-IP- Address or NAS-Identifier MUST be present in an Access-Request packet. Note that NAS-IP-Address MUST NOT be used to select the shared secret used to authenticate the request. The source IP address of the Access-Request packet MUST be used to select the shared secret. A summary of the NAS-IP-Address Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 for NAS-IP-Address. Length 6 Address The Address field is four octets. 5.5. NAS-Port Description This Attribute indicates the physical port number of the NAS which is authenticating the user. It is only used in Access-Request packets. Note that this is using "port" in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD be present in an Access-Request packet, if the NAS differentiates among its ports. A summary of the NAS-Port Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 5 for NAS-Port. Length 6 Value The Value field is four octets. 5.6. Service-Type Description This Attribute indicates the type of service the user has requested, or the type of service to be provided. It MAY be used in both Access-Request and Access-Accept packets. A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead. A summary of the Service-Type Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 6 for Service-Type. Length 6 Value The Value field is four octets. 1 Login 2 Framed 3 Callback Login 4 Callback Framed 5 Outbound 6 Administrative 7 NAS Prompt 8 Authenticate Only 9 Callback NAS Prompt 10 Call Check 11 Callback Administrative The service types are defined as follows when used in an Access- Accept. When used in an Access-Request, they MAY be considered to be a hint to the RADIUS server that the NAS has reason to believe the user would prefer the kind of service indicated, but the server is not required to honor the hint. Login The user should be connected to a host. Framed A Framed Protocol should be started for the User, such as PPP or SLIP. Callback Login The user should be disconnected and called back, then connected to a host. Callback Framed The user should be disconnected and called back, then a Framed Protocol should be started for the User, such as PPP or SLIP. Outbound The user should be granted access to outgoing devices. Administrative The user should be granted access to the administrative interface to the NAS from which privileged commands can be executed. NAS Prompt The user should be provided a command prompt on the NAS from which non-privileged commands can be executed. Authenticate Only Only Authentication is requested, and no authorization information needs to be returned in the Access-Accept (typically used by proxy servers rather than the NAS itself). Callback NAS Prompt The user should be disconnected and called back, then provided a command prompt on the NAS from which non-privileged commands can be executed. Call Check Used by the NAS in an Access-Request packet to indicate that a call is being received and that the RADIUS server should send back an Access-Accept to answer the call, or an Access-Reject to not accept the call, typically based on the Called-Station-Id or Calling-Station-Id attributes. It is recommended that such Access-Requests use the value of Calling-Station-Id as the value of the User-Name. Callback Administrative The user should be disconnected and called back, then granted access to the administrative interface to the NAS from which privileged commands can be executed. 5.7. Framed-Protocol Description This Attribute indicates the framing to be used for framed access. It MAY be used in both Access-Request and Access-Accept packets. A summary of the Framed-Protocol Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 7 for Framed-Protocol. Length 6 Value The Value field is four octets. 1 PPP 2 SLIP 3 AppleTalk Remote Access Protocol (ARAP) 4 Gandalf proprietary SingleLink/MultiLink protocol 5 Xylogics proprietary IPX/SLIP 6 X.75 Synchronous 5.8. Framed-IP-Address Description This Attribute indicates the address to be configured for the user. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that address, but the server is not required to honor the hint. A summary of the Framed-IP-Address Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8 for Framed-IP-Address. Length 6 Address The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS Should allow the user to select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates that the NAS should select an address for the user (e.g. Assigned from a pool of addresses kept by the NAS). Other valid values indicate that the NAS should use that value as the user's IP address. > The list of types is small. Each type > is statically defined in an RFC. In what RFC is the "8-bit Tag + 24-bit Integer" "data type" defined? That's easy, none. The fact that some implementations _treat_ it as a "data type" doesn't make it so, since there are other ways to implement a tag. > RADIUS implementations use these > definitions to determine how to manipulate the attributes (parse, > print, > wire-encode, wire-decode). The types cannot be changed, because they > have existing definitions. Defining new encoding/decode means defining > new types... because you can't encode the OLD type in a NEW way, and > you > can't encode the NEW type in the OLD way. > > Otherwise... please suggest how implementations can do the > impossible, > and encode these new attributes using a novel format, without adding a > new encoding method. > > > That said, rfc 3162 clearly already > > has a "call it whatever you want" data-type for "Framed-IPv6-Prefix", > > which happens to be the same type of data as in the IPv6-Prefix in > > draft-lourdelet. > > Absolute nonsense. Framed-IPv6-Prefix has a different on-the-wire > format than IPv6-prefix. Therefore, they are different data types. Alan, who's spouting nonsense here? Are you claiming that entire attributes are "data types" now? > > The odd one out is probably the IPv6-Route-Option-Preference in > > draft-lourdelet, which has an rfc4191 derived 2 bit signed integer. > No > > problem in changing that to a simple signed integer, while > restricting > > the values. > > RADIUS has no support for signed integers. See: > > http://tools.ietf.org/html/draft-ietf-radext-design-08 > > I suggest reading the document before posting any more confusion > about > data types in RADIUS. It describes the DeKok > data model, along with > supported and not-supported data types. ... -- to 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, 07 Oct 2009 13:01:55 +0000 Message-ID: <4ACC9125.2070206@deployingradius.com> Date: Wed, 07 Oct 2009 15:01:25 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" CC: Bernard Aboba , "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: IPv6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wojciech Dec (wdec) wrote: > So a number of points: Draft-lourdelet clearly defins NEW Attributes NOT > changing existing attributes and the draft does not propose anything for > which there isn't a precedent (see rfc2868, rfc3162). I think we're really talking about different things. I keep trying to explain that the draft is doing something *new*. You keep claiming it isn't. > Overall, thanks for educating me, but perhaps you should take a step > back: In draft-lourdelet we're defining the on-the-wire format of these > new attributes. The data-type used for internal bindings of these > attributes is an implementation detail, which you (and perhaps others) > appear to make a business of the Radext WG (it seems that while new to > Radext, I haven't been missing out on much fun after all). The "implementation detail" you're arguing about is discussed in the design guidelines document. It's something that comes up in this WG, and in others. Implementation details are relevant, and cannot be dismissed with a wave of the hand. > Now, even if that were justfiied, with a definition of "string" like the > one above you have no right to claim that a "string" data-type cannot be > used for sending an arbitrary sequence of 1-255 octets of/in whatever > encoding. I think you have a problem reading my messages. I didn't claim the "string" type wasn't suitable for sending arbitrary strings. I said that you couldn't have it both ways: (1) claim that it's an attribute with a strongly typed definition (tag + integer), and (2) claim that it's also an arbitrary sequence of octets. It's about consistency. I like it. You're not following it. >> Otherwise... please suggest how implementations can do the >> impossible, and encode these new attributes using a novel >> format, without adding a new encoding method. > > Uhm, for the IPv6-Prefix attribute one could have one of the following > abstract definitions (all of them with no new exotic data-types other > than those likely already used) > > struct IPv6-Prefix { uint8_t tag; uint8_t prefix-length; uint128_t > prefix; }; Please point out where the "struct" type is defined in the RADIUS specifications. You can't. It isn't defined anywhere. You invented it, and claimed that it can be used in RADIUS, and that it's just an "implementation detail". It's not. If this was Diameter, this would be possible. Diameter defines a grouped attribute, which can be used to group arbitrary other attributes (i.e. data types) into a "struct" like object. > May I suggest that once more you're confusing on-the-wire format with > internal data-type representation. Uh... the internal data types represent at *least* the on-the-wire format. If they didn't, the data types couldn't be encoded onto the wire. > It would seem that according to you > each attribute in Radius with some internal structure not seen > previoulsy is effectively a new data-type Don't blame me. That would appear to be the consensus of this WG, as written in the design guidelines document. > and that this needs to be > enforced by the Radius specs. I'll call these non-atomic-data-types to > differentiate from what I consider common atomic data-types that rely on > common types/units of data (unit 32, etc). It's from the perspective of > non-atomic-data-types that draft-lourdelet *may* indeed be seen to call > for something new. It "may* but *it doesn't have* because that's again > all up to *implementation detail*. Ignoring implementation details won't make them go away. This draft *gratuitously* introduces new data types where existing ones could be re-used. That's not an implementation detail: it's bad design. > All this shows how pointless is defining the protocol *and* such > non-atomic-data-type implementation specifics at the same time. The > protocol spec should not go into implementation specifics and your > argument around why it should be otherwise is rather unsubstatiated. Strange. I could have sworn I was writing messages explaining my position. Did you read them? RADIUS servers have historically been been driven by data dictionaries. See Section 2 of the design guidelines document. This isn't an "implementation detail". It is billions of dollars of equipment in hundreds of thousands of sites. Some implementations have simple dictionary support, others support complex dictionaries. But this "implementation detail" needs to be taken into account when writing new specifications. > Draft-ietf-radext-design-08.txt doesn't do better, if actually being > misguided in some of these aspects. I suggest that you post a separate review of the document. It's clear that you have valuable input which could make the document better. > It would help all if you could be a bit more constructive... By all means. Simple specifications that leverage existing implementations are good. Specifications that follow historical practices are usually a good idea, too. I am encouraging good practice. Part of this involves pointing out bad practices, and explaining why they're bad. If you think this is not constructive, I suggest you avoid peer review entirely. 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, 07 Oct 2009 12:23:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=1777; q=dns/txt; s=amsiport01001; t=1254918151; x=1256127751; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20IPv6|Date:=20Wed,=207=20Oct=202009=2014 :22:21=20+0200|Message-ID:=20|To:=20"David=20B.=20Ne lson"=20,=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20 quoted-printable|In-Reply-To:=20<30B10043-1F22-4AD6-8246- 2F80DFA081AE@elbrysnetworks.com>|References:=20=20=20=20=20<9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetw orks.com>=20<4ACB5A24.1000400@deployingradius.com>=20=20=20<4ACB 9EBB.9010304@deployingradius.com>=20=20<30B10043-1F2 2-4AD6-8246-2F80DFA081AE@elbrysnetworks.com>; bh=iuYpqn1D3EgmwxfStpiZM9wfpQ4EBEJegOQOOLK0Qds=; b=o16Kca36TJdUvxJMBzBK+5r6EckFk6M2pfVSV4uIOrL/aSxNx5zqFM2L 3s30wdrrZXVRF9vrZgfn9mILFiDKNfZ2AXfKqLA2RhLb4x0OTqKRfU3mb 73J1QPcdG8CEyMeRfHrTy7LCTxb6OXs/G7UOQHwTtwCaK2F813u01QufU k=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=wdec@cisco.com Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Date: Wed, 7 Oct 2009 14:22:21 +0200 Message-ID: Thread-Topic: IPv6 Thread-Index: AcpGzXc2JsOFHpNBQbmdU/TJ3dfUnwAeqIhQ From: "Wojciech Dec (wdec)" To: "David B. Nelson" , DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1777; t=1254918149; x=1255782149; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20IPv6 |Sender:=20; bh=iuYpqn1D3EgmwxfStpiZM9wfpQ4EBEJegOQOOLK0Qds=; b=AilQUvISKMqCEvURBNo6yDBFGqBoe8vK2SKEeQV+AHVCQ7NqQeyDYGeZq4 4rcptgpBRQe7pAdBZ/HmdXZOQA0+fve9P/CBaGWIDgH+vTdkrPoH+Lczl2vC ihJYNtF5+S; =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson > Sent: 06 October 2009 23:39 > To: radiusext@ops.ietf.org > Subject: Re: IPv6 >=20 >=20 > On Oct 6, 2009, at 5:14 PM, Wojciech Dec (wdec) wrote: >=20 > > That same RFC 2865, in section 5, states: > > > > string 1-253 octets containing binary data (values 0 through > > 255 decimal, inclusive). Strings of length zero (0) > > MUST NOT be sent; omit the entire attribute instead. > > > > With that, Ipv6 Prefix, Route options,=20 > Auth-IPv6-Prefix-User-ID, etc=20 > > would be pretty much covered by using the string term. >=20 > With all due respect, the String data type is just a string of =20 > undistinguished octets. While you may conceptually overlay=20 > it with a =20 > structure, i.e define sub-fields, that action creates a new=20 > data type. In other words, the String type is just a string.=20 > You may lament the fact that RADIUS, as defined in RFCs up=20 > through 2865, has no method to formally define structured=20 > data, but the fact is that it has none. Sure, that's fair. The point I was making is that with the string definition above, passing an IPv6 prefix (or anything else up to 255 bytes really) did not require any new data-type and in terms of say the IPv6-prefix. Furthermore rfc2868 provides plenty of precedent for structured attributes with "String", if one wants, eg Tunnel-Password. -Woj. >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 07 Oct 2009 12:09:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=7443; q=dns/txt; s=sjiport06001; t=1254917287; x=1256126887; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20IPv6|Date:=20Wed,=207=20Oct=202009=2014 :07:46=20+0200|Message-ID:=20|To:=20"Alan=20DeKok" =20|Cc:=20"Bernard=20Aboba"=20 ,=0D=0A=20=20=20=20=20=20=20 =20"David=20B.=20Nelson"=20, =0D=0A=20=20=20=20=20=20=20=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<4ACC5B0B.9060906@deployingradiu s.com>|References:=20=20 =20=20=20<9E1DAF16-40C5-4 A25-82D0-EEDB7561BA64@elbrysnetworks.com>=20<4ACB5A24.100 0400@deployingradius.com>=20=20=20<4ACB9EBB.9010304@deployingrad ius.com>=20=20<4ACBB7C1.2000900@deployingradius.com> =20=20<4ACC5B0B.9060906@deployingradius.com>; bh=GlK3jBdBRNkSit9us/JKNGHaMIYbYfvQOqQEAUqNqgE=; b=pRiaGP9dtvccjuPh3xyB35pXHVkOShDsJA2RV109J8rMG4DGIPBxKLKd bwZW76t8OXWC9e16nydxZtLaImo+ac2NSKsPJVeeIYmn89KurwyXGkCgF mgbrqViV+cwFXVChfi8+ejGPSOO6w3yRAqdFZ76UUYvqDjUAHjZVIM0SN U=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=wdec@cisco.com Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Date: Wed, 7 Oct 2009 14:07:46 +0200 Message-ID: Thread-Topic: IPv6 Thread-Index: AcpHLhiy+skUtrTYSymOv1L0eu5lqgACEvHw From: "Wojciech Dec (wdec)" To: "Alan DeKok" Cc: "Bernard Aboba" , "David B. Nelson" , DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7443; t=1254917286; x=1255781286; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20IPv6 |Sender:=20; bh=GlK3jBdBRNkSit9us/JKNGHaMIYbYfvQOqQEAUqNqgE=; b=cLjevWfgyAnFg1UhtMEJKbXOngCJUmQjNlgZew07jTy5CSZ7yxd27Zcw/5 kuCE96Y+PXOYBjPcxt7IPEXKuxkYQJRxZLSmj8Qq9fSPcfnJ+7F7n+jXaigb doYvuFnCep; =20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: 07 October 2009 11:11 > To: Wojciech Dec (wdec) > Cc: Bernard Aboba; David B. Nelson; radiusext@ops.ietf.org > Subject: Re: IPv6 >=20 > Wojciech Dec (wdec) wrote: > > Guess someone forgot to add a character encoding set=20 > limitation to the=20 > > definition of "string" above. Without it, any sequence of=20 > 1-253 octets=20 > > falls neatly under the "a string". >=20 > Is this a joke? >=20 > Here's a short explanation, as it's clear you are=20 > completely unfamiliar with RADIUS. >=20 > RADIUS attributes are typed. The list of types is small. =20 > Each type is statically defined in an RFC. RADIUS=20 > implementations use these definitions to determine how to=20 > manipulate the attributes (parse, print, wire-encode,=20 > wire-decode). The types cannot be changed, because they have=20 > existing definitions. Defining new encoding/decode means=20 > defining new types... because you can't encode the OLD type=20 > in a NEW way, and you can't encode the NEW type in the OLD way. So a number of points: Draft-lourdelet clearly defins NEW Attributes NOT changing existing attributes and the draft does not propose anything for which there isn't a precedent (see rfc2868, rfc3162).=20 Overall, thanks for educating me, but perhaps you should take a step back: In draft-lourdelet we're defining the on-the-wire format of these new attributes. The data-type used for internal bindings of these attributes is an implementation detail, which you (and perhaps others) appear to make a business of the Radext WG (it seems that while new to Radext, I haven't been missing out on much fun after all).=20 Now, even if that were justfiied, with a definition of "string" like the one above you have no right to claim that a "string" data-type cannot be used for sending an arbitrary sequence of 1-255 octets of/in whatever encoding. You're clearly basing your point on non-atomic data-types, which I comment on further below... >=20 > Otherwise... please suggest how implementations can do the=20 > impossible, and encode these new attributes using a novel=20 > format, without adding a new encoding method. Uhm, for the IPv6-Prefix attribute one could have one of the following abstract definitions (all of them with no new exotic data-types other than those likely already used) struct IPv6-Prefix { uint8_t tag; uint8_t prefix-length; uint128_t prefix; }; OR struct IPv6-Prefix { uint8_t tag; uint8_t prefix-length; string_t prefix; }; Etc. >=20 > > That said, rfc 3162 clearly already > > has a "call it whatever you want" data-type for=20 > "Framed-IPv6-Prefix",=20 > > which happens to be the same type of data as in the IPv6-Prefix in=20 > > draft-lourdelet. >=20 > Absolute nonsense. Framed-IPv6-Prefix has a different=20 > on-the-wire format than IPv6-prefix. Therefore, they are=20 > different data types. May I suggest that once more you're confusing on-the-wire format with internal data-type representation. It would seem that according to you each attribute in Radius with some internal structure not seen previoulsy is effectively a new data-type and that this needs to be enforced by the Radius specs. I'll call these non-atomic-data-types to differentiate from what I consider common atomic data-types that rely on common types/units of data (unit 32, etc). It's from the perspective of non-atomic-data-types that draft-lourdelet *may* indeed be seen to call for something new. It "may* but *it doesn't have* because that's again all up to *implementation detail*. I'll use the following example to illustrate.=20 RFC3162 defines the framed-ipv6-attribute, and so presumably an implementation also has a pseudo-data-type to support it: Framed-IPv6-Prefix 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Implementation wise, the difference between the above and the IPv6-Prefix attribute in draft-lauderlet is the semantic of the Reserved field vs the Tag field. If, when coding the psudeo-data-type one chose to have the Reserved field modelled as a unit8 then it would be the same pseudo-data-type that would apply to draft-lourdelet. If a different choice was made, then a new psudo-data-type need to be cast. Coincidentally, the Radius spec doesn't say which data-type should the Reserved field be cast as. All this shows how pointless is defining the protocol *and* such non-atomic-data-type implementation specifics at the same time. The protocol spec should not go into implementation specifics and your argument around why it should be otherwise is rather unsubstatiated. Draft-ietf-radext-design-08.txt doesn't do better, if actually being misguided in some of these aspects. It would help all if you could be a bit more constructive...=20 -Woj. >=20 > > The odd one out is probably the IPv6-Route-Option-Preference in=20 > > draft-lourdelet, which has an rfc4191 derived 2 bit signed=20 > integer. No=20 > > problem in changing that to a simple signed integer, while=20 > restricting=20 > > the values. >=20 > RADIUS has no support for signed integers. See: >=20 > http://tools.ietf.org/html/draft-ietf-radext-design-08 >=20 > I suggest reading the document before posting any more=20 > confusion about data types in RADIUS. It describes the=20 > RADIUS data model, along with supported and not-supported data types. >=20 > > I'm still finding the issue rather nonsensical. Do you=20 > really mean to=20 > > say that the addition of an attribute, the tag, requires the=20 > > re-definition of each and every data type that radius has, eg "the=20 > > tagged 64-bit unsigned integer", etc? That's bizzarre at=20 > best... Why? >=20 > Because that's how RADIUS works. DHCP works the same way. =20 > As does DNS. As does SNMP. As does NTP. The list goes on... >=20 > In fact, *any* protocol that has bit-packing of data (as=20 > opposed to text encoding like FTP or SMTP) has pretty much=20 > fixed data types. You can't change the interpretation of a=20 > "32-bit integer", because its meaning is already defined. >=20 > Try updating your C compiler to interpret "uint32_t" as=20 > "struct foo". > See how many third-party programs compile without error. =20 > Those programs make assumptions base on the definitions of=20 > the data types. Changing the data types means that the=20 > assumptions are no longer valid, and the programs no longer=20 > work as intended. >=20 > I'm surprised that this behavior is novel to you. Binary=20 > packed protocols have worked this way for a *long* time. >=20 > Alan DeKok. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 07 Oct 2009 09:11:43 +0000 Message-ID: <4ACC5B0B.9060906@deployingradius.com> Date: Wed, 07 Oct 2009 11:10:35 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" CC: Bernard Aboba , "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: IPv6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wojciech Dec (wdec) wrote: > Guess someone forgot to add a character encoding set limitation to the > definition of "string" above. Without it, any sequence of 1-253 octets > falls neatly under the "a string". Is this a joke? Here's a short explanation, as it's clear you are completely unfamiliar with RADIUS. RADIUS attributes are typed. The list of types is small. Each type is statically defined in an RFC. RADIUS implementations use these definitions to determine how to manipulate the attributes (parse, print, wire-encode, wire-decode). The types cannot be changed, because they have existing definitions. Defining new encoding/decode means defining new types... because you can't encode the OLD type in a NEW way, and you can't encode the NEW type in the OLD way. Otherwise... please suggest how implementations can do the impossible, and encode these new attributes using a novel format, without adding a new encoding method. > That said, rfc 3162 clearly already > has a "call it whatever you want" data-type for "Framed-IPv6-Prefix", > which happens to be the same type of data as in the IPv6-Prefix in > draft-lourdelet. Absolute nonsense. Framed-IPv6-Prefix has a different on-the-wire format than IPv6-prefix. Therefore, they are different data types. > The odd one out is probably the IPv6-Route-Option-Preference in > draft-lourdelet, which has an rfc4191 derived 2 bit signed integer. No > problem in changing that to a simple signed integer, while restricting > the values. RADIUS has no support for signed integers. See: http://tools.ietf.org/html/draft-ietf-radext-design-08 I suggest reading the document before posting any more confusion about data types in RADIUS. It describes the RADIUS data model, along with supported and not-supported data types. > I'm still finding the issue rather nonsensical. Do you really mean to > say that the addition of an attribute, the tag, requires the > re-definition of each and every data type that radius has, eg "the > tagged 64-bit unsigned integer", etc? That's bizzarre at best... Why? Because that's how RADIUS works. DHCP works the same way. As does DNS. As does SNMP. As does NTP. The list goes on... In fact, *any* protocol that has bit-packing of data (as opposed to text encoding like FTP or SMTP) has pretty much fixed data types. You can't change the interpretation of a "32-bit integer", because its meaning is already defined. Try updating your C compiler to interpret "uint32_t" as "struct foo". See how many third-party programs compile without error. Those programs make assumptions base on the definitions of the data types. Changing the data types means that the assumptions are no longer valid, and the programs no longer work as intended. I'm surprised that this behavior is novel to you. Binary packed protocols have worked this way for a *long* time. 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, 07 Oct 2009 07:55:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=2586; q=dns/txt; s=amsiport01001; t=1254902011; x=1256111611; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20IPv6|Date:=20Wed,=207=20Oct=202009=2009 :53:25=20+0200|Message-ID:=20|To:=20"Alan=20DeKok" =20|Cc:=20"Bernard=20Aboba"=20 ,=0D=0A=20=20=20=20=20=20=20 =20"David=20B.=20Nelson"=20, =0D=0A=20=20=20=20=20=20=20=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<4ACBB7C1.2000900@deployingradiu s.com>|References:=20=20 =20=20=20<9E1DAF16-40C5-4 A25-82D0-EEDB7561BA64@elbrysnetworks.com>=20<4ACB5A24.100 0400@deployingradius.com>=20=20=20<4ACB9EBB.9010304@deployingrad ius.com>=20=20<4ACBB7C1.2000900@deployingradius.com>; bh=lE5ljsZcIN38j3qem/6paiAb7AmspO/c4kbN3UPeUzw=; b=Jeo2F/ZCpw4s4KOq/+EGUrM53jKzsFFPYv7jsP0xxV5fkycdKarvck6x GJUMkD2aM0gfQIeRnoRJljlQtdjrYQQd4eeoCnD5nJk01GL5wI/xQLv9I 6bZ0aEUGbo9jtwQVeYIG3rK7kibhwV0Z480Gg1zRhs0Be/5rd55ZHPcaz E=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=wdec@cisco.com Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Date: Wed, 7 Oct 2009 09:53:25 +0200 Message-ID: Thread-Topic: IPv6 Thread-Index: AcpGzLZZUU3YYe+NQrudLX8CLV7L4gAUuOfQ From: "Wojciech Dec (wdec)" To: "Alan DeKok" Cc: "Bernard Aboba" , "David B. Nelson" , DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2586; t=1254902009; x=1255766009; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20IPv6 |Sender:=20; bh=lE5ljsZcIN38j3qem/6paiAb7AmspO/c4kbN3UPeUzw=; b=Hwylk6vIiTaAWqoEtDxq7l3IKGYts++i0EshPM2v6TlxW1++txlIzi0tvK 0RTT5HIXQj96E79Giuo2opV0F558qG7SDemNGS1667WhxdSjM/GFV82yNEN7 rF3eJ58Eej; =20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: 06 October 2009 23:34 > To: Wojciech Dec (wdec) > Cc: Bernard Aboba; David B. Nelson; radiusext@ops.ietf.org > Subject: Re: IPv6 >=20 > Wojciech Dec (wdec) wrote: > > That same RFC 2865, in section 5, states: > >=20 > > string 1-253 octets containing binary data (values=20 > 0 through > > 255 decimal, inclusive). Strings of length zero (0) > > MUST NOT be sent; omit the entire attribute instead. > >=20 > > With that, Ipv6 Prefix, Route options,=20 > Auth-IPv6-Prefix-User-ID, etc=20 > > would be pretty much covered by using the string term. >=20 > The document says that attributes are of type "string", and=20 > not IPv6 prefix or integer. Re-defining "32-bit integer" to=20 > mean "string" is an argument from absurdity. Guess someone forgot to add a character encoding set limitation to the definition of "string" above. Without it, any sequence of 1-253 octets falls neatly under the "a string". That said, rfc 3162 clearly already has a "call it whatever you want" data-type for "Framed-IPv6-Prefix", which happens to be the same type of data as in the IPv6-Prefix in draft-lourdelet. Re Auth-IPv6-Prefix-User-ID, changing it to a string would definitely work (and I see no problem in that). The odd one out is probably the IPv6-Route-Option-Preference in draft-lourdelet, which has an rfc4191 derived 2 bit signed integer. No problem in changing that to a simple signed integer, while restricting the values. =20 >=20 > >> 3.3 IPv6-Prefix > >> Defines an 8-bit tag followed by a 64-bit integer. There are NO=20 > >> existing attributes that are tagged 64-bit integers. > >> This data type is new. > >=20 > > Are unsigned 64-bit integers really a new thing to Radius?=20 >=20 > You missed the word "tagged" in the sentence above. That=20 > makes my comment meaningful, instead of nonsensical. I'm still finding the issue rather nonsensical. Do you really mean to say that the addition of an attribute, the tag, requires the re-definition of each and every data type that radius has, eg "the tagged 64-bit unsigned integer", etc? That's bizzarre at best... Why? -Woj. >=20 > > That would > > seemingly contradict what's presented as de facto in > > http://tools.ietf.org/html/draft-ietf-radext-design-08#section-2.1.1 >=20 > Only if you take a discussion about "tagged" attributes,=20 > and ignore key words like "tagged". >=20 > Alan DeKok. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 06 Oct 2009 21:39:11 +0000 Message-Id: <30B10043-1F22-4AD6-8246-2F80DFA081AE@elbrysnetworks.com> From: "David B. Nelson" To: radiusext@ops.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: IPv6 Date: Tue, 6 Oct 2009 17:38:50 -0400 On Oct 6, 2009, at 5:14 PM, Wojciech Dec (wdec) wrote: > That same RFC 2865, in section 5, states: > > string 1-253 octets containing binary data (values 0 through > 255 decimal, inclusive). Strings of length zero (0) > MUST NOT be sent; omit the entire attribute instead. > > With that, Ipv6 Prefix, Route options, Auth-IPv6-Prefix-User-ID, etc > would be pretty much covered by using the string term. With all due respect, the String data type is just a string of undistinguished octets. While you may conceptually overlay it with a structure, i.e define sub-fields, that action creates a new data type. In other words, the String type is just a string. You may lament the fact that RADIUS, as defined in RFCs up through 2865, has no method to formally define structured data, but the fact is that it has none. -- to 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, 06 Oct 2009 21:34:21 +0000 Message-ID: <4ACBB7C1.2000900@deployingradius.com> Date: Tue, 06 Oct 2009 23:33:53 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" CC: Bernard Aboba , "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: IPv6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wojciech Dec (wdec) wrote: > That same RFC 2865, in section 5, states: > > string 1-253 octets containing binary data (values 0 through > 255 decimal, inclusive). Strings of length zero (0) > MUST NOT be sent; omit the entire attribute instead. > > With that, Ipv6 Prefix, Route options, Auth-IPv6-Prefix-User-ID, etc > would be pretty much covered by using the string term. The document says that attributes are of type "string", and not IPv6 prefix or integer. Re-defining "32-bit integer" to mean "string" is an argument from absurdity. >> 3.3 IPv6-Prefix >> Defines an 8-bit tag followed by a 64-bit integer. There >> are NO existing attributes that are tagged 64-bit integers. >> This data type is new. > > Are unsigned 64-bit integers really a new thing to Radius? You missed the word "tagged" in the sentence above. That makes my comment meaningful, instead of nonsensical. > That would > seemingly contradict what's presented as de facto in > http://tools.ietf.org/html/draft-ietf-radext-design-08#section-2.1.1 Only if you take a discussion about "tagged" attributes, and ignore key words like "tagged". Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 06 Oct 2009 21:15:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=2058; q=dns/txt; s=amsiport01001; t=1254863676; x=1256073276; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20IPv6|Date:=20Tue,=206=20Oct=202009=2023 :14:11=20+0200|Message-ID:=20|To:=20"Alan=20DeKok" =20|Cc:=20"Bernard=20Aboba"=20 ,=0D=0A=20=20=20=20=20=20=20 =20"David=20B.=20Nelson"=20, =0D=0A=20=20=20=20=20=20=20=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<4ACB9EBB.9010304@deployingradiu s.com>|References:=20=20 =20=20=20<9E1DAF16-40C5-4 A25-82D0-EEDB7561BA64@elbrysnetworks.com>=20<4ACB5A24.100 0400@deployingradius.com>=20=20=20<4ACB9EBB.9010304@deployingrad ius.com>; bh=wjW6yQkDaVzx5/wX1Pz5CSxV9cpBpKuQUA3k5O9iXA0=; b=e1V31N3A6erU0NjthdzXKRGHEPjTYfK+eMxGaTu3KUvV45Ot17vdtCQb VQyUodFhVr/JzZhfM1OEJ7bC9vBWRX/2Kf8hVp/37kTZhtj9jxUwH2KoD YhwQRQy0jMod2U06RB+pMsg/M3TrM0Y9pLfcnO5QkPRW9Jj58qHMWwsny 0=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=wdec@cisco.com Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Date: Tue, 6 Oct 2009 23:14:11 +0200 Message-ID: Thread-Topic: IPv6 Thread-Index: AcpGvdYH5mXEhoIYSCyy4FaarcDu0gACGGLA From: "Wojciech Dec (wdec)" To: "Alan DeKok" Cc: "Bernard Aboba" , "David B. Nelson" , DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2058; t=1254863674; x=1255727674; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20IPv6 |Sender:=20; bh=wjW6yQkDaVzx5/wX1Pz5CSxV9cpBpKuQUA3k5O9iXA0=; b=H0CGJhDWE+R7CaQmO2TX68IYYOoKr+aKXvdpsJSZ8kWaXJIdUGph22PvZS doyIpNC3BBZMdDe7INYHsJ03Hw+nuqrtuCWqVIh5GxIgjiNyKbr6h1HI4+Kn Eu9xPLL07N; =20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: 06 October 2009 21:47 > To: Wojciech Dec (wdec) > Cc: Bernard Aboba; David B. Nelson; radiusext@ops.ietf.org > Subject: Re: IPv6 >=20 > Wojciech Dec (wdec) wrote: > > Woj> Indeed... What's the IPv6 document being referred=20 > to here? If > > it happens to be draft-lourdelet-radext-ipv6-access,=20 > then it does > > not define any new tagging scheme. >=20 > Uh... have you compared it to RFC 2868? That same RFC 2865, in section 5, states: string 1-253 octets containing binary data (values 0 through 255 decimal, inclusive). Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. With that, Ipv6 Prefix, Route options, Auth-IPv6-Prefix-User-ID, etc would be pretty much covered by using the string term. >=20 > 3.3 IPv6-Prefix >=20 > Defines an IPv6 prefix with a tag. There are NO existing=20 > tagged IPv6 attributes. RFC 2868 defines tagged integers and=20 > strings *only*. This data type is new. >=20 > 3.5 IPv6-Route-Option-Lifetime >=20 > Defines an 8-bit tag, followed by a 32-bit integer. RFC=20 > 2868 defines a 32-bit integer where the 8-bit tag over-writes=20 > the highest 8 bit of the integer. This data type is new. >=20 > 3.6 and 3.7 have the same issue. >=20 > 3.8. Auth-IPv6-Prefix-User-ID >=20 > Defines an 8-bit tag followed by a 64-bit integer. There=20 > are NO existing attributes that are tagged 64-bit integers. =20 > This data type is new. Are unsigned 64-bit integers really a new thing to Radius? That would seemingly contradict what's presented as de facto in http://tools.ietf.org/html/draft-ietf-radext-design-08#section-2.1.1 -Woj. >=20 >=20 > This draft defines a number of new tagged data types which=20 > are not previously used in any RFC, or on any vendor=20 > equipment, or in any specification from another standards body. >=20 > Alan DeKok. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 06 Oct 2009 19:47:58 +0000 Message-ID: <4ACB9EBB.9010304@deployingradius.com> Date: Tue, 06 Oct 2009 21:47:07 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Wojciech Dec (wdec)" CC: Bernard Aboba , "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: IPv6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wojciech Dec (wdec) wrote: > Woj> Indeed... What's the IPv6 document being referred to here? If > it happens to be draft-lourdelet-radext-ipv6-access, then it does > not define any new tagging scheme. Uh... have you compared it to RFC 2868? 3.3 IPv6-Prefix Defines an IPv6 prefix with a tag. There are NO existing tagged IPv6 attributes. RFC 2868 defines tagged integers and strings *only*. This data type is new. 3.5 IPv6-Route-Option-Lifetime Defines an 8-bit tag, followed by a 32-bit integer. RFC 2868 defines a 32-bit integer where the 8-bit tag over-writes the highest 8 bit of the integer. This data type is new. 3.6 and 3.7 have the same issue. 3.8. Auth-IPv6-Prefix-User-ID Defines an 8-bit tag followed by a 64-bit integer. There are NO existing attributes that are tagged 64-bit integers. This data type is new. This draft defines a number of new tagged data types which are not previously used in any RFC, or on any vendor equipment, or in any specification from another standards body. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 06 Oct 2009 16:55:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=3560; q=dns/txt; s=amsiport01001; t=1254848094; x=1256057694; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Wojciech=20Dec=20(wdec)"=20 |Subject:=20RE:=20IPv6|Date:=20Tue,=206=20Oct=202009=2018 :54:46=20+0200|Message-ID:=20|To:=20"Bernard=20Aboba "=20,=0D=0A=20=20=20=20=20=20 =20=20"David=20B.=20Nelson"=20,=0D=0A=20=20=20=20=20=20=20=20"Alan=20DeKok"=20|Cc:=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20=20=20=20 =20<9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.c om>=20<4ACB5A24.1000400@deployingradius.com>=20; bh=wq4WmOvXymyLivyiJguu+4CxmdwmLxwlxexaCMgv/lo=; b=VPPP6/lC4jUpiC/gFKf/AsTM5tLlwrfGYkG3bg44W0GF4J6aEc4ei3KV 07r33mbPPK9d/U8Uku0vGLVKFYk90nym46T4DMUPAdaqFut5aguMVOKPx kDf4I/KvAwZYD1C+6qBC+4SWE8o4LoNLXLRHhTmLDlp+C9KMpRkzbbCpe E=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (partially verified [3499 bytes] [TEST]) header.i=wdec@cisco.com Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA46A5.B936BA37" Subject: RE: IPv6 Date: Tue, 6 Oct 2009 18:54:46 +0200 Message-ID: Thread-Topic: IPv6 Thread-Index: AcpGmimNmHL4XJmDSkmkFVc1VhiTrAAAUplQ From: "Wojciech Dec (wdec)" To: "Bernard Aboba" , "David B. Nelson" , "Alan DeKok" Cc: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3499; t=1254848092; x=1255712092; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20IPv6 |Sender:=20; bh=A+sqFbd66jmbYD//pVVaIN0cvpjhaXTb9lkcY8AtQpE=; b=YbKMD421H8Z5nGux28eNrcNy6B9a5JvhDLrkCQrGPIST8awm5fO86cr3cC Oe57ZXFq/atIL211BN8hy+YLhTqJ/i7vPgyDrHpmM2oOPw42M38d19xTUAIo ctgN+i/qLW; This is a multi-part message in MIME format. ------_=_NextPart_001_01CA46A5.B936BA37 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: 06 October 2009 17:31 To: David B. Nelson; Alan DeKok Cc: radiusext@ops.ietf.org Subject: RE: IPv6 =09 =09 > True. OTOH, I don't see any need to be coy about "future documents"=20 > when we know exactly what document we're talking about and exactly=20 > what it recommends. Often the best approach is the most=20 > straightforward approach. =09 Do we know exactly which document we're talking about? Both the IPv6 document and Extended Attributes define tagging schemes. =20 =20 Woj> Indeed... What's the IPv6 document being referred to here? If it happens to be draft-lourdelet-radext-ipv6-access, then it does not define any new tagging scheme. =09 =09 - Woj.=20 =09 =09 ------_=_NextPart_001_01CA46A5.B936BA37 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: 06 October 2009 17:31
To: David B. = Nelson;=20 Alan DeKok
Cc: radiusext@ops.ietf.org
Subject: RE: = IPv6
 
Woj> = Indeed... What's=20 the IPv6 document being referred to here? If it happens to be=20 draft-lourdelet-radext-ipv6-access, then it does not define any new = tagging=20 scheme.
- Woj. 

------_=_NextPart_001_01CA46A5.B936BA37-- -- to 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, 06 Oct 2009 15:31:58 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_41e262d3-b06b-40b9-999e-c137d002c02b_" From: Bernard Aboba To: "David B. Nelson" , Alan DeKok CC: "radiusext@ops.ietf.org" Subject: RE: IPv6 Date: Tue, 6 Oct 2009 08:31:21 -0700 <4A71C395-DEAB-41C0-A94F-09A68A0A28D5@elbrysnetworks.com> MIME-Version: 1.0 --_41e262d3-b06b-40b9-999e-c137d002c02b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > True. OTOH=2C I don't see any need to be coy about "future documents" =20 > when we know exactly what document we're talking about and exactly =20 > what it recommends. Often the best approach is the most =20 > straightforward approach. Do we know exactly which document we're talking about? Both the IPv6 document and Extended Attributes define tagging schemes.=20 = --_41e262d3-b06b-40b9-999e-c137d002c02b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B True. OTOH=2C I don't see any need to be coy about "future docu= ments"
>=3B when we know exactly what document we're talking about a= nd exactly
>=3B what it recommends. Often the best approach is the = most
>=3B straightforward approach.

Do we know exactly which = document we're talking about? =3B Both the
IPv6 document and Extende= d Attributes define tagging schemes.

= --_41e262d3-b06b-40b9-999e-c137d002c02b_-- -- to 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, 06 Oct 2009 14:59:38 +0000 Cc: radiusext@ops.ietf.org Message-Id: <4A71C395-DEAB-41C0-A94F-09A68A0A28D5@elbrysnetworks.com> From: "David B. Nelson" To: Alan DeKok Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: IPv6 Date: Tue, 6 Oct 2009 10:59:17 -0400 On Oct 6, 2009, at 10:54 AM, Alan DeKok wrote: > ...I don't see a need to reference future documents, when those > documents can simply state that they update this one. True. OTOH, I don't see any need to be coy about "future documents" when we know exactly what document we're talking about and exactly what it recommends. Often the best approach is the most straightforward approach. -- to 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, 06 Oct 2009 14:54:59 +0000 Message-ID: <4ACB5A24.1000400@deployingradius.com> Date: Tue, 06 Oct 2009 16:54:28 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: IPv6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > All of this dancing around, simply to avoid a non-normative reference to > the RADIUS Extended Attributes document? Why? It doesn't matter too much to me. But I don't see a need to reference future documents, when those documents can simply state that they update this one. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 06 Oct 2009 14:43:33 +0000 Message-Id: <9E1DAF16-40C5-4A25-82D0-EEDB7561BA64@elbrysnetworks.com> From: "David B. Nelson" To: radiusext@ops.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: IPv6 Date: Tue, 6 Oct 2009 10:42:51 -0400 On Oct 5, 2009, at 9:18 PM, Bernard Aboba wrote: > > It should say what's bad about the current tags, and leave it to > later > > documents to decide how to fix them. > > One approach might be to say just that: > > "For these reasons, the tagging scheme described in RFC 2868 is > not suitable for use as a generic grouping mechanism. Further > guidance in this area is left to future documents." All of this dancing around, simply to avoid a non-normative reference to the RADIUS Extended Attributes document? Why? -- to 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, 06 Oct 2009 14:29:54 +0000 Message-ID: <4ACB543A.3010904@deployingradius.com> Date: Tue, 06 Oct 2009 16:29:14 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: Jari Arkko , "dromasca@avaya.com" , gdweber@avaya.com, "David B. Nelson" , "radiusext@ops.ietf.org" Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > How about this? > > "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. The most interoperable way to address these > issues is for the vendor or SDO to request allocation of multiple > Vendor identifiers. > > However, instead of doing this, vendors have defined the following > non-standard VSA formats:" Looks good to me. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 06 Oct 2009 14:28:04 +0000 Message-ID: <4ACB53CB.2000606@deployingradius.com> Date: Tue, 06 Oct 2009 16:27:23 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: Jari Arkko , "dromasca@avaya.com" , gdweber@avaya.com, "David B. Nelson" , "radiusext@ops.ietf.org" Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > How about this? > > All VSA schemes that do not follow the [RFC2865] recommendations > are NOT RECOMMENDED since these formats will typically not be > implementable without RADIUS server code changes. This includes all > the above formats, as well as Vendor types of more than 8 bits, vendor > lengths of less than 8 bits, vendor lengths of more than 8 bits and > Vendor-Specific contents that are not in Type-Length-Value format. Looks good to me. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 06 Oct 2009 14:23:12 +0000 Message-ID: <4ACB529A.50702@deployingradius.com> Date: Tue, 06 Oct 2009 16:22:18 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: IPv6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >> It should say what's bad about the current tags, and leave it to later >> documents to decide how to fix them. > > One approach might be to say just that: > > "For these reasons, the tagging scheme described in RFC 2868 is > not suitable for use as a generic grouping mechanism. Further > guidance in this area is left to future documents." Sounds good to me. I'll see if I can rev the document this week. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 06 Oct 2009 01:19:32 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_3b3aeb65-c11f-4af3-ae9c-8e0a3b08d4bd_" From: Bernard Aboba To: Alan DeKok , "radiusext@ops.ietf.org" Subject: RE: IPv6 Date: Mon, 5 Oct 2009 18:18:45 -0700 <4ACA7496.60208@deployingradius.com> MIME-Version: 1.0 --_3b3aeb65-c11f-4af3-ae9c-8e0a3b08d4bd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It should say what's bad about the current tags=2C and leave it to late= r > documents to decide how to fix them. One approach might be to say just that: "For these reasons=2C the tagging scheme described in RFC 2868 is not suitable for use as a generic grouping mechanism. Further guidance in this area is left to future documents." = --_3b3aeb65-c11f-4af3-ae9c-8e0a3b08d4bd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B It should say what's bad about the current tags=2C and leave it to= later
>=3B documents to decide how to fix them.

One approach m= ight be to say just that:

"For these reasons=2C the tagging scheme d= escribed in RFC 2868 is
not suitable for use as a generic grouping mecha= nism. =3B =3B Further
guidance in this area is left to future do= cuments."
= --_3b3aeb65-c11f-4af3-ae9c-8e0a3b08d4bd_-- -- to 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, 05 Oct 2009 22:35:36 +0000 Message-ID: <4ACA7496.60208@deployingradius.com> Date: Tue, 06 Oct 2009 00:35:02 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: IPv6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Given that existing tagged types are not suitable for generic use, there > doesn't seem to be an alternative to a new data type. The question is > what this document can or should say about that. I agree with David. It should stick to recommended practices, and not define new standards. > While the Extended Attributes document is probably the right place to > deal with this issue in depth, the question is whether something can > be said in the Design Guidelines document, and if so, what. It should say what's bad about the current tags, and leave it to later documents to decide how to fix them. 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, 05 Oct 2009 22:00:52 +0000 Message-Id: From: "David B. Nelson" To: radiusext@ops.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: IPv6 Date: Mon, 5 Oct 2009 17:59:49 -0400 On Oct 5, 2009, at 1:50 PM, Bernard Aboba wrote: > While the Extended Attributes document is probably the right place to > deal with this issue in depth, the question is whether something can > be said in the Design Guidelines document, and if so, what. This sounds like we're coming full circle. I think where we started was with the Design Guidelines for "RADIUS Classic" directing developers who wanted to make effective use tagging to the Extended RADIUS Attributes draft / RFC. -- to 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, 05 Oct 2009 17:51:33 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_29c902fa-2703-4a91-a23a-e44cdffed479_" From: Bernard Aboba To: Alan DeKok CC: "radiusext@ops.ietf.org" Subject: RE: IPv6 Date: Mon, 5 Oct 2009 10:50:46 -0700 <4ACA0A86.3020303@deployingradius.com> MIME-Version: 1.0 --_29c902fa-2703-4a91-a23a-e44cdffed479_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > For these reasons=2C the tagging scheme described in RFC 2868 is > > not suitable for use as a generic grouping mechanism. Where > > a tagging scheme is required for use with arbitrary data types=2C > > it is RECOMMENDED that: > > =20 > > * A fixed tagging field be used so as to remove potential > > interoperability issues associated with determining whether > > an optional tag is present=3B=20 > >=20 > > * The design make no assumption about the content of the > > data within tagged attributes." =20 >=20 > Hmm... OK. This sounds an awful lot like making recommendations on > later RADEXT documents. I'm not sure that's useful. Assuming that the first sentence makes sense=2C the next question that a reader will ask is "What is the alternative?" =20 > The alternative is to interpret this as recommending a new data type: > tagged attributes with a format defined outside of RADEXT. I'm not sure > I like that much better. Given that existing tagged types are not suitable for generic use=2C there doesn't seem to be an alternative to a new data type. The question is what this document can or should say about that.=20 While the Extended Attributes document is probably the right place to deal with this issue in depth=2C the question is whether something can be said in the Design Guidelines document=2C and if so=2C what.=20 = --_29c902fa-2703-4a91-a23a-e44cdffed479_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B >=3B For these reasons=2C the tagging scheme described in R= FC 2868 is
>=3B >=3B not suitable for use as a generic grouping m= echanism. Where
>=3B >=3B a tagging scheme is required for use w= ith arbitrary data types=2C
>=3B >=3B it is RECOMMENDED that:
= >=3B >=3B
>=3B >=3B * A fixed tagging field be us= ed so as to remove potential
>=3B >=3B interoperability is= sues associated with determining whether
>=3B >=3B an opti= onal tag is present=3B
>=3B >=3B
>=3B >=3B * The de= sign make no assumption about the content of the
>=3B >=3B = data within tagged attributes."
>=3B
>=3B Hmm... OK. This = sounds an awful lot like making recommendations on
>=3B later RADEXT d= ocuments. I'm not sure that's useful.

Assuming that the first sente= nce makes sense=2C the next question that
a reader will ask is "What is = the alternative?" =3B

>=3B The alternative is to interpret = this as recommending a new data type:
>=3B tagged attributes with a fo= rmat defined outside of RADEXT. I'm not sure
>=3B I like that much be= tter.

Given that existing tagged types are not suitable for generic = use=2C =3B there
doesn't seem to be an alternative to a new data typ= e. =3B The question is
what this document can or should say about th= at.

While the Extended Attributes document is probably the right pl= ace to
deal with this issue in depth=2C the question is whether somethin= g can
be said in the Design Guidelines document=2C and if so=2C what.

= --_29c902fa-2703-4a91-a23a-e44cdffed479_-- -- to 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, 05 Oct 2009 15:03:35 +0000 Message-ID: <4ACA0A86.3020303@deployingradius.com> Date: Mon, 05 Oct 2009 17:02:30 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: IPv6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > How about this? ... > For these reasons, the tagging scheme described in RFC 2868 is > not suitable for use as a generic grouping mechanism. Where > a tagging scheme is required for use with arbitrary data types, > it is RECOMMENDED that: > > * A fixed tagging field be used so as to remove potential > interoperability issues associated with determining whether > an optional tag is present; > > * The design make no assumption about the content of the > data within tagged attributes." Hmm... OK. This sounds an awful lot like making recommendations on later RADEXT documents. I'm not sure that's useful. The alternative is to interpret this as recommending a new data type: tagged attributes with a format defined outside of RADEXT. I'm not sure I like that much better. 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, 04 Oct 2009 19:06:23 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_67fc6fee-6279-4b28-a0e0-be3aa7fed4fc_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Draft updates and slides Date: Sun, 4 Oct 2009 12:05:21 -0700 MIME-Version: 1.0 --_67fc6fee-6279-4b28-a0e0-be3aa7fed4fc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In advance of the Virtual Interim meeting on October 13=2C we are asking fo= r authors to update their drafts and send in their slides=2C so that we can make them available for m= eeting participants.=20 Please submit updates to your drafts as well as slides by October 11=2C 200= 9.=20 = --_67fc6fee-6279-4b28-a0e0-be3aa7fed4fc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In advance of the Virtual Interim meeting on October 13=2C we are asking fo= r authors to update their
drafts and send in their slides=2C so that we = can make them available for meeting participants.

Please submit upd= ates to your drafts as well as slides by October 11=2C 2009.



= --_67fc6fee-6279-4b28-a0e0-be3aa7fed4fc_-- -- to 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, 02 Oct 2009 10:33:29 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: Need for WebEx at IETF 76 Date: Fri, 2 Oct 2009 12:32:06 +0200 Message-ID: Thread-Topic: Need for WebEx at IETF 76 thread-index: AcpC62cK+Vp4d9meScWEUESp+2mT7QAXlQ/Q From: "Romascanu, Dan (Dan)" To: , "OPS Area (E-mail)" , "radext mailing list" , , , , "IETF IPFIX Working Group" =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Alexa Morris Sent: Friday, October 02, 2009 1:03 AM To: The IESG Subject: Need for WebEx at IETF 76 I'd like to know if any of you might need to use WebEx for any working group sessions taking place at IETF 76. Please note that at present I'm looking more for a "I need WebEx because one of my key presenters will not be physically present"=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:

> True. OTOH, I don't see any need to be coy about "future = documents"
> when we know exactly what document we're talking = about and=20 exactly
> what it recommends. Often the best approach is the = most=20
> straightforward approach.

Do we know exactly which = document=20 we're talking about?  Both the
IPv6 document and Extended = Attributes=20 define tagging schemes.  
Bernard,