From owner-radiusext@ops.ietf.org Mon Sep 5 07:33:10 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2334721F8BA8 for ; Mon, 5 Sep 2011 07:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGmcQ-6JVXAz for ; Mon, 5 Sep 2011 07:32:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id EFDA321F8BA9 for ; Mon, 5 Sep 2011 07:32:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R0aCr-000Min-RR for radiusext-data0@psg.com; Mon, 05 Sep 2011 14:31:25 +0000 Received: from [2a01:e0b:1:76:21c:c0ff:fe27:7b54] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R0aCp-000Mib-NW for radiusext@ops.ietf.org; Mon, 05 Sep 2011 14:31:23 +0000 Received: from thor.lan (69-165-133-211.dsl.teksavvy.com [69.165.133.211]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 4BAAD123409F for ; Mon, 5 Sep 2011 16:31:18 +0200 (CEST) Message-ID: <4E64DD35.4030306@deployingradius.com> Date: Mon, 05 Sep 2011 10:31:17 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: 'radext mailing list' Subject: Extensions document X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: The latest rev is here: http://tools.ietf.org/html/draft-ietf-radext-radius-extensions-01 There has been little discussion on this document. There are multiple inter-operable implementations. There are drafts which could benefit from it's format now. There's an individual draft which uses the format. Can we do a WG last call on it? There have been no objections to the document, so it would seem to be "baked". 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 Sep 5 10:38:20 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0C621F8B6D for ; Mon, 5 Sep 2011 10:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.871 X-Spam-Level: X-Spam-Status: No, score=-101.871 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L41Y5MQajPFJ for ; Mon, 5 Sep 2011 10:38:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 4323C21F8B66 for ; Mon, 5 Sep 2011 10:38:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R0d5t-0007hX-Bl for radiusext-data0@psg.com; Mon, 05 Sep 2011 17:36:25 +0000 Received: from blu0-omc1-s14.blu0.hotmail.com ([65.55.116.25]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R0d5o-0007h5-0J for radiusext@ops.ietf.org; Mon, 05 Sep 2011 17:36:20 +0000 Received: from BLU152-W28 ([65.55.116.7]) by blu0-omc1-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Sep 2011 10:36:18 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_7058360d-4922-4c95-abdf-334eaec71edc_" X-Originating-IP: [64.134.138.77] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Remaing issues on draft-ietf-radext-crypto-agility-requirements Date: Mon, 5 Sep 2011 10:36:19 -0700 Importance: Normal In-Reply-To: References: ,, MIME-Version: 1.0 X-OriginalArrivalTime: 05 Sep 2011 17:36:18.0819 (UTC) FILETIME=[51F54D30:01CC6BF2] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_7058360d-4922-4c95-abdf-334eaec71edc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The -07 version of the Crypto-agility document (see http://tools.ietf.org/h= tml/draft-ietf-radext-crypto-agility-requirements-07) addressed=2C some=2C = but not all of the GENART review comments.=20 As document shepard=2C I'd like to get the WG's opinion on the remaining is= sues.=20 Below=2C find the original email from Mary Barnes (the GENART reviewer=2C d= enoted as [MB])=2C and my response=2C relating to the status of the comment= s (denoted as [BA]).=20 To move forward=2C I'd encourage WG participants to provide their opinion o= n how the comments should be resolved.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [MB] - General. I=20 don't think you need references to the RADEXT WG since it a product of=20 that WG - it's listed in the document header and it's obvious in the=20 tools. Folks that aren't familiar with IETF probably don't care what WG produced the document. Subsequent comments below give specific=20 suggestions around this. =20 =20 [BA] The RADEXT WG is mentioned in the document header=2C and in Sections 1.1 and 1.3. =20 I believe that these mentions were made to remind the IESG of the process = that was originally agreed to. During discussion of crypto-agility=2C ther= e seems to have been some confusion on the original charge=2C how it origin= ated and what it covered. I believe this is why the context is provided in= Section 1.1=2C covering where the IETF 66 discussion occurred (e.g. in RADEXT as opposed to OPSAWG=2C AAA WG or DIME) so as to pinpoint = the relevant proceedings and minutes. =20 Since the publication of crypto-agility solutions is ocurring in=20 RADEXT=2C Section 1.3 on publication procedures also mentions the RADEXT=20 WG. =20 =20 =20 [MB] - Introduction=2Csecond paragraph. I don't think this necessarily fits the=20 context of a published RFC. In general=2C the content of WG documents is=20 based on mailing list discussion. And=2C it's usual that an informational document is published to provide the type of information that is noted=20 in that paragraph. So=2C I would think you could just delete that=20 paragraph.=20 =20 =20 [BA] The mailing=20 list discussion is mentioned to describe how the document evolved in respon= se to the original IESG request. Alternatively=2C it would be possible to = cite the RFC 6218=20 IESG note: =20 =20 =20 IESG Note The IESG has concluded that this work is related to IETF work done in the RADEXT WG=2C but this relationship does not prevent publishing. The IESG recommends that the RADEXT WG proceed with the work for an interoperable modern key wrap solution using attributes from the standard space as part of its charter. =20 [MB] - Section 1.3. I don't think the background is necessary. Certainly=2C the motivation for this work is useful introductory information=2C but I=20 think that initial problem statement/objectives could be reworded in=20 present tense in terms of objectives and what this document=20 specifies.=20 [MB] While=2C=20 the author deleted this section=2C they just moved the text to the=20 Introduction rather than rewording the initial problem=20 statement/objectives. [/MB] =20 =20 [BA] I believe the background is there to provide the IESG with context t= hat may no longer be apparent.=20 =20 =20 [MB] - Section 4.3=2C 3rd paragraph. Shouldn't the "can be" be a "MAY be"? -=20 i.e=2C isn't this normative behavior in terms of describing how the=20 requirements for backwards compatibility can be satisfied or in some=20 cases where they can't?=20 =20 =20 [BA] Due to the definition of "MAY" in the Requirements section (not the = same in this document as in RFC 2119!)=2C were a "MAY" to be added here=2C = it would not have an effect=2C since "MAYs" are not used in evaluating subm= issions. I believe this is why the change was not made.=20 =20 =20 [BA] - Section 4.3=2C 4th paragraph. Shouldn't the "can omit" be a "MAY om= it"? =20 =20 =20 [BA] It can be changed=2C but as noted above=2C because of the changed re= quirements language=2C this wouldn't affect the selection process.=20 =20 =20 [MB] - Section 4.3=2C 6th paragraph. Shouldn't the "can be" be a "MAY be"? [BA] It can be changed=2C but as noted above=2C because of the changed requ= irements language=2C this wouldn't affect the selection process.=20 ---------- Forwarded message ---------- From: Romascanu=2C Dan (Dan) Date: Thu=2C Aug 4=2C 2011 at 12:01 PM Subject: FW: new version of draft-ietf-radext-crypto-agility-requirements To: Dave Nelson Cc: Mary Barnes =2C Russ Housley =2C "Sanchez=2C Mauricio (HP Networking)" = =2C jouni.korhonen@nsn.com Hi Dave=2C=20 It looks that there are a few more issues from the GenART review left unadd= ressed in the latest version. Can you please answer based on the list below= =2C either suggest fixes or explain why you believe the issues are not a pr= oblem?=20 Thanks and Regards=2C Dan=20 =20 From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 Sent: Wednesday=2C August 03=2C 2011 8:51 PM To: Russ Housley Cc: Romascanu=2C Dan (Dan) Subject: Re: new version of draft-ietf-radext-crypto-agility-requirements I just reviewed the diff and not all the issues were addressed (as listed = below). I don't recall seeing a response from the author as to why they w= ere not addressed or why the author felt the recommendations were not appli= cable. If you'd like=2C I can send out an official gen-art re-review.=20 Regards=2CMary. The following "Minor issues" were not addressed in the -07: - General. I don't think you need references to the RADEXT WG since it a = product of that WG - it's listed in the document header and it's obvious in= the tools. Folks that aren't familiar with IETF probably don't care what = WG produced the document. Subsequent comments below give specific suggesti= ons around this. - Introduction=2Csecond paragraph. I don't think this necessarily fits the= context of a published RFC. In general=2C the content of WG documents is b= ased on mailing list discussion. And=2C it's usual that an informational d= ocument is published to provide the type of information that is noted in th= at paragraph. So=2C I would think you could just delete that paragraph.=20 - Section 1.3. I don't think the background is necessary. Certainly=2C th= e motivation for this work is useful introductory information=2C but I thin= k that initial problem statement/objectives could be reworded in present = tense in terms of objectives and what this document specifies.=20 [MB] While=2C the author deleted this section=2C they just moved the text t= o the Introduction rather than rewording the initial problem statement/obje= ctives. [/MB] - Section 4.3=2C 3rd paragraph. Shouldn't the "can be" be a "MAY be"? - i= .e=2C isn't this normative behavior in terms of describing how the requirem= ents for backwards compatibility can be satisfied or in some cases where th= ey can't?=20 - Section 4.3=2C 4th paragraph. Shouldn't the "can omit" be a "MAY omit"?= =20 - Section 4.3=2C 6th paragraph. Shouldn't the "can be" be a "MAY be"? =20 On Wed=2C Aug 3=2C 2011 at 11:28 AM=2C Russ Housley = wrote: Mary: Please let me know if the new version resolves you concerns. Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D Discuss (2011-07-11)=20 The Gen-ART Review by Mary Barnes raises quire a few concerns. It deserves a response. The review can be found at: http://wiki.tools.ietf.org/dav/genart/reviews/ draft-ietf-radext-crypto-agility-requirements-06-barnes.txt On Aug 3=2C 2011=2C at 8:11 AM=2C Romascanu=2C Dan (Dan) wrote: > > > Hi Russ=2C > > A new version of draft-ietf-radext-crypto-agility-requirements was > submitted a few days ago. This version should resolve the concerns > expressed in you DISCUSS and the Gen-ART review. Can you check if you > are in the position to clear? > > Thanks and Regards=2C > > Dan > =20 --=20 Regards=2C Dave David B. Nelson Sr. Software Architect Elbrys Networks=2C Inc. www.elbrys.com +1.603.570.2636 = --_7058360d-4922-4c95-abdf-334eaec71edc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The -07 version of the Crypto-agility document (see http://tools.ietf.org/h= tml/draft-ietf-radext-crypto-agility-requirements-07) addressed=2C some=2C = but not all of the GENART review comments.

As document shepard=2C I= 'd like to get the WG's opinion on the remaining issues.

Below=2C f= ind the original email from Mary Barnes (the GENART reviewer=2C denoted as = [MB])=2C and my response=2C relating to the status of the comments (denoted= as [BA]).

To move forward=2C I'd encourage WG participants to prov= ide their opinion on how the comments should be resolved.

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

[MB] - General.  =3BI=20 don't think you need references to the RADEXT WG since it a product of=20 that WG - it's listed in the document header and it's obvious in the=20 tools.  =3BFolks that aren't familiar with IETF probably don't care wha= t WG produced the document.  =3BSubsequent comments below give specific=20 suggestions around this.


[BA] The RADEXT WG is mentioned in the document header=2C and in Sections 1.1 and 1.3. = =3B =3B I believe that these mentions were made to remind the IESG of the process = that was originally agreed to. =3B During discussion of crypto-agility= =2C there seems to have been some confusion on the original charge=2C how i= t originated and what it covered. =3B I believe this is why the context= is provided in Section 1.1=2C covering where the IETF 66 discussion occurr= ed (e.g. in RADEXT as opposed to OPSAWG=2C AAA WG or DIME) so as to pinpoint = the relevant proceedings and minutes. =3B=20 Since the publication of crypto-agility solutions is ocurring in=20 RADEXT=2C Section 1.3 on publication procedures also mentions the RADEXT=20 WG. =3B

 =3B

[MB] - Introduction=2Csecond paragraph. I don't think this necessarily fits the=20 context of a published RFC. In general=2C the content of WG documents is=20 based on mailing list discussion.  =3BAnd=2C it's usual that an informa= tional document is published to provide the type of information that is noted=20 in that paragraph. So=2C I would think you could just delete that=20 paragraph.


[BA] The mailing=20 list discussion is mentioned to describe how the document evolved in respon= se to the original IESG request. =3B Alternatively=2C it would be possi= ble to cite the RFC 6218=20 IESG note:


IESG Note

   The IESG has concluded that this work is related to IETF work done in
   the RADEXT WG=2C but this relationship does not prevent publishing.
   The IESG recommends that the RADEXT WG proceed with the work for an
   interoperable modern key wrap solution using attributes from the
   standard space as part of its charter.

 =3B

[MB] - Section 1.3.  =3BI don't think the background is necessary. Certainly= =2C the motivation for this work is useful introductory information=2C but I=20 think that initial problem statement/objectives could be reworded in=20 present  =3B  =3Btense in terms of objectives and what this documen= t=20 specifies. =3B

[MB] While=2C=20 the author deleted this section=2C they just moved the text to the=20 Introduction rather than rewording the initial problem=20 statement/objectives. [/MB]


[BA] I believe the b= ackground is there to provide the IESG with context that may no longer be a= pparent.

 =3B

[MB] - Section 4.3=2C 3rd paragraph.  =3BShouldn't the "can be" be a "MAY be"= ? -=20 i.e=2C isn't this normative behavior in terms of describing how the=20 requirements for backwards compatibility can be satisfied or in some=20 cases where they can't?


[BA] Due to the defi= nition of "MAY" in the Requirements section (not the same in this document = as in RFC 2119!)=2C were a "MAY" to be added here=2C it would not have an e= ffect=2C since "MAYs" are not used in evaluating submissions. =3B = =3B I believe this is why the change was not made.

 =3B

[BA] - Section 4= .3=2C 4th paragraph.  =3BShouldn't the "can omit" be a "MAY omit"? = =3B


[BA] It can be chang= ed=2C but as noted above=2C because of the changed requirements language=2C= this wouldn't affect the selection process.

 =3B

[MB] - Section 4.3=2C 6th paragraph.  =3BShouldn't the "can be" be a "M= AY be"?

[BA] It can be changed=2C but as noted above=2C because of the changed requ= irements language=2C this wouldn't affect the selection process.


---------- Forwarded message ----= ------
From: Romascanu=2C Dan (Dan)= <=3Bdromasca@ava= ya.com>=3B
Date: Thu=2C Aug 4=2C 2011 at 12:01 PM
Subject: FW: new version of draft= -ietf-radext-crypto-agility-requirements
To: Dave Nelson <=3Bdnelson@elbrys.com>=3B
Cc: Mary Bar= nes <=3Bmary.ietf.barnes@gm= ail.com>=3B=2C Russ Housley <=3Bhousley@vigilsec.com>=3B=2C "Sanchez=2C Mauricio (HP Networking)= " <=3Bmauricio.sanchez@hp.com<= /a>>=3B=2C jouni.korhonen@nsn.c= om


Hi Dave=2C

=  =3B

= It looks that there are a few more issues from the GenART review left unadd= ressed in the latest version. Can you please answer based on the list below= =2C either suggest fixes or explain why you believe the issues are not a pr= oblem?

=  =3B

Thanks and Regards=2C=

 =3B

Dan

=  =3B

 =3B

From: Mary Barnes= [mailto:mary.ietf.barnes@gma= il.com]
Sent: Wednesday=2C August 03=2C 2011 8:51 PM
To: Russ Hous= ley
Cc: Romascanu=2C Dan (Dan)
Subject: Re: new version= of draft-ietf-radext-crypto-agility-requirements

<= /div>

 =3B=

I just reviewed th= e diff and not all the issues were addressed (as listed below).  =3B I = don't recall seeing a response from the author as to why they were not addr= essed or why the author felt the recommendations were not applicable.  = =3BIf you'd like=2C I can send out an official gen-art re-review. =3B

 =3B

Re= gards=2C

Mary.

 =3B

Th= e following "Minor issues" were not addressed in the -07:

=

 =3B=

- = General.  =3BI don't think you need references to the RADEXT WG since i= t a product of that WG - it's listed in the document header and it's obviou= s in the tools.  =3BFolks that aren't familiar with IETF probably don't= care what WG produced the document.  =3BSubsequent comments below give= specific suggestions around this.

&nbs= p=3B

- Introduction=2Csecond paragraph. I don't think this necessarily fits = the context of a published RFC. In general=2C the content of WG documents i= s based on mailing list discussion.  =3BAnd=2C it's usual that an infor= mational document is published to provide the type of information that is n= oted in that paragraph. So=2C I would think you could just delete that para= graph. =3B

&nbs= p=3B

- Section 1.3.  =3BI don't think the background is necessary. Certa= inly=2C the motivation for this work is useful introductory information=2C = but I think that initial problem statement/objectives could be reworded in = present  =3B  =3Btense in terms of objectives and what this documen= t specifies. =3B

[MB] While= =2C the author deleted this section=2C they just moved the text to the Intr= oduction rather than rewording the initial problem statement/objectives. [/= MB]

&nbs= p=3B

- Section 4.3=2C 3rd paragraph.  =3BShouldn't the "can be" be a "MA= Y be"? - i.e=2C isn't this normative behavior in terms of describing how th= e requirements for backwards compatibility can be satisfied or in some case= s where they can't? =3B

&nbs= p=3B

- Section 4.3=2C 4th paragraph.  =3BShouldn't the "can omit" be a "= MAY omit"?  =3B

&nbs= p=3B

- Section 4.3=2C 6th paragraph.  =3BShouldn't the "can be" be a "MA= Y be"?

 =3B

 =3B

 =3B

 =3B

On Wed=2C Aug 3=2C 2011 at 11:28 AM= =2C Russ Housley <=3Bhousley@vigi= lsec.com>=3B wrote:

Mary:

Please let me know if the new version res= olves you concerns.

Russ

=3D =3D =3D =3D =3D =3D =3D =3D =3D = =3D

Discuss (2011-07-11)


 =3BThe Gen-ART Review by Mary Barnes raises quire a few concer= ns.  =3BIt
 =3Bdeserves a response.  =3BThe review can be fo= und at:

 =3B  =3Bhttp://wiki.tools.ietf.org/dav/genart/rev= iews/
 =3B  =3Bdraft-ietf-radext-crypto-agility-requirements-06-barnes.tx= t





On Aug 3=2C 2011=2C = at 8:11 AM=2C Romascanu=2C Dan (Dan) wrote:

>=3B
>=3B
>= =3B Hi Russ=2C
>=3B
>=3B A new version of draft-ietf-radext-crypt= o-agility-requirements was
>=3B submitted a few days ago. This version should resolve the concerns>=3B expressed in you DISCUSS and the Gen-ART review. Can you check if = you
>=3B are in the position to clear?
>=3B
>=3B Thanks and = Regards=2C
>=3B
>=3B Dan
>=3B


<= p class=3D"ecxMsoNormal" style=3D"margin-left:.5in"> =3B<= /p>



--

Regar= ds=2C

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks=2C Inc.www.elbrys.com
= +1.603.570.2636
= --_7058360d-4922-4c95-abdf-334eaec71edc_-- -- to unsubscribe send a message to radiusext-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 Sep 5 11:24:32 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421C721F8AFC for ; Mon, 5 Sep 2011 11:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAncaxaA4oVi for ; Mon, 5 Sep 2011 11:24:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 8A62021F8AF0 for ; Mon, 5 Sep 2011 11:24:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R0dpy-0009sk-BR for radiusext-data0@psg.com; Mon, 05 Sep 2011 18:24:02 +0000 Received: from mail.mancalanetworks.com ([46.105.178.48]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R0dpv-0009sR-G8 for radiusext@ops.ietf.org; Mon, 05 Sep 2011 18:23:59 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mancalanetworks.com (Postfix) with ESMTP id F01221E2876C for ; Mon, 5 Sep 2011 20:27:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at mancalanetworks.com Received: from mail.mancalanetworks.com ([127.0.0.1]) by localhost (mail.mancalanetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxbdKw3MkudP for ; Mon, 5 Sep 2011 20:27:34 +0200 (CEST) Received: from [192.168.0.13] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by mail.mancalanetworks.com (Postfix) with ESMTPSA id BF3461E28768 for ; Mon, 5 Sep 2011 20:27:33 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) Subject: Extended attrs doc From: Arran Cudbard-Bell In-Reply-To: <4E64E451.1070003@deployingradius.com> Date: Mon, 5 Sep 2011 20:23:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8539FDCA-232D-44B2-8620-509EAA39581C@mancalanetworks.com> References: <4E64E451.1070003@deployingradius.com> To: radiusext@ops.ietf.org X-Mailer: Apple Mail (2.1244.3) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: > Does anyone have feedback? >=20 > My $0.02 is that the format of the "long" attributes is very awkward. > It means that there are *two* format changes. The "flags" octet has 7 > unused bits, which doesn't seem useful. And the discussion around the > whole "flags" thing seems awkward. I agree. Packet space is a finite resource, and it seems inefficient to = essentially waste an additional two octets per concatenated value, = unless someone can come up with some additional uses for the flags = field... > The rules for encoding it are: >=20 > - take attribute data (> 253 octets) > - fill up the first attribute as normal, until "length =3D 255" > - take the rest of the data > - chop it into fragments of 253 octets > - pack it into "Fragment-Data" (type =3D 255, length =3D 255) > - last fragment has length <=3D 255 > OR last fragment has length =3D=3D 255, AND the next attribute > is not Fragment-Data >=20 > The rules for decoding it are: >=20 > - For each attribute in the packet > - if length is 255 AND the next attribute is Fragment-Data (255) > THEN the data from the next attribute is concatenated to this one >=20 Seems sensible to me... > There are two issues with this proposal: >=20 > 1) vendors have "self allocated" attribute 255. This proposal is > compatible with that, as Fragment-Data is define only when the > previous attribute has Length=3D=3D255. This should be rare. It goes directly against RFC 2865 too. They've broken the existing = standard, and so forwards compatibility of their implementations is not = guaranteed. >=20 > 2) existing proxies re-ordering attributes. > RFC 2865 says that implementations MUST NOT re-order attributes > of the same type. But they CAN re-order attributes of differing > type. So there's a chance that proxies which don't understand > Fragment-Data will re-order them, breaking the packet entirely... >=20 > I'm not aware of many (if any) proxies that do (2). Most are more > stringent than the requirements of RFC 2865, and don't re-order > attributes of differing type. The only time I can see this happening is when filtering a request. But = as the attributes are usually processed in order, and copied in order; = this should be a non issue... >=20 > Thoughts? >=20 No worse than the original implementation of VSAs :) -Arran -- to unsubscribe send a message to radiusext-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 Sep 6 05:32:07 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD0821F86EA for ; Tue, 6 Sep 2011 05:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.388 X-Spam-Level: X-Spam-Status: No, score=-103.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTWpfc770Rsd for ; Tue, 6 Sep 2011 05:32:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADC921F86C7 for ; Tue, 6 Sep 2011 05:32:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R0uoD-000OST-VF for radiusext-data0@psg.com; Tue, 06 Sep 2011 12:31:21 +0000 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100]) by psg.com with esmtps (TLSv1:SEED-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R0uo6-000ORN-HN for radiusext@ops.ietf.org; Tue, 06 Sep 2011 12:31:14 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOoRZk6HCzI1/2dsb2JhbABCgk2lVXiBRgEBAQEDEgoRAz4EFwIBCA0BBw0GDAsBBgFFEQEBBAESCBMHpgICnB6GCmAEmFuLYg X-IronPort-AV: E=Sophos;i="4.68,338,1312171200"; d="scan'208,217";a="301825718" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Sep 2011 08:30:56 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Sep 2011 08:22:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6C90.D27844F8" Subject: RE: Remaing issues on draft-ietf-radext-crypto-agility-requirements Date: Tue, 6 Sep 2011 14:30:54 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Remaing issues on draft-ietf-radext-crypto-agility-requirements Thread-Index: AcxsiEQKEM8K3CigSBmR2bp2yOPx0wAB9Llg References: From: "Romascanu, Dan (Dan)" To: "Dave Nelson" , Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6C90.D27844F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 =20 From: Dave Nelson [mailto:dnelson@elbrys.com]=20 =20 [MB] - Introduction,second paragraph. I don't think this necessarily fits the context of a published RFC. In general, the content of WG documents is based on mailing list discussion. And, it's usual that an informational document is published to provide the type of information that is noted in that paragraph. So, I would think you could just delete that paragraph.=20 [BA] The mailing list discussion is mentioned to describe how the document evolved in response to the original IESG request. Alternatively, it would be possible to cite the RFC 6218 IESG note: IESG Note =20 The IESG has concluded that this work is related to IETF work done in the RADEXT WG, but this relationship does not prevent publishing. The IESG recommends that the RADEXT WG proceed with the work for an interoperable modern key wrap solution using attributes from the standard space as part of its charter. [DN] I guess either approach would work. While there are clearly established styles for RFCs, I think that some of the "rules" can be relaxed for an "in-house" document, such as a requirements document. =20 [[DR]] Actually I do not think that the IESG note approach would work. This work is not only 'related to IETF work done in the RADEXT WG' but is actually a result of chartered work in the WG.=20 =20 Maybe the way to go is to talk with Russ and see whether he stands behind the first three comments in the GenART review. Russ knows well the history and the background of this work, and he may have an opinion whether including the history of the document and the WG road information is useful.=20 =20 Regards, =20 Dan =20 ------_=_NextPart_001_01CC6C90.D27844F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

 

From:= = Dave Nelson [mailto:dnelson@elbrys.com] =

 

[MB] - Introduction,second paragraph. I don't = think this necessarily fits the context of a published RFC. In general, = the content of WG documents is based on mailing list discussion. =  And, it's usual that an informational document is published to = provide the type of information that is noted in that paragraph. So, I = would think you could just delete that paragraph.

[BA] The mailing list discussion is mentioned = to describe how the document evolved in response to the original IESG = request.  Alternatively, it would be possible to cite the RFC 6218 = IESG note:

IESG =
Note
 
   The =
IESG has concluded that this work is related to IETF work done =
in
   the RADEXT WG, but this =
relationship does not prevent =
publishing.
   The IESG recommends that =
the RADEXT WG proceed with the work for =
an
   interoperable modern key wrap =
solution using attributes from the
   =
standard space as part of its =
charter.

[DN] I guess either approach would = work.  While there are clearly established styles for RFCs, I think = that some of the "rules" can be relaxed for an = "in-house" document, such as a requirements = document.

 

[[DR]] Actually I do not think that the IESG note approach would = work. This work is not only ‘related to IETF work done in the = RADEXT WG’ but is actually a result of chartered work in the WG. =

 

Maybe the way to go is to talk with Russ and see whether he stands = behind the first three comments in the GenART review. Russ knows well = the history and the background of this work, and he may have an opinion = whether including the history of the document and the WG road = information is useful.

 

Regards,

 

Dan

 

------_=_NextPart_001_01CC6C90.D27844F8-- -- to unsubscribe send a message to radiusext-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 Sep 6 06:25:29 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F33B21F8745 for ; Tue, 6 Sep 2011 06:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.387 X-Spam-Level: X-Spam-Status: No, score=-103.387 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkxJxb6LPnd9 for ; Tue, 6 Sep 2011 06:25:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECAC21F871C for ; Tue, 6 Sep 2011 06:25:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R0vd8-0003Fo-4I for radiusext-data0@psg.com; Tue, 06 Sep 2011 13:23:58 +0000 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100]) by psg.com with esmtps (TLSv1:SEED-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R0vd4-0003F6-BX for radiusext@ops.ietf.org; Tue, 06 Sep 2011 13:23:54 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYAAF8dZk7GmAcF/2dsb2JhbAA/A4JNlgyPKHiBRgEBAQEDEgoRAxkwEAIBCA0BAwQBAQsGDAsBBgFFCQgBAQQTCBqlbAKcLINegixgBJhbi2I X-IronPort-AV: E=Sophos;i="4.68,338,1312171200"; d="scan'208,217";a="301837229" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Sep 2011 09:23:51 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Sep 2011 09:19:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6C98.376CC508" Subject: RE: Remaing issues on draft-ietf-radext-crypto-agility-requirements Date: Tue, 6 Sep 2011 15:23:49 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Remaing issues on draft-ietf-radext-crypto-agility-requirements Thread-Index: Acxsl+UJd3ftAttlTq+BQ4BmOIopKwAACh3g References: From: "Romascanu, Dan (Dan)" To: "Dave Nelson" Cc: Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6C98.376CC508 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I suggest that Bernard (as document shepherd) sends a version of his query mail to Russ truncated to the first three issues.=20 =20 Regards, =20 Dan =20 =20 =20 From: Dave Nelson [mailto:dnelson@elbrys.com]=20 Sent: Tuesday, September 06, 2011 4:21 PM To: Romascanu, Dan (Dan) Cc: radiusext@ops.ietf.org Subject: Re: Remaing issues on draft-ietf-radext-crypto-agility-requirements =20 On Tue, Sep 6, 2011 at 8:30 AM, Romascanu, Dan (Dan) wrote: =20 Maybe the way to go is to talk with Russ and see whether he stands behind the first three comments in the GenART review. Russ knows well the history and the background of this work, and he may have an opinion whether including the history of the document and the WG road information is useful. =20 That sounds like a good idea. Who do you suggest should approach Russ? =20 Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 ------_=_NextPart_001_01CC6C98.376CC508 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I suggest that Bernard (as document shepherd) sends a version of his = query mail to Russ truncated to the first three issues. =

 

Regards,

 

Dan

 

 

 

From:= = Dave Nelson [mailto:dnelson@elbrys.com]
Sent: Tuesday, = September 06, 2011 4:21 PM
To: Romascanu, Dan = (Dan)
Cc: radiusext@ops.ietf.org
Subject: Re: = Remaing issues on = draft-ietf-radext-crypto-agility-requirements

=

 

On = Tue, Sep 6, 2011 at 8:30 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> = wrote:

 

Maybe the way to go is to talk = with Russ and see whether he stands behind the first three comments in = the GenART review. Russ knows well the history and the background of = this work, and he may have an opinion whether including the history of = the document and the WG road information is = useful.

=

 

That sounds like a good idea.   Who do you = suggest should approach Russ?

 

Regards,

Dave

David B. Nelson
Sr. = Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

------_=_NextPart_001_01CC6C98.376CC508-- -- to unsubscribe send a message to radiusext-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 Sep 8 02:24:27 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E628321F8B03 for ; Thu, 8 Sep 2011 02:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6J5YASousWlY for ; Thu, 8 Sep 2011 02:24:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 580C421F8AFC for ; Thu, 8 Sep 2011 02:24:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R1alr-000125-Jg for radiusext-data0@psg.com; Thu, 08 Sep 2011 09:19:43 +0000 Received: from mail-gx0-f182.google.com ([209.85.161.182]) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R1aln-00011s-VG for radiusext@ops.ietf.org; Thu, 08 Sep 2011 09:19:40 +0000 Received: by gxk28 with SMTP id 28so1071169gxk.41 for ; Thu, 08 Sep 2011 02:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=HVSnNRrOcLy1WKuUaiaLzDiFvZ78P2T1Q7vkVQNWhyQ=; b=mJvbgdjMOyvLbjGIPZJ2aCcg8HMipIrO2HrzhOtrNlUicWiDj7zLnT2klusWiT7dSB jauFZVRb7XBVGYH28yk5QwRFWc/hbz679WpFCABXhknXA2Ewkx6842vjBOTZuqFiuQAo j/7qGN6+Ti4sugr3LOMwrxOc/nESb8TKGv7WI= Received: by 10.236.178.39 with SMTP id e27mr2459243yhm.99.1315473578881; Thu, 08 Sep 2011 02:19:38 -0700 (PDT) Received: from [10.255.131.1] ([192.100.123.77]) by mx.google.com with ESMTPS id l69sm2912264yhj.21.2011.09.08.02.19.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Sep 2011 02:19:38 -0700 (PDT) Subject: WGLC for draft-ietf-radext-radius-extensions-01 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4E64DD35.4030306@deployingradius.com> Date: Thu, 8 Sep 2011 12:19:33 +0300 Cc: "Mauricio (HP Networking) Sanchez" , Alan DeKok , jouni korhonen Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E64DD35.4030306@deployingradius.com> To: radext mailing list X-Mailer: Apple Mail (2.1084) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Folks, This mail starts two weeks WGLC for = draft-ietf-radext-radius-extensions-01. Send your comments to the list = and also record them to the issue tracker. The WGLC ends 22nd September, = 23:59 CET+1. The authors are encouraged to recruit reviewers for the I-D. Cheers, Jouni & Mauricio= -- to unsubscribe send a message to radiusext-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 Sep 8 12:13:49 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D4621F8B92 for ; Thu, 8 Sep 2011 12:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xi7fterKA4Lv for ; Thu, 8 Sep 2011 12:13:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFCD21F8B27 for ; Thu, 8 Sep 2011 12:13:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R1k1l-00084d-Ar for radiusext-data0@psg.com; Thu, 08 Sep 2011 19:12:45 +0000 Received: from mail-bw0-f52.google.com ([209.85.214.52]) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R1k1g-00084H-A3 for radiusext@ops.ietf.org; Thu, 08 Sep 2011 19:12:40 +0000 Received: by bkbzs2 with SMTP id zs2so1370892bkb.11 for ; Thu, 08 Sep 2011 12:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=2YiZmFJ6px9UbQiddV976z0mq77W0hNFAOwEzcMP5kk=; b=V4TfQFnpVoBUvWU7tgmV6te+MTZ8rIZqHPqZKi4FOKXMlv2lnGUQXDNrl0hBhKfLgB swLzhrO69zZiNQnEwfTMKN8ysI/XuEEYjWnz5rtlYArP1hsuYvrfrivIDS8PJD3oGFe9 ifTa8FXUU+4+7yAS2RoEemk7w88pUh+q3guwA= Received: by 10.204.132.78 with SMTP id a14mr856366bkt.195.1315509157133; Thu, 08 Sep 2011 12:12:37 -0700 (PDT) Received: from a83-245-214-61.elisa-laajakaista.fi (a83-245-214-61.elisa-laajakaista.fi [83.245.214.61]) by mx.google.com with ESMTPS id zw12sm1171269bkb.10.2011.09.08.12.12.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Sep 2011 12:12:36 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: WGLC for draft-ietf-radext-radsec-09 Date: Thu, 8 Sep 2011 22:12:34 +0300 Message-Id: <5237C2DA-4D15-41AD-80C4-F6E12CCB1CFE@gmail.com> Cc: "Mauricio (HP Networking) Sanchez" , jouni korhonen To: radext mailing list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Folks, This mail starts two weeks WGLC for draft-ietf-radext-radsec-09. Send = your comments to the list and also record them to the issue tracker. The = WGLC ends 22nd September, 23:59 CET+1. The authors are encouraged to recruit reviewers for the I-D. Cheers, Jouni & Mauricio= -- to unsubscribe send a message to radiusext-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 Sep 9 23:24:57 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8768F21F8715 for ; Fri, 9 Sep 2011 23:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpAnc9Te8PQb for ; Fri, 9 Sep 2011 23:24:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9011421F86E0 for ; Fri, 9 Sep 2011 23:24:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R2Guz-000414-2a for radiusext-data0@psg.com; Sat, 10 Sep 2011 06:19:57 +0000 Received: from blu0-omc1-s38.blu0.hotmail.com ([65.55.116.49]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R2GrI-0003v5-K7 for radiusext@ops.ietf.org; Sat, 10 Sep 2011 06:16:08 +0000 Received: from BLU152-W25 ([65.55.116.7]) by blu0-omc1-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Sep 2011 23:16:03 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_8b928907-2eee-4bcf-9c2a-97b629d002c0_" X-Originating-IP: [70.88.131.169] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Re: i18n and RADIUS Date: Fri, 9 Sep 2011 23:16:03 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 10 Sep 2011 06:16:03.0730 (UTC) FILETIME=[1E55B720:01CC6F81] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_8b928907-2eee-4bcf-9c2a-97b629d002c0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It has occurred to me that the most fundamental mistake of RFC 4282 is the = assertion that there is a single NAI encoding for every protocol. In reality=2C the protocol in which the NAI is encoded makes the decision a= bout the encoding. Where the protocol is 8-bit clean and requires UTF-8 (b= oth EAP and RADIUS fall in this category)=2C the encoding described in RF= C 4282 does not apply. EAP and RADIUS implementations can and do carry UT= F-8 natively. The only time a conversion from a U label to an A label woul= d be required would be for a DNS lookup such as what is envisaged in the Dy= namic Discovery document.=20 That said=2C issues of internationalization could come up within specific E= AP methods. However=2C not all methods utilize the same internationaliza= tion mechanisms. For example=2C none of the authentication methods defined= in RFC 3748 specify the use of SASLPREP=2C and as far as I am aware=2C no = implementations of those methods (e.g. EAP-MD5) use it. There is substant= ial variety in EAP methods defined elsewhere (compare say=2C EAP-EKE with E= AP-TLS and EAP-MS-CHAP=2C for example). =20 Given this=2C the following sentence in RFC 3748 Section 5 (quoted by PRECI= S) is not just inappropriate (the choice should be left to the method spec= )=2C but actually misleading because the methods defined in RFC 3748 do not= in fact use SASLPREP.=20 EAP methods MAY support authentication based on shared secrets. If the shared secret is a passphrase entered by the user=2C implementations MAY support entering passphrases with non-ASCII characters. In this case=2C the input should be processed using an appropriate stringprep [RFC3454] profile=2C and encoded in octets using UTF-8 encoding [RFC2279]. A preliminary version of a possible stringprep profile is described in [SASLPREP]. =20 Alan DeKok said: As discussed at the last IETF=2C RFC 4282 has some problems. My draft (expired) describes the issues=2C and proposes a way to address them. The Precis working group is looking at i18n issues across a wide variety of protocols. The framework document applies to RADIUS and to EAP=2C though neither is explicitly mentioned: http://tools.ietf.org/id/draft-blanchet-precis-framework-02.txt I'd recommend reading Section 3=2C which defines stringprep "classes" for names and secrets. Section 10 deals with "confusable" strings=2C and says that applications need to find a way to deal with them. It looks like the work in Precis will allow RADIUS and EAP to continue with their current way of dealing with names and passwords. Since neither RADIUS nor EAP show strings to users=2C "confusable" strings can be avoided in the protocol transport. Alan DeKok. = --_8b928907-2eee-4bcf-9c2a-97b629d002c0_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It has occurred to me that the most fundamental mistake of RFC 4282 is= the assertion that there is a single NAI encoding for every protocol.

In reality=2C the protocol in which the NAI is encoded= makes the decision about the encoding.  =3BWhere the protocol is 8-bit= clean and requires UTF-8 (both EAP and RADIUS fall in this category)=2C &n= bsp=3B the encoding described in RFC 4282 does not apply.  =3B EAP and = RADIUS implementations can and do carry UTF-8 natively.  =3BThe only ti= me a conversion from a U label to an A label would be required would be for= a DNS lookup such as what is envisaged in the Dynamic Discovery document.&= nbsp=3B

That said=2C issues of internationalizatio= n could come up within specific EAP methods.  =3BHowever=2C  =3B no= t all methods utilize the same internationalization mechanisms.  =3BFor= example=2C none of the authentication methods defined in RFC 3748 specify = the use of SASLPREP=2C and as far as I am aware=2C no implementations of th= ose methods (e.g. EAP-MD5) use it.  =3B There is =3Bsubstantial var= iety in EAP methods defined elsewhere (compare say=2C EAP-EKE with EAP-TLS = and EAP-MS-CHAP=2C for example).  =3B

Given th= is=2C the following sentence in RFC 3748 Section 5 (quoted by PRECIS)  = =3Bis not just inappropriate (the choice should be left to the method spec)= =2C but actually misleading because the methods defined in RFC 3748 do not = in fact use SASLPREP. =3B

   EAP =
methods MAY support authentication based on shared secrets.  If
   the shared secret is a passphrase entered by the user=2C
   implementations MAY support entering passphrases with non-ASCII
   characters.  In this case=2C the input should be processed using an
   appropriate stringprep [RFC3454] profile=2C and encoded in octets using
   UTF-8 encoding [RFC2279].  A preliminary version of a possible
   stringprep profile is described in [SASLPREP].









 =3B


Alan DeKok said:<= /div>

  As discussed at the l=
ast IETF=2C RFC 4282 has some problems.  My draft
(expired) describes the issues=2C and proposes a way to address them.

  The Precis working group is looking at i18n issues across a wide
variety of protocols.  The framework document applies to RADIUS and to
EAP=2C though neither is explicitly mentioned:


http://tools.ietf.org/id/draft-blanchet-precis-framework-=
02.txt

  I'd recommend reading Section 3=2C which defines stringprep "classes"
for names and secrets.  Section 10 deals with "confusable" strings=2C and
says that applications need to find a way to deal with them.

  It looks like the work in Precis will allow RADIUS and EAP to continue
with their current way of dealing with names and passwords.  Since
neither RADIUS nor EAP show strings to users=2C "confusable" strings can
be avoided in the protocol transport.

  Alan DeKok.
= --_8b928907-2eee-4bcf-9c2a-97b629d002c0_-- -- to unsubscribe send a message to radiusext-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 Sep 10 06:56:42 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D07121F84CF for ; Sat, 10 Sep 2011 06:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liW+e-qjr71P for ; Sat, 10 Sep 2011 06:56:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4F121F84CC for ; Sat, 10 Sep 2011 06:56:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R2O1S-000Lek-SO for radiusext-data0@psg.com; Sat, 10 Sep 2011 13:55:08 +0000 Received: from [2a01:e0b:1:76:21c:c0ff:fe27:7b54] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R2O1M-000Lds-MO for radiusext@ops.ietf.org; Sat, 10 Sep 2011 13:55:01 +0000 Message-ID: <4E6B6C2F.3010807@deployingradius.com> Date: Sat, 10 Sep 2011 15:54:55 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: i18n and RADIUS References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > It has occurred to me that the most fundamental mistake of RFC 4282 is > the assertion that there is a single NAI encoding for every protocol. I would be wary of defining different encodings for different protocols. > In reality, the protocol in which the NAI is encoded makes the decision > about the encoding. Where the protocol is 8-bit clean and requires > UTF-8 (both EAP and RADIUS fall in this category), the encoding > described in RFC 4282 does not apply. I agree completely. That's been my push for ~4 years. > EAP and RADIUS implementations > can and do carry UTF-8 natively. The only time a conversion from a U > label to an A label would be required would be for a DNS lookup such as > what is envisaged in the Dynamic Discovery document. Yes. > That said, issues of internationalization could come up within specific > EAP methods. However, not all methods utilize the same > internationalization mechanisms. For example, none of the > authentication methods defined in RFC 3748 specify the use of SASLPREP, > and as far as I am aware, no implementations of those methods (e.g. > EAP-MD5) use it. There is substantial variety in EAP methods defined > elsewhere (compare say, EAP-EKE with EAP-TLS and EAP-MS-CHAP, for > example). I'm not aware of any implementations which use SASLPREP for EAP. Talking to the various authors (open source && commercial) leads me to conclude that they treat the user identifier as an opaque string. If the local encoding is UTF-8, that is used. If it's something else, that is used. > Given this, the following sentence in RFC 3748 Section 5 (quoted by > PRECIS) is not just inappropriate (the choice should be left to the > method spec), but actually misleading because the methods defined in RFC > 3748 do not in fact use SASLPREP. > > EAP methods MAY support authentication based on shared secrets. If > the shared secret is a passphrase entered by the user, > implementations MAY support entering passphrases with non-ASCII > characters. In this case, the input should be processed using an > appropriate stringprep [RFC3454] profile, and encoded in octets using > UTF-8 encoding [RFC2279]. A preliminary version of a possible > stringprep profile is described in [SASLPREP]. The existing methods don't do that. But I can see it being useful. e.g. when a local 16-bit character encoding is used, that MUST NOT go on the wire. It has to be converted (somehow) into a form that third parties can recognize. I've refreshed my 4282bis document: http://www.ietf.org/id/draft-dekok-radext-nai-01.txt The only changes are dates && idnits fixes. So the text might not be perfect. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Sep 10 10:50:13 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8AF21F8A66 for ; Sat, 10 Sep 2011 10:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.381 X-Spam-Level: X-Spam-Status: No, score=-102.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNUYy6KHkaWC for ; Sat, 10 Sep 2011 10:50:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE9F21F8A62 for ; Sat, 10 Sep 2011 10:50:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R2Rfs-0009VL-OX for radiusext-data0@psg.com; Sat, 10 Sep 2011 17:49:04 +0000 Received: from blu0-omc2-s19.blu0.hotmail.com ([65.55.111.94]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R2Rfn-0009V7-9H for radiusext@ops.ietf.org; Sat, 10 Sep 2011 17:48:59 +0000 Received: from BLU152-W26 ([65.55.111.72]) by blu0-omc2-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Sep 2011 10:48:58 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_7340695c-aa38-4b88-836b-cdb36cc9c938_" X-Originating-IP: [70.88.131.169] From: Bernard Aboba To: Alan DeKok CC: "radiusext@ops.ietf.org" Subject: RE: i18n and RADIUS Date: Sat, 10 Sep 2011 10:48:57 -0700 Importance: Normal In-Reply-To: <4E6B6C2F.3010807@deployingradius.com> References: ,<4E6B6C2F.3010807@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 10 Sep 2011 17:48:58.0151 (UTC) FILETIME=[EA9EEB70:01CC6FE1] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_7340695c-aa38-4b88-836b-cdb36cc9c938_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I would be wary of defining different encodings for different protocols= . [BA] Luckily=2C I believe that all protocols which can carry an NAI are 8= -bit clean and support UTF-8=2C so I think that in practice I am not aware= of any network access protocol (including Diameter) that requires punycode= encoding of the NAI. However=2C if such a protocol were to exist=2C it wo= uld have no bearing on the encoding within EAP/RADIUS. That is an importan= t point to make=2C because RFC 4282 proponents often point to the encoding = of an email address in say=2C EAI=2C as somehow implyiing that the same enc= oding needs to be enforced in EAP and RADIUS. That argument is fundamental= ly unsound=2C and needs to be laid out clearly. The IDNA documents make mu= ch the same point=2C by stating that the encoding of a domain name in DNS h= as no bearing on how it is to be encoded in other protocols. But somehow t= his message has not been clearly stated to apply to network access protocol= s which are 8-bit clean. =20 > > In reality=2C the protocol in which the NAI is encoded makes the decisi= on > > about the encoding. Where the protocol is 8-bit clean and requires > > UTF-8 (both EAP and RADIUS fall in this category)=2C the encoding > > described in RFC 4282 does not apply. >=20 > I agree completely. That's been my push for ~4 years. [BA] I believe t= hat this argument is already laid out clearly in RFC 2865=2C 3748 and other= related RFCs=2C and has been implemented very widely. So this is not just= an "opinion"=2C it is a reality which aligns with the RFCs. This unique c= onvergence of reality and standards should be celebrated=2C not punished :( > I'm not aware of any implementations which use SASLPREP for EAP. [BA] That is certainly true of implementations of the EAP methods described= in RFC 3748 (e.g. Identity=2C EAP-MD5=2C OTP=2C etc.). However EAP-EKE (RF= C 6124) does reference SASLPREP (see Section 5.1): This protocol support= s internationalized=2C non-ASCII passwords. The input password string SHOULD be processed according to the rules of the [RFC4013] profile of [RFC3454]. A password SHOULD be considered a "stored string" per [RFC3454]=2C and unassigned code points are therefore prohibited. The output is the binary representation of the processed UTF-8 [RFC3629] character string. Prohibited output and unassigned code points encountered in SASLprep preprocessing SHOULD cause a preprocessing failure and the output SHOULD NOT be used. > Talki= ng to the various authors (open source && commercial) leads me to > conclude that they treat the user identifier as an opaque string. If > the local encoding is UTF-8=2C that is used. If it's something else=2C t= hat > is used. [BA] I believe this is true of the Identity-Response=2C which is= of the most relevance to RADIUS (since it is placed into the User-Name fie= ld as noted in RFC 3579). Not sure how individual EAP methods handle this= =2C but that doesn't affect RADIUS.=20 > The existing methods don't do that. But I can see it being useful. > e.g. when a local 16-bit character encoding is used=2C that MUST NOT go o= n > the wire. It has to be converted (somehow) into a form that third > parties can recognize. [BA] The EAP methods defined in RFC 3748 do not do that. However=2C there = are some EAP methods (such as EAP-EKE) that do. =20 > I've refreshed my 4282bis document: >=20 > http://www.ietf.org/id/draft-dekok-radext-nai-01.txt >=20 > The only changes are dates && idnits fixes. So the text might not be > perfect. [BA] Rather than doing an RFC 4282bis=2C I am wondering whether it might ma= ke sense to recast this as "Internationalization in RADIUS". Since RFC 42= 82 is fundamentally wrong in its approach to internationalization=2C it may= be better to focus on explaining why it does not apply in a document that = focuses on RADIUS. = --_7340695c-aa38-4b88-836b-cdb36cc9c938_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B I would be wary of defining different encodings for different = protocols.
 =3B
[BA] Luckily=2C =3BI believe that all protoco= ls which can carry an NAI are 8-bit clean and support UTF-8=2C so I think t= hat in practice I am =3B not aware of any network access =3Bprotoco= l (including Diameter) that requires punycode encoding of the NAI.
&nbs= p=3B
However=2C if such a protocol were to exist=2C it would have no bea= ring on the encoding within EAP/RADIUS. =3B
 =3B
That is an i= mportant point to make=2C because RFC 4282 proponents often point to the en= coding of an email address in say=2C EAI=2C as somehow implyiing that the s= ame encoding needs to be enforced in EAP and RADIUS. =3B That argument = is fundamentally unsound=2C and needs to be laid out clearly. =3B The I= DNA documents make much the same point=2C by stating that the encoding of a= domain name in DNS has no bearing on how it is to be encoded in other prot= ocols. =3B But somehow this message has not been clearly stated to appl= y to network access protocols which are 8-bit clean. =3B
 =3B>=3B >=3B In reality=2C the protocol in which the NAI is encoded make= s the decision
>=3B >=3B about the encoding. Where the protocol is = 8-bit clean and requires
>=3B >=3B UTF-8 (both EAP and RADIUS fall i= n this category)=2C the encoding
>=3B >=3B described in RFC 4282 d= oes not apply.
>=3B
>=3B I agree completely. That's been my p= ush for ~4 years.
 =3B
[BA] I believe that this argument is alrea= dy laid out clearly in RFC 2865=2C 3748 and other related RFCs=2C and has b= een implemented very widely. =3B So this is not just an "opinion"=2C it= is a reality which aligns with the RFCs. =3B This unique convergence o= f reality and standards should be celebrated=2C not punished :(

>= =3B I'm not aware of any implementations which use SASLPREP for EAP.
<= BR>[BA] That is certainly true of implementations of the EAP methods descri= bed in RFC 3748 (e.g. Identity=2C EAP-MD5=2C OTP=2C etc.).
 =3B
H= owever EAP-EKE (RFC 6124) does reference SASLPREP (see Section 5.1):
&nb= sp=3B
   This protocol supports internationalized=
=2C non-ASCII passwords.  The
   input password string SHOULD be processed according to the rules of
   the [RFC4013] profile of [=
RFC3454].  A password SHOULD be considered
   a "stored string" per [RFC3454]=2C and un=
assigned code points are
   therefore prohibited.  The output is the binary representation of the
   processed UTF-8 [RFC3629] character st=
ring.  Prohibited output and
   unassigned code points encountered in SASLprep preprocessing SHOULD
   cause a preprocessing failure and the output SHOULD NOT be used.
&n= bsp=3B
>=3B Talking to the various authors (open source &=3B&=3B= commercial) leads me to
>=3B conclude that they treat the user identi= fier as an opaque string. If
>=3B the local encoding is UTF-8=2C that= is used. If it's something else=2C that
>=3B is used.
 =3B[BA] I believe this is true of the Identity-Response=2C which is of the mo= st relevance to RADIUS (since it is placed into the User-Name field as note= d in RFC 3579). =3B
 =3B
Not sure how individual EAP methods= handle this=2C but that doesn't affect RADIUS.

>=3B The existi= ng methods don't do that. But I can see it being useful.
>=3B e.g. wh= en a local 16-bit character encoding is used=2C that MUST NOT go on
>= =3B the wire. It has to be converted (somehow) into a form that third
&= gt=3B parties can recognize.

[BA] The EAP methods defined in RFC 374= 8 do not do that. =3B However=2C there are some EAP methods (such as EA= P-EKE) that do.
 =3B

>=3B I've refreshed my 4282bis docu= ment:
>=3B
>=3B http://www.ietf.org/id/draft-dekok-radext-nai-01= .txt
>=3B
>=3B The only changes are dates &=3B&=3B idnit= s fixes. So the text might not be
>=3B perfect.

[BA] Rather th= an doing an RFC 4282bis=2C I am wondering whether it might make sense to re= cast this as "Internationalization in RADIUS". =3B
 =3B
Sinc= e RFC 4282 is fundamentally wrong in its approach to internationalization= =2C it may be better to focus on explaining why it does not apply in a docu= ment that focuses on RADIUS. =3B
= --_7340695c-aa38-4b88-836b-cdb36cc9c938_-- -- to unsubscribe send a message to radiusext-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 Sep 10 11:20:08 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99EF21F8514 for ; Sat, 10 Sep 2011 11:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7wtv0ETBqgF for ; Sat, 10 Sep 2011 11:20:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id E6AE221F8509 for ; Sat, 10 Sep 2011 11:20:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R2S9I-0000jT-0x for radiusext-data0@psg.com; Sat, 10 Sep 2011 18:19:28 +0000 Received: from [2a01:e0b:1:76:21c:c0ff:fe27:7b54] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R2S9F-0000is-6X for radiusext@ops.ietf.org; Sat, 10 Sep 2011 18:19:25 +0000 Message-ID: <4E6BAA29.7070201@deployingradius.com> Date: Sat, 10 Sep 2011 20:19:21 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: i18n and RADIUS References: ,<4E6B6C2F.3010807@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: > That is an important point to make, because RFC 4282 proponents often > point to the encoding of an email address in say, EAI, as somehow > implyiing that the same encoding needs to be enforced in EAP and > RADIUS. That argument is fundamentally unsound, and needs to be laid > out clearly. The IDNA documents make much the same point, by stating > that the encoding of a domain name in DNS has no bearing on how it is to > be encoded in other protocols. But somehow this message has not been > clearly stated to apply to network access protocols which are 8-bit clean. That's why I wrote 4282bis... > [BA] I believe that this argument is already laid out clearly in RFC > 2865, 3748 and other related RFCs, and has been implemented very > widely. So this is not just an "opinion", it is a reality which aligns > with the RFCs. This unique convergence of reality and standards should > be celebrated, not punished :( The document says that explicitly: No one has implemented the recommendations of 4282. > [BA] Rather than doing an RFC 4282bis, I am wondering whether it might > make sense to recast this as "Internationalization in RADIUS". Having a 4282bis would mean that 4282 would no longer be relevant. The current document is simple, and has a simple focus. i18n in RADIUS might be a longer document. > Since RFC 4282 is fundamentally wrong in its approach to > internationalization, it may be better to focus on explaining why it > does not apply in a document that focuses on RADIUS. The 4282bis document does that extensively. 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 davidsonjones2010@gmail.com Wed Sep 14 00:48:19 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FE121F8CA9 for ; Wed, 14 Sep 2011 00:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.887 X-Spam-Level: **** X-Spam-Status: No, score=4.887 tagged_above=-999 required=5 tests=[BAYES_80=2, FM_FORGED_GMAIL=0.622, FORGED_HOTMAIL_RCVD2=1.502, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WyWxZ8DC3h9 for ; Wed, 14 Sep 2011 00:48:18 -0700 (PDT) Received: from mail-gw0-f67.google.com (mail-gw0-f67.google.com [74.125.83.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7308321F8CB8 for ; Wed, 14 Sep 2011 00:48:18 -0700 (PDT) Received: by gwm11 with SMTP id 11so203760gwm.6 for ; Wed, 14 Sep 2011 00:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=lRbYXfQ8A1+L9og/AYv800ZFF1jb37ghgr8ecvyPA1I=; b=rCX+1zTLCUXuwvatVBXP2EvyyLTdxkRbStLCxaoyiz+itIjqR1O48mAFYs7MtisWSI faUW9M+05EmF0ZRDBtO8jOh8WYoYIEdZQgaL+Sw9t1DN1Hf0Wvg4h6XhHkW64RDn8jlQ ZSHM3vE4sNZAq3COkd5KvH/uEtUgJ1HjE/Mow= MIME-Version: 1.0 Received: by 10.236.185.195 with SMTP id u43mr38708208yhm.106.1315986624128; Wed, 14 Sep 2011 00:50:24 -0700 (PDT) Reply-To: rutherford.finance.home@hotmail.com Sender: davidsonjones2010@gmail.com Received: by 10.236.50.112 with HTTP; Wed, 14 Sep 2011 00:50:24 -0700 (PDT) Date: Wed, 14 Sep 2011 00:50:24 -0700 X-Google-Sender-Auth: QMGTRc8T5PDUhWSH3gmSvGKAN-Y Message-ID: Subject: From: Ruther Ford To: undisclosed-recipients:; Content-Type: multipart/alternative; boundary=20cf3020807442aa8b04ace2037c --20cf3020807442aa8b04ace2037c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bonne journ=E9e, Avez-vous besoin d'un pr=EAt? si oui contactez-nous avec le formulaire ci-dessous pr=EAt pour que vous puissiez obtenir ce pr=EAt dont vous avez besoin. D=E9tails de l'application. Nom complet :...... Pays :........ Montant n=E9cessaire :....... Pr=EAt =E0 terme :......... T=E9l=E9phone :.......... Sexe :......... Age :............... t=E9l=E9phone :.............+ Revenez nous voir avec ce d=E9tail. Good Day, Are you in need of a loan? if yes contact us with the below loan form so that you can get that loan you need. Application Detials. Full Name:...... Country:........ Amount Needed:....... Loan Term:......... Phone:.......... Gender:......... Age:............... Phone:.............+ Get back to us with this details. --20cf3020807442aa8b04ace2037c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bonne journ=E9e,

Avez-vous besoin d'un pr=EAt? si oui contactez-= nous avec le formulaire ci-dessous pr=EAt pour que vous puissiez obtenir ce= pr=EAt dont vous avez besoin.

D=E9tails de l'application.
Nom complet :......
Pays :........
Montant n=E9cessaire :.......
Pr=EAt =E0 terme :......= ...
T=E9l=E9phone :..........
Sexe :.........
Age :...............=
t=E9l=E9phone :.............+

Revenez nous voir avec ce d=E9tail= .




Good Day,

Are you in need of a loan? if yes contact us with = the below loan form so that you can get that loan you need.

Applicat= ion Detials.

Full Name:......
Country:........
Amount Needed:.= ......
Loan Term:.........
Phone:..........
Gender:.........
Age:........= .......
Phone:.............+

Get back to us with this details.





--20cf3020807442aa8b04ace2037c-- From owner-radiusext@ops.ietf.org Thu Sep 15 14:07:21 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D8621F84F9 for ; Thu, 15 Sep 2011 14:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.468 X-Spam-Level: X-Spam-Status: No, score=-101.468 tagged_above=-999 required=5 tests=[AWL=-1.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCT4hSW3xi8g for ; Thu, 15 Sep 2011 14:07:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9633A21F84D6 for ; Thu, 15 Sep 2011 14:07:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R4J5G-000GW8-31 for radiusext-data0@psg.com; Thu, 15 Sep 2011 21:02:58 +0000 Received: from mail.ietf.org ([2001:1890:123a::1:1e]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R4J58-000GUx-91 for radiusext@ops.ietf.org; Thu, 15 Sep 2011 21:02:50 +0000 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAA411E80D2; Thu, 15 Sep 2011 14:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-HCfC9zejXk; Thu, 15 Sep 2011 14:00:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE19911E80CD; Thu, 15 Sep 2011 14:00:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Document Action: 'Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)' to Informational RFC (draft-ietf-radext-crypto-agility-requirements-07.txt) X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Cc: RFC Editor , radext mailing list , radext chair Message-ID: <20110915210035.22751.51507.idtracker@ietfa.amsl.com> Date: Thu, 15 Sep 2011 14:00:35 -0700 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: The IESG has approved the following document: - 'Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)' (draft-ietf-radext-crypto-agility-requirements-07.txt) as an Informational RFC This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-radext-crypto-agility-requirements/ Technical Summary This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS) as well as the process by which crypto-agility solutions will be developed and published by the RADEXT working group. Crypto- agility is defined as the ability of RADIUS implementations to automatically negotiate cryptographic algorithms for use in RADIUS exchanges, including the algorithms used to integrity protect and authenticate RADIUS packets and to hide RADIUS attributes. Negotiation of cryptographic algorithms may occur within the RADIUS protocol, or within a lower layer such as the transport layer. Working Group Summary The document has adequate review from members of the community. Work on crypto-agility requirements began at IETF 66. A working definition of crypto-agility was discussed during the RADEXT WG session at IETF 68. The initial WG last call completed on August 10, 2008, and the WG last call issues were resolved at IETF 73 and on the mailing list. The document was then reviewed by the Security Area Director (Pasi Eronen) on February 18, 2009. The major items brought up during this review and subsequent discussions related to the role of automated key management, as well as security properties such as perfect forward secrecy. The final RADEXT WG last call completed on May 1, 2011. There appears to be strong consensus behind the document. Document Quality The document has been reviewed by participants within the IETF RADEXT WG, as well as by external reviewers. It has completed two RADEXT WG last calls. -- to unsubscribe send a message to radiusext-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 Sep 23 03:10:55 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E527821F8BB0 for ; Fri, 23 Sep 2011 03:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osJ0eyn2kBE8 for ; Fri, 23 Sep 2011 03:10:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2637821F8BBE for ; Fri, 23 Sep 2011 03:10:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R72hO-00078x-IM for radiusext-data0@psg.com; Fri, 23 Sep 2011 10:09:38 +0000 Received: from mail-wy0-f180.google.com ([74.125.82.180]) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R72hL-00078U-J5 for radiusext@ops.ietf.org; Fri, 23 Sep 2011 10:09:36 +0000 Received: by wyh11 with SMTP id 11so2565534wyh.11 for ; Fri, 23 Sep 2011 03:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=BESuv2aJ57V4nRcOfbTu8YkwKOy7jKCFBxomPyo5bCM=; b=Yj5efo86mq8292H7LjWdrmQhpyRJ9wW/AgyAEkGxSBThFjfQK/Yp1Ho3vUznobI6NC 9FNZmiHvX12uBGJMxlmoApB+b07aO+3n7ikdRUwIwIXxJUlXu4i6qxtTMyEM67j5RCFf QO5BAOW7sn/nRNc0BKtzHSy3+E5t6sHfoCPJo= Received: by 10.216.0.2 with SMTP id 2mr4731074wea.82.1316772573498; Fri, 23 Sep 2011 03:09:33 -0700 (PDT) Received: from [10.255.129.254] ([192.100.123.77]) by mx.google.com with ESMTPS id es10sm9859063wbb.4.2011.09.23.03.09.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Sep 2011 03:09:32 -0700 (PDT) Subject: Re: WGLC for draft-ietf-radext-radius-extensions-01 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Fri, 23 Sep 2011 13:09:27 +0300 Cc: "Mauricio (HP Networking) Sanchez" , Alan DeKok Content-Transfer-Encoding: quoted-printable Message-Id: <94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> References: <4E64DD35.4030306@deployingradius.com> To: radext mailing list X-Mailer: Apple Mail (2.1084) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Folks, The WGLC ended for this I-D yesterday. There were no comments, which I = don't feel too comfortable with. However, regarding this particular I-D = it has been around for quite some time and we know there are already = multiple inter-operable implementations. We'll move the I-D forward. - Jouni On Sep 8, 2011, at 12:19 PM, jouni korhonen wrote: > Folks, >=20 > This mail starts two weeks WGLC for = draft-ietf-radext-radius-extensions-01. Send your comments to the list = and also record them to the issue tracker. The WGLC ends 22nd September, = 23:59 CET+1. >=20 > The authors are encouraged to recruit reviewers for the I-D. >=20 > Cheers, > Jouni & Mauricio -- to unsubscribe send a message to radiusext-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 Sep 23 03:19:07 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C7421F8B05 for ; Fri, 23 Sep 2011 03:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNA8w6yV3u5j for ; Fri, 23 Sep 2011 03:19:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id ED2F421F863E for ; Fri, 23 Sep 2011 03:19:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R72qw-0007Og-Pj for radiusext-data0@psg.com; Fri, 23 Sep 2011 10:19:30 +0000 Received: from mail-wy0-f180.google.com ([74.125.82.180]) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R72qt-0007OV-Ol for radiusext@ops.ietf.org; Fri, 23 Sep 2011 10:19:27 +0000 Received: by wyh11 with SMTP id 11so2575518wyh.11 for ; Fri, 23 Sep 2011 03:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ymvf6TyPKDZdqq+L7mYFulAvrf5ypmdG59T/nKdueYg=; b=tij+DGr9Nc7O/0kKX+8cn8rVxqzpK9naoeAg1q83n6tj4+1Uw1LXt3QYVVo+Dnx8Ap oE/BZ/fTmfPNnpQMFG2NHazx9L0npinXApImOeKQCWrqGFDE7GaJQn6LISln542G3NoE pPglw/S8nqEOiWVW4CETCCycUO6RE4K8WXHvY= Received: by 10.216.187.141 with SMTP id y13mr3373693wem.79.1316773166054; Fri, 23 Sep 2011 03:19:26 -0700 (PDT) Received: from [10.255.129.254] ([192.100.123.77]) by mx.google.com with ESMTPS id i11sm15676714wbn.25.2011.09.23.03.19.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Sep 2011 03:19:25 -0700 (PDT) Subject: Re: WGLC for draft-ietf-radext-radsec-09 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <5237C2DA-4D15-41AD-80C4-F6E12CCB1CFE@gmail.com> Date: Fri, 23 Sep 2011 13:19:22 +0300 Cc: "Mauricio (HP Networking) Sanchez" , Stefan Winter Content-Transfer-Encoding: quoted-printable Message-Id: <6BC3DBF9-C864-435E-B8C2-21AE2B19664D@gmail.com> References: <5237C2DA-4D15-41AD-80C4-F6E12CCB1CFE@gmail.com> To: radext mailing list X-Mailer: Apple Mail (2.1084) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Folks, The WGLC for this I-D completed yesterday. There were no comments, which = I am not too comfortable with. However, again the I-D has been around = for 2 years and 10 months.. so I guess those who had something to say = have already done that. We'll move the I-D forward. - Jouni On Sep 8, 2011, at 10:12 PM, jouni korhonen wrote: > Folks, >=20 > This mail starts two weeks WGLC for draft-ietf-radext-radsec-09. Send = your comments to the list and also record them to the issue tracker. The = WGLC ends 22nd September, 23:59 CET+1. >=20 > The authors are encouraged to recruit reviewers for the I-D. >=20 > Cheers, > Jouni & Mauricio -- to unsubscribe send a message to radiusext-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 Sep 23 04:24:45 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073D021F8BE4 for ; Fri, 23 Sep 2011 04:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwuzIz8CcQM5 for ; Fri, 23 Sep 2011 04:24:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 6329021F8BBA for ; Fri, 23 Sep 2011 04:24:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R73sL-0009JH-2I for radiusext-data0@psg.com; Fri, 23 Sep 2011 11:25:01 +0000 Received: from [2a01:e0b:1:76:21c:c0ff:fe27:7b54] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R73sH-0009In-Ru for radiusext@ops.ietf.org; Fri, 23 Sep 2011 11:24:58 +0000 Message-ID: <4E7C6C87.5080302@deployingradius.com> Date: Fri, 23 Sep 2011 13:24:55 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: jouni korhonen CC: radext mailing list , "Mauricio (HP Networking) Sanchez" , Stefan Winter Subject: Re: WGLC for draft-ietf-radext-radsec-09 References: <5237C2DA-4D15-41AD-80C4-F6E12CCB1CFE@gmail.com> <6BC3DBF9-C864-435E-B8C2-21AE2B19664D@gmail.com> In-Reply-To: <6BC3DBF9-C864-435E-B8C2-21AE2B19664D@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: jouni korhonen wrote: > The WGLC for this I-D completed yesterday. There were no comments, which I am not too comfortable with. However, again the I-D has been around for 2 years and 10 months.. so I guess those who had something to say have already done that. We'll move the I-D forward. There are 3-4 interoperable implementations. So the document describes what is in use today. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Sep 25 10:04:41 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A6421F8B12 for ; Sun, 25 Sep 2011 10:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.856 X-Spam-Level: X-Spam-Status: No, score=-100.856 tagged_above=-999 required=5 tests=[AWL=-1.272, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtRtUgGpelhJ for ; Sun, 25 Sep 2011 10:04:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 5A51121F8B0B for ; Sun, 25 Sep 2011 10:04:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R7s7C-0007dJ-9Q for radiusext-data0@psg.com; Sun, 25 Sep 2011 17:03:42 +0000 Received: from blu0-omc1-s23.blu0.hotmail.com ([65.55.116.34]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R7s78-0007d7-GF for radiusext@ops.ietf.org; Sun, 25 Sep 2011 17:03:38 +0000 Received: from BLU152-W26 ([65.55.116.7]) by blu0-omc1-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Sep 2011 10:03:37 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3e49f6ea-cb16-4889-afaa-98e682e8ee59_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RE: WGLC for draft-ietf-radext-radius-extensions-01 Date: Sun, 25 Sep 2011 10:03:37 -0700 Importance: Normal In-Reply-To: <94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> References: <4E64DD35.4030306@deployingradius.com> ,<94DBA75C-3D10-4487-8C56-303901E55704@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 25 Sep 2011 17:03:37.0812 (UTC) FILETIME=[115E6140:01CC7BA5] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_3e49f6ea-cb16-4889-afaa-98e682e8ee59_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here are my comments: The IANA Considerations section needs to be revised. It is recommended tha= t the IANA considerations section be rewritten=20 according to the recommendations of RFC 5226=2C and that this be cited as a normative reference. Some issues: 1. The IANA considerations section does not specify how attributes are to b= e allocated from the extended space=2C using policy terms defined in RFC 52= 26.=20 2. Normative language terms "SHOULD"/"SHOULD NOT" are used in Sections 9.1 = and 9.5. =20 The IANA is not a policy making body and therefore is not capable of handli= ng MAY=2C SHOULD or SHOULD NOT directives.=20 9.1. Attribute Allocations IANA is requested to move the "Unassigned" numbers in the range 144-191 from "Unassigned" to "Deprecated". This status means that allocations SHOULD NOT be made from this space. Instead=2C allocations SHOULD be taken from the Extended Type space=2C starting with lower numbered attributes. However=2C allocation from the "Deprecated" space MAY still be performed by publication of an IETF specification=2C where that specification requests allocation from the "Deprecated" space=2C and gives reasons why use of the Extended Type space is impossible. [BA]=20 It seems that the goal is to still allow allocation from the Unassigned ran= ge=2C while preferring allocation from the Extended Type space. A more implementable way of accomplishing this might be to say that unless = specifically requested to allocate from the Standard RADIUS space=2C IANA should make allocations from the extended type space.=20 9.5. Extending the RADIUS Attribute Type Space The extended RADIUS Attribute Type space may eventually approach exhaustion. When necessary=2C the space SHOULD be extended by publication of a specification which allocates new attributes of either the "Extended Type"=2C or the "Extended Type with flags" format. [BA] This material relates to IETF not IANA processing=2C and so is not appropriate for an IANA considerations section. The IANA cannot handle the policy decisions that are implied here.=20 The specification SHOULD request allocation of a specific number from the "Reserved" RADIUS Attribute type space=2C such as 247. The attribute(s) SHOULD be given a name which follows the naming convention used in this document. The Extended-Type value of 26 MUST be allocated to a "Vendor Specific" attribute=2C of data type "esv". The Extended-Type values of 241 through 255 MUST be marked as "Reserved". IANA SHOULD allocate the attribute(s) as requested. For example=2C if allocation of attribute 247 is requested=2C the following definitions MUST be made in the specification=2C and allocated by IANA. * 247.1 Extended-Attribute-7 * 247.{1-25} Unassigned * 247.26 Extended-Vendor-Specific-7 * 247.{27-240} Unassigned * 247.{241-255} Reserved We note=2Chowever=2C that the above list is an example=2C and we do not request or perform allocation of attribute 247 in this document. = --_3e49f6ea-cb16-4889-afaa-98e682e8ee59_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Here are my comments:

The IANA Considerations section needs to be re= vised. =3B It is recommended that the IANA considerations section be re= written=20 according to the recommendations of RFC 5226=2C and that this be cited as a normative reference.

Some issues:

1. The IANA considerations section does not specify= how attributes are to be allocated from the extended space=2C using policy= terms defined in RFC 5226.
2. Normative language terms "SHOULD"/"SHOUL= D NOT" are used in Sections 9.1 and 9.5. =3B 
The IANA is not a policy making body and therefore is not capable of handl=
ing MAY=2C SHOULD or SHOULD NOT directives. 

9.1.  Attribute Alloca=
tions


   IANA is requested to move the "Unassigned" numbers in the range
   144-191 from "Unassigned" to "Deprecated".  This status means that
   allocations SHOULD NOT be made from this space.  Instead=2C allocations
   SHOULD be taken from the Extended Type space=2C starting with lower
   numbered attributes.  However=2C allocation from the "Deprecated" space
   MAY still be performed by publication of an IETF specification=2C where
   that specification requests allocation from the "Deprecated" space=2C
   and gives reasons why use of the Extended Type space is impossible.
<=
br>
[BA] 

It seems that the goal is to still allow allocation fro=
m the Unassigned range=2C while preferring allocation from the Extended Typ=
e space.

A more implementable way of accomplishing this might be to =
say that unless specifically requested to allocate from the Standard RADIUS=
 space=2C
IANA should make allocations from the extended type space. 
9.5.  Extending the=
 RADIUS Attribute Type Space


   The extended RADIUS Attribute Type space may eventually approach
   exhaustion.  When necessary=2C the space SHOULD be extended by
   publication of a specification which allocates new attributes of
   either the "Extended Type"=2C or the "Extended Type with flags" format.<=
br>
[BA] This material relates to IETF not IANA processing=2C and so is =
not
appropriate for an IANA considerations section.  The IANA cannot han=
dle
the policy decisions that are implied here. 


   =3BTh=
e specification SHOULD request allocation of a specific number from
   the "Reserved" RADIUS Attribute type space=2C such as 247.  The
   attribute(s) SHOULD be given a name which follows the naming
   convention used in this document.  The Extended-Type value of 26 MUST
   be allocated to a "Vendor Specific" attribute=2C of data type "esv".
   The Extended-Type values of 241 through 255 MUST be marked as
   "Reserved".

   IANA SHOULD allocate the attribute(s) as requested.  For example=2C if
   allocation of attribute 247 is requested=2C the following definitions
   MUST be made in the specification=2C and allocated by IANA.

   * 247.1          Extended-Attribute-7
   * 247.{1-25}     Unassigned
   * 247.26         Extended-Vendor-Specific-7
   * 247.{27-240}   Unassigned
   * 247.{241-255}  Reserved

   We note=2Chowever=2C that the above list is an example=2C and we do not
   request or perform allocation of attribute 247 in this document.

=





= --_3e49f6ea-cb16-4889-afaa-98e682e8ee59_-- -- to unsubscribe send a message to radiusext-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 Sep 26 10:52:25 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE1921F8BEB for ; Mon, 26 Sep 2011 10:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.319 X-Spam-Level: X-Spam-Status: No, score=-102.319 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TFHw8LBwJ+t for ; Mon, 26 Sep 2011 10:52:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 02B9A21F87E2 for ; Mon, 26 Sep 2011 10:52:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R8FKy-000A0W-QF for radiusext-data0@psg.com; Mon, 26 Sep 2011 17:51:28 +0000 Received: from blu0-omc1-s1.blu0.hotmail.com ([65.55.116.12]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R8FKq-0009zB-Kk for radiusext@ops.ietf.org; Mon, 26 Sep 2011 17:51:21 +0000 Received: from BLU152-W3 ([65.55.116.8]) by blu0-omc1-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 10:51:14 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_4dae0541-0b73-4565-bcc4-eb4fa69e7ff8_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: New version of RADIUS WLAN document Date: Mon, 26 Sep 2011 10:51:13 -0700 Importance: Normal In-Reply-To: <20110926173925.30818.85449.idtracker@ietfa.amsl.com> References: <20110926173925.30818.85449.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-OriginalArrivalTime: 26 Sep 2011 17:51:14.0016 (UTC) FILETIME=[E2364600:01CC7C74] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_4dae0541-0b73-4565-bcc4-eb4fa69e7ff8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI. =20 This topic is on the RADEXT WG charter. The RADEXT WG was requested to re= view the document for adoption as a WG work item on 13 November 2007: http://ops.ietf.org/lists/radiusext/2007/msg00906.html However=2C no summary of that "Call for Review" was ever issued.=20 =20 > Filename: draft-aboba-radext-wlan > Revision: 14 > Title: RADIUS Attributes for IEEE 802 Networks > Creation date: 2011-09-26 > WG ID: Individual Submission > Number of pages: 19 >=20 > Abstract: > RFC 3580 provides guidelines for the use of the Remote Authentication > Dialin User Service (RADIUS) within IEEE 802 local area networks > (LANs). This document proposes additional attributes for use within > IEEE 802 networks=2C as well as providing clarifications on the usage > of the EAP-Key-Name attribute=2C updating RFC 4072. The attributes > defined in this document are usable both within RADIUS and Diameter. >=20 > = =20 >=20 >=20 > The IETF Secretariat = --_4dae0541-0b73-4565-bcc4-eb4fa69e7ff8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
FYI.  =3B

This topic is on the RADEXT WG charter.  =3B The = RADEXT WG was requested to review the document for adoption as a WG work it= em on 13 November 2007:
http://ops.ietf.org/lists/radiusext/2007/msg0090= 6.html

However=2C no summary of that "Call for Review" was ever issu= ed.
 =3B
>=3B Filename: draft-aboba-radext-wlan
>= =3B Revision: 14
>=3B Title: RADIUS Attributes for IEEE 802 Network= s
>=3B Creation date: 2011-09-26
>=3B WG ID: Individual Submis= sion
>=3B Number of pages: 19
>=3B
>=3B Abstract:
>=3B= RFC 3580 provides guidelines for the use of the Remote Authentication>=3B Dialin User Service (RADIUS) within IEEE 802 local area network= s
>=3B (LANs). This document proposes additional attributes for us= e within
>=3B IEEE 802 networks=2C as well as providing clarificati= ons on the usage
>=3B of the EAP-Key-Name attribute=2C updating RFC= 4072. The attributes
>=3B defined in this document are usable bot= h within RADIUS and Diameter.
>=3B
>=3B =
>=3B
&g= t=3B
>=3B The IETF Secretariat
= --_4dae0541-0b73-4565-bcc4-eb4fa69e7ff8_-- -- to unsubscribe send a message to radiusext-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 Sep 28 16:23:24 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA2911E8088 for ; Wed, 28 Sep 2011 16:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.551 X-Spam-Level: X-Spam-Status: No, score=-103.551 tagged_above=-999 required=5 tests=[AWL=-0.952, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtB8JLK8zYaO for ; Wed, 28 Sep 2011 16:23:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C82B211E80FB for ; Wed, 28 Sep 2011 16:23:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R93S6-0005FV-HL for radiusext-data0@psg.com; Wed, 28 Sep 2011 23:22:10 +0000 Received: from mtv-iport-3.cisco.com ([173.36.130.14]) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R93S2-0005FJ-Hz for radiusext@ops.ietf.org; Wed, 28 Sep 2011 23:22:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1455; q=dns/txt; s=iport; t=1317252126; x=1318461726; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ukITUNBe5Oe8bhZJnSLE2/DQNe7idTccqZbDg2D/eVU=; b=TPubDZIFjvghol5BTuxGaNzKJKeLTLqxDAc6kesI/113GT4sxXPKr6g5 Q3+S2YxgzC/irWX7aV9HSZzteIEVjMlJUP/z/b5ZIAC80kQdRb2EZUuHZ YfmzRAFuXPRBowE6NyaBIQUeTsTniWhWgGZw5hfmFePlp5+Oc0T5jf1ni A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALmrg06rRDoG/2dsb2JhbABCqAd4gVMBAQEBAgEBAg8BCh0/BQsLRigvBjWHVgaZXwGeHocMBIdyiUuCGIUijDM X-IronPort-AV: E=Sophos;i="4.68,458,1312156800"; d="scan'208";a="4889415" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 28 Sep 2011 23:22:05 +0000 Received: from [10.33.249.43] ([10.33.249.43]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8SNM59C015849; Wed, 28 Sep 2011 23:22:05 GMT Subject: Re: New version of RADIUS WLAN document Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Wed, 28 Sep 2011 16:22:16 -0700 Cc: "radiusext@ops.ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <018F1447-E33C-46CE-9B8F-59025904515C@cisco.com> References: <20110926173925.30818.85449.idtracker@ietfa.amsl.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Since the EAP-lower-layer attribute is not 802 specific and it is a = useful value in EAP channel bindings it is included in the EAP channel = bindings draft: draft-ietf-emu-chbind-09. This document has just start = WGLC call in EMU. If you have comments on the document please send = them to the EMU list before October 21, 2011. =20 Thanks, Joe On Sep 26, 2011, at 10:51 AM, Bernard Aboba wrote: > FYI. =20 >=20 > This topic is on the RADEXT WG charter. The RADEXT WG was requested = to review the document for adoption as a WG work item on 13 November = 2007: > http://ops.ietf.org/lists/radiusext/2007/msg00906.html >=20 > However, no summary of that "Call for Review" was ever issued.=20 > =20 > > Filename: draft-aboba-radext-wlan > > Revision: 14 > > Title: RADIUS Attributes for IEEE 802 Networks > > Creation date: 2011-09-26 > > WG ID: Individual Submission > > Number of pages: 19 > >=20 > > Abstract: > > RFC 3580 provides guidelines for the use of the Remote = Authentication > > Dialin User Service (RADIUS) within IEEE 802 local area networks > > (LANs). This document proposes additional attributes for use within > > IEEE 802 networks, as well as providing clarifications on the usage > > of the EAP-Key-Name attribute, updating RFC 4072. The attributes > > defined in this document are usable both within RADIUS and Diameter. > >=20 > >=20 > >=20 > >=20 > > The IETF Secretariat -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From radext-bounces@ietf.org Thu Sep 29 13:51:45 2011 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC1621F8EE1 for ; Thu, 29 Sep 2011 13:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1317329504; bh=/yqm7t1vLb2eK9wotekVwJdJdVbYu+cpJRW5bCnWnPg=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Subject:From: To:Message-ID:Date:List-Id:Sender; b=sGBnWiKMXkan9DW74Y7s+CDOTK808AUqoRfwzlINnB6FcLjONLAonBedsld7lS9z0 sy7bbYttMDI9r6EFKOOvWY5QOXpuPuQwDk8xYbDlyUsbC46jMqFxeXqBYaDsxoxUZD HT8r76+5TJ5pDztB4sM+NAMPNX1sKf0l3NZsERjA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Welcome to the "radext" mailing list From: radext-request@ietf.org To: radext-archive-IeZ9sae2@lists.ietf.org X-No-Archive: yes Message-ID: Date: Thu, 29 Sep 2011 13:51:25 -0700 Precedence: bulk X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 List-Id: RADIUS EXTensions working group discussion list X-List-Administrivia: yes Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Welcome to the radext@ietf.org mailing list! Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: The IETF plenary session The IESG, or any member thereof on behalf of the IESG Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices Any IETF working group or portion thereof Any Birds of a Feather (BOF) session The IAB or any member thereof on behalf of the IAB The RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 5378 and RFC 3979 for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public. To post to this list, send your email to: radext@ietf.org General information about the mailing list is at: https://www.ietf.org/mailman/listinfo/radext If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www.ietf.org/mailman/options/radext/radext-archive-iez9sae2%40lists.ietf.org You can also make such adjustments via email by sending a message to: radext-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: mxf4Cu5d Normally, Mailman will remind you of your ietf.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you.