From owner-radiusext@ops.ietf.org Mon Nov 2 08:13: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 EE9F228C121 for ; Mon, 2 Nov 2009 08:13:12 -0800 (PST) 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 Vuf8RTS3DqQv for ; Mon, 2 Nov 2009 08:13:12 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D1D4C3A6A47 for ; Mon, 2 Nov 2009 08:13:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N4zSm-000MWA-7J for radiusext-data0@psg.com; Mon, 02 Nov 2009 16:09:00 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N4zSi-000MUg-E3 for radiusext@ops.ietf.org; Mon, 02 Nov 2009 16:08:56 +0000 Received: from static-68-179-118-158.ptr.terago.net (static-68-179-118-158.ptr.terago.net [68.179.118.158]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 16E9C1234313; Mon, 2 Nov 2009 17:02:36 +0100 (CET) Message-ID: <4AEF0414.5040402@deployingradius.com> Date: Mon, 02 Nov 2009 11:08:52 -0500 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: Issue 323: Use of a Product Name 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: > > *Issue 323: Use of a Product Name* > Submitter name: Bernard Aboba > Submitter email address: bernard_aboba@hotmail.com > Date first submitted: October 30, 2009 > Reference: > Document: RADSEC, Status-Server, RADIUS over DTLS The latest Status-Server draft does not use the "radsec" term. > Comment type: E > Priority: S > Section: Various > Rationale/Explanation of issue: > > > "RADSEC" is the name of a commercial product. I would suggest that the > term "RADIUS over TLS" or RTLS be used instead to describe the protocol. > > */ > /* > > > > -- to unsubscribe send a message to radiusext-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 Nov 3 03:42: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 8E11328C134 for ; Tue, 3 Nov 2009 03:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.629 X-Spam-Level: * X-Spam-Status: No, score=1.629 tagged_above=-999 required=5 tests=[AWL=-1.797, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MSGID_MULTIPLE_AT=1.449, 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 VHZpb+97SILG for ; Tue, 3 Nov 2009 03:42:35 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE7413A6359 for ; Tue, 3 Nov 2009 03:42:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N5Hiv-0002uX-VM for radiusext-data0@psg.com; Tue, 03 Nov 2009 11:38:53 +0000 Received: from [74.208.4.194] (helo=mout.perfora.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N5His-0002uA-O7 for radiusext@ops.ietf.org; Tue, 03 Nov 2009 11:38:50 +0000 Received: from LENOVO (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MPnHG-1N1PqH1btq-004OrO; Tue, 03 Nov 2009 06:38:50 -0500 From: "Alper Yegin" To: Subject: New NAS-Port-Types Date: Tue, 3 Nov 2009 13:38:45 +0200 Message-ID: <013d01ca5c7a$36979630$a3c6c290$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpcejNSwMCVVg2vTDy5oD3fMrgHFQ== Content-Language: en-us X-Provags-ID: V01U2FsdGVkX18Y6AkyBhj9ZzOoanCgIj9q9KHOy5dPKKwNJOI A6KqoK9FhROaxKhdPu/H5tnu3Jvw37QvzZqg9CbxOpXhC+1RLw A0LkxSJvvoTUPfORN/qrA== Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hello, WiMAX Forum is defining new types of NASes that are used for interworking/handover between WiMAX and WiFi, 3GPP, and 3GPP2. So, new NAS-Port-Types are needed. But according to IANA: Sub-registry: Values for RADIUS Attribute 61, NAS-Port-Type Reference: [RFC2865] Registration Procedures: -->> Not defined <<-- What is the procedure to obtain new IANA-assigned NAS port types? Alper -- to unsubscribe send a message to radiusext-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 Nov 3 04:36: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 8DC303A6816 for ; Tue, 3 Nov 2009 04:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.712 X-Spam-Level: X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[AWL=1.207, 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 LQGyNNyFl0b0 for ; Tue, 3 Nov 2009 04:36:51 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9448C3A6819 for ; Tue, 3 Nov 2009 04:36:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N5IaS-0007a3-0Z for radiusext-data0@psg.com; Tue, 03 Nov 2009 12:34:12 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N5IaO-0007Zb-Hp for radiusext@ops.ietf.org; Tue, 03 Nov 2009 12:34:08 +0000 Received: from static-68-179-118-158.ptr.terago.net (static-68-179-118-158.ptr.terago.net [68.179.118.158]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 344C21234313; Tue, 3 Nov 2009 13:28:22 +0100 (CET) Message-ID: <4AF0233E.6060906@deployingradius.com> Date: Tue, 03 Nov 2009 07:34:06 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alper Yegin CC: radiusext@ops.ietf.org Subject: Re: New NAS-Port-Types References: <013d01ca5c7a$36979630$a3c6c290$@yegin@yegin.org> In-Reply-To: <013d01ca5c7a$36979630$a3c6c290$@yegin@yegin.org> 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: Alper Yegin wrote: > But according to IANA: > > Sub-registry: Values for RADIUS Attribute 61, NAS-Port-Type > Reference: [RFC2865] > Registration Procedures: -->> Not defined <<-- > > What is the procedure to obtain new IANA-assigned NAS port types? Odd. RFC 3575 *should* apply here. http://iana.org/protocols/ Under "RADIUS Attribute Values" says RFC 3575 applies. This, however, is not reflected in any of the following attributes (NAS-Port-Type, Acct-Status-Type, etc.) Some, such as Tunnel-Medium-Type, are marked "IETF Consensus", when the RFC 3575 suggestion of "Designated Expert" should apply, too. RFC 3575 makes it clear that the *only* RADIUS attribute handled that requires IETF Consensus is Service-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 Tue Nov 3 07:17:57 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 039843A67B0 for ; Tue, 3 Nov 2009 07:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.156 X-Spam-Level: * X-Spam-Status: No, score=1.156 tagged_above=-999 required=5 tests=[AWL=-0.949, 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 rZE+vmmo9zAT for ; Tue, 3 Nov 2009 07:17:56 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 296463A691D for ; Tue, 3 Nov 2009 07:17:56 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N5L3J-000M4r-OP for radiusext-data0@psg.com; Tue, 03 Nov 2009 15:12:09 +0000 Received: from [65.55.111.76] (helo=blu0-omc2-s1.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N5L3H-000M4P-HQ for radiusext@ops.ietf.org; Tue, 03 Nov 2009 15:12:07 +0000 Received: from BLU137-DS2 ([65.55.111.73]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 07:12:06 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Alper Yegin'" , References: <013d01ca5c7a$36979630$a3c6c290$@yegin@yegin.org> In-Reply-To: <013d01ca5c7a$36979630$a3c6c290$@yegin@yegin.org> Subject: RE: New NAS-Port-Types Date: Tue, 3 Nov 2009 07:12:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpcejNSwMCVVg2vTDy5oD3fMrgHFQAHcbHg Content-Language: en-us X-OriginalArrivalTime: 03 Nov 2009 15:12:06.0997 (UTC) FILETIME=[01E3C850:01CA5C98] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: IANA considerations for RADIUS are defined in RFC 3575. -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alper Yegin Sent: Tuesday, November 03, 2009 3:39 AM To: radiusext@ops.ietf.org Subject: New NAS-Port-Types Hello, WiMAX Forum is defining new types of NASes that are used for interworking/handover between WiMAX and WiFi, 3GPP, and 3GPP2. So, new NAS-Port-Types are needed. But according to IANA: Sub-registry: Values for RADIUS Attribute 61, NAS-Port-Type Reference: [RFC2865] Registration Procedures: -->> Not defined <<-- What is the procedure to obtain new IANA-assigned NAS port types? Alper -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Nov 9 17:04: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 1BC9728C278 for ; Mon, 9 Nov 2009 17:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=0.299, 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 RJz0QCnNC-by for ; Mon, 9 Nov 2009 17:04:01 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DF71B3A69DE for ; Mon, 9 Nov 2009 17:04:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N7f6e-000HX4-PJ for radiusext-data0@psg.com; Tue, 10 Nov 2009 01:01:12 +0000 Received: from [65.55.116.48] (helo=blu0-omc1-s37.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N7f6c-000HWg-1s for radiusext@ops.ietf.org; Tue, 10 Nov 2009 01:01:10 +0000 Received: from BLU137-DS2 ([65.55.116.9]) by blu0-omc1-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 17:01:09 -0800 X-Originating-IP: [131.107.0.74] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'radext mailing list'" , Subject: Problem with draft-wu-dime-local-keytran Date: Mon, 9 Nov 2009 17:01:07 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CA615E.3B77FDA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphoUk7/yU7tggjQrSam6FoJtYnKw== Content-Language: en-us X-OriginalArrivalTime: 10 Nov 2009 01:01:09.0405 (UTC) FILETIME=[4A15C4D0:01CA61A1] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0022_01CA615E.3B77FDA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have reviewed draft-wu-dime-local-keytran and found an issue with it. The document utilizes an existing RADIUS attribute (EAP-Key-Name) within a Diameter Grouped AVP. According to the value of the EAP-Key-Type AVP, the type of key being sent (and therefore the EAP-Key-Name) will change. Unfortunately, this usage is incompatible with the definition of the EAP-Key-Name in RFC 4072. RFC 4072 Section 4.1.4 notes: The EAP-Key-Name AVP (Radius Attribute Type 102) is of type OctetString. It contains an opaque key identifier (name) generated by the EAP method. Exactly how this name is used depends on the link layer in question, and is beyond the scope of this document (see [EAPKey] for more discussion). As noted in RFC 5247 Section 5.9, the EAP-Key-Name attribute contains the EAP-Session-Id, and followon standards such as IEEE 802.1X-REV depend on this attribute in order to obtain the EAP-Sesssion-Id utilized in subsequent cryptographic calculations. My concerns about this usage include: a. The inclusion of an existing RADIUS attribute within a Diameter Grouped AVP, thereby changing their meaning. The usage of grouping with existing RADIUS attributes has been discussed and rejected in RADEXT as part of the Extended Attributes work, due to concerns about backward compatibility. This document therefore represents an attempt to get around an objection raised in RADEXT via submission of a document in DIME. b. The updating of RFC 5247 by a non-standards track document in a WG that has no charter to revise EAP standards track documents. c. Conflicts between this document and work items on the RADEXT WG charter requested by IEEE 802.1 and referred to in the appendix of IEEE 802.1X-REV. ------=_NextPart_000_0022_01CA615E.3B77FDA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed draft-wu-dime-local-keytran and = found an issue with it.

 

The document utilizes an existing RADIUS attribute (EAP-Key-Name) within a Diameter Grouped AVP.   According to = the value of the EAP-Key-Type AVP,

the type of key being sent (and therefore the = EAP-Key-Name) will change.

 

Unfortunately, this usage is incompatible with the definition of the EAP-Key-Name in RFC 4072.  RFC 4072 Section 4.1.4 = notes:

 

   The EAP-Key-Name AVP (Radius Attribute Type 102) is of = type

   OctetString.  It contains an opaque key identifier (name) = generated

   by the EAP method.  Exactly how this name is used depends on the = link

   layer in question, and is beyond the scope of this document = (see

   [EAPKey] for more discussion).

 

As noted in RFC 5247 Section 5.9, the EAP-Key-Name = attribute contains the EAP-Session-Id, and followon standards such

as IEEE 802.1X-REV depend on this attribute in = order to obtain the EAP-Sesssion-Id utilized in subsequent = cryptographic

calculations.   

 

My concerns about this usage = include:

 

a.       The inclusion of an existing RADIUS attribute = within a Diameter Grouped AVP, thereby changing their meaning.  The usage of grouping = with existing RADIUS attributes has been discussed and rejected in RADEXT as = part of the Extended Attributes work, due to concerns about backward = compatibility.   This document therefore represents an attempt to get around an = objection raised in RADEXT via submission of a document in DIME.

b.      The updating of RFC 5247 by a non-standards = track document in a WG that has no charter to revise EAP standards track = documents.

c.       Conflicts between this document and work items = on the RADEXT WG charter requested by IEEE 802.1 and referred to in the = appendix of IEEE 802.1X-REV.

 

------=_NextPart_000_0022_01CA615E.3B77FDA0-- -- to unsubscribe send a message to radiusext-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 Nov 11 17:38: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 5A9A63A67F2 for ; Wed, 11 Nov 2009 17:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[AWL=0.133, 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 5gp8GXtpIl1j for ; Wed, 11 Nov 2009 17:38:21 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 687C13A67B1 for ; Wed, 11 Nov 2009 17:38:17 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N8OZm-0000g1-9F for radiusext-data0@psg.com; Thu, 12 Nov 2009 01:34:18 +0000 Received: from [65.55.116.48] (helo=blu0-omc1-s37.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N8OZh-0000fD-JJ for radiusext@ops.ietf.org; Thu, 12 Nov 2009 01:34:13 +0000 Received: from BLU137-DS7 ([65.55.116.9]) by blu0-omc1-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 17:34:12 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: CC: Subject: Re: RFC 3579 Date: Wed, 11 Nov 2009 17:34:21 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01CA62F5.34801800" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcpfMu4Mi/aIwCeuTO6zuPBEDg3rAwAAi++AAQBaAzAAAGp5EA== Content-Language: en-us X-OriginalArrivalTime: 12 Nov 2009 01:34:12.0786 (UTC) FILETIME=[3D193120:01CA6338] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0026_01CA62F5.34801800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In the normal case you describe below (where the NAS always starts off with an EAP-Identity Request) there is no need for the NAS to ever send an EAP-Start packet to the RADIUS server. This is only useful if the Identity exchange might be superfluous and the RADIUS server can just start off with the EAP method Request from the beginning. There are a very limited number of situations where this would be useful because: a. The NAS has to route the request to a RADIUS server without a User-Name attribute because there has been no Identity Exchange (e.g. only the Calling-Station-Id might be available to be placed in the User-Name attribute) b. The RADIUS server has to be prepared to choose the EAP method based on what is placed in the User-Name attribute, if anything. There are some limited situations in which this might be useful. but I'm not aware of much deployment experience. The EAP-Start packet is a RADIUS Access-Request packet containing an EAP-Message attribute with a single NUL character. So the length of the EAP-Message attribute is >=3. Might make sense to file an errata to clarify. There is no RADIUS attribute to encapsulate EAPoL, only EAP-Message, which is used to encapsulate EAP. So there is no way to send an EAPoL-Start packet to a RADIUS server within an EAP-Message attribute. If there is a need to convey EAPoL-Start data (e.g. IEEE 802.1X-REV extensions to EAPoL-Start such as NIDs) then you'd need to define a distinct RADIUS attribute to convey that. From: Koehler, Yannick [mailto:yannick.koehler@hp.com] Sent: Friday, November 06, 2009 2:46 PM To: Bernard Aboba; pcalhoun@airespace.com Subject: RFC 3579 Hello, I have read the RFC 3579 and I have some questions and I was hoping to get some answers from you. In the RFC it says that the EAP-Start may be represented by an EAP-Message of length 2 (no data). Yet, the specification of this EAP-Message attribute is defined with a length >= 3 and that, even in the RFC 3579. Also, I do not follow why there is an EAP-Start packet is this the same as EAPOL-Start ? And if not, why sending such an empty packet to a RADIUS server? It seems to me like it waste a round-trip. My understanding of 802.1x nego is something like that: Client sends EAPOL-Start NAS answer EAP-Identity Request Client sends EAP-Identity response NAS sends RADIUS with EAP identity response to RADIUS RADIUS reply NAS forward answer. Client continue exchange. How is the EAP-Start affecting this negotiation and when is it used, and why? Is there more documentation on this packet? -- Yannick Koehler ------=_NextPart_000_0026_01CA62F5.34801800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the normal case you describe below (where the NAS = always starts off with an EAP-Identity Request) there is no need for the NAS to = ever send an EAP-Start packet to the RADIUS server.  This is only useful = if the Identity exchange might be superfluous and the RADIUS server can just = start off with the EAP method Request from the beginning.  There are a very = limited number of situations where this would be useful = because:

 

a.    The NAS has to route the request to = a RADIUS server without a User-Name attribute because there has been no Identity Exchange (e.g. only the Calling-Station-Id might be available to be = placed in the User-Name attribute)

b.    The RADIUS server has to be = prepared to choose the EAP method based on what is placed in the User-Name = attribute, if anything. 

 

There are some limited situations in which this might be = useful… but I’m not aware of much deployment experience. =

 

The EAP-Start packet is a RADIUS Access-Request packet containing an EAP-Message attribute with a single NUL character.  = So the length of the EAP-Message attribute is >=3D3. =

Might make sense to file an errata to clarify. =

 

There is no RADIUS attribute to encapsulate EAPoL, only EAP-Message, which is used to encapsulate EAP.   So there is = no way to send an EAPoL-Start packet to a RADIUS server within an EAP-Message attribute.  If there is a need to convey EAPoL-Start data (e.g. = IEEE 802.1X-REV extensions to EAPoL-Start such as NIDs) then you’d need = to define a distinct RADIUS attribute to convey that.

 

 

 

 

 

From:= Koehler, = Yannick [mailto:yannick.koehler@hp.com]
Sent: Friday, November 06, 2009 2:46 PM
To: Bernard Aboba; pcalhoun@airespace.com
Subject: RFC 3579

 

Hello,

 

  I have read the RFC 3579 and I have some = questions and I was hoping to get some answers from you.  In the RFC it says = that the EAP-Start may be represented by an EAP-Message of length 2 (no = data).  Yet, the specification of this EAP-Message attribute is defined = with a length >=3D 3 and that, even in the RFC 3579.  Also, I do not = follow why there is an EAP-Start packet is this the same as EAPOL-Start ?  And = if not, why sending such an empty packet to a RADIUS server?  It seems = to me like it waste a round-trip.

 

  My understanding of 802.1x nego is something = like that:

 

  Client sends EAPOL-Start

              &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =      NAS answer EAP-Identity Request

  Client sends EAP-Identity = response

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           NAS sends RADIUS with EAP identity response to RADIUS

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           RADIUS reply

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           NAS forward answer.

  Client continue exchange.

 

How is the EAP-Start affecting this negotiation and = when is it used, and why?  Is there more documentation on this = packet?

 

--

Yannick Koehler

------=_NextPart_000_0026_01CA62F5.34801800-- -- to unsubscribe send a message to radiusext-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 Nov 12 10:49:16 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5343A680F for ; Thu, 12 Nov 2009 10:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.663 X-Spam-Level: X-Spam-Status: No, score=0.663 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgEWEBP9T3d2 for ; Thu, 12 Nov 2009 10:49:09 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16F4C3A67AC for ; Thu, 12 Nov 2009 10:49:08 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N8efR-0001DW-6a for radiusext-data0@psg.com; Thu, 12 Nov 2009 18:45:13 +0000 Received: from [65.55.111.103] (helo=blu0-omc2-s28.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N8efL-0001CL-Fm for radiusext@ops.ietf.org; Thu, 12 Nov 2009 18:45:07 +0000 Received: from BLU137-DS6 ([65.55.111.73]) by blu0-omc2-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 10:44:34 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Koehler, Yannick'" , References: <6ADBC80DB6D4264A892C376E5E07753062EA567864@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <6ADBC80DB6D4264A892C376E5E07753062EA567864@GVW0671EXC.americas.hpqcorp.net> Subject: RE: RFC 3579 Date: Thu, 12 Nov 2009 10:44:43 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CA6385.257698D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpfMu4Mi/aIwCeuTO6zuPBEDg3rAwAAi++AAQBaAzAAAGp5EAAZ/DJgAAnlM0A= Content-Language: en-us X-OriginalArrivalTime: 12 Nov 2009 18:44:34.0658 (UTC) FILETIME=[2DCE3C20:01CA63C8] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0001_01CA6385.257698D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Windows 7 does not include a RADIUS client. So I'm surprised that you are seeing it send RADIUS packets at all, let alone a RADIUS Access-Request including an EAP-Message attribute. If a NAS sends an EAP Identity-Request to an EAP peer, I'd expect the EAP peer to respond with an EAP Identity-Response. The NAS can then send an Access-Request with an EAP-Message attribute containing the contents of the EAP-Response/Identity. Am I missing something? From: Koehler, Yannick [mailto:yannick.koehler@hp.com] Sent: Thursday, November 12, 2009 6:01 AM To: Bernard Aboba; radiusext@ops.ietf.org Subject: RE: RFC 3579 An errata would be useful because even after your reply the RFC seems even more confusing, this part of the RFC no more apply then: " EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data)." We saw report that Windows 7 was sending a EAP-Message with length of 2, that is why I am inquiring. But considering what you just said, the fact that our product sends an identity-request should force them to send an EAP Identity response and not an EAP-start. I will pursue my investigation to figure out in which situation the Windows 7 act like this. -- Yannick Koehler From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: November-11-09 8:34 PM To: radiusext@ops.ietf.org Cc: Koehler, Yannick Subject: Re: RFC 3579 In the normal case you describe below (where the NAS always starts off with an EAP-Identity Request) there is no need for the NAS to ever send an EAP-Start packet to the RADIUS server. This is only useful if the Identity exchange might be superfluous and the RADIUS server can just start off with the EAP method Request from the beginning. There are a very limited number of situations where this would be useful because: a. The NAS has to route the request to a RADIUS server without a User-Name attribute because there has been no Identity Exchange (e.g. only the Calling-Station-Id might be available to be placed in the User-Name attribute) b. The RADIUS server has to be prepared to choose the EAP method based on what is placed in the User-Name attribute, if anything. There are some limited situations in which this might be useful. but I'm not aware of much deployment experience. The EAP-Start packet is a RADIUS Access-Request packet containing an EAP-Message attribute with a single NUL character. So the length of the EAP-Message attribute is >=3. Might make sense to file an errata to clarify. There is no RADIUS attribute to encapsulate EAPoL, only EAP-Message, which is used to encapsulate EAP. So there is no way to send an EAPoL-Start packet to a RADIUS server within an EAP-Message attribute. If there is a need to convey EAPoL-Start data (e.g. IEEE 802.1X-REV extensions to EAPoL-Start such as NIDs) then you'd need to define a distinct RADIUS attribute to convey that. From: Koehler, Yannick [mailto:yannick.koehler@hp.com] Sent: Friday, November 06, 2009 2:46 PM To: Bernard Aboba; pcalhoun@airespace.com Subject: RFC 3579 Hello, I have read the RFC 3579 and I have some questions and I was hoping to get some answers from you. In the RFC it says that the EAP-Start may be represented by an EAP-Message of length 2 (no data). Yet, the specification of this EAP-Message attribute is defined with a length >= 3 and that, even in the RFC 3579. Also, I do not follow why there is an EAP-Start packet is this the same as EAPOL-Start ? And if not, why sending such an empty packet to a RADIUS server? It seems to me like it waste a round-trip. My understanding of 802.1x nego is something like that: Client sends EAPOL-Start NAS answer EAP-Identity Request Client sends EAP-Identity response NAS sends RADIUS with EAP identity response to RADIUS RADIUS reply NAS forward answer. Client continue exchange. How is the EAP-Start affecting this negotiation and when is it used, and why? Is there more documentation on this packet? -- Yannick Koehler ------=_NextPart_000_0001_01CA6385.257698D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Windows 7 does not = include a RADIUS client.  So I’m surprised that you are seeing it send = RADIUS packets at all, let alone a RADIUS Access-Request including an EAP-Message = attribute.

 

If a NAS sends an EAP = Identity-Request to an EAP peer, I’d expect the EAP peer to respond with an  = EAP Identity-Response.  The NAS can then send an  Access-Request = with an EAP-Message attribute containing the contents of the = EAP-Response/Identity. 

 

Am I missing = something?

 

From:= Koehler, = Yannick [mailto:yannick.koehler@hp.com]
Sent: Thursday, November 12, 2009 6:01 AM
To: Bernard Aboba; radiusext@ops.ietf.org
Subject: RE: RFC 3579

 

An errata would be = useful because even after your reply the RFC seems even more confusing, this = part of the RFC no more apply then:

 

“=
   EAP-Start is indicated by sending an EAP-Message attribute =
with a

   length of 2 (no data).”

 

We saw report that = Windows 7 was sending a EAP-Message with length of 2, that is why I am = inquiring.  But considering what you just said, the fact that our product sends an identity-request should force them to send an EAP Identity response and = not an EAP-start.  I will pursue my investigation to figure out in which situation the Windows 7 act like this.

 

--

Yannick = Koehler

 

 

From:= Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: November-11-09 8:34 PM
To: radiusext@ops.ietf.org
Cc: Koehler, Yannick
Subject: Re: RFC 3579

 

In the normal case you describe below (where the NAS = always starts off with an EAP-Identity Request) there is no need for the NAS to = ever send an EAP-Start packet to the RADIUS server.  This is only useful = if the Identity exchange might be superfluous and the RADIUS server can just = start off with the EAP method Request from the beginning.  There are a very = limited number of situations where this would be useful = because:

 

a.    The NAS has to route the request to = a RADIUS server without a User-Name attribute because there has been no = Identity Exchange (e.g. only the Calling-Station-Id might be available to be = placed in the User-Name attribute)

b.    The RADIUS server has to be = prepared to choose the EAP method based on what is placed in the User-Name = attribute, if anything. 

 

There are some limited situations in which this might be = useful… but I’m not aware of much deployment experience. =

 

The EAP-Start packet is a RADIUS Access-Request packet containing an EAP-Message attribute with a single NUL character.  = So the length of the EAP-Message attribute is >=3D3. =

Might make sense to file an errata to clarify. =

 

There is no RADIUS attribute to encapsulate EAPoL, only EAP-Message, which is used to encapsulate EAP.   So there is = no way to send an EAPoL-Start packet to a RADIUS server within an EAP-Message attribute.  If there is a need to convey EAPoL-Start data (e.g. = IEEE 802.1X-REV extensions to EAPoL-Start such as NIDs) then you’d need = to define a distinct RADIUS attribute to convey that.

 

 

 

 

 

From:= Koehler, = Yannick [mailto:yannick.koehler@hp.com]
Sent: Friday, November 06, 2009 2:46 PM
To: Bernard Aboba; pcalhoun@airespace.com
Subject: RFC 3579

 

Hello,

 

  I have read the RFC 3579 and I have some = questions and I was hoping to get some answers from you.  In the RFC it says = that the EAP-Start may be represented by an EAP-Message of length 2 (no = data).  Yet, the specification of this EAP-Message attribute is defined = with a length >=3D 3 and that, even in the RFC 3579.  Also, I do not = follow why there is an EAP-Start packet is this the same as EAPOL-Start ?  And = if not, why sending such an empty packet to a RADIUS server?  It seems = to me like it waste a round-trip.

 

  My understanding of 802.1x nego is something = like that:

 

  Client sends EAPOL-Start

  =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =      NAS answer EAP-Identity Request

  Client sends EAP-Identity = response

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           NAS sends RADIUS with EAP identity response to RADIUS

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           RADIUS reply

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           NAS forward answer.

  Client continue exchange.

 

How is the EAP-Start affecting this negotiation and = when is it used, and why?  Is there more documentation on this = packet?

 

--

Yannick Koehler

------=_NextPart_000_0001_01CA6385.257698D0-- -- to unsubscribe send a message to radiusext-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 Nov 12 13:55: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 EA2713A6831 for ; Thu, 12 Nov 2009 13:55:30 -0800 (PST) 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.907, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvL9+5W7Ya9H for ; Thu, 12 Nov 2009 13:55:22 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 013653A67E4 for ; Thu, 12 Nov 2009 13:55:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N8han-000PeY-PQ for radiusext-data0@psg.com; Thu, 12 Nov 2009 21:52:37 +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 1N8hai-000Pe6-A8 for radiusext@ops.ietf.org; Thu, 12 Nov 2009 21:52:32 +0000 Received: from BLU137-DS5 ([65.55.111.72]) by blu0-omc2-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 13:52:31 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Koehler, Yannick'" , References: <6ADBC80DB6D4264A892C376E5E07753062EA567864@GVW0671EXC.americas.hpqcorp.net> <6ADBC80DB6D4264A892C376E5E07753062EA5679EB@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <6ADBC80DB6D4264A892C376E5E07753062EA5679EB@GVW0671EXC.americas.hpqcorp.net> Subject: RE: RFC 3579 Date: Thu, 12 Nov 2009 13:52:30 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E4_01CA639F.60EC76E0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcpfMu4Mi/aIwCeuTO6zuPBEDg3rAwAAi++AAQBaAzAAAGp5EAAZ/DJgAAnlM0AAAJxsQAAF7IJw Content-Language: en-us X-OriginalArrivalTime: 12 Nov 2009 21:52:31.0458 (UTC) FILETIME=[6F4D5C20:01CA63E2] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_01E4_01CA639F.60EC76E0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit There is no such thing as an EAP-Start packet defined outside of RADIUS. Perhaps you are thinking of EAPoL-Start? However, EAPoL-Start as defined in IEEE 802.1X-2004 does not contain any data, nor does it contain an EAP packet. An EAP authenticator can respond to an EAPoL-Start by sending an EAP-Request/Identity to the peer; there is no reason to send a RADIUS Access-Request/EAP-Message packet to the RADIUS server unless there is a desire to bypass the Identity exchange. From: Koehler, Yannick [mailto:yannick.koehler@hp.com] Sent: Thursday, November 12, 2009 11:01 AM To: Bernard Aboba; radiusext@ops.ietf.org Subject: RE: RFC 3579 Hi, I received claim that Windows 7 sends out EAP-Start not RADIUS packets. Those EAP-Start most likely are transmitted over a EAPOL packet and our product extract the EAP and sends it over RADIUS. I was mostly getting up to date with this RFC because it seems that this is where the EAP-Start got defined. -- Yannick Koehler From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: November-12-09 1:45 PM To: Koehler, Yannick; radiusext@ops.ietf.org Subject: RE: RFC 3579 Windows 7 does not include a RADIUS client. So I'm surprised that you are seeing it send RADIUS packets at all, let alone a RADIUS Access-Request including an EAP-Message attribute. If a NAS sends an EAP Identity-Request to an EAP peer, I'd expect the EAP peer to respond with an EAP Identity-Response. The NAS can then send an Access-Request with an EAP-Message attribute containing the contents of the EAP-Response/Identity. Am I missing something? From: Koehler, Yannick [mailto:yannick.koehler@hp.com] Sent: Thursday, November 12, 2009 6:01 AM To: Bernard Aboba; radiusext@ops.ietf.org Subject: RE: RFC 3579 An errata would be useful because even after your reply the RFC seems even more confusing, this part of the RFC no more apply then: " EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data)." We saw report that Windows 7 was sending a EAP-Message with length of 2, that is why I am inquiring. But considering what you just said, the fact that our product sends an identity-request should force them to send an EAP Identity response and not an EAP-start. I will pursue my investigation to figure out in which situation the Windows 7 act like this. -- Yannick Koehler From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: November-11-09 8:34 PM To: radiusext@ops.ietf.org Cc: Koehler, Yannick Subject: Re: RFC 3579 In the normal case you describe below (where the NAS always starts off with an EAP-Identity Request) there is no need for the NAS to ever send an EAP-Start packet to the RADIUS server. This is only useful if the Identity exchange might be superfluous and the RADIUS server can just start off with the EAP method Request from the beginning. There are a very limited number of situations where this would be useful because: a. The NAS has to route the request to a RADIUS server without a User-Name attribute because there has been no Identity Exchange (e.g. only the Calling-Station-Id might be available to be placed in the User-Name attribute) b. The RADIUS server has to be prepared to choose the EAP method based on what is placed in the User-Name attribute, if anything. There are some limited situations in which this might be useful. but I'm not aware of much deployment experience. The EAP-Start packet is a RADIUS Access-Request packet containing an EAP-Message attribute with a single NUL character. So the length of the EAP-Message attribute is >=3. Might make sense to file an errata to clarify. There is no RADIUS attribute to encapsulate EAPoL, only EAP-Message, which is used to encapsulate EAP. So there is no way to send an EAPoL-Start packet to a RADIUS server within an EAP-Message attribute. If there is a need to convey EAPoL-Start data (e.g. IEEE 802.1X-REV extensions to EAPoL-Start such as NIDs) then you'd need to define a distinct RADIUS attribute to convey that. From: Koehler, Yannick [mailto:yannick.koehler@hp.com] Sent: Friday, November 06, 2009 2:46 PM To: Bernard Aboba; pcalhoun@airespace.com Subject: RFC 3579 Hello, I have read the RFC 3579 and I have some questions and I was hoping to get some answers from you. In the RFC it says that the EAP-Start may be represented by an EAP-Message of length 2 (no data). Yet, the specification of this EAP-Message attribute is defined with a length >= 3 and that, even in the RFC 3579. Also, I do not follow why there is an EAP-Start packet is this the same as EAPOL-Start ? And if not, why sending such an empty packet to a RADIUS server? It seems to me like it waste a round-trip. My understanding of 802.1x nego is something like that: Client sends EAPOL-Start NAS answer EAP-Identity Request Client sends EAP-Identity response NAS sends RADIUS with EAP identity response to RADIUS RADIUS reply NAS forward answer. Client continue exchange. How is the EAP-Start affecting this negotiation and when is it used, and why? Is there more documentation on this packet? -- Yannick Koehler ------=_NextPart_000_01E4_01CA639F.60EC76E0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

There is no such = thing as an EAP-Start packet defined outside of RADIUS.  Perhaps you are thinking of = EAPoL-Start?  However, EAPoL-Start as defined in IEEE 802.1X-2004 does not contain any data, = nor does it contain an EAP packet.   An EAP authenticator can respond = to an EAPoL-Start by sending an EAP-Request/Identity to the peer;  there is no reason = to send a RADIUS Access-Request/EAP-Message packet to the RADIUS server unless = there is a desire to bypass the Identity exchange.

 

 

 

From:= Koehler, = Yannick [mailto:yannick.koehler@hp.com]
Sent: Thursday, November 12, 2009 11:01 AM
To: Bernard Aboba; radiusext@ops.ietf.org
Subject: RE: RFC 3579

 

Hi,

 

  I received = claim that Windows 7 sends out EAP-Start not RADIUS packets.  Those EAP-Start = most likely are transmitted over a EAPOL packet and our product extract the = EAP and sends it over RADIUS.  I was mostly getting up to date with this = RFC because it seems that this is where the EAP-Start got = defined.

 

--

Yannick = Koehler

 

From:= Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: November-12-09 1:45 PM
To: Koehler, Yannick; radiusext@ops.ietf.org
Subject: RE: RFC 3579

 

Windows 7 does not = include a RADIUS client.  So I’m surprised that you are seeing it send = RADIUS packets at all, let alone a RADIUS Access-Request including an = EAP-Message attribute.

 

If a NAS sends an EAP Identity-Request to an EAP peer, I’d expect the EAP peer to = respond with an  EAP Identity-Response.  The NAS can then send an  = Access-Request with an EAP-Message attribute containing the contents of the EAP-Response/Identity. 

 

Am I missing = something?

 

From:= Koehler, = Yannick [mailto:yannick.koehler@hp.com]
Sent: Thursday, November 12, 2009 6:01 AM
To: Bernard Aboba; radiusext@ops.ietf.org
Subject: RE: RFC 3579

 

An errata would be = useful because even after your reply the RFC seems even more confusing, this = part of the RFC no more apply then:

 

“=
   EAP-Start is indicated by sending an EAP-Message attribute =
with a

   length of 2 (no data).”

 

We saw report that = Windows 7 was sending a EAP-Message with length of 2, that is why I am = inquiring.  But considering what you just said, the fact that our product sends an identity-request should force them to send an EAP Identity response and = not an EAP-start.  I will pursue my investigation to figure out in which situation the Windows 7 act like this.

 

--

Yannick = Koehler

 

 

From:= Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: November-11-09 8:34 PM
To: radiusext@ops.ietf.org
Cc: Koehler, Yannick
Subject: Re: RFC 3579

 

In the normal case you describe below (where the NAS = always starts off with an EAP-Identity Request) there is no need for the NAS to = ever send an EAP-Start packet to the RADIUS server.  This is only useful = if the Identity exchange might be superfluous and the RADIUS server can just = start off with the EAP method Request from the beginning.  There are a very = limited number of situations where this would be useful = because:

 

a.    The NAS has to route the request to = a RADIUS server without a User-Name attribute because there has been no = Identity Exchange (e.g. only the Calling-Station-Id might be available to be = placed in the User-Name attribute)

b.    The RADIUS server has to be = prepared to choose the EAP method based on what is placed in the User-Name = attribute, if anything. 

 

There are some limited situations in which this might be = useful… but I’m not aware of much deployment experience. =

 

The EAP-Start packet is a RADIUS Access-Request packet containing an EAP-Message attribute with a single NUL character.  = So the length of the EAP-Message attribute is >=3D3. =

Might make sense to file an errata to clarify. =

 

There is no RADIUS attribute to encapsulate EAPoL, only EAP-Message, which is used to encapsulate EAP.   So there is = no way to send an EAPoL-Start packet to a RADIUS server within an EAP-Message attribute.  If there is a need to convey EAPoL-Start data (e.g. = IEEE 802.1X-REV extensions to EAPoL-Start such as NIDs) then you’d need = to define a distinct RADIUS attribute to convey that.

 

 

 

 

 

From:= Koehler, = Yannick [mailto:yannick.koehler@hp.com]
Sent: Friday, November 06, 2009 2:46 PM
To: Bernard Aboba; pcalhoun@airespace.com
Subject: RFC 3579

 

Hello,

 

  I have read the RFC 3579 and I have some = questions and I was hoping to get some answers from you.  In the RFC it says = that the EAP-Start may be represented by an EAP-Message of length 2 (no = data).  Yet, the specification of this EAP-Message attribute is defined = with a length >=3D 3 and that, even in the RFC 3579.  Also, I do not = follow why there is an EAP-Start packet is this the same as EAPOL-Start ?  And = if not, why sending such an empty packet to a RADIUS server?  It seems = to me like it waste a round-trip.

 

  My understanding of 802.1x nego is something = like that:

 

  Client sends EAPOL-Start

              &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =      NAS answer EAP-Identity Request

  Client sends EAP-Identity = response

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           NAS sends RADIUS with EAP identity response to RADIUS

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           RADIUS reply

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           NAS forward answer.

  Client continue exchange.

 

How is the EAP-Start affecting this negotiation and = when is it used, and why?  Is there more documentation on this = packet?

 

--

Yannick Koehler

------=_NextPart_000_01E4_01CA639F.60EC76E0-- -- to unsubscribe send a message to radiusext-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 Nov 12 16: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 249C93A67D1 for ; Thu, 12 Nov 2009 16:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.395 X-Spam-Level: X-Spam-Status: No, score=0.395 tagged_above=-999 required=5 tests=[AWL=-0.600, 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 5pPTHpzU9MMu for ; Thu, 12 Nov 2009 16:59:03 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 92AF83A6784 for ; Thu, 12 Nov 2009 16:59:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N8kRq-000OMG-Be for radiusext-data0@psg.com; Fri, 13 Nov 2009 00:55:34 +0000 Received: from [65.55.116.37] (helo=blu0-omc1-s26.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N8kRl-000OM3-9j for radiusext@ops.ietf.org; Fri, 13 Nov 2009 00:55:29 +0000 Received: from BLU137-DS4 ([65.55.116.8]) by blu0-omc1-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 16:55:28 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: References: <003901ca61a5$2b00eee0$8102cca0$@com> In-Reply-To: <003901ca61a5$2b00eee0$8102cca0$@com> Subject: Registration of RADIUS Attribute Values and RFC 3575 Date: Thu, 12 Nov 2009 16:55:27 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0212_01CA63B8.EF85DC20" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcphpSiOJiCTGTGPQlyjnn0H4TQe1wCVoRhw Content-Language: en-us X-OriginalArrivalTime: 13 Nov 2009 00:55:28.0588 (UTC) FILETIME=[FE2E78C0:01CA63FB] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0212_01CA63B8.EF85DC20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Recently on the RADEXT WG mailing list, an issue has been raised about the IANA allocation procedures for RADIUS attribute values: http://ops.ietf.org/lists/radiusext/2009/msg00625.html As noted in RFC 3575, Section 2.1: Certain attributes (for example, NAS-Port-Type) in RADIUS define a list of values to correspond with various meanings. There can be 4 billion (2^32) values for each attribute. Additional values can be allocated by the Designated Expert. The exception to this policy is the Service-Type attribute (6), whose values define new modes of operation for RADIUS. Values 1-16 of the Service-Type attribute have been allocated. Allocation of new Service-Type values are by IETF Consensus. The intention is that any allocation will be accompanied by a published RFC. Given the above text, it is my understanding that according to RFC 3575, additional values for RADIUS attributes (with the exception of the Service-Type attribute (6)) are to be allocated by Designated Expert. However, within the IANA RADIUS registry ( http://www.iana.org/protocols/) RADIUS attribute values are listed as requiring Standards Action. All in all, a substantial number of the entries in this registry appear to be incorrect. Given that RFC 3575 specifically indicates that standards action is not required for allocation of values for any RADIUS attribute other than Service-Type, there is not much room for interpretation here and I would like to make sure that this problem is corrected as soon as possible. We have notified IANA, but so far we have not gotten any response. ------=_NextPart_000_0212_01CA63B8.EF85DC20 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Recently on the = RADEXT WG mailing list, an issue has been raised about the IANA allocation = procedures for RADIUS attribute values:

http://ops.ietf.org/lists/radiusext/2009/msg00625= .html

 

As noted in RFC 3575, = Section 2.1:

 

   Certain attributes (for example, = NAS-Port-Type) in RADIUS define a

   list of values to correspond with various meanings.  There can be 4

   billion (2^32) values for each = attribute.  Additional values can be

   allocated by the Designated Expert.  = The exception to this policy is

   the Service-Type attribute (6), whose values = define new modes of

   operation for RADIUS.  Values 1-16 of = the Service-Type attribute have

   been allocated.  Allocation of new Service-Type values are by IETF

   Consensus.  The intention is that any allocation will be accompanied

   by a published RFC.

 

Given the above text, = it is my understanding that according to RFC 3575, additional values for RADIUS attributes (with the exception of the Service-Type attribute (6)) are to = be allocated by Designated Expert.

 

However, within the = IANA RADIUS registry (http://www.iana.org/protocols/) RADIUS attribute values are listed as requiring Standards Action.  =  All in all, a substantial number of the entries in this registry appear to be incorrect.

 

Given that RFC 3575 = specifically indicates that standards action is not required for allocation of values = for any RADIUS attribute other than Service-Type, there is not much room for interpretation here and I would like to make sure that this problem is corrected as soon as possible.   We have notified IANA, but so = far we have not gotten any response.

 

 

 

 

 

 

 

 

 

------=_NextPart_000_0212_01CA63B8.EF85DC20-- -- to unsubscribe send a message to radiusext-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 Nov 13 01:49: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 F21FD3A6859 for ; Fri, 13 Nov 2009 01:49:47 -0800 (PST) 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 o9x+ewHJ8EX1 for ; Fri, 13 Nov 2009 01:49:47 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F24653A69E3 for ; Fri, 13 Nov 2009 01:49:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N8sj8-0000IE-01 for radiusext-data0@psg.com; Fri, 13 Nov 2009 09:45:58 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N8sj5-0000Hu-N1 for radiusext@ops.ietf.org; Fri, 13 Nov 2009 09:45:55 +0000 Message-ID: <4AFD2ACF.3020503@deployingradius.com> Date: Fri, 13 Nov 2009 10:45:51 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "'Koehler, Yannick'" , radiusext@ops.ietf.org Subject: Re: RFC 3579 References: <6ADBC80DB6D4264A892C376E5E07753062EA567864@GVW0671EXC.americas.hpqcorp.net> <6ADBC80DB6D4264A892C376E5E07753062EA5679EB@GVW0671EXC.americas.hpqcorp.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: > There is no such thing as an EAP-Start packet defined outside of > RADIUS. Perhaps you are thinking of EAPoL-Start? However, EAPoL-Start > as defined in IEEE 802.1X-2004 does not contain any data, nor does it > contain an EAP packet. An EAP authenticator can respond to an > EAPoL-Start by sending an EAP-Request/Identity to the peer; there is no > reason to send a RADIUS Access-Request/EAP-Message packet to the RADIUS > server unless there is a desire to bypass the Identity exchange. IIRC, I have seen packet traces where the EAP-Message attribute contains only 4 octets. The server then responds with an Access-Challenge/EAP-Identity request, and authentication continues. But that behavior is rare. 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 Nov 17 11:26:47 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 B7FC73A6939 for ; Tue, 17 Nov 2009 11:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.404 X-Spam-Level: X-Spam-Status: No, score=0.404 tagged_above=-999 required=5 tests=[AWL=-1.701, 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 Re37DIBGTlIU for ; Tue, 17 Nov 2009 11:26:46 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B5BC63A681C for ; Tue, 17 Nov 2009 11:26:43 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NATd7-000BsA-HN for radiusext-data0@psg.com; Tue, 17 Nov 2009 19:22:21 +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 1NATd4-000Brk-9h for radiusext@ops.ietf.org; Tue, 17 Nov 2009 19:22:18 +0000 Received: from BLU137-DS3 ([65.55.116.9]) by blu0-omc1-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 11:22:17 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Subject: FW: draft-ietf-radext-dynamic-discovery-01.txt Date: Tue, 17 Nov 2009 11:22:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpntphHkhPwrfRST4mZYOPVC8Z7DQABK2DA Content-Language: en-us X-OriginalArrivalTime: 17 Nov 2009 19:22:17.0340 (UTC) FILETIME=[4688DBC0:01CA67BB] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: -----Original Message----- From: Leslie Daigle [mailto:leslie@thinkingcat.com] Sent: Tuesday, November 17, 2009 10:49 AM To: stefan.winter@restena.lu; mikem@open.com.au Cc: Bernard Aboba; David Nelson Subject: draft-ietf-radext-dynamic-discovery-01.txt Hi, Looking for something completely different, I came across your RADEXT draft (draft-ietf-radext-dynamic-discovery-01.txt). You need to know that NAPTR records cannot be used "in the wild" (as in, "just retrieve the NAPTR record"), as currently described in your document. NAPTR records are part of the DNS implementation of the Dynamic Delegation Discovery System (DDDS) -- see RFC3403. To use them, you need to define a DDDS application (as outlined in that suite of documents). You may find that S-NAPTR (RFC3958) does the trick for you. Leslie. P.S.: Feel free to forward this note to the WG mailing list, if that's useful. -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- -- to unsubscribe send a message to radiusext-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 Nov 18 11:42:08 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C5B3A687B for ; Wed, 18 Nov 2009 11:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.024 X-Spam-Level: * X-Spam-Status: No, score=1.024 tagged_above=-999 required=5 tests=[AWL=-1.381, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, 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 UIHLuz7Kki4L for ; Wed, 18 Nov 2009 11:42:07 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9D2EB3A635F for ; Wed, 18 Nov 2009 11:42:07 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NAqLx-000E4x-0U for radiusext-data0@psg.com; Wed, 18 Nov 2009 19:38:09 +0000 Received: from [65.55.111.110] (helo=blu0-omc2-s35.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NAqLu-000E4Q-Vy for radiusext@ops.ietf.org; Wed, 18 Nov 2009 19:38:07 +0000 Received: from BLU137-DS2 ([65.55.111.73]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 11:38:06 -0800 X-Originating-IP: [131.107.0.105] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: =?iso-8859-1?Q?'Klaus_Kl=F6ser'?= , References: <7673D9BE-50F2-444B-81E8-91C71E09AAD2@kloeser.com> In-Reply-To: <7673D9BE-50F2-444B-81E8-91C71E09AAD2@kloeser.com> Subject: RE: Radius MIB and DMTFs CIM Date: Wed, 18 Nov 2009 11:38:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHKaIVPDw3qIMJqskeOG5bfSPTeEZE8PBsQ Content-Language: en-us X-OriginalArrivalTime: 18 Nov 2009 19:38:06.0362 (UTC) FILETIME=[A69BDFA0:01CA6886] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Not as far as I know.=20 -----Original Message----- From: Klaus Kl=F6ser [mailto:klaus@kloeser.com]=20 Sent: Wednesday, November 18, 2009 11:27 AM To: Bernard Aboba Subject: Radius MIB and DMTFs CIM Hi, I would be interested, if there is a representation of RADIUS management information in DMTF's CIM classes (www.dmtf.org). Any Information is appreciated ! Thank you Best regards Klaus Kl=F6ser -- to unsubscribe send a message to radiusext-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 Nov 20 16:46: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 80B173A67DA for ; Fri, 20 Nov 2009 16:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[AWL=-1.607, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 ynlig9-Q8kcS for ; Fri, 20 Nov 2009 16:46:34 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 359A23A67B2 for ; Fri, 20 Nov 2009 16:46:33 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NBe1C-000178-LX for radiusext-data0@psg.com; Sat, 21 Nov 2009 00:40:02 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NBQKk-0001ef-Hp for radiusext@ops.ietf.org; Fri, 20 Nov 2009 10:03:20 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAGn4BUurRN+J/2dsb2JhbACCJiuNRqxNl2+EPAQ X-IronPort-AV: E=Sophos;i="4.44,776,1249257600"; d="scan'208,217";a="51957766" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 20 Nov 2009 10:03:17 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nAKA2k7Y001138; Fri, 20 Nov 2009 10:03:16 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, 20 Nov 2009 11:03:04 +0100 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_01CA69C8.A6909654" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 20 Nov 2009 11:02:57 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxAAAQa5/AAAMdz4AVuTG4A References: From: "Wojciech Dec (wdec)" To: "Bernard Aboba" Cc: "Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 20 Nov 2009 10:03:04.0493 (UTC) FILETIME=[A6B7F5D0:01CA69C8] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA69C8.A6909654 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trying for the 4th time now: =20 - 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?) - could you point out (summarise) the issues that were not addressed? =20 Thanks, Woj. ________________________________ From: Wojciech Dec (wdec)=20 Sent: 23 October 2009 20:36 To: 'Bernard Aboba'; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 =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 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_01CA69C8.A6909654 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trying for the 4th time=20 now:

 

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

- Are you now = convinced of=20 "interest"? (and if not, or partially, then on what grounds?)

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

 

Thanks,

Woj.


From: Wojciech Dec (wdec) =
Sent: 23=20 October 2009 20:36
To: 'Bernard Aboba';=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

 

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=20 the 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=20 per my earlier mail(s):

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

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

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

 

Thanks.

 

 

 

 

 

 

------_=_NextPart_001_01CA69C8.A6909654-- -- to unsubscribe send a message to radiusext-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 Nov 20 17:59:24 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 8FDB33A67D7 for ; Fri, 20 Nov 2009 17:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.306 X-Spam-Level: X-Spam-Status: No, score=0.306 tagged_above=-999 required=5 tests=[AWL=-1.059, 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 WjyEP+H71qVe for ; Fri, 20 Nov 2009 17:59:20 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 99CEC3A67B3 for ; Fri, 20 Nov 2009 17:59:19 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NBf9k-0006w1-D2 for radiusext-data0@psg.com; Sat, 21 Nov 2009 01:52:56 +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 1NBf9i-0006vi-NO for radiusext@ops.ietf.org; Sat, 21 Nov 2009 01:52:54 +0000 Received: from BLU137-DS5 ([65.55.116.7]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 17:52:54 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Subject: Consensus Call on Broadband Forum Next Steps Date: Fri, 20 Nov 2009 17:52:53 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01CA6A0A.48E07FD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpqTUVYdNkJUbxERw+zyz1b5r9yQQAAAnOw Content-Language: en-us X-OriginalArrivalTime: 21 Nov 2009 01:52:54.0045 (UTC) FILETIME=[57237CD0:01CA6A4D] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_006C_01CA6A0A.48E07FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As noted by David Miles in his post on September 23, 2009 (see http://ops.ietf.org/lists/radiusext/2009/msg00444.html) , the Broadband Forum has a need for additional RADIUS attributes in order to support their work on IPv6 access over PPP. To address the request from the Broadband Forum, the RADEXT WG held a session on IPv6 access during the RADEXT Virtual Interim meeting on October 13, 2009. During this meeting, consensus was reached on next steps with respect to the Broadband Forum request. The purpose of this message is to confirm the consensus reached during the interim meeting on those next steps. As described in the minutes of the RADEXT Virtual Interim meeting (see http://ops.ietf.org/lists/radiusext/2009/msg00531.html), a suggestion was made by David Miles to focus WG efforts on completion of work on IPv6 RADIUS attributes relevant to the work of the Broadband Forum (primarily IPv6-Address but also potentially DNS-Server-Address). In order to move forward, David volunteered to put together a document defining additional RADIUS Attributes for use in Broadband Forum IPv6 PPP usage scenarios. This document would include an overview of the Broadband Forum IPv6 over PPP architecture, while incorporating relevant attributes defined in a previously expired document, http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp. Assuming that the WG consensus was confirmed, David promised to prepare a document meeting this description for consideration. The Consensus Call will last until Friday, December 4, 2009. If you favor the consensus of the virtual interim meeting as described above (to focus on completing a document relating to the Broadband Forum's IPv6 over PPP scenarios), please reply to this email affirmatively, indicating your support for David's suggested next steps. If you oppose the consensus of the Virtual Interim, please reply indicating your opposition, as well as a potential alternate way forward. ------=_NextPart_000_006C_01CA6A0A.48E07FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As noted by David Miles in his post on September = 23, 2009 (see http://op= s.ietf.org/lists/radiusext/2009/msg00444.html) , the Broadband Forum has a need for additional RADIUS attributes in = order to support their work on IPv6 access over PPP. 

 

To address the request from the Broadband Forum, = the RADEXT WG held a session on IPv6 access during the RADEXT Virtual Interim meeting = on October 13, 2009.  During this meeting, consensus was reached on = next steps with respect to the Broadband Forum request.  The purpose of = this message is to confirm the consensus reached during the interim meeting = on those next steps. 

 

As described in the minutes of the RADEXT Virtual = Interim meeting (see http://op= s.ietf.org/lists/radiusext/2009/msg00531.html), a suggestion was made by David Miles to focus  WG efforts on = completion of work on IPv6 RADIUS attributes relevant to the work of the Broadband = Forum (primarily IPv6-Address but also potentially DNS-Server-Address).   In order to move forward, David volunteered to put together a = document defining additional RADIUS Attributes for use in Broadband Forum IPv6 = PPP usage scenarios.  This document would include an overview of the = Broadband Forum IPv6 over PPP architecture, while incorporating relevant attributes = defined in a previously expired document, http= ://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp.   Assuming that the WG consensus was confirmed, David promised = to prepare a document meeting this description for consideration. =

 

The Consensus Call will last until Friday, December = 4, 2009.  If you favor the consensus of the virtual interim meeting as described above (to focus on completing a document relating to the = Broadband Forum’s IPv6 over PPP scenarios), please reply to this email affirmatively, = indicating your support for David’s suggested next steps.   If you = oppose the consensus of the Virtual Interim, please reply indicating your = opposition, as well as a potential alternate way forward.

 

 

------=_NextPart_000_006C_01CA6A0A.48E07FD0-- -- to unsubscribe send a message to radiusext-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 Nov 20 18:03: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 07B2E3A6880 for ; Fri, 20 Nov 2009 18:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.542 X-Spam-Level: X-Spam-Status: No, score=-0.542 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 sM+EW1-gbztR for ; Fri, 20 Nov 2009 18:03:09 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9EEB13A6842 for ; Fri, 20 Nov 2009 18:03:08 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NBfGv-0007X5-9K for radiusext-data0@psg.com; Sat, 21 Nov 2009 02:00:21 +0000 Received: from [65.55.116.81] (helo=blu0-omc3-s6.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NBfGp-0007WI-Nx for radiusext@ops.ietf.org; Sat, 21 Nov 2009 02:00:15 +0000 Received: from BLU137-DS6 ([65.55.116.73]) by blu0-omc3-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 17:59:02 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Wojciech Dec \(wdec\)'" CC: "'Romascanu, Dan \(Dan\)'" , References: In-Reply-To: Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 20 Nov 2009 17:59:02 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01CA6A0B.24A99B00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxAAAQa5/AAAMdz4AVuTG4AACFW8VA= Content-Language: en-us X-OriginalArrivalTime: 21 Nov 2009 01:59:02.0752 (UTC) FILETIME=[32E7B600:01CA6A4E] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0076_01CA6A0B.24A99B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit At the Virtual Interim, the RADEXT WG held a session devoted to next steps on the IPv6 access work. During the session, David Miles suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. In order to confirm that consensus, the RADEXT WG has issued a Consensus Call to the mailing list (see http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please feel free to express your opinions on the list relating to the consensus that was reached at the Interim. From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Friday, November 20, 2009 2:03 AM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes Trying for the 4th time now: - could you confirm that what my mail outlined in terms of moving forward is also your expectation? - Are you now convinced of "interest"? (and if not, or partially, then on what grounds?) - could you point out (summarise)the issues that were not addressed? Thanks, Woj. ------=_NextPart_000_0076_01CA6A0B.24A99B00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the Virtual Interim, the RADEXT WG held a session = devoted to next steps on the IPv6 access work.  During the session, David = Miles suggested a path forward for the IPv6 Access work that appeared to have consensus = among the Virtual Interim attendees. 

 

In order to confirm that consensus, the RADEXT WG has = issued a Consensus Call to the mailing list (see   = http://ops.ietf.org/lists/radiusext/2009/msg00636.html).   Please feel free to express your opinions on the list relating to = the consensus that was reached at the Interim. =   

 

From:= owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On = Behalf Of Wojciech Dec (wdec)
Sent: Friday, November 20, 2009 2:03 AM
To: Bernard Aboba
Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interim = Minutes

 

Trying for the 4th time now:

 

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

- Are you now convinced of "interest"? (and if not, or = partially, then on what grounds?)

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

 

Thanks,

Woj.

 =

------=_NextPart_000_0076_01CA6A0B.24A99B00-- -- to unsubscribe send a message to radiusext-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 Nov 22 03:02: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 2CA013A67B8 for ; Sun, 22 Nov 2009 03:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.699 X-Spam-Level: X-Spam-Status: No, score=-7.699 tagged_above=-999 required=5 tests=[AWL=0.795, 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 0knAvEs7GBhG for ; Sun, 22 Nov 2009 03:02:12 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93E5B3A635F for ; Sun, 22 Nov 2009 03:02:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCA86-0009u3-1x for radiusext-data0@psg.com; Sun, 22 Nov 2009 10:57:18 +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 1NCA7z-0009tE-UF for radiusext@ops.ietf.org; Sun, 22 Nov 2009 10:57:12 +0000 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: AksAAFOnCEuQ/uCWe2dsb2JhbACCIyyNS4tvAQELCyQGnx6WWIQ8BIFwg2s X-IronPort-AV: E=Sophos;i="4.47,266,1257120000"; d="scan'208,217";a="54939911" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 22 Nov 2009 10:57:08 +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 nAMAv84P014511; Sun, 22 Nov 2009 10:57:08 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); Sun, 22 Nov 2009 11:57:08 +0100 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_01CA6B62.8915925E" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun, 22 Nov 2009 11:57:04 +0100 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/AAAMdz4AVuTG4AACFW8VAAREs84A== References: From: "Wojciech Dec (wdec)" To: "Bernard Aboba" Cc: "Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 22 Nov 2009 10:57:08.0735 (UTC) FILETIME=[894380F0:01CA6B62] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6B62.8915925E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, =20 this thread directly stems from the minutes of the meeting. On behalf of the draft authors I proposed a way forward and in relation to this I have asked you (as chair) repeatedly for some answers/clarifications. Now, given that at the n'th attempt you are still unable to answer them clearly is telling me and other folks that you're quite simply unwilling or unable to carry out your duties as chair of this WG.=20 =20 Thanks, Woj. ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 21 November 2009 02:59 To: Wojciech Dec (wdec) Cc: 'Romascanu, Dan (Dan)'; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 At the Virtual Interim, the RADEXT WG held a session devoted to next steps on the IPv6 access work. During the session, David Miles suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. =20 =20 In order to confirm that consensus, the RADEXT WG has issued a Consensus Call to the mailing list (see http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please feel free to express your opinions on the list relating to the consensus that was reached at the Interim. =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Friday, November 20, 2009 2:03 AM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 Trying for the 4th time now: =20 - 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?) - could you point out (summarise)the issues that were not addressed? =20 Thanks, Woj. =20 ------_=_NextPart_001_01CA6B62.8915925E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bernard,
 
this thread directly stems from the minutes of the = meeting. On=20 behalf of the draft authors I proposed a way forward and=20 in relation to this I have asked you (as = chair) repeatedly=20 for some answers/clarifications. Now, given that at the n'th = attempt you=20 are still unable to answer them clearly is telling me and other = folks=20 that you're quite simply unwilling or unable to carry out = your=20 duties as chair of this WG.
 
Thanks,
Woj.

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: 21 November 2009=20 02:59
To: Wojciech Dec (wdec)
Cc: 'Romascanu, Dan = (Dan)';=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

At=20 the Virtual Interim, the RADEXT WG held a session devoted to next = steps on the=20 IPv6 access work.  During the session, David Miles suggested a = path=20 forward for the IPv6 Access work that appeared to have consensus among = the=20 Virtual Interim attendees. 

 

In=20 order to confirm that consensus, the RADEXT WG has issued a Consensus = Call to=20 the mailing list (see  =20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html).  =  Please=20 feel free to express your opinions on the list relating to the = consensus that=20 was reached at the Interim.   

 

From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On=20 Behalf Of Wojciech Dec (wdec)
Sent: Friday, November 20, = 2009=20 2:03 AM
To: Bernard Aboba
Cc: Romascanu, Dan = (Dan);=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

 

Trying=20 for the 4th time now:

 

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

- Are you = now=20 convinced of "interest"? (and if not, or partially, then on what=20 grounds?)

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

 

Thanks,

Woj.

 

------_=_NextPart_001_01CA6B62.8915925E-- -- to unsubscribe send a message to radiusext-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 Nov 22 03:02: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 D724D3A67B8 for ; Sun, 22 Nov 2009 03:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.858 X-Spam-Level: X-Spam-Status: No, score=-7.858 tagged_above=-999 required=5 tests=[AWL=0.636, 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 RHuXV3auZoIJ for ; Sun, 22 Nov 2009 03:02:21 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ED9083A6839 for ; Sun, 22 Nov 2009 03:02:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCA85-0009tx-CS for radiusext-data0@psg.com; Sun, 22 Nov 2009 10:57:17 +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 1NCA7y-0009tE-GI for radiusext@ops.ietf.org; Sun, 22 Nov 2009 10:57:11 +0000 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: AkoAAFOnCEuQ/uCWe2dsb2JhbACCIS6ZOgEBCwskBp8elliEPASBcINr X-IronPort-AV: E=Sophos;i="4.47,266,1257120000"; d="scan'208,217";a="54939910" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 22 Nov 2009 10:57:08 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAMAv8Ar014505; Sun, 22 Nov 2009 10:57:08 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Nov 2009 11:57:08 +0100 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_01CA6B62.88C22010" Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Sun, 22 Nov 2009 11:54:30 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Call on Broadband Forum Next Steps Thread-Index: AcpqTUVYdNkJUbxERw+zyz1b5r9yQQAAAnOwAETEhnA= References: From: "Wojciech Dec (wdec)" To: "Bernard Aboba" , X-OriginalArrivalTime: 22 Nov 2009 10:57:08.0395 (UTC) FILETIME=[890F9FB0:01CA6B62] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6B62.88C22010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I disagree with the consensus statement below. As stated repeatedly on the thread, the pursuit of this draft has been a wild goose chase since the beginning and until further clarification is given, including actually answering to the draft authors, there is nothing which indicates that the statement below is not a continuation of this goose chase. The questions posed were clear and included a clarification of the intended way forward. =20 -Woj. =20 =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: 21 November 2009 02:53 To: radiusext@ops.ietf.org Subject: Consensus Call on Broadband Forum Next Steps =09 =09 As noted by David Miles in his post on September 23, 2009 (see http://ops.ietf.org/lists/radiusext/2009/msg00444.html) , the Broadband Forum has a need for additional RADIUS attributes in order to support their work on IPv6 access over PPP. =20 =20 To address the request from the Broadband Forum, the RADEXT WG held a session on IPv6 access during the RADEXT Virtual Interim meeting on October 13, 2009. During this meeting, consensus was reached on next steps with respect to the Broadband Forum request. The purpose of this message is to confirm the consensus reached during the interim meeting on those next steps. =20 =20 As described in the minutes of the RADEXT Virtual Interim meeting (see http://ops.ietf.org/lists/radiusext/2009/msg00531.html), a suggestion was made by David Miles to focus WG efforts on completion of work on IPv6 RADIUS attributes relevant to the work of the Broadband Forum (primarily IPv6-Address but also potentially DNS-Server-Address). In order to move forward, David volunteered to put together a document defining additional RADIUS Attributes for use in Broadband Forum IPv6 PPP usage scenarios. This document would include an overview of the Broadband Forum IPv6 over PPP architecture, while incorporating relevant attributes defined in a previously expired document, http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp. Assuming that the WG consensus was confirmed, David promised to prepare a document meeting this description for consideration.=20 =20 The Consensus Call will last until Friday, December 4, 2009. If you favor the consensus of the virtual interim meeting as described above (to focus on completing a document relating to the Broadband Forum's IPv6 over PPP scenarios), please reply to this email affirmatively, indicating your support for David's suggested next steps. If you oppose the consensus of the Virtual Interim, please reply indicating your opposition, as well as a potential alternate way forward.=20 =20 =20 ------_=_NextPart_001_01CA6B62.88C22010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 disagree with the consensus statement below. As stated repeatedly on the = thread,=20 the pursuit of this draft has been a wild goose chase since the = beginning and=20 until further clarification is given, including actually = answering to the=20 draft authors, there is nothing which indicates that the statement = below is=20 not a continuation of this goose chase. The questions posed were clear = and=20 included a clarification of the intended way = forward.
 
-Woj.
 
 

From: owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: 21 November 2009 02:53
To:=20 radiusext@ops.ietf.org
Subject: Consensus Call on Broadband = Forum=20 Next Steps

As noted by David Miles in his post on September = 23, 2009=20 (see http://op= s.ietf.org/lists/radiusext/2009/msg00444.html)=20 , the Broadband Forum has a need for additional RADIUS attributes in = order to=20 support their work on IPv6 access over PPP. 

 

To address the request from the Broadband Forum, = the RADEXT=20 WG held a session on IPv6 access during the RADEXT Virtual Interim = meeting on=20 October 13, 2009.  During this meeting, consensus was reached on = next=20 steps with respect to the Broadband Forum request.  The purpose = of this=20 message is to confirm the consensus reached during the interim meeting = on=20 those next steps. 

 

As described in the minutes of the RADEXT Virtual = Interim=20 meeting (see http://op= s.ietf.org/lists/radiusext/2009/msg00531.html),=20 a suggestion was made by David Miles to focus  WG efforts on = completion=20 of work on IPv6 RADIUS attributes relevant to the work of the = Broadband Forum=20 (primarily IPv6-Address but also potentially = DNS-Server-Address). =20  In order to move forward, David volunteered to put together a = document=20 defining additional RADIUS Attributes for use in Broadband Forum IPv6 = PPP=20 usage scenarios.  This document would include an overview of the=20 Broadband Forum IPv6 over PPP architecture, while incorporating = relevant=20 attributes defined in a previously expired document, http= ://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp.=20   Assuming that the WG consensus was confirmed, David = promised to=20 prepare a document meeting this description for consideration. =

 

The Consensus Call will last until Friday, = December 4,=20 2009.  If you favor the consensus of the virtual interim meeting = as=20 described above (to focus on completing a document relating to the = Broadband=20 Forum’s IPv6 over PPP scenarios), please reply to this email = affirmatively,=20 indicating your support for David’s suggested next = steps.   If you=20 oppose the consensus of the Virtual Interim, please reply indicating = your=20 opposition, as well as a potential alternate way forward. =

 

 

------_=_NextPart_001_01CA6B62.88C22010-- -- to unsubscribe send a message to radiusext-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 Nov 22 05:22: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 69E163A6A06 for ; Sun, 22 Nov 2009 05:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Zi4gkGpqpHj for ; Sun, 22 Nov 2009 05:22:16 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 23C083A67D4 for ; Sun, 22 Nov 2009 05:22:16 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCCLG-000M6T-C8 for radiusext-data0@psg.com; Sun, 22 Nov 2009 13:19:02 +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 1NCCLE-000M69-Jf for radiusext@ops.ietf.org; Sun, 22 Nov 2009 13:19:01 +0000 Received: from OMTA21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 8Cpk1d0081ZXKqc5BDJztQ; Sun, 22 Nov 2009 13:18:59 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA21.westchester.pa.mail.comcast.net with comcast id 8DSv1d0094H2mdz3hDSvXY; Sun, 22 Nov 2009 13:26:56 +0000 From: "Dave Nelson" To: Cc: "'Wojciech Dec \(wdec\)'" References: Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Sun, 22 Nov 2009 08:18:59 -0500 Message-ID: <4CA2F69AA99746FB881570A6C2FF7198@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: AcpqTUVYdNkJUbxERw+zyz1b5r9yQQAAAnOwAETEhnAABMhYIA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Wojciech Dec writes... > I disagree with the consensus statement below. Noted. > As stated repeatedly on the thread, the pursuit of this > draft has been a wild goose chase since the beginning and > until further clarification is given, including actually > answering=A0to the draft authors, there is nothing=A0which > indicates that the statement below is not a continuation > of this goose chase. The questions posed were clear and=20 > included a clarification of the intended way forward. To wit, on October 23, 2009 you wrote: We're currently planning on a two draft approach, pretty much reverting to the state prior to the=20 "merged draft", along with changes to rid of any=20 datatype issues (fingers crossed) and additional=20 explanatory text. Before we proceed on this path,=20 which to some may seem to be yet another goose chase, could you confirm that this is also your expectation? The process for advancing work in the RADEXT WG does not include any a priori guarantees that any particular draft revision will garner = sufficient support of the WG members to be adopted as a WG Work Item. It seems = like that's the assurance you're seeking, however. There have been repeated comments on the list about the design of the attributes in the -01 draft, including comments about the use of = tagging. You have previously responded that the current format falls within the blanket provisions of the string data type and that there are precedents = for such usage in other RFCs. Thus, your query of October 23 was the first indication that you might be willing to modify the design of those attributes to meet with WG approval. The way the process works is that you submit a revised draft that = addresses the comments received on the list, and then the WG reviews the new draft against the accumulated comments. If at that point in time there is significant interest in adopting the draft as a WG Work Item, the draft = can move forward. I'll remind you that when counting WG members that are interested in a given draft, and are willing to review and comment upon = the draft, the chairs don=92t count the authors. The chairs need to see = that there are sufficient non-author WG members interested in the work to = ensure *independent* review. In the absence of a new draft, another WG member, David Miles, proposed another way forward for a subset of the work in the "merged draft". The current consensus call on the WG mailing list is to determine if the consensus of the list matches the consensus of the WG at the Interim Meeting. That's always the way these things are done in the IETF, = consensus must be validated on the list. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Nov 22 07:34: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 8EC753A698C for ; Sun, 22 Nov 2009 07:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.543 X-Spam-Level: X-Spam-Status: No, score=-0.543 tagged_above=-999 required=5 tests=[AWL=-0.049, 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 pDG-tCIEkuKF for ; Sun, 22 Nov 2009 07:34:22 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9AF1D3A682D for ; Sun, 22 Nov 2009 07:34:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCENi-0008CK-66 for radiusext-data0@psg.com; Sun, 22 Nov 2009 15:29:42 +0000 Received: from [65.55.111.159] (helo=blu0-omc4-s20.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCENg-0008C8-VT for radiusext@ops.ietf.org; Sun, 22 Nov 2009 15:29:41 +0000 Received: from BLU137-W21 ([65.55.111.136]) by blu0-omc4-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Nov 2009 07:29:40 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_8d0d6558-af4d-49f6-ae86-47d72038edfd_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Sun, 22 Nov 2009 07:29:40 -0800 Importance: Normal In-Reply-To: <4CA2F69AA99746FB881570A6C2FF7198@NEWTON603> References: ,<4CA2F69AA99746FB881570A6C2FF7198@NEWTON603> MIME-Version: 1.0 X-OriginalArrivalTime: 22 Nov 2009 15:29:40.0449 (UTC) FILETIME=[9BA50D10:01CA6B88] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_8d0d6558-af4d-49f6-ae86-47d72038edfd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As David Nelson notes=2C it is the responsibility of the authors of a docum= ent to revise their document in response to comments submitted RADEXT WG pa= rticipants. =20 The minutes and the issues list (available at http://www.drizzle.com/~aboba= /RADEXT ) describe in considerable detail the issues that have been raised = with the document. These concerns range from the basic (insufficient arti= culation of the usage scenarios) to the specific (compatibility with RADIUS= Design Guidelines). Revision of a document in response to WG comments is= required prior to adoption as a WG work item for two reasons: 1. It demonstrates acceptance on the part of the authors in conforming to the processes and procedures of the IETF which require "rough consensus" for WG work products. =20 2. It demonstrates the interest of the authors to actually complete the wor= k.=20 At the RADEXT WG interim=2C we had a suggestion from David Miles for moving= forward which both addresses the concerns relating to context (by discussi= on of specific scenarios of interest to the Broadband Forum) as well as add= ressing review comments (by limiting the focus to attributes whose conforma= nce to Design Guidelines is not in dispute). Given the positive response= at the Virtual Interim=2C we are now attempting to determine whether there= is consensus for moving forward.=20 Past experience has shown that breaking off a piece of the problem in this = way has the potential to enable rapid progress. At the RADEXT WG Virtual I= nterim=2C specific next steps were presented=2C which included submission o= f a revised draft along the lines that David Miles has suggested. Preparat= ion of such a revised draft is not gated by this consensus call.=20 > Wojciech Dec writes... >=20 > > I disagree with the consensus statement below. >=20 > Noted. >=20 > > As stated repeatedly on the thread=2C the pursuit of this > > draft has been a wild goose chase since the beginning and > > until further clarification is given=2C including actually > > answering to the draft authors=2C there is nothing which > > indicates that the statement below is not a continuation > > of this goose chase. The questions posed were clear and=20 > > included a clarification of the intended way forward. >=20 > To wit=2C on October 23=2C 2009 you wrote: >=20 > We're currently planning on a two draft approach=2C > pretty much reverting to the state prior to the=20 > "merged draft"=2C along with changes to rid of any=20 > datatype issues (fingers crossed) and additional=20 > explanatory text. Before we proceed on this path=2C=20 > which to some may seem to be yet another goose chase=2C > could you confirm that this is also your expectation? >=20 > The process for advancing work in the RADEXT WG does not include any a > priori guarantees that any particular draft revision will garner sufficie= nt > support of the WG members to be adopted as a WG Work Item. It seems like > that's the assurance you're seeking=2C however. >=20 > There have been repeated comments on the list about the design of the > attributes in the -01 draft=2C including comments about the use of taggin= g. > You have previously responded that the current format falls within the > blanket provisions of the string data type and that there are precedents = for > such usage in other RFCs. Thus=2C your query of October 23 was the first > indication that you might be willing to modify the design of those > attributes to meet with WG approval. >=20 > The way the process works is that you submit a revised draft that address= es > the comments received on the list=2C and then the WG reviews the new draf= t > against the accumulated comments. If at that point in time there is > significant interest in adopting the draft as a WG Work Item=2C the draft= can > move forward. I'll remind you that when counting WG members that are > interested in a given draft=2C and are willing to review and comment upon= the > draft=2C the chairs don=92t count the authors. The chairs need to see th= at > there are sufficient non-author WG members interested in the work to ensu= re > *independent* review. >=20 > In the absence of a new draft=2C another WG member=2C David Miles=2C prop= osed > another way forward for a subset of the work in the "merged draft". The > current consensus call on the WG mailing list is to determine if the > consensus of the list matches the consensus of the WG at the Interim > Meeting. That's always the way these things are done in the IETF=2C cons= ensus > must be validated on the list. >=20 >=20 >=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: = --_8d0d6558-af4d-49f6-ae86-47d72038edfd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As David Nelson notes=2C it is the responsibility of the authors of a docum= ent to revise their document in response to comments submitted RADEXT WG pa= rticipants. =3B

The minutes and the issues list (available at http://www.drizzle.com/~a= boba/RADEXT ) describe in considerable detail the issues that have been rai= sed with the document. =3B =3B These concerns range from the basic = (insufficient articulation of the usage scenarios) to the specific (compati= bility with RADIUS Design Guidelines). =3B =3B Revision of a docume= nt in response to WG comments is required prior to adoption as a WG work it= em for two reasons:

1. It demonstrates acceptance on the part of the authors in conforming to the processes and procedures of the IETF which require "rough consensus" for WG work products. =3B
2. It demonstrates the interest of the authors to actually complete the wor= k.

At the RADEXT WG interim=2C we had a suggestion from David Miles= for moving forward which both addresses the concerns relating to context (= by discussion of specific scenarios of interest to the Broadband Forum) as = well as addressing review comments (by limiting the focus to attributes who= se conformance to Design Guidelines is not in dispute). =3B =3B&nbs= p=3B Given the positive response at the Virtual Interim=2C we are now attem= pting to determine whether there is consensus for moving forward.

P= ast experience has shown that breaking off a piece of the problem in this w= ay has the potential to enable rapid progress. =3B At the RADEXT WG Vir= tual Interim=2C specific next steps were presented=2C which included submis= sion of a revised draft along the lines that David Miles has suggested.&nbs= p=3B Preparation of such a revised draft is not gated by this consensus cal= l.






>=3B Wojciech Dec writes...
>=3B
= >=3B >=3B I disagree with the consensus statement below.
>=3B
= >=3B Noted.
>=3B
>=3B >=3B As stated repeatedly on the threa= d=2C the pursuit of this
>=3B >=3B draft has been a wild goose chase= since the beginning and
>=3B >=3B until further clarification is gi= ven=2C including actually
>=3B >=3B answering =3Bto the draft au= thors=2C there is nothing =3Bwhich
>=3B >=3B indicates that the = statement below is not a continuation
>=3B >=3B of this goose chase.= The questions posed were clear and
>=3B >=3B included a clarificat= ion of the intended way forward.
>=3B
>=3B To wit=2C on October = 23=2C 2009 you wrote:
>=3B
>=3B We're currently planning on= a two draft approach=2C
>=3B pretty much reverting to the state = prior to the
>=3B "merged draft"=2C along with changes to rid of= any
>=3B datatype issues (fingers crossed) and additional
&= gt=3B explanatory text. Before we proceed on this path=2C
>=3B = which to some may seem to be yet another goose chase=2C
>=3B = could you confirm that this is also your expectation?
>=3B
>=3B = The process for advancing work in the RADEXT WG does not include any a
&= gt=3B priori guarantees that any particular draft revision will garner suff= icient
>=3B support of the WG members to be adopted as a WG Work Item.= It seems like
>=3B that's the assurance you're seeking=2C however.>=3B
>=3B There have been repeated comments on the list about the= design of the
>=3B attributes in the -01 draft=2C including comments = about the use of tagging.
>=3B You have previously responded that the = current format falls within the
>=3B blanket provisions of the string = data type and that there are precedents for
>=3B such usage in other R= FCs. Thus=2C your query of October 23 was the first
>=3B indication t= hat you might be willing to modify the design of those
>=3B attributes= to meet with WG approval.
>=3B
>=3B The way the process works i= s that you submit a revised draft that addresses
>=3B the comments rec= eived on the list=2C and then the WG reviews the new draft
>=3B agains= t the accumulated comments. If at that point in time there is
>=3B si= gnificant interest in adopting the draft as a WG Work Item=2C the draft can=
>=3B move forward. I'll remind you that when counting WG members tha= t are
>=3B interested in a given draft=2C and are willing to review an= d comment upon the
>=3B draft=2C the chairs don=92t count the authors.= The chairs need to see that
>=3B there are sufficient non-author WG = members interested in the work to ensure
>=3B *independent* review.>=3B
>=3B In the absence of a new draft=2C another WG member=2C Da= vid Miles=2C proposed
>=3B another way forward for a subset of the wor= k in the "merged draft". The
>=3B current consensus call on the WG ma= iling list is to determine if the
>=3B consensus of the list matches t= he consensus of the WG at the Interim
>=3B Meeting. That's always the= way these things are done in the IETF=2C consensus
>=3B must be valid= ated on the list.
>=3B
>=3B
>=3B
>=3B --
>=3B t= o unsubscribe send a message to radiusext-request@ops.ietf.org with
>= =3B the word 'unsubscribe' in a single line as the message text body.
&g= t=3B archive: <=3Bhttp://psg.com/lists/radiusext/>=3B
= --_8d0d6558-af4d-49f6-ae86-47d72038edfd_-- -- to unsubscribe send a message to radiusext-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 Nov 22 07:54: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 302A03A68E7 for ; Sun, 22 Nov 2009 07:54:27 -0800 (PST) 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 L0wGVV0bWJwV for ; Sun, 22 Nov 2009 07:54:26 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 637843A686C for ; Sun, 22 Nov 2009 07:54:26 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCEjr-000AU4-Ks for radiusext-data0@psg.com; Sun, 22 Nov 2009 15:52:35 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCEjq-000ATi-PT for radiusext@ops.ietf.org; Sun, 22 Nov 2009 15:52:34 +0000 Message-ID: <4B095E41.1080202@deployingradius.com> Date: Sun, 22 Nov 2009 16:52:33 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: Re: Consensus Call on Broadband Forum Next Steps References: ,<4CA2F69AA99746FB881570A6C2FF7198@NEWTON603> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > Past experience has shown that breaking off a piece of the problem in > this way has the potential to enable rapid progress. At the RADEXT WG > Virtual Interim, specific next steps were presented, which included > submission of a revised draft along the lines that David Miles has > suggested. Preparation of such a revised draft is not gated by this > consensus call. I would like to see an updated draft prior to responding to the consensus call. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Nov 22 08:09: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 C95843A6932 for ; Sun, 22 Nov 2009 08:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 qu5Ekp4LOaZd for ; Sun, 22 Nov 2009 08:09:31 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 385703A68B7 for ; Sun, 22 Nov 2009 08:09:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCExi-000Bne-JQ for radiusext-data0@psg.com; Sun, 22 Nov 2009 16:06:54 +0000 Received: from [65.55.116.102] (helo=blu0-omc3-s27.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCExh-000BnP-Hz for radiusext@ops.ietf.org; Sun, 22 Nov 2009 16:06:53 +0000 Received: from BLU137-W15 ([65.55.116.72]) by blu0-omc3-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Nov 2009 08:06:52 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_c4a775fb-8427-4513-9cb8-9710ca13084d_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: CC: "dromasca@avaya.com" , "radiusext@ops.ietf.org" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun, 22 Nov 2009 08:06:52 -0800 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 22 Nov 2009 16:06:52.0675 (UTC) FILETIME=[CE27B530:01CA6B8D] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_c4a775fb-8427-4513-9cb8-9710ca13084d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Woj -- The meetings of the RADEXT WG are openly publicized and are available to an= yone (including people who are not physically present). Presentations and = agenda items are openly solicited. If you would like time on the agenda of= a physical or virtual meeting=2C all you need to do is to post a message t= o the WG list and your request will be honored. =20 In your initial message (see http://ops.ietf.org/lists/radiusext/2009/msg00= 552.html) you requested guidance as to whether it would be better for the w= ork on IPv6 access to proceed with a draft focusing on an initial set of at= tributes along the lines of the original submission (http://tools.ietf.org/= html/draft-lourdelet-radext-ipv6-dhcp-00)=2C or whether a combined submissi= on would be preferable=2C along the lines of the -01 submission.=20 That is exactly the issue that is now under consideration within the Consen= sus Call that has been issued. As noted in the virtual interim minutes=2C = David Miles has suggested that the focused approach would be more likely to= result in rapid progress=2C and other participants at the Virtual Interim = agreed with this suggestion.=20 Since the IETF operates on "rough consensus"=2C it is the duty of the Chair= s to engage the WG participants on issues such as these=2C rather than maki= ng unilateral decisions.=20 Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun=2C 22 Nov 2009 11:57:04 +0100 From: wdec@cisco.com To: bernard_aboba@hotmail.com CC: dromasca@avaya.com=3B radiusext@ops.ietf.org Bernard=2C =20 this thread directly stems from the minutes of the meeting. On=20 behalf of the draft authors I proposed a way forward and=20 in relation to this I have asked you (as chair) repeatedly=20 for some answers/clarifications. Now=2C given that at the n'th attempt you= =20 are still unable to answer them clearly is telling me and other folks=20 that you're quite simply unwilling or unable to carry out your=20 duties as chair of this WG.=20 =20 Thanks=2C Woj. =20 =20 From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]=20 Sent: 21 November 2009=20 02:59 To: Wojciech Dec (wdec) Cc: 'Romascanu=2C Dan (Dan)'=3B=20 radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim=20 Minutes =20 =20 At=20 the Virtual Interim=2C the RADEXT WG held a session devoted to next steps= on the=20 IPv6 access work. During the session=2C David Miles suggested a path=20 forward for the IPv6 Access work that appeared to have consensus among th= e=20 Virtual Interim attendees. =20 =20 In=20 order to confirm that consensus=2C the RADEXT WG has issued a Consensus C= all to=20 the mailing list (see =20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please=20 feel free to express your opinions on the list relating to the consensus = that=20 was reached at the Interim. =20 =20 =20 =20 From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On=20 Behalf Of Wojciech Dec (wdec) Sent: Friday=2C November 20=2C 2009=20 2:03 AM To: Bernard Aboba Cc: Romascanu=2C Dan (Dan)=3B=20 radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim=20 Minutes =20 Trying=20 for the 4th time now: =20 -=20 could you=20 confirm that what my mail outlined in terms of moving=20 forward is also your expectation?=20 - Are you now=20 convinced of "interest"? (and if not=2C or partially=2C then on what=20 grounds?) - could you point out=20 (summarise)the issues that were not addressed? =20 Thanks=2C Woj. =20 =20 =20 = --_c4a775fb-8427-4513-9cb8-9710ca13084d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Woj --

The meetings of the RADEXT WG are openly publicized and are a= vailable to anyone (including people who are not physically present). = =3B Presentations and agenda items are openly solicited. =3B If you wou= ld like time on the agenda of a physical or virtual meeting=2C all you need= to do is to post a message to the WG list and your request will be honored= . =3B

In your initial message (see http://ops.ietf.org/lists/ra= diusext/2009/msg00552.html) you requested guidance as to whether it would b= e better for the work on IPv6 access to proceed with a draft focusing on an= initial set of attributes along the lines of the original submission (http= ://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00)=2C or whether a= combined submission would be preferable=2C along the lines of the -01 subm= ission.

That is exactly the issue that is now under consideration w= ithin the Consensus Call that has been issued. =3B As noted in the virt= ual interim minutes=2C David Miles has suggested that the focused approach = would be more likely to result in rapid progress=2C and other participants = at the Virtual Interim agreed with this suggestion.

Since the IETF = operates on "rough consensus"=2C it is the duty of the Chairs to engage the= WG participants on issues such as these=2C rather than making unilateral d= ecisions.

Subject: RE: Draft RADEXT Virtual= Interim Minutes
Date: Sun=2C 22 Nov 2009 11:57:04 +0100
From: wdec@c= isco.com
To: bernard_aboba@hotmail.com
CC: dromasca@avaya.com=3B radi= usext@ops.ietf.org

Bernard=2C
 =3B
this thread directly stems from the minutes of t= he meeting. =3BOn=20 behalf of the draft authors I =3Bproposed =3Ba way forward and=20 in =3Brelation to this =3BI =3Bhave asked you (as chair) = =3Brepeatedly=20 for some answers/clarifications. Now=2C given that at the n'th attempt = =3Byou=20 are still unable to answer them clearly =3Bis telling me and other folk= s=20 that =3Byou're quite =3Bsimply unwilling or unable =3Bto carry = out your=20 duties as chair of this WG.
=  =3B
= Thanks=2C
= Woj.

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: 21 November 2009=20 02:59
To: Wojciech Dec (wdec)
Cc: 'Romascanu=2C Dan (= Dan)'=3B=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interi= m=20 Minutes

At=20 the Virtual Interim=2C the RADEXT WG held a session devoted to next steps= on the=20 IPv6 access work. =3B During the session=2C David Miles suggested a p= ath=20 forward for the IPv6 Access work that appeared to have consensus among th= e=20 Virtual Interim attendees. =3B

 =3B=

In=20 order to confirm that consensus=2C the RADEXT WG has issued a Consensus C= all to=20 the mailing list (see =3B =3B=20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html). =3B  =3B= Please=20 feel free to express your opinions on the list relating to the consensus = that=20 was reached at the Interim.  =3B =3B

 =3B=

From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= =20 Behalf Of Wojciech Dec (wdec)
Sent: Friday=2C November 20= =2C 2009=20 2:03 AM
To: Bernard Aboba
Cc: Romascanu=2C Dan (Dan)= =3B=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interi= m=20 Minutes

 =3B

Trying=20 for the 4th time now:

 =3B

-=20 could you=20 confirm that =3Bwhat =3Bmy mail =3Boutlined in terms of movin= g=20 forward =3Bis also your expectation? =3B

- Are you now=20 convinced of "interest"? (and if not=2C or partially=2C then on what=20 grounds?)

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

 =3B=

Thanks=2C

Woj.<= /p>

 =3B

= --_c4a775fb-8427-4513-9cb8-9710ca13084d_-- -- to unsubscribe send a message to radiusext-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 Nov 22 08:49: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 671343A6859 for ; Sun, 22 Nov 2009 08:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.207 X-Spam-Level: X-Spam-Status: No, score=0.207 tagged_above=-999 required=5 tests=[AWL=-0.788, 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 zStIZF9yojAd for ; Sun, 22 Nov 2009 08:49:45 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E87303A681E for ; Sun, 22 Nov 2009 08:49:44 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCFY6-000F0E-N1 for radiusext-data0@psg.com; Sun, 22 Nov 2009 16:44:30 +0000 Received: from [65.55.111.100] (helo=blu0-omc2-s25.blu0.hotmail.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCFY4-000Ezw-LU for radiusext@ops.ietf.org; Sun, 22 Nov 2009 16:44:28 +0000 Received: from BLU137-W36 ([65.55.111.73]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Nov 2009 08:44:27 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_49ff6259-b376-4ef3-952a-ae1c6049cb71_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Alan DeKok CC: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Sun, 22 Nov 2009 08:44:28 -0800 Importance: Normal In-Reply-To: <4B095E41.1080202@deployingradius.com> References: ,<4CA2F69AA99746FB881570A6C2FF7198@NEWTON603> ,<4B095E41.1080202@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 22 Nov 2009 16:44:27.0910 (UTC) FILETIME=[0E614260:01CA6B93] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_49ff6259-b376-4ef3-952a-ae1c6049cb71_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alan DeKok said: "I would like to see an updated draft prior to responding to the consensus = call".=20 [BA] Since IETF "Working Groups" make progress through the revision of docu= ments in response to comments from WG participants (that is=2C by doing wor= k)=2C there is no doubt that an updated draft would represent a welcome dev= elopment. In fact=2C it is hard to imagine how any progress can be made w= ithout such a submission. After all=2C there can be no progress within a "= Working Group" without actual work being accomplished.=20 At the Virtual Interim meeting=2C David Miles indicated an interest in prod= ucing such a submission=2C and the meeting participants provided encouragem= ent for him to proceed along the lines he suggested. Since such a draft w= ould represent an individual submission and the draft submission window is = open=2C it can be submitted at any time.=20 Nevertheless=2C we have received a request for additional guidance (see htt= p://ops.ietf.org/lists/radiusext/2009/msg00552.html) and in order to respon= d to the request=2C a Consensus Call has been issued. Rather than represen= ting a formal Call for Adoption=2C this Consensus Call is merely attempting= to determine whether the approach proposed by David Miles (which envisaged= a focused draft addressing the open issues and incorporating elements of h= ttp://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00) represents a= potential way forward. Given that the draft which David Miles suggested does not actually exist=2C= I can understand why WG participants might feel some level of discomfort i= n rendering a judgment on its suitability=2C particularly since the issues = raised in previous WG discussions (listed on the RADEXT WG Issue list at ht= tp://www.drizzle.com/~aboba/RADEXT) have remained unaddressed for some time= . Just as most of us are uncomfortable with signing a blank check=2C ther= e may naturally be concern that the results of the Consensus Call could be = misinterpreted as a blanket endorsement for a subsequent revision=2C regard= less of its contents. =20 While we certainly do not want to encourage such a mis-interpretation=2C gi= ven the lack of progress thus far and the repeated requests for "guidance"= =2C the Consensus Call seemed like the best way to address the specific que= stion that was asked on the list.=20 However=2C this is not the only way to make progress. For those not comfor= table responding to the Consensus Call=2C it is still possible to contribut= e in other ways. As you alluded to=2C the foremost way would be to submit = a draft addressing the issues that have been raised in previous WG discussi= ons in physical and virtual meetings as well as on the list. However=2C an= alternative way to contribute would be by submitting reviews of one or mor= e of the existing documents=2C including http://tools.ietf.org/html/draft-l= ourdelet-radext-ipv6-dhcp-00.=20 = --_49ff6259-b376-4ef3-952a-ae1c6049cb71_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alan DeKok said:

"I would like to see an updated draft prior to resp= onding to the consensus call".

[BA] Since IETF "Working Groups" mak= e progress through the revision of documents in response to comments from W= G participants (that is=2C by doing work)=2C there is no doubt that an upda= ted draft would represent a welcome development. =3B =3B In fact=2C= it is hard to imagine how any progress can be made without such a submissi= on. =3B After all=2C there can be no progress within a "Working Group" = without actual work being accomplished.

At the Virtual Interim meet= ing=2C David Miles indicated an interest in producing such a submission=2C = and the meeting participants provided encouragement for him to proceed alon= g the lines he suggested. =3B =3B Since such a draft would represen= t an individual submission and the draft submission window is open=2C it ca= n be submitted at any time.

Nevertheless=2C we have received a requ= est for additional guidance (see http://ops.ietf.org/lists/radiusext/2009/m= sg00552.html) and in order to respond to the request=2C a Consensus Call ha= s been issued. =3B Rather than representing a formal Call for Adoption= =2C this Consensus Call is merely attempting to determine whether the appro= ach proposed by David Miles (which envisaged a focused draft addressing the= open issues and incorporating elements of http://tools.ietf.org/html/draft= -lourdelet-radext-ipv6-dhcp-00) represents a potential way forward.

= Given that the draft which David Miles suggested does not actually exist=2C= I can understand why WG participants might feel some level of discomfort i= n rendering a judgment on its suitability=2C particularly since the issues = raised in previous WG discussions (listed on the RADEXT WG Issue list at ht= tp://www.drizzle.com/~aboba/RADEXT) have remained unaddressed for some time= . =3B =3B Just as most of us are uncomfortable with signing a blank= check=2C there may naturally be concern that the results of the Consensus = Call could be misinterpreted as a blanket endorsement for a subsequent revi= sion=2C regardless of its contents. =3B

While we certainly do n= ot want to encourage such a mis-interpretation=2C given the lack of progres= s thus far and the repeated requests for "guidance"=2C the Consensus Call s= eemed like the best way to address the specific question that was asked on = the list.

However=2C this is not the only way to make progress.&nbs= p=3B For those not comfortable responding to the Consensus Call=2C it is st= ill possible to contribute in other ways. =3B As you alluded to=2C the = foremost way would be to submit a draft addressing the issues that have bee= n raised in previous WG discussions in physical and virtual meetings as wel= l as on the list. =3B However=2C an alternative way to contribute would= be by submitting reviews of one or more of the existing documents=2C inclu= ding http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00.

= --_49ff6259-b376-4ef3-952a-ae1c6049cb71_-- -- to unsubscribe send a message to radiusext-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 Nov 22 09: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 444CE3A681D for ; Sun, 22 Nov 2009 09:25:22 -0800 (PST) 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 1JXoUMjnKQ4E for ; Sun, 22 Nov 2009 09:25:21 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 63AEB3A67C1 for ; Sun, 22 Nov 2009 09:25:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCG9m-000IKA-00 for radiusext-data0@psg.com; Sun, 22 Nov 2009 17:23:26 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCG9l-000IJy-Bi for radiusext@ops.ietf.org; Sun, 22 Nov 2009 17:23:25 +0000 Message-ID: <4B09738B.5050403@deployingradius.com> Date: Sun, 22 Nov 2009 18:23:23 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: Re: Consensus Call on Broadband Forum Next Steps References: ,<4CA2F69AA99746FB881570A6C2FF7198@NEWTON603> ,<4B095E41.1080202@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: > While we certainly do not want to encourage such a mis-interpretation, > given the lack of progress thus far and the repeated requests for > "guidance", the Consensus Call seemed like the best way to address the > specific question that was asked on the list. I believe the document(s) can be updated, and should then be accepted as WG items. 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 Nov 23 03:51: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 5D4BD3A6830 for ; Mon, 23 Nov 2009 03:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=-0.948, 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 2X4BW4f-g2Hx for ; Mon, 23 Nov 2009 03:51:47 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B02D73A67EF for ; Mon, 23 Nov 2009 03:51:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCXNH-0004KI-Op for radiusext-data0@psg.com; Mon, 23 Nov 2009 11:46:31 +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 1NCXNG-0004K1-AX for radiusext@ops.ietf.org; Mon, 23 Nov 2009 11:46:30 +0000 X-IronPort-AV: E=Sophos;i="4.47,271,1257138000"; d="scan'208,217";a="191287538" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Nov 2009 06:46:27 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 23 Nov 2009 06:46:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6C32.8D906335" Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Mon, 23 Nov 2009 12:46:15 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Call on Broadband Forum Next Steps Thread-Index: Acprk4W/5rWkelX5TXiQ/WKQDdQRrgAndh+Q References: ,<4CA2F69AA99746FB881570A6C2FF7198@NEWTON603> ,<4B095E41.1080202@deployingradius.com> From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , "Alan DeKok" Cc: "David B. Nelson" , Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6C32.8D906335 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I feel the need to intervene with a question which is also a suggestion about a possible way forward. Would it be possible for co-authors of draft-lourdelet-radext-ipv6-dhcp together with David Miles to get together and provide an updated version of the I-D (adding of course David as a co-author) which would incorporate the elements of David's way forward suggestion made at the interim meeting and address to the possible extend comments and concerns expressed relative to draft-lourdelet-radext-ipv6-dhcp-00? The WG members could address better the consensus question with a document in front of them in my opinion.=20 =20 Dan =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Sunday, November 22, 2009 6:44 PM To: Alan DeKok Cc: David B. Nelson; radiusext@ops.ietf.org Subject: RE: Consensus Call on Broadband Forum Next Steps =09 =09 Alan DeKok said: =09 "I would like to see an updated draft prior to responding to the consensus call".=20 =09 [BA] Since IETF "Working Groups" make progress through the revision of documents in response to comments from WG participants (that is, by doing work), there is no doubt that an updated draft would represent a welcome development. In fact, it is hard to imagine how any progress can be made without such a submission. After all, there can be no progress within a "Working Group" without actual work being accomplished.=20 =09 At the Virtual Interim meeting, David Miles indicated an interest in producing such a submission, and the meeting participants provided encouragement for him to proceed along the lines he suggested. Since such a draft would represent an individual submission and the draft submission window is open, it can be submitted at any time.=20 =09 Nevertheless, we have received a request for additional guidance (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) and in order to respond to the request, a Consensus Call has been issued. Rather than representing a formal Call for Adoption, this Consensus Call is merely attempting to determine whether the approach proposed by David Miles (which envisaged a focused draft addressing the open issues and incorporating elements of http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00) represents a potential way forward. =09 Given that the draft which David Miles suggested does not actually exist, I can understand why WG participants might feel some level of discomfort in rendering a judgment on its suitability, particularly since the issues raised in previous WG discussions (listed on the RADEXT WG Issue list at http://www.drizzle.com/~aboba/RADEXT) have remained unaddressed for some time. Just as most of us are uncomfortable with signing a blank check, there may naturally be concern that the results of the Consensus Call could be misinterpreted as a blanket endorsement for a subsequent revision, regardless of its contents. =20 =09 While we certainly do not want to encourage such a mis-interpretation, given the lack of progress thus far and the repeated requests for "guidance", the Consensus Call seemed like the best way to address the specific question that was asked on the list.=20 =09 However, this is not the only way to make progress. For those not comfortable responding to the Consensus Call, it is still possible to contribute in other ways. As you alluded to, the foremost way would be to submit a draft addressing the issues that have been raised in previous WG discussions in physical and virtual meetings as well as on the list. However, an alternative way to contribute would be by submitting reviews of one or more of the existing documents, including http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00.=20 =09 =09 =09 ------_=_NextPart_001_01CA6C32.8D906335 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I feel the=20 need to intervene with a question which is also a suggestion = about a=20 possible way forward. Would it be possible for co-authors of draft-lourdelet-radext-ipv6-dhcp=20 together with David Miles to get together = and provide=20 an updated version of the I-D (adding of course David as a co-author) = which=20 would incorporate the elements of David's way forward suggestion made at = the=20 interim meeting and address to the possible extend comments and concerns = expressed relative to draft-lourdelet-radext-ipv6-dhcp-00? The WG = members could=20 address better the consensus question with a document in front of them = in my=20 opinion.
 
Dan
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Sunday, November 22, 2009 6:44 PM
To: = Alan=20 DeKok
Cc: David B. Nelson; = radiusext@ops.ietf.org
Subject:=20 RE: Consensus Call on Broadband Forum Next Steps

Alan DeKok said:

"I would like to see an updated = draft prior=20 to responding to the consensus call".

[BA] Since IETF "Working = Groups"=20 make progress through the revision of documents in response to = comments from=20 WG participants (that is, by doing work), there is no doubt that an = updated=20 draft would represent a welcome development.   In fact, it = is hard=20 to imagine how any progress can be made without such a = submission.  After=20 all, there can be no progress within a "Working Group" without actual = work=20 being accomplished.

At the Virtual Interim meeting, David = Miles=20 indicated an interest in producing such a submission, and the meeting=20 participants provided encouragement for him to proceed along the lines = he=20 suggested.   Since such a draft would represent an = individual=20 submission and the draft submission window is open, it can be = submitted at any=20 time.

Nevertheless, we have received a request for additional = guidance=20 (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) and in = order to=20 respond to the request, a Consensus Call has been issued.  Rather = than=20 representing a formal Call for Adoption, this Consensus Call is merely = attempting to determine whether the approach proposed by David Miles = (which=20 envisaged a focused draft addressing the open issues and incorporating = elements of = http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00)=20 represents a potential way forward.

Given that the draft which = David=20 Miles suggested does not actually exist, I can understand why WG = participants=20 might feel some level of discomfort in rendering a judgment on its=20 suitability, particularly since the issues raised in previous WG = discussions=20 (listed on the RADEXT WG Issue list at = http://www.drizzle.com/~aboba/RADEXT)=20 have remained unaddressed for some time.   Just as most of = us are=20 uncomfortable with signing a blank check, there may naturally be = concern that=20 the results of the Consensus Call could be misinterpreted as a blanket = endorsement for a subsequent revision, regardless of its = contents. =20

While we certainly do not want to encourage such a = mis-interpretation,=20 given the lack of progress thus far and the repeated requests for = "guidance",=20 the Consensus Call seemed like the best way to address the specific = question=20 that was asked on the list.

However, this is not the only way = to make=20 progress.  For those not comfortable responding to the Consensus = Call, it=20 is still possible to contribute in other ways.  As you alluded = to, the=20 foremost way would be to submit a draft addressing the issues that = have been=20 raised in previous WG discussions in physical and virtual meetings as = well as=20 on the list.  However, an alternative way to contribute would be = by=20 submitting reviews of one or more of the existing documents, including = http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00.=20


------_=_NextPart_001_01CA6C32.8D906335-- -- to unsubscribe send a message to radiusext-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 Nov 23 05: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 36A303A67F4 for ; Mon, 23 Nov 2009 05:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.964 X-Spam-Level: X-Spam-Status: No, score=-7.964 tagged_above=-999 required=5 tests=[AWL=0.530, 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 qcYYncjnwTOE for ; Mon, 23 Nov 2009 05:02:13 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 31C5A3A6A60 for ; Mon, 23 Nov 2009 05:02:13 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCYTj-000BNd-D5 for radiusext-data0@psg.com; Mon, 23 Nov 2009 12:57:15 +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 1NCYTh-000BMx-Fg for radiusext@ops.ietf.org; Mon, 23 Nov 2009 12:57:14 +0000 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: AocAAC8VCkuQ/uCWe2dsb2JhbACCIy2NTYpigQ8BAQsLJAagbpZigi0VgXoEgXCDa4dZ X-IronPort-AV: E=Sophos;i="4.47,272,1257120000"; d="scan'208,217";a="55003902" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2009 12:57:12 +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 nANCvCaP018419; Mon, 23 Nov 2009 12:57:12 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); Mon, 23 Nov 2009 13:57:12 +0100 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_01CA6C3C.77F6F21C" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Mon, 23 Nov 2009 13:53:30 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: Acprjd9VBMqcnZtIQFWbEkSBR8TIgQAnYNrw References: , From: "Wojciech Dec (wdec)" To: "Bernard Aboba" Cc: , X-OriginalArrivalTime: 23 Nov 2009 12:57:12.0513 (UTC) FILETIME=[79768B10:01CA6C3C] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6C3C.77F6F21C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, =20 as explained in http://www.ops.ietf.org/lists/radiusext/2009/msg00558.html the draft has been repeatedly presented, modified based on WG feedback and re-presented (or attempted to). The fact that now there seems to be some opinion, consisting effectively of adding descriptive text and an author, etc, does not address the basic question of what were the issues with the previous draft that have not yet been addressed? In other words and perhaps fundamentally, before issuing a consensus call we all would like to know what are the issues with the originally proposed draft? =20 Draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access -00, which had no data-type/tagging controversy and which was presented at IETF74 was claimed to have issues (that actually resulted in 01). This -00 draft now however appears to bear all the hallmarks of what's been claimed as the "virtual meeting" consented way forward, give or take additional descriptive text. Have the issues have disappeared? Persistently, it has also been claimed that there was no interest in the draft. Is there now interest? My simple 3 questions were aimed at clarifying all this, but despite asking numerous times received no clear reply other than some stonewalling (eg check the minutes), or a "consensus call" message which was very odd for a non WG draft to say the least. The implied messaging of changing draft authorship was also highly inconsiderate. =20 Now the above is just one of the many bizarre twists in the story of this draft and its "progress" in Radex. I could go on and on, including pointing out chair-101 items like that; enquiries regarding virtual meeting went un-answered; that meeting conclusions have no IETF binding status; that there is no obligation to attend meetings (esp ones scheduled in a diff time zone); and that having a discussion on draft *without* any of the draft authors present is highly unusual if not down right wrong. =20 The bottom line as I see it is that instead of facilitating WG progress, the activity of the WG chairs has and continues to hinder such progress (eg by refusing to even summarize what are any outstanding issues), as well as evidencing some rather dubious chairing practices.=20 Generalizing from this experience, I can say that the authors of the draft have the distinct impression that any extensions to Radius are actually less than welcome by the chairs of the Radext WG. =20 regards, Woj. =20 =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: 22 November 2009 17:07 To: Wojciech Dec (wdec) Cc: dromasca@avaya.com; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 Woj -- =09 The meetings of the RADEXT WG are openly publicized and are available to anyone (including people who are not physically present). Presentations and agenda items are openly solicited. If you would like time on the agenda of a physical or virtual meeting, all you need to do is to post a message to the WG list and your request will be honored. =20 =09 In your initial message (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you requested guidance as to whether it would be better for the work on IPv6 access to proceed with a draft focusing on an initial set of attributes along the lines of the original submission (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00), or whether a combined submission would be preferable, along the lines of the -01 submission.=20 =09 That is exactly the issue that is now under consideration within the Consensus Call that has been issued. As noted in the virtual interim minutes, David Miles has suggested that the focused approach would be more likely to result in rapid progress, and other participants at the Virtual Interim agreed with this suggestion.=20 =09 Since the IETF operates on "rough consensus", it is the duty of the Chairs to engage the WG participants on issues such as these, rather than making unilateral decisions.=20 =09 =09 ________________________________ Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun, 22 Nov 2009 11:57:04 +0100 From: wdec@cisco.com To: bernard_aboba@hotmail.com CC: dromasca@avaya.com; radiusext@ops.ietf.org =09 =09 Bernard, =20 this thread directly stems from the minutes of the meeting. On behalf of the draft authors I proposed a way forward and in relation to this I have asked you (as chair) repeatedly for some answers/clarifications. Now, given that at the n'th attempt you are still unable to answer them clearly is telling me and other folks that you're quite simply unwilling or unable to carry out your duties as chair of this WG.=20 =20 Thanks, Woj. ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 21 November 2009 02:59 To: Wojciech Dec (wdec) Cc: 'Romascanu, Dan (Dan)'; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 At the Virtual Interim, the RADEXT WG held a session devoted to next steps on the IPv6 access work. During the session, David Miles suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. =20 =20 In order to confirm that consensus, the RADEXT WG has issued a Consensus Call to the mailing list (see http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please feel free to express your opinions on the list relating to the consensus that was reached at the Interim. =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Friday, November 20, 2009 2:03 AM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 Trying for the 4th time now: =20 - 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?) - could you point out (summarise)the issues that were not addressed? =20 Thanks, Woj. =20 ------_=_NextPart_001_01CA6C3C.77F6F21C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bernard,
 
as=20 explained in http:= //www.ops.ietf.org/lists/radiusext/2009/msg00558.html the=20 draft has been repeatedly presented, modified based on WG feedback = and=20 re-presented (or attempted to).
The fact=20 that now there seems to be some opinion, consisting effectively of = adding=20 descriptive text and an author, etc, does not address the = basic=20 question of what were the issues with the previous draft that have = not yet=20 been addressed? In other words and perhaps fundamentally, before = issuing a=20 consensus call we all would like to know what are the issues with = the=20 originally proposed draft?
 
Draft=20 http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access= -00,=20 which had no data-type/tagging controversy and which was = presented at=20 IETF74 was claimed to have issues (that actually resulted in 01). This = -00 draft=20 now however appears to bear all the hallmarks of what's been = claimed as the=20 "virtual meeting" consented way forward, give or take additional=20 descriptive text. Have the issues have disappeared?=20 Persistently, it has also been claimed = that there=20 was no interest in the draft. Is there now=20 interest?
My simple 3 = questions=20 were aimed at clarifying all this, but despite asking numerous times = received no=20 clear reply other than some stonewalling (eg check the minutes), = or a=20 "consensus call" message which was very odd for a=20 non WG draft to say the least. The implied messaging of = changing draft=20 authorship was also highly = inconsiderate.
 
Now the = above is=20 just one of the many bizarre twists in the story of this = draft and its=20 "progress" in Radex. I could go on and on, including pointing out = chair-101=20 items like that; enquiries regarding virtual meeting went = un-answered;=20 that meeting conclusions have no IETF  binding status; = that there=20 is no obligation to attend meetings (esp ones scheduled in a diff time = zone);=20 and that having a discussion on draft *without* any of the draft = authors=20 present is highly unusual if not down right=20 wrong.
 
The bottom line as I=20 see it is that instead of facilitating WG progress, the activity of = the=20 WG chairs has and continues to hinder such progress (eg by = refusing to=20 even summarize what are any outstanding issues), as well as=20 evidencing some rather dubious chairing practices.=20
Generalizing = from this=20 experience, I can say that the authors of the draft have the = distinct=20 impression that any extensions to Radius are actually less = than welcome by=20 the chairs of the Radext WG.
 
regards,
Woj.
 
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: 22 November 2009 17:07
To: Wojciech = Dec=20 (wdec)
Cc: dromasca@avaya.com;=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

Woj --

The meetings of the RADEXT WG are openly = publicized=20 and are available to anyone (including people who are not physically=20 present).  Presentations and agenda items are openly = solicited.  If=20 you would like time on the agenda of a physical or virtual meeting, = all you=20 need to do is to post a message to the WG list and your request will = be=20 honored. 

In your initial message (see=20 http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you requested = guidance=20 as to whether it would be better for the work on IPv6 access to = proceed with a=20 draft focusing on an initial set of attributes along the lines of the = original=20 submission = (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00),=20 or whether a combined submission would be preferable, along the lines = of the=20 -01 submission.

That is exactly the issue that is now under=20 consideration within the Consensus Call that has been issued.  As = noted=20 in the virtual interim minutes, David Miles has suggested that the = focused=20 approach would be more likely to result in rapid progress, and other=20 participants at the Virtual Interim agreed with this suggestion. =

Since=20 the IETF operates on "rough consensus", it is the duty of the Chairs = to engage=20 the WG participants on issues such as these, rather than making = unilateral=20 decisions.

Subject: RE: Draft RADEXT Virtual Interim Minutes
Date: Sun, 22 Nov = 2009=20 11:57:04 +0100
From: wdec@cisco.com
To: = bernard_aboba@hotmail.com
CC:=20 dromasca@avaya.com; radiusext@ops.ietf.org

Bernard,
 
this thread directly stems from the minutes of the = meeting. On=20 behalf of the draft authors I proposed a way forward and=20 in relation to this I have asked you (as = chair) repeatedly=20 for some answers/clarifications. Now, given that at the n'th = attempt you=20 are still unable to answer them clearly is telling me and other = folks=20 that you're quite simply unwilling or unable to carry = out your=20 duties as chair of this WG.
 
Thanks,
Woj.

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: 21 November 2009 = 02:59
To: Wojciech Dec (wdec)
Cc: 'Romascanu, = Dan=20 (Dan)'; radiusext@ops.ietf.org
Subject: RE: Draft RADEXT = Virtual=20 Interim Minutes

At=20 the Virtual Interim, the RADEXT WG held a session devoted to next = steps on=20 the IPv6 access work.  During the session, David Miles = suggested a path=20 forward for the IPv6 Access work that appeared to have consensus = among the=20 Virtual Interim attendees. 

 

In=20 order to confirm that consensus, the RADEXT WG has issued a = Consensus Call=20 to the mailing list (see  =20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html).  =  Please=20 feel free to express your opinions on the list relating to the = consensus=20 that was reached at the Interim.   

 

From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On=20 Behalf Of Wojciech Dec (wdec)
Sent: Friday, November = 20, 2009=20 2:03 AM
To: Bernard Aboba
Cc: Romascanu, Dan = (Dan);=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

 

Trying=20 for the 4th time now:

 

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

- Are you = now=20 convinced of "interest"? (and if not, or partially, then on what=20 grounds?)

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

 

Thanks,

Woj.

 

------_=_NextPart_001_01CA6C3C.77F6F21C-- -- to unsubscribe send a message to radiusext-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 Nov 23 05:02: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 80EB73A6831 for ; Mon, 23 Nov 2009 05:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.04 X-Spam-Level: X-Spam-Status: No, score=-8.04 tagged_above=-999 required=5 tests=[AWL=0.454, 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 BaXfFXZ9C2sY for ; Mon, 23 Nov 2009 05:02:36 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B35A93A6A62 for ; Mon, 23 Nov 2009 05:02:35 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCYTh-000BNJ-8M for radiusext-data0@psg.com; Mon, 23 Nov 2009 12:57:13 +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 1NCYTf-000BMx-A0 for radiusext@ops.ietf.org; Mon, 23 Nov 2009 12:57:12 +0000 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: Aj8AAC8VCkuQ/uCWe2dsb2JhbACCIS+ZPgEBCwskBqBulmKEPASBcINr X-IronPort-AV: E=Sophos;i="4.47,272,1257120000"; d="scan'208,217";a="55003893" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2009 12:57:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nANCv9BX018395; Mon, 23 Nov 2009 12:57:09 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 13:57:09 +0100 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_01CA6C3C.77500D80" Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Mon, 23 Nov 2009 13:57:05 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Call on Broadband Forum Next Steps Thread-Index: Acprk4W/5rWkelX5TXiQ/WKQDdQRrgAndh+QAAE2d4A= References: ,<4CA2F69AA99746FB881570A6C2FF7198@NEWTON603> ,<4B095E41.1080202@deployingradius.com> From: "Wojciech Dec (wdec)" To: "Romascanu, Dan (Dan)" , "Bernard Aboba" , "Alan DeKok" Cc: "David B. Nelson" , X-OriginalArrivalTime: 23 Nov 2009 12:57:09.0030 (UTC) FILETIME=[77631460:01CA6C3C] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6C3C.77500D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Dan, =20 that was pretty much the gist of my proposal, which I sought to obtain confirmation on (and so far not received one) in terms of a next step. Descriptive text aside, technically it would appear to be very much identical to http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access -00, if not an earlier version, however none of the authors is willing to spend more editing time and do "yet another round" only to arrive at hear more claims of "previous issues not addressed". What are/were these issues? It goes without saying, that with the exception of the data-type issue the reasons for why even the last draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access -01 has been objected to are unclear. As such we are still expecting a response to the questions posed, while tentatively planning to re-present a souped up version of the earlier draft(s). =20 Thanks, Woj. =20 =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: 23 November 2009 12:46 To: Bernard Aboba; Alan DeKok Cc: David B. Nelson; radiusext@ops.ietf.org Subject: RE: Consensus Call on Broadband Forum Next Steps =09 =09 I feel the need to intervene with a question which is also a suggestion about a possible way forward. Would it be possible for co-authors of draft-lourdelet-radext-ipv6-dhcp together with David Miles to get together and provide an updated version of the I-D (adding of course David as a co-author) which would incorporate the elements of David's way forward suggestion made at the interim meeting and address to the possible extend comments and concerns expressed relative to draft-lourdelet-radext-ipv6-dhcp-00? The WG members could address better the consensus question with a document in front of them in my opinion.=20 =20 Dan =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Sunday, November 22, 2009 6:44 PM To: Alan DeKok Cc: David B. Nelson; radiusext@ops.ietf.org Subject: RE: Consensus Call on Broadband Forum Next Steps =09 =09 Alan DeKok said: =09 "I would like to see an updated draft prior to responding to the consensus call".=20 =09 [BA] Since IETF "Working Groups" make progress through the revision of documents in response to comments from WG participants (that is, by doing work), there is no doubt that an updated draft would represent a welcome development. In fact, it is hard to imagine how any progress can be made without such a submission. After all, there can be no progress within a "Working Group" without actual work being accomplished.=20 =09 At the Virtual Interim meeting, David Miles indicated an interest in producing such a submission, and the meeting participants provided encouragement for him to proceed along the lines he suggested. Since such a draft would represent an individual submission and the draft submission window is open, it can be submitted at any time.=20 =09 Nevertheless, we have received a request for additional guidance (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) and in order to respond to the request, a Consensus Call has been issued. Rather than representing a formal Call for Adoption, this Consensus Call is merely attempting to determine whether the approach proposed by David Miles (which envisaged a focused draft addressing the open issues and incorporating elements of http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00) represents a potential way forward. =09 Given that the draft which David Miles suggested does not actually exist, I can understand why WG participants might feel some level of discomfort in rendering a judgment on its suitability, particularly since the issues raised in previous WG discussions (listed on the RADEXT WG Issue list at http://www.drizzle.com/~aboba/RADEXT) have remained unaddressed for some time. Just as most of us are uncomfortable with signing a blank check, there may naturally be concern that the results of the Consensus Call could be misinterpreted as a blanket endorsement for a subsequent revision, regardless of its contents. =20 =09 While we certainly do not want to encourage such a mis-interpretation, given the lack of progress thus far and the repeated requests for "guidance", the Consensus Call seemed like the best way to address the specific question that was asked on the list.=20 =09 However, this is not the only way to make progress. For those not comfortable responding to the Consensus Call, it is still possible to contribute in other ways. As you alluded to, the foremost way would be to submit a draft addressing the issues that have been raised in previous WG discussions in physical and virtual meetings as well as on the list. However, an alternative way to contribute would be by submitting reviews of one or more of the existing documents, including http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00.=20 =09 =09 =09 ------_=_NextPart_001_01CA6C3C.77500D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello=20 Dan,
 
that was=20 pretty much the gist of my proposal, which I sought to obtain = confirmation on=20 (and so far not received one) in terms of a next step. Descriptive text = aside,=20 technically it would appear to be very much identical to http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access= -00,=20 if not an earlier version, however none of the = authors=20 is willing to spend more editing time and do "yet another = round" only=20 to arrive at hear more claims of "previous issues not addressed". = What=20 are/were these issues? It goes without saying, that with the exception of the = data-type=20 issue the reasons for why even the last draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access= -01=20 has been objected to are unclear. As such we are still expecting a = response=20 to the questions posed, while tentatively planning to re-present a = souped up=20 version of the earlier draft(s).
 
Thanks,
Woj.
 
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Romascanu, = Dan=20 (Dan)
Sent: 23 November 2009 12:46
To: Bernard = Aboba; Alan=20 DeKok
Cc: David B. Nelson; = radiusext@ops.ietf.org
Subject:=20 RE: Consensus Call on Broadband Forum Next Steps

I feel the=20 need to intervene with a question which is also a suggestion = about a=20 possible way forward. Would it be possible for co-authors of = draft-lourdelet-radext-ipv6-dhcp=20 together with David Miles to get together = and=20 provide an updated version of the I-D (adding of course David as a = co-author)=20 which would incorporate the elements of David's way forward suggestion = made at=20 the interim meeting and address to the possible extend comments and = concerns=20 expressed relative to draft-lourdelet-radext-ipv6-dhcp-00? The WG = members=20 could address better the consensus question with a document in front = of them=20 in my opinion.
 
Dan
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Sunday, November 22, 2009 6:44 = PM
To: Alan=20 DeKok
Cc: David B. Nelson;=20 radiusext@ops.ietf.org
Subject: RE: Consensus Call on = Broadband=20 Forum Next Steps

Alan DeKok said:

"I would like to see an updated = draft=20 prior to responding to the consensus call".

[BA] Since IETF = "Working=20 Groups" make progress through the revision of documents in response = to=20 comments from WG participants (that is, by doing work), there is no = doubt=20 that an updated draft would represent a welcome = development.   In=20 fact, it is hard to imagine how any progress can be made without = such a=20 submission.  After all, there can be no progress within a = "Working=20 Group" without actual work being accomplished.

At the = Virtual=20 Interim meeting, David Miles indicated an interest in producing such = a=20 submission, and the meeting participants provided encouragement for = him to=20 proceed along the lines he suggested.   Since such a draft = would=20 represent an individual submission and the draft submission window = is open,=20 it can be submitted at any time.

Nevertheless, we have = received a=20 request for additional guidance (see=20 http://ops.ietf.org/lists/radiusext/2009/msg00552.html) and in order = to=20 respond to the request, a Consensus Call has been issued.  = Rather than=20 representing a formal Call for Adoption, this Consensus Call is = merely=20 attempting to determine whether the approach proposed by David Miles = (which=20 envisaged a focused draft addressing the open issues and = incorporating=20 elements of = http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00)=20 represents a potential way forward.

Given that the draft = which David=20 Miles suggested does not actually exist, I can understand why WG=20 participants might feel some level of discomfort in rendering a = judgment on=20 its suitability, particularly since the issues raised in previous WG = discussions (listed on the RADEXT WG Issue list at=20 http://www.drizzle.com/~aboba/RADEXT) have remained unaddressed for = some=20 time.   Just as most of us are uncomfortable with signing = a blank=20 check, there may naturally be concern that the results of the = Consensus Call=20 could be misinterpreted as a blanket endorsement for a subsequent = revision,=20 regardless of its contents. 

While we certainly do not = want to=20 encourage such a mis-interpretation, given the lack of progress thus = far and=20 the repeated requests for "guidance", the Consensus Call seemed like = the=20 best way to address the specific question that was asked on the = list.=20

However, this is not the only way to make progress.  = For those=20 not comfortable responding to the Consensus Call, it is still = possible to=20 contribute in other ways.  As you alluded to, the foremost way = would be=20 to submit a draft addressing the issues that have been raised in = previous WG=20 discussions in physical and virtual meetings as well as on the = list. =20 However, an alternative way to contribute would be by submitting = reviews of=20 one or more of the existing documents, including=20 http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00.=20


------_=_NextPart_001_01CA6C3C.77500D80-- -- to unsubscribe send a message to radiusext-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 Nov 23 05:09: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 761DC3A6A70 for ; Mon, 23 Nov 2009 05:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.386 X-Spam-Level: X-Spam-Status: No, score=-1.386 tagged_above=-999 required=5 tests=[AWL=-0.892, 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 xRPJ8qIgyohm for ; Mon, 23 Nov 2009 05:09:00 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6680F3A67F4 for ; Mon, 23 Nov 2009 05:09:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCYc9-000CNT-L1 for radiusext-data0@psg.com; Mon, 23 Nov 2009 13:05:57 +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 1NCYc1-000CM8-87 for radiusext@ops.ietf.org; Mon, 23 Nov 2009 13:05:49 +0000 X-IronPort-AV: E=Sophos;i="4.47,272,1257138000"; d="scan'208,217";a="181289874" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 23 Nov 2009 08:05:46 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Nov 2009 08:05:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6C3D.9AFACEE7" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Mon, 23 Nov 2009 14:05:17 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: Acprjd9VBMqcnZtIQFWbEkSBR8TIgQAnYNrwAARs21A= References: , From: "Romascanu, Dan (Dan)" To: "Wojciech Dec (wdec)" , "Bernard Aboba" Cc: Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6C3D.9AFACEE7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I suggest to everybody to cool down a little and try to work in a constructive manner from where we are right now. Communication seems key in such situations - It looks to me for example that if at least one of the authors of draft-lourdelet-radext-ipv6-access could have attended the meeting many of the hurdles of the current situation would not have existed. Can the document editors and David work together towards issuing a revised I-D to be submitted as a basis for consensus?=20 =20 Dan =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: Monday, November 23, 2009 2:54 PM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 Bernard, =20 as explained in http://www.ops.ietf.org/lists/radiusext/2009/msg00558.html the draft has been repeatedly presented, modified based on WG feedback and re-presented (or attempted to). The fact that now there seems to be some opinion, consisting effectively of adding descriptive text and an author, etc, does not address the basic question of what were the issues with the previous draft that have not yet been addressed? In other words and perhaps fundamentally, before issuing a consensus call we all would like to know what are the issues with the originally proposed draft? =20 Draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access -00, which had no data-type/tagging controversy and which was presented at IETF74 was claimed to have issues (that actually resulted in 01). This -00 draft now however appears to bear all the hallmarks of what's been claimed as the "virtual meeting" consented way forward, give or take additional descriptive text. Have the issues have disappeared? Persistently, it has also been claimed that there was no interest in the draft. Is there now interest? My simple 3 questions were aimed at clarifying all this, but despite asking numerous times received no clear reply other than some stonewalling (eg check the minutes), or a "consensus call" message which was very odd for a non WG draft to say the least. The implied messaging of changing draft authorship was also highly inconsiderate. =20 Now the above is just one of the many bizarre twists in the story of this draft and its "progress" in Radex. I could go on and on, including pointing out chair-101 items like that; enquiries regarding virtual meeting went un-answered; that meeting conclusions have no IETF binding status; that there is no obligation to attend meetings (esp ones scheduled in a diff time zone); and that having a discussion on draft *without* any of the draft authors present is highly unusual if not down right wrong. =20 The bottom line as I see it is that instead of facilitating WG progress, the activity of the WG chairs has and continues to hinder such progress (eg by refusing to even summarize what are any outstanding issues), as well as evidencing some rather dubious chairing practices.=20 Generalizing from this experience, I can say that the authors of the draft have the distinct impression that any extensions to Radius are actually less than welcome by the chairs of the Radext WG. =20 regards, Woj. =20 =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: 22 November 2009 17:07 To: Wojciech Dec (wdec) Cc: dromasca@avaya.com; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 Woj -- =09 The meetings of the RADEXT WG are openly publicized and are available to anyone (including people who are not physically present). Presentations and agenda items are openly solicited. If you would like time on the agenda of a physical or virtual meeting, all you need to do is to post a message to the WG list and your request will be honored. =20 =09 In your initial message (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you requested guidance as to whether it would be better for the work on IPv6 access to proceed with a draft focusing on an initial set of attributes along the lines of the original submission (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00), or whether a combined submission would be preferable, along the lines of the -01 submission.=20 =09 That is exactly the issue that is now under consideration within the Consensus Call that has been issued. As noted in the virtual interim minutes, David Miles has suggested that the focused approach would be more likely to result in rapid progress, and other participants at the Virtual Interim agreed with this suggestion.=20 =09 Since the IETF operates on "rough consensus", it is the duty of the Chairs to engage the WG participants on issues such as these, rather than making unilateral decisions.=20 =09 =09 ________________________________ Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun, 22 Nov 2009 11:57:04 +0100 From: wdec@cisco.com To: bernard_aboba@hotmail.com CC: dromasca@avaya.com; radiusext@ops.ietf.org =09 =09 Bernard, =20 this thread directly stems from the minutes of the meeting. On behalf of the draft authors I proposed a way forward and in relation to this I have asked you (as chair) repeatedly for some answers/clarifications. Now, given that at the n'th attempt you are still unable to answer them clearly is telling me and other folks that you're quite simply unwilling or unable to carry out your duties as chair of this WG.=20 =20 Thanks, Woj. ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 21 November 2009 02:59 To: Wojciech Dec (wdec) Cc: 'Romascanu, Dan (Dan)'; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 At the Virtual Interim, the RADEXT WG held a session devoted to next steps on the IPv6 access work. During the session, David Miles suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. =20 =20 In order to confirm that consensus, the RADEXT WG has issued a Consensus Call to the mailing list (see http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please feel free to express your opinions on the list relating to the consensus that was reached at the Interim. =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Friday, November 20, 2009 2:03 AM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 Trying for the 4th time now: =20 - 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?) - could you point out (summarise)the issues that were not addressed? =20 Thanks, Woj. =20 ------_=_NextPart_001_01CA6C3D.9AFACEE7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I suggest to=20 everybody to cool down a little and try to work in a constructive manner = from=20 where we are right now. Communication seems key in such situations - It = looks to=20 me for example that if at least one of the authors of=20 draft-lourdelet-radext-ipv6-access could have attended the meeting many of the hurdles of = the current=20 situation would not have existed. Can the document editors and David = work=20 together towards issuing a revised I-D to be submitted as a basis for = consensus?=20
 
Dan
 

From: Wojciech Dec (wdec) = [mailto:wdec@cisco.com]=20
Sent: Monday, November 23, 2009 2:54 PM
To: = Bernard=20 Aboba
Cc: Romascanu, Dan (Dan);=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

Bernard,
 
as=20 explained in http:= //www.ops.ietf.org/lists/radiusext/2009/msg00558.html the=20 draft has been repeatedly presented, modified based on = WG feedback and=20 re-presented (or attempted to).
The=20 fact that now there seems to be some opinion, consisting = effectively of=20 adding descriptive text and an author, etc, does not = address=20 the basic question of what were the issues with the previous = draft that=20 have not yet been addressed? In other words and perhaps = fundamentally, before issuing a=20 consensus call we all would like to know what are the issues with = the=20 originally proposed draft?
 
Draft=20 http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access= -00,=20 which had no data-type/tagging controversy and which was=20 presented at IETF74 was claimed to have issues (that actually = resulted in=20 01). This -00 draft now however appears to bear all the hallmarks = of=20 what's been claimed as the "virtual meeting" consented way = forward, give=20 or take additional descriptive text. Have the issues have = disappeared?=20 Persistently, it has also been claimed = that there=20 was no interest in the draft. Is there now=20 interest?
My simple 3 = questions=20 were aimed at clarifying all this, but despite asking numerous times = received=20 no clear reply other than some stonewalling (eg check the = minutes),=20 or a "consensus call" message which was very odd = for a=20 non WG draft to say the least. The implied messaging of = changing=20 draft authorship was also highly=20 inconsiderate.
 
Now the = above is=20 just one of the many bizarre twists in the story of this = draft and=20 its "progress" in Radex. I could go on and on, including pointing out=20 chair-101 items like that; enquiries regarding virtual = meeting went=20 un-answered; that meeting conclusions have no IETF  = binding=20 status; that there is no obligation to attend meetings (esp ones = scheduled in=20 a diff time zone); and that having a discussion on = draft *without* any of=20 the draft authors present is highly unusual if not down right=20 wrong.
 
The bottom line as=20 I see it is that instead of facilitating WG progress, the = activity of the=20 WG chairs has and continues to hinder such progress (eg by = refusing=20 to even summarize what are any outstanding issues), as well as=20 evidencing some rather dubious chairing practices.=20
Generalizing from this=20 experience, I can say that the authors of the draft have the = distinct=20 impression that any extensions to Radius are actually less = than welcome=20 by the chairs of the Radext WG.
 
regards,
Woj.
 
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: 22 November 2009 17:07
To: Wojciech = Dec=20 (wdec)
Cc: dromasca@avaya.com;=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

Woj --

The meetings of the RADEXT WG are openly = publicized=20 and are available to anyone (including people who are not physically = present).  Presentations and agenda items are openly = solicited. =20 If you would like time on the agenda of a physical or virtual = meeting, all=20 you need to do is to post a message to the WG list and your request = will be=20 honored. 

In your initial message (see=20 http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you = requested=20 guidance as to whether it would be better for the work on IPv6 = access to=20 proceed with a draft focusing on an initial set of attributes along = the=20 lines of the original submission=20 (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00), or = whether=20 a combined submission would be preferable, along the lines of the = -01=20 submission.

That is exactly the issue that is now under=20 consideration within the Consensus Call that has been issued.  = As noted=20 in the virtual interim minutes, David Miles has suggested that the = focused=20 approach would be more likely to result in rapid progress, and other = participants at the Virtual Interim agreed with this suggestion.=20

Since the IETF operates on "rough consensus", it is the duty = of the=20 Chairs to engage the WG participants on issues such as these, rather = than=20 making unilateral decisions.

Subject: RE: Draft RADEXT Virtual Interim Minutes
Date: Sun, 22 = Nov 2009=20 11:57:04 +0100
From: wdec@cisco.com
To:=20 bernard_aboba@hotmail.com
CC: dromasca@avaya.com;=20 radiusext@ops.ietf.org

Bernard,
 
this thread directly stems from the minutes of the=20 meeting. On behalf of the draft authors I proposed a = way=20 forward and in relation to this I have asked you (as=20 chair) repeatedly for some answers/clarifications. Now, given = that at=20 the n'th attempt you are still unable to answer them = clearly is=20 telling me and other folks that you're quite simply = unwilling or=20 unable to carry out your duties as chair of this WG.=20
 
Thanks,
Woj.

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: 21 November = 2009=20 02:59
To: Wojciech Dec (wdec)
Cc: 'Romascanu, = Dan=20 (Dan)'; radiusext@ops.ietf.org
Subject: RE: Draft RADEXT = Virtual=20 Interim Minutes

At=20 the Virtual Interim, the RADEXT WG held a session devoted to next = steps on=20 the IPv6 access work.  During the session, David Miles = suggested a=20 path forward for the IPv6 Access work that appeared to have = consensus=20 among the Virtual Interim attendees. 

 

In=20 order to confirm that consensus, the RADEXT WG has issued a = Consensus Call=20 to the mailing list (see  =20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html). =20  Please feel free to express your opinions on the list = relating to=20 the consensus that was reached at the Interim. =   

 

From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On=20 Behalf Of Wojciech Dec (wdec)
Sent: Friday, November = 20,=20 2009 2:03 AM
To: Bernard Aboba
Cc: Romascanu, = Dan=20 (Dan); radiusext@ops.ietf.org
Subject: RE: Draft RADEXT = Virtual=20 Interim Minutes

 

Trying=20 for the 4th time now:

 

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

- Are = you now=20 convinced of "interest"? (and if not, or partially, then on what=20 grounds?)

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

 

Thanks,

Woj.

 

------_=_NextPart_001_01CA6C3D.9AFACEE7-- -- to unsubscribe send a message to radiusext-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 Nov 23 05:16: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 ABE143A6A74 for ; Mon, 23 Nov 2009 05:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.096 X-Spam-Level: X-Spam-Status: No, score=-8.096 tagged_above=-999 required=5 tests=[AWL=0.398, 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 Epovz+nzRu9T for ; Mon, 23 Nov 2009 05:16:35 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 555803A6A73 for ; Mon, 23 Nov 2009 05:16:35 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCYiq-000DE7-Qf for radiusext-data0@psg.com; Mon, 23 Nov 2009 13:12:52 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCYin-000DDl-On for radiusext@ops.ietf.org; Mon, 23 Nov 2009 13:12:51 +0000 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: AocAALMYCkuQ/uCWe2dsb2JhbACCIy2NTYpigQ8BAQsLJAahEJZjgi0VgXoEgXCDa4dZ X-IronPort-AV: E=Sophos;i="4.47,272,1257120000"; d="scan'208,217";a="55005693" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2009 13:12:47 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nANDClEp023504; Mon, 23 Nov 2009 13:12:47 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 14:12:47 +0100 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_01CA6C3E.A6A3194A" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Mon, 23 Nov 2009 14:12:44 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: Acprjd9VBMqcnZtIQFWbEkSBR8TIgQAnYNrwAARs21AAADS5MA== References: , From: "Wojciech Dec (wdec)" To: "Romascanu, Dan (Dan)" , "Bernard Aboba" Cc: X-OriginalArrivalTime: 23 Nov 2009 13:12:47.0467 (UTC) FILETIME=[A6BD33B0:01CA6C3E] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6C3E.A6A3194A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As highlighted, we (the authors and David) intend progressing on this approach and have discussed it at the last meeting. However we are similarly in agreement as to expecting an answer as to what "issues" do say draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00 have, if not http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-01 (data type aside). As far as we're concerned addressing previously raised issues is precisely what led to the situation of today.=20 =20 =20 -Woj. ________________________________ From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: 23 November 2009 14:05 To: Wojciech Dec (wdec); Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 I suggest to everybody to cool down a little and try to work in a constructive manner from where we are right now. Communication seems key in such situations - It looks to me for example that if at least one of the authors of draft-lourdelet-radext-ipv6-access could have attended the meeting many of the hurdles of the current situation would not have existed. Can the document editors and David work together towards issuing a revised I-D to be submitted as a basis for consensus?=20 =20 Dan =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: Monday, November 23, 2009 2:54 PM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 Bernard, =20 as explained in http://www.ops.ietf.org/lists/radiusext/2009/msg00558.html the draft has been repeatedly presented, modified based on WG feedback and re-presented (or attempted to). The fact that now there seems to be some opinion, consisting effectively of adding descriptive text and an author, etc, does not address the basic question of what were the issues with the previous draft that have not yet been addressed? In other words and perhaps fundamentally, before issuing a consensus call we all would like to know what are the issues with the originally proposed draft? =20 Draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access -00, which had no data-type/tagging controversy and which was presented at IETF74 was claimed to have issues (that actually resulted in 01). This -00 draft now however appears to bear all the hallmarks of what's been claimed as the "virtual meeting" consented way forward, give or take additional descriptive text. Have the issues have disappeared? Persistently, it has also been claimed that there was no interest in the draft. Is there now interest? My simple 3 questions were aimed at clarifying all this, but despite asking numerous times received no clear reply other than some stonewalling (eg check the minutes), or a "consensus call" message which was very odd for a non WG draft to say the least. The implied messaging of changing draft authorship was also highly inconsiderate. =20 Now the above is just one of the many bizarre twists in the story of this draft and its "progress" in Radex. I could go on and on, including pointing out chair-101 items like that; enquiries regarding virtual meeting went un-answered; that meeting conclusions have no IETF binding status; that there is no obligation to attend meetings (esp ones scheduled in a diff time zone); and that having a discussion on draft *without* any of the draft authors present is highly unusual if not down right wrong. =20 The bottom line as I see it is that instead of facilitating WG progress, the activity of the WG chairs has and continues to hinder such progress (eg by refusing to even summarize what are any outstanding issues), as well as evidencing some rather dubious chairing practices.=20 Generalizing from this experience, I can say that the authors of the draft have the distinct impression that any extensions to Radius are actually less than welcome by the chairs of the Radext WG. =20 regards, Woj. =20 =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: 22 November 2009 17:07 To: Wojciech Dec (wdec) Cc: dromasca@avaya.com; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 Woj -- =09 The meetings of the RADEXT WG are openly publicized and are available to anyone (including people who are not physically present). Presentations and agenda items are openly solicited. If you would like time on the agenda of a physical or virtual meeting, all you need to do is to post a message to the WG list and your request will be honored. =20 =09 In your initial message (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you requested guidance as to whether it would be better for the work on IPv6 access to proceed with a draft focusing on an initial set of attributes along the lines of the original submission (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00), or whether a combined submission would be preferable, along the lines of the -01 submission.=20 =09 That is exactly the issue that is now under consideration within the Consensus Call that has been issued. As noted in the virtual interim minutes, David Miles has suggested that the focused approach would be more likely to result in rapid progress, and other participants at the Virtual Interim agreed with this suggestion.=20 =09 Since the IETF operates on "rough consensus", it is the duty of the Chairs to engage the WG participants on issues such as these, rather than making unilateral decisions.=20 =09 =09 ________________________________ Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun, 22 Nov 2009 11:57:04 +0100 From: wdec@cisco.com To: bernard_aboba@hotmail.com CC: dromasca@avaya.com; radiusext@ops.ietf.org =09 =09 Bernard, =20 this thread directly stems from the minutes of the meeting. On behalf of the draft authors I proposed a way forward and in relation to this I have asked you (as chair) repeatedly for some answers/clarifications. Now, given that at the n'th attempt you are still unable to answer them clearly is telling me and other folks that you're quite simply unwilling or unable to carry out your duties as chair of this WG.=20 =20 Thanks, Woj. ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 21 November 2009 02:59 To: Wojciech Dec (wdec) Cc: 'Romascanu, Dan (Dan)'; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 At the Virtual Interim, the RADEXT WG held a session devoted to next steps on the IPv6 access work. During the session, David Miles suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. =20 =20 In order to confirm that consensus, the RADEXT WG has issued a Consensus Call to the mailing list (see http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please feel free to express your opinions on the list relating to the consensus that was reached at the Interim. =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Friday, November 20, 2009 2:03 AM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 Trying for the 4th time now: =20 - 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?) - could you point out (summarise)the issues that were not addressed? =20 Thanks, Woj. =20 ------_=_NextPart_001_01CA6C3E.A6A3194A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As=20 highlighted, we (the authors and David) intend progressing on this = approach and=20 have discussed it at the last meeting. However we are similarly in = agreement as=20 to expecting an answer as to what "issues" do say draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00<= /A> have,=20 if not http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-01<= /A>=20 (data type aside). As far as we're concerned addressing previously = raised issues=20 is precisely what led to the situation of today.=20
 
 
-Woj.

From: Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: 23 November 2009=20 14:05
To: Wojciech Dec (wdec); Bernard Aboba
Cc:=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

I suggest=20 to everybody to cool down a little and try to work in a constructive = manner=20 from where we are right now. Communication seems key in such = situations - It=20 looks to me for example that if at least one of the authors of=20 draft-lourdelet-radext-ipv6-access could have attended the meeting many of the hurdles of = the=20 current situation would not have existed. Can the document editors and = David=20 work together towards issuing a revised I-D to be submitted as a basis = for=20 consensus?
 
Dan
 

From: Wojciech Dec (wdec) = [mailto:wdec@cisco.com]=20
Sent: Monday, November 23, 2009 2:54 PM
To: = Bernard=20 Aboba
Cc: Romascanu, Dan (Dan);=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

Bernard,
 
as=20 explained in http:= //www.ops.ietf.org/lists/radiusext/2009/msg00558.html the=20 draft has been repeatedly presented, modified based on = WG feedback and=20 re-presented (or attempted to).
The=20 fact that now there seems to be some opinion, consisting = effectively of=20 adding descriptive text and an author, etc, does not = address=20 the basic question of what were the issues with the previous = draft that=20 have not yet been addressed? In other words and perhaps = fundamentally, before issuing=20 a consensus call we all would like to know what are the issues = with the=20 originally proposed draft?
 
Draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access= -00,=20 which had no data-type/tagging controversy and which was=20 presented at IETF74 was claimed to have issues (that actually = resulted=20 in 01). This -00 draft now however appears to bear all the = hallmarks of=20 what's been claimed as the "virtual meeting" consented way = forward,=20 give or take additional descriptive text. Have the issues have=20 disappeared? Persistently, it=20 has also been claimed that there was no interest in the draft. = Is there=20 now interest?
My=20 simple 3 questions were aimed at clarifying all this, but despite = asking=20 numerous times received no clear reply other than some = stonewalling (eg=20 check the minutes), or a "consensus call" message which = was=20 very odd for a non WG draft to say the least. = The=20 implied messaging of changing draft authorship was also highly=20 inconsiderate.
 
Now=20 the above is just one of the many bizarre twists in the = story of=20 this draft and its "progress" in Radex. I could go on and on, = including=20 pointing out chair-101 items like that; enquiries regarding virtual=20 meeting went un-answered; that meeting = conclusions have no=20 IETF  binding status; that there is no obligation to attend = meetings=20 (esp ones scheduled in a diff time zone); and that having a = discussion on=20 draft *without* any of the draft authors present is highly = unusual if=20 not down right wrong.
 
The bottom line as I see it is = that=20 instead of facilitating WG progress, the activity of the = WG chairs=20 has and continues to hinder such progress (eg by refusing to = even=20 summarize what are any outstanding issues), as well as=20 evidencing some rather dubious chairing practices.=20
Generalizing from this experience, I can = say that=20 the authors of the draft have the distinct impression that any=20 extensions to Radius are actually less than welcome by the = chairs of=20 the Radext WG.
 
regards,
Woj.
 
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: 22 November 2009 17:07
To: = Wojciech Dec=20 (wdec)
Cc: dromasca@avaya.com;=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

Woj --

The meetings of the RADEXT WG are openly=20 publicized and are available to anyone (including people who are = not=20 physically present).  Presentations and agenda items are = openly=20 solicited.  If you would like time on the agenda of a = physical or=20 virtual meeting, all you need to do is to post a message to the WG = list=20 and your request will be honored. 

In your initial = message=20 (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you = requested=20 guidance as to whether it would be better for the work on IPv6 = access to=20 proceed with a draft focusing on an initial set of attributes = along the=20 lines of the original submission=20 (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00), = or=20 whether a combined submission would be preferable, along the lines = of the=20 -01 submission.

That is exactly the issue that is now = under=20 consideration within the Consensus Call that has been = issued.  As=20 noted in the virtual interim minutes, David Miles has suggested = that the=20 focused approach would be more likely to result in rapid progress, = and=20 other participants at the Virtual Interim agreed with this = suggestion.=20

Since the IETF operates on "rough consensus", it is the = duty of=20 the Chairs to engage the WG participants on issues such as these, = rather=20 than making unilateral decisions.

Subject: RE: Draft RADEXT Virtual Interim Minutes
Date: Sun, 22 = Nov=20 2009 11:57:04 +0100
From: wdec@cisco.com
To:=20 bernard_aboba@hotmail.com
CC: dromasca@avaya.com;=20 radiusext@ops.ietf.org

Bernard,
 
this thread directly stems from the minutes of the=20 meeting. On behalf of the draft authors = I proposed a way=20 forward and in relation to this I have asked you = (as=20 chair) repeatedly for some answers/clarifications. Now, given = that at=20 the n'th attempt you are still unable to answer them = clearly is=20 telling me and other folks that you're quite simply = unwilling or=20 unable to carry out your duties as chair of this WG.=20
 
Thanks,
Woj.

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: 21 November = 2009=20 02:59
To: Wojciech Dec (wdec)
Cc: = 'Romascanu, Dan=20 (Dan)'; radiusext@ops.ietf.org
Subject: RE: Draft = RADEXT=20 Virtual Interim Minutes

At=20 the Virtual Interim, the RADEXT WG held a session devoted to = next steps=20 on the IPv6 access work.  During the session, David Miles = suggested=20 a path forward for the IPv6 Access work that appeared to have = consensus=20 among the Virtual Interim attendees. 

 

In=20 order to confirm that consensus, the RADEXT WG has issued a = Consensus=20 Call to the mailing list (see  =20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html). =20  Please feel free to express your opinions on the list = relating to=20 the consensus that was reached at the Interim. =   

 

From:=20 owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org] On=20 Behalf Of Wojciech Dec (wdec)
Sent: Friday, = November 20,=20 2009 2:03 AM
To: Bernard Aboba
Cc: = Romascanu, Dan=20 (Dan); radiusext@ops.ietf.org
Subject: RE: Draft = RADEXT=20 Virtual Interim Minutes

 

Trying=20 for the 4th time now:

 

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

- Are = you now=20 convinced of "interest"? (and if not, or partially, then on what = grounds?)

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

 

Thanks,

Woj.

 

<= /HTML> ------_=_NextPart_001_01CA6C3E.A6A3194A-- -- to unsubscribe send a message to radiusext-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 Nov 23 05:24: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 93CD728C112 for ; Mon, 23 Nov 2009 05:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwvLz0yMg-aV for ; Mon, 23 Nov 2009 05:24:13 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 82BBA3A6A73 for ; Mon, 23 Nov 2009 05:24:13 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCYrD-000ETx-7N for radiusext-data0@psg.com; Mon, 23 Nov 2009 13:21: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 1NCYr6-000ETW-PN for radiusext@ops.ietf.org; Mon, 23 Nov 2009 13:21:25 +0000 Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 8d9m1d0040cZkys54dMQri; Mon, 23 Nov 2009 13:21:24 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA10.westchester.pa.mail.comcast.net with comcast id 8dMP1d00H4H2mdz3WdMP0n; Mon, 23 Nov 2009 13:21:24 +0000 From: "Dave Nelson" To: "'Wojciech Dec \(wdec\)'" , "'Romascanu, Dan \(Dan\)'" , "'Bernard Aboba'" , "'Alan DeKok'" Cc: References: ,<4CA2F69AA99746FB881570A6C2FF7198@NEWTON603> ,<4B095E41.1080202@deployingradius.com> Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Mon, 23 Nov 2009 08:21:26 -0500 Message-ID: <8CF160205F4440688CD6BE2812A8DEFD@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: Acprk4W/5rWkelX5TXiQ/WKQDdQRrgAndh+QAAE2d4AAAgpkUA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > What are/were these issues? Issues are listed in the RADEXT Issues Tracker, located at: http://www.drizzle.com/~aboba/RADEXT/ The issues on your draft are 317, 321, 322. In addition, there are discussions that are logged in the RADEXT WG = mailing list archives. > As such=A0we are still expecting a response to the questions posed, > while tentatively planning to re-present a souped up version of > the earlier draft(s). The only question that I'm aware of is your question of October 23, that = is to say, "If we address the attribute design issues can this draft move forward"? That's not the way the WG works. There are no shortcuts to addressing commentary and posting revised drafts. Your current draft is at -01, so it's not like there has been a *lot* of revision activity. The best way forward is to propose *specific* text revisions to address outstanding comments. You can do that either by submitting a revised draft, or by submitting sections of OLD and NEW text to the mailing list to show the = WG what changes you propose to make in the next draft revision. In many = ways, that's actually preferable. -- to unsubscribe send a message to radiusext-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 Nov 23 13:46: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 555E128C1BF for ; Mon, 23 Nov 2009 13:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.521 X-Spam-Level: X-Spam-Status: No, score=-5.521 tagged_above=-999 required=5 tests=[AWL=-2.267, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ6bcDyLhumY for ; Mon, 23 Nov 2009 13:45:47 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8D07228C1B6 for ; Mon, 23 Nov 2009 13:45:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCgaA-000Jk1-60 for radiusext-data0@psg.com; Mon, 23 Nov 2009 21:36:26 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCga5-000JjX-9v for radiusext@ops.ietf.org; Mon, 23 Nov 2009 21:36:21 +0000 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcLANOOCkurRN+K/2dsb2JhbACCUY1QimOkOpc0gi0VgXoEgXCDa4dZ X-IronPort-AV: E=Sophos;i="4.47,273,1257120000"; d="scan'208,217";a="53015859" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 23 Nov 2009 21:36:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nANLaIKl009254; Mon, 23 Nov 2009 21:36:19 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); Mon, 23 Nov 2009 22:36:18 +0100 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_01CA6C84.FDAEFAA6" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Mon, 23 Nov 2009 22:36:18 +0100 Message-ID: In-Reply-To: <986DCE2E44129444B6435ABE8C9E424D046560AB@SGSINSMBS02.ad4.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: Acprjd9VBMqcnZtIQFWbEkSBR8TIgQAnYNrwAARs21AAADS5MAAQZErAAACw+PA= References: , <986DCE2E44129444B6435ABE8C9E424D046560AB@SGSINSMBS02.ad4.ad.alcatel.com> From: "Wojciech Dec (wdec)" To: "MILES DAVID" , "Romascanu, Dan (Dan)" , "Bernard Aboba" Cc: X-OriginalArrivalTime: 23 Nov 2009 21:36:18.0462 (UTC) FILETIME=[FDE533E0:01CA6C84] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6C84.FDAEFAA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, =20 thanks for the support, which is one that effectively amounts to backing the two draft approach (https://ops.ietf.org/lists/radiusext/2009/msg00552.html ). I will take you up on contributing the descriptive text to complete an updated version of http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00, unless you have radically alternative suggestions in mind for the DNS, address and route options. =20 Cheers, Woj. ________________________________ From: MILES DAVID [mailto:David.Miles@alcatel-lucent.com]=20 Sent: 23 November 2009 22:00 To: Wojciech Dec (wdec); Romascanu, Dan (Dan); Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 In the interest of moving forward, I would like to take the crack at this... I noted none of the current authors want to take this work on - I do and I will. I'll produce a new draft and author it ... if any of the current authors want to be on the draft please let me know - i do not get anything for having my name on a draft=20 =20 I truly understand Woj's frustration here but I am here for short term kicks - I really need to get this gap sorted out and I hope those that feel stepped on by my course of action can appreciate that you sometimes need to make sacrifices to get the outcome you need (which here is clearly some new RADIUS AVP types). I promise to be designated beer-guy at all future IETF's for those authors feeling hard done by :)=20 =20 -d =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Monday, 23 November 2009 11:43 PM To: Romascanu, Dan (Dan); Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 As highlighted, we (the authors and David) intend progressing on this approach and have discussed it at the last meeting. However we are similarly in agreement as to expecting an answer as to what "issues" do say draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00 have, if not http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-01 (data type aside). As far as we're concerned addressing previously raised issues is precisely what led to the situation of today.=20 =20 =20 -Woj. =20 =09 ________________________________ From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: 23 November 2009 14:05 To: Wojciech Dec (wdec); Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes I suggest to everybody to cool down a little and try to work in a constructive manner from where we are right now. Communication seems key in such situations - It looks to me for example that if at least one of the authors of draft-lourdelet-radext-ipv6-access could have attended the meeting many of the hurdles of the current situation would not have existed. Can the document editors and David work together towards issuing a revised I-D to be submitted as a basis for consensus?=20 =20 Dan =20 =20 =09 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: Monday, November 23, 2009 2:54 PM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes Bernard, =20 as explained in http://www.ops.ietf.org/lists/radiusext/2009/msg00558.html the draft has been repeatedly presented, modified based on WG feedback and re-presented (or attempted to). The fact that now there seems to be some opinion, consisting effectively of adding descriptive text and an author, etc, does not address the basic question of what were the issues with the previous draft that have not yet been addressed? In other words and perhaps fundamentally, before issuing a consensus call we all would like to know what are the issues with the originally proposed draft? =20 Draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access -00, which had no data-type/tagging controversy and which was presented at IETF74 was claimed to have issues (that actually resulted in 01). This -00 draft now however appears to bear all the hallmarks of what's been claimed as the "virtual meeting" consented way forward, give or take additional descriptive text. Have the issues have disappeared? Persistently, it has also been claimed that there was no interest in the draft. Is there now interest? My simple 3 questions were aimed at clarifying all this, but despite asking numerous times received no clear reply other than some stonewalling (eg check the minutes), or a "consensus call" message which was very odd for a non WG draft to say the least. The implied messaging of changing draft authorship was also highly inconsiderate. =20 Now the above is just one of the many bizarre twists in the story of this draft and its "progress" in Radex. I could go on and on, including pointing out chair-101 items like that; enquiries regarding virtual meeting went un-answered; that meeting conclusions have no IETF binding status; that there is no obligation to attend meetings (esp ones scheduled in a diff time zone); and that having a discussion on draft *without* any of the draft authors present is highly unusual if not down right wrong. =20 The bottom line as I see it is that instead of facilitating WG progress, the activity of the WG chairs has and continues to hinder such progress (eg by refusing to even summarize what are any outstanding issues), as well as evidencing some rather dubious chairing practices.=20 Generalizing from this experience, I can say that the authors of the draft have the distinct impression that any extensions to Radius are actually less than welcome by the chairs of the Radext WG. =20 regards, Woj. =20 =20 =20 =09 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: 22 November 2009 17:07 To: Wojciech Dec (wdec) Cc: dromasca@avaya.com; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes Woj -- =09 The meetings of the RADEXT WG are openly publicized and are available to anyone (including people who are not physically present). Presentations and agenda items are openly solicited. If you would like time on the agenda of a physical or virtual meeting, all you need to do is to post a message to the WG list and your request will be honored. =20 =09 In your initial message (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you requested guidance as to whether it would be better for the work on IPv6 access to proceed with a draft focusing on an initial set of attributes along the lines of the original submission (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00), or whether a combined submission would be preferable, along the lines of the -01 submission.=20 =09 That is exactly the issue that is now under consideration within the Consensus Call that has been issued. As noted in the virtual interim minutes, David Miles has suggested that the focused approach would be more likely to result in rapid progress, and other participants at the Virtual Interim agreed with this suggestion.=20 =09 Since the IETF operates on "rough consensus", it is the duty of the Chairs to engage the WG participants on issues such as these, rather than making unilateral decisions.=20 =09 ________________________________ Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun, 22 Nov 2009 11:57:04 +0100 From: wdec@cisco.com To: bernard_aboba@hotmail.com CC: dromasca@avaya.com; radiusext@ops.ietf.org Bernard, =20 this thread directly stems from the minutes of the meeting. On behalf of the draft authors I proposed a way forward and in relation to this I have asked you (as chair) repeatedly for some answers/clarifications. Now, given that at the n'th attempt you are still unable to answer them clearly is telling me and other folks that you're quite simply unwilling or unable to carry out your duties as chair of this WG.=20 =20 Thanks, Woj. =20 =09 ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 21 November 2009 02:59 To: Wojciech Dec (wdec) Cc: 'Romascanu, Dan (Dan)'; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes At the Virtual Interim, the RADEXT WG held a session devoted to next steps on the IPv6 access work. During the session, David Miles suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. =20 =20 In order to confirm that consensus, the RADEXT WG has issued a Consensus Call to the mailing list (see http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please feel free to express your opinions on the list relating to the consensus that was reached at the Interim. =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Friday, November 20, 2009 2:03 AM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 Trying for the 4th time now: =20 - 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?) - could you point out (summarise)the issues that were not addressed? =20 Thanks, Woj. =20 ------_=_NextPart_001_01CA6C84.FDAEFAA6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
David,
 
thanks for the support, which is one that effectively = amounts=20 to backing the two draft approach (https://= ops.ietf.org/lists/radiusext/2009/msg00552.html ).=20 I will take you up on contributing the descriptive text to complete an = updated=20 version of http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00,=20 unless you have radically alternative suggestions in mind for the DNS, = address=20 and route options.
 
Cheers,
Woj.
From: MILES DAVID=20 [mailto:David.Miles@alcatel-lucent.com]
Sent: 23 November = 2009=20 22:00
To: Wojciech Dec (wdec); Romascanu, Dan (Dan); Bernard = Aboba
Cc: radiusext@ops.ietf.org
Subject: RE: = Draft RADEXT=20 Virtual Interim Minutes

In=20 the interest of moving forward, I would like to take the crack at = this... I=20 noted none of the current authors want to take this work on – I = do and I will.=20 I’ll produce a new draft and author it ... if any of the current = authors want=20 to be on the draft please let me know – i do not get anything = for having my=20 name on a draft

 

I=20 truly understand Woj’s frustration here but I am here for short = term kicks – I=20 really need to get this gap sorted out and I hope those that feel = stepped on=20 by my course of action can appreciate that you sometimes need to make=20 sacrifices to get the outcome you need (which here is clearly some new = RADIUS=20 AVP types). I promise to be designated beer-guy at all future = IETF’s for those=20 authors feeling hard done by :)

 

-d

 

 

From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On=20 Behalf Of Wojciech Dec (wdec)
Sent: Monday, 23 November = 2009=20 11:43 PM
To: Romascanu, Dan (Dan); Bernard = Aboba
Cc:=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

 

As = highlighted, we=20 (the authors and David) intend progressing on this approach and have = discussed=20 it at the last meeting. However we are similarly in agreement as to = expecting=20 an answer as to what "issues" do say draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00&nbs= p;have,=20 if not http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-01=20 (data type aside). As far as we're concerned addressing previously = raised=20 issues is precisely what led to the situation of today. =

 

 

-Woj.

 

From:=20 Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: 23 = November 2009 14:05
To: Wojciech Dec (wdec); Bernard=20 Aboba
Cc: radiusext@ops.ietf.org
Subject: RE: = Draft=20 RADEXT Virtual Interim Minutes

I=20 suggest to everybody to cool down a little and try to work in a = constructive=20 manner from where we are right now. Communication seems key in such=20 situations - It looks to me for example that if at least one of the = authors=20 of draft-lourdelet-radext-ipv6-access=20 could=20 have attended the meeting many of the hurdles of the current = situation would=20 not have existed. Can the document editors and David work together = towards=20 issuing a revised I-D to be submitted as a basis for consensus? =

 

Dan

 

 

From:=20 Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: = Monday,=20 November 23, 2009 2:54 PM
To: Bernard = Aboba
Cc:=20 Romascanu, Dan (Dan); radiusext@ops.ietf.org
Subject: = RE: Draft=20 RADEXT Virtual Interim Minutes

Bernard,

 

as = explained in=20 http:= //www.ops.ietf.org/lists/radiusext/2009/msg00558.html the=20 draft has been repeatedly presented, modified based on = WG feedback=20 and re-presented (or attempted to).

The = fact that=20 now there seems to be some opinion, consisting effectively of = adding=20 descriptive text and an author, etc, does not = address the=20 basic question of what were the issues with the previous = draft that=20 have not yet been addressed? In other words and perhaps=20 fundamentally, before issuing a consensus call we all = would like=20 to know what are the issues with the originally proposed=20 draft?

 

Draft = http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00,=20 which had no data-type/tagging controversy and which was=20 presented at IETF74 was claimed to have issues (that actually = resulted in 01). This -00 draft now however appears to bear = all the=20 hallmarks of what's been claimed as the "virtual meeting"=20 consented way forward, give or take additional descriptive = text. Have=20 the issues have disappeared? Persistently, it has also = been=20 claimed that there was no interest in the draft. Is there now=20 interest?

My = simple 3=20 questions were aimed at clarifying all this, but despite asking = numerous=20 times received no clear reply other than some = stonewalling (eg check=20 the minutes), or a "consensus call" message which was=20 very odd for a non WG draft to say the least. = The=20 implied messaging of changing draft authorship was also highly=20 inconsiderate.

 

Now = the=20 above is just one of the many bizarre twists in the = story of=20 this draft and its "progress" in Radex. I could go on and on, = including pointing out chair-101 items like that; enquiries = regarding=20 virtual meeting went un-answered; that meeting=20 conclusions have no IETF  binding status; that there is = no=20 obligation to attend meetings (esp ones scheduled in a diff time = zone);=20 and that having a discussion on draft *without* any of the = draft=20 authors present is highly unusual if not down right = wrong.

 

The bottom=20 line as I see it is that instead of facilitating WG progress, = the=20 activity of the WG chairs has and continues to hinder = such=20 progress (eg by refusing to even summarize what are any=20 outstanding issues), as well as evidencing some rather=20 dubious chairing practices.

Generalizing=20 from this experience, I can say that the authors of the = draft have=20 the distinct impression that any extensions to Radius are actually = less=20 than welcome by the chairs of the Radext WG.

 

regards,

Woj.

 

 

 

From:=20 owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org] On=20 Behalf Of Bernard Aboba
Sent: 22 November 2009=20 17:07
To: Wojciech Dec (wdec)
Cc:=20 dromasca@avaya.com; radiusext@ops.ietf.org
Subject: = RE: Draft=20 RADEXT Virtual Interim Minutes

Woj=20 --

The meetings of the RADEXT WG are openly publicized = and are=20 available to anyone (including people who are not physically=20 present).  Presentations and agenda items are openly=20 solicited.  If you would like time on the agenda of a = physical or=20 virtual meeting, all you need to do is to post a message to the = WG list=20 and your request will be honored. 

In your initial = message=20 (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you = requested guidance as to whether it would be better for the work = on IPv6=20 access to proceed with a draft focusing on an initial set of = attributes=20 along the lines of the original submission=20 = (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00), or=20 whether a combined submission would be preferable, along the = lines of=20 the -01 submission.

That is exactly the issue that is = now under=20 consideration within the Consensus Call that has been = issued.  As=20 noted in the virtual interim minutes, David Miles has suggested = that the=20 focused approach would be more likely to result in rapid = progress, and=20 other participants at the Virtual Interim agreed with this = suggestion.=20

Since the IETF operates on "rough consensus", it is the = duty of=20 the Chairs to engage the WG participants on issues such as = these, rather=20 than making unilateral decisions.

Subject:=20 RE: Draft RADEXT Virtual Interim Minutes
Date: Sun, 22 Nov = 2009=20 11:57:04 +0100
From: wdec@cisco.com
To:=20 bernard_aboba@hotmail.com
CC: dromasca@avaya.com;=20 radiusext@ops.ietf.org

Bernard,

 

this thread=20 directly stems from the minutes of the meeting. On behalf = of the=20 draft authors I proposed a way forward and = in relation to=20 this I have asked you (as chair) repeatedly for = some=20 answers/clarifications. Now, given that at the n'th = attempt you are=20 still unable to answer them clearly is telling me and other = folks=20 that you're quite simply unwilling or unable to = carry out=20 your duties as chair of this WG.

 

Thanks,

Woj.

 

From: = Bernard=20 Aboba [mailto:bernard_aboba@hotmail.com]
Sent: 21 = November=20 2009 02:59
To: Wojciech Dec (wdec)
Cc: = 'Romascanu,=20 Dan (Dan)'; radiusext@ops.ietf.org
Subject: RE: = Draft RADEXT=20 Virtual Interim Minutes

At=20 the Virtual Interim, the RADEXT WG held a session devoted to = next=20 steps on the IPv6 access work.  During the session, David = Miles=20 suggested a path forward for the IPv6 Access work that = appeared to=20 have consensus among the Virtual Interim attendees.  =

 

In=20 order to confirm that consensus, the RADEXT WG has issued a = Consensus=20 Call to the mailing list (see  =20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html).  =  Please feel free to express your opinions on the list = relating=20 to the consensus that was reached at the Interim.=20   

 

From: = owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org]=20 On Behalf Of Wojciech Dec (wdec)
Sent: = Friday,=20 November 20, 2009 2:03 AM
To: Bernard = Aboba
Cc:=20 Romascanu, Dan (Dan); = radiusext@ops.ietf.org
Subject: RE:=20 Draft RADEXT Virtual Interim Minutes

 

Trying=20 for the 4th time now:

 

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

-=20 Are you now convinced of "interest"? (and if not, or = partially, then=20 on what grounds?)

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

 

Thanks,

Woj.

 

------_=_NextPart_001_01CA6C84.FDAEFAA6-- -- to unsubscribe send a message to radiusext-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 Nov 23 13:58: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 A5AA23A68B3 for ; Mon, 23 Nov 2009 13:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.914 X-Spam-Level: X-Spam-Status: No, score=-5.914 tagged_above=-999 required=5 tests=[AWL=-1.419, 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 Dzx6QxBQ1iy2 for ; Mon, 23 Nov 2009 13:58:16 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 390BB3A67D9 for ; Mon, 23 Nov 2009 13:58:16 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCgre-000Ley-Ew for radiusext-data0@psg.com; Mon, 23 Nov 2009 21:54:30 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCgrd-000Len-IR for radiusext@ops.ietf.org; Mon, 23 Nov 2009 21:54:29 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAM+SCkurRN+K/2dsb2JhbAC/UZc4gi2CDwSBcINr X-IronPort-AV: E=Sophos;i="4.47,273,1257120000"; d="scan'208";a="108485911" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 23 Nov 2009 21:54:24 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nANLsLA4022375; Mon, 23 Nov 2009 21:54:21 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); Mon, 23 Nov 2009 22:54:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Mon, 23 Nov 2009 22:54:14 +0100 Message-ID: In-Reply-To: <8CF160205F4440688CD6BE2812A8DEFD@NEWTON603> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus Call on Broadband Forum Next Steps Thread-Index: Acprk4W/5rWkelX5TXiQ/WKQDdQRrgAndh+QAAE2d4AAAgpkUAARy/BA References: ,<4CA2F69AA99746FB881570A6C2FF7198@NEWTON603> ,<4B095E41.1080202@deployingradius.com> <8CF160205F4440688CD6BE2812A8DEFD@NEWTON603> From: "Wojciech Dec (wdec)" To: "Dave Nelson" , "Romascanu, Dan (Dan)" , "Bernard Aboba" , "Alan DeKok" Cc: X-OriginalArrivalTime: 23 Nov 2009 21:54:20.0969 (UTC) FILETIME=[831EA990:01CA6C87] 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 Dave Nelson > Sent: 23 November 2009 14:21 > To: Wojciech Dec (wdec); 'Romascanu, Dan (Dan)'; 'Bernard=20 > Aboba'; 'Alan DeKok' > Cc: radiusext@ops.ietf.org > Subject: RE: Consensus Call on Broadband Forum Next Steps >=20 > > What are/were these issues? >=20 > Issues are listed in the RADEXT Issues Tracker, located at: >=20 > http://www.drizzle.com/~aboba/RADEXT/ >=20 > The issues on your draft are 317, 321, 322. Thanks, odd that it took so many attempts at getting this answer. That = said, 321 applied (applies?) to = draft-sarikaya-radext-prefix-authorization, which was not part of = http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00. 317 applies to draft-lourdelet-radext-ipv6-access-01 and has been noted = and discussed. On the other hand 322 is quite clearly applicable to any of the drafts = including what appears to have been finally understood at the = illuminative virtual gathering. Does it still apply? Ie is there still a = need to detail the "service aspect" 322 is asking for? Oddly, if one = looks at other Radius draft there isn't quite much more than what's in = our draft today. >=20 > In addition, there are discussions that are logged in the=20 > RADEXT WG mailing list archives. >=20 > > As such=A0we are still expecting a response to the questions posed,=20 > > while tentatively planning to re-present a souped up version of the=20 > > earlier draft(s). >=20 > The only question that I'm aware of is your question of=20 > October 23, that is to say, "If we address the attribute=20 > design issues can this draft move forward"? Uhm... Perhaps reading the follow may help? #1 https://ops.ietf.org/lists/radiusext/2009/msg00552.html #2 https://ops.ietf.org/lists/radiusext/2009/msg00558.html #3 https://ops.ietf.org/lists/radiusext/2009/msg00562.html #4 https://ops.ietf.org/lists/radiusext/2009/msg00635.html >=20 > That's not the way the WG works. There are no shortcuts to=20 > addressing commentary and posting revised drafts. Your=20 > current draft is at -01, so it's not like there has been a=20 > *lot* of revision activity. The best way forward is to=20 I'm sorry, the draft history is presented at = https://ops.ietf.org/lists/radiusext/2009/msg00558.html It would now be 04/05 if not for all the direction/name changes as asked = for by the chairs of this WG (!!) -Woj. > propose *specific* text revisions to address outstanding=20 > comments. You can do that either by submitting a revised=20 > draft, or by submitting sections of OLD and NEW text to the=20 > mailing list to show the WG what changes you propose to make=20 > in the next draft revision. In many ways, that's actually preferable. >=20 >=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 Mon Nov 23 14:04: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 99C2B3A6A7B for ; Mon, 23 Nov 2009 14:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.035 X-Spam-Level: X-Spam-Status: No, score=0.035 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIiGGusag9ZL for ; Mon, 23 Nov 2009 14:04:39 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FC563A6778 for ; Mon, 23 Nov 2009 14:04:38 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCgxO-000MJn-OH for radiusext-data0@psg.com; Mon, 23 Nov 2009 22:00:26 +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 1NCgxM-000MJJ-Bv for radiusext@ops.ietf.org; Mon, 23 Nov 2009 22:00:24 +0000 Received: from BLU137-W30 ([65.55.116.7]) by blu0-omc1-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Nov 2009 14:00:23 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_8124f040-dcd6-4c3f-b4d0-5f0702e1dbb1_" X-Originating-IP: [64.134.221.168] From: Bernard Aboba To: , "dromasca@avaya.com" CC: "radiusext@ops.ietf.org" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Mon, 23 Nov 2009 14:00:23 -0800 Importance: Normal In-Reply-To: <986DCE2E44129444B6435ABE8C9E424D046560AB@SGSINSMBS02.ad4.ad.alcatel.com> References: , ,<986DCE2E44129444B6435ABE8C9E424D046560AB@SGSINSMBS02.ad4.ad.alcatel.com> MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2009 22:00:23.0695 (UTC) FILETIME=[5B5241F0:01CA6C88] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_8124f040-dcd6-4c3f-b4d0-5f0702e1dbb1_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for volunteering. =20 As we discussed during the Virtual Interim=2C a draft focusing on the Broad= band Forum IPv6 over PPP needs has the potential to rapidly address the out= standing issues and enable rapid progress.=20 Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Tue=2C 24 Nov 2009 05:00:18 +0800 From: David.Miles@alcatel-lucent.com To: wdec@cisco.com=3B dromasca@avaya.com=3B bernard_aboba@hotmail.com CC: radiusext@ops.ietf.org In the interest of moving forward=2C I would like to take the crack at this... I noted none of the current authors want to take this work= on =96 I do and I will. I=92ll produce a new draft and author it ... if any of the current authors want to be on the draft please let me know =96 i do not get anything for having my name on a draft=20 =20 I truly understand Woj=92s frustration here but I am here for short term kicks =96 I really need to get this gap sorted out and I hope those that feel stepped on by my course of action can appreciate that = you sometimes need to make sacrifices to get the outcome you need (which here i= s clearly some new RADIUS AVP types). I promise to be designated beer-guy at = all future IETF=92s for those authors feeling hard done by :)=20 =20 -d =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Monday=2C 23 November 2009 11:43 PM To: Romascanu=2C Dan (Dan)=3B Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 As highlighted=2C we (the authors and David) intend progressing on this approa= ch and have discussed it at the last meeting. However we are similarly in agreemen= t as to expecting an answer as to what "issues" do say draft http://tools.ietf.o= rg/html/draft-lourdelet-radext-ipv6-access-00 have=2C if not http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-01 (data type aside). As far as we're concerned addressing previously raised issues is precisely what led to the situation of today.=20 =20 =20 -Woj. =20 From: Romascanu=2C Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: 23 November 2009 14:05 To: Wojciech Dec (wdec)=3B Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes I suggest to everybody to cool down a little and try to work in a constructive manner from where we are right now. Communication seems key in such situations - It looks to me for example that if at least one of the authors of draft-lourdelet-radext-ipv6-access could have attended the meeting many of the hurdles of the current situation would not have existed. Can the document editors and David work together towards issu= ing a revised I-D to be submitted as a basis for consensus?=20 =20 Dan =20 =20 From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: Monday=2C November 23=2C 2009 2:54 PM To: Bernard Aboba Cc: Romascanu=2C Dan (Dan)=3B radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes Bernard=2C =20 as explained in http://www.ops.ietf.org/lists/radiusext/2009/msg00558.html the draft has been repeatedly presented=2C modified based on WG feedback and re-presented (or attempted to). The fact that now there seems to be some opinion=2C consisting effectively of adding descriptive text and an author=2C etc=2C does not address the basic question of what were the issues with the previous draft that have not yet been addressed? In other words and perhaps fundamentally=2C before issuing a consensus call we all would like to know what are the issues with the originally proposed draft? =20 Draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00=2C which had no data-type/tagging controversy and which was presented at IETF74 was claimed to have issues (that actually resulted in 01). This -00 draft now however appears to bear all the hallmarks of what's been claimed as the "virtual meeting" consented way forward=2C give or take additional descriptive text. Have the issues have disappeared? Persistently=2C it has also been claimed that there was no interest in the draft. Is there now interest? My simple 3 questions were aimed at clarifying all this=2C but despite asking numerous times received no clear reply other than some stonewalling (eg check the minutes)=2C or a "consensus call" message which was very odd for a non WG draft to say the least. The implied messaging of changing draft authorship was also highly inconsiderate. =20 Now the above is just one of the many bizarre twists in the story of this draft and its "progress" in Radex. I could go on and on=2C including pointing out chair-101 items like that=3B enquiries regarding vir= tual meeting went un-answered=3B that meeting conclusions have no IETF binding status=3B that there is no obligation to attend meetings (esp ones scheduled in a diff time zone)=3B and that having a discussion on draft *without* any of the draft authors present is highly unusual if not down right wrong. =20 The bottom line as I see it is that instead of facilitating WG progress=2C the activit= y of the WG chairs has and continues to hinder such progress (eg by refusing to even summarize what are any outstanding issues)=2C as well as evidencing some rather dubious chairing practices.=20 Generalizing from this experience=2C I can say that the authors of the draft have the distinct impression that any extensions to Radius are actually less than welcome by the chairs of the Radext WG. =20 regards=2C Woj. =20 =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behal= f Of Bernard Aboba Sent: 22 November 2009 17:07 To: Wojciech Dec (wdec) Cc: dromasca@avaya.com=3B radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes Woj -- The meetings of the RADEXT WG are openly publicized and are available to an= yone (including people who are not physically present). Presentations and agenda items are openly solicited. If you would like time on the agenda of a physical or virtual meeting=2C all you need to do is to post a message= to the WG list and your request will be honored. =20 In your initial message (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you requested guida= nce as to whether it would be better for the work on IPv6 access to proceed wit= h a draft focusing on an initial set of attributes along the lines of the origi= nal submission (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00)= =2C or whether a combined submission would be preferable=2C along the lines of the= -01 submission.=20 That is exactly the issue that is now under consideration within the Consen= sus Call that has been issued. As noted in the virtual interim minutes=2C Davi= d Miles has suggested that the focused approach would be more likely to resul= t in rapid progress=2C and other participants at the Virtual Interim agreed with= this suggestion.=20 Since the IETF operates on "rough consensus"=2C it is the duty of the Chairs to engage the WG participants on issues such as these=2C rather than making unilateral decisions.=20 Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun=2C 22 Nov 2009 11:57:04 +0100 From: wdec@cisco.com To: bernard_aboba@hotmail.com CC: dromasca@avaya.com=3B radiusext@ops.ietf.org Bernard=2C =20 this thread directly stems from the minutes of the meeting. On behalf of the draft authors I proposed a way forward and in relation to this I have asked you (as chair) repeatedly for some answers/clarifications. Now=2C given that at the n'th attempt you are still unable to answer them clearly is telling me and other folks that you're quite simply unwilling or unable to carry out your duties as chair of this WG.=20 =20 Thanks=2C Woj. =20 From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 21 November 2009 02:59 To: Wojciech Dec (wdec) Cc: 'Romascanu=2C Dan (Dan)'=3B radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes At the Virtual Interim=2C the RADEXT WG held a session devoted to next steps on the IPv6 access work. During the session=2C David Miles suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. =20 =20 In order to confirm that consensus=2C the RADEXT WG has issued a Consensus Call to the mailing list (see =20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please feel free to express your opinions on the list relating to the consensus th= at was reached at the Interim. =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behal= f Of Wojciech Dec (wdec) Sent: Friday=2C November 20=2C 2009 2:03 AM To: Bernard Aboba Cc: Romascanu=2C Dan (Dan)=3B radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 Trying for the 4th time now: =20 - 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=2C or partially=2C then on what grounds?) - could you point out (summarise)the issues that were not addressed? =20 Thanks=2C Woj. =20 = --_8124f040-dcd6-4c3f-b4d0-5f0702e1dbb1_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for volunteering. =3B

As we discussed during the Virtual= Interim=2C a draft focusing on the Broadband Forum IPv6 over PPP needs has= the potential to rapidly address the outstanding issues and enable rapid p= rogress.

Subject: RE: Draft RADEXT Virtual = Interim Minutes
Date: Tue=2C 24 Nov 2009 05:00:18 +0800
From: David.M= iles@alcatel-lucent.com
To: wdec@cisco.com=3B dromasca@avaya.com=3B bern= ard_aboba@hotmail.com
CC: radiusext@ops.ietf.org

In the interest o= f moving forward=2C I would like to take the crack at this... I noted none of the current authors want to take this work= on =96 I do and I will. I=92ll produce a new draft and author it ... if any of the current authors want to be on the draft please let me know =96 i do not get anything for having my name on a draft

 =3B

I truly understan= d Woj=92s frustration here but I am here for short term kicks =96 I really need to get this gap sorted out and I hope those that feel stepped on by my course of action can appreciate that = you sometimes need to make sacrifices to get the outcome you need (which here i= s clearly some new RADIUS AVP types). I promise to be designated beer-guy at = all future IETF=92s for those authors feeling hard done by :)

 =3B

-d

 =3B

 =3B

From:= owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wde= c)
Sent: Monday=2C 23 November 2009 11:43 PM
To: Romascanu=2C Dan (Dan)=3B Bernard Aboba
Cc: radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interim Minutes

 =3B

As highlighted=2C we (the authors and David) intend progressing on this approa= ch and have discussed it at the last meeting. However we are similarly in agreemen= t as to expecting an answer as to what "issues" do say draft http://tools.iet= f.org/html/draft-lourdelet-radext-ipv6-access-00 =3Bhave=2C if not http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-01<= /a> (data type aside). As far as we're concerned addressing previously raised issues is precisely what =3Bled to the =3Bsituation of today.

 =3B

 =3B

-Woj.

 =3B

From: Romascanu=2C Dan (Dan) [mailto:dromasca@avaya.com]
Sent: 23 November 2009 14:05
To: Wojciech Dec (wdec)=3B Bernard Aboba
Cc: radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interim Minutes

I suggest to everybody to cool down= a little and try to work in a constructive manner from where we are right now. Communication seems key in such situations - It looks to me for example that if at least one of the authors of draft-lourdelet-radext-ipv6-access = could have attended the meeting many of the hurdles of the current situation would not have existed. Can the document editors and David work together towards issu= ing a revised I-D to be submitted as a basis for consensus?

 =3B

Dan

 =3B

 =3B

From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: Monday=2C November 23=2C 2009 2:54 PM
To: Bernard Aboba
Cc: Romascanu=2C Dan (Dan)=3B radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interim Minutes

Bernard=2C

 =3B

as explained in http://www.ops.ietf.org/lists/radiusext/2009/msg00558.html<= /a> =3Bthe draft has been repeatedly presented=2C modified based on WG =3Bfeedback= and re-presented (or attempted to).

The fact that now there seems to be =3Bsome opinion=2C consisting effective= ly of adding descriptive text =3Band =3Ban author=2C etc=2C =3Bdoes n= ot address the basic question of =3Bwhat were the issues with the previous draft that = have not yet been addressed? In other words and perhaps fundamentally=2C =3B= before issuing a consensus call =3Bwe all would like to know what are the issu= es with the originally =3Bproposed draft?

 =3B

Draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00=2C which had no data-type/tagging controversy and which =3Bwas presented&n= bsp=3Bat IETF74 was claimed to have issues (that actually resulted in 01). This -00 draft now however appears to =3Bbear all the hallmarks of what's been c= laimed as the "virtual meeting" consented =3Bway forward=2C give or take additional descriptive text. Have the =3Bissues have disappeared? Persistently=2C it has =3Balso been claimed that there was no interest = in the draft. Is there now interest?

My simple 3 questions were aimed at clarifying all this=2C but despite asking numerous times received no clear reply other than some stonewalling =3B= (eg check the minutes)=2C or =3Ba "consensus call" message =3Bwhich was very =3Bodd for =3Ba non =3BWG =3Bdraft to say the least. T= he implied messaging of changing draft authorship was also highly inconsiderate.

 =3B

Now the above =3Bis just one of the many =3Bbizarre twists in the story= of this draft =3Band its "progress" in Radex. I could go on and on=2C including pointing out chair-101 items like that=3B enquiries regarding vir= tual meeting =3Bwent un-answered=3B that =3Bmeeting conclusions =3Bh= ave no IETF =3B binding status=3B that there is no obligation to attend meetin= gs (esp ones scheduled in a diff time zone)=3B and that having a discussion on draft =3B*without* any of the draft authors present is highly unusual i= f not down right wrong.

 =3B

The =3Bbottom line as I see it =3Bis that instead of facilitating WG progress=2C the = activity of the WG =3Bchairs has =3Band continues to hinder such progress (e= g by refusing to even summarize what are any outstanding =3Bissues)=2C as we= ll as evidencing =3Bsome rather dubious =3Bchairing practices.

Generalizing from this experience=2C I can say that the authors of the draft =3Bhave= the distinct impression that any extensions to Radius are actually less than =3Bwelcome by the chairs of the Radext WG.

 =3B

regards=2C

Woj.

 =3B

 =3B

 =3B

From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Be= half Of Bernard Aboba
Sent: 22 November 2009 17:07
To: Wojciech Dec (wdec)
Cc: dromasca@avaya.com=3B radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interim Minutes

Woj --

The meetings of the RADEXT WG are openly publicized and are available to an= yone (including people who are not physically present). =3B Presentations an= d agenda items are openly solicited. =3B If you would like time on the ag= enda of a physical or virtual meeting=2C all you need to do is to post a message= to the WG list and your request will be honored. =3B

In your initial message (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you requested guida= nce as to whether it would be better for the work on IPv6 access to proceed wit= h a draft focusing on an initial set of attributes along the lines of the origi= nal submission (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00)= =2C or whether a combined submission would be preferable=2C along the lines of the= -01 submission.

That is exactly the issue that is now under consideration within the Consen= sus Call that has been issued. =3B As noted in the virtual interim minutes= =2C David Miles has suggested that the focused approach would be more likely to resul= t in rapid progress=2C and other participants at the Virtual Interim agreed with= this suggestion.

Since the IETF operates on "rough consensus"=2C it is the duty of the Chairs to engage the WG participants on issues such as these=2C rather than making unilateral decisions.

Subject: RE: Dr= aft RADEXT Virtual Interim Minutes
Date: Sun=2C 22 Nov 2009 11:57:04 +0100
From: wdec@cisco.com
To: bernard_aboba@hotmail.com
CC: dromasca@avaya.com=3B radiusext@ops.ietf.org

Bernard= =2C

 =3B

this thre= ad directly stems from the minutes of the meeting. =3BOn behalf of the draft authors I =3Bproposed =3Ba way forward and in =3Brelation to this =3BI =3Bhave asked you (as chair) =3Brepeatedly for some answers/clarifications. Now=2C given that at the n'th attempt =3Byou ar= e still unable to answer them clearly =3Bis telling me and other folks that =3Byou're quite =3Bsimply unwilling or unable =3Bto carry = out your duties as chair of this WG.

 =3B

Thanks=2C=

Woj.

 =3B

From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: 21 November 2009 02:59
To: Wojciech Dec (wdec)
Cc: 'Romascanu=2C Dan (Dan)'=3B radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interim Minutes

At the Virtual In= terim=2C the RADEXT WG held a session devoted to next steps on the IPv6 access work. =3B During the session=2C David Mil= es suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. =3B

 =3B

In order to confi= rm that consensus=2C the RADEXT WG has issued a Consensus Call to the mailing list (see =3B =3B http://ops.ietf.org/lists/radiusext/2009/msg00636.html). =3B  =3BPl= ease feel free to express your opinions on the list relating to the consensus th= at was reached at the Interim.  =3B =3B

 =3B

From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Be= half Of Wojciech Dec (wdec)
Sent: Friday=2C November 20=2C 2009 2:03 AM
To: Bernard Aboba
Cc: Romascanu=2C Dan (Dan)=3B radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interim Minutes

 =3B

Trying for the 4th time now:

 =3B

- could you confirm that =3Bwh= at =3Bmy mail =3Boutlined in terms of moving forward =3Bis also your expectation? =3B

- Are you now convinced of "intere= st"? (and if not=2C or partially=2C then on what grounds?)

- could you point out (summarise)t= he issues =3Bthat were not addressed?

 =3B

Thanks=2C

Woj.

 =3B

= --_8124f040-dcd6-4c3f-b4d0-5f0702e1dbb1_-- -- to unsubscribe send a message to radiusext-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 Nov 23 14:42: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 A24933A6AD4 for ; Mon, 23 Nov 2009 14:42:04 -0800 (PST) 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 ZfaRn8Pr39aq for ; Mon, 23 Nov 2009 14:42:03 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D6B33A6971 for ; Mon, 23 Nov 2009 14:42:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NChYs-0000Rc-Oa for radiusext-data0@psg.com; Mon, 23 Nov 2009 22:39:10 +0000 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NChYr-0000Mw-QC for radiusext@ops.ietf.org; Mon, 23 Nov 2009 22:39:10 +0000 Received: (qmail 18164 invoked from network); 23 Nov 2009 22:38:30 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 23 Nov 2009 22:38:30 -0000 Message-Id: <257D828C-16E8-4564-8FA1-6750784A65D3@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: Consensus Call on Broadband Forum Next Steps Date: Mon, 23 Nov 2009 17:38:29 -0500 References: ,<4CA2F69AA99746FB881570A6C2FF7198@NEWTON603> ,<4B095E41.1080202@deployingradius.com> <8CF160205F4440688CD6BE2812A8DEFD@NEWTON603> X-Mailer: Apple Mail (2.936) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: On Nov 23, 2009, at 4:54 PM, Wojciech Dec (wdec) wrote: >> Issues are listed in the RADEXT Issues Tracker, located at: >> >> http://www.drizzle.com/~aboba/RADEXT/ >> >> The issues on your draft are 317, 321, 322. > > Thanks, odd that it took so many attempts at getting this answer. Sorry. I didn't realize that's what you were asking. After all, the location of the Issues Tracker is well know to regular RADEXT WG members, is listed on the WG charter page, is included in the instructions for all WGLC, etc. > On the other hand 322 is quite clearly applicable to any of the > drafts including what appears to have been finally understood > at the illuminative virtual gathering. Does it still apply? Ie is > there > still a need to detail the "service aspect" 322 is asking for? Oddly, > if one looks at other Radius draft there isn't quite much more than > what's in our draft today. RADIUS is all about provisioning well-know services. We explicitly discourage defining new services within the scope of a RADIUS document. Further, if there is no a convenient reference, e.g. a Section of an RFC, that clearly and unambiguously describes *exactly* what the RADIUS Attribute in question is intended to provision, then some added detail needs to be provided. When I say "exactly", I mean without addition, deletion or transformation. > #1 https://ops.ietf.org/lists/radiusext/2009/msg00552.html Q: 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? A: That's the subject of the currently ongoing consensus call. Q: Are you now convinced of "interest"? A: Interest is measured by non-author reviewers who actively contribute commentary on the WG mailing list. > #2 https://ops.ietf.org/lists/radiusext/2009/msg00558.html Nothing in that message ends with a "?". > #3 https://ops.ietf.org/lists/radiusext/2009/msg00562.html Q: could you point out (summarise) the issues that were not addressed? A: Asked and answered. > #4 https://ops.ietf.org/lists/radiusext/2009/msg00635.html Duplicate questions. -- to unsubscribe send a message to radiusext-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 Nov 28 16:21:24 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 94FAF3A67C0 for ; Sat, 28 Nov 2009 16:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[AWL=-1.620, 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 E7yQF3xueHco for ; Sat, 28 Nov 2009 16:21:23 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3B98B3A6821 for ; Sat, 28 Nov 2009 16:21:23 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NEXTO-000JMm-82 for radiusext-data0@psg.com; Sun, 29 Nov 2009 00:17:06 +0000 Received: from [65.55.116.36] (helo=blu0-omc1-s25.blu0.hotmail.com) by psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NEXTN-000JMc-1i for radiusext@ops.ietf.org; Sun, 29 Nov 2009 00:17:05 +0000 Received: from BLU137-W13 ([65.55.116.9]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 28 Nov 2009 16:17:04 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_301452d5-b48d-412a-8ffc-da562a38d53e_" X-Originating-IP: [131.107.0.82] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RADEXT WG Last Call on Status-Server Document Date: Sat, 28 Nov 2009 16:17:04 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 29 Nov 2009 00:17:04.0266 (UTC) FILETIME=[474ED6A0:01CA7089] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_301452d5-b48d-412a-8ffc-da562a38d53e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on the Status-Server Documen= t=2C prior to requesting that the IESG approve it for publication as an Inf= ormational RFC. =20 The document is available for inspection here: http://tools.ietf.org/html/draft-ietf-radext-status-server RADEXT WG last call will last until December 15=2C 2009. =20 Regardless of whether you have comments or not=2C please send your opinion = on the document's suitability for publication to the RADEXT WG mailing list= (radiusext@ops.ietf.org). If you have comments to submit=2C please send t= hem in the format described in the RADEXT WG Issues list (http://www.drizzl= e.com/~aboba/RADEXT). =20 = --_301452d5-b48d-412a-8ffc-da562a38d53e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on the Status-Server Documen= t=2C prior to requesting that the IESG approve it for publication as an Inf= ormational RFC. =3B

The document is available for inspection he= re:
http://tools.ietf.org/html/draft-ietf-radext-status-server

RA= DEXT WG last call will last until December 15=2C 2009. =3B

Rega= rdless of whether you have comments or not=2C please send your opinion on t= he document's suitability for publication to the RADEXT WG mailing list (ra= diusext@ops.ietf.org). =3B If you have comments to submit=2C please sen= d them in the format described in the RADEXT WG Issues list (http://www.dri= zzle.com/~aboba/RADEXT).  =3B





= --_301452d5-b48d-412a-8ffc-da562a38d53e_-- -- to unsubscribe send a message to radiusext-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 Nov 28 16:22: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 1C4FE3A67C0 for ; Sat, 28 Nov 2009 16:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.526 X-Spam-Level: X-Spam-Status: No, score=0.526 tagged_above=-999 required=5 tests=[AWL=-1.580, 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 JJIq7SnZojyV for ; Sat, 28 Nov 2009 16:21:59 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 360F53A67AE for ; Sat, 28 Nov 2009 16:21:59 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NEXV4-000JS9-IN for radiusext-data0@psg.com; Sun, 29 Nov 2009 00:18:50 +0000 Received: from [65.55.116.40] (helo=blu0-omc1-s29.blu0.hotmail.com) by psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NEXV3-000JRy-N4 for radiusext@ops.ietf.org; Sun, 29 Nov 2009 00:18:49 +0000 Received: from BLU137-W5 ([65.55.116.7]) by blu0-omc1-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 28 Nov 2009 16:18:49 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_a821147b-bf58-42ca-ae22-2b5b2f77e6cb_" X-Originating-IP: [131.107.0.82] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RADEXT WG Last Call on the RADIUS over TCP Document Date: Sat, 28 Nov 2009 16:18:48 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 29 Nov 2009 00:18:49.0050 (UTC) FILETIME=[85C39BA0:01CA7089] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_a821147b-bf58-42ca-ae22-2b5b2f77e6cb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on the RADIUS over TCP Docum= ent=2C prior to requesting that the IESG approve it for publication as an Experimental RFC. =20 The document is available for inspection here: http://tools.ietf.org/html/draft-ietf-radext-tcp-transport RADEXT WG last call will last until December 15=2C 2009. =20 Regardless of whether you have comments or not=2C please send your opinion on the document's suitability for publication to the RADEXT WG mailing list (radiusext@ops.ietf.org). If you have comments to submit=2C please send them in the format described in the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT). =20 = --_a821147b-bf58-42ca-ae22-2b5b2f77e6cb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on the RADIUS over TCP Docum= ent=2C prior to requesting that the IESG approve it for publication as an Experimental RFC. =3B

The document is available for inspection here:
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

RADEXT WG last call will last until December 15=2C 2009. =3B

Regardless of whether you have comments or not=2C please send your opinion on the document's suitability for publication to the RADEXT WG mailing list (radiusext@ops.ietf.org). =3B If you have comments to subm= it=2C please send them in the format described in the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT). =3B




= = --_a821147b-bf58-42ca-ae22-2b5b2f77e6cb_-- -- to unsubscribe send a message to radiusext-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 Nov 30 07:58:24 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 026B63A6A8F for ; Mon, 30 Nov 2009 07:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[AWL=-1.541, 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 r8BlN7eVgNX3 for ; Mon, 30 Nov 2009 07:58:23 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D8FFB3A6886 for ; Mon, 30 Nov 2009 07:58:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NF8Z0-0006EX-L2 for radiusext-data0@psg.com; Mon, 30 Nov 2009 15:53:22 +0000 Received: from [65.55.116.43] (helo=blu0-omc1-s32.blu0.hotmail.com) by psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NF8Yz-0006EG-0K for radiusext@ops.ietf.org; Mon, 30 Nov 2009 15:53:21 +0000 Received: from BLU137-W23 ([65.55.116.9]) by blu0-omc1-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 07:53:19 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_ab8992de-c2d8-43e1-957c-cb18d692ab93_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RADEXT WG Last Call on the RADIUS over TCP Document Date: Mon, 30 Nov 2009 07:53:19 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 30 Nov 2009 15:53:19.0165 (UTC) FILETIME=[3C91EED0:01CA71D5] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_ab8992de-c2d8-43e1-957c-cb18d692ab93_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on the RADIUS over TCP Docum= ent=2C prior to requesting that the IESG approve it for publication as an Experimental RFC. =20 The document is available for inspection here: http://tools.ietf.org/html/draft-ietf-radext-tcp-transport RADEXT WG last call will last until December 15=2C 2009. =20 Regardless of whether you have comments or not=2C please send your opinion on the document's suitability for publication to the RADEXT WG mailing list (radiusext@ops.ietf.org). If you have comments to submit=2C please send them in the format described in the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT). =20 = --_ab8992de-c2d8-43e1-957c-cb18d692ab93_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This is an announcement of RADEX= T WG last call on the RADIUS over TCP Document=2C prior to requesting that = the IESG approve it for publication as an Experimental RFC. =3B

The document is available for inspection here:
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

RADEXT WG last call will last until December 15=2C 2009. =3B

Regardless of whether you have comments or not=2C please send your opinion on the document's suitability for publication to the RADEXT WG mailing list (radiusext@ops.ietf.org). =3B If you have comments to subm= it=2C please send them in the format described in the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT). =3B

= = --_ab8992de-c2d8-43e1-957c-cb18d692ab93_-- -- to unsubscribe send a 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, 30 Nov 2009 15:54:34 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_ab8992de-c2d8-43e1-957c-cb18d692ab93_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RADEXT WG Last Call on the RADIUS over TCP Document Date: Mon, 30 Nov 2009 07:53:19 -0800 MIME-Version: 1.0 --_ab8992de-c2d8-43e1-957c-cb18d692ab93_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on the RADIUS over TCP Docum= ent=2C prior to requesting that the IESG approve it for publication as an Experimental RFC. =20 The document is available for inspection here: http://tools.ietf.org/html/draft-ietf-radext-tcp-transport RADEXT WG last call will last until December 15=2C 2009. =20 Regardless of whether you have comments or not=2C please send your opinion on the document's suitability for publication to the RADEXT WG mailing list (radiusext@ops.ietf.org). If you have comments to submit=2C please send them in the format described in the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT). =20 = --_ab8992de-c2d8-43e1-957c-cb18d692ab93_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This is an announcement of RADEX= T WG last call on the RADIUS over TCP Document=2C prior to requesting that = the IESG approve it for publication as an Experimental RFC. =3B

The document is available for inspection here:
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

RADEXT WG last call will last until December 15=2C 2009. =3B

Regardless of whether you have comments or not=2C please send your opinion on the document's suitability for publication to the RADEXT WG mailing list (radiusext@ops.ietf.org). =3B If you have comments to subm= it=2C please send them in the format described in the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT). =3B

= = --_ab8992de-c2d8-43e1-957c-cb18d692ab93_-- -- to unsubscribe send a 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, 29 Nov 2009 00:19:12 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_a821147b-bf58-42ca-ae22-2b5b2f77e6cb_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RADEXT WG Last Call on the RADIUS over TCP Document Date: Sat, 28 Nov 2009 16:18:48 -0800 MIME-Version: 1.0 --_a821147b-bf58-42ca-ae22-2b5b2f77e6cb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on the RADIUS over TCP Docum= ent=2C prior to requesting that the IESG approve it for publication as an Experimental RFC. =20 The document is available for inspection here: http://tools.ietf.org/html/draft-ietf-radext-tcp-transport RADEXT WG last call will last until December 15=2C 2009. =20 Regardless of whether you have comments or not=2C please send your opinion on the document's suitability for publication to the RADEXT WG mailing list (radiusext@ops.ietf.org). If you have comments to submit=2C please send them in the format described in the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT). =20 = --_a821147b-bf58-42ca-ae22-2b5b2f77e6cb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on the RADIUS over TCP Docum= ent=2C prior to requesting that the IESG approve it for publication as an Experimental RFC. =3B

The document is available for inspection here:
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

RADEXT WG last call will last until December 15=2C 2009. =3B

Regardless of whether you have comments or not=2C please send your opinion on the document's suitability for publication to the RADEXT WG mailing list (radiusext@ops.ietf.org). =3B If you have comments to subm= it=2C please send them in the format described in the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT). =3B




= = --_a821147b-bf58-42ca-ae22-2b5b2f77e6cb_-- -- to unsubscribe send a 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, 29 Nov 2009 00:18:25 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_301452d5-b48d-412a-8ffc-da562a38d53e_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RADEXT WG Last Call on Status-Server Document Date: Sat, 28 Nov 2009 16:17:04 -0800 MIME-Version: 1.0 --_301452d5-b48d-412a-8ffc-da562a38d53e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on the Status-Server Documen= t=2C prior to requesting that the IESG approve it for publication as an Inf= ormational RFC. =20 The document is available for inspection here: http://tools.ietf.org/html/draft-ietf-radext-status-server RADEXT WG last call will last until December 15=2C 2009. =20 Regardless of whether you have comments or not=2C please send your opinion = on the document's suitability for publication to the RADEXT WG mailing list= (radiusext@ops.ietf.org). If you have comments to submit=2C please send t= hem in the format described in the RADEXT WG Issues list (http://www.drizzl= e.com/~aboba/RADEXT). =20 = --_301452d5-b48d-412a-8ffc-da562a38d53e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on the Status-Server Documen= t=2C prior to requesting that the IESG approve it for publication as an Inf= ormational RFC. =3B

The document is available for inspection he= re:
http://tools.ietf.org/html/draft-ietf-radext-status-server

RA= DEXT WG last call will last until December 15=2C 2009. =3B

Rega= rdless of whether you have comments or not=2C please send your opinion on t= he document's suitability for publication to the RADEXT WG mailing list (ra= diusext@ops.ietf.org). =3B If you have comments to submit=2C please sen= d them in the format described in the RADEXT WG Issues list (http://www.dri= zzle.com/~aboba/RADEXT).  =3B





= --_301452d5-b48d-412a-8ffc-da562a38d53e_-- -- to unsubscribe send a 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, 23 Nov 2009 22:39:45 +0000 Message-Id: <257D828C-16E8-4564-8FA1-6750784A65D3@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: Consensus Call on Broadband Forum Next Steps Date: Mon, 23 Nov 2009 17:38:29 -0500 On Nov 23, 2009, at 4:54 PM, Wojciech Dec (wdec) wrote: >> Issues are listed in the RADEXT Issues Tracker, located at: >> >> http://www.drizzle.com/~aboba/RADEXT/ >> >> The issues on your draft are 317, 321, 322. > > Thanks, odd that it took so many attempts at getting this answer. Sorry. I didn't realize that's what you were asking. After all, the location of the Issues Tracker is well know to regular RADEXT WG members, is listed on the WG charter page, is included in the instructions for all WGLC, etc. > On the other hand 322 is quite clearly applicable to any of the > drafts including what appears to have been finally understood > at the illuminative virtual gathering. Does it still apply? Ie is > there > still a need to detail the "service aspect" 322 is asking for? Oddly, > if one looks at other Radius draft there isn't quite much more than > what's in our draft today. RADIUS is all about provisioning well-know services. We explicitly discourage defining new services within the scope of a RADIUS document. Further, if there is no a convenient reference, e.g. a Section of an RFC, that clearly and unambiguously describes *exactly* what the RADIUS Attribute in question is intended to provision, then some added detail needs to be provided. When I say "exactly", I mean without addition, deletion or transformation. > #1 https://ops.ietf.org/lists/radiusext/2009/msg00552.html Q: 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? A: That's the subject of the currently ongoing consensus call. Q: Are you now convinced of "interest"? A: Interest is measured by non-author reviewers who actively contribute commentary on the WG mailing list. > #2 https://ops.ietf.org/lists/radiusext/2009/msg00558.html Nothing in that message ends with a "?". > #3 https://ops.ietf.org/lists/radiusext/2009/msg00562.html Q: could you point out (summarise) the issues that were not addressed? A: Asked and answered. > #4 https://ops.ietf.org/lists/radiusext/2009/msg00635.html Duplicate questions. -- to unsubscribe send a 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, 23 Nov 2009 22:00:39 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_8124f040-dcd6-4c3f-b4d0-5f0702e1dbb1_" From: Bernard Aboba To: , "dromasca@avaya.com" CC: "radiusext@ops.ietf.org" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Mon, 23 Nov 2009 14:00:23 -0800 MIME-Version: 1.0 --_8124f040-dcd6-4c3f-b4d0-5f0702e1dbb1_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for volunteering. =20 As we discussed during the Virtual Interim=2C a draft focusing on the Broad= band Forum IPv6 over PPP needs has the potential to rapidly address the out= standing issues and enable rapid progress.=20 Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Tue=2C 24 Nov 2009 05:00:18 +0800 From: David.Miles@alcatel-lucent.com To: wdec@cisco.com=3B dromasca@avaya.com=3B bernard_aboba@hotmail.com CC: radiusext@ops.ietf.org In the interest of moving forward=2C I would like to take the crack at this... I noted none of the current authors want to take this work= on =96 I do and I will. I=92ll produce a new draft and author it ... if any of the current authors want to be on the draft please let me know =96 i do not get anything for having my name on a draft=20 =20 I truly understand Woj=92s frustration here but I am here for short term kicks =96 I really need to get this gap sorted out and I hope those that feel stepped on by my course of action can appreciate that = you sometimes need to make sacrifices to get the outcome you need (which here i= s clearly some new RADIUS AVP types). I promise to be designated beer-guy at = all future IETF=92s for those authors feeling hard done by :)=20 =20 -d =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Monday=2C 23 November 2009 11:43 PM To: Romascanu=2C Dan (Dan)=3B Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 As highlighted=2C we (the authors and David) intend progressing on this approa= ch and have discussed it at the last meeting. However we are similarly in agreemen= t as to expecting an answer as to what "issues" do say draft http://tools.ietf.o= rg/html/draft-lourdelet-radext-ipv6-access-00 have=2C if not http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-01 (data type aside). As far as we're concerned addressing previously raised issues is precisely what led to the situation of today.=20 =20 =20 -Woj. =20 From: Romascanu=2C Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: 23 November 2009 14:05 To: Wojciech Dec (wdec)=3B Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes I suggest to everybody to cool down a little and try to work in a constructive manner from where we are right now. Communication seems key in such situations - It looks to me for example that if at least one of the authors of draft-lourdelet-radext-ipv6-access could have attended the meeting many of the hurdles of the current situation would not have existed. Can the document editors and David work together towards issu= ing a revised I-D to be submitted as a basis for consensus?=20 =20 Dan =20 =20 From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: Monday=2C November 23=2C 2009 2:54 PM To: Bernard Aboba Cc: Romascanu=2C Dan (Dan)=3B radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes Bernard=2C =20 as explained in http://www.ops.ietf.org/lists/radiusext/2009/msg00558.html the draft has been repeatedly presented=2C modified based on WG feedback and re-presented (or attempted to). The fact that now there seems to be some opinion=2C consisting effectively of adding descriptive text and an author=2C etc=2C does not address the basic question of what were the issues with the previous draft that have not yet been addressed? In other words and perhaps fundamentally=2C before issuing a consensus call we all would like to know what are the issues with the originally proposed draft? =20 Draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00=2C which had no data-type/tagging controversy and which was presented at IETF74 was claimed to have issues (that actually resulted in 01). This -00 draft now however appears to bear all the hallmarks of what's been claimed as the "virtual meeting" consented way forward=2C give or take additional descriptive text. Have the issues have disappeared? Persistently=2C it has also been claimed that there was no interest in the draft. Is there now interest? My simple 3 questions were aimed at clarifying all this=2C but despite asking numerous times received no clear reply other than some stonewalling (eg check the minutes)=2C or a "consensus call" message which was very odd for a non WG draft to say the least. The implied messaging of changing draft authorship was also highly inconsiderate. =20 Now the above is just one of the many bizarre twists in the story of this draft and its "progress" in Radex. I could go on and on=2C including pointing out chair-101 items like that=3B enquiries regarding vir= tual meeting went un-answered=3B that meeting conclusions have no IETF binding status=3B that there is no obligation to attend meetings (esp ones scheduled in a diff time zone)=3B and that having a discussion on draft *without* any of the draft authors present is highly unusual if not down right wrong. =20 The bottom line as I see it is that instead of facilitating WG progress=2C the activit= y of the WG chairs has and continues to hinder such progress (eg by refusing to even summarize what are any outstanding issues)=2C as well as evidencing some rather dubious chairing practices.=20 Generalizing from this experience=2C I can say that the authors of the draft have the distinct impression that any extensions to Radius are actually less than welcome by the chairs of the Radext WG. =20 regards=2C Woj. =20 =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behal= f Of Bernard Aboba Sent: 22 November 2009 17:07 To: Wojciech Dec (wdec) Cc: dromasca@avaya.com=3B radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes Woj -- The meetings of the RADEXT WG are openly publicized and are available to an= yone (including people who are not physically present). Presentations and agenda items are openly solicited. If you would like time on the agenda of a physical or virtual meeting=2C all you need to do is to post a message= to the WG list and your request will be honored. =20 In your initial message (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you requested guida= nce as to whether it would be better for the work on IPv6 access to proceed wit= h a draft focusing on an initial set of attributes along the lines of the origi= nal submission (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00)= =2C or whether a combined submission would be preferable=2C along the lines of the= -01 submission.=20 That is exactly the issue that is now under consideration within the Consen= sus Call that has been issued. As noted in the virtual interim minutes=2C Davi= d Miles has suggested that the focused approach would be more likely to resul= t in rapid progress=2C and other participants at the Virtual Interim agreed with= this suggestion.=20 Since the IETF operates on "rough consensus"=2C it is the duty of the Chairs to engage the WG participants on issues such as these=2C rather than making unilateral decisions.=20 Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun=2C 22 Nov 2009 11:57:04 +0100 From: wdec@cisco.com To: bernard_aboba@hotmail.com CC: dromasca@avaya.com=3B radiusext@ops.ietf.org Bernard=2C =20 this thread directly stems from the minutes of the meeting. On behalf of the draft authors I proposed a way forward and in relation to this I have asked you (as chair) repeatedly for some answers/clarifications. Now=2C given that at the n'th attempt you are still unable to answer them clearly is telling me and other folks that you're quite simply unwilling or unable to carry out your duties as chair of this WG.=20 =20 Thanks=2C Woj. =20 From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 21 November 2009 02:59 To: Wojciech Dec (wdec) Cc: 'Romascanu=2C Dan (Dan)'=3B radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes At the Virtual Interim=2C the RADEXT WG held a session devoted to next steps on the IPv6 access work. During the session=2C David Miles suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. =20 =20 In order to confirm that consensus=2C the RADEXT WG has issued a Consensus Call to the mailing list (see =20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please feel free to express your opinions on the list relating to the consensus th= at was reached at the Interim. =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behal= f Of Wojciech Dec (wdec) Sent: Friday=2C November 20=2C 2009 2:03 AM To: Bernard Aboba Cc: Romascanu=2C Dan (Dan)=3B radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 Trying for the 4th time now: =20 - 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=2C or partially=2C then on what grounds?) - could you point out (summarise)the issues that were not addressed? =20 Thanks=2C Woj. =20 = --_8124f040-dcd6-4c3f-b4d0-5f0702e1dbb1_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for volunteering. =3B

As we discussed during the Virtual= Interim=2C a draft focusing on the Broadband Forum IPv6 over PPP needs has= the potential to rapidly address the outstanding issues and enable rapid p= rogress.

Subject: RE: Draft RADEXT Virtual = Interim Minutes
Date: Tue=2C 24 Nov 2009 05:00:18 +0800
From: David.M= iles@alcatel-lucent.com
To: wdec@cisco.com=3B dromasca@avaya.com=3B bern= ard_aboba@hotmail.com
CC: radiusext@ops.ietf.org

In the interest o= f moving forward=2C I would like to take the crack at this... I noted none of the current authors want to take this work= on =96 I do and I will. I=92ll produce a new draft and author it ... if any of the current authors want to be on the draft please let me know =96 i do not get anything for having my name on a draft

 =3B

I truly understan= d Woj=92s frustration here but I am here for short term kicks =96 I really need to get this gap sorted out and I hope those that feel stepped on by my course of action can appreciate that = you sometimes need to make sacrifices to get the outcome you need (which here i= s clearly some new RADIUS AVP types). I promise to be designated beer-guy at = all future IETF=92s for those authors feeling hard done by :)

 =3B

-d

 =3B

 =3B

From:= owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wde= c)
Sent: Monday=2C 23 November 2009 11:43 PM
To: Romascanu=2C Dan (Dan)=3B Bernard Aboba
Cc: radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interim Minutes

 =3B

As highlighted=2C we (the authors and David) intend progressing on this approa= ch and have discussed it at the last meeting. However we are similarly in agreemen= t as to expecting an answer as to what "issues" do say draft http://tools.iet= f.org/html/draft-lourdelet-radext-ipv6-access-00 =3Bhave=2C if not http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-01<= /a> (data type aside). As far as we're concerned addressing previously raised issues is precisely what =3Bled to the =3Bsituation of today.

 =3B

 =3B

-Woj.

 =3B

From: Romascanu=2C Dan (Dan) [mailto:dromasca@avaya.com]
Sent: 23 November 2009 14:05
To: Wojciech Dec (wdec)=3B Bernard Aboba
Cc: radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interim Minutes

I suggest to everybody to cool down= a little and try to work in a constructive manner from where we are right now. Communication seems key in such situations - It looks to me for example that if at least one of the authors of draft-lourdelet-radext-ipv6-access = could have attended the meeting many of the hurdles of the current situation would not have existed. Can the document editors and David work together towards issu= ing a revised I-D to be submitted as a basis for consensus?

 =3B

Dan

 =3B

 =3B

From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: Monday=2C November 23=2C 2009 2:54 PM
To: Bernard Aboba
Cc: Romascanu=2C Dan (Dan)=3B radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interim Minutes

Bernard=2C

 =3B

as explained in http://www.ops.ietf.org/lists/radiusext/2009/msg00558.html<= /a> =3Bthe draft has been repeatedly presented=2C modified based on WG =3Bfeedback= and re-presented (or attempted to).

The fact that now there seems to be =3Bsome opinion=2C consisting effective= ly of adding descriptive text =3Band =3Ban author=2C etc=2C =3Bdoes n= ot address the basic question of =3Bwhat were the issues with the previous draft that = have not yet been addressed? In other words and perhaps fundamentally=2C =3B= before issuing a consensus call =3Bwe all would like to know what are the issu= es with the originally =3Bproposed draft?

 =3B

Draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00=2C which had no data-type/tagging controversy and which =3Bwas presented&n= bsp=3Bat IETF74 was claimed to have issues (that actually resulted in 01). This -00 draft now however appears to =3Bbear all the hallmarks of what's been c= laimed as the "virtual meeting" consented =3Bway forward=2C give or take additional descriptive text. Have the =3Bissues have disappeared? Persistently=2C it has =3Balso been claimed that there was no interest = in the draft. Is there now interest?

My simple 3 questions were aimed at clarifying all this=2C but despite asking numerous times received no clear reply other than some stonewalling =3B= (eg check the minutes)=2C or =3Ba "consensus call" message =3Bwhich was very =3Bodd for =3Ba non =3BWG =3Bdraft to say the least. T= he implied messaging of changing draft authorship was also highly inconsiderate.

 =3B

Now the above =3Bis just one of the many =3Bbizarre twists in the story= of this draft =3Band its "progress" in Radex. I could go on and on=2C including pointing out chair-101 items like that=3B enquiries regarding vir= tual meeting =3Bwent un-answered=3B that =3Bmeeting conclusions =3Bh= ave no IETF =3B binding status=3B that there is no obligation to attend meetin= gs (esp ones scheduled in a diff time zone)=3B and that having a discussion on draft =3B*without* any of the draft authors present is highly unusual i= f not down right wrong.

 =3B

The =3Bbottom line as I see it =3Bis that instead of facilitating WG progress=2C the = activity of the WG =3Bchairs has =3Band continues to hinder such progress (e= g by refusing to even summarize what are any outstanding =3Bissues)=2C as we= ll as evidencing =3Bsome rather dubious =3Bchairing practices.

Generalizing from this experience=2C I can say that the authors of the draft =3Bhave= the distinct impression that any extensions to Radius are actually less than =3Bwelcome by the chairs of the Radext WG.

 =3B

regards=2C

Woj.

 =3B

 =3B

 =3B

From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Be= half Of Bernard Aboba
Sent: 22 November 2009 17:07
To: Wojciech Dec (wdec)
Cc: dromasca@avaya.com=3B radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interim Minutes

Woj --

The meetings of the RADEXT WG are openly publicized and are available to an= yone (including people who are not physically present). =3B Presentations an= d agenda items are openly solicited. =3B If you would like time on the ag= enda of a physical or virtual meeting=2C all you need to do is to post a message= to the WG list and your request will be honored. =3B

In your initial message (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you requested guida= nce as to whether it would be better for the work on IPv6 access to proceed wit= h a draft focusing on an initial set of attributes along the lines of the origi= nal submission (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00)= =2C or whether a combined submission would be preferable=2C along the lines of the= -01 submission.

That is exactly the issue that is now under consideration within the Consen= sus Call that has been issued. =3B As noted in the virtual interim minutes= =2C David Miles has suggested that the focused approach would be more likely to resul= t in rapid progress=2C and other participants at the Virtual Interim agreed with= this suggestion.

Since the IETF operates on "rough consensus"=2C it is the duty of the Chairs to engage the WG participants on issues such as these=2C rather than making unilateral decisions.

Subject: RE: Dr= aft RADEXT Virtual Interim Minutes
Date: Sun=2C 22 Nov 2009 11:57:04 +0100
From: wdec@cisco.com
To: bernard_aboba@hotmail.com
CC: dromasca@avaya.com=3B radiusext@ops.ietf.org

Bernard= =2C

 =3B

this thre= ad directly stems from the minutes of the meeting. =3BOn behalf of the draft authors I =3Bproposed =3Ba way forward and in =3Brelation to this =3BI =3Bhave asked you (as chair) =3Brepeatedly for some answers/clarifications. Now=2C given that at the n'th attempt =3Byou ar= e still unable to answer them clearly =3Bis telling me and other folks that =3Byou're quite =3Bsimply unwilling or unable =3Bto carry = out your duties as chair of this WG.

 =3B

Thanks=2C=

Woj.

 =3B

From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: 21 November 2009 02:59
To: Wojciech Dec (wdec)
Cc: 'Romascanu=2C Dan (Dan)'=3B radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interim Minutes

At the Virtual In= terim=2C the RADEXT WG held a session devoted to next steps on the IPv6 access work. =3B During the session=2C David Mil= es suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. =3B

 =3B

In order to confi= rm that consensus=2C the RADEXT WG has issued a Consensus Call to the mailing list (see =3B =3B http://ops.ietf.org/lists/radiusext/2009/msg00636.html). =3B  =3BPl= ease feel free to express your opinions on the list relating to the consensus th= at was reached at the Interim.  =3B =3B

 =3B

From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Be= half Of Wojciech Dec (wdec)
Sent: Friday=2C November 20=2C 2009 2:03 AM
To: Bernard Aboba
Cc: Romascanu=2C Dan (Dan)=3B radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interim Minutes

 =3B

Trying for the 4th time now:

 =3B

- could you confirm that =3Bwh= at =3Bmy mail =3Boutlined in terms of moving forward =3Bis also your expectation? =3B

- Are you now convinced of "intere= st"? (and if not=2C or partially=2C then on what grounds?)

- could you point out (summarise)t= he issues =3Bthat were not addressed?

 =3B

Thanks=2C

Woj.

 =3B

= --_8124f040-dcd6-4c3f-b4d0-5f0702e1dbb1_-- -- to unsubscribe send a 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, 23 Nov 2009 21:54:45 +0000 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Mon, 23 Nov 2009 22:54:14 +0100 Message-ID: Thread-Topic: Consensus Call on Broadband Forum Next Steps Thread-Index: Acprk4W/5rWkelX5TXiQ/WKQDdQRrgAndh+QAAE2d4AAAgpkUAARy/BA From: "Wojciech Dec (wdec)" To: "Dave Nelson" , "Romascanu, Dan (Dan)" , "Bernard Aboba" , "Alan DeKok" Cc: =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Dave Nelson > Sent: 23 November 2009 14:21 > To: Wojciech Dec (wdec); 'Romascanu, Dan (Dan)'; 'Bernard=20 > Aboba'; 'Alan DeKok' > Cc: radiusext@ops.ietf.org > Subject: RE: Consensus Call on Broadband Forum Next Steps >=20 > > What are/were these issues? >=20 > Issues are listed in the RADEXT Issues Tracker, located at: >=20 > http://www.drizzle.com/~aboba/RADEXT/ >=20 > The issues on your draft are 317, 321, 322. Thanks, odd that it took so many attempts at getting this answer. That = said, 321 applied (applies?) to = draft-sarikaya-radext-prefix-authorization, which was not part of = http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00. 317 applies to draft-lourdelet-radext-ipv6-access-01 and has been noted = and discussed. On the other hand 322 is quite clearly applicable to any of the drafts = including what appears to have been finally understood at the = illuminative virtual gathering. Does it still apply? Ie is there still a = need to detail the "service aspect" 322 is asking for? Oddly, if one = looks at other Radius draft there isn't quite much more than what's in = our draft today. >=20 > In addition, there are discussions that are logged in the=20 > RADEXT WG mailing list archives. >=20 > > As such=A0we are still expecting a response to the questions posed,=20 > > while tentatively planning to re-present a souped up version of the=20 > > earlier draft(s). >=20 > The only question that I'm aware of is your question of=20 > October 23, that is to say, "If we address the attribute=20 > design issues can this draft move forward"? Uhm... Perhaps reading the follow may help? #1 https://ops.ietf.org/lists/radiusext/2009/msg00552.html #2 https://ops.ietf.org/lists/radiusext/2009/msg00558.html #3 https://ops.ietf.org/lists/radiusext/2009/msg00562.html #4 https://ops.ietf.org/lists/radiusext/2009/msg00635.html >=20 > That's not the way the WG works. There are no shortcuts to=20 > addressing commentary and posting revised drafts. Your=20 > current draft is at -01, so it's not like there has been a=20 > *lot* of revision activity. The best way forward is to=20 I'm sorry, the draft history is presented at = https://ops.ietf.org/lists/radiusext/2009/msg00558.html It would now be 04/05 if not for all the direction/name changes as asked = for by the chairs of this WG (!!) -Woj. > propose *specific* text revisions to address outstanding=20 > comments. You can do that either by submitting a revised=20 > draft, or by submitting sections of OLD and NEW text to the=20 > mailing list to show the WG what changes you propose to make=20 > in the next draft revision. In many ways, that's actually preferable. >=20 >=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: Mon, 23 Nov 2009 21:37:18 +0000 Authentication-Results: sj-iport-4.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_01CA6C84.FDAEFAA6" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Mon, 23 Nov 2009 22:36:18 +0100 Message-ID: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: Acprjd9VBMqcnZtIQFWbEkSBR8TIgQAnYNrwAARs21AAADS5MAAQZErAAACw+PA= From: "Wojciech Dec (wdec)" To: "MILES DAVID" , "Romascanu, Dan (Dan)" , "Bernard Aboba" Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6C84.FDAEFAA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, =20 thanks for the support, which is one that effectively amounts to backing the two draft approach (https://ops.ietf.org/lists/radiusext/2009/msg00552.html ). I will take you up on contributing the descriptive text to complete an updated version of http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00, unless you have radically alternative suggestions in mind for the DNS, address and route options. =20 Cheers, Woj. ________________________________ From: MILES DAVID [mailto:David.Miles@alcatel-lucent.com]=20 Sent: 23 November 2009 22:00 To: Wojciech Dec (wdec); Romascanu, Dan (Dan); Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 In the interest of moving forward, I would like to take the crack at this... I noted none of the current authors want to take this work on - I do and I will. I'll produce a new draft and author it ... if any of the current authors want to be on the draft please let me know - i do not get anything for having my name on a draft=20 =20 I truly understand Woj's frustration here but I am here for short term kicks - I really need to get this gap sorted out and I hope those that feel stepped on by my course of action can appreciate that you sometimes need to make sacrifices to get the outcome you need (which here is clearly some new RADIUS AVP types). I promise to be designated beer-guy at all future IETF's for those authors feeling hard done by :)=20 =20 -d =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Monday, 23 November 2009 11:43 PM To: Romascanu, Dan (Dan); Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 As highlighted, we (the authors and David) intend progressing on this approach and have discussed it at the last meeting. However we are similarly in agreement as to expecting an answer as to what "issues" do say draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00 have, if not http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-01 (data type aside). As far as we're concerned addressing previously raised issues is precisely what led to the situation of today.=20 =20 =20 -Woj. =20 =09 ________________________________ From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: 23 November 2009 14:05 To: Wojciech Dec (wdec); Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes I suggest to everybody to cool down a little and try to work in a constructive manner from where we are right now. Communication seems key in such situations - It looks to me for example that if at least one of the authors of draft-lourdelet-radext-ipv6-access could have attended the meeting many of the hurdles of the current situation would not have existed. Can the document editors and David work together towards issuing a revised I-D to be submitted as a basis for consensus?=20 =20 Dan =20 =20 =09 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: Monday, November 23, 2009 2:54 PM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes Bernard, =20 as explained in http://www.ops.ietf.org/lists/radiusext/2009/msg00558.html the draft has been repeatedly presented, modified based on WG feedback and re-presented (or attempted to). The fact that now there seems to be some opinion, consisting effectively of adding descriptive text and an author, etc, does not address the basic question of what were the issues with the previous draft that have not yet been addressed? In other words and perhaps fundamentally, before issuing a consensus call we all would like to know what are the issues with the originally proposed draft? =20 Draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access -00, which had no data-type/tagging controversy and which was presented at IETF74 was claimed to have issues (that actually resulted in 01). This -00 draft now however appears to bear all the hallmarks of what's been claimed as the "virtual meeting" consented way forward, give or take additional descriptive text. Have the issues have disappeared? Persistently, it has also been claimed that there was no interest in the draft. Is there now interest? My simple 3 questions were aimed at clarifying all this, but despite asking numerous times received no clear reply other than some stonewalling (eg check the minutes), or a "consensus call" message which was very odd for a non WG draft to say the least. The implied messaging of changing draft authorship was also highly inconsiderate. =20 Now the above is just one of the many bizarre twists in the story of this draft and its "progress" in Radex. I could go on and on, including pointing out chair-101 items like that; enquiries regarding virtual meeting went un-answered; that meeting conclusions have no IETF binding status; that there is no obligation to attend meetings (esp ones scheduled in a diff time zone); and that having a discussion on draft *without* any of the draft authors present is highly unusual if not down right wrong. =20 The bottom line as I see it is that instead of facilitating WG progress, the activity of the WG chairs has and continues to hinder such progress (eg by refusing to even summarize what are any outstanding issues), as well as evidencing some rather dubious chairing practices.=20 Generalizing from this experience, I can say that the authors of the draft have the distinct impression that any extensions to Radius are actually less than welcome by the chairs of the Radext WG. =20 regards, Woj. =20 =20 =20 =09 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: 22 November 2009 17:07 To: Wojciech Dec (wdec) Cc: dromasca@avaya.com; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes Woj -- =09 The meetings of the RADEXT WG are openly publicized and are available to anyone (including people who are not physically present). Presentations and agenda items are openly solicited. If you would like time on the agenda of a physical or virtual meeting, all you need to do is to post a message to the WG list and your request will be honored. =20 =09 In your initial message (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you requested guidance as to whether it would be better for the work on IPv6 access to proceed with a draft focusing on an initial set of attributes along the lines of the original submission (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00), or whether a combined submission would be preferable, along the lines of the -01 submission.=20 =09 That is exactly the issue that is now under consideration within the Consensus Call that has been issued. As noted in the virtual interim minutes, David Miles has suggested that the focused approach would be more likely to result in rapid progress, and other participants at the Virtual Interim agreed with this suggestion.=20 =09 Since the IETF operates on "rough consensus", it is the duty of the Chairs to engage the WG participants on issues such as these, rather than making unilateral decisions.=20 =09 ________________________________ Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun, 22 Nov 2009 11:57:04 +0100 From: wdec@cisco.com To: bernard_aboba@hotmail.com CC: dromasca@avaya.com; radiusext@ops.ietf.org Bernard, =20 this thread directly stems from the minutes of the meeting. On behalf of the draft authors I proposed a way forward and in relation to this I have asked you (as chair) repeatedly for some answers/clarifications. Now, given that at the n'th attempt you are still unable to answer them clearly is telling me and other folks that you're quite simply unwilling or unable to carry out your duties as chair of this WG.=20 =20 Thanks, Woj. =20 =09 ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 21 November 2009 02:59 To: Wojciech Dec (wdec) Cc: 'Romascanu, Dan (Dan)'; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes At the Virtual Interim, the RADEXT WG held a session devoted to next steps on the IPv6 access work. During the session, David Miles suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. =20 =20 In order to confirm that consensus, the RADEXT WG has issued a Consensus Call to the mailing list (see http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please feel free to express your opinions on the list relating to the consensus that was reached at the Interim. =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Friday, November 20, 2009 2:03 AM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 Trying for the 4th time now: =20 - 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?) - could you point out (summarise)the issues that were not addressed? =20 Thanks, Woj. =20 ------_=_NextPart_001_01CA6C84.FDAEFAA6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
David,
 
thanks for the support, which is one that effectively = amounts=20 to backing the two draft approach (https://= ops.ietf.org/lists/radiusext/2009/msg00552.html ).=20 I will take you up on contributing the descriptive text to complete an = updated=20 version of http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00,=20 unless you have radically alternative suggestions in mind for the DNS, = address=20 and route options.
 
Cheers,
Woj.
From: MILES DAVID=20 [mailto:David.Miles@alcatel-lucent.com]
Sent: 23 November = 2009=20 22:00
To: Wojciech Dec (wdec); Romascanu, Dan (Dan); Bernard = Aboba
Cc: radiusext@ops.ietf.org
Subject: RE: = Draft RADEXT=20 Virtual Interim Minutes

In=20 the interest of moving forward, I would like to take the crack at = this... I=20 noted none of the current authors want to take this work on – I = do and I will.=20 I’ll produce a new draft and author it ... if any of the current = authors want=20 to be on the draft please let me know – i do not get anything = for having my=20 name on a draft

 

I=20 truly understand Woj’s frustration here but I am here for short = term kicks – I=20 really need to get this gap sorted out and I hope those that feel = stepped on=20 by my course of action can appreciate that you sometimes need to make=20 sacrifices to get the outcome you need (which here is clearly some new = RADIUS=20 AVP types). I promise to be designated beer-guy at all future = IETF’s for those=20 authors feeling hard done by :)

 

-d

 

 

From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On=20 Behalf Of Wojciech Dec (wdec)
Sent: Monday, 23 November = 2009=20 11:43 PM
To: Romascanu, Dan (Dan); Bernard = Aboba
Cc:=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

 

As = highlighted, we=20 (the authors and David) intend progressing on this approach and have = discussed=20 it at the last meeting. However we are similarly in agreement as to = expecting=20 an answer as to what "issues" do say draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00&nbs= p;have,=20 if not http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-01=20 (data type aside). As far as we're concerned addressing previously = raised=20 issues is precisely what led to the situation of today. =

 

 

-Woj.

 

From:=20 Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: 23 = November 2009 14:05
To: Wojciech Dec (wdec); Bernard=20 Aboba
Cc: radiusext@ops.ietf.org
Subject: RE: = Draft=20 RADEXT Virtual Interim Minutes

I=20 suggest to everybody to cool down a little and try to work in a = constructive=20 manner from where we are right now. Communication seems key in such=20 situations - It looks to me for example that if at least one of the = authors=20 of draft-lourdelet-radext-ipv6-access=20 could=20 have attended the meeting many of the hurdles of the current = situation would=20 not have existed. Can the document editors and David work together = towards=20 issuing a revised I-D to be submitted as a basis for consensus? =

 

Dan

 

 

From:=20 Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: = Monday,=20 November 23, 2009 2:54 PM
To: Bernard = Aboba
Cc:=20 Romascanu, Dan (Dan); radiusext@ops.ietf.org
Subject: = RE: Draft=20 RADEXT Virtual Interim Minutes

Bernard,

 

as = explained in=20 http:= //www.ops.ietf.org/lists/radiusext/2009/msg00558.html the=20 draft has been repeatedly presented, modified based on = WG feedback=20 and re-presented (or attempted to).

The = fact that=20 now there seems to be some opinion, consisting effectively of = adding=20 descriptive text and an author, etc, does not = address the=20 basic question of what were the issues with the previous = draft that=20 have not yet been addressed? In other words and perhaps=20 fundamentally, before issuing a consensus call we all = would like=20 to know what are the issues with the originally proposed=20 draft?

 

Draft = http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00,=20 which had no data-type/tagging controversy and which was=20 presented at IETF74 was claimed to have issues (that actually = resulted in 01). This -00 draft now however appears to bear = all the=20 hallmarks of what's been claimed as the "virtual meeting"=20 consented way forward, give or take additional descriptive = text. Have=20 the issues have disappeared? Persistently, it has also = been=20 claimed that there was no interest in the draft. Is there now=20 interest?

My = simple 3=20 questions were aimed at clarifying all this, but despite asking = numerous=20 times received no clear reply other than some = stonewalling (eg check=20 the minutes), or a "consensus call" message which was=20 very odd for a non WG draft to say the least. = The=20 implied messaging of changing draft authorship was also highly=20 inconsiderate.

 

Now = the=20 above is just one of the many bizarre twists in the = story of=20 this draft and its "progress" in Radex. I could go on and on, = including pointing out chair-101 items like that; enquiries = regarding=20 virtual meeting went un-answered; that meeting=20 conclusions have no IETF  binding status; that there is = no=20 obligation to attend meetings (esp ones scheduled in a diff time = zone);=20 and that having a discussion on draft *without* any of the = draft=20 authors present is highly unusual if not down right = wrong.

 

The bottom=20 line as I see it is that instead of facilitating WG progress, = the=20 activity of the WG chairs has and continues to hinder = such=20 progress (eg by refusing to even summarize what are any=20 outstanding issues), as well as evidencing some rather=20 dubious chairing practices.

Generalizing=20 from this experience, I can say that the authors of the = draft have=20 the distinct impression that any extensions to Radius are actually = less=20 than welcome by the chairs of the Radext WG.

 

regards,

Woj.

 

 

 

From:=20 owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org] On=20 Behalf Of Bernard Aboba
Sent: 22 November 2009=20 17:07
To: Wojciech Dec (wdec)
Cc:=20 dromasca@avaya.com; radiusext@ops.ietf.org
Subject: = RE: Draft=20 RADEXT Virtual Interim Minutes

Woj=20 --

The meetings of the RADEXT WG are openly publicized = and are=20 available to anyone (including people who are not physically=20 present).  Presentations and agenda items are openly=20 solicited.  If you would like time on the agenda of a = physical or=20 virtual meeting, all you need to do is to post a message to the = WG list=20 and your request will be honored. 

In your initial = message=20 (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you = requested guidance as to whether it would be better for the work = on IPv6=20 access to proceed with a draft focusing on an initial set of = attributes=20 along the lines of the original submission=20 = (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00), or=20 whether a combined submission would be preferable, along the = lines of=20 the -01 submission.

That is exactly the issue that is = now under=20 consideration within the Consensus Call that has been = issued.  As=20 noted in the virtual interim minutes, David Miles has suggested = that the=20 focused approach would be more likely to result in rapid = progress, and=20 other participants at the Virtual Interim agreed with this = suggestion.=20

Since the IETF operates on "rough consensus", it is the = duty of=20 the Chairs to engage the WG participants on issues such as = these, rather=20 than making unilateral decisions.

Subject:=20 RE: Draft RADEXT Virtual Interim Minutes
Date: Sun, 22 Nov = 2009=20 11:57:04 +0100
From: wdec@cisco.com
To:=20 bernard_aboba@hotmail.com
CC: dromasca@avaya.com;=20 radiusext@ops.ietf.org

Bernard,

 

this thread=20 directly stems from the minutes of the meeting. On behalf = of the=20 draft authors I proposed a way forward and = in relation to=20 this I have asked you (as chair) repeatedly for = some=20 answers/clarifications. Now, given that at the n'th = attempt you are=20 still unable to answer them clearly is telling me and other = folks=20 that you're quite simply unwilling or unable to = carry out=20 your duties as chair of this WG.

 

Thanks,

Woj.

 

From: = Bernard=20 Aboba [mailto:bernard_aboba@hotmail.com]
Sent: 21 = November=20 2009 02:59
To: Wojciech Dec (wdec)
Cc: = 'Romascanu,=20 Dan (Dan)'; radiusext@ops.ietf.org
Subject: RE: = Draft RADEXT=20 Virtual Interim Minutes

At=20 the Virtual Interim, the RADEXT WG held a session devoted to = next=20 steps on the IPv6 access work.  During the session, David = Miles=20 suggested a path forward for the IPv6 Access work that = appeared to=20 have consensus among the Virtual Interim attendees.  =

 

In=20 order to confirm that consensus, the RADEXT WG has issued a = Consensus=20 Call to the mailing list (see  =20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html).  =  Please feel free to express your opinions on the list = relating=20 to the consensus that was reached at the Interim.=20   

 

From: = owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org]=20 On Behalf Of Wojciech Dec (wdec)
Sent: = Friday,=20 November 20, 2009 2:03 AM
To: Bernard = Aboba
Cc:=20 Romascanu, Dan (Dan); = radiusext@ops.ietf.org
Subject: RE:=20 Draft RADEXT Virtual Interim Minutes

 

Trying=20 for the 4th time now:

 

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

-=20 Are you now convinced of "interest"? (and if not, or = partially, then=20 on what grounds?)

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

 

Thanks,

Woj.

 

------_=_NextPart_001_01CA6C84.FDAEFAA6-- -- to unsubscribe send a 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, 23 Nov 2009 13:21:43 +0000 From: "Dave Nelson" To: "'Wojciech Dec \(wdec\)'" , "'Romascanu, Dan \(Dan\)'" , "'Bernard Aboba'" , "'Alan DeKok'" Cc: Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Mon, 23 Nov 2009 08:21:26 -0500 Message-ID: <8CF160205F4440688CD6BE2812A8DEFD@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Index: Acprk4W/5rWkelX5TXiQ/WKQDdQRrgAndh+QAAE2d4AAAgpkUA== > What are/were these issues? Issues are listed in the RADEXT Issues Tracker, located at: http://www.drizzle.com/~aboba/RADEXT/ The issues on your draft are 317, 321, 322. In addition, there are discussions that are logged in the RADEXT WG = mailing list archives. > As such=A0we are still expecting a response to the questions posed, > while tentatively planning to re-present a souped up version of > the earlier draft(s). The only question that I'm aware of is your question of October 23, that = is to say, "If we address the attribute design issues can this draft move forward"? That's not the way the WG works. There are no shortcuts to addressing commentary and posting revised drafts. Your current draft is at -01, so it's not like there has been a *lot* of revision activity. The best way forward is to propose *specific* text revisions to address outstanding comments. You can do that either by submitting a revised draft, or by submitting sections of OLD and NEW text to the mailing list to show the = WG what changes you propose to make in the next draft revision. In many = ways, that's actually preferable. -- to unsubscribe send a 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, 23 Nov 2009 13:13:09 +0000 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_01CA6C3E.A6A3194A" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Mon, 23 Nov 2009 14:12:44 +0100 Message-ID: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: Acprjd9VBMqcnZtIQFWbEkSBR8TIgQAnYNrwAARs21AAADS5MA== From: "Wojciech Dec (wdec)" To: "Romascanu, Dan (Dan)" , "Bernard Aboba" Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6C3E.A6A3194A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As highlighted, we (the authors and David) intend progressing on this approach and have discussed it at the last meeting. However we are similarly in agreement as to expecting an answer as to what "issues" do say draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00 have, if not http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-01 (data type aside). As far as we're concerned addressing previously raised issues is precisely what led to the situation of today.=20 =20 =20 -Woj. ________________________________ From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: 23 November 2009 14:05 To: Wojciech Dec (wdec); Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 I suggest to everybody to cool down a little and try to work in a constructive manner from where we are right now. Communication seems key in such situations - It looks to me for example that if at least one of the authors of draft-lourdelet-radext-ipv6-access could have attended the meeting many of the hurdles of the current situation would not have existed. Can the document editors and David work together towards issuing a revised I-D to be submitted as a basis for consensus?=20 =20 Dan =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: Monday, November 23, 2009 2:54 PM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 Bernard, =20 as explained in http://www.ops.ietf.org/lists/radiusext/2009/msg00558.html the draft has been repeatedly presented, modified based on WG feedback and re-presented (or attempted to). The fact that now there seems to be some opinion, consisting effectively of adding descriptive text and an author, etc, does not address the basic question of what were the issues with the previous draft that have not yet been addressed? In other words and perhaps fundamentally, before issuing a consensus call we all would like to know what are the issues with the originally proposed draft? =20 Draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access -00, which had no data-type/tagging controversy and which was presented at IETF74 was claimed to have issues (that actually resulted in 01). This -00 draft now however appears to bear all the hallmarks of what's been claimed as the "virtual meeting" consented way forward, give or take additional descriptive text. Have the issues have disappeared? Persistently, it has also been claimed that there was no interest in the draft. Is there now interest? My simple 3 questions were aimed at clarifying all this, but despite asking numerous times received no clear reply other than some stonewalling (eg check the minutes), or a "consensus call" message which was very odd for a non WG draft to say the least. The implied messaging of changing draft authorship was also highly inconsiderate. =20 Now the above is just one of the many bizarre twists in the story of this draft and its "progress" in Radex. I could go on and on, including pointing out chair-101 items like that; enquiries regarding virtual meeting went un-answered; that meeting conclusions have no IETF binding status; that there is no obligation to attend meetings (esp ones scheduled in a diff time zone); and that having a discussion on draft *without* any of the draft authors present is highly unusual if not down right wrong. =20 The bottom line as I see it is that instead of facilitating WG progress, the activity of the WG chairs has and continues to hinder such progress (eg by refusing to even summarize what are any outstanding issues), as well as evidencing some rather dubious chairing practices.=20 Generalizing from this experience, I can say that the authors of the draft have the distinct impression that any extensions to Radius are actually less than welcome by the chairs of the Radext WG. =20 regards, Woj. =20 =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: 22 November 2009 17:07 To: Wojciech Dec (wdec) Cc: dromasca@avaya.com; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 Woj -- =09 The meetings of the RADEXT WG are openly publicized and are available to anyone (including people who are not physically present). Presentations and agenda items are openly solicited. If you would like time on the agenda of a physical or virtual meeting, all you need to do is to post a message to the WG list and your request will be honored. =20 =09 In your initial message (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you requested guidance as to whether it would be better for the work on IPv6 access to proceed with a draft focusing on an initial set of attributes along the lines of the original submission (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00), or whether a combined submission would be preferable, along the lines of the -01 submission.=20 =09 That is exactly the issue that is now under consideration within the Consensus Call that has been issued. As noted in the virtual interim minutes, David Miles has suggested that the focused approach would be more likely to result in rapid progress, and other participants at the Virtual Interim agreed with this suggestion.=20 =09 Since the IETF operates on "rough consensus", it is the duty of the Chairs to engage the WG participants on issues such as these, rather than making unilateral decisions.=20 =09 =09 ________________________________ Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun, 22 Nov 2009 11:57:04 +0100 From: wdec@cisco.com To: bernard_aboba@hotmail.com CC: dromasca@avaya.com; radiusext@ops.ietf.org =09 =09 Bernard, =20 this thread directly stems from the minutes of the meeting. On behalf of the draft authors I proposed a way forward and in relation to this I have asked you (as chair) repeatedly for some answers/clarifications. Now, given that at the n'th attempt you are still unable to answer them clearly is telling me and other folks that you're quite simply unwilling or unable to carry out your duties as chair of this WG.=20 =20 Thanks, Woj. ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 21 November 2009 02:59 To: Wojciech Dec (wdec) Cc: 'Romascanu, Dan (Dan)'; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 At the Virtual Interim, the RADEXT WG held a session devoted to next steps on the IPv6 access work. During the session, David Miles suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. =20 =20 In order to confirm that consensus, the RADEXT WG has issued a Consensus Call to the mailing list (see http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please feel free to express your opinions on the list relating to the consensus that was reached at the Interim. =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Friday, November 20, 2009 2:03 AM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 Trying for the 4th time now: =20 - 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?) - could you point out (summarise)the issues that were not addressed? =20 Thanks, Woj. =20 ------_=_NextPart_001_01CA6C3E.A6A3194A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As=20 highlighted, we (the authors and David) intend progressing on this = approach and=20 have discussed it at the last meeting. However we are similarly in = agreement as=20 to expecting an answer as to what "issues" do say draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-00<= /A> have,=20 if not http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access-01<= /A>=20 (data type aside). As far as we're concerned addressing previously = raised issues=20 is precisely what led to the situation of today.=20
 
 
-Woj.

From: Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: 23 November 2009=20 14:05
To: Wojciech Dec (wdec); Bernard Aboba
Cc:=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

I suggest=20 to everybody to cool down a little and try to work in a constructive = manner=20 from where we are right now. Communication seems key in such = situations - It=20 looks to me for example that if at least one of the authors of=20 draft-lourdelet-radext-ipv6-access could have attended the meeting many of the hurdles of = the=20 current situation would not have existed. Can the document editors and = David=20 work together towards issuing a revised I-D to be submitted as a basis = for=20 consensus?
 
Dan
 

From: Wojciech Dec (wdec) = [mailto:wdec@cisco.com]=20
Sent: Monday, November 23, 2009 2:54 PM
To: = Bernard=20 Aboba
Cc: Romascanu, Dan (Dan);=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

Bernard,
 
as=20 explained in http:= //www.ops.ietf.org/lists/radiusext/2009/msg00558.html the=20 draft has been repeatedly presented, modified based on = WG feedback and=20 re-presented (or attempted to).
The=20 fact that now there seems to be some opinion, consisting = effectively of=20 adding descriptive text and an author, etc, does not = address=20 the basic question of what were the issues with the previous = draft that=20 have not yet been addressed? In other words and perhaps = fundamentally, before issuing=20 a consensus call we all would like to know what are the issues = with the=20 originally proposed draft?
 
Draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access= -00,=20 which had no data-type/tagging controversy and which was=20 presented at IETF74 was claimed to have issues (that actually = resulted=20 in 01). This -00 draft now however appears to bear all the = hallmarks of=20 what's been claimed as the "virtual meeting" consented way = forward,=20 give or take additional descriptive text. Have the issues have=20 disappeared? Persistently, it=20 has also been claimed that there was no interest in the draft. = Is there=20 now interest?
My=20 simple 3 questions were aimed at clarifying all this, but despite = asking=20 numerous times received no clear reply other than some = stonewalling (eg=20 check the minutes), or a "consensus call" message which = was=20 very odd for a non WG draft to say the least. = The=20 implied messaging of changing draft authorship was also highly=20 inconsiderate.
 
Now=20 the above is just one of the many bizarre twists in the = story of=20 this draft and its "progress" in Radex. I could go on and on, = including=20 pointing out chair-101 items like that; enquiries regarding virtual=20 meeting went un-answered; that meeting = conclusions have no=20 IETF  binding status; that there is no obligation to attend = meetings=20 (esp ones scheduled in a diff time zone); and that having a = discussion on=20 draft *without* any of the draft authors present is highly = unusual if=20 not down right wrong.
 
The bottom line as I see it is = that=20 instead of facilitating WG progress, the activity of the = WG chairs=20 has and continues to hinder such progress (eg by refusing to = even=20 summarize what are any outstanding issues), as well as=20 evidencing some rather dubious chairing practices.=20
Generalizing from this experience, I can = say that=20 the authors of the draft have the distinct impression that any=20 extensions to Radius are actually less than welcome by the = chairs of=20 the Radext WG.
 
regards,
Woj.
 
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: 22 November 2009 17:07
To: = Wojciech Dec=20 (wdec)
Cc: dromasca@avaya.com;=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

Woj --

The meetings of the RADEXT WG are openly=20 publicized and are available to anyone (including people who are = not=20 physically present).  Presentations and agenda items are = openly=20 solicited.  If you would like time on the agenda of a = physical or=20 virtual meeting, all you need to do is to post a message to the WG = list=20 and your request will be honored. 

In your initial = message=20 (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you = requested=20 guidance as to whether it would be better for the work on IPv6 = access to=20 proceed with a draft focusing on an initial set of attributes = along the=20 lines of the original submission=20 (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00), = or=20 whether a combined submission would be preferable, along the lines = of the=20 -01 submission.

That is exactly the issue that is now = under=20 consideration within the Consensus Call that has been = issued.  As=20 noted in the virtual interim minutes, David Miles has suggested = that the=20 focused approach would be more likely to result in rapid progress, = and=20 other participants at the Virtual Interim agreed with this = suggestion.=20

Since the IETF operates on "rough consensus", it is the = duty of=20 the Chairs to engage the WG participants on issues such as these, = rather=20 than making unilateral decisions.

Subject: RE: Draft RADEXT Virtual Interim Minutes
Date: Sun, 22 = Nov=20 2009 11:57:04 +0100
From: wdec@cisco.com
To:=20 bernard_aboba@hotmail.com
CC: dromasca@avaya.com;=20 radiusext@ops.ietf.org

Bernard,
 
this thread directly stems from the minutes of the=20 meeting. On behalf of the draft authors = I proposed a way=20 forward and in relation to this I have asked you = (as=20 chair) repeatedly for some answers/clarifications. Now, given = that at=20 the n'th attempt you are still unable to answer them = clearly is=20 telling me and other folks that you're quite simply = unwilling or=20 unable to carry out your duties as chair of this WG.=20
 
Thanks,
Woj.

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: 21 November = 2009=20 02:59
To: Wojciech Dec (wdec)
Cc: = 'Romascanu, Dan=20 (Dan)'; radiusext@ops.ietf.org
Subject: RE: Draft = RADEXT=20 Virtual Interim Minutes

At=20 the Virtual Interim, the RADEXT WG held a session devoted to = next steps=20 on the IPv6 access work.  During the session, David Miles = suggested=20 a path forward for the IPv6 Access work that appeared to have = consensus=20 among the Virtual Interim attendees. 

 

In=20 order to confirm that consensus, the RADEXT WG has issued a = Consensus=20 Call to the mailing list (see  =20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html). =20  Please feel free to express your opinions on the list = relating to=20 the consensus that was reached at the Interim. =   

 

From:=20 owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org] On=20 Behalf Of Wojciech Dec (wdec)
Sent: Friday, = November 20,=20 2009 2:03 AM
To: Bernard Aboba
Cc: = Romascanu, Dan=20 (Dan); radiusext@ops.ietf.org
Subject: RE: Draft = RADEXT=20 Virtual Interim Minutes

 

Trying=20 for the 4th time now:

 

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

- Are = you now=20 convinced of "interest"? (and if not, or partially, then on what = grounds?)

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

 

Thanks,

Woj.

 

<= /HTML> ------_=_NextPart_001_01CA6C3E.A6A3194A-- -- to unsubscribe send a 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, 23 Nov 2009 13:06:07 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6C3D.9AFACEE7" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Mon, 23 Nov 2009 14:05:17 +0100 Message-ID: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: Acprjd9VBMqcnZtIQFWbEkSBR8TIgQAnYNrwAARs21A= From: "Romascanu, Dan (Dan)" To: "Wojciech Dec (wdec)" , "Bernard Aboba" Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6C3D.9AFACEE7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I suggest to everybody to cool down a little and try to work in a constructive manner from where we are right now. Communication seems key in such situations - It looks to me for example that if at least one of the authors of draft-lourdelet-radext-ipv6-access could have attended the meeting many of the hurdles of the current situation would not have existed. Can the document editors and David work together towards issuing a revised I-D to be submitted as a basis for consensus?=20 =20 Dan =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: Monday, November 23, 2009 2:54 PM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 Bernard, =20 as explained in http://www.ops.ietf.org/lists/radiusext/2009/msg00558.html the draft has been repeatedly presented, modified based on WG feedback and re-presented (or attempted to). The fact that now there seems to be some opinion, consisting effectively of adding descriptive text and an author, etc, does not address the basic question of what were the issues with the previous draft that have not yet been addressed? In other words and perhaps fundamentally, before issuing a consensus call we all would like to know what are the issues with the originally proposed draft? =20 Draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access -00, which had no data-type/tagging controversy and which was presented at IETF74 was claimed to have issues (that actually resulted in 01). This -00 draft now however appears to bear all the hallmarks of what's been claimed as the "virtual meeting" consented way forward, give or take additional descriptive text. Have the issues have disappeared? Persistently, it has also been claimed that there was no interest in the draft. Is there now interest? My simple 3 questions were aimed at clarifying all this, but despite asking numerous times received no clear reply other than some stonewalling (eg check the minutes), or a "consensus call" message which was very odd for a non WG draft to say the least. The implied messaging of changing draft authorship was also highly inconsiderate. =20 Now the above is just one of the many bizarre twists in the story of this draft and its "progress" in Radex. I could go on and on, including pointing out chair-101 items like that; enquiries regarding virtual meeting went un-answered; that meeting conclusions have no IETF binding status; that there is no obligation to attend meetings (esp ones scheduled in a diff time zone); and that having a discussion on draft *without* any of the draft authors present is highly unusual if not down right wrong. =20 The bottom line as I see it is that instead of facilitating WG progress, the activity of the WG chairs has and continues to hinder such progress (eg by refusing to even summarize what are any outstanding issues), as well as evidencing some rather dubious chairing practices.=20 Generalizing from this experience, I can say that the authors of the draft have the distinct impression that any extensions to Radius are actually less than welcome by the chairs of the Radext WG. =20 regards, Woj. =20 =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: 22 November 2009 17:07 To: Wojciech Dec (wdec) Cc: dromasca@avaya.com; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 Woj -- =09 The meetings of the RADEXT WG are openly publicized and are available to anyone (including people who are not physically present). Presentations and agenda items are openly solicited. If you would like time on the agenda of a physical or virtual meeting, all you need to do is to post a message to the WG list and your request will be honored. =20 =09 In your initial message (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you requested guidance as to whether it would be better for the work on IPv6 access to proceed with a draft focusing on an initial set of attributes along the lines of the original submission (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00), or whether a combined submission would be preferable, along the lines of the -01 submission.=20 =09 That is exactly the issue that is now under consideration within the Consensus Call that has been issued. As noted in the virtual interim minutes, David Miles has suggested that the focused approach would be more likely to result in rapid progress, and other participants at the Virtual Interim agreed with this suggestion.=20 =09 Since the IETF operates on "rough consensus", it is the duty of the Chairs to engage the WG participants on issues such as these, rather than making unilateral decisions.=20 =09 =09 ________________________________ Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun, 22 Nov 2009 11:57:04 +0100 From: wdec@cisco.com To: bernard_aboba@hotmail.com CC: dromasca@avaya.com; radiusext@ops.ietf.org =09 =09 Bernard, =20 this thread directly stems from the minutes of the meeting. On behalf of the draft authors I proposed a way forward and in relation to this I have asked you (as chair) repeatedly for some answers/clarifications. Now, given that at the n'th attempt you are still unable to answer them clearly is telling me and other folks that you're quite simply unwilling or unable to carry out your duties as chair of this WG.=20 =20 Thanks, Woj. ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 21 November 2009 02:59 To: Wojciech Dec (wdec) Cc: 'Romascanu, Dan (Dan)'; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 At the Virtual Interim, the RADEXT WG held a session devoted to next steps on the IPv6 access work. During the session, David Miles suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. =20 =20 In order to confirm that consensus, the RADEXT WG has issued a Consensus Call to the mailing list (see http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please feel free to express your opinions on the list relating to the consensus that was reached at the Interim. =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Friday, November 20, 2009 2:03 AM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 Trying for the 4th time now: =20 - 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?) - could you point out (summarise)the issues that were not addressed? =20 Thanks, Woj. =20 ------_=_NextPart_001_01CA6C3D.9AFACEE7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I suggest to=20 everybody to cool down a little and try to work in a constructive manner = from=20 where we are right now. Communication seems key in such situations - It = looks to=20 me for example that if at least one of the authors of=20 draft-lourdelet-radext-ipv6-access could have attended the meeting many of the hurdles of = the current=20 situation would not have existed. Can the document editors and David = work=20 together towards issuing a revised I-D to be submitted as a basis for = consensus?=20
 
Dan
 

From: Wojciech Dec (wdec) = [mailto:wdec@cisco.com]=20
Sent: Monday, November 23, 2009 2:54 PM
To: = Bernard=20 Aboba
Cc: Romascanu, Dan (Dan);=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

Bernard,
 
as=20 explained in http:= //www.ops.ietf.org/lists/radiusext/2009/msg00558.html the=20 draft has been repeatedly presented, modified based on = WG feedback and=20 re-presented (or attempted to).
The=20 fact that now there seems to be some opinion, consisting = effectively of=20 adding descriptive text and an author, etc, does not = address=20 the basic question of what were the issues with the previous = draft that=20 have not yet been addressed? In other words and perhaps = fundamentally, before issuing a=20 consensus call we all would like to know what are the issues with = the=20 originally proposed draft?
 
Draft=20 http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access= -00,=20 which had no data-type/tagging controversy and which was=20 presented at IETF74 was claimed to have issues (that actually = resulted in=20 01). This -00 draft now however appears to bear all the hallmarks = of=20 what's been claimed as the "virtual meeting" consented way = forward, give=20 or take additional descriptive text. Have the issues have = disappeared?=20 Persistently, it has also been claimed = that there=20 was no interest in the draft. Is there now=20 interest?
My simple 3 = questions=20 were aimed at clarifying all this, but despite asking numerous times = received=20 no clear reply other than some stonewalling (eg check the = minutes),=20 or a "consensus call" message which was very odd = for a=20 non WG draft to say the least. The implied messaging of = changing=20 draft authorship was also highly=20 inconsiderate.
 
Now the = above is=20 just one of the many bizarre twists in the story of this = draft and=20 its "progress" in Radex. I could go on and on, including pointing out=20 chair-101 items like that; enquiries regarding virtual = meeting went=20 un-answered; that meeting conclusions have no IETF  = binding=20 status; that there is no obligation to attend meetings (esp ones = scheduled in=20 a diff time zone); and that having a discussion on = draft *without* any of=20 the draft authors present is highly unusual if not down right=20 wrong.
 
The bottom line as=20 I see it is that instead of facilitating WG progress, the = activity of the=20 WG chairs has and continues to hinder such progress (eg by = refusing=20 to even summarize what are any outstanding issues), as well as=20 evidencing some rather dubious chairing practices.=20
Generalizing from this=20 experience, I can say that the authors of the draft have the = distinct=20 impression that any extensions to Radius are actually less = than welcome=20 by the chairs of the Radext WG.
 
regards,
Woj.
 
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: 22 November 2009 17:07
To: Wojciech = Dec=20 (wdec)
Cc: dromasca@avaya.com;=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

Woj --

The meetings of the RADEXT WG are openly = publicized=20 and are available to anyone (including people who are not physically = present).  Presentations and agenda items are openly = solicited. =20 If you would like time on the agenda of a physical or virtual = meeting, all=20 you need to do is to post a message to the WG list and your request = will be=20 honored. 

In your initial message (see=20 http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you = requested=20 guidance as to whether it would be better for the work on IPv6 = access to=20 proceed with a draft focusing on an initial set of attributes along = the=20 lines of the original submission=20 (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00), or = whether=20 a combined submission would be preferable, along the lines of the = -01=20 submission.

That is exactly the issue that is now under=20 consideration within the Consensus Call that has been issued.  = As noted=20 in the virtual interim minutes, David Miles has suggested that the = focused=20 approach would be more likely to result in rapid progress, and other = participants at the Virtual Interim agreed with this suggestion.=20

Since the IETF operates on "rough consensus", it is the duty = of the=20 Chairs to engage the WG participants on issues such as these, rather = than=20 making unilateral decisions.

Subject: RE: Draft RADEXT Virtual Interim Minutes
Date: Sun, 22 = Nov 2009=20 11:57:04 +0100
From: wdec@cisco.com
To:=20 bernard_aboba@hotmail.com
CC: dromasca@avaya.com;=20 radiusext@ops.ietf.org

Bernard,
 
this thread directly stems from the minutes of the=20 meeting. On behalf of the draft authors I proposed a = way=20 forward and in relation to this I have asked you (as=20 chair) repeatedly for some answers/clarifications. Now, given = that at=20 the n'th attempt you are still unable to answer them = clearly is=20 telling me and other folks that you're quite simply = unwilling or=20 unable to carry out your duties as chair of this WG.=20
 
Thanks,
Woj.

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: 21 November = 2009=20 02:59
To: Wojciech Dec (wdec)
Cc: 'Romascanu, = Dan=20 (Dan)'; radiusext@ops.ietf.org
Subject: RE: Draft RADEXT = Virtual=20 Interim Minutes

At=20 the Virtual Interim, the RADEXT WG held a session devoted to next = steps on=20 the IPv6 access work.  During the session, David Miles = suggested a=20 path forward for the IPv6 Access work that appeared to have = consensus=20 among the Virtual Interim attendees. 

 

In=20 order to confirm that consensus, the RADEXT WG has issued a = Consensus Call=20 to the mailing list (see  =20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html). =20  Please feel free to express your opinions on the list = relating to=20 the consensus that was reached at the Interim. =   

 

From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On=20 Behalf Of Wojciech Dec (wdec)
Sent: Friday, November = 20,=20 2009 2:03 AM
To: Bernard Aboba
Cc: Romascanu, = Dan=20 (Dan); radiusext@ops.ietf.org
Subject: RE: Draft RADEXT = Virtual=20 Interim Minutes

 

Trying=20 for the 4th time now:

 

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

- Are = you now=20 convinced of "interest"? (and if not, or partially, then on what=20 grounds?)

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

 

Thanks,

Woj.

 

------_=_NextPart_001_01CA6C3D.9AFACEE7-- -- to unsubscribe send a 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, 23 Nov 2009 12:57:54 +0000 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_01CA6C3C.77500D80" Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Mon, 23 Nov 2009 13:57:05 +0100 Message-ID: Thread-Topic: Consensus Call on Broadband Forum Next Steps Thread-Index: Acprk4W/5rWkelX5TXiQ/WKQDdQRrgAndh+QAAE2d4A= From: "Wojciech Dec (wdec)" To: "Romascanu, Dan (Dan)" , "Bernard Aboba" , "Alan DeKok" Cc: "David B. Nelson" , This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6C3C.77500D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Dan, =20 that was pretty much the gist of my proposal, which I sought to obtain confirmation on (and so far not received one) in terms of a next step. Descriptive text aside, technically it would appear to be very much identical to http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access -00, if not an earlier version, however none of the authors is willing to spend more editing time and do "yet another round" only to arrive at hear more claims of "previous issues not addressed". What are/were these issues? It goes without saying, that with the exception of the data-type issue the reasons for why even the last draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access -01 has been objected to are unclear. As such we are still expecting a response to the questions posed, while tentatively planning to re-present a souped up version of the earlier draft(s). =20 Thanks, Woj. =20 =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: 23 November 2009 12:46 To: Bernard Aboba; Alan DeKok Cc: David B. Nelson; radiusext@ops.ietf.org Subject: RE: Consensus Call on Broadband Forum Next Steps =09 =09 I feel the need to intervene with a question which is also a suggestion about a possible way forward. Would it be possible for co-authors of draft-lourdelet-radext-ipv6-dhcp together with David Miles to get together and provide an updated version of the I-D (adding of course David as a co-author) which would incorporate the elements of David's way forward suggestion made at the interim meeting and address to the possible extend comments and concerns expressed relative to draft-lourdelet-radext-ipv6-dhcp-00? The WG members could address better the consensus question with a document in front of them in my opinion.=20 =20 Dan =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Sunday, November 22, 2009 6:44 PM To: Alan DeKok Cc: David B. Nelson; radiusext@ops.ietf.org Subject: RE: Consensus Call on Broadband Forum Next Steps =09 =09 Alan DeKok said: =09 "I would like to see an updated draft prior to responding to the consensus call".=20 =09 [BA] Since IETF "Working Groups" make progress through the revision of documents in response to comments from WG participants (that is, by doing work), there is no doubt that an updated draft would represent a welcome development. In fact, it is hard to imagine how any progress can be made without such a submission. After all, there can be no progress within a "Working Group" without actual work being accomplished.=20 =09 At the Virtual Interim meeting, David Miles indicated an interest in producing such a submission, and the meeting participants provided encouragement for him to proceed along the lines he suggested. Since such a draft would represent an individual submission and the draft submission window is open, it can be submitted at any time.=20 =09 Nevertheless, we have received a request for additional guidance (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) and in order to respond to the request, a Consensus Call has been issued. Rather than representing a formal Call for Adoption, this Consensus Call is merely attempting to determine whether the approach proposed by David Miles (which envisaged a focused draft addressing the open issues and incorporating elements of http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00) represents a potential way forward. =09 Given that the draft which David Miles suggested does not actually exist, I can understand why WG participants might feel some level of discomfort in rendering a judgment on its suitability, particularly since the issues raised in previous WG discussions (listed on the RADEXT WG Issue list at http://www.drizzle.com/~aboba/RADEXT) have remained unaddressed for some time. Just as most of us are uncomfortable with signing a blank check, there may naturally be concern that the results of the Consensus Call could be misinterpreted as a blanket endorsement for a subsequent revision, regardless of its contents. =20 =09 While we certainly do not want to encourage such a mis-interpretation, given the lack of progress thus far and the repeated requests for "guidance", the Consensus Call seemed like the best way to address the specific question that was asked on the list.=20 =09 However, this is not the only way to make progress. For those not comfortable responding to the Consensus Call, it is still possible to contribute in other ways. As you alluded to, the foremost way would be to submit a draft addressing the issues that have been raised in previous WG discussions in physical and virtual meetings as well as on the list. However, an alternative way to contribute would be by submitting reviews of one or more of the existing documents, including http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00.=20 =09 =09 =09 ------_=_NextPart_001_01CA6C3C.77500D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello=20 Dan,
 
that was=20 pretty much the gist of my proposal, which I sought to obtain = confirmation on=20 (and so far not received one) in terms of a next step. Descriptive text = aside,=20 technically it would appear to be very much identical to http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access= -00,=20 if not an earlier version, however none of the = authors=20 is willing to spend more editing time and do "yet another = round" only=20 to arrive at hear more claims of "previous issues not addressed". = What=20 are/were these issues? It goes without saying, that with the exception of the = data-type=20 issue the reasons for why even the last draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access= -01=20 has been objected to are unclear. As such we are still expecting a = response=20 to the questions posed, while tentatively planning to re-present a = souped up=20 version of the earlier draft(s).
 
Thanks,
Woj.
 
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Romascanu, = Dan=20 (Dan)
Sent: 23 November 2009 12:46
To: Bernard = Aboba; Alan=20 DeKok
Cc: David B. Nelson; = radiusext@ops.ietf.org
Subject:=20 RE: Consensus Call on Broadband Forum Next Steps

I feel the=20 need to intervene with a question which is also a suggestion = about a=20 possible way forward. Would it be possible for co-authors of = draft-lourdelet-radext-ipv6-dhcp=20 together with David Miles to get together = and=20 provide an updated version of the I-D (adding of course David as a = co-author)=20 which would incorporate the elements of David's way forward suggestion = made at=20 the interim meeting and address to the possible extend comments and = concerns=20 expressed relative to draft-lourdelet-radext-ipv6-dhcp-00? The WG = members=20 could address better the consensus question with a document in front = of them=20 in my opinion.
 
Dan
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Sunday, November 22, 2009 6:44 = PM
To: Alan=20 DeKok
Cc: David B. Nelson;=20 radiusext@ops.ietf.org
Subject: RE: Consensus Call on = Broadband=20 Forum Next Steps

Alan DeKok said:

"I would like to see an updated = draft=20 prior to responding to the consensus call".

[BA] Since IETF = "Working=20 Groups" make progress through the revision of documents in response = to=20 comments from WG participants (that is, by doing work), there is no = doubt=20 that an updated draft would represent a welcome = development.   In=20 fact, it is hard to imagine how any progress can be made without = such a=20 submission.  After all, there can be no progress within a = "Working=20 Group" without actual work being accomplished.

At the = Virtual=20 Interim meeting, David Miles indicated an interest in producing such = a=20 submission, and the meeting participants provided encouragement for = him to=20 proceed along the lines he suggested.   Since such a draft = would=20 represent an individual submission and the draft submission window = is open,=20 it can be submitted at any time.

Nevertheless, we have = received a=20 request for additional guidance (see=20 http://ops.ietf.org/lists/radiusext/2009/msg00552.html) and in order = to=20 respond to the request, a Consensus Call has been issued.  = Rather than=20 representing a formal Call for Adoption, this Consensus Call is = merely=20 attempting to determine whether the approach proposed by David Miles = (which=20 envisaged a focused draft addressing the open issues and = incorporating=20 elements of = http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00)=20 represents a potential way forward.

Given that the draft = which David=20 Miles suggested does not actually exist, I can understand why WG=20 participants might feel some level of discomfort in rendering a = judgment on=20 its suitability, particularly since the issues raised in previous WG = discussions (listed on the RADEXT WG Issue list at=20 http://www.drizzle.com/~aboba/RADEXT) have remained unaddressed for = some=20 time.   Just as most of us are uncomfortable with signing = a blank=20 check, there may naturally be concern that the results of the = Consensus Call=20 could be misinterpreted as a blanket endorsement for a subsequent = revision,=20 regardless of its contents. 

While we certainly do not = want to=20 encourage such a mis-interpretation, given the lack of progress thus = far and=20 the repeated requests for "guidance", the Consensus Call seemed like = the=20 best way to address the specific question that was asked on the = list.=20

However, this is not the only way to make progress.  = For those=20 not comfortable responding to the Consensus Call, it is still = possible to=20 contribute in other ways.  As you alluded to, the foremost way = would be=20 to submit a draft addressing the issues that have been raised in = previous WG=20 discussions in physical and virtual meetings as well as on the = list. =20 However, an alternative way to contribute would be by submitting = reviews of=20 one or more of the existing documents, including=20 http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00.=20


------_=_NextPart_001_01CA6C3C.77500D80-- -- to unsubscribe send a 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, 23 Nov 2009 12:57:47 +0000 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_01CA6C3C.77F6F21C" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Mon, 23 Nov 2009 13:53:30 +0100 Message-ID: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: Acprjd9VBMqcnZtIQFWbEkSBR8TIgQAnYNrw From: "Wojciech Dec (wdec)" To: "Bernard Aboba" Cc: , This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6C3C.77F6F21C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, =20 as explained in http://www.ops.ietf.org/lists/radiusext/2009/msg00558.html the draft has been repeatedly presented, modified based on WG feedback and re-presented (or attempted to). The fact that now there seems to be some opinion, consisting effectively of adding descriptive text and an author, etc, does not address the basic question of what were the issues with the previous draft that have not yet been addressed? In other words and perhaps fundamentally, before issuing a consensus call we all would like to know what are the issues with the originally proposed draft? =20 Draft http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access -00, which had no data-type/tagging controversy and which was presented at IETF74 was claimed to have issues (that actually resulted in 01). This -00 draft now however appears to bear all the hallmarks of what's been claimed as the "virtual meeting" consented way forward, give or take additional descriptive text. Have the issues have disappeared? Persistently, it has also been claimed that there was no interest in the draft. Is there now interest? My simple 3 questions were aimed at clarifying all this, but despite asking numerous times received no clear reply other than some stonewalling (eg check the minutes), or a "consensus call" message which was very odd for a non WG draft to say the least. The implied messaging of changing draft authorship was also highly inconsiderate. =20 Now the above is just one of the many bizarre twists in the story of this draft and its "progress" in Radex. I could go on and on, including pointing out chair-101 items like that; enquiries regarding virtual meeting went un-answered; that meeting conclusions have no IETF binding status; that there is no obligation to attend meetings (esp ones scheduled in a diff time zone); and that having a discussion on draft *without* any of the draft authors present is highly unusual if not down right wrong. =20 The bottom line as I see it is that instead of facilitating WG progress, the activity of the WG chairs has and continues to hinder such progress (eg by refusing to even summarize what are any outstanding issues), as well as evidencing some rather dubious chairing practices.=20 Generalizing from this experience, I can say that the authors of the draft have the distinct impression that any extensions to Radius are actually less than welcome by the chairs of the Radext WG. =20 regards, Woj. =20 =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: 22 November 2009 17:07 To: Wojciech Dec (wdec) Cc: dromasca@avaya.com; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 Woj -- =09 The meetings of the RADEXT WG are openly publicized and are available to anyone (including people who are not physically present). Presentations and agenda items are openly solicited. If you would like time on the agenda of a physical or virtual meeting, all you need to do is to post a message to the WG list and your request will be honored. =20 =09 In your initial message (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you requested guidance as to whether it would be better for the work on IPv6 access to proceed with a draft focusing on an initial set of attributes along the lines of the original submission (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00), or whether a combined submission would be preferable, along the lines of the -01 submission.=20 =09 That is exactly the issue that is now under consideration within the Consensus Call that has been issued. As noted in the virtual interim minutes, David Miles has suggested that the focused approach would be more likely to result in rapid progress, and other participants at the Virtual Interim agreed with this suggestion.=20 =09 Since the IETF operates on "rough consensus", it is the duty of the Chairs to engage the WG participants on issues such as these, rather than making unilateral decisions.=20 =09 =09 ________________________________ Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun, 22 Nov 2009 11:57:04 +0100 From: wdec@cisco.com To: bernard_aboba@hotmail.com CC: dromasca@avaya.com; radiusext@ops.ietf.org =09 =09 Bernard, =20 this thread directly stems from the minutes of the meeting. On behalf of the draft authors I proposed a way forward and in relation to this I have asked you (as chair) repeatedly for some answers/clarifications. Now, given that at the n'th attempt you are still unable to answer them clearly is telling me and other folks that you're quite simply unwilling or unable to carry out your duties as chair of this WG.=20 =20 Thanks, Woj. ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 21 November 2009 02:59 To: Wojciech Dec (wdec) Cc: 'Romascanu, Dan (Dan)'; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 At the Virtual Interim, the RADEXT WG held a session devoted to next steps on the IPv6 access work. During the session, David Miles suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. =20 =20 In order to confirm that consensus, the RADEXT WG has issued a Consensus Call to the mailing list (see http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please feel free to express your opinions on the list relating to the consensus that was reached at the Interim. =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Friday, November 20, 2009 2:03 AM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 Trying for the 4th time now: =20 - 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?) - could you point out (summarise)the issues that were not addressed? =20 Thanks, Woj. =20 ------_=_NextPart_001_01CA6C3C.77F6F21C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bernard,
 
as=20 explained in http:= //www.ops.ietf.org/lists/radiusext/2009/msg00558.html the=20 draft has been repeatedly presented, modified based on WG feedback = and=20 re-presented (or attempted to).
The fact=20 that now there seems to be some opinion, consisting effectively of = adding=20 descriptive text and an author, etc, does not address the = basic=20 question of what were the issues with the previous draft that have = not yet=20 been addressed? In other words and perhaps fundamentally, before = issuing a=20 consensus call we all would like to know what are the issues with = the=20 originally proposed draft?
 
Draft=20 http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access= -00,=20 which had no data-type/tagging controversy and which was = presented at=20 IETF74 was claimed to have issues (that actually resulted in 01). This = -00 draft=20 now however appears to bear all the hallmarks of what's been = claimed as the=20 "virtual meeting" consented way forward, give or take additional=20 descriptive text. Have the issues have disappeared?=20 Persistently, it has also been claimed = that there=20 was no interest in the draft. Is there now=20 interest?
My simple 3 = questions=20 were aimed at clarifying all this, but despite asking numerous times = received no=20 clear reply other than some stonewalling (eg check the minutes), = or a=20 "consensus call" message which was very odd for a=20 non WG draft to say the least. The implied messaging of = changing draft=20 authorship was also highly = inconsiderate.
 
Now the = above is=20 just one of the many bizarre twists in the story of this = draft and its=20 "progress" in Radex. I could go on and on, including pointing out = chair-101=20 items like that; enquiries regarding virtual meeting went = un-answered;=20 that meeting conclusions have no IETF  binding status; = that there=20 is no obligation to attend meetings (esp ones scheduled in a diff time = zone);=20 and that having a discussion on draft *without* any of the draft = authors=20 present is highly unusual if not down right=20 wrong.
 
The bottom line as I=20 see it is that instead of facilitating WG progress, the activity of = the=20 WG chairs has and continues to hinder such progress (eg by = refusing to=20 even summarize what are any outstanding issues), as well as=20 evidencing some rather dubious chairing practices.=20
Generalizing = from this=20 experience, I can say that the authors of the draft have the = distinct=20 impression that any extensions to Radius are actually less = than welcome by=20 the chairs of the Radext WG.
 
regards,
Woj.
 
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: 22 November 2009 17:07
To: Wojciech = Dec=20 (wdec)
Cc: dromasca@avaya.com;=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

Woj --

The meetings of the RADEXT WG are openly = publicized=20 and are available to anyone (including people who are not physically=20 present).  Presentations and agenda items are openly = solicited.  If=20 you would like time on the agenda of a physical or virtual meeting, = all you=20 need to do is to post a message to the WG list and your request will = be=20 honored. 

In your initial message (see=20 http://ops.ietf.org/lists/radiusext/2009/msg00552.html) you requested = guidance=20 as to whether it would be better for the work on IPv6 access to = proceed with a=20 draft focusing on an initial set of attributes along the lines of the = original=20 submission = (http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00),=20 or whether a combined submission would be preferable, along the lines = of the=20 -01 submission.

That is exactly the issue that is now under=20 consideration within the Consensus Call that has been issued.  As = noted=20 in the virtual interim minutes, David Miles has suggested that the = focused=20 approach would be more likely to result in rapid progress, and other=20 participants at the Virtual Interim agreed with this suggestion. =

Since=20 the IETF operates on "rough consensus", it is the duty of the Chairs = to engage=20 the WG participants on issues such as these, rather than making = unilateral=20 decisions.

Subject: RE: Draft RADEXT Virtual Interim Minutes
Date: Sun, 22 Nov = 2009=20 11:57:04 +0100
From: wdec@cisco.com
To: = bernard_aboba@hotmail.com
CC:=20 dromasca@avaya.com; radiusext@ops.ietf.org

Bernard,
 
this thread directly stems from the minutes of the = meeting. On=20 behalf of the draft authors I proposed a way forward and=20 in relation to this I have asked you (as = chair) repeatedly=20 for some answers/clarifications. Now, given that at the n'th = attempt you=20 are still unable to answer them clearly is telling me and other = folks=20 that you're quite simply unwilling or unable to carry = out your=20 duties as chair of this WG.
 
Thanks,
Woj.

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: 21 November 2009 = 02:59
To: Wojciech Dec (wdec)
Cc: 'Romascanu, = Dan=20 (Dan)'; radiusext@ops.ietf.org
Subject: RE: Draft RADEXT = Virtual=20 Interim Minutes

At=20 the Virtual Interim, the RADEXT WG held a session devoted to next = steps on=20 the IPv6 access work.  During the session, David Miles = suggested a path=20 forward for the IPv6 Access work that appeared to have consensus = among the=20 Virtual Interim attendees. 

 

In=20 order to confirm that consensus, the RADEXT WG has issued a = Consensus Call=20 to the mailing list (see  =20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html).  =  Please=20 feel free to express your opinions on the list relating to the = consensus=20 that was reached at the Interim.   

 

From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On=20 Behalf Of Wojciech Dec (wdec)
Sent: Friday, November = 20, 2009=20 2:03 AM
To: Bernard Aboba
Cc: Romascanu, Dan = (Dan);=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

 

Trying=20 for the 4th time now:

 

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

- Are you = now=20 convinced of "interest"? (and if not, or partially, then on what=20 grounds?)

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

 

Thanks,

Woj.

 

------_=_NextPart_001_01CA6C3C.77F6F21C-- -- to unsubscribe send a 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, 23 Nov 2009 11:47:36 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6C32.8D906335" Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Mon, 23 Nov 2009 12:46:15 +0100 Message-ID: Thread-Topic: Consensus Call on Broadband Forum Next Steps Thread-Index: Acprk4W/5rWkelX5TXiQ/WKQDdQRrgAndh+Q From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , "Alan DeKok" Cc: "David B. Nelson" , This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6C32.8D906335 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I feel the need to intervene with a question which is also a suggestion about a possible way forward. Would it be possible for co-authors of draft-lourdelet-radext-ipv6-dhcp together with David Miles to get together and provide an updated version of the I-D (adding of course David as a co-author) which would incorporate the elements of David's way forward suggestion made at the interim meeting and address to the possible extend comments and concerns expressed relative to draft-lourdelet-radext-ipv6-dhcp-00? The WG members could address better the consensus question with a document in front of them in my opinion.=20 =20 Dan =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Sunday, November 22, 2009 6:44 PM To: Alan DeKok Cc: David B. Nelson; radiusext@ops.ietf.org Subject: RE: Consensus Call on Broadband Forum Next Steps =09 =09 Alan DeKok said: =09 "I would like to see an updated draft prior to responding to the consensus call".=20 =09 [BA] Since IETF "Working Groups" make progress through the revision of documents in response to comments from WG participants (that is, by doing work), there is no doubt that an updated draft would represent a welcome development. In fact, it is hard to imagine how any progress can be made without such a submission. After all, there can be no progress within a "Working Group" without actual work being accomplished.=20 =09 At the Virtual Interim meeting, David Miles indicated an interest in producing such a submission, and the meeting participants provided encouragement for him to proceed along the lines he suggested. Since such a draft would represent an individual submission and the draft submission window is open, it can be submitted at any time.=20 =09 Nevertheless, we have received a request for additional guidance (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) and in order to respond to the request, a Consensus Call has been issued. Rather than representing a formal Call for Adoption, this Consensus Call is merely attempting to determine whether the approach proposed by David Miles (which envisaged a focused draft addressing the open issues and incorporating elements of http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00) represents a potential way forward. =09 Given that the draft which David Miles suggested does not actually exist, I can understand why WG participants might feel some level of discomfort in rendering a judgment on its suitability, particularly since the issues raised in previous WG discussions (listed on the RADEXT WG Issue list at http://www.drizzle.com/~aboba/RADEXT) have remained unaddressed for some time. Just as most of us are uncomfortable with signing a blank check, there may naturally be concern that the results of the Consensus Call could be misinterpreted as a blanket endorsement for a subsequent revision, regardless of its contents. =20 =09 While we certainly do not want to encourage such a mis-interpretation, given the lack of progress thus far and the repeated requests for "guidance", the Consensus Call seemed like the best way to address the specific question that was asked on the list.=20 =09 However, this is not the only way to make progress. For those not comfortable responding to the Consensus Call, it is still possible to contribute in other ways. As you alluded to, the foremost way would be to submit a draft addressing the issues that have been raised in previous WG discussions in physical and virtual meetings as well as on the list. However, an alternative way to contribute would be by submitting reviews of one or more of the existing documents, including http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00.=20 =09 =09 =09 ------_=_NextPart_001_01CA6C32.8D906335 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I feel the=20 need to intervene with a question which is also a suggestion = about a=20 possible way forward. Would it be possible for co-authors of draft-lourdelet-radext-ipv6-dhcp=20 together with David Miles to get together = and provide=20 an updated version of the I-D (adding of course David as a co-author) = which=20 would incorporate the elements of David's way forward suggestion made at = the=20 interim meeting and address to the possible extend comments and concerns = expressed relative to draft-lourdelet-radext-ipv6-dhcp-00? The WG = members could=20 address better the consensus question with a document in front of them = in my=20 opinion.
 
Dan
 

From: owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Sunday, November 22, 2009 6:44 PM
To: = Alan=20 DeKok
Cc: David B. Nelson; = radiusext@ops.ietf.org
Subject:=20 RE: Consensus Call on Broadband Forum Next Steps

Alan DeKok said:

"I would like to see an updated = draft prior=20 to responding to the consensus call".

[BA] Since IETF "Working = Groups"=20 make progress through the revision of documents in response to = comments from=20 WG participants (that is, by doing work), there is no doubt that an = updated=20 draft would represent a welcome development.   In fact, it = is hard=20 to imagine how any progress can be made without such a = submission.  After=20 all, there can be no progress within a "Working Group" without actual = work=20 being accomplished.

At the Virtual Interim meeting, David = Miles=20 indicated an interest in producing such a submission, and the meeting=20 participants provided encouragement for him to proceed along the lines = he=20 suggested.   Since such a draft would represent an = individual=20 submission and the draft submission window is open, it can be = submitted at any=20 time.

Nevertheless, we have received a request for additional = guidance=20 (see http://ops.ietf.org/lists/radiusext/2009/msg00552.html) and in = order to=20 respond to the request, a Consensus Call has been issued.  Rather = than=20 representing a formal Call for Adoption, this Consensus Call is merely = attempting to determine whether the approach proposed by David Miles = (which=20 envisaged a focused draft addressing the open issues and incorporating = elements of = http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00)=20 represents a potential way forward.

Given that the draft which = David=20 Miles suggested does not actually exist, I can understand why WG = participants=20 might feel some level of discomfort in rendering a judgment on its=20 suitability, particularly since the issues raised in previous WG = discussions=20 (listed on the RADEXT WG Issue list at = http://www.drizzle.com/~aboba/RADEXT)=20 have remained unaddressed for some time.   Just as most of = us are=20 uncomfortable with signing a blank check, there may naturally be = concern that=20 the results of the Consensus Call could be misinterpreted as a blanket = endorsement for a subsequent revision, regardless of its = contents. =20

While we certainly do not want to encourage such a = mis-interpretation,=20 given the lack of progress thus far and the repeated requests for = "guidance",=20 the Consensus Call seemed like the best way to address the specific = question=20 that was asked on the list.

However, this is not the only way = to make=20 progress.  For those not comfortable responding to the Consensus = Call, it=20 is still possible to contribute in other ways.  As you alluded = to, the=20 foremost way would be to submit a draft addressing the issues that = have been=20 raised in previous WG discussions in physical and virtual meetings as = well as=20 on the list.  However, an alternative way to contribute would be = by=20 submitting reviews of one or more of the existing documents, including = http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00.=20


------_=_NextPart_001_01CA6C32.8D906335-- -- to unsubscribe send a 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, 22 Nov 2009 17:23:49 +0000 Message-ID: <4B09738B.5050403@deployingradius.com> Date: Sun, 22 Nov 2009 18:23:23 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: Re: Consensus Call on Broadband Forum Next Steps Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > While we certainly do not want to encourage such a mis-interpretation, > given the lack of progress thus far and the repeated requests for > "guidance", the Consensus Call seemed like the best way to address the > specific question that was asked on the list. I believe the document(s) can be updated, and should then be accepted as WG items. 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, 22 Nov 2009 16:45:04 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_49ff6259-b376-4ef3-952a-ae1c6049cb71_" From: Bernard Aboba To: Alan DeKok CC: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Sun, 22 Nov 2009 08:44:28 -0800 MIME-Version: 1.0 --_49ff6259-b376-4ef3-952a-ae1c6049cb71_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alan DeKok said: "I would like to see an updated draft prior to responding to the consensus = call".=20 [BA] Since IETF "Working Groups" make progress through the revision of docu= ments in response to comments from WG participants (that is=2C by doing wor= k)=2C there is no doubt that an updated draft would represent a welcome dev= elopment. In fact=2C it is hard to imagine how any progress can be made w= ithout such a submission. After all=2C there can be no progress within a "= Working Group" without actual work being accomplished.=20 At the Virtual Interim meeting=2C David Miles indicated an interest in prod= ucing such a submission=2C and the meeting participants provided encouragem= ent for him to proceed along the lines he suggested. Since such a draft w= ould represent an individual submission and the draft submission window is = open=2C it can be submitted at any time.=20 Nevertheless=2C we have received a request for additional guidance (see htt= p://ops.ietf.org/lists/radiusext/2009/msg00552.html) and in order to respon= d to the request=2C a Consensus Call has been issued. Rather than represen= ting a formal Call for Adoption=2C this Consensus Call is merely attempting= to determine whether the approach proposed by David Miles (which envisaged= a focused draft addressing the open issues and incorporating elements of h= ttp://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00) represents a= potential way forward. Given that the draft which David Miles suggested does not actually exist=2C= I can understand why WG participants might feel some level of discomfort i= n rendering a judgment on its suitability=2C particularly since the issues = raised in previous WG discussions (listed on the RADEXT WG Issue list at ht= tp://www.drizzle.com/~aboba/RADEXT) have remained unaddressed for some time= . Just as most of us are uncomfortable with signing a blank check=2C ther= e may naturally be concern that the results of the Consensus Call could be = misinterpreted as a blanket endorsement for a subsequent revision=2C regard= less of its contents. =20 While we certainly do not want to encourage such a mis-interpretation=2C gi= ven the lack of progress thus far and the repeated requests for "guidance"= =2C the Consensus Call seemed like the best way to address the specific que= stion that was asked on the list.=20 However=2C this is not the only way to make progress. For those not comfor= table responding to the Consensus Call=2C it is still possible to contribut= e in other ways. As you alluded to=2C the foremost way would be to submit = a draft addressing the issues that have been raised in previous WG discussi= ons in physical and virtual meetings as well as on the list. However=2C an= alternative way to contribute would be by submitting reviews of one or mor= e of the existing documents=2C including http://tools.ietf.org/html/draft-l= ourdelet-radext-ipv6-dhcp-00.=20 = --_49ff6259-b376-4ef3-952a-ae1c6049cb71_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alan DeKok said:

"I would like to see an updated draft prior to resp= onding to the consensus call".

[BA] Since IETF "Working Groups" mak= e progress through the revision of documents in response to comments from W= G participants (that is=2C by doing work)=2C there is no doubt that an upda= ted draft would represent a welcome development. =3B =3B In fact=2C= it is hard to imagine how any progress can be made without such a submissi= on. =3B After all=2C there can be no progress within a "Working Group" = without actual work being accomplished.

At the Virtual Interim meet= ing=2C David Miles indicated an interest in producing such a submission=2C = and the meeting participants provided encouragement for him to proceed alon= g the lines he suggested. =3B =3B Since such a draft would represen= t an individual submission and the draft submission window is open=2C it ca= n be submitted at any time.

Nevertheless=2C we have received a requ= est for additional guidance (see http://ops.ietf.org/lists/radiusext/2009/m= sg00552.html) and in order to respond to the request=2C a Consensus Call ha= s been issued. =3B Rather than representing a formal Call for Adoption= =2C this Consensus Call is merely attempting to determine whether the appro= ach proposed by David Miles (which envisaged a focused draft addressing the= open issues and incorporating elements of http://tools.ietf.org/html/draft= -lourdelet-radext-ipv6-dhcp-00) represents a potential way forward.

= Given that the draft which David Miles suggested does not actually exist=2C= I can understand why WG participants might feel some level of discomfort i= n rendering a judgment on its suitability=2C particularly since the issues = raised in previous WG discussions (listed on the RADEXT WG Issue list at ht= tp://www.drizzle.com/~aboba/RADEXT) have remained unaddressed for some time= . =3B =3B Just as most of us are uncomfortable with signing a blank= check=2C there may naturally be concern that the results of the Consensus = Call could be misinterpreted as a blanket endorsement for a subsequent revi= sion=2C regardless of its contents. =3B

While we certainly do n= ot want to encourage such a mis-interpretation=2C given the lack of progres= s thus far and the repeated requests for "guidance"=2C the Consensus Call s= eemed like the best way to address the specific question that was asked on = the list.

However=2C this is not the only way to make progress.&nbs= p=3B For those not comfortable responding to the Consensus Call=2C it is st= ill possible to contribute in other ways. =3B As you alluded to=2C the = foremost way would be to submit a draft addressing the issues that have bee= n raised in previous WG discussions in physical and virtual meetings as wel= l as on the list. =3B However=2C an alternative way to contribute would= be by submitting reviews of one or more of the existing documents=2C inclu= ding http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00.

= --_49ff6259-b376-4ef3-952a-ae1c6049cb71_-- -- to unsubscribe send a 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, 22 Nov 2009 16:07:11 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_c4a775fb-8427-4513-9cb8-9710ca13084d_" From: Bernard Aboba To: CC: "dromasca@avaya.com" , "radiusext@ops.ietf.org" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun, 22 Nov 2009 08:06:52 -0800 MIME-Version: 1.0 --_c4a775fb-8427-4513-9cb8-9710ca13084d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Woj -- The meetings of the RADEXT WG are openly publicized and are available to an= yone (including people who are not physically present). Presentations and = agenda items are openly solicited. If you would like time on the agenda of= a physical or virtual meeting=2C all you need to do is to post a message t= o the WG list and your request will be honored. =20 In your initial message (see http://ops.ietf.org/lists/radiusext/2009/msg00= 552.html) you requested guidance as to whether it would be better for the w= ork on IPv6 access to proceed with a draft focusing on an initial set of at= tributes along the lines of the original submission (http://tools.ietf.org/= html/draft-lourdelet-radext-ipv6-dhcp-00)=2C or whether a combined submissi= on would be preferable=2C along the lines of the -01 submission.=20 That is exactly the issue that is now under consideration within the Consen= sus Call that has been issued. As noted in the virtual interim minutes=2C = David Miles has suggested that the focused approach would be more likely to= result in rapid progress=2C and other participants at the Virtual Interim = agreed with this suggestion.=20 Since the IETF operates on "rough consensus"=2C it is the duty of the Chair= s to engage the WG participants on issues such as these=2C rather than maki= ng unilateral decisions.=20 Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun=2C 22 Nov 2009 11:57:04 +0100 From: wdec@cisco.com To: bernard_aboba@hotmail.com CC: dromasca@avaya.com=3B radiusext@ops.ietf.org Bernard=2C =20 this thread directly stems from the minutes of the meeting. On=20 behalf of the draft authors I proposed a way forward and=20 in relation to this I have asked you (as chair) repeatedly=20 for some answers/clarifications. Now=2C given that at the n'th attempt you= =20 are still unable to answer them clearly is telling me and other folks=20 that you're quite simply unwilling or unable to carry out your=20 duties as chair of this WG.=20 =20 Thanks=2C Woj. =20 =20 From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]=20 Sent: 21 November 2009=20 02:59 To: Wojciech Dec (wdec) Cc: 'Romascanu=2C Dan (Dan)'=3B=20 radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim=20 Minutes =20 =20 At=20 the Virtual Interim=2C the RADEXT WG held a session devoted to next steps= on the=20 IPv6 access work. During the session=2C David Miles suggested a path=20 forward for the IPv6 Access work that appeared to have consensus among th= e=20 Virtual Interim attendees. =20 =20 In=20 order to confirm that consensus=2C the RADEXT WG has issued a Consensus C= all to=20 the mailing list (see =20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please=20 feel free to express your opinions on the list relating to the consensus = that=20 was reached at the Interim. =20 =20 =20 =20 From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On=20 Behalf Of Wojciech Dec (wdec) Sent: Friday=2C November 20=2C 2009=20 2:03 AM To: Bernard Aboba Cc: Romascanu=2C Dan (Dan)=3B=20 radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim=20 Minutes =20 Trying=20 for the 4th time now: =20 -=20 could you=20 confirm that what my mail outlined in terms of moving=20 forward is also your expectation?=20 - Are you now=20 convinced of "interest"? (and if not=2C or partially=2C then on what=20 grounds?) - could you point out=20 (summarise)the issues that were not addressed? =20 Thanks=2C Woj. =20 =20 =20 = --_c4a775fb-8427-4513-9cb8-9710ca13084d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Woj --

The meetings of the RADEXT WG are openly publicized and are a= vailable to anyone (including people who are not physically present). = =3B Presentations and agenda items are openly solicited. =3B If you wou= ld like time on the agenda of a physical or virtual meeting=2C all you need= to do is to post a message to the WG list and your request will be honored= . =3B

In your initial message (see http://ops.ietf.org/lists/ra= diusext/2009/msg00552.html) you requested guidance as to whether it would b= e better for the work on IPv6 access to proceed with a draft focusing on an= initial set of attributes along the lines of the original submission (http= ://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00)=2C or whether a= combined submission would be preferable=2C along the lines of the -01 subm= ission.

That is exactly the issue that is now under consideration w= ithin the Consensus Call that has been issued. =3B As noted in the virt= ual interim minutes=2C David Miles has suggested that the focused approach = would be more likely to result in rapid progress=2C and other participants = at the Virtual Interim agreed with this suggestion.

Since the IETF = operates on "rough consensus"=2C it is the duty of the Chairs to engage the= WG participants on issues such as these=2C rather than making unilateral d= ecisions.

Subject: RE: Draft RADEXT Virtual= Interim Minutes
Date: Sun=2C 22 Nov 2009 11:57:04 +0100
From: wdec@c= isco.com
To: bernard_aboba@hotmail.com
CC: dromasca@avaya.com=3B radi= usext@ops.ietf.org

Bernard=2C
 =3B
this thread directly stems from the minutes of t= he meeting. =3BOn=20 behalf of the draft authors I =3Bproposed =3Ba way forward and=20 in =3Brelation to this =3BI =3Bhave asked you (as chair) = =3Brepeatedly=20 for some answers/clarifications. Now=2C given that at the n'th attempt = =3Byou=20 are still unable to answer them clearly =3Bis telling me and other folk= s=20 that =3Byou're quite =3Bsimply unwilling or unable =3Bto carry = out your=20 duties as chair of this WG.
=  =3B
= Thanks=2C
= Woj.

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: 21 November 2009=20 02:59
To: Wojciech Dec (wdec)
Cc: 'Romascanu=2C Dan (= Dan)'=3B=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interi= m=20 Minutes

At=20 the Virtual Interim=2C the RADEXT WG held a session devoted to next steps= on the=20 IPv6 access work. =3B During the session=2C David Miles suggested a p= ath=20 forward for the IPv6 Access work that appeared to have consensus among th= e=20 Virtual Interim attendees. =3B

 =3B=

In=20 order to confirm that consensus=2C the RADEXT WG has issued a Consensus C= all to=20 the mailing list (see =3B =3B=20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html). =3B  =3B= Please=20 feel free to express your opinions on the list relating to the consensus = that=20 was reached at the Interim.  =3B =3B

 =3B=

From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= =20 Behalf Of Wojciech Dec (wdec)
Sent: Friday=2C November 20= =2C 2009=20 2:03 AM
To: Bernard Aboba
Cc: Romascanu=2C Dan (Dan)= =3B=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interi= m=20 Minutes

 =3B

Trying=20 for the 4th time now:

 =3B

-=20 could you=20 confirm that =3Bwhat =3Bmy mail =3Boutlined in terms of movin= g=20 forward =3Bis also your expectation? =3B

- Are you now=20 convinced of "interest"? (and if not=2C or partially=2C then on what=20 grounds?)

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

 =3B=

Thanks=2C

Woj.<= /p>

 =3B

= --_c4a775fb-8427-4513-9cb8-9710ca13084d_-- -- to unsubscribe send a 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, 22 Nov 2009 15:52:51 +0000 Message-ID: <4B095E41.1080202@deployingradius.com> Date: Sun, 22 Nov 2009 16:52:33 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: Re: Consensus Call on Broadband Forum Next Steps Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Past experience has shown that breaking off a piece of the problem in > this way has the potential to enable rapid progress. At the RADEXT WG > Virtual Interim, specific next steps were presented, which included > submission of a revised draft along the lines that David Miles has > suggested. Preparation of such a revised draft is not gated by this > consensus call. I would like to see an updated draft prior to responding to the consensus call. 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, 22 Nov 2009 15:30:33 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_8d0d6558-af4d-49f6-ae86-47d72038edfd_" From: Bernard Aboba To: "David B. Nelson" , "radiusext@ops.ietf.org" Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Sun, 22 Nov 2009 07:29:40 -0800 MIME-Version: 1.0 --_8d0d6558-af4d-49f6-ae86-47d72038edfd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As David Nelson notes=2C it is the responsibility of the authors of a docum= ent to revise their document in response to comments submitted RADEXT WG pa= rticipants. =20 The minutes and the issues list (available at http://www.drizzle.com/~aboba= /RADEXT ) describe in considerable detail the issues that have been raised = with the document. These concerns range from the basic (insufficient arti= culation of the usage scenarios) to the specific (compatibility with RADIUS= Design Guidelines). Revision of a document in response to WG comments is= required prior to adoption as a WG work item for two reasons: 1. It demonstrates acceptance on the part of the authors in conforming to the processes and procedures of the IETF which require "rough consensus" for WG work products. =20 2. It demonstrates the interest of the authors to actually complete the wor= k.=20 At the RADEXT WG interim=2C we had a suggestion from David Miles for moving= forward which both addresses the concerns relating to context (by discussi= on of specific scenarios of interest to the Broadband Forum) as well as add= ressing review comments (by limiting the focus to attributes whose conforma= nce to Design Guidelines is not in dispute). Given the positive response= at the Virtual Interim=2C we are now attempting to determine whether there= is consensus for moving forward.=20 Past experience has shown that breaking off a piece of the problem in this = way has the potential to enable rapid progress. At the RADEXT WG Virtual I= nterim=2C specific next steps were presented=2C which included submission o= f a revised draft along the lines that David Miles has suggested. Preparat= ion of such a revised draft is not gated by this consensus call.=20 > Wojciech Dec writes... >=20 > > I disagree with the consensus statement below. >=20 > Noted. >=20 > > As stated repeatedly on the thread=2C the pursuit of this > > draft has been a wild goose chase since the beginning and > > until further clarification is given=2C including actually > > answering to the draft authors=2C there is nothing which > > indicates that the statement below is not a continuation > > of this goose chase. The questions posed were clear and=20 > > included a clarification of the intended way forward. >=20 > To wit=2C on October 23=2C 2009 you wrote: >=20 > We're currently planning on a two draft approach=2C > pretty much reverting to the state prior to the=20 > "merged draft"=2C along with changes to rid of any=20 > datatype issues (fingers crossed) and additional=20 > explanatory text. Before we proceed on this path=2C=20 > which to some may seem to be yet another goose chase=2C > could you confirm that this is also your expectation? >=20 > The process for advancing work in the RADEXT WG does not include any a > priori guarantees that any particular draft revision will garner sufficie= nt > support of the WG members to be adopted as a WG Work Item. It seems like > that's the assurance you're seeking=2C however. >=20 > There have been repeated comments on the list about the design of the > attributes in the -01 draft=2C including comments about the use of taggin= g. > You have previously responded that the current format falls within the > blanket provisions of the string data type and that there are precedents = for > such usage in other RFCs. Thus=2C your query of October 23 was the first > indication that you might be willing to modify the design of those > attributes to meet with WG approval. >=20 > The way the process works is that you submit a revised draft that address= es > the comments received on the list=2C and then the WG reviews the new draf= t > against the accumulated comments. If at that point in time there is > significant interest in adopting the draft as a WG Work Item=2C the draft= can > move forward. I'll remind you that when counting WG members that are > interested in a given draft=2C and are willing to review and comment upon= the > draft=2C the chairs don=92t count the authors. The chairs need to see th= at > there are sufficient non-author WG members interested in the work to ensu= re > *independent* review. >=20 > In the absence of a new draft=2C another WG member=2C David Miles=2C prop= osed > another way forward for a subset of the work in the "merged draft". The > current consensus call on the WG mailing list is to determine if the > consensus of the list matches the consensus of the WG at the Interim > Meeting. That's always the way these things are done in the IETF=2C cons= ensus > must be validated on the list. >=20 >=20 >=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: = --_8d0d6558-af4d-49f6-ae86-47d72038edfd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As David Nelson notes=2C it is the responsibility of the authors of a docum= ent to revise their document in response to comments submitted RADEXT WG pa= rticipants. =3B

The minutes and the issues list (available at http://www.drizzle.com/~a= boba/RADEXT ) describe in considerable detail the issues that have been rai= sed with the document. =3B =3B These concerns range from the basic = (insufficient articulation of the usage scenarios) to the specific (compati= bility with RADIUS Design Guidelines). =3B =3B Revision of a docume= nt in response to WG comments is required prior to adoption as a WG work it= em for two reasons:

1. It demonstrates acceptance on the part of the authors in conforming to the processes and procedures of the IETF which require "rough consensus" for WG work products. =3B
2. It demonstrates the interest of the authors to actually complete the wor= k.

At the RADEXT WG interim=2C we had a suggestion from David Miles= for moving forward which both addresses the concerns relating to context (= by discussion of specific scenarios of interest to the Broadband Forum) as = well as addressing review comments (by limiting the focus to attributes who= se conformance to Design Guidelines is not in dispute). =3B =3B&nbs= p=3B Given the positive response at the Virtual Interim=2C we are now attem= pting to determine whether there is consensus for moving forward.

P= ast experience has shown that breaking off a piece of the problem in this w= ay has the potential to enable rapid progress. =3B At the RADEXT WG Vir= tual Interim=2C specific next steps were presented=2C which included submis= sion of a revised draft along the lines that David Miles has suggested.&nbs= p=3B Preparation of such a revised draft is not gated by this consensus cal= l.






>=3B Wojciech Dec writes...
>=3B
= >=3B >=3B I disagree with the consensus statement below.
>=3B
= >=3B Noted.
>=3B
>=3B >=3B As stated repeatedly on the threa= d=2C the pursuit of this
>=3B >=3B draft has been a wild goose chase= since the beginning and
>=3B >=3B until further clarification is gi= ven=2C including actually
>=3B >=3B answering =3Bto the draft au= thors=2C there is nothing =3Bwhich
>=3B >=3B indicates that the = statement below is not a continuation
>=3B >=3B of this goose chase.= The questions posed were clear and
>=3B >=3B included a clarificat= ion of the intended way forward.
>=3B
>=3B To wit=2C on October = 23=2C 2009 you wrote:
>=3B
>=3B We're currently planning on= a two draft approach=2C
>=3B pretty much reverting to the state = prior to the
>=3B "merged draft"=2C along with changes to rid of= any
>=3B datatype issues (fingers crossed) and additional
&= gt=3B explanatory text. Before we proceed on this path=2C
>=3B = which to some may seem to be yet another goose chase=2C
>=3B = could you confirm that this is also your expectation?
>=3B
>=3B = The process for advancing work in the RADEXT WG does not include any a
&= gt=3B priori guarantees that any particular draft revision will garner suff= icient
>=3B support of the WG members to be adopted as a WG Work Item.= It seems like
>=3B that's the assurance you're seeking=2C however.>=3B
>=3B There have been repeated comments on the list about the= design of the
>=3B attributes in the -01 draft=2C including comments = about the use of tagging.
>=3B You have previously responded that the = current format falls within the
>=3B blanket provisions of the string = data type and that there are precedents for
>=3B such usage in other R= FCs. Thus=2C your query of October 23 was the first
>=3B indication t= hat you might be willing to modify the design of those
>=3B attributes= to meet with WG approval.
>=3B
>=3B The way the process works i= s that you submit a revised draft that addresses
>=3B the comments rec= eived on the list=2C and then the WG reviews the new draft
>=3B agains= t the accumulated comments. If at that point in time there is
>=3B si= gnificant interest in adopting the draft as a WG Work Item=2C the draft can=
>=3B move forward. I'll remind you that when counting WG members tha= t are
>=3B interested in a given draft=2C and are willing to review an= d comment upon the
>=3B draft=2C the chairs don=92t count the authors.= The chairs need to see that
>=3B there are sufficient non-author WG = members interested in the work to ensure
>=3B *independent* review.>=3B
>=3B In the absence of a new draft=2C another WG member=2C Da= vid Miles=2C proposed
>=3B another way forward for a subset of the wor= k in the "merged draft". The
>=3B current consensus call on the WG ma= iling list is to determine if the
>=3B consensus of the list matches t= he consensus of the WG at the Interim
>=3B Meeting. That's always the= way these things are done in the IETF=2C consensus
>=3B must be valid= ated on the list.
>=3B
>=3B
>=3B
>=3B --
>=3B t= o unsubscribe send a message to radiusext-request@ops.ietf.org with
>= =3B the word 'unsubscribe' in a single line as the message text body.
&g= t=3B archive: <=3Bhttp://psg.com/lists/radiusext/>=3B
= --_8d0d6558-af4d-49f6-ae86-47d72038edfd_-- -- to unsubscribe send a 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, 22 Nov 2009 13:19:44 +0000 From: "Dave Nelson" To: Cc: "'Wojciech Dec \(wdec\)'" Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Sun, 22 Nov 2009 08:18:59 -0500 Message-ID: <4CA2F69AA99746FB881570A6C2FF7198@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Index: AcpqTUVYdNkJUbxERw+zyz1b5r9yQQAAAnOwAETEhnAABMhYIA== Wojciech Dec writes... > I disagree with the consensus statement below. Noted. > As stated repeatedly on the thread, the pursuit of this > draft has been a wild goose chase since the beginning and > until further clarification is given, including actually > answering=A0to the draft authors, there is nothing=A0which > indicates that the statement below is not a continuation > of this goose chase. The questions posed were clear and=20 > included a clarification of the intended way forward. To wit, on October 23, 2009 you wrote: We're currently planning on a two draft approach, pretty much reverting to the state prior to the=20 "merged draft", along with changes to rid of any=20 datatype issues (fingers crossed) and additional=20 explanatory text. Before we proceed on this path,=20 which to some may seem to be yet another goose chase, could you confirm that this is also your expectation? The process for advancing work in the RADEXT WG does not include any a priori guarantees that any particular draft revision will garner = sufficient support of the WG members to be adopted as a WG Work Item. It seems = like that's the assurance you're seeking, however. There have been repeated comments on the list about the design of the attributes in the -01 draft, including comments about the use of = tagging. You have previously responded that the current format falls within the blanket provisions of the string data type and that there are precedents = for such usage in other RFCs. Thus, your query of October 23 was the first indication that you might be willing to modify the design of those attributes to meet with WG approval. The way the process works is that you submit a revised draft that = addresses the comments received on the list, and then the WG reviews the new draft against the accumulated comments. If at that point in time there is significant interest in adopting the draft as a WG Work Item, the draft = can move forward. I'll remind you that when counting WG members that are interested in a given draft, and are willing to review and comment upon = the draft, the chairs don=92t count the authors. The chairs need to see = that there are sufficient non-author WG members interested in the work to = ensure *independent* review. In the absence of a new draft, another WG member, David Miles, proposed another way forward for a subset of the work in the "merged draft". The current consensus call on the WG mailing list is to determine if the consensus of the list matches the consensus of the WG at the Interim Meeting. That's always the way these things are done in the IETF, = consensus must be validated on the list. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 22 Nov 2009 10:58:40 +0000 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_01CA6B62.88C22010" Subject: RE: Consensus Call on Broadband Forum Next Steps Date: Sun, 22 Nov 2009 11:54:30 +0100 Message-ID: Thread-Topic: Consensus Call on Broadband Forum Next Steps Thread-Index: AcpqTUVYdNkJUbxERw+zyz1b5r9yQQAAAnOwAETEhnA= From: "Wojciech Dec (wdec)" To: "Bernard Aboba" , This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6B62.88C22010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I disagree with the consensus statement below. As stated repeatedly on the thread, the pursuit of this draft has been a wild goose chase since the beginning and until further clarification is given, including actually answering to the draft authors, there is nothing which indicates that the statement below is not a continuation of this goose chase. The questions posed were clear and included a clarification of the intended way forward. =20 -Woj. =20 =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: 21 November 2009 02:53 To: radiusext@ops.ietf.org Subject: Consensus Call on Broadband Forum Next Steps =09 =09 As noted by David Miles in his post on September 23, 2009 (see http://ops.ietf.org/lists/radiusext/2009/msg00444.html) , the Broadband Forum has a need for additional RADIUS attributes in order to support their work on IPv6 access over PPP. =20 =20 To address the request from the Broadband Forum, the RADEXT WG held a session on IPv6 access during the RADEXT Virtual Interim meeting on October 13, 2009. During this meeting, consensus was reached on next steps with respect to the Broadband Forum request. The purpose of this message is to confirm the consensus reached during the interim meeting on those next steps. =20 =20 As described in the minutes of the RADEXT Virtual Interim meeting (see http://ops.ietf.org/lists/radiusext/2009/msg00531.html), a suggestion was made by David Miles to focus WG efforts on completion of work on IPv6 RADIUS attributes relevant to the work of the Broadband Forum (primarily IPv6-Address but also potentially DNS-Server-Address). In order to move forward, David volunteered to put together a document defining additional RADIUS Attributes for use in Broadband Forum IPv6 PPP usage scenarios. This document would include an overview of the Broadband Forum IPv6 over PPP architecture, while incorporating relevant attributes defined in a previously expired document, http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp. Assuming that the WG consensus was confirmed, David promised to prepare a document meeting this description for consideration.=20 =20 The Consensus Call will last until Friday, December 4, 2009. If you favor the consensus of the virtual interim meeting as described above (to focus on completing a document relating to the Broadband Forum's IPv6 over PPP scenarios), please reply to this email affirmatively, indicating your support for David's suggested next steps. If you oppose the consensus of the Virtual Interim, please reply indicating your opposition, as well as a potential alternate way forward.=20 =20 =20 ------_=_NextPart_001_01CA6B62.88C22010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 disagree with the consensus statement below. As stated repeatedly on the = thread,=20 the pursuit of this draft has been a wild goose chase since the = beginning and=20 until further clarification is given, including actually = answering to the=20 draft authors, there is nothing which indicates that the statement = below is=20 not a continuation of this goose chase. The questions posed were clear = and=20 included a clarification of the intended way = forward.
 
-Woj.
 
 

From: owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
Sent: 21 November 2009 02:53
To:=20 radiusext@ops.ietf.org
Subject: Consensus Call on Broadband = Forum=20 Next Steps

As noted by David Miles in his post on September = 23, 2009=20 (see http://op= s.ietf.org/lists/radiusext/2009/msg00444.html)=20 , the Broadband Forum has a need for additional RADIUS attributes in = order to=20 support their work on IPv6 access over PPP. 

 

To address the request from the Broadband Forum, = the RADEXT=20 WG held a session on IPv6 access during the RADEXT Virtual Interim = meeting on=20 October 13, 2009.  During this meeting, consensus was reached on = next=20 steps with respect to the Broadband Forum request.  The purpose = of this=20 message is to confirm the consensus reached during the interim meeting = on=20 those next steps. 

 

As described in the minutes of the RADEXT Virtual = Interim=20 meeting (see http://op= s.ietf.org/lists/radiusext/2009/msg00531.html),=20 a suggestion was made by David Miles to focus  WG efforts on = completion=20 of work on IPv6 RADIUS attributes relevant to the work of the = Broadband Forum=20 (primarily IPv6-Address but also potentially = DNS-Server-Address). =20  In order to move forward, David volunteered to put together a = document=20 defining additional RADIUS Attributes for use in Broadband Forum IPv6 = PPP=20 usage scenarios.  This document would include an overview of the=20 Broadband Forum IPv6 over PPP architecture, while incorporating = relevant=20 attributes defined in a previously expired document, http= ://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp.=20   Assuming that the WG consensus was confirmed, David = promised to=20 prepare a document meeting this description for consideration. =

 

The Consensus Call will last until Friday, = December 4,=20 2009.  If you favor the consensus of the virtual interim meeting = as=20 described above (to focus on completing a document relating to the = Broadband=20 Forum’s IPv6 over PPP scenarios), please reply to this email = affirmatively,=20 indicating your support for David’s suggested next = steps.   If you=20 oppose the consensus of the Virtual Interim, please reply indicating = your=20 opposition, as well as a potential alternate way forward. =

 

 

------_=_NextPart_001_01CA6B62.88C22010-- -- to unsubscribe send a 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, 22 Nov 2009 10:58:32 +0000 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_01CA6B62.8915925E" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Sun, 22 Nov 2009 11:57:04 +0100 Message-ID: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxAAAQa5/AAAMdz4AVuTG4AACFW8VAAREs84A== From: "Wojciech Dec (wdec)" To: "Bernard Aboba" Cc: "Romascanu, Dan (Dan)" , This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6B62.8915925E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, =20 this thread directly stems from the minutes of the meeting. On behalf of the draft authors I proposed a way forward and in relation to this I have asked you (as chair) repeatedly for some answers/clarifications. Now, given that at the n'th attempt you are still unable to answer them clearly is telling me and other folks that you're quite simply unwilling or unable to carry out your duties as chair of this WG.=20 =20 Thanks, Woj. ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: 21 November 2009 02:59 To: Wojciech Dec (wdec) Cc: 'Romascanu, Dan (Dan)'; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 At the Virtual Interim, the RADEXT WG held a session devoted to next steps on the IPv6 access work. During the session, David Miles suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. =20 =20 In order to confirm that consensus, the RADEXT WG has issued a Consensus Call to the mailing list (see http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please feel free to express your opinions on the list relating to the consensus that was reached at the Interim. =20 =20 From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Friday, November 20, 2009 2:03 AM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =20 Trying for the 4th time now: =20 - 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?) - could you point out (summarise)the issues that were not addressed? =20 Thanks, Woj. =20 ------_=_NextPart_001_01CA6B62.8915925E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bernard,
 
this thread directly stems from the minutes of the = meeting. On=20 behalf of the draft authors I proposed a way forward and=20 in relation to this I have asked you (as = chair) repeatedly=20 for some answers/clarifications. Now, given that at the n'th = attempt you=20 are still unable to answer them clearly is telling me and other = folks=20 that you're quite simply unwilling or unable to carry out = your=20 duties as chair of this WG.
 
Thanks,
Woj.

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: 21 November 2009=20 02:59
To: Wojciech Dec (wdec)
Cc: 'Romascanu, Dan = (Dan)';=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

At=20 the Virtual Interim, the RADEXT WG held a session devoted to next = steps on the=20 IPv6 access work.  During the session, David Miles suggested a = path=20 forward for the IPv6 Access work that appeared to have consensus among = the=20 Virtual Interim attendees. 

 

In=20 order to confirm that consensus, the RADEXT WG has issued a Consensus = Call to=20 the mailing list (see  =20 http://ops.ietf.org/lists/radiusext/2009/msg00636.html).  =  Please=20 feel free to express your opinions on the list relating to the = consensus that=20 was reached at the Interim.   

 

From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On=20 Behalf Of Wojciech Dec (wdec)
Sent: Friday, November 20, = 2009=20 2:03 AM
To: Bernard Aboba
Cc: Romascanu, Dan = (Dan);=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

 

Trying=20 for the 4th time now:

 

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

- Are you = now=20 convinced of "interest"? (and if not, or partially, then on what=20 grounds?)

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

 

Thanks,

Woj.

 

------_=_NextPart_001_01CA6B62.8915925E-- -- to unsubscribe send a 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, 21 Nov 2009 02:00:36 +0000 Message-ID: From: "Bernard Aboba" To: "'Wojciech Dec \(wdec\)'" CC: "'Romascanu, Dan \(Dan\)'" , Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 20 Nov 2009 17:59:02 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01CA6A0B.24A99B00" Thread-Index: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxAAAQa5/AAAMdz4AVuTG4AACFW8VA= Content-Language: en-us ------=_NextPart_000_0076_01CA6A0B.24A99B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit At the Virtual Interim, the RADEXT WG held a session devoted to next steps on the IPv6 access work. During the session, David Miles suggested a path forward for the IPv6 Access work that appeared to have consensus among the Virtual Interim attendees. In order to confirm that consensus, the RADEXT WG has issued a Consensus Call to the mailing list (see http://ops.ietf.org/lists/radiusext/2009/msg00636.html). Please feel free to express your opinions on the list relating to the consensus that was reached at the Interim. From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: Friday, November 20, 2009 2:03 AM To: Bernard Aboba Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes Trying for the 4th time now: - could you confirm that what my mail outlined in terms of moving forward is also your expectation? - Are you now convinced of "interest"? (and if not, or partially, then on what grounds?) - could you point out (summarise)the issues that were not addressed? Thanks, Woj. ------=_NextPart_000_0076_01CA6A0B.24A99B00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the Virtual Interim, the RADEXT WG held a session = devoted to next steps on the IPv6 access work.  During the session, David = Miles suggested a path forward for the IPv6 Access work that appeared to have consensus = among the Virtual Interim attendees. 

 

In order to confirm that consensus, the RADEXT WG has = issued a Consensus Call to the mailing list (see   = http://ops.ietf.org/lists/radiusext/2009/msg00636.html).   Please feel free to express your opinions on the list relating to = the consensus that was reached at the Interim. =   

 

From:= owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On = Behalf Of Wojciech Dec (wdec)
Sent: Friday, November 20, 2009 2:03 AM
To: Bernard Aboba
Cc: Romascanu, Dan (Dan); radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual Interim = Minutes

 

Trying for the 4th time now:

 

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

- Are you now convinced of "interest"? (and if not, or = partially, then on what grounds?)

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

 

Thanks,

Woj.

 =

------=_NextPart_000_0076_01CA6A0B.24A99B00-- -- to unsubscribe send a 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, 21 Nov 2009 01:54:30 +0000 Message-ID: From: "Bernard Aboba" To: Subject: Consensus Call on Broadband Forum Next Steps Date: Fri, 20 Nov 2009 17:52:53 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01CA6A0A.48E07FD0" Thread-Index: AcpqTUVYdNkJUbxERw+zyz1b5r9yQQAAAnOw Content-Language: en-us ------=_NextPart_000_006C_01CA6A0A.48E07FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As noted by David Miles in his post on September 23, 2009 (see http://ops.ietf.org/lists/radiusext/2009/msg00444.html) , the Broadband Forum has a need for additional RADIUS attributes in order to support their work on IPv6 access over PPP. To address the request from the Broadband Forum, the RADEXT WG held a session on IPv6 access during the RADEXT Virtual Interim meeting on October 13, 2009. During this meeting, consensus was reached on next steps with respect to the Broadband Forum request. The purpose of this message is to confirm the consensus reached during the interim meeting on those next steps. As described in the minutes of the RADEXT Virtual Interim meeting (see http://ops.ietf.org/lists/radiusext/2009/msg00531.html), a suggestion was made by David Miles to focus WG efforts on completion of work on IPv6 RADIUS attributes relevant to the work of the Broadband Forum (primarily IPv6-Address but also potentially DNS-Server-Address). In order to move forward, David volunteered to put together a document defining additional RADIUS Attributes for use in Broadband Forum IPv6 PPP usage scenarios. This document would include an overview of the Broadband Forum IPv6 over PPP architecture, while incorporating relevant attributes defined in a previously expired document, http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp. Assuming that the WG consensus was confirmed, David promised to prepare a document meeting this description for consideration. The Consensus Call will last until Friday, December 4, 2009. If you favor the consensus of the virtual interim meeting as described above (to focus on completing a document relating to the Broadband Forum's IPv6 over PPP scenarios), please reply to this email affirmatively, indicating your support for David's suggested next steps. If you oppose the consensus of the Virtual Interim, please reply indicating your opposition, as well as a potential alternate way forward. ------=_NextPart_000_006C_01CA6A0A.48E07FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As noted by David Miles in his post on September = 23, 2009 (see http://op= s.ietf.org/lists/radiusext/2009/msg00444.html) , the Broadband Forum has a need for additional RADIUS attributes in = order to support their work on IPv6 access over PPP. 

 

To address the request from the Broadband Forum, = the RADEXT WG held a session on IPv6 access during the RADEXT Virtual Interim meeting = on October 13, 2009.  During this meeting, consensus was reached on = next steps with respect to the Broadband Forum request.  The purpose of = this message is to confirm the consensus reached during the interim meeting = on those next steps. 

 

As described in the minutes of the RADEXT Virtual = Interim meeting (see http://op= s.ietf.org/lists/radiusext/2009/msg00531.html), a suggestion was made by David Miles to focus  WG efforts on = completion of work on IPv6 RADIUS attributes relevant to the work of the Broadband = Forum (primarily IPv6-Address but also potentially DNS-Server-Address).   In order to move forward, David volunteered to put together a = document defining additional RADIUS Attributes for use in Broadband Forum IPv6 = PPP usage scenarios.  This document would include an overview of the = Broadband Forum IPv6 over PPP architecture, while incorporating relevant attributes = defined in a previously expired document, http= ://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp.   Assuming that the WG consensus was confirmed, David promised = to prepare a document meeting this description for consideration. =

 

The Consensus Call will last until Friday, December = 4, 2009.  If you favor the consensus of the virtual interim meeting as described above (to focus on completing a document relating to the = Broadband Forum’s IPv6 over PPP scenarios), please reply to this email affirmatively, = indicating your support for David’s suggested next steps.   If you = oppose the consensus of the Virtual Interim, please reply indicating your = opposition, as well as a potential alternate way forward.

 

 

------=_NextPart_000_006C_01CA6A0A.48E07FD0-- -- to unsubscribe send a 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, 21 Nov 2009 00:41:15 +0000 Authentication-Results: sj-iport-4.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_01CA69C8.A6909654" Subject: RE: Draft RADEXT Virtual Interim Minutes Date: Fri, 20 Nov 2009 11:02:57 +0100 Message-ID: Thread-Topic: Draft RADEXT Virtual Interim Minutes Thread-Index: AcpT+FgDCU+tVkA+QUWWoBT2lXh60AAAylxAAAQa5/AAAMdz4AVuTG4A From: "Wojciech Dec (wdec)" To: "Bernard Aboba" Cc: "Romascanu, Dan (Dan)" , This is a multi-part message in MIME format. ------_=_NextPart_001_01CA69C8.A6909654 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Trying for the 4th time now: =20 - 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?) - could you point out (summarise) the issues that were not addressed? =20 Thanks, Woj. ________________________________ From: Wojciech Dec (wdec)=20 Sent: 23 October 2009 20:36 To: 'Bernard Aboba'; radiusext@ops.ietf.org Subject: RE: Draft RADEXT Virtual Interim Minutes =09 =09 =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 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_01CA69C8.A6909654 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trying for the 4th time=20 now:

 

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

- Are you now = convinced of=20 "interest"? (and if not, or partially, then on what grounds?)

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

 

Thanks,

Woj.


From: Wojciech Dec (wdec) =
Sent: 23=20 October 2009 20:36
To: 'Bernard Aboba';=20 radiusext@ops.ietf.org
Subject: RE: Draft RADEXT Virtual = Interim=20 Minutes

 

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=20 the 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=20 per my earlier mail(s):

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

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

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

 

Thanks.

 

 

 

 

 

 

------_=_NextPart_001_01CA69C8.A6909654-- -- to unsubscribe send a 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, 18 Nov 2009 19:39:00 +0000 Message-ID: From: "Bernard Aboba" To: =?iso-8859-1?Q?'Klaus_Kl=F6ser'?= , Subject: RE: Radius MIB and DMTFs CIM Date: Wed, 18 Nov 2009 11:38:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Index: AQHKaIVPDw3qIMJqskeOG5bfSPTeEZE8PBsQ Content-Language: en-us Not as far as I know.=20 -----Original Message----- From: Klaus Kl=F6ser [mailto:klaus@kloeser.com]=20 Sent: Wednesday, November 18, 2009 11:27 AM To: Bernard Aboba Subject: Radius MIB and DMTFs CIM Hi, I would be interested, if there is a representation of RADIUS management information in DMTF's CIM classes (www.dmtf.org). Any Information is appreciated ! Thank you Best regards Klaus Kl=F6ser -- to unsubscribe send a 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, 17 Nov 2009 19:23:20 +0000 Message-ID: From: "Bernard Aboba" To: Subject: FW: draft-ietf-radext-dynamic-discovery-01.txt Date: Tue, 17 Nov 2009 11:22:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpntphHkhPwrfRST4mZYOPVC8Z7DQABK2DA Content-Language: en-us -----Original Message----- From: Leslie Daigle [mailto:leslie@thinkingcat.com] Sent: Tuesday, November 17, 2009 10:49 AM To: stefan.winter@restena.lu; mikem@open.com.au Cc: Bernard Aboba; David Nelson Subject: draft-ietf-radext-dynamic-discovery-01.txt Hi, Looking for something completely different, I came across your RADEXT draft (draft-ietf-radext-dynamic-discovery-01.txt). You need to know that NAPTR records cannot be used "in the wild" (as in, "just retrieve the NAPTR record"), as currently described in your document. NAPTR records are part of the DNS implementation of the Dynamic Delegation Discovery System (DDDS) -- see RFC3403. To use them, you need to define a DDDS application (as outlined in that suite of documents). You may find that S-NAPTR (RFC3958) does the trick for you. Leslie. P.S.: Feel free to forward this note to the WG mailing list, if that's useful. -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- -- to unsubscribe send a 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, 13 Nov 2009 09:47:02 +0000 Message-ID: <4AFD2ACF.3020503@deployingradius.com> Date: Fri, 13 Nov 2009 10:45:51 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "'Koehler, Yannick'" , radiusext@ops.ietf.org Subject: Re: RFC 3579 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > There is no such thing as an EAP-Start packet defined outside of > RADIUS. Perhaps you are thinking of EAPoL-Start? However, EAPoL-Start > as defined in IEEE 802.1X-2004 does not contain any data, nor does it > contain an EAP packet. An EAP authenticator can respond to an > EAPoL-Start by sending an EAP-Request/Identity to the peer; there is no > reason to send a RADIUS Access-Request/EAP-Message packet to the RADIUS > server unless there is a desire to bypass the Identity exchange. IIRC, I have seen packet traces where the EAP-Message attribute contains only 4 octets. The server then responds with an Access-Challenge/EAP-Identity request, and authentication continues. But that behavior is rare. 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, 13 Nov 2009 00:56:29 +0000 Message-ID: From: "Bernard Aboba" To: Subject: Registration of RADIUS Attribute Values and RFC 3575 Date: Thu, 12 Nov 2009 16:55:27 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0212_01CA63B8.EF85DC20" thread-index: AcphpSiOJiCTGTGPQlyjnn0H4TQe1wCVoRhw Content-Language: en-us ------=_NextPart_000_0212_01CA63B8.EF85DC20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Recently on the RADEXT WG mailing list, an issue has been raised about the IANA allocation procedures for RADIUS attribute values: http://ops.ietf.org/lists/radiusext/2009/msg00625.html As noted in RFC 3575, Section 2.1: Certain attributes (for example, NAS-Port-Type) in RADIUS define a list of values to correspond with various meanings. There can be 4 billion (2^32) values for each attribute. Additional values can be allocated by the Designated Expert. The exception to this policy is the Service-Type attribute (6), whose values define new modes of operation for RADIUS. Values 1-16 of the Service-Type attribute have been allocated. Allocation of new Service-Type values are by IETF Consensus. The intention is that any allocation will be accompanied by a published RFC. Given the above text, it is my understanding that according to RFC 3575, additional values for RADIUS attributes (with the exception of the Service-Type attribute (6)) are to be allocated by Designated Expert. However, within the IANA RADIUS registry ( http://www.iana.org/protocols/) RADIUS attribute values are listed as requiring Standards Action. All in all, a substantial number of the entries in this registry appear to be incorrect. Given that RFC 3575 specifically indicates that standards action is not required for allocation of values for any RADIUS attribute other than Service-Type, there is not much room for interpretation here and I would like to make sure that this problem is corrected as soon as possible. We have notified IANA, but so far we have not gotten any response. ------=_NextPart_000_0212_01CA63B8.EF85DC20 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Recently on the = RADEXT WG mailing list, an issue has been raised about the IANA allocation = procedures for RADIUS attribute values:

http://ops.ietf.org/lists/radiusext/2009/msg00625= .html

 

As noted in RFC 3575, = Section 2.1:

 

   Certain attributes (for example, = NAS-Port-Type) in RADIUS define a

   list of values to correspond with various meanings.  There can be 4

   billion (2^32) values for each = attribute.  Additional values can be

   allocated by the Designated Expert.  = The exception to this policy is

   the Service-Type attribute (6), whose values = define new modes of

   operation for RADIUS.  Values 1-16 of = the Service-Type attribute have

   been allocated.  Allocation of new Service-Type values are by IETF

   Consensus.  The intention is that any allocation will be accompanied

   by a published RFC.

 

Given the above text, = it is my understanding that according to RFC 3575, additional values for RADIUS attributes (with the exception of the Service-Type attribute (6)) are to = be allocated by Designated Expert.

 

However, within the = IANA RADIUS registry (http://www.iana.org/protocols/) RADIUS attribute values are listed as requiring Standards Action.  =  All in all, a substantial number of the entries in this registry appear to be incorrect.

 

Given that RFC 3575 = specifically indicates that standards action is not required for allocation of values = for any RADIUS attribute other than Service-Type, there is not much room for interpretation here and I would like to make sure that this problem is corrected as soon as possible.   We have notified IANA, but so = far we have not gotten any response.

 

 

 

 

 

 

 

 

 

------=_NextPart_000_0212_01CA63B8.EF85DC20-- -- to unsubscribe send a 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, 12 Nov 2009 21:53:18 +0000 Message-ID: From: "Bernard Aboba" To: "'Koehler, Yannick'" , Subject: RE: RFC 3579 Date: Thu, 12 Nov 2009 13:52:30 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E4_01CA639F.60EC76E0" thread-index: AcpfMu4Mi/aIwCeuTO6zuPBEDg3rAwAAi++AAQBaAzAAAGp5EAAZ/DJgAAnlM0AAAJxsQAAF7IJw Content-Language: en-us ------=_NextPart_000_01E4_01CA639F.60EC76E0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit There is no such thing as an EAP-Start packet defined outside of RADIUS. Perhaps you are thinking of EAPoL-Start? However, EAPoL-Start as defined in IEEE 802.1X-2004 does not contain any data, nor does it contain an EAP packet. An EAP authenticator can respond to an EAPoL-Start by sending an EAP-Request/Identity to the peer; there is no reason to send a RADIUS Access-Request/EAP-Message packet to the RADIUS server unless there is a desire to bypass the Identity exchange. From: Koehler, Yannick [mailto:yannick.koehler@hp.com] Sent: Thursday, November 12, 2009 11:01 AM To: Bernard Aboba; radiusext@ops.ietf.org Subject: RE: RFC 3579 Hi, I received claim that Windows 7 sends out EAP-Start not RADIUS packets. Those EAP-Start most likely are transmitted over a EAPOL packet and our product extract the EAP and sends it over RADIUS. I was mostly getting up to date with this RFC because it seems that this is where the EAP-Start got defined. -- Yannick Koehler From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: November-12-09 1:45 PM To: Koehler, Yannick; radiusext@ops.ietf.org Subject: RE: RFC 3579 Windows 7 does not include a RADIUS client. So I'm surprised that you are seeing it send RADIUS packets at all, let alone a RADIUS Access-Request including an EAP-Message attribute. If a NAS sends an EAP Identity-Request to an EAP peer, I'd expect the EAP peer to respond with an EAP Identity-Response. The NAS can then send an Access-Request with an EAP-Message attribute containing the contents of the EAP-Response/Identity. Am I missing something? From: Koehler, Yannick [mailto:yannick.koehler@hp.com] Sent: Thursday, November 12, 2009 6:01 AM To: Bernard Aboba; radiusext@ops.ietf.org Subject: RE: RFC 3579 An errata would be useful because even after your reply the RFC seems even more confusing, this part of the RFC no more apply then: " EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data)." We saw report that Windows 7 was sending a EAP-Message with length of 2, that is why I am inquiring. But considering what you just said, the fact that our product sends an identity-request should force them to send an EAP Identity response and not an EAP-start. I will pursue my investigation to figure out in which situation the Windows 7 act like this. -- Yannick Koehler From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: November-11-09 8:34 PM To: radiusext@ops.ietf.org Cc: Koehler, Yannick Subject: Re: RFC 3579 In the normal case you describe below (where the NAS always starts off with an EAP-Identity Request) there is no need for the NAS to ever send an EAP-Start packet to the RADIUS server. This is only useful if the Identity exchange might be superfluous and the RADIUS server can just start off with the EAP method Request from the beginning. There are a very limited number of situations where this would be useful because: a. The NAS has to route the request to a RADIUS server without a User-Name attribute because there has been no Identity Exchange (e.g. only the Calling-Station-Id might be available to be placed in the User-Name attribute) b. The RADIUS server has to be prepared to choose the EAP method based on what is placed in the User-Name attribute, if anything. There are some limited situations in which this might be useful. but I'm not aware of much deployment experience. The EAP-Start packet is a RADIUS Access-Request packet containing an EAP-Message attribute with a single NUL character. So the length of the EAP-Message attribute is >=3. Might make sense to file an errata to clarify. There is no RADIUS attribute to encapsulate EAPoL, only EAP-Message, which is used to encapsulate EAP. So there is no way to send an EAPoL-Start packet to a RADIUS server within an EAP-Message attribute. If there is a need to convey EAPoL-Start data (e.g. IEEE 802.1X-REV extensions to EAPoL-Start such as NIDs) then you'd need to define a distinct RADIUS attribute to convey that. From: Koehler, Yannick [mailto:yannick.koehler@hp.com] Sent: Friday, November 06, 2009 2:46 PM To: Bernard Aboba; pcalhoun@airespace.com Subject: RFC 3579 Hello, I have read the RFC 3579 and I have some questions and I was hoping to get some answers from you. In the RFC it says that the EAP-Start may be represented by an EAP-Message of length 2 (no data). Yet, the specification of this EAP-Message attribute is defined with a length >= 3 and that, even in the RFC 3579. Also, I do not follow why there is an EAP-Start packet is this the same as EAPOL-Start ? And if not, why sending such an empty packet to a RADIUS server? It seems to me like it waste a round-trip. My understanding of 802.1x nego is something like that: Client sends EAPOL-Start NAS answer EAP-Identity Request Client sends EAP-Identity response NAS sends RADIUS with EAP identity response to RADIUS RADIUS reply NAS forward answer. Client continue exchange. How is the EAP-Start affecting this negotiation and when is it used, and why? Is there more documentation on this packet? -- Yannick Koehler ------=_NextPart_000_01E4_01CA639F.60EC76E0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

There is no such = thing as an EAP-Start packet defined outside of RADIUS.  Perhaps you are thinking of = EAPoL-Start?  However, EAPoL-Start as defined in IEEE 802.1X-2004 does not contain any data, = nor does it contain an EAP packet.   An EAP authenticator can respond = to an EAPoL-Start by sending an EAP-Request/Identity to the peer;  there is no reason = to send a RADIUS Access-Request/EAP-Message packet to the RADIUS server unless = there is a desire to bypass the Identity exchange.

 

 

 

From:= Koehler, = Yannick [mailto:yannick.koehler@hp.com]
Sent: Thursday, November 12, 2009 11:01 AM
To: Bernard Aboba; radiusext@ops.ietf.org
Subject: RE: RFC 3579

 

Hi,

 

  I received = claim that Windows 7 sends out EAP-Start not RADIUS packets.  Those EAP-Start = most likely are transmitted over a EAPOL packet and our product extract the = EAP and sends it over RADIUS.  I was mostly getting up to date with this = RFC because it seems that this is where the EAP-Start got = defined.

 

--

Yannick = Koehler

 

From:= Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: November-12-09 1:45 PM
To: Koehler, Yannick; radiusext@ops.ietf.org
Subject: RE: RFC 3579

 

Windows 7 does not = include a RADIUS client.  So I’m surprised that you are seeing it send = RADIUS packets at all, let alone a RADIUS Access-Request including an = EAP-Message attribute.

 

If a NAS sends an EAP Identity-Request to an EAP peer, I’d expect the EAP peer to = respond with an  EAP Identity-Response.  The NAS can then send an  = Access-Request with an EAP-Message attribute containing the contents of the EAP-Response/Identity. 

 

Am I missing = something?

 

From:= Koehler, = Yannick [mailto:yannick.koehler@hp.com]
Sent: Thursday, November 12, 2009 6:01 AM
To: Bernard Aboba; radiusext@ops.ietf.org
Subject: RE: RFC 3579

 

An errata would be = useful because even after your reply the RFC seems even more confusing, this = part of the RFC no more apply then:

 

“=
   EAP-Start is indicated by sending an EAP-Message attribute =
with a

   length of 2 (no data).”

 

We saw report that = Windows 7 was sending a EAP-Message with length of 2, that is why I am = inquiring.  But considering what you just said, the fact that our product sends an identity-request should force them to send an EAP Identity response and = not an EAP-start.  I will pursue my investigation to figure out in which situation the Windows 7 act like this.

 

--

Yannick = Koehler

 

 

From:= Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: November-11-09 8:34 PM
To: radiusext@ops.ietf.org
Cc: Koehler, Yannick
Subject: Re: RFC 3579

 

In the normal case you describe below (where the NAS = always starts off with an EAP-Identity Request) there is no need for the NAS to = ever send an EAP-Start packet to the RADIUS server.  This is only useful = if the Identity exchange might be superfluous and the RADIUS server can just = start off with the EAP method Request from the beginning.  There are a very = limited number of situations where this would be useful = because:

 

a.    The NAS has to route the request to = a RADIUS server without a User-Name attribute because there has been no = Identity Exchange (e.g. only the Calling-Station-Id might be available to be = placed in the User-Name attribute)

b.    The RADIUS server has to be = prepared to choose the EAP method based on what is placed in the User-Name = attribute, if anything. 

 

There are some limited situations in which this might be = useful… but I’m not aware of much deployment experience. =

 

The EAP-Start packet is a RADIUS Access-Request packet containing an EAP-Message attribute with a single NUL character.  = So the length of the EAP-Message attribute is >=3D3. =

Might make sense to file an errata to clarify. =

 

There is no RADIUS attribute to encapsulate EAPoL, only EAP-Message, which is used to encapsulate EAP.   So there is = no way to send an EAPoL-Start packet to a RADIUS server within an EAP-Message attribute.  If there is a need to convey EAPoL-Start data (e.g. = IEEE 802.1X-REV extensions to EAPoL-Start such as NIDs) then you’d need = to define a distinct RADIUS attribute to convey that.

 

 

 

 

 

From:= Koehler, = Yannick [mailto:yannick.koehler@hp.com]
Sent: Friday, November 06, 2009 2:46 PM
To: Bernard Aboba; pcalhoun@airespace.com
Subject: RFC 3579

 

Hello,

 

  I have read the RFC 3579 and I have some = questions and I was hoping to get some answers from you.  In the RFC it says = that the EAP-Start may be represented by an EAP-Message of length 2 (no = data).  Yet, the specification of this EAP-Message attribute is defined = with a length >=3D 3 and that, even in the RFC 3579.  Also, I do not = follow why there is an EAP-Start packet is this the same as EAPOL-Start ?  And = if not, why sending such an empty packet to a RADIUS server?  It seems = to me like it waste a round-trip.

 

  My understanding of 802.1x nego is something = like that:

 

  Client sends EAPOL-Start

              &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =      NAS answer EAP-Identity Request

  Client sends EAP-Identity = response

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           NAS sends RADIUS with EAP identity response to RADIUS

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           RADIUS reply

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           NAS forward answer.

  Client continue exchange.

 

How is the EAP-Start affecting this negotiation and = when is it used, and why?  Is there more documentation on this = packet?

 

--

Yannick Koehler

------=_NextPart_000_01E4_01CA639F.60EC76E0-- -- to unsubscribe send a 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, 12 Nov 2009 18:46:16 +0000 Message-ID: From: "Bernard Aboba" To: "'Koehler, Yannick'" , Subject: RE: RFC 3579 Date: Thu, 12 Nov 2009 10:44:43 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CA6385.257698D0" Thread-Index: AcpfMu4Mi/aIwCeuTO6zuPBEDg3rAwAAi++AAQBaAzAAAGp5EAAZ/DJgAAnlM0A= Content-Language: en-us ------=_NextPart_000_0001_01CA6385.257698D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Windows 7 does not include a RADIUS client. So I'm surprised that you are seeing it send RADIUS packets at all, let alone a RADIUS Access-Request including an EAP-Message attribute. If a NAS sends an EAP Identity-Request to an EAP peer, I'd expect the EAP peer to respond with an EAP Identity-Response. The NAS can then send an Access-Request with an EAP-Message attribute containing the contents of the EAP-Response/Identity. Am I missing something? From: Koehler, Yannick [mailto:yannick.koehler@hp.com] Sent: Thursday, November 12, 2009 6:01 AM To: Bernard Aboba; radiusext@ops.ietf.org Subject: RE: RFC 3579 An errata would be useful because even after your reply the RFC seems even more confusing, this part of the RFC no more apply then: " EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data)." We saw report that Windows 7 was sending a EAP-Message with length of 2, that is why I am inquiring. But considering what you just said, the fact that our product sends an identity-request should force them to send an EAP Identity response and not an EAP-start. I will pursue my investigation to figure out in which situation the Windows 7 act like this. -- Yannick Koehler From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: November-11-09 8:34 PM To: radiusext@ops.ietf.org Cc: Koehler, Yannick Subject: Re: RFC 3579 In the normal case you describe below (where the NAS always starts off with an EAP-Identity Request) there is no need for the NAS to ever send an EAP-Start packet to the RADIUS server. This is only useful if the Identity exchange might be superfluous and the RADIUS server can just start off with the EAP method Request from the beginning. There are a very limited number of situations where this would be useful because: a. The NAS has to route the request to a RADIUS server without a User-Name attribute because there has been no Identity Exchange (e.g. only the Calling-Station-Id might be available to be placed in the User-Name attribute) b. The RADIUS server has to be prepared to choose the EAP method based on what is placed in the User-Name attribute, if anything. There are some limited situations in which this might be useful. but I'm not aware of much deployment experience. The EAP-Start packet is a RADIUS Access-Request packet containing an EAP-Message attribute with a single NUL character. So the length of the EAP-Message attribute is >=3. Might make sense to file an errata to clarify. There is no RADIUS attribute to encapsulate EAPoL, only EAP-Message, which is used to encapsulate EAP. So there is no way to send an EAPoL-Start packet to a RADIUS server within an EAP-Message attribute. If there is a need to convey EAPoL-Start data (e.g. IEEE 802.1X-REV extensions to EAPoL-Start such as NIDs) then you'd need to define a distinct RADIUS attribute to convey that. From: Koehler, Yannick [mailto:yannick.koehler@hp.com] Sent: Friday, November 06, 2009 2:46 PM To: Bernard Aboba; pcalhoun@airespace.com Subject: RFC 3579 Hello, I have read the RFC 3579 and I have some questions and I was hoping to get some answers from you. In the RFC it says that the EAP-Start may be represented by an EAP-Message of length 2 (no data). Yet, the specification of this EAP-Message attribute is defined with a length >= 3 and that, even in the RFC 3579. Also, I do not follow why there is an EAP-Start packet is this the same as EAPOL-Start ? And if not, why sending such an empty packet to a RADIUS server? It seems to me like it waste a round-trip. My understanding of 802.1x nego is something like that: Client sends EAPOL-Start NAS answer EAP-Identity Request Client sends EAP-Identity response NAS sends RADIUS with EAP identity response to RADIUS RADIUS reply NAS forward answer. Client continue exchange. How is the EAP-Start affecting this negotiation and when is it used, and why? Is there more documentation on this packet? -- Yannick Koehler ------=_NextPart_000_0001_01CA6385.257698D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Windows 7 does not = include a RADIUS client.  So I’m surprised that you are seeing it send = RADIUS packets at all, let alone a RADIUS Access-Request including an EAP-Message = attribute.

 

If a NAS sends an EAP = Identity-Request to an EAP peer, I’d expect the EAP peer to respond with an  = EAP Identity-Response.  The NAS can then send an  Access-Request = with an EAP-Message attribute containing the contents of the = EAP-Response/Identity. 

 

Am I missing = something?

 

From:= Koehler, = Yannick [mailto:yannick.koehler@hp.com]
Sent: Thursday, November 12, 2009 6:01 AM
To: Bernard Aboba; radiusext@ops.ietf.org
Subject: RE: RFC 3579

 

An errata would be = useful because even after your reply the RFC seems even more confusing, this = part of the RFC no more apply then:

 

“=
   EAP-Start is indicated by sending an EAP-Message attribute =
with a

   length of 2 (no data).”

 

We saw report that = Windows 7 was sending a EAP-Message with length of 2, that is why I am = inquiring.  But considering what you just said, the fact that our product sends an identity-request should force them to send an EAP Identity response and = not an EAP-start.  I will pursue my investigation to figure out in which situation the Windows 7 act like this.

 

--

Yannick = Koehler

 

 

From:= Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: November-11-09 8:34 PM
To: radiusext@ops.ietf.org
Cc: Koehler, Yannick
Subject: Re: RFC 3579

 

In the normal case you describe below (where the NAS = always starts off with an EAP-Identity Request) there is no need for the NAS to = ever send an EAP-Start packet to the RADIUS server.  This is only useful = if the Identity exchange might be superfluous and the RADIUS server can just = start off with the EAP method Request from the beginning.  There are a very = limited number of situations where this would be useful = because:

 

a.    The NAS has to route the request to = a RADIUS server without a User-Name attribute because there has been no = Identity Exchange (e.g. only the Calling-Station-Id might be available to be = placed in the User-Name attribute)

b.    The RADIUS server has to be = prepared to choose the EAP method based on what is placed in the User-Name = attribute, if anything. 

 

There are some limited situations in which this might be = useful… but I’m not aware of much deployment experience. =

 

The EAP-Start packet is a RADIUS Access-Request packet containing an EAP-Message attribute with a single NUL character.  = So the length of the EAP-Message attribute is >=3D3. =

Might make sense to file an errata to clarify. =

 

There is no RADIUS attribute to encapsulate EAPoL, only EAP-Message, which is used to encapsulate EAP.   So there is = no way to send an EAPoL-Start packet to a RADIUS server within an EAP-Message attribute.  If there is a need to convey EAPoL-Start data (e.g. = IEEE 802.1X-REV extensions to EAPoL-Start such as NIDs) then you’d need = to define a distinct RADIUS attribute to convey that.

 

 

 

 

 

From:= Koehler, = Yannick [mailto:yannick.koehler@hp.com]
Sent: Friday, November 06, 2009 2:46 PM
To: Bernard Aboba; pcalhoun@airespace.com
Subject: RFC 3579

 

Hello,

 

  I have read the RFC 3579 and I have some = questions and I was hoping to get some answers from you.  In the RFC it says = that the EAP-Start may be represented by an EAP-Message of length 2 (no = data).  Yet, the specification of this EAP-Message attribute is defined = with a length >=3D 3 and that, even in the RFC 3579.  Also, I do not = follow why there is an EAP-Start packet is this the same as EAPOL-Start ?  And = if not, why sending such an empty packet to a RADIUS server?  It seems = to me like it waste a round-trip.

 

  My understanding of 802.1x nego is something = like that:

 

  Client sends EAPOL-Start

  =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =      NAS answer EAP-Identity Request

  Client sends EAP-Identity = response

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           NAS sends RADIUS with EAP identity response to RADIUS

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           RADIUS reply

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           NAS forward answer.

  Client continue exchange.

 

How is the EAP-Start affecting this negotiation and = when is it used, and why?  Is there more documentation on this = packet?

 

--

Yannick Koehler

------=_NextPart_000_0001_01CA6385.257698D0-- -- to unsubscribe send a 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, 12 Nov 2009 01:35:22 +0000 Message-ID: From: "Bernard Aboba" To: CC: Subject: Re: RFC 3579 Date: Wed, 11 Nov 2009 17:34:21 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01CA62F5.34801800" thread-index: AcpfMu4Mi/aIwCeuTO6zuPBEDg3rAwAAi++AAQBaAzAAAGp5EA== Content-Language: en-us ------=_NextPart_000_0026_01CA62F5.34801800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In the normal case you describe below (where the NAS always starts off with an EAP-Identity Request) there is no need for the NAS to ever send an EAP-Start packet to the RADIUS server. This is only useful if the Identity exchange might be superfluous and the RADIUS server can just start off with the EAP method Request from the beginning. There are a very limited number of situations where this would be useful because: a. The NAS has to route the request to a RADIUS server without a User-Name attribute because there has been no Identity Exchange (e.g. only the Calling-Station-Id might be available to be placed in the User-Name attribute) b. The RADIUS server has to be prepared to choose the EAP method based on what is placed in the User-Name attribute, if anything. There are some limited situations in which this might be useful. but I'm not aware of much deployment experience. The EAP-Start packet is a RADIUS Access-Request packet containing an EAP-Message attribute with a single NUL character. So the length of the EAP-Message attribute is >=3. Might make sense to file an errata to clarify. There is no RADIUS attribute to encapsulate EAPoL, only EAP-Message, which is used to encapsulate EAP. So there is no way to send an EAPoL-Start packet to a RADIUS server within an EAP-Message attribute. If there is a need to convey EAPoL-Start data (e.g. IEEE 802.1X-REV extensions to EAPoL-Start such as NIDs) then you'd need to define a distinct RADIUS attribute to convey that. From: Koehler, Yannick [mailto:yannick.koehler@hp.com] Sent: Friday, November 06, 2009 2:46 PM To: Bernard Aboba; pcalhoun@airespace.com Subject: RFC 3579 Hello, I have read the RFC 3579 and I have some questions and I was hoping to get some answers from you. In the RFC it says that the EAP-Start may be represented by an EAP-Message of length 2 (no data). Yet, the specification of this EAP-Message attribute is defined with a length >= 3 and that, even in the RFC 3579. Also, I do not follow why there is an EAP-Start packet is this the same as EAPOL-Start ? And if not, why sending such an empty packet to a RADIUS server? It seems to me like it waste a round-trip. My understanding of 802.1x nego is something like that: Client sends EAPOL-Start NAS answer EAP-Identity Request Client sends EAP-Identity response NAS sends RADIUS with EAP identity response to RADIUS RADIUS reply NAS forward answer. Client continue exchange. How is the EAP-Start affecting this negotiation and when is it used, and why? Is there more documentation on this packet? -- Yannick Koehler ------=_NextPart_000_0026_01CA62F5.34801800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the normal case you describe below (where the NAS = always starts off with an EAP-Identity Request) there is no need for the NAS to = ever send an EAP-Start packet to the RADIUS server.  This is only useful = if the Identity exchange might be superfluous and the RADIUS server can just = start off with the EAP method Request from the beginning.  There are a very = limited number of situations where this would be useful = because:

 

a.    The NAS has to route the request to = a RADIUS server without a User-Name attribute because there has been no Identity Exchange (e.g. only the Calling-Station-Id might be available to be = placed in the User-Name attribute)

b.    The RADIUS server has to be = prepared to choose the EAP method based on what is placed in the User-Name = attribute, if anything. 

 

There are some limited situations in which this might be = useful… but I’m not aware of much deployment experience. =

 

The EAP-Start packet is a RADIUS Access-Request packet containing an EAP-Message attribute with a single NUL character.  = So the length of the EAP-Message attribute is >=3D3. =

Might make sense to file an errata to clarify. =

 

There is no RADIUS attribute to encapsulate EAPoL, only EAP-Message, which is used to encapsulate EAP.   So there is = no way to send an EAPoL-Start packet to a RADIUS server within an EAP-Message attribute.  If there is a need to convey EAPoL-Start data (e.g. = IEEE 802.1X-REV extensions to EAPoL-Start such as NIDs) then you’d need = to define a distinct RADIUS attribute to convey that.

 

 

 

 

 

From:= Koehler, = Yannick [mailto:yannick.koehler@hp.com]
Sent: Friday, November 06, 2009 2:46 PM
To: Bernard Aboba; pcalhoun@airespace.com
Subject: RFC 3579

 

Hello,

 

  I have read the RFC 3579 and I have some = questions and I was hoping to get some answers from you.  In the RFC it says = that the EAP-Start may be represented by an EAP-Message of length 2 (no = data).  Yet, the specification of this EAP-Message attribute is defined = with a length >=3D 3 and that, even in the RFC 3579.  Also, I do not = follow why there is an EAP-Start packet is this the same as EAPOL-Start ?  And = if not, why sending such an empty packet to a RADIUS server?  It seems = to me like it waste a round-trip.

 

  My understanding of 802.1x nego is something = like that:

 

  Client sends EAPOL-Start

              &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =      NAS answer EAP-Identity Request

  Client sends EAP-Identity = response

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           NAS sends RADIUS with EAP identity response to RADIUS

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           RADIUS reply

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           NAS forward answer.

  Client continue exchange.

 

How is the EAP-Start affecting this negotiation and = when is it used, and why?  Is there more documentation on this = packet?

 

--

Yannick Koehler

------=_NextPart_000_0026_01CA62F5.34801800-- -- to unsubscribe send a 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, 10 Nov 2009 01:02:00 +0000 Message-ID: From: "Bernard Aboba" To: "'radext mailing list'" , Subject: Problem with draft-wu-dime-local-keytran Date: Mon, 9 Nov 2009 17:01:07 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CA615E.3B77FDA0" Thread-Index: AcphoUk7/yU7tggjQrSam6FoJtYnKw== Content-Language: en-us ------=_NextPart_000_0022_01CA615E.3B77FDA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have reviewed draft-wu-dime-local-keytran and found an issue with it. The document utilizes an existing RADIUS attribute (EAP-Key-Name) within a Diameter Grouped AVP. According to the value of the EAP-Key-Type AVP, the type of key being sent (and therefore the EAP-Key-Name) will change. Unfortunately, this usage is incompatible with the definition of the EAP-Key-Name in RFC 4072. RFC 4072 Section 4.1.4 notes: The EAP-Key-Name AVP (Radius Attribute Type 102) is of type OctetString. It contains an opaque key identifier (name) generated by the EAP method. Exactly how this name is used depends on the link layer in question, and is beyond the scope of this document (see [EAPKey] for more discussion). As noted in RFC 5247 Section 5.9, the EAP-Key-Name attribute contains the EAP-Session-Id, and followon standards such as IEEE 802.1X-REV depend on this attribute in order to obtain the EAP-Sesssion-Id utilized in subsequent cryptographic calculations. My concerns about this usage include: a. The inclusion of an existing RADIUS attribute within a Diameter Grouped AVP, thereby changing their meaning. The usage of grouping with existing RADIUS attributes has been discussed and rejected in RADEXT as part of the Extended Attributes work, due to concerns about backward compatibility. This document therefore represents an attempt to get around an objection raised in RADEXT via submission of a document in DIME. b. The updating of RFC 5247 by a non-standards track document in a WG that has no charter to revise EAP standards track documents. c. Conflicts between this document and work items on the RADEXT WG charter requested by IEEE 802.1 and referred to in the appendix of IEEE 802.1X-REV. ------=_NextPart_000_0022_01CA615E.3B77FDA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed draft-wu-dime-local-keytran and = found an issue with it.

 

The document utilizes an existing RADIUS attribute (EAP-Key-Name) within a Diameter Grouped AVP.   According to = the value of the EAP-Key-Type AVP,

the type of key being sent (and therefore the = EAP-Key-Name) will change.

 

Unfortunately, this usage is incompatible with the definition of the EAP-Key-Name in RFC 4072.  RFC 4072 Section 4.1.4 = notes:

 

   The EAP-Key-Name AVP (Radius Attribute Type 102) is of = type

   OctetString.  It contains an opaque key identifier (name) = generated

   by the EAP method.  Exactly how this name is used depends on the = link

   layer in question, and is beyond the scope of this document = (see

   [EAPKey] for more discussion).

 

As noted in RFC 5247 Section 5.9, the EAP-Key-Name = attribute contains the EAP-Session-Id, and followon standards such

as IEEE 802.1X-REV depend on this attribute in = order to obtain the EAP-Sesssion-Id utilized in subsequent = cryptographic

calculations.   

 

My concerns about this usage = include:

 

a.       The inclusion of an existing RADIUS attribute = within a Diameter Grouped AVP, thereby changing their meaning.  The usage of grouping = with existing RADIUS attributes has been discussed and rejected in RADEXT as = part of the Extended Attributes work, due to concerns about backward = compatibility.   This document therefore represents an attempt to get around an = objection raised in RADEXT via submission of a document in DIME.

b.      The updating of RFC 5247 by a non-standards = track document in a WG that has no charter to revise EAP standards track = documents.

c.       Conflicts between this document and work items = on the RADEXT WG charter requested by IEEE 802.1 and referred to in the = appendix of IEEE 802.1X-REV.

 

------=_NextPart_000_0022_01CA615E.3B77FDA0-- -- to unsubscribe send a 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, 03 Nov 2009 15:12:47 +0000 Message-ID: From: "Bernard Aboba" To: "'Alper Yegin'" , Subject: RE: New NAS-Port-Types Date: Tue, 3 Nov 2009 07:12:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpcejNSwMCVVg2vTDy5oD3fMrgHFQAHcbHg Content-Language: en-us IANA considerations for RADIUS are defined in RFC 3575. -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alper Yegin Sent: Tuesday, November 03, 2009 3:39 AM To: radiusext@ops.ietf.org Subject: New NAS-Port-Types Hello, WiMAX Forum is defining new types of NASes that are used for interworking/handover between WiMAX and WiFi, 3GPP, and 3GPP2. So, new NAS-Port-Types are needed. But according to IANA: Sub-registry: Values for RADIUS Attribute 61, NAS-Port-Type Reference: [RFC2865] Registration Procedures: -->> Not defined <<-- What is the procedure to obtain new IANA-assigned NAS port types? Alper -- to 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: Tue, 03 Nov 2009 12:34:43 +0000 Message-ID: <4AF0233E.6060906@deployingradius.com> Date: Tue, 03 Nov 2009 07:34:06 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alper Yegin CC: radiusext@ops.ietf.org Subject: Re: New NAS-Port-Types Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Alper Yegin wrote: > But according to IANA: > > Sub-registry: Values for RADIUS Attribute 61, NAS-Port-Type > Reference: [RFC2865] > Registration Procedures: -->> Not defined <<-- > > What is the procedure to obtain new IANA-assigned NAS port types? Odd. RFC 3575 *should* apply here. http://iana.org/protocols/ Under "RADIUS Attribute Values" says RFC 3575 applies. This, however, is not reflected in any of the following attributes (NAS-Port-Type, Acct-Status-Type, etc.) Some, such as Tunnel-Medium-Type, are marked "IETF Consensus", when the RFC 3575 suggestion of "Designated Expert" should apply, too. RFC 3575 makes it clear that the *only* RADIUS attribute handled that requires IETF Consensus is Service-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: Tue, 03 Nov 2009 11:39:43 +0000 From: "Alper Yegin" To: Subject: New NAS-Port-Types Date: Tue, 3 Nov 2009 13:38:45 +0200 Message-ID: <013d01ca5c7a$36979630$a3c6c290$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcpcejNSwMCVVg2vTDy5oD3fMrgHFQ== Content-Language: en-us Hello, WiMAX Forum is defining new types of NASes that are used for interworking/handover between WiMAX and WiFi, 3GPP, and 3GPP2. So, new NAS-Port-Types are needed. But according to IANA: Sub-registry: Values for RADIUS Attribute 61, NAS-Port-Type Reference: [RFC2865] Registration Procedures: -->> Not defined <<-- What is the procedure to obtain new IANA-assigned NAS port types? Alper -- to unsubscribe send a 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, 02 Nov 2009 16:09:49 +0000 Message-ID: <4AEF0414.5040402@deployingradius.com> Date: Mon, 02 Nov 2009 11:08:52 -0500 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: Issue 323: Use of a Product Name Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > *Issue 323: Use of a Product Name* > Submitter name: Bernard Aboba > Submitter email address: bernard_aboba@hotmail.com > Date first submitted: October 30, 2009 > Reference: > Document: RADSEC, Status-Server, RADIUS over DTLS The latest Status-Server draft does not use the "radsec" term. > Comment type: E > Priority: S > Section: Various > Rationale/Explanation of issue: > > > "RADSEC" is the name of a commercial product. I would suggest that the > term "RADIUS over TLS" or RTLS be used instead to describe the protocol. > > */ > /* > > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: