From owner-radiusext@ops.ietf.org Thu Jul 7 14:41: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 872E29E8022 for ; Thu, 7 Jul 2011 14:41:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfxXor-jgAdw for ; Thu, 7 Jul 2011 14:41:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A06BB9E8028 for ; Thu, 7 Jul 2011 14:41:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QewHz-000E4o-9b for radiusext-data0@psg.com; Thu, 07 Jul 2011 21:39:15 +0000 Received: from vs13.mail.saunalahti.fi ([195.197.172.103]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QewHw-000E4G-0s for radiusext@ops.ietf.org; Thu, 07 Jul 2011 21:39:12 +0000 Received: from saunalahti-vams (localhost [127.0.0.1]) by vs13.mail.saunalahti.fi (Postfix) with SMTP id 4FE202C003B for ; Fri, 8 Jul 2011 00:39:09 +0300 (EEST) Received: from vs13.mail.saunalahti.fi ([127.0.0.1]) by vs13.mail.saunalahti.fi ([195.197.172.103]) with SMTP (gateway) id A077294D61A; Fri, 08 Jul 2011 00:39:09 +0300 Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by vs13.mail.saunalahti.fi (Postfix) with ESMTP id 421F82C003B for ; Fri, 8 Jul 2011 00:39:09 +0300 (EEST) Received: from a88-114-175-183.elisa-laajakaista.fi (a88-114-175-183.elisa-laajakaista.fi [88.114.175.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 51C54151563 for ; Fri, 8 Jul 2011 00:39:04 +0300 (EEST) From: Jouni Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Fwd: [Softwires] WG last call on RADIUS Attribute for 6rd Date: Fri, 8 Jul 2011 00:39:04 +0300 References: To: radiusext@ops.ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Antivirus: VAMS Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: FYI Begin forwarded message: > From: Yong Cui > Date: July 7, 2011 11:37:54 AM GMT+03:00 > To: Softwires-wg list > Cc: Yong Cui > Subject: [Softwires] WG last call on RADIUS Attribute for 6rd >=20 > The chairs of the Softwire WG would like to start a 2-week working > group last call on =B3RADIUS Attribute for 6rd=B2. > http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ >=20 > Please send substantive comments to the list and editorial comments > to the authors. >=20 > The wg last call ends on July 21 at 9am EST. >=20 > - Alain & Yong >=20 >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires -- to 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 Jul 8 05:07:44 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 9DDDA21F88C3 for ; Fri, 8 Jul 2011 05:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ-4SFAVEHIl for ; Fri, 8 Jul 2011 05:07:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C0B3E21F88AE for ; Fri, 8 Jul 2011 05:07:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qf9nH-000NcV-TQ for radiusext-data0@psg.com; Fri, 08 Jul 2011 12:04:27 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::1e]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qf9nE-000Nc1-PS for radiusext@ops.ietf.org; Fri, 08 Jul 2011 12:04:24 +0000 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0ADE21F8992 for ; Fri, 8 Jul 2011 05:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6JKwPZEP0wj; Fri, 8 Jul 2011 05:04:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9705021F88E3; Fri, 8 Jul 2011 05:04:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action: draft-ietf-radext-radsec-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110708120423.25749.93529.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 05:04:23 -0700 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. Title : TLS encryption for RADIUS Author(s) : Stefan Winter Mike McCauley Stig Venaas Klaas Wierenga Filename : draft-ietf-radext-radsec-09.txt Pages : 21 Date : 2011-07-08 This document specifies security on the transport layer (TLS) for the RADIUS protocol when transmitted over TCP. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-09.txt -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Jul 8 05:55:05 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 1A61821F8A18 for ; Fri, 8 Jul 2011 05:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs7tUcr+0UT6 for ; Fri, 8 Jul 2011 05:55:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C4AFD21F8A14 for ; Fri, 8 Jul 2011 05:54:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QfAYa-000PvQ-Iz for radiusext-data0@psg.com; Fri, 08 Jul 2011 12:53:20 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::1e]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QfAYX-000PvG-RP for radiusext@ops.ietf.org; Fri, 08 Jul 2011 12:53:18 +0000 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F6321F88BC for ; Fri, 8 Jul 2011 05:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOGn1uuePOdT; Fri, 8 Jul 2011 05:53:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ACB21F85F8; Fri, 8 Jul 2011 05:53:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action: draft-ietf-radext-dynamic-discovery-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110708125316.10485.28224.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 05:53:16 -0700 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADI= US/DTLS Author(s) : Stefan Winter Mike McCauley Filename : draft-ietf-radext-dynamic-discovery-03.txt Pages : 9 Date : 2011-07-08 This document specifies a means to find authoritative RADIUS servers for a given realm. It can be used in conjunction with RADIUS/TLS and RADIUS/DTLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-dynamic-discovery-03.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-dynamic-discovery-03.t= xt -- to 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 Jul 8 05:57:23 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 31FE021F88E3 for ; Fri, 8 Jul 2011 05:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.953 X-Spam-Level: X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEI0CrIGHfA9 for ; Fri, 8 Jul 2011 05:57:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 6C98B21F85AF for ; Fri, 8 Jul 2011 05:57:09 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QfAb3-000062-HO for radiusext-data0@psg.com; Fri, 08 Jul 2011 12:55:53 +0000 Received: from smtprelay.restena.lu ([2001:a18:1::62]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QfAb0-00005p-UR for radiusext@ops.ietf.org; Fri, 08 Jul 2011 12:55:51 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 640CA109FB for ; Fri, 8 Jul 2011 14:55:49 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 54236109FA for ; Fri, 8 Jul 2011 14:55:49 +0200 (CEST) Message-ID: <4E16FE52.1040004@restena.lu> Date: Fri, 08 Jul 2011 14:55:46 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 CC: radiusext@ops.ietf.org Subject: Re: I-D Action: draft-ietf-radext-radsec-09.txt References: <20110708120423.25749.93529.idtracker@ietfa.amsl.com> In-Reply-To: <20110708120423.25749.93529.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4ACBD71D56C2BE88B5F721E0" X-Virus-Scanned: ClamAV Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4ACBD71D56C2BE88B5F721E0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, this revision includes - a new Appendix C: Compliance with crypto-agility requirements - wordsmithing regarding Connecting Client Identity - condensed packet types list This closes all tracker issues on the draft. I think it might be the time for (another) WG last call. Greetings, Stefan Winter Am 08.07.2011 14:04, schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the RADIUS EXTensions Working Group= of the IETF. > > Title : TLS encryption for RADIUS > Author(s) : Stefan Winter > Mike McCauley > Stig Venaas > Klaas Wierenga > Filename : draft-ietf-radext-radsec-09.txt > Pages : 21 > Date : 2011-07-08 > > This document specifies security on the transport layer (TLS) for th= e > RADIUS protocol when transmitted over TCP. This enables dynamic > trust relationships between RADIUS servers. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-09.txt > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig4ACBD71D56C2BE88B5F721E0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4W/lYACgkQ+jm90f8eFWYrlwCeOTzhsKWaG95l6oUmA0w8uIaE Dz8AniWTqXQGKRqlzpaHn4QV9k7aq7Ko =SFzo -----END PGP SIGNATURE----- --------------enig4ACBD71D56C2BE88B5F721E0-- -- to 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 Jul 8 05:58:54 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 6BD7421F8991 for ; Fri, 8 Jul 2011 05:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.784 X-Spam-Level: X-Spam-Status: No, score=-101.784 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wTed-dXoOAy for ; Fri, 8 Jul 2011 05:58:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 700F221F891F for ; Fri, 8 Jul 2011 05:58:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QfAc0-0000BI-7t for radiusext-data0@psg.com; Fri, 08 Jul 2011 12:56:52 +0000 Received: from smtprelay.restena.lu ([2001:a18:1::62]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QfAbt-0000B3-T9 for radiusext@ops.ietf.org; Fri, 08 Jul 2011 12:56:46 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id EF170109FB for ; Fri, 8 Jul 2011 14:56:44 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9D438109FA for ; Fri, 8 Jul 2011 14:56:44 +0200 (CEST) Message-ID: <4E16FE8D.5090508@restena.lu> Date: Fri, 08 Jul 2011 14:56:45 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: I-D Action: draft-ietf-radext-dynamic-discovery-03.txt References: <20110708125316.10485.28224.idtracker@ietfa.amsl.com> In-Reply-To: <20110708125316.10485.28224.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig989042A4944CC0213E0F1B43" X-Virus-Scanned: ClamAV Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig989042A4944CC0213E0F1B43 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, this revision uses service tags aaa+auth aaa+acct aaa+dynauth as S-NAPTR labels; it's the only major change to rev -02. Greetings, Stefan Winter Am 08.07.2011 14:53, schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the RADIUS EXTensions Working Group= of the IETF. > > Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and = RADIUS/DTLS > Author(s) : Stefan Winter > Mike McCauley > Filename : draft-ietf-radext-dynamic-discovery-03.txt > Pages : 9 > Date : 2011-07-08 > > This document specifies a means to find authoritative RADIUS servers= > for a given realm. It can be used in conjunction with RADIUS/TLS an= d > RADIUS/DTLS. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-radext-dynamic-discovery= -03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-dynamic-discovery-= 03.txt > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig989042A4944CC0213E0F1B43 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4W/o0ACgkQ+jm90f8eFWZ2XgCeJxvlQUFpnbp7o823RckBioqq OScAnjjhN/wv369pIBMiQi6YhZKRU4O/ =JYVb -----END PGP SIGNATURE----- --------------enig989042A4944CC0213E0F1B43-- -- to 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 Jul 8 06:02:52 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 E8D6421F8800 for ; Fri, 8 Jul 2011 06:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HfAT7jURd0a for ; Fri, 8 Jul 2011 06:02:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 0E14821F8828 for ; Fri, 8 Jul 2011 06:02:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QfAfm-0000PS-I7 for radiusext-data0@psg.com; Fri, 08 Jul 2011 13:00:46 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QfAfj-0000P2-Ef for radiusext@ops.ietf.org; Fri, 08 Jul 2011 13:00:43 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QfAfd-0007CS-9W; Fri, 08 Jul 2011 06:00:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: stefan.winter@restena.lu X-Trac-Project: radext Date: Fri, 08 Jul 2011 13:00:37 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #93: Compliance with Crypto-Agility Requirements X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/93#comment:1 Message-ID: <075.a2bad8cf8ce347cb0b0ec7386aa51788@trac.tools.ietf.org> References: <066.cbbe14ddeb8841047bdcf9c9dd8d3d7b@trac.tools.ietf.org> X-Trac-Ticket-ID: 93 In-Reply-To: <066.cbbe14ddeb8841047bdcf9c9dd8d3d7b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: stefan.winter@restena.lu, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #93: Compliance with Crypto-Agility Requirements Changes (by stefan.winter@…): * status: new => closed * resolution: => fixed Comment: The newest rev -09 now contains Appendix C with this information. That should close the issue. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: radsec | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Jul 8 06:03: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 8727121F8A1E for ; Fri, 8 Jul 2011 06:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6q8S027fx2Z for ; Fri, 8 Jul 2011 06:03:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id CAB0D21F8A14 for ; Fri, 8 Jul 2011 06:03:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QfAex-0000Ll-Dg for radiusext-data0@psg.com; Fri, 08 Jul 2011 12:59:55 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QfAes-0000LP-BP for radiusext@ops.ietf.org; Fri, 08 Jul 2011 12:59:51 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QfAen-0008N0-AL; Fri, 08 Jul 2011 05:59:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: stefan.winter@restena.lu X-Trac-Project: radext Date: Fri, 08 Jul 2011 12:59:45 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #14: DDNS Application X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/14#comment:1 Message-ID: <072.5a598b7253246b45cac01589cd57f704@trac.tools.ietf.org> References: <063.59b80889172dc2d689a2047d37953ca2@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <063.59b80889172dc2d689a2047d37953ca2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: stefan.winter@restena.lu, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #14: DDNS Application Changes (by stefan.winter@…): * status: new => closed * resolution: => fixed Comment: The current rev (-03) of the draft uses S-NAPTR definitions "aaa+auth" "aaa+acct" and "aaa+dynauth" along with the protocol fields "radius.tls" and "radius.dtls". This should close the issue. -- ------------------------------------+--------------------------------------- Reporter: leslie@… | Owner: stefan.winter@… Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: dynamic-discovery | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Jul 8 06:12: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 4B5A321F8565 for ; Fri, 8 Jul 2011 06:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKnUZspK+Pmy for ; Fri, 8 Jul 2011 06:12:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id CDF3821F8566 for ; Fri, 8 Jul 2011 06:11:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QfAoY-0000qo-79 for radiusext-data0@psg.com; Fri, 08 Jul 2011 13:09:50 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QfAoV-0000qR-MO for radiusext@ops.ietf.org; Fri, 08 Jul 2011 13:09:47 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QfAoU-0008OI-1B; Fri, 08 Jul 2011 06:09:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: stefan.winter@restena.lu X-Trac-Project: radext Date: Fri, 08 Jul 2011 13:09:46 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #13: Review X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/13#comment:1 Message-ID: <075.815075c76d2d5bbc3224ea7ec92d35d1@trac.tools.ietf.org> References: <066.4deafd48bd1699f32677b19573e08c0c@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <066.4deafd48bd1699f32677b19573e08c0c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: stefan.winter@restena.lu, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #13: Review Changes (by stefan.winter@…): * status: new => closed * resolution: => fixed Comment: 1. regarding abstract and references: -09 now has no references in the abstract. The scope has been clarified to "RADIUS over TLS and DTLS". 2. the term RadSec has been replaced with RADIUS/TLS and RADIUS/DTLS 3. SRV labels have been changed. 4. Examples have been changed. 5. RFC4282 is not referenced any longer. 6. explanatory text for "name resultion library != DNS" has been added. A reference to the IDNAbis Protocol RFC has been added. 7. IPv6 usage has been mentioned; but the guidance is limited to "according to the host system's IP stack capabilities". It's difficult to be more specific. 8. regarding: when is dynamic discovery useful. Primarily for X.509 based operations yes, but there may be cases where an out-of-band mechanism delivers PSK keys "just in time" (abfab KNP may be an example). So I'm hesitant to scope the usefulness of this draft too tightly. I think this closes all the discussed points in this issue; please re-open if you think this is not the case. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: stefan.winter@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dynamic-discovery | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Jul 8 11:03: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 4E1B121F89EB for ; Fri, 8 Jul 2011 11:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggQv0xU-mO7I for ; Fri, 8 Jul 2011 11:03:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id BA51921F85D1 for ; Fri, 8 Jul 2011 11:03:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QfFLl-000HHX-N7 for radiusext-data0@psg.com; Fri, 08 Jul 2011 18:00:25 +0000 Received: from g1t0026.austin.hp.com ([15.216.28.33]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QfFLf-000HH4-2T for radiusext@ops.ietf.org; Fri, 08 Jul 2011 18:00:19 +0000 Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTPS id DD865C54B for ; Fri, 8 Jul 2011 18:00:12 +0000 (UTC) Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 8 Jul 2011 17:58:45 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Fri, 8 Jul 2011 18:58:44 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" Date: Fri, 8 Jul 2011 18:58:43 +0100 Subject: Agenda items for IETF 81 Thread-Topic: Agenda items for IETF 81 Thread-Index: Acw9mKrikl2IG9vJQm61mjzlsSnEJg== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C766D3409@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C766D3409GVW0671EXCame_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C766D3409GVW0671EXCame_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RADEXT has been given a 2 =BD hour time slot on Monday morning (7/25) from = 09:00 to 11:30. Please send any requests for agenda slots to chairs. Thank you, Mauricio --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C766D3409GVW0671EXCame_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

RADEXT has been = given a 2 =BD hour time slot on Monday morning (7/25) from 09:00 to 11:30. =

 

Please send any requests for agenda slots to chairs.=A0

<= p class=3DMsoNormal> 

Thank you,

Mauricio

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C766D3409GVW0671EXCame_-- -- to 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 Jul 10 23:54:40 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 68F6721F89F2 for ; Sun, 10 Jul 2011 23:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtPezXagyGpp for ; Sun, 10 Jul 2011 23:54:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 0B96B21F89CC for ; Sun, 10 Jul 2011 23:54:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgAKt-000ONl-H9 for radiusext-data0@psg.com; Mon, 11 Jul 2011 06:51:19 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgAKq-000ONV-BB for radiusext@ops.ietf.org; Mon, 11 Jul 2011 06:51:16 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QgAKm-0003VP-Ut; Sun, 10 Jul 2011 23:51:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 11 Jul 2011 06:51:12 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #99: AD Review of RADIUS Crypto-Agility Requirements X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/99#comment:1 Message-ID: <068.f96612faed9b2cc3e94bb5a6bdd7e2b0@trac.tools.ietf.org> References: <059.188ec2e19b4809635aafabbaffc6355c@trac.tools.ietf.org> X-Trac-Ticket-ID: 99 In-Reply-To: <059.188ec2e19b4809635aafabbaffc6355c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #99: AD Review of RADIUS Crypto-Agility Requirements Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Proposed resolution is as follows: T1. This language appears to be boilerplate in AAA requirements RFCs and BCPs (see RFC 2989 Section 1.1, RFC 4962 Section 1.1, etc.). No change suggested. T2. Recommended change in 4.2 is: Guidance on acceptable algorithms can be found in [NIST-SP800-131A]. It is RECOMMENDED that mandatory-to-implement cryptographic algorithms be chosen from among those classified as "Acceptable" with no known deprecation date from within this or successor documents. T3. This is a typo. It should refer to Section 3. E1. A newer notice should be used. E2. Recommend combining Section 1.3 and 1.1 as follows: 1.1. General At the IETF-66 meeting, the RADIUS Extensions (RADEXT) Working Group was asked by members of the Security Area Directorate to prepare a formal description of a crypto-agility work item, and corresponding charter milestones. After consultation with one of the Security Area Directors, Russ Housley, text was initially proposed on the RADEXT WG mailing list on October 26, 2006: The RADEXT WG will review the security requirements for crypto- agility in IETF protocols, and identify the deficiencies of the existing RADIUS protocol specifications against these requirements. Specific attention will be paid to RFC 4962 [RFC4962]. The RADEXT WG will propose one or more specifications to remediate any identified deficiencies in the crypto-agility properties of the RADIUS protocol. The known deficiencies include the issue of negotiation of substitute algorithms for the message digest functions, the key-wrap functions, and the password-hiding function. Additionally, at least one mandatory to implement cryptographic algorithm will be defined in each of these areas, as required. This document describes the features, properties and limitations of RADIUS crypto-agility solutions, as well as defining the term "crypto-agility" as used in this context, and providing the motivations for this work. The requirements defined in this memo have been developed based on e- mail messages posted to the RADEXT WG mailing list, which may be found in the archives of that list. The purpose of framing the requirements in this memo is to formalize and memorialize them for future reference, and to bring them explicitly to the attention of the IESG and the IETF Community, as we proceed with this work. E3. The typo should be corrected. -- -----------------------------------+---------------------------------------- Reporter: dromasca@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jul 11 00:04:47 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 280C521F8A58 for ; Mon, 11 Jul 2011 00:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+-erlhD+IXm for ; Mon, 11 Jul 2011 00:04:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id B7E1521F8A19 for ; Mon, 11 Jul 2011 00:04:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgAVz-000Ok5-Kq for radiusext-data0@psg.com; Mon, 11 Jul 2011 07:02:47 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgAVw-000Ojv-GX for radiusext@ops.ietf.org; Mon, 11 Jul 2011 07:02:44 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QgAVu-0000v0-Ls; Mon, 11 Jul 2011 00:02:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 11 Jul 2011 07:02:42 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #100: Gen-ART Review X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/100#comment:1 Message-ID: <076.dc584d681dcb4a8ac9bd857299019c1e@trac.tools.ietf.org> References: <067.e81dbf4d76574598789baa0c45d6a812@trac.tools.ietf.org> X-Trac-Ticket-ID: 100 In-Reply-To: <067.e81dbf4d76574598789baa0c45d6a812@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #100: Gen-ART Review Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Proposed resolution is as follows: - Change: OLD: This memo, when approved, reflects the consensus of the RADIUS Extensions (RADEXT) Working Group of the IETF as to the features, properties and limitations of the crypto-agility work item for RADIUS. NEW: This memo describes the features, properties and limitations of the crypto-agility solution for RADIUS. - Introduction,second paragraph. In this situation, there has apparently been some confusion about the history, so articulating the background is important. - Section 1.3 has been deleted. - Section 2. First sentence has been deleted. - Section 2, 4th paragraph. SHOULD NOT upgraded to MUST NOT. - Section 4.2, 5th paragraph, 1st sentence. Change to: " Support for encryption of individual RADIUS attributes is OPTIONAL for solutions that provide encryption of entire RADIUS packets." - Section 4.2, "Limit key scope" paragraph. Change to: Support for end-to-end confidentiality of RADIUS attributes is OPTIONAL. Change Section 4.3 to: 4.3. Backwards Compatibility Solutions MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both crypto-agility and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). While backward compatibility is needed to ease the transition between legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is only appropriate prior to the compromise of those mechanisms. After legacy mechanisms have been compromised, secure algorithms MUST be used, so that backward compatibility is no longer possible. Since RADIUS is a request/response protocol, the ability to negotiate cryptographic algorithms within a single RADIUS exchange is inherently limited. Prior to receipt of a response, a requester will not know what algorithms are supported by the responder. Therefore, while a RADIUS request can provide a list of supported cryptographic algorithms which can be selected for use within a response, prior to the receipt of a response, the cryptographic algorithms utilized to provide security services within an initial request will need to be pre-determined. In order to enable a request to be handled both by legacy as well as crypto-agile implementations, a request can be secured with legacy algorithms was well as with attributes providing security services using more secure algorithms. This approach allows a RADIUS packet to be processed by legacy implementations as well as by crypto-agile implementations, and does not result in additional response delays. If this technique is used, credentials used with legacy algorithms MUST be cryptographically independent of the credentials used with the more secure algorithms. In this approach to backward compatibility, legacy mechanisms are initially used in requests sent between crypto-agile implementations. However, if the responder indicates support for crypto-agility, future requests can use more secure mechanisms. Probing techniques can be used to avoid the use of legacy algorithms in requests sent between crypto-agile implementations. For example, an initial request can omit use of legacy mechanisms. If a response is received, then the recipient can be assumed to be crypto-agile and future requests to that recipient can utilize secure mechanisms. Similarly, the responder can assume that the requester supports crypto-agility and can prohibit use of legacy mechanisms in future requests. If a response is not received, in the absence of information indicating responder support for crypto-agility (such as pre- configuration or previous receipt of a crypto-agile response), a new request can be composed utilizing legacy mechanisms. Since legacy implementations not supporting crypto-agility will silently discard requests not protected by legacy algorithms rather than returning an error, repeated requests can be required to distinguish lack of support for crypto-agility from packet loss or other failure conditions. Therefore probing techniques can delay initial communication between crypto-agile requesters and legacy responders. This can be addressed by upgrading the responders (e.g. RADIUS servers) first. - Section 4.6. Change OLD: At the IETF-70 meeting, and leading up to that meeting, the RADEXT WG debated whether or not RFC 4107 would require a RADIUS Crypto-Agility solution to feature Automated Key Management (AKM). The working group determined that AKM was not inherently required for RADIUS based on the following points: NEW: Consideration was given as to whether or not RFC 4107 would require a RADIUS Crypto-Agility solution to feature Automated Key Management (AKM). It was determined that AKM was not inherently required for RADIUS based on the following points: Nits: - Section 4.6, 1st paragraph after the bulleted list: Change .., the same time, … -> …, at the same time,... -- ----------------------------------------+----------------------------------- Reporter: mary.ietf.barnes@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jul 11 00:19:43 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 2D87221F88FE for ; Mon, 11 Jul 2011 00:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.374 X-Spam-Level: X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHqd-SsG2ZUo for ; Mon, 11 Jul 2011 00:19:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 125DB21F88D8 for ; Mon, 11 Jul 2011 00:19:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgAk2-000PFD-OW for radiusext-data0@psg.com; Mon, 11 Jul 2011 07:17:18 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgAjz-000PEu-3i for radiusext@ops.ietf.org; Mon, 11 Jul 2011 07:17:15 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QgAjx-0004yi-0g; Mon, 11 Jul 2011 00:17:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 11 Jul 2011 07:17:12 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: =?utf-8?q?Re=3A_=5Bradext=5D_=23101=3A_Secdir_review_of_draft-ie?= =?utf-8?q?tf-radext-crypto-agility-requirements-06=E2=80=8F?= X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/101#comment:1 Message-ID: <072.d6fc1008cb1475645509bf3e77d286c0@trac.tools.ietf.org> References: <063.921701c6d8a7e1501f2bc570ac34eb42@trac.tools.ietf.org> X-Trac-Ticket-ID: 101 In-Reply-To: <063.921701c6d8a7e1501f2bc570ac34eb42@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #101: Secdir review of draft-ietf-radext-crypto-agility-requirements-06‏ Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Proposed resolution is as follows: In Section 2 change "MUST NOT introduce new capabilities negotiation features" to "MUST NOT introduce generic new capabilities negotiation features". Change Section 4.3 to the following: 4.3. Backwards Compatibility Solutions MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both crypto-agility and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). While backward compatibility is needed to ease the transition between legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is only appropriate prior to the compromise of those mechanisms. After legacy mechanisms have been compromised, secure algorithms MUST be used, so that backward compatibility is no longer possible. Since RADIUS is a request/response protocol, the ability to negotiate cryptographic algorithms within a single RADIUS exchange is inherently limited. Prior to receipt of a response, a requester will not know what algorithms are supported by the responder. Therefore, while a RADIUS request can provide a list of supported cryptographic algorithms which can be selected for use within a response, prior to the receipt of a response, the cryptographic algorithms utilized to provide security services within an initial request will need to be pre-determined. In order to enable a request to be handled both by legacy as well as crypto-agile implementations, a request can be secured with legacy algorithms was well as with attributes providing security services using more secure algorithms. This approach allows a RADIUS packet to be processed by legacy implementations as well as by crypto-agile implementations, and does not result in additional response delays. If this technique is used, credentials used with legacy algorithms MUST be cryptographically independent of the credentials used with the more secure algorithms, so that compromise of the legacy credentials does not result in compromise of the credentials used with more secure algorithms. In this approach to backward compatibility, legacy mechanisms are initially used in requests sent between crypto-agile implementations. However, if the responder indicates support for crypto-agility, future requests can use more secure mechanisms. Note that if a responder is upgraded and then subsequently needs to be downgraded (e.g. due to bugs), this could result in requesters being unable to communicate with the downgraded responder unless a mechanism is provided to configure the requester to re-enable use of legacy algorithms. Probing techniques can be used to avoid the use of legacy algorithms in requests sent between crypto-agile implementations. For example, an initial request can omit use of legacy mechanisms. If a response is received, then the recipient can be assumed to be crypto-agile and future requests to that recipient can utilize secure mechanisms. Similarly, the responder can assume that the requester supports crypto-agility and can prohibit use of legacy mechanisms in future requests. Note that if a requester is upgraded and then subsequently needs to be downgraded (e.g. due to bugs), this could result in the requester being unable to interpret responses, unless a mechanism is provided to configure the responder to re-enable use of legacy algorithms. If a response is not received, in the absence of information indicating responder support for crypto-agility (such as pre- configuration or previous receipt of a crypto-agile response), a new request can be composed utilizing legacy mechanisms. Since legacy implementations not supporting crypto-agility will silently discard requests not protected by legacy algorithms rather than returning an error, repeated requests can be required to distinguish lack of support for crypto-agility from packet loss or other failure conditions. Therefore probing techniques can delay initial communication between crypto-agile requesters and legacy responders. This can be addressed by upgrading the responders (e.g. RADIUS servers) first. -- ------------------------------------+--------------------------------------- Reporter: charliek@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jul 11 00:39:09 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 10F4921F873E for ; Mon, 11 Jul 2011 00:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPh4DmQJyHsE for ; Mon, 11 Jul 2011 00:39:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 197A121F870F for ; Mon, 11 Jul 2011 00:39:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgB2o-000PnE-QK for radiusext-data0@psg.com; Mon, 11 Jul 2011 07:36:42 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgB2m-000Pn3-2e for radiusext@ops.ietf.org; Mon, 11 Jul 2011 07:36:40 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QgB2W-0001qp-EN; Mon, 11 Jul 2011 00:36:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-radext-ipv6-access@tools.ietf.org, roberta.maglione@telecomitalia.it X-Trac-Project: radext Date: Mon, 11 Jul 2011 07:36:24 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #102: Comments on draft-ietf-radext-ipv6-access-04 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/102 Message-ID: <074.87f6e6ae0de4961fd9bfd0855312923b@trac.tools.ietf.org> X-Trac-Ticket-ID: 102 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ipv6-access@tools.ietf.org, roberta.maglione@telecomitalia.it, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #102: Comments on draft-ietf-radext-ipv6-access-04 Hello, I read this document and I have some comments. This draft, in section 2.1, introduces Framed-IPv6-Address Attribute to be used for providing a DHCPv6 server residing on a NAS with one or more IPv6 addresses to be assigned to the clients. An alternative way to achieve a similar result is to extract an IPv6 address to be assigned, from a pool of addresses locally configured on the NAS. In my opinion it would be useful to add in this document a new attribute to allow the RADIUS server to convey a pool name to be used for DHCPv6 based addressing, when a single IPv6 address needs to be assigned to a host, to a NAS hosting a DHCPv6 server. I wrote an initial proposal in order to add the new attribute in the current draft, please see attached file. Any comments or feedback from the authors and from the group are welcome. Thanks, Best regards, Roberta Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. -- -----------------------------------------------+---------------------------- Reporter: roberta.maglione@… | Owner: draft-ietf-radext-ipv6-access@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: Active WG Document | Keywords: -----------------------------------------------+---------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jul 11 02:00: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 1A77C21F8922 for ; Mon, 11 Jul 2011 02:00: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANIfaOHZyIuV for ; Mon, 11 Jul 2011 02:00:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id AC0C421F8684 for ; Mon, 11 Jul 2011 02:00:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgCI5-0002Kd-L1 for radiusext-data0@psg.com; Mon, 11 Jul 2011 08:56:33 +0000 Received: from out45-ams.mf.surf.net ([145.0.1.45]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgCI2-0002KH-9Y for radiusext@ops.ietf.org; Mon, 11 Jul 2011 08:56:30 +0000 Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6B8uJjv006168; Mon, 11 Jul 2011 10:56:19 +0200 Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=macmini.wierenga.net) by teletubbie.het.net.je with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgCHW-000Ly7-2m; Mon, 11 Jul 2011 10:55:58 +0200 Message-ID: <4E1ABAB2.70401@wierenga.net> Date: Mon, 11 Jul 2011 10:56:18 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" , "Romascanu, Dan (Dan)" CC: "'radiusext@ops.ietf.org'" Subject: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request References: <9BC2F7926B33FE4AB10D69891D58FC1C5C753B978A@GVW0671EXC.americas.hpqcorp.net> <4E072543.5070903@wierenga.net> In-Reply-To: <4E072543.5070903@wierenga.net> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0vF6wUjEm - e17166b113f5 - 20110711 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.45 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mauricio, Dan, Is it too much to expect a response to my e-mail? It is not even that I care *that* much about the issue at hand, but I find the style of communication (or rather the lack thereof) extremely disappointing..... Klaas On 6/26/11 2:25 PM, Klaas Wierenga wrote: > On 6/24/11 9:42 PM, Sanchez, Mauricio (HP Networking) wrote: > > Mauricio, > > I find this procedure rather odd. I think at the very least you > should have forwarded the replies to the proper list before the poll > closed. Far be it from me to suggest any conspiracy, but I find it > inappropriate to come up with a rabbit from the hat trick after the > poll has closed. I thought consensus was gauged on the list, not at > some private alias? I have seen no discussion on the list, apart from > Avi's responses (thanks for that!), where do all these people all of > a sudden come from? And does it matter what company they represent? I > was under the impression that "we are all individuals"..... > > Can I ask for some more openness in future consensus polls? > > Klaas (who is ashamed that after expressing his opinion in the > meeting, then on the list, he missed the final consensus call) > > >> After discussion between current chairs and AD, the conclusion we >> have reached is to approve this request as we believe rough >> consensus for approval has been achieved. The situation is bit >> peculiar in that a number of industry individuals expressed >> themselves in favor of approving the request, but sent their email >> to the incorrect email address (owner-radiusext@ops.ietf.org rather >> than radiusext@ops.ietf.org). I have attached the emails for all >> those individuals who used the incorrect address. > >> The chairs appreciate the spirited conversation arising from this >> topic and do agree with the long-term RADIUS experts that these >> new types are not entirely in-line given the definition and past >> usage of the attribute. However, the chairs feel the misalignment >> between these new types and the attribute definition is not >> sufficiently large to warrant disallowing the allocation. We also >> took into account the industry support for immediate usage of these >> types into account. > >> So as to improve the usability of these new values, we will be >> asking IANA to include references to the appropriate WiMAX >> standards (and sections if available) in the IANA registry. Avi: >> We'd appreciate your assistance in getting us the right information >> to include. > >> If after this decision the WG would like to continue exploring a >> generalized solution to similar use cases, the chairs and AD are >> supportive. > >> -MS > >> -------------------------------------------------------------------------------------------------- > >> Final count In Favor Clearwire - Dave McGiniss, David Holmes ZTE >> - Chu Li Alcatel - Pertez Feder Intel - Muthiah Venkatachala Huawei >> - Ronal Mao Samsun - Jungshin Park NSN - Seyeedi Shahab Sprint - >> Mark Lipford, Brent Hirschman Bridgewater - Avi Lior > >> Opposed Alan DeKok Stefan Winter Bernard Aboba Dave Nelson > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org > with the word 'unsubscribe' in a single line as the message text > body. archive: -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4aurEACgkQH2Wy/p4XeFJqngCfXBDweUhBoECg7CnT1VQQk69z Kc0AoKbsOhLXz1HhrKZpNnn6roZaZpIK =pNbq -----END PGP SIGNATURE----- -- to 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 Jul 11 02:06:11 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 69ABB21F8893 for ; Mon, 11 Jul 2011 02:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpMEizOFempX for ; Mon, 11 Jul 2011 02:06:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id D08B321F8828 for ; Mon, 11 Jul 2011 02:06:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgCPe-0002e3-B8 for radiusext-data0@psg.com; Mon, 11 Jul 2011 09:04:22 +0000 Received: from liberty.deployingradius.com ([88.191.76.128]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgCPc-0002dZ-57 for radiusext@ops.ietf.org; Mon, 11 Jul 2011 09:04:20 +0000 Message-ID: <4E1ABC91.6020209@deployingradius.com> Date: Mon, 11 Jul 2011 11:04:17 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Klaas Wierenga CC: "Sanchez, Mauricio (HP Networking)" , "Romascanu, Dan (Dan)" , "'radiusext@ops.ietf.org'" Subject: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request References: <9BC2F7926B33FE4AB10D69891D58FC1C5C753B978A@GVW0671EXC.americas.hpqcorp.net> <4E072543.5070903@wierenga.net> <4E1ABAB2.70401@wierenga.net> In-Reply-To: <4E1ABAB2.70401@wierenga.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Klaas Wierenga wrote: > Is it too much to expect a response to my e-mail? It is not even that I > care *that* much about the issue at hand, but I find the style of > communication (or rather the lack thereof) extremely disappointing..... I concur. I'd like to appeal the decision. 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 Jul 11 02:53:23 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 1ADE521F852B for ; Mon, 11 Jul 2011 02:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.159 X-Spam-Level: X-Spam-Status: No, score=-103.159 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qM6quzAjxuF for ; Mon, 11 Jul 2011 02:53:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id CC95121F8AEE for ; Mon, 11 Jul 2011 02:53:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgD99-0004B8-8V for radiusext-data0@psg.com; Mon, 11 Jul 2011 09:51:23 +0000 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by psg.com with esmtps (TLSv1:SEED-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgD95-0004A3-OX for radiusext@ops.ietf.org; Mon, 11 Jul 2011 09:51:20 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAEHGGk6HCzI1/2dsb2JhbABTmAKPN3erdwKadoM1giZfBJBJhyaLLg X-IronPort-AV: E=Sophos;i="4.65,514,1304308800"; d="scan'208";a="255889969" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Jul 2011 05:50:14 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Jul 2011 05:43:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Date: Mon, 11 Jul 2011 11:50:10 +0200 Message-ID: In-Reply-To: <4E1ABAB2.70401@wierenga.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acw/qGroPLRPVVIuT92exsJYRojJRgABr5tA References: <9BC2F7926B33FE4AB10D69891D58FC1C5C753B978A@GVW0671EXC.americas.hpqcorp.net> <4E072543.5070903@wierenga.net> <4E1ABAB2.70401@wierenga.net> From: "Romascanu, Dan (Dan)" To: "Klaas Wierenga" , "Sanchez, Mauricio (HP Networking)" Cc: Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi Mauricio,=20 I believe that Klaas has a point here. As WG chair you and/or your co-chair should respond to Klaas's mail and address his concerns about the way the consensus call was conducted. =20 Thanks and Regards, Dan=20 > -----Original Message----- > From: Klaas Wierenga [mailto:klaas@wierenga.net] > Sent: Monday, July 11, 2011 11:56 AM > To: Sanchez, Mauricio (HP Networking); Romascanu, Dan (Dan) > Cc: 'radiusext@ops.ietf.org' > Subject: Re: Conclusion of RADEXT WG call for consensus poll for IANA > #409959 NAS-Port-Type value request >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Mauricio, Dan, >=20 > Is it too much to expect a response to my e-mail? It is not even that I > care *that* much about the issue at hand, but I find the style of > communication (or rather the lack thereof) extremely disappointing..... >=20 > Klaas >=20 > On 6/26/11 2:25 PM, Klaas Wierenga wrote: > > On 6/24/11 9:42 PM, Sanchez, Mauricio (HP Networking) wrote: > > > > Mauricio, > > > > I find this procedure rather odd. I think at the very least you > > should have forwarded the replies to the proper list before the poll > > closed. Far be it from me to suggest any conspiracy, but I find it > > inappropriate to come up with a rabbit from the hat trick after the > > poll has closed. I thought consensus was gauged on the list, not at > > some private alias? I have seen no discussion on the list, apart from > > Avi's responses (thanks for that!), where do all these people all of > > a sudden come from? And does it matter what company they represent? I > > was under the impression that "we are all individuals"..... > > > > Can I ask for some more openness in future consensus polls? > > > > Klaas (who is ashamed that after expressing his opinion in the > > meeting, then on the list, he missed the final consensus call) > > > > > >> After discussion between current chairs and AD, the conclusion we > >> have reached is to approve this request as we believe rough > >> consensus for approval has been achieved. The situation is bit > >> peculiar in that a number of industry individuals expressed > >> themselves in favor of approving the request, but sent their email > >> to the incorrect email address (owner-radiusext@ops.ietf.org rather > >> than radiusext@ops.ietf.org). I have attached the emails for all > >> those individuals who used the incorrect address. > > > >> The chairs appreciate the spirited conversation arising from this > >> topic and do agree with the long-term RADIUS experts that these > >> new types are not entirely in-line given the definition and past > >> usage of the attribute. However, the chairs feel the misalignment > >> between these new types and the attribute definition is not > >> sufficiently large to warrant disallowing the allocation. We also > >> took into account the industry support for immediate usage of these > >> types into account. > > > >> So as to improve the usability of these new values, we will be > >> asking IANA to include references to the appropriate WiMAX > >> standards (and sections if available) in the IANA registry. Avi: > >> We'd appreciate your assistance in getting us the right information > >> to include. > > > >> If after this decision the WG would like to continue exploring a > >> generalized solution to similar use cases, the chairs and AD are > >> supportive. > > > >> -MS > > > >> -------------------------------------------------------------------- > ------------------------------ > > > >> Final count In Favor Clearwire - Dave McGiniss, David Holmes ZTE > >> - Chu Li Alcatel - Pertez Feder Intel - Muthiah Venkatachala Huawei > >> - Ronal Mao Samsun - Jungshin Park NSN - Seyeedi Shahab Sprint - > >> Mark Lipford, Brent Hirschman Bridgewater - Avi Lior > > > >> Opposed Alan DeKok Stefan Winter Bernard Aboba Dave Nelson > > > > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org > > with the word 'unsubscribe' in a single line as the message text > > body. archive: >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk4aurEACgkQH2Wy/p4XeFJqngCfXBDweUhBoECg7CnT1VQQk69z > Kc0AoKbsOhLXz1HhrKZpNnn6roZaZpIK > =3DpNbq > -----END PGP SIGNATURE----- -- to 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 Jul 11 02:58: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 7AF9D21F8AB0 for ; Mon, 11 Jul 2011 02:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7Ev3AUCw28M for ; Mon, 11 Jul 2011 02:58:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 96D1721F8611 for ; Mon, 11 Jul 2011 02:58:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgDD8-0004Kc-Q0 for radiusext-data0@psg.com; Mon, 11 Jul 2011 09:55:30 +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 1QgDD6-0004KS-IJ for radiusext@ops.ietf.org; Mon, 11 Jul 2011 09:55:28 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAANLHGk6HCzI1/2dsb2JhbABTmAKPN3eIeqJbApp2hVtfBJdviy4 X-IronPort-AV: E=Sophos;i="4.65,514,1304308800"; d="scan'208";a="289918315" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Jul 2011 05:55:26 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Jul 2011 05:48:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Date: Mon, 11 Jul 2011 11:55:24 +0200 Message-ID: In-Reply-To: <4E1ABC91.6020209@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acw/qZTU08scupyOSUq4fRHZO+bQZwABskgw References: <9BC2F7926B33FE4AB10D69891D58FC1C5C753B978A@GVW0671EXC.americas.hpqcorp.net> <4E072543.5070903@wierenga.net> <4E1ABAB2.70401@wierenga.net> <4E1ABC91.6020209@deployingradius.com> From: "Romascanu, Dan (Dan)" To: "Alan DeKok" , "Klaas Wierenga" Cc: "Sanchez, Mauricio (HP Networking)" , Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi Alan,=20 If this is a formal appeal to the WG chairs, please formulate it in a more detailed manner. I recommend that you read RFC 2026, section 6.5, and especially 6.5.1 and 6.5.4 to start with.=20 As per 6.5.4:=20 > All appeals must include a detailed and specific description of the facts of the dispute. =20 Thanks and Regards, Dan=20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Monday, July 11, 2011 12:04 PM > To: Klaas Wierenga > Cc: Sanchez, Mauricio (HP Networking); Romascanu, Dan (Dan); > 'radiusext@ops.ietf.org' > Subject: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll > for IANA #409959 NAS-Port-Type value request >=20 > Klaas Wierenga wrote: > > Is it too much to expect a response to my e-mail? It is not even that > I > > care *that* much about the issue at hand, but I find the style of > > communication (or rather the lack thereof) extremely > disappointing..... >=20 > I concur. >=20 > I'd like to appeal the decision. >=20 > Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jul 11 07:26: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 59DA621F86E8 for ; Mon, 11 Jul 2011 07:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctBDqthJE6NI for ; Mon, 11 Jul 2011 07:26:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 38EDA21F86C3 for ; Mon, 11 Jul 2011 07:26:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgHPC-000H0g-PU for radiusext-data0@psg.com; Mon, 11 Jul 2011 14:24:14 +0000 Received: from out47-ams.mf.surf.net ([145.0.1.47]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgHP9-000H0W-IX for radiusext@ops.ietf.org; Mon, 11 Jul 2011 14:24:12 +0000 Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6BENtqE014428; Mon, 11 Jul 2011 16:23:55 +0200 Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=macmini.wierenga.net) by teletubbie.het.net.je with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgHOX-000NQz-Ic; Mon, 11 Jul 2011 16:23:33 +0200 Message-ID: <4E1B0779.1040302@wierenga.net> Date: Mon, 11 Jul 2011 16:23:53 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Dave Nelson CC: "Romascanu, Dan (Dan)" , Alan DeKok , "Sanchez, Mauricio (HP Networking)" , radiusext@ops.ietf.org Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request References: <9BC2F7926B33FE4AB10D69891D58FC1C5C753B978A@GVW0671EXC.americas.hpqcorp.net> <4E072543.5070903@wierenga.net> <4E1ABAB2.70401@wierenga.net> <4E1ABC91.6020209@deployingradius.com> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0vF6CnT4P - 9784bc45b06c - 20110711 X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.47 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dave, > It appears to me that the only thing that is in dispute is the > process issue of accepting comments not properly received on the > RADEXT WG email list, and forwarded to the list as part of the > decision announcement. true, and the unwillingness of the chair to respond to critique and questions... > Now, it's true that old-time IETF'ers tend to disdain "flash mob > voting", meaning a flurry of postings from individuals outside the > WG core membership, at the behest of the proponent of a particular > proposal. That appears to have been the case here, and explains why > postings were sent to the "request" address, rather that the list > itself. However, I don't believe that this form of input is > officially distinguished from any other form input under the IETF > process. ehm, I am not so sure about that. The request address is *not* a public address, and as such is different from the radext mailing list or a statement at the IETF meeting. If the chair can at his discretion pull out extra votes (why was my objection for example not noted, after all it is in the minutes of the IETF meeting?) > What's been demonstrated is that there are numerically more > supporters of this particular proposal outside the core RADEXT WG (or > IETF) than opponents to it inside the core RADEXT WG. Given that > this proposal have been languishing for quite some time, perhaps we > need to let it slide. While I agree that the usage in this proposal > not good I don't mind letting it slide, if you read my earlier message, I just asked Mauricio to in the future refrain from these practises and at the very least forward the messages prior to the close of the call (hey, I might want to organize my own "flash mob" if that is the new style ;-) I was willing to put this on the chairs inexperience, and a simple apology and promise not to use these shady tactics in the future would have made me perfectly happy. Our chair however decided to completely ignore any voices of concern. I find that rather insulting to those that do show up at the meetings and discuss on the mailing list. > RADIUS "form", the suggested alternatives all require the > specification of a new RADIUS attribute. That would have been a good > path to follow when the reuest was initially presented. Indeed Klaas > > Regards, > > Dave > > David B. Nelson Sr. Software Architect Elbrys Networks, Inc. > www.elbrys.com +1.603.570.2636 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4bB3kACgkQH2Wy/p4XeFK4zgCgjAQfRf1q9EOPRRZouXrUhBQk 9zUAoMFJbQuKDvcbVwbBdsOtuZbw8lNi =Zvi3 -----END PGP SIGNATURE----- -- to 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 Jul 11 08:50: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 0410A21F8E02 for ; Mon, 11 Jul 2011 08:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cL2rvEZGhLR3 for ; Mon, 11 Jul 2011 08:50:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1257E21F8D7D for ; Mon, 11 Jul 2011 08:50:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgIh5-000KBu-H7 for radiusext-data0@psg.com; Mon, 11 Jul 2011 15:46:47 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgIh2-000KBW-Ks for radiusext@ops.ietf.org; Mon, 11 Jul 2011 15:46:44 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QgIh0-0001sp-5N; Mon, 11 Jul 2011 08:46:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 11 Jul 2011 15:46:42 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #69: Section 1 X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/radext/trac/ticket/69#comment:5 Message-ID: <075.f34b47229a63ef9fe0f777cf35f9eaea@trac.tools.ietf.org> References: <066.2bae7a4d167a08e0f441859ab7024657@trac.tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <066.2bae7a4d167a08e0f441859ab7024657@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #69: Section 1 Changes (by wdec@…): * status: assigned => closed * resolution: => fixed Comment: resolved as proposed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jul 11 08:57:58 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 0F74B21F844C for ; Mon, 11 Jul 2011 08:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQTqL0qnBYGW for ; Mon, 11 Jul 2011 08:57:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9A53D21F84DF for ; Mon, 11 Jul 2011 08:57:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgIq9-000KZn-DT for radiusext-data0@psg.com; Mon, 11 Jul 2011 15:56:09 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgIq6-000KZV-C5 for radiusext@ops.ietf.org; Mon, 11 Jul 2011 15:56:06 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QgIq4-0000QL-Nc; Mon, 11 Jul 2011 08:56:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 11 Jul 2011 15:56:04 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #71: Section 2.3 and 3.3 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/71#comment:6 Message-ID: <075.f59b262e6544f845776c41915bc40df8@trac.tools.ietf.org> References: <066.72032b396a31a3350ac652b172d83b12@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <066.72032b396a31a3350ac652b172d83b12@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #71: Section 2.3 and 3.3 Changes (by wdec@…): * status: assigned => closed * resolution: => fixed Comment: accepted. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jul 11 08:59:03 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 D5C1821F8B82 for ; Mon, 11 Jul 2011 08:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lsK-PGoOMOf for ; Mon, 11 Jul 2011 08:59:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id D38DB21F8C3D for ; Mon, 11 Jul 2011 08:58:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgIrF-000Kcp-PC for radiusext-data0@psg.com; Mon, 11 Jul 2011 15:57:17 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgIrD-000Kcb-8T for radiusext@ops.ietf.org; Mon, 11 Jul 2011 15:57:15 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QgIrB-0000TF-AV; Mon, 11 Jul 2011 08:57:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 11 Jul 2011 15:57:13 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #61: DNS attribute for IPv4? X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/61#comment:5 Message-ID: <075.b6bd94c1e4d7b1d5d697751c7ab5b65b@trac.tools.ietf.org> References: <066.cc2411f6b119d81f73eec60b018d6670@trac.tools.ietf.org> X-Trac-Ticket-ID: 61 In-Reply-To: <066.cc2411f6b119d81f73eec60b018d6670@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #61: DNS attribute for IPv4? Changes (by wdec@…): * status: assigned => closed * resolution: => fixed Comment: resolved as proposed. -- ---------------------------------------+------------------------------------ Reporter: aland@… | Owner: wdec@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: ipv6-access | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jul 11 11:22: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 9537611E8143 for ; Mon, 11 Jul 2011 11:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6ELA3qyFDUs for ; Mon, 11 Jul 2011 11:22:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C3E0E21F8E32 for ; Mon, 11 Jul 2011 11:22:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgL5J-0000ea-Im for radiusext-data0@psg.com; Mon, 11 Jul 2011 18:19:57 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::1e]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgL5G-0000eA-Vj for radiusext@ops.ietf.org; Mon, 11 Jul 2011 18:19:55 +0000 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8226D21F8F0F for ; Mon, 11 Jul 2011 11:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8obigwfNeZkj; Mon, 11 Jul 2011 11:19:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06C221F8ED7; Mon, 11 Jul 2011 11:19:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action: draft-ietf-radext-ipv6-access-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711181952.26274.22717.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 11:19:52 -0700 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. Title : RADIUS attributes for IPv6 Access Networks Author(s) : Benoit Lourdelet Wojciech Dec Behcet Sarikaya Glen Zorn David Miles Filename : draft-ietf-radext-ipv6-access-05.txt Pages : 15 Date : 2011-07-11 This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement; assignment of a named IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host DHCPv6 addressing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-ipv6-access-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-ipv6-access-05.txt -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jul 11 11:22:59 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 A6ACC11E8142 for ; Mon, 11 Jul 2011 11:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l20qGR4TLSA2 for ; Mon, 11 Jul 2011 11:22:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 3C95C11E813E for ; Mon, 11 Jul 2011 11:22:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgL5m-0000g3-0x for radiusext-data0@psg.com; Mon, 11 Jul 2011 18:20:26 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QgL5j-0000ft-P9 for radiusext@ops.ietf.org; Mon, 11 Jul 2011 18:20:23 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QgL5c-0003ny-MY; Mon, 11 Jul 2011 11:20:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-radext-ipv6-access@tools.ietf.org, wdec@cisco.com X-Trac-Project: radext Date: Mon, 11 Jul 2011 18:20:16 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #102: Comments on draft-ietf-radext-ipv6-access-04 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/102#comment:1 Message-ID: <083.739796f0493290be957231da890d400a@trac.tools.ietf.org> References: <074.87f6e6ae0de4961fd9bfd0855312923b@trac.tools.ietf.org> X-Trac-Ticket-ID: 102 In-Reply-To: <074.87f6e6ae0de4961fd9bfd0855312923b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ipv6-access@tools.ietf.org, wdec@cisco.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #102: Comments on draft-ietf-radext-ipv6-access-04 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved with editorial changes into draft ver -05 -- -----------------------------------------------+---------------------------- Reporter: roberta.maglione@… | Owner: draft-ietf-radext-ipv6-access@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------------------+---------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jul 13 10:35:56 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 654BB11E820F for ; Wed, 13 Jul 2011 10:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-38uCpdo+v4 for ; Wed, 13 Jul 2011 10:35:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0BE11E8209 for ; Wed, 13 Jul 2011 10:35:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qh3IR-000IUb-PZ for radiusext-data0@psg.com; Wed, 13 Jul 2011 17:32:27 +0000 Received: from g5t0008.atlanta.hp.com ([15.192.0.45]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qh3IO-000ITD-6P for radiusext@ops.ietf.org; Wed, 13 Jul 2011 17:32:24 +0000 Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g5t0008.atlanta.hp.com (Postfix) with ESMTPS id 86DC824020; Wed, 13 Jul 2011 17:32:20 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 13 Jul 2011 17:30:52 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Wed, 13 Jul 2011 18:30:53 +0100 From: "Sanchez, Mauricio (HP Networking)" To: Klaas Wierenga CC: "'radiusext@ops.ietf.org'" Date: Wed, 13 Jul 2011 18:30:50 +0100 Subject: RE: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Topic: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acwz/CvBj0gBcTiJTlCXwzX2wH9ubQNgWw+w Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C777D39B1@GVW0671EXC.americas.hpqcorp.net> References: <9BC2F7926B33FE4AB10D69891D58FC1C5C753B978A@GVW0671EXC.americas.hpqcorp.net> <4E072543.5070903@wierenga.net> In-Reply-To: <4E072543.5070903@wierenga.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Klaas, It was during discussion between the chairs and AD after the close of the p= oll that we determined that responses had not been sent to the correct emai= l. I was copied directly on each email, so I didn't notice that emails wer= e going to the incorrect address during the polling period. Otherwise, I w= ould have immediately forwarded emails to the email list. This point of em= ails not going to the correct email was discussed between chairs and AD and= for just this particular request and situation, we decided that we would c= ount the approvals sent to incorrect email as part of establishing rough c= onsensus to approve the request. Moreover, we, the chairs and AD, felt tha= t given (a)the minor misalignment between these new types and the attribute= definition and (b) the industry support for this request, that we could pr= oceed forward. =20 You are right that it doesn't matter what companies individuals represent. = I included company names purely as informational and should not be interpr= eted in any way.=20 For this particular consensus poll, we actually went through two consensus = polling periods. The first was on April 4 and the second was on May 17. = We did the second because the first was inconclusive. Did you not receive = both? The chairs and AD have the good intentions of RADEXT in mind and we will de= finitely keep the group appropriately engaged moving forward. =20 -MS=20 -----Original Message----- From: Klaas Wierenga [mailto:klaas@wierenga.net]=20 Sent: Sunday, June 26, 2011 5:26 AM To: Sanchez, Mauricio (HP Networking) Cc: 'radiusext@ops.ietf.org' Subject: Re: Conclusion of RADEXT WG call for consensus poll for IANA #4099= 59 NAS-Port-Type value request -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/24/11 9:42 PM, Sanchez, Mauricio (HP Networking) wrote: Mauricio, I find this procedure rather odd. I think at the very least you should have= forwarded the replies to the proper list before the poll closed. Far be it from me to suggest any conspiracy, but I find it inappropriate to= come up with a rabbit from the hat trick after the poll has closed. I thou= ght consensus was gauged on the list, not at some private alias? I have seen no discussion on the list, apart from Avi's responses (thanks f= or that!), where do all these people all of a sudden come from? And does it matter what company they represent? I was under the impression = that "we are all individuals"..... Can I ask for some more openness in future consensus polls? Klaas (who is ashamed that after expressing his opinion in the meeting, the= n on the list, he missed the final consensus call) > After discussion between current chairs and AD, the conclusion we have=20 > reached is to approve this request as we believe rough consensus for=20 > approval has been achieved. The situation is bit peculiar in that a=20 > number of industry individuals expressed themselves in favor of=20 > approving the request, but sent their email to the incorrect email=20 > address (owner-radiusext@ops.ietf.org rather than=20 > radiusext@ops.ietf.org). I have attached the emails for all those=20 > individuals who used the incorrect address. >=20 > The chairs appreciate the spirited conversation arising from this=20 > topic and do agree with the long-term RADIUS experts that these new=20 > types are not entirely in-line given the definition and past usage of > the attribute. However, the chairs feel the misalignment between > these new types and the attribute definition is not sufficiently large=20 > to warrant disallowing the allocation. We also took into account the=20 > industry support for immediate usage of these types into account. >=20 > So as to improve the usability of these new values, we will be asking=20 > IANA to include references to the appropriate WiMAX standards (and > sections if available) in the IANA registry. Avi: We'd appreciate > your assistance in getting us the right information to include. >=20 > If after this decision the WG would like to continue exploring a=20 > generalized solution to similar use cases, the chairs and AD are=20 > supportive. >=20 > -MS >=20 > ---------------------------------------------------------------------- > ---------------------------- > > Final count In Favor Clearwire - Dave McGiniss, David Holmes ZTE -=20 > Chu Li Alcatel - Pertez Feder Intel - Muthiah Venkatachala Huawei -=20 > Ronal Mao Samsun - Jungshin Park NSN - Seyeedi Shahab Sprint - Mark=20 > Lipford, Brent Hirschman Bridgewater - Avi Lior >=20 > Opposed Alan DeKok Stefan Winter Bernard Aboba Dave Nelson -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4HJUMACgkQH2Wy/p4XeFJpOwCdF+yKyZdjhuZdRLGkGrCdsj68 weEAnAiv2I8hkMYF0bQsk096qjFTi/69 =3DZmUy -----END PGP SIGNATURE----- -- to 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 Jul 13 10:54: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 7CACE21F867F for ; Wed, 13 Jul 2011 10:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEa0hQWKZUap for ; Wed, 13 Jul 2011 10:54:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBF121F865B for ; Wed, 13 Jul 2011 10:54:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qh3c3-000JVc-UL for radiusext-data0@psg.com; Wed, 13 Jul 2011 17:52:43 +0000 Received: from g4t0017.houston.hp.com ([15.201.24.20]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qh3bx-000JVC-0N for radiusext@ops.ietf.org; Wed, 13 Jul 2011 17:52:37 +0000 Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id 19CFA385B6; Wed, 13 Jul 2011 17:52:34 +0000 (UTC) Received: from G6W0644.americas.hpqcorp.net (16.230.34.80) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 13 Jul 2011 17:50:15 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G6W0644.americas.hpqcorp.net ([16.230.34.80]) with mapi; Wed, 13 Jul 2011 18:50:14 +0100 From: "Sanchez, Mauricio (HP Networking)" To: Dave Nelson , "Romascanu, Dan (Dan)" CC: Alan DeKok , Klaas Wierenga , "radiusext@ops.ietf.org" Date: Wed, 13 Jul 2011 18:50:13 +0100 Subject: RE: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Topic: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acw/0Kq0dRgTkdnoRTOF5QwqcYIycQBsrArw Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C777D39DA@GVW0671EXC.americas.hpqcorp.net> References: <9BC2F7926B33FE4AB10D69891D58FC1C5C753B978A@GVW0671EXC.americas.hpqcorp.net> <4E072543.5070903@wierenga.net> <4E1ABAB2.70401@wierenga.net> <4E1ABC91.6020209@deployingradius.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D39DAGVW0671EXCame_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D39DAGVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As I stated in my previous message, this situation of incorrect list addres= s usage was discussed between the chairs and the AD. Given the fact that t= his proposal had been languishing for some time, that the request wasn't an= egregious violation of RADIUS, alternatives would require a new attribute,= industry was waiting for an answer from RADEXT, the chairs and AD felt tha= t we could proceed forward in counting these non-standard votes of approval= . There are times to be pedantic and times where we should not be, and so = we made the call to let this one "slide". Unless the AD has different guidance, I intend to be stricter in future ins= tances and not let non-standard votes be considered. -MS From: Dave Nelson [mailto:dnelson@elbrys.com] Sent: Monday, July 11, 2011 6:45 AM To: Romascanu, Dan (Dan) Cc: Alan DeKok; Klaas Wierenga; Sanchez, Mauricio (HP Networking); radiusex= t@ops.ietf.org Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll fo= r IANA #409959 NAS-Port-Type value request On Mon, Jul 11, 2011 at 5:55 AM, Romascanu, Dan (Dan) > wrote: > All appeals must include a detailed and specific description of the > facts of the dispute. It appears to me that the only thing that is in dispute is the process issu= e of accepting comments not properly received on the RADEXT WG email list, = and forwarded to the list as part of the decision announcement. Now, it's true that old-time IETF'ers tend to disdain "flash mob voting", m= eaning a flurry of postings from individuals outside the WG core membership= , at the behest of the proponent of a particular proposal. That appears to= have been the case here, and explains why postings were sent to the "reque= st" address, rather that the list itself. However, I don't believe that th= is form of input is officially distinguished from any other form input unde= r the IETF process. What's been demonstrated is that there are numerically more supporters of t= his particular proposal outside the core RADEXT WG (or IETF) than opponents= to it inside the core RADEXT WG. Given that this proposal have been langu= ishing for quite some time, perhaps we need to let it slide. While I agree= that the usage in this proposal not good RADIUS "form", the suggested alte= rnatives all require the specification of a new RADIUS attribute. That wou= ld have been a good path to follow when the reuest was initially presented. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D39DAGVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As I stat= ed in my previous message, this situation of incorrect list address usage w= as discussed between the chairs and the AD.  Given the fact that this = proposal had been languishing for some time, that the request wasn’t = an egregious violation of RADIUS, alternatives would require a new attribut= e, industry was waiting for an answer from RADEXT, the chairs and AD felt t= hat we could proceed forward in counting these non-standard votes of approv= al.  There are times to be pedantic and times where we should not be, = and so we made the call to let this one “slide”.

 

Unless the AD has different guidance, I intend to be stric= ter in future instances and not let non-standard votes be considered. =

 

-MS

 

 

 

From: Dave Nelson [mailto:dnelson@elbrys.com]
Sent: Monday, July 11, 2011 6:45 AM
To: Romascanu, Dan (Dan)
Cc= : Alan DeKok; Klaas Wierenga; Sanchez, Mauricio (HP Networking); radius= ext@ops.ietf.org
Subject: Re: APPEAL: Re: Conclusion of RADEXT WG= call for consensus poll for IANA #409959 NAS-Port-Type value request<= /o:p>

 

On Mon, Jul 11, 2011 at 5:55 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:


>    All appeals must include a detailed and specific des= cription of the
>    facts of the dispute.

 

It appears to me that the only thing that is in dispute is t= he process issue of accepting comments not properly received = ;on the RADEXT WG email list, and forwarded to the list= as part of the decision announcement.

 

Now, it= 's true that old-time IETF'ers tend to disdain "flash mob voting"= , meaning a flurry of postings from individuals outside the WG core members= hip, at the behest of the proponent of a particular proposal.  That ap= pears to have been the case here, and explains why postings were sent to th= e "request" address, rather that the list itself.  However, = I don't believe that this form of input is officially distin= guished from any other form input under the IETF process.

 

What's been demonstrated is that there are = numerically more supporters of this particular proposal outside the core RA= DEXT WG (or IETF) than opponents to it inside the core RADEXT WG.=  Given that this proposal have been languishing f= or quite some time, perhaps we need to let it slide.  While I agree th= at the usage in this proposal not good RADIUS "form", the suggest= ed alternatives all require the specification of a new RADIUS att= ribute.  That would have been a good path to follow whe= n the reuest was initially presented.

 

Regards,

Dave

David B. Nelson
Sr. Software ArchitectElbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D39DAGVW0671EXCame_-- -- to 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 Jul 13 11:10:16 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 4A12921F8BDA for ; Wed, 13 Jul 2011 11:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTWDQUupqwlr for ; Wed, 13 Jul 2011 11:10:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF6121F8BDB for ; Wed, 13 Jul 2011 11:10:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qh3q9-000KWF-7d for radiusext-data0@psg.com; Wed, 13 Jul 2011 18:07:17 +0000 Received: from g1t0029.austin.hp.com ([15.216.28.36]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qh3q3-000KVy-I8 for radiusext@ops.ietf.org; Wed, 13 Jul 2011 18:07:11 +0000 Received: from G2W1953G.americas.hpqcorp.net (gvt0525.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id 961FB385D7; Wed, 13 Jul 2011 18:07:08 +0000 (UTC) Received: from G5W0602.americas.hpqcorp.net (16.228.9.185) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 13 Jul 2011 18:05:34 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0602.americas.hpqcorp.net ([16.228.9.185]) with mapi; Wed, 13 Jul 2011 19:05:33 +0100 From: "Sanchez, Mauricio (HP Networking)" To: Klaas Wierenga , Dave Nelson CC: "Romascanu, Dan (Dan)" , Alan DeKok , "radiusext@ops.ietf.org" Date: Wed, 13 Jul 2011 19:05:32 +0100 Subject: RE: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Topic: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acw/1jK5VK4bNVSmTG2ucH/9AjIlawBryv9g Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C777D3A03@GVW0671EXC.americas.hpqcorp.net> References: <9BC2F7926B33FE4AB10D69891D58FC1C5C753B978A@GVW0671EXC.americas.hpqcorp.net> <4E072543.5070903@wierenga.net> <4E1ABAB2.70401@wierenga.net> <4E1ABC91.6020209@deployingradius.com> <4E1B0779.1040302@wierenga.net> In-Reply-To: <4E1B0779.1040302@wierenga.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Klaas, Apologies for my lack of response as I have been taking some time off these= last couple of weeks and I've clearly let RADEXT fall through the cracks. = As I stated in my response to Dave, this situation was discussed between t= he chairs and AD and we all agreed that we could move forward in this parti= cular instance. Unless guidance differs from the AD, I've taken note that = in future discussions we should not be as tolerant of non-standard comments= . =20 As for the flash mob effect, I've been in IETF long enough to see it happen= . They do happen and will continue to happen. It's the nature of our busin= ess. However, I fully agree with you that crystal clear transparency and t= imeliness is necessary. You have my commitment moving forward.=20 BTW, the official minutes for IETF 80 RADEXT state that you had no opinion = on this IANA request, so at least from the minutes there's no clear indicat= ion of your approval or disapproval. In hindsight, Bernard and I should ha= ve done a hum poll or such during the meeting.=20 -MS=20 =20 -----Original Message----- From: Klaas Wierenga [mailto:klaas@wierenga.net]=20 Sent: Monday, July 11, 2011 7:24 AM To: Dave Nelson Cc: Romascanu, Dan (Dan); Alan DeKok; Sanchez, Mauricio (HP Networking); ra= diusext@ops.ietf.org Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll fo= r IANA #409959 NAS-Port-Type value request -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dave, > It appears to me that the only thing that is in dispute is the process=20 > issue of accepting comments not properly received on the RADEXT WG=20 > email list, and forwarded to the list as part of the decision=20 > announcement. true, and the unwillingness of the chair to respond to critique and questio= ns... > Now, it's true that old-time IETF'ers tend to disdain "flash mob=20 > voting", meaning a flurry of postings from individuals outside the WG=20 > core membership, at the behest of the proponent of a particular=20 > proposal. That appears to have been the case here, and explains why=20 > postings were sent to the "request" address, rather that the list=20 > itself. However, I don't believe that this form of input is=20 > officially distinguished from any other form input under the IETF=20 > process. ehm, I am not so sure about that. The request address is *not* a public add= ress, and as such is different from the radext mailing list or a statement = at the IETF meeting. If the chair can at his discretion pull out extra vote= s (why was my objection for example not noted, after all it is in the minut= es of the IETF meeting?) > What's been demonstrated is that there are numerically more supporters=20 > of this particular proposal outside the core RADEXT WG (or > IETF) than opponents to it inside the core RADEXT WG. Given that this=20 > proposal have been languishing for quite some time, perhaps we need to=20 > let it slide. While I agree that the usage in this proposal not good I don't mind letting it slide, if you read my earlier message, I just asked= Mauricio to in the future refrain from these practises and at the very lea= st forward the messages prior to the close of the call (hey, I might want t= o organize my own "flash mob" if that is the new style ;-) I was willing to= put this on the chairs inexperience, and a simple apology and promise not = to use these shady tactics in the future would have made me perfectly happy= . Our chair however decided to completely ignore any voices of concern. I f= ind that rather insulting to those that do show up at the meetings and disc= uss on the mailing list. > RADIUS "form", the suggested alternatives all require the=20 > specification of a new RADIUS attribute. That would have been a good=20 > path to follow when the reuest was initially presented. Indeed Klaas >=20 > Regards, >=20 > Dave >=20 > David B. Nelson Sr. Software Architect Elbrys Networks, Inc.=20 > www.elbrys.com +1.603.570.2636 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4bB3kACgkQH2Wy/p4XeFK4zgCgjAQfRf1q9EOPRRZouXrUhBQk 9zUAoMFJbQuKDvcbVwbBdsOtuZbw8lNi =3DZvi3 -----END PGP SIGNATURE----- -- to 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 Jul 13 11:13:56 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 1158A21F8BF4 for ; Wed, 13 Jul 2011 11:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5k5r0B0vIAUb for ; Wed, 13 Jul 2011 11:13:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0D521F8BED for ; Wed, 13 Jul 2011 11:13:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qh3uj-000Kjw-Qt for radiusext-data0@psg.com; Wed, 13 Jul 2011 18:12:01 +0000 Received: from out42-ams.mf.surf.net ([145.0.1.42]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qh3uc-000KjN-Dd for radiusext@ops.ietf.org; Wed, 13 Jul 2011 18:11:54 +0000 Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6DIBcCj004886; Wed, 13 Jul 2011 20:11:38 +0200 Received: from 5ed00726.cm-7-1a.dynamic.ziggo.nl ([94.208.7.38] helo=[192.168.1.100]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qh3ty-000APr-U6; Wed, 13 Jul 2011 20:11:15 +0200 References: <9BC2F7926B33FE4AB10D69891D58FC1C5C753B978A@GVW0671EXC.americas.hpqcorp.net> <4E072543.5070903@wierenga.net> <4E1ABAB2.70401@wierenga.net> <4E1ABC91.6020209@deployingradius.com> <4E1B0779.1040302@wierenga.net> <9BC2F7926B33FE4AB10D69891D58FC1C5C777D3A03@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5C777D3A03@GVW0671EXC.americas.hpqcorp.net> Mime-Version: 1.0 (iPad Mail 8J3) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7E90A15D-210A-4B92-BE0F-E8F3F6F39FB1@wierenga.net> Cc: Dave Nelson , "Romascanu, Dan (Dan)" , Alan DeKok , "radiusext@ops.ietf.org" X-Mailer: iPad Mail (8J3) From: Klaas Wierenga Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Date: Wed, 13 Jul 2011 20:12:18 +0200 To: "Sanchez, Mauricio (HP Networking)" X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0vF7ubCrH - e94d9d2d37f8 - 20110713 X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.42 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Mauricio, Thanks for the clarification and for the assurance that this is a one off oc= casion. Klaas On Jul 13, 2011, at 8:05 PM, "Sanchez, Mauricio (HP Networking)" wrote: > Klaas, > Apologies for my lack of response as I have been taking some time off thes= e last couple of weeks and I've clearly let RADEXT fall through the cracks. = As I stated in my response to Dave, this situation was discussed between th= e chairs and AD and we all agreed that we could move forward in this particu= lar instance. Unless guidance differs from the AD, I've taken note that in f= uture discussions we should not be as tolerant of non-standard comments. =20= >=20 > As for the flash mob effect, I've been in IETF long enough to see it happe= n. They do happen and will continue to happen. It's the nature of our busin= ess. However, I fully agree with you that crystal clear transparency and ti= meliness is necessary. You have my commitment moving forward.=20 >=20 > BTW, the official minutes for IETF 80 RADEXT state that you had no opinion= on this IANA request, so at least from the minutes there's no clear indicat= ion of your approval or disapproval. In hindsight, Bernard and I should hav= e done a hum poll or such during the meeting.=20 >=20 > -MS=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Klaas Wierenga [mailto:klaas@wierenga.net]=20 > Sent: Monday, July 11, 2011 7:24 AM > To: Dave Nelson > Cc: Romascanu, Dan (Dan); Alan DeKok; Sanchez, Mauricio (HP Networking); r= adiusext@ops.ietf.org > Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll f= or IANA #409959 NAS-Port-Type value request >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Dave, >=20 >> It appears to me that the only thing that is in dispute is the process=20= >> issue of accepting comments not properly received on the RADEXT WG=20 >> email list, and forwarded to the list as part of the decision=20 >> announcement. >=20 > true, and the unwillingness of the chair to respond to critique and questi= ons... >=20 >> Now, it's true that old-time IETF'ers tend to disdain "flash mob=20 >> voting", meaning a flurry of postings from individuals outside the WG=20 >> core membership, at the behest of the proponent of a particular=20 >> proposal. That appears to have been the case here, and explains why=20 >> postings were sent to the "request" address, rather that the list=20 >> itself. However, I don't believe that this form of input is=20 >> officially distinguished from any other form input under the IETF=20 >> process. >=20 > ehm, I am not so sure about that. The request address is *not* a public ad= dress, and as such is different from the radext mailing list or a statement a= t the IETF meeting. If the chair can at his discretion pull out extra votes (= why was my objection for example not noted, after all it is in the minutes o= f the IETF meeting?) >=20 >> What's been demonstrated is that there are numerically more supporters=20= >> of this particular proposal outside the core RADEXT WG (or >> IETF) than opponents to it inside the core RADEXT WG. Given that this=20= >> proposal have been languishing for quite some time, perhaps we need to=20= >> let it slide. While I agree that the usage in this proposal not good >=20 > I don't mind letting it slide, if you read my earlier message, I just aske= d Mauricio to in the future refrain from these practises and at the very lea= st forward the messages prior to the close of the call (hey, I might want to= organize my own "flash mob" if that is the new style ;-) I was willing to p= ut this on the chairs inexperience, and a simple apology and promise not to u= se these shady tactics in the future would have made me perfectly happy. Our= chair however decided to completely ignore any voices of concern. I find th= at rather insulting to those that do show up at the meetings and discuss on t= he mailing list. >=20 >> RADIUS "form", the suggested alternatives all require the=20 >> specification of a new RADIUS attribute. That would have been a good=20 >> path to follow when the reuest was initially presented. >=20 > Indeed >=20 > Klaas >=20 >>=20 >> Regards, >>=20 >> Dave >>=20 >> David B. Nelson Sr. Software Architect Elbrys Networks, Inc.=20 >> www.elbrys.com +1.603.570.2636 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk4bB3kACgkQH2Wy/p4XeFK4zgCgjAQfRf1q9EOPRRZouXrUhBQk > 9zUAoMFJbQuKDvcbVwbBdsOtuZbw8lNi > =3DZvi3 > -----END PGP SIGNATURE----- -- to 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 Jul 13 15:42:40 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 406E111E8077 for ; Wed, 13 Jul 2011 15:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.448 X-Spam-Level: X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owjwk7I-X9By for ; Wed, 13 Jul 2011 15:42:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEDD11E8075 for ; Wed, 13 Jul 2011 15:42:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qh86O-0006AS-4D for radiusext-data0@psg.com; Wed, 13 Jul 2011 22:40:20 +0000 Received: from g6t0184.atlanta.hp.com ([15.193.32.61]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qh86I-0006A7-2Q for radiusext@ops.ietf.org; Wed, 13 Jul 2011 22:40:14 +0000 Received: from G9W0369G.americas.hpqcorp.net (g9w0369g.houston.hp.com [16.216.193.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0184.atlanta.hp.com (Postfix) with ESMTPS id 3C386C102 for ; Wed, 13 Jul 2011 22:40:11 +0000 (UTC) Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G9W0369G.americas.hpqcorp.net (16.216.193.232) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 13 Jul 2011 22:37:18 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Wed, 13 Jul 2011 23:37:18 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" Date: Wed, 13 Jul 2011 23:37:16 +0100 Subject: RADEXT WG Agenda for IETF 81 - Take One Thread-Topic: RADEXT WG Agenda for IETF 81 - Take One Thread-Index: AcxBrUXPycXZ1yytT/CP9jOm6NKG+A== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C777D3CF5@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D3CF5GVW0671EXCame_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D3CF5GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RADEXT WG IETF 81 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Monday, July 25, 2011 0900 - 1130 Room 2101 9:00 - 09:20 AM, Preliminaries (20 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status IPv6 items (45 minutes) 9:20 - 9:35 AM Radius Extensions for CGN Configurations, Dean Cheng (15 min= utes) http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-radius-ext-00.txt 9:35 - 9:50 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec (15 = minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access 9:50 - 10:05 AM RADIUS accounting for traffic classes, Stefan Winter (15 mi= n) http://tools.ietf.org/html/draft-winter-radext-fancyaccounting Enhancement items (30 minutes) 10:05 AM - 10:15 AM Dynamic Peer Discovery, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery 10:15 - 10:25 AM RFC4282bis, Alan DeKok (10 minutes) 10:25 - 10:35 AM RADIUS Protocol Extensions, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions Security items (20 minutes) 10:35 - 10:45 AM RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls 10:45 - 10:55 AM RADIUS over TLS, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec Discussion and Wrap-up (35 minutes) 10:55 - 11:15 AM Discussion (20 minutes) 11:15 - 11:30 AM Next Steps: WG Chairs & ADs (15 minutes) --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D3CF5GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RADEXT WG IETF 8= 1 Agenda

 

Chairs:

Jouni Korhonen <= jouni.korhonen at nsn.com>

Mauricio S= anchez <mauricio.sanchez at hp.com>

 

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

 <= /p>

Monday, July 25, 2011

0900 - 1130

Room 2101<= /p>

 

9:00 - 09= :20 AM, Preliminaries (20 minutes)

=  

Audio/Video & Remote Presentation = Debugging

Note Well

Note Takers

Jabber scribe=

Agenda bash

Document Status

 

IPv6 items (45 minutes)

 

9:20 - 9:35 AM Radius E= xtensions for CGN Configurations, Dean Cheng (15 minutes)

http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-ra= dius-ext-00.txt

 

9:35 - 9:50 AM RADIUS Attributes for IPv6 Access Netw= orks, Wojcieh Dec (15 minutes)

http://tools.= ietf.org/html/draft-ietf-radext-ipv6-access

 

9:50 - 10:05 AM RADIUS ac= counting for traffic classes, Stefan Winter (15 min)

http://tools.ietf.org/html/draft-winter-radext-fancyaccountin= g

 

Enhancement items (30 minutes)

<= o:p> 

10:05 AM - 10:15 AM Dynamic Peer D= iscovery, Stefan Winter (10 minutes)

htt= p://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery<= /p>

 

10:15 - 1= 0:25 AM RFC4282bis, Alan DeKok (10 minutes)

 

10:25 - 10:35 AM RADIUS Proto= col Extensions, Alan DeKok (10 minutes)

= = http://tools.ietf.org/html/draft-ietf-radext-radius-extensions

 

Securi= ty items (20 minutes)

 <= /p>

10:35  - 10:45 AM RADIUS over DTLS, Alan DeKok= (10 minutes)

http://tools.ietf.org/html/draft-ietf-r= adext-dtls

 

10:45  - 10:55 AM RADIUS over TLS, Stefan Winter (10 = minutes)

http://tools.ietf.org/html/draft-ietf-rade= xt-radsec

 

Discussion and Wrap-up (35 minutes)

 

10:55 – 11:15 = AM Discussion (20 minutes)

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

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D3CF5GVW0671EXCame_-- -- to 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 Jul 13 22:52: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 14B9B1F0C39 for ; Wed, 13 Jul 2011 22:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.925 X-Spam-Level: X-Spam-Status: No, score=-102.925 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CizDcb+hRcT2 for ; Wed, 13 Jul 2011 22:52:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id B85441F0C36 for ; Wed, 13 Jul 2011 22:52:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QhEo9-000N6Y-89 for radiusext-data0@psg.com; Thu, 14 Jul 2011 05:49:57 +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 1QhEo2-000N5f-FU for radiusext@ops.ietf.org; Thu, 14 Jul 2011 05:49:50 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAACiDHk6HCzI1/2dsb2JhbABNBpgSjz93rlICm02DPIIfXwSYAYs1 X-IronPort-AV: E=Sophos;i="4.65,527,1304308800"; d="scan'208";a="290615639" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Jul 2011 01:49:41 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Jul 2011 01:42:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Date: Thu, 14 Jul 2011 07:49:39 +0200 Message-ID: In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5C777D3A03@GVW0671EXC.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acw/1jK5VK4bNVSmTG2ucH/9AjIlawBryv9gABhBZmA= References: <9BC2F7926B33FE4AB10D69891D58FC1C5C753B978A@GVW0671EXC.americas.hpqcorp.net> <4E072543.5070903@wierenga.net> <4E1ABAB2.70401@wierenga.net> <4E1ABC91.6020209@deployingradius.com> <4E1B0779.1040302@wierenga.net> <9BC2F7926B33FE4AB10D69891D58FC1C5C777D3A03@GVW0671EXC.americas.hpqcorp.net> From: "Romascanu, Dan (Dan)" To: "Sanchez, Mauricio (HP Networking)" , "Klaas Wierenga" , "Dave Nelson" Cc: "Alan DeKok" , Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi,=20 Thanks to all for the opinions and advice.=20 Before proceeding I think that it is important to hear also from Alan who was the first who introduced in the discussion (and subject line of the thread) the idea of an appeal. Alan, please clarify whether you intent to continue with a formal and detailed appeal to the WG chairs. If the answer is yes I would kindly ask that you describes exactly in your own words what you are appealing and which actions of the WG chairs would satisfy your concerns. If there is no intention to continue with a formal appeal this should also be made clear, and the WG can discuss if everybody is OK with the proposal and commitment of the WG chair (Mauricio).=20 Thanks and Regards, Dan=20 > -----Original Message----- > From: Sanchez, Mauricio (HP Networking) > [mailto:mauricio.sanchez@hp.com] > Sent: Wednesday, July 13, 2011 9:06 PM > To: Klaas Wierenga; Dave Nelson > Cc: Romascanu, Dan (Dan); Alan DeKok; radiusext@ops.ietf.org > Subject: RE: APPEAL: Re: Conclusion of RADEXT WG call for consensus > poll for IANA #409959 NAS-Port-Type value request >=20 > Klaas, > Apologies for my lack of response as I have been taking some time off > these last couple of weeks and I've clearly let RADEXT fall through the > cracks. As I stated in my response to Dave, this situation was > discussed between the chairs and AD and we all agreed that we could > move forward in this particular instance. Unless guidance differs from > the AD, I've taken note that in future discussions we should not be as > tolerant of non-standard comments. >=20 > As for the flash mob effect, I've been in IETF long enough to see it > happen. They do happen and will continue to happen. It's the nature of > our business. However, I fully agree with you that crystal clear > transparency and timeliness is necessary. You have my commitment > moving forward. >=20 > BTW, the official minutes for IETF 80 RADEXT state that you had no > opinion on this IANA request, so at least from the minutes there's no > clear indication of your approval or disapproval. In hindsight, > Bernard and I should have done a hum poll or such during the meeting. >=20 > -MS >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Klaas Wierenga [mailto:klaas@wierenga.net] > Sent: Monday, July 11, 2011 7:24 AM > To: Dave Nelson > Cc: Romascanu, Dan (Dan); Alan DeKok; Sanchez, Mauricio (HP > Networking); radiusext@ops.ietf.org > Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus > poll for IANA #409959 NAS-Port-Type value request >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Dave, >=20 > > It appears to me that the only thing that is in dispute is the > process > > issue of accepting comments not properly received on the RADEXT WG > > email list, and forwarded to the list as part of the decision > > announcement. >=20 > true, and the unwillingness of the chair to respond to critique and > questions... >=20 > > Now, it's true that old-time IETF'ers tend to disdain "flash mob > > voting", meaning a flurry of postings from individuals outside the WG > > core membership, at the behest of the proponent of a particular > > proposal. That appears to have been the case here, and explains why > > postings were sent to the "request" address, rather that the list > > itself. However, I don't believe that this form of input is > > officially distinguished from any other form input under the IETF > > process. >=20 > ehm, I am not so sure about that. The request address is *not* a public > address, and as such is different from the radext mailing list or a > statement at the IETF meeting. If the chair can at his discretion pull > out extra votes (why was my objection for example not noted, after all > it is in the minutes of the IETF meeting?) >=20 > > What's been demonstrated is that there are numerically more > supporters > > of this particular proposal outside the core RADEXT WG (or > > IETF) than opponents to it inside the core RADEXT WG. Given that > this > > proposal have been languishing for quite some time, perhaps we need > to > > let it slide. While I agree that the usage in this proposal not good >=20 > I don't mind letting it slide, if you read my earlier message, I just > asked Mauricio to in the future refrain from these practises and at the > very least forward the messages prior to the close of the call (hey, I > might want to organize my own "flash mob" if that is the new style ;-) > I was willing to put this on the chairs inexperience, and a simple > apology and promise not to use these shady tactics in the future would > have made me perfectly happy. Our chair however decided to completely > ignore any voices of concern. I find that rather insulting to those > that do show up at the meetings and discuss on the mailing list. >=20 > > RADIUS "form", the suggested alternatives all require the > > specification of a new RADIUS attribute. That would have been a good > > path to follow when the reuest was initially presented. >=20 > Indeed >=20 > Klaas >=20 > > > > Regards, > > > > Dave > > > > David B. Nelson Sr. Software Architect Elbrys Networks, Inc. > > www.elbrys.com +1.603.570.2636 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk4bB3kACgkQH2Wy/p4XeFK4zgCgjAQfRf1q9EOPRRZouXrUhBQk > 9zUAoMFJbQuKDvcbVwbBdsOtuZbw8lNi > =3DZvi3 > -----END PGP SIGNATURE----- -- to 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 Jul 14 08:51:51 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 8545321F8C6D for ; Thu, 14 Jul 2011 08:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKZvsr0uAVn9 for ; Thu, 14 Jul 2011 08:51:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 99EEF21F8B4C for ; Thu, 14 Jul 2011 08:51:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QhO9b-000PiZ-6Y for radiusext-data0@psg.com; Thu, 14 Jul 2011 15:48:43 +0000 Received: from liberty.deployingradius.com ([88.191.76.128]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QhO9Y-000Phc-1G for radiusext@ops.ietf.org; Thu, 14 Jul 2011 15:48:40 +0000 Message-ID: <4E1F0FCF.2010602@deployingradius.com> Date: Thu, 14 Jul 2011 17:48:31 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: "Sanchez, Mauricio (HP Networking)" , Klaas Wierenga , Dave Nelson , radiusext@ops.ietf.org Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request References: <9BC2F7926B33FE4AB10D69891D58FC1C5C753B978A@GVW0671EXC.americas.hpqcorp.net> <4E072543.5070903@wierenga.net> <4E1ABAB2.70401@wierenga.net> <4E1ABC91.6020209@deployingradius.com> <4E1B0779.1040302@wierenga.net> <9BC2F7926B33FE4AB10D69891D58FC1C5C777D3A03@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Romascanu, Dan (Dan) wrote: > Before proceeding I think that it is important to hear also from Alan > who was the first who introduced in the discussion (and subject line of > the thread) the idea of an appeal. Alan, please clarify whether you > intent to continue with a formal and detailed appeal to the WG chairs. I've discussed this with Mauricio privately. I won't be filing a formal appeal. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Jul 20 13:28:01 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 2D2AB21F8A80 for ; Wed, 20 Jul 2011 13:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.478 X-Spam-Level: X-Spam-Status: No, score=-106.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GDn6wj46TXv for ; Wed, 20 Jul 2011 13:28:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB1121F8A64 for ; Wed, 20 Jul 2011 13:27:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QjdKB-000Ifq-Sd for radiusext-data0@psg.com; Wed, 20 Jul 2011 20:24:55 +0000 Received: from g1t0029.austin.hp.com ([15.216.28.36]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QjdK9-000Iff-Hj for radiusext@ops.ietf.org; Wed, 20 Jul 2011 20:24:53 +0000 Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id 008543882C; Wed, 20 Jul 2011 20:24:50 +0000 (UTC) Received: from G5W0602.americas.hpqcorp.net (16.228.9.185) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 20 Jul 2011 20:23:51 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G5W0602.americas.hpqcorp.net ([16.228.9.185]) with mapi; Wed, 20 Jul 2011 21:23:50 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" CC: "jouni.korhonen@nsn.com" Date: Wed, 20 Jul 2011 21:23:48 +0100 Subject: IETF 81 meeting slides Thread-Topic: IETF 81 meeting slides Thread-Index: AcxHGu6eQ2kx3SC3SECHFw6irHYPiw== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C7791D959@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C7791D959GVW0671EXCame_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C7791D959GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you are presenting and have not submitted to co-chairs your slides, plea= se do so at your earliest convenience. This time around we are in at the= start of the week, so slides are due earlier than in past meetings. Thanks, Mauricio --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C7791D959GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you are prese= nting and have not submitted to co-chairs your slides, please do so at your= earliest convenience.    This time around we are in at the = start of the week, so slides are due earlier than in past meetings.

 

Than= ks,

Mauricio

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C7791D959GVW0671EXCame_-- -- to 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 Jul 23 15:23:12 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 46B3A21F8C24 for ; Sat, 23 Jul 2011 15:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxP-iDBbk7Tr for ; Sat, 23 Jul 2011 15:23:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 8016121F8BEA for ; Sat, 23 Jul 2011 15:23:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QkkX3-00080F-Mx for radiusext-data0@psg.com; Sat, 23 Jul 2011 22:18:49 +0000 Received: from g5t0009.atlanta.hp.com ([15.192.0.46]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QkkX1-000801-8t for radiusext@ops.ietf.org; Sat, 23 Jul 2011 22:18:47 +0000 Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g5t0009.atlanta.hp.com (Postfix) with ESMTPS id C61F2300E5; Sat, 23 Jul 2011 22:18:44 +0000 (UTC) Received: from G5W0324.americas.hpqcorp.net (16.228.8.69) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Sat, 23 Jul 2011 22:13:38 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0324.americas.hpqcorp.net ([16.228.8.69]) with mapi; Sat, 23 Jul 2011 23:13:38 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" CC: "jouni.korhonen@nsn.com" Date: Sat, 23 Jul 2011 23:13:35 +0100 Subject: RE: IETF 81 meeting slides - second call Thread-Topic: IETF 81 meeting slides - second call Thread-Index: AcxJhaC6LZDIiBirTqKduW/zA3KEYw== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C781849CA@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849CAGVW0671EXCame_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849CAGVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks if you have submitted your slides. If you have not, please do so AS= AP. Our meeting is Monday morning. Thanks, Mauricio --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849CAGVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Thanks if yo= u have submitted your slides.  If you have not, please do so ASAP. &nb= sp;Our meeting is Monday morning.

 

T= hanks,

Mauricio

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849CAGVW0671EXCame_-- -- to 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 Jul 23 16:34: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 C2CF221F8B9C for ; Sat, 23 Jul 2011 16:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApPiYoR+Z+4P for ; Sat, 23 Jul 2011 16:34:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC5721F8B98 for ; Sat, 23 Jul 2011 16:34:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QklfQ-0009yl-89 for radiusext-data0@psg.com; Sat, 23 Jul 2011 23:31:32 +0000 Received: from g6t0184.atlanta.hp.com ([15.193.32.61]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QklfN-0009yc-6F for radiusext@ops.ietf.org; Sat, 23 Jul 2011 23:31:29 +0000 Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g6t0184.atlanta.hp.com (Postfix) with ESMTPS id BC57DC1FF; Sat, 23 Jul 2011 23:31:26 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 23 Jul 2011 23:30:41 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Sun, 24 Jul 2011 00:30:42 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" CC: "jouni.korhonen@nsn.com" Date: Sun, 24 Jul 2011 00:30:40 +0100 Subject: IETF 81 - Remote attendees Thread-Topic: IETF 81 - Remote attendees Thread-Index: AcxJkCCtwezNUcLrRFWMOdpMZSemyg== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C781849DC@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849DCGVW0671EXCame_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849DCGVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below is the email from IETF regarding remote attendance options. At this = time, we only plan to use audio streaming, but no WebEx. For those of you presenting on Monday that will be remote, we will specific= instructions through in another email. -MS Greetings! We're two weeks out from the beginning of meeting streaming. For those inte= rested in monitoring sessions or participating remotely the following infor= mation may prove useful. - -Audio Streaming- All 8 parallel tracks at the IETF 81 meeting will be broadcast starting wit= h the commencement of working group sessions on Monday, July 25, 2011 at 09= 00 EDT (GMT-4) and continue until Friday, July 29 at 1515 EDT. Because we have been asked several times in the past, note that if you wish= to use the rooms that are being recorded for impromptu meeting during unsc= heduled sessions or lunch breaks that you can invite remote participants to= tune in to the appropriate stream. Recording cannot be guaranteed for unsc= heduled sessions. Conversely, it should never be assumed that recording or = observation is not occurring on open microphones, they are after all connec= ted to the Internet. The links for streaming sources and the schedule are best retrieved from th= e IETF tools agenda, which as per Standard operating procedure will be loca= ted here: http://tools.ietf.org/agenda/81/ - -Jabber/XMPP- For information on IETF Jabber participation see: http://www.ietf.org/jabber/index.html or click on the Jabber links in the tools team agenda once you have a prope= rly configured jabber/xmpp messaging client. - -Webex- Webex screen sharing participation is possible for a limited number of sess= ions. Consult with your working-group chair or the secretariat for more inf= ormation. - -Ticketing- For prompt access to the meeting trouble desk, the email address is: mtd@ietf.org For streaming related issues please send email to ietf-streaming@verilan.co= m with info including the current time a= nd affected streaming channel. Regards, --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849DCGVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Below is the email from IETF regarding rem= ote attendance options.  At this time, we only plan to use audio strea= ming, but no WebEx.  

 

For those of you presenting on Monday that will be remote, we wi= ll specific instructions through in another email.=

<= o:p> 

-MS

 

 

 =

 

 =

G= reetings!

We're two weeks out fr= om the beginning of meeting streaming. For those interested in monitoring sessions or participating re= motely the following information may prove useful.

- -Audio Streaming-

All 8 parallel t= racks at the IETF 81 m= eeting will be broadcast starting with the commencement of working group se= ssions on Monday, July 25, 2011 at 0900 EDT (GMT-4) and continue until Frid= ay, July 29 at 1515 EDT.

Becau= se we have been asked several times in the past, note that if you wish to u= se the rooms that are being recorded for impromptu meeting during unschedul= ed sessions or lunch breaks that you can invite remote participants to tune= in to the appropriate stream. Recording cannot be guaranteed for unschedul= ed sessions. Conversely, it should never be assumed that recording or obser= vation is not occurring on open microphones, they are after all connected t= o the Internet.

The links for&= nbsp;streaming sources and = the schedule are best retrieved from the IETF tools agenda, which as per Standard operating pro= cedure will be located here:

<= a href=3D"http://tools.ietf.org/agenda/80/" target=3D"_blank">http://tools.ietf.org/agenda/81/

= - -Jabber/XMPP-

For informatio= n on IETF Jabber parti= cipation see:

http://www.ietf.org/jabber= /index.html

or clic= k on the Jabber links in the tools team agenda once you have a properly con= figured jabber/xmpp messaging client.

- -Webex-

Webex screen= sharing participation is possible for a limited number of sessions. Consul= t with your working-group chair or the secretariat for more information.

- -Ticketing-

For prompt access to the meeting trouble desk, t= he email address is:

mtd@ietf= .org

For streaming related issues please send email to ietf-streaming<= /span>@verilan.com with info = including the current time and affected streaming channel.

Regards,

 =

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849DCGVW0671EXCame_-- -- to 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 Jul 24 19:44:54 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 94CB911E8072 for ; Sun, 24 Jul 2011 19:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lr-syMsvuAra for ; Sun, 24 Jul 2011 19:44:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id BF72111E8070 for ; Sun, 24 Jul 2011 19:44:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlB6M-000A7V-6O for radiusext-data0@psg.com; Mon, 25 Jul 2011 02:41:02 +0000 Received: from g6t0184.atlanta.hp.com ([15.193.32.61]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlB6G-000A77-Vu for radiusext@ops.ietf.org; Mon, 25 Jul 2011 02:40:57 +0000 Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0184.atlanta.hp.com (Postfix) with ESMTPS id CA8B1C31D for ; Mon, 25 Jul 2011 02:40:54 +0000 (UTC) Received: from G5W0602.americas.hpqcorp.net (16.228.9.185) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 25 Jul 2011 02:38:33 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0602.americas.hpqcorp.net ([16.228.9.185]) with mapi; Mon, 25 Jul 2011 03:38:32 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" Date: Mon, 25 Jul 2011 03:38:29 +0100 Subject: RADEXT WG Agenda for IETF 81 - Final Thread-Topic: RADEXT WG Agenda for IETF 81 - Final Thread-Index: AcxKc9HxGVHl6BtCTGamuwz9N7M1mw== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C78184A51@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78184A51GVW0671EXCame_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78184A51GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Final agenda. See everyone tomorrow. -MS ----------------------------------------------- RADEXT WG IETF 81 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Monday, July 25, 2011 0900 - 1130 Room 2101 9:00 - 09:20 AM, Preliminaries (20 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status IPv6 items (45 minutes) 9:20 - 9:35 AM Radius Extensions for CGN Configurations, Dean Cheng (15 min= utes) http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-radius-ext-00.txt 9:35 - 9:50 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec (15 = minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access 9:50 - 10:05 AM RADIUS accounting for traffic classes, Stefan Winter (15 mi= n) http://tools.ietf.org/html/draft-winter-radext-fancyaccounting Enhancement items (30 minutes) 10:05 AM - 10:15 AM Dynamic Peer Discovery, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery 10:15 - 10:25 AM RFC4282bis, Alan DeKok (10 minutes) 10:25 - 10:35 AM RADIUS Protocol Extensions, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions Security items (20 minutes) 10:35 - 10:45 AM RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls 10:45 - 10:55 AM RADIUS over TLS, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec Discussion and Wrap-up (35 minutes) 10:55 - 11:15 AM Discussion (20 minutes) Email list server migration 11:15 - 11:30 AM Next Steps: WG Chairs & ADs (15 minutes) WG Goals/Milestones status --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78184A51GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Final agenda.&nb= sp; See everyone tomorrow.

 

-MS

&n= bsp;

----------------------------------------= -------

 

 

RADEXT WG IETF 81 Agend= a

 

Chairs:

Jouni Korhonen <jouni.kor= honen at nsn.com>

Mauricio Sanchez &l= t;mauricio.sanchez at hp.com>

&n= bsp;

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

 

Monday, July 25, 2011

090= 0 - 1130

Room 2101

 

9:00 - 09:20 AM, P= reliminaries (20 minutes)

Audio/Video &a= mp; Remote Presentation Debugging

Note W= ell

Note Takers

Jabber scribe

Agenda bash

Document Status

 

 

IPv6 items (45 minutes)

 

9:20 - 9:35 AM Radius Extensio= ns for CGN Configurations, Dean Cheng (15 minutes)

http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-radius-ext-0= 0.txt

 

9:35 - 9:50 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh = Dec (15 minutes)

http://tools.ietf.org/h= tml/draft-ietf-radext-ipv6-access

&= nbsp;

9:50 - 10:05 AM RADIUS accounting for t= raffic classes, Stefan Winter (15 min)

= http://tools.ietf.org/html/draft-winter-radext-fancyaccounting

 

 = ;

Enhancement items (30 minutes)

 

10:05 AM -= 10:15 AM Dynamic Peer Discovery, Stefan Winter (10 minutes)

=

http://tools.ietf.org/html/draft-ietf-radext-dynamic-d= iscovery

 

10:15 - 10:25 AM RFC4282bis, Alan DeKok (10 minutes)

 

10:25 -= 10:35 AM RADIUS Protocol Extensions, Alan DeKok (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-radius-e= xtensions

 

 

Security items (20 m= inutes)

 

10:35  - 10:45 AM RADIUS over DTLS, Alan DeKok (10 minutes)<= o:p>

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

 

10:45  - 10:55 AM RADIUS over TLS, Stefan Winter (10 minu= tes)

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

 

 

Discussion and= Wrap-up (35 minutes)

 <= /p>

10:55 – 11:15 AM Discussion (20 minutes)=

Email list server migration

<= p class=3DMsoNormal> 

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

WG Goals/Milestones status

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78184A51GVW0671EXCame_-- -- to 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 Jul 25 06:35: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 0582B21F8A4B for ; Mon, 25 Jul 2011 06:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=0.851, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxBW29KwriWK for ; Mon, 25 Jul 2011 06:35:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD8521F89A1 for ; Mon, 25 Jul 2011 06:35:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlLH9-0007uu-2r for radiusext-data0@psg.com; Mon, 25 Jul 2011 13:32:51 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::1e]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlLH5-0007ug-J0 for radiusext@ops.ietf.org; Mon, 25 Jul 2011 13:32:47 +0000 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F40221F8AF4 for ; Mon, 25 Jul 2011 06:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGIDXu4EgZEb; Mon, 25 Jul 2011 06:32:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E90821F8A4B; Mon, 25 Jul 2011 06:32:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action: draft-ietf-radext-crypto-agility-requirements-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.56 Message-ID: <20110725133246.6845.44158.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 06:32:46 -0700 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. Title : Crypto-Agility Requirements for Remote Dial-In User Serv= ice (RADIUS) Author(s) : David B. Nelson Filename : draft-ietf-radext-crypto-agility-requirements-07.txt Pages : 12 Date : 2011-07-11 This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requir= ements-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-require= ments-07.txt -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Jul 25 06:48:36 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 1813F21F84D1 for ; Mon, 25 Jul 2011 06:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.435 X-Spam-Level: X-Spam-Status: No, score=-5.435 tagged_above=-999 required=5 tests=[AWL=1.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FpEq5WfEomP for ; Mon, 25 Jul 2011 06:48:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD5221F84CE for ; Mon, 25 Jul 2011 06:48:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlLUE-0008Q1-Hd for radiusext-data0@psg.com; Mon, 25 Jul 2011 13:46:22 +0000 Received: from szxga03-in.huawei.com ([119.145.14.66]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlLUC-0008Pk-0U for radiusext@ops.ietf.org; Mon, 25 Jul 2011 13:46:20 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOW003ZE694QC@szxga03-in.huawei.com> for radiusext@ops.ietf.org; Mon, 25 Jul 2011 21:46:16 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOW009T2694LA@szxga03-in.huawei.com> for radiusext@ops.ietf.org; Mon, 25 Jul 2011 21:46:16 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACU76146; Mon, 25 Jul 2011 21:46:16 +0800 (CST) Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 25 Jul 2011 21:46:13 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Mon, 25 Jul 2011 21:46:16 +0800 Date: Mon, 25 Jul 2011 13:46:14 +0000 From: Jiangsheng Subject: Reviewing is appreciated on draft-ietf-softwire-6rd-radius-attrib-02 X-Originating-IP: [172.24.2.41] To: "radiusext@ops.ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B920121DB47@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-GB Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: Reviewing is appreciated on draft-ietf-softwire-6rd-radius-attrib-02 Thread-index: AcxK0SHX8H25pQ1dSC2uR41GAm6gJw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi, all, This draft is now under the WGLC in softwire WG. We would like to also get reviewing from Radext WG. This draft was presented in IETF 80 meeting and received valuable comments. It has modified according to these comments. http://tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib-02 The WGLC in softwire is end Aug 02. Comments before that date are appreciated. Best regards, Sheng -- to 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 Jul 25 09:27:23 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 47AEA21F8784 for ; Mon, 25 Jul 2011 09:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=4.524, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULE04tOYzOYp for ; Mon, 25 Jul 2011 09:27:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id D8E5E11E8080 for ; Mon, 25 Jul 2011 09:27:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlNwI-000FYB-K9 for radiusext-data0@psg.com; Mon, 25 Jul 2011 16:23:30 +0000 Received: from szxga04-in.huawei.com ([119.145.14.67]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlNwF-000FXK-2I for radiusext@ops.ietf.org; Mon, 25 Jul 2011 16:23:27 +0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOW00B6ODJ05M@szxga04-in.huawei.com> for radiusext@ops.ietf.org; Tue, 26 Jul 2011 00:23:25 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOW00762DJ0C0@szxga04-in.huawei.com> for radiusext@ops.ietf.org; Tue, 26 Jul 2011 00:23:24 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACO94112; Tue, 26 Jul 2011 00:23:24 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 26 Jul 2011 00:23:22 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Tue, 26 Jul 2011 00:23:19 +0800 Date: Mon, 25 Jul 2011 16:23:18 +0000 From: Leaf yeh Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session X-Originating-IP: [172.24.2.41] To: "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" Cc: "fine_sz@huawei.com" , Qiujin , Wangshuxiang Message-id: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_3EPHcbtLqW3BaZvu8m4QXw)" Content-language: zh-CN Content-class: urn:content-classes:message Accept-Language: zh-CN, en-US Thread-topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3Tw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --Boundary_(ID_3EPHcbtLqW3BaZvu8m4QXw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Question for clarification: We already have the following Radius Attributes for the address/prefix pools: Framed-Pool (88, section 5.18 of RFC2869), Framed-IPv6-Pool (100, section 2.6 of RFC3162). http://www.iana.org/assignments/radius-types/radius-types.xml The foramt are the same as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/prefix pools: Delegated-IPv6-Prefix-Pool, Stateful-IPv6-Address-Pool, the fomat of these 2 attributes are the same as the above one. Supposed the above attributes could be explained as follows: Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; All above attributes are only used to provide the name of the address/prefix pools in a 'string'. I doubt the necessity to make so many 'name' or 'string' attributes for the different address/prefix pools to prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take the role to interpret the meaning of the pook name, right? I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv6? I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 prefix/address pool per the same logic. Am I right? Best Regards, Leaf --Boundary_(ID_3EPHcbtLqW3BaZvu8m4QXw) Content-id: Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

Question for clarification:

 

We already have the following Radius Attributes for the address/prefix pools:

 

Framed-Pool (88, section 5.18 of RFC2869),

Framed-IPv6-Pool (100, section 2.6 of RFC3162).

 

http://www.iana.org/assignments/radius-types/radius-types.xml

 

The foramt are the same as follows:

 

0                   1                   2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/prefix pools:

 

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

 

the fomat of these 2 attributes are the same as the above one.

 

 

Supposed the above attributes could be explained as follows:

 

Framed-Pool was designed for the IPv4 address pool; 

Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;

Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;

Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

 

All above attributes are only used to provide the name of the address/prefix pools in a 'string'. I doubt the necessity to make so many 'name' or 'string' attributes for the different address/prefix pools to prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take the role to interpret the meaning of the pook name, right?

 

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv6?

I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 prefix/address pool per the same logic. Am I right?

 

 

Best Regards,

Leaf

 

 

 


 

 


 

 

 

 

 

--Boundary_(ID_3EPHcbtLqW3BaZvu8m4QXw)-- -- to 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 Jul 25 15:34: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 EE66A11E80E0 for ; Mon, 25 Jul 2011 15:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B-efebltcK5 for ; Mon, 25 Jul 2011 15:34:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBC911E80B1 for ; Mon, 25 Jul 2011 15:34:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlTfk-000784-QW for radiusext-data0@psg.com; Mon, 25 Jul 2011 22:30:48 +0000 Received: from g6t0186.atlanta.hp.com ([15.193.32.63]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlTfW-00077l-1m for radiusext@ops.ietf.org; Mon, 25 Jul 2011 22:30:34 +0000 Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id C431C2C14F for ; Mon, 25 Jul 2011 22:30:30 +0000 (UTC) Received: from G5W0602.americas.hpqcorp.net (16.228.9.185) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 25 Jul 2011 22:29:43 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0602.americas.hpqcorp.net ([16.228.9.185]) with mapi; Mon, 25 Jul 2011 23:29:42 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" Date: Mon, 25 Jul 2011 23:29:42 +0100 Subject: RADEXT WG - IETF 81 preliminary meeting notes Thread-Topic: RADEXT WG - IETF 81 preliminary meeting notes Thread-Index: AcxLGaaSIMWqzBhyQQq096RhZBECsg== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C78185121@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78185121GVW0671EXCame_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78185121GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These are the preliminary notes for IETF 81. Many thanks to Mark Jones for = taking notes this morning. Comments/corrections welcome. -MS ---------------------------------------------------------------------------= ----------------------------------- RADEXT WG Minutes IETF 81 Quebec, Canada Monday, July 25th, 2011 Meeting started 9:02 AM and ended 11:27AM EDT. Approximately 35 individuals= in meeting Chairs: Jouni Korhonen Mauricio Sanchez 1. Preliminaries Agenda slides: http://www.ietf.org/proceedings/81/slides/radext-3.pptx Attendees: Bluesheets circulated. Note Well Note Takers - Note volunteer Mark Jones Jabber scribe - Alan DeKok jabber scribe Agenda bash - IPv6, enhancements, security grouped item. No changes to agenda made **************************************************************** 2. Radius Extensions for CGN Configurations, Dean Cheng http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-radius-ext-00.txt Presented by Dean Cheng. Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-2.ppt Hannes Tschofenig: Slide 3: Do you now assume DHCP between end host and NAT= ? Dean Cheng: Service Request is a general term but no change. Hannes Tschofenig: What happens when NAT runs out of ports? Dean Cheng: Number of ports are configured on server. It is used to limit. Hannes Tschofenig: What happens in failure case? i.e. you reach restriction= . Dean Cheng: AAA only returns limits. If use wants more ports, ICMP can be u= sed to indicate error. Hannes Tschofenig: How do you ensure ICMP reaches end host? Dean Cheng: OK. We can discuss offline. Mauricio Sanchez: Slide 5: Did you read RFC6158 RADIUS Guidelines Dean Cheng: Yes. Need some help on these encoding wrt RADIUS guidelines. --- Questions: Mauricio Sanchez: Where is this in BEHAVE WG? Dean: Result of merge of two drafts to BEHAVE. Chair suggested to present i= n RADEXT because comments received were on RADIUS aspects Dan Romanascu: Is this a charter item in BEHAVE. Dean: No. Still be chartered. Chair said it is within scope of BEHAVE. Dan: What do you need from RADEXT? Advisor? WGLC? Dean: BEHAVE suggest to present in RADEXT to get comments. Dan: In draft, need to expand acronyms. Hannes: (1) Need to define bigger picture. NAT behaviour when it runs out o= f resources. Need to know why it fails. (2) AAA client does not live on NAT= . DHCP and NAT are mashed together but it depends how these are related. Dean: AAA client is not changed. NAT44 must be co-located with BNG. Hannes: Very special scenario. Dean: If CNG (NAT44) not colo with BNG this falls apart. Dan: Any other mechanisms to configure CNG other than this draft? Dean: No change. Only leverages existing deployment. **************************************************************** 3. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec http://tools.ietf.org/html/draft-ietf-radext-ipv6-access Presented by Mauricio Sanchez. Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-5.ppt Questions: Leaf Yeh: In new version, new attribs. Only sends name of pool. DHCP alrea= dy has a pool. Doesn't think this is necessary. Attributes in v4 can already do this. Ther= e is no need to a v6 pool name. Leaf agreed to send concern to list Roberta Maglione: It is just a pool name. Semantics are different. Bernard Adoba: One is a prefix pool and the other is an address pool. May n= eed to do both at once. Leaf: But it is only a string. So DHCP server can use name format is disamb= iguate. Mauricio Sanchez: Sounds like valid reason for these two attributes. Please= bring comments to list. **************************************************************** 4. RADIUS accounting for traffic classes, Stefan Winter http://tools.ietf.org/html/draft-winter-radext-fancyaccounting Presented remotely by Stefan Winter. Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-4.pdf Other issues: Mark Jones: We don't need to include filter definition in accounting stream= . Just include filter name (bucket label) in the accounting stream. Stefan: Ok. Nice and simple. Works for me. Dan Romanascu : Reuse definitions from RFC4898 Mauricio Sanchez: Concerned about number of drafts to progress. Does not wa= nt to oversubscribe WG. Poll: Who is interested in this work? Who will help= out if WG item? Show of hands in room: Relevant and useful: No interest. Stefan: Will let draft expire unless someone comes forward with interest. Mauricio Sanchez: Thanks for spending time on this. **************************************************************** 5. Dynamic Peer Discovery, Stefan Winter http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery Presented by Stefan Winter. Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-0.pdf Stefan Winter: Asked about IESG comments on DIME equiv. Mark Jones: IESG DISCUSS is on format of Application Protocol Tag. Concern = was that the current format indicates a structure. Stefan Winter: Any IESG comments on Service Tag? Mark Jones: No. Just protocol tags. Comments or questions: Dan Romanascu: Jouni, Can you comment on issues encountered in DIME? Jouni Korhonen: Need to solve this in DIME. Mark gave summary of IESG conce= rn. Dan Romanascu: Do we need to stop work in this? Jouni Korhonen: No. Mark Jones: Confident that labels will be resolved. Not doing anything unna= tural with our original labels. No reason to stop work on this. **************************************************************** 6. RFC4282bis, Alan DeKok Presented by Alan Dekok Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-6.ppt Dan Romanascu: So 4282bis strips out internationization, right? How is thi= s separation being followed in other groups? Alan Dekok: Working with PRECIS on that aspect. **************************************************************** 7. RADIUS Protocol Extensions, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions Presented by Alan Dekok. Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-8.ppt Dan Romanascu: So this is a new type and is not backwards compatible? Alan: Backwards compatible for proxies that treat as an opaque blob. IANA s= ays these types (241-244) are not used but they are used in the real world.= Tough. Sam Hartman: I have a draft in abfab requiring this and would like to see t= his go fwd. Please don't call it an OID though. Alan Dekok: Audit shows that this should handle allocation needs for the f= oreseeable future. So we don't need adhoc formats. Just help them implement this new format. **************************************************************** 8. RADIUS over DTLS, Alan DeKok http://tools.ietf.org/html/draft-ietf-radext-dtls Presented by Alan Dekok. Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-7.ppt No questions. **************************************************************** 9. RADIUS over TLS, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec Presented remotely by Stefan Winter. Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-1.pdf Mauricio: Agree that it is ready for WGLC. Any other comments/questions? Dan Romanascu: TCP port allocation. Intention is to reuse port for radsec. = So are there any backwards compatability issues. Stefan Winter: No. Old radsec is the format for RADIUS/TLS. OCS said once R= FC is published they will change their implementation to do it this way. **************************************************************** (Margaret requested to present at RADEXT after agenda bashing had occurred = and WG chairs accepted presentation request) 10. Multihop Federations (Trust Router). Margaret Wasserman Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-9.pptx Philip Hallam-Baker: Looks like UUCP. It was replaced with DNS. Anything th= at looks like a namespace should be using DNS. Look at Bridge CAs. Used in= PKI space. Lots of univ are in Bridge Cas. Can also use Rulebook structure= so never need a path of more than 2 so don't need BGP. Margaret Wasserman: This is not about getting to every node. Only about get= ting between nodes in AAA infrastructure. They are all IP nodes and already= in BGP Philip Hallam-Baker: You will find you use only 10% of BGP and not the inte= resting part. Hannes: Draft addresses some of the issues. Relationship are not purely mec= hanical. Don't want to talk to everyone. Like SAML, Liberty Alliance. Come = up with circle of trust. They exist in AAA space. The Trust Router setup al= lows shortcuts. Alan Dekok: Echo Hannes. Need to represent biz relationships: Who to talk t= o depends on who is asking. Still have questions on the details Margaret Wasserman: This lets you put policy in interesting places (local t= rust router). E.g. not route should Russian nodes even if the route is shor= ter. Klaas Wierenga: This work is motivated by problems seen in large scale SAML= deployments. Esp to express complex polices around who you want to trust. = Share some of Philips concerns Philip Hallam-Baker: Working on this problem for 15yrs. Similar to other ap= proaches that have already been implemented. Sam Hartman: This is in the draft. Philip: Why not in the presentation? Margaret Wasserman: Not accepted as WG item in abfab. Feedback required on = abfab list. Hannes: Also talking to VOIP folks who are reusing BGP concepts. Margaret Wasserman: we have not written these protocols. If a better way, p= lease explain. Philip Hallam-Baker: Thinking as a CA. Someone has to manage it and money w= ill flow around. The task of introduction is going to be paid. May want to = pay premium to find a path with a higher degree of trust. Margaret Wasserman: Allows for biz intelligence at many different layers. Philip Hallam-Baker: Contracts will determine this. Don't need this hop by = hop. Can take this offline. Margaret Wasserman: Would be interested in those pointers to approaches alr= eady tried. Klaas Wierenga: This goes beyond abfab. So AD pushed us to present in other= groups that see the same type of problem. Welcome a broad discussion. Margaret Wasserman: On agenda in abfab on Friday morning. **************************************************************** 11. Email list server migration Dan Romanascu: Please explain what it means for people on the list. Mauricio: Nothing. Should be transparent. Got a process for archive migrati= on. Jouni: Auto move of subscribers to new list. Emails will be forwarded betwe= en lists. Secretary will move archives. Dan: On behalf of doubters: Can you explain migration of archives? Mauricio: Others (Fred Baker) created the process for painless migration of= archives. So we Dan: Do references on the tracker need to change? Jouni: Direct links to archives need to be updated. Mauricio: Will need to look into that and make sure it is remedied. **************************************************************** 12. Next Steps: WG Chairs & ADs WG Goals/Milestones status No questions --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78185121GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These are the pr= eliminary notes for IETF 81. Many thanks to Mark Jones for taking notes thi= s morning.  Comments/corrections welcome.

 

-MS

 

-------------------= ---------------------------------------------------------------------------= ----------------

RADEXT WG Minutes<= /o:p>

IETF 81

Qu= ebec, Canada

Monday, July 25th, 2011

Meeting started 9:02 AM and ended 11:27AM = EDT. Approximately 35 individuals in meeting

 

Chairs:

Jouni Korhonen <jouni.korhonen@nsn.com>

=

Mauricio Sanchez <mauricio.sanchez@hp.com><= /o:p>

&nb= sp;

1. Preliminaries

 

Agenda slides: http:= //www.ietf.org/proceedings/81/slides/radext-3.pptx

 

Attendees: Bluesheet= s circulated.

Note Well

Note Takers

- Note vo= lunteer Mark Jones

Jabber scribe

- Alan DeKok jabber scribe

Agenda bash

- IPv6, enha= ncements, security grouped item.  No changes to agenda made=

 

********= ********************************************************

 

2. Radius Extens= ions for CGN Configurations, Dean Cheng

http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-radius-ext-00.txt

 

Pres= ented by Dean Cheng.

Slidedeck: http://w= ww.ietf.org/proceedings/81/slides/radext-2.ppt

Hannes Tschofenig: Slide 3: Do you now assume DHCP between end host = and NAT?

Dean Cheng: Service Request is= a general term but no change.

Hannes Ts= chofenig: What happens when NAT runs out of ports?

Dean Cheng: Number of ports are configured on server. It is us= ed to limit.

Hannes Tschofenig: What hap= pens in failure case? i.e. you reach restriction.

Dean Cheng: AAA only returns limits. If use wants more ports, ICM= P can be used to indicate

error.

Hannes Tsc= hofenig: How do you ensure ICMP reaches end host?

Dean Cheng: OK. We can discuss offline.

Mauricio Sanchez:  Slide 5: Did you read RFC6158 RADIUS Guid= elines

Dean Cheng: Yes. Need some help o= n these encoding wrt RADIUS guidelines.

=

---

Questions:

Mauricio Sanchez: Where is this in BEHAVE WG?

Dean: Result of merge of two drafts to BEHAVE. Chair suggest= ed to present in RADEXT because

comments received were on RADIUS aspects<= /o:p>

Dan Romanascu: Is this a charter item in BEHA= VE.

Dean: No. Still be chartered. Chair = said it is within scope of BEHAVE.

Dan:= What do you need from RADEXT? Advisor? WGLC?

Dean: BEHAVE suggest to present in RADEXT to get comments.=

Dan: In draft, need to expand acronyms.=

Hannes: (1) Need to define bigger picture. NAT beh= aviour when it runs out of resources. Need to know why it fails. (2) AAA cl= ient does not live on NAT. DHCP and NAT are mashed together but it depends = how these are related.

Dean: AAA client= is not changed. NAT44 must be co-located with BNG.

Hannes: Very special scenario.

Dean: If CNG (NAT44) not colo with BNG this falls apart.

Dan: Any other mechanisms to configure CNG other than= this draft?

Dean: No change. Only lever= ages existing deployment.

 

***********************************************= *****************

 

=

3. RADIUS Attributes for IPv6 Access Networks, Wojcieh= Dec

http://tools.ietf.org/html/draft-i= etf-radext-ipv6-access

<= p class=3DMsoNormal>Presented by Mauricio Sanchez.

Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-5.= ppt

Questions:

Leaf  Yeh: In new vers= ion, new attribs. Only sends name of pool. DHCP already has a pool.

Doesn’t think this is necessary. Attribu= tes in v4 can already do this. There is no need to a v6 pool name.

Leaf agreed to send concern to list<= /p>

Roberta Maglione: It is just a pool name. Semantics= are different.

Bernard Adoba: One is a= prefix pool and the other is an address pool. May need to do both at =

once.

Lea= f: But it is only a string. So DHCP server can use name format is disambigu= ate.

Mauricio Sanchez: Sounds like valid= reason for these two attributes. Please bring comments to

<= p class=3DMsoNormal>list.

****************************************************= ************

4. RADIUS accounting for traffic classes, Stefan Winter

http://tools.ietf.org/html/draft-winter-radext-f= ancyaccounting

Presented remotely by Ste= fan Winter.

Slidedeck: http://www.ietf.o= rg/proceedings/81/slides/radext-4.pdf

<= o:p>

Other issues:

Mark Jones: We don’t ne= ed to include filter definition in accounting stream. Just include filter n= ame (bucket label) in the accounting stream.

Stefan: Ok. Nice and simple. Works for me.

Dan Romanascu : Reuse definitions from RFC4898

Mauricio Sanchez: Conce= rned about number of drafts to progress. Does not want to oversubscribe WG.= Poll: Who is interested in this work? Who will help out if WG item?

Show of hands in room:

Relevant and useful: No interest.

Stefan: Will let draft expire unless someone comes forward with inte= rest.

Mauricio Sanchez: Thanks for spend= ing time on this.

 

=

******************************************************= **********

 

5. Dynamic Peer Discovery, Stefan Winter

http://tools.ietf.org/html/draft-ietf-radext-dynamic-discove= ry

Presented by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings/81/sl= ides/radext-0.pdf

Stefan Winter: Asked about IESG comments on DIME equiv.=

Mark Jones: IESG DISCUSS is on format of App= lication Protocol Tag. Concern was that the current format indicates a stru= cture.

Stefan Winter: Any IESG comments = on Service Tag?

Mark Jones: No. Just pro= tocol tags.

Comments or questions:

Dan Roma= nascu: Jouni, Can you comment on issues encountered in DIME?

=

Jouni Korhonen: Need to solve this in DIME. Mark gave = summary of IESG concern.

Dan Romanascu: = Do we need to stop work in this?

Jouni K= orhonen: No.

Mark Jones: Confident that= labels will be resolved. Not doing anything unnatural with our original la= bels. No reason to stop work on this.

<= o:p>

****************************************= ************************

 

6. RFC4282bis, Alan DeKok

Presented by Alan Dekok

Sl= idedeck: http://www.ietf.org/proceedings/81/slides/radext-6.ppt<= /p>

Dan Romanascu:= So  4282bis strips out internationization, right? How is this separat= ion being followed in other groups?

Alan= Dekok: Working with PRECIS on that aspect.

**********************************= ******************************

7. RADIUS Protocol Extensions, Alan DeKok (10 m= inutes)

http://tools.ietf.org/html/draft= -ietf-radext-radius-extensions

Presented= by  Alan Dekok.

Slidedeck:  h= ttp://www.ietf.org/proceedings/81/slides/radext-8.ppt

Dan Romanascu: So this i= s a new type and is not backwards compatible?

Alan: Backwards compatible for proxies that treat as an opaque blob. = IANA says these types (241-244) are not used but they are used in the real = world. Tough.

Sam Hartman: I have a draf= t in abfab requiring this and would like to see this go fwd. Please donR= 17;t call it an OID though. 

 = ;Alan Dekok: Audit shows that this should handle allocation needs for the f= oreseeable future.

So we don’t ne= ed adhoc formats. Just help them implement this new format.

<= p class=3DMsoNormal>

******************= **********************************************

 

8. RADIUS over DTLS, Alan = DeKok

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

Presented by  Alan= Dekok.

Slidedeck:  http://www.ietf= .org/proceedings/81/slides/radext-7.ppt

= No questions.

**************************************************************= **

= 9. RADIUS over TLS, Stefan Winter (10 minutes)

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

Presented remotely by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings/81/slides/radext= -1.pdf

Mauricio: Agree that it is ready for WGLC. Any other comments/questions= ?

Dan Romanascu: TCP port allocation. In= tention is to reuse port for radsec. So are there any  backwards compa= tability issues.

Stefan Winter: No. Old= radsec is the format for RADIUS/TLS. OCS said once RFC is published they w= ill change their implementation to do it this way.

 

********************= ********************************************

(Margaret requested to present at RADEXT after agenda bashing had occu= rred and WG chairs accepted presentation request) 

 

10. Multihop Fed= erations (Trust Router).

Margaret Wasserman

Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-9.pptx

Philip Hal= lam-Baker: Looks like UUCP. It was replaced with DNS. Anything that looks l= ike a  namespace should be using DNS. Look at Bridge CAs. Used in PKI = space. Lots of univ are in Bridge Cas. Can also use Rulebook structure so n= ever need a path of more than 2 so don’t need

BGP.

Margaret Wasserman: T= his is not about getting to every node. Only about getting between nodes in= AAA infrastructure. They are all IP nodes and already in BGP

Philip Hallam-Baker: You will find you use only 10% o= f BGP and not the interesting part.

Hann= es: Draft addresses some of the issues. Relationship are not purely mechani= cal. Don’t want to talk to everyone. Like SAML, Liberty Alliance. Com= e up with circle of trust. They exist in AAA space. The Trust Router setup = allows shortcuts.

Alan Dekok: Echo Hanne= s. Need to represent biz relationships: Who to talk to depends on who is as= king. Still have questions on the details

Margaret Wasserman: This lets you put policy in interesting places (local= trust router). E.g. not route should Russian nodes even if the route is sh= orter.

Klaas Wierenga: This work is moti= vated by problems seen in large scale SAML deployments. Esp to express comp= lex polices around who you want to trust. Share some of Philips concerns

Philip Hallam-Baker: Working on this probl= em for 15yrs. Similar to other approaches that have already been implemente= d.

Sam Hartman: This is in the draft.

Philip: Why not in the presentation?=

Margaret Wasserman: Not accepted as WG item = in abfab. Feedback required on abfab list.

Hannes: Also talking to VOIP folks who are reusing BGP concepts.

Margaret Wasserman: we have not written these = protocols. If a better way, please explain.

Philip Hallam-Baker: Thinking as a CA. Someone has to manage it and mon= ey will flow around. The task of introduction is going to be paid. May want= to pay premium to find a path with a higher degree of trust.

Margaret Wasserman: Allows for biz intelligence at ma= ny different layers.

Philip Hallam-Baker= : Contracts will determine this. Don’t need this hop by hop. Can take= this offline.

Margaret Wasserman: Would= be interested in those pointers to approaches already tried.

Klaas Wierenga: This goes beyond abfab. So AD pushed = us to present in other groups that see the same type of problem. Welcome a = broad discussion.

Margaret Wasserman: On= agenda in abfab on Friday morning.

 

 

****************************************************************<= /o:p>

 

11.= Email list server migration

Dan Romana= scu: Please explain what it means for people on the list.

Mauricio: Nothing. Should be transparent. Got a process f= or archive migration.

Jouni: Auto move o= f subscribers to new list. Emails will be forwarded between lists. 

Secre= tary will move archives.

Dan: On behalf = of doubters: Can you explain migration of archives?

Mauricio: Others (Fred Baker) created the process for painless= migration of archives. So we

Dan: Do r= eferences on the tracker need to change?

Jouni: Direct links to archives need to be updated.

Mauricio: Will need to look into that and make sure it is reme= died.

 

****************************************************************

12. N= ext Steps: WG Chairs & ADs

WG Goals/= Milestones status

No questions

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78185121GVW0671EXCame_-- -- to 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 Jul 26 04:41:05 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 DB11E21F8BD5 for ; Tue, 26 Jul 2011 04:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Wu-Vz2NFwVc for ; Tue, 26 Jul 2011 04:41:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 93E8D21F8BBC for ; Tue, 26 Jul 2011 04:41:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlfxV-000APm-Ey for radiusext-data0@psg.com; Tue, 26 Jul 2011 11:37:57 +0000 Received: from szxga04-in.huawei.com ([119.145.14.67]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlfxN-000APX-79 for radiusext@ops.ietf.org; Tue, 26 Jul 2011 11:37:51 +0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOX00C58UYZHQ@szxga04-in.huawei.com> for radiusext@ops.ietf.org; Tue, 26 Jul 2011 19:37:47 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOX001FHUYZVM@szxga04-in.huawei.com> for radiusext@ops.ietf.org; Tue, 26 Jul 2011 19:37:47 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACP59583; Tue, 26 Jul 2011 19:37:46 +0800 (CST) Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 26 Jul 2011 19:37:43 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Tue, 26 Jul 2011 19:37:42 +0800 Date: Tue, 26 Jul 2011 11:37:41 +0000 From: Leaf yeh Subject: Re: RADEXT WG - IETF 81 preliminary meeting notes In-reply-to: <9BC2F7926B33FE4AB10D69891D58FC1C5C78185121@GVW0671EXC.americas.hpqcorp.net> X-Originating-IP: [172.24.2.40] To: "Sanchez, Mauricio (HP Networking)" , "'radiusext@ops.ietf.org'" Cc: "fine_sz@huawei.com" , Qiujin , Wangshuxiang , Behcet Sarikaya Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_CTBeIIdVcoMZCGN4hjNyyA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: RADEXT WG - IETF 81 preliminary meeting notes Thread-index: AcxLGaaSIMWqzBhyQQq096RhZBECsgAKk+UAABEeaxY= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <9BC2F7926B33FE4AB10D69891D58FC1C5C78185121@GVW0671EXC.americas.hpqcorp.net> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --Boundary_(ID_CTBeIIdVcoMZCGN4hjNyyA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SSd2ZSBzZW50IGEgcXVlc3Rpb24gb2YgY2xhcmlmaWNhdGlvbiB0byB0aGUgbWFpbGluZyBsaXN0 IGFnYWlzbnQgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3MtMDUuIFBscy4gcmVmZXIgdG8g aHR0cHM6Ly9vcHMuaWV0Zi5vcmcvbGlzdHMvcmFkaXVzZXh0LzIwMTAvbXNnMDA5NTkuaHRtbC4N Cg0KU29ycnkgZm9yIG15IHBvb3IgZXhwcmVzc2lvbiBpbiB0aGUgUmFkZXh0IHNlc3Npb24uIEkn ZCBsaWtlIHRvIGNsYXJpZnkgbXkgd29yZHMgaW4gdGhlIG1lZXRpbmcgbm90ZXMgaGVyZS4NCg0K DQo+IDMuIFJBRElVUyBBdHRyaWJ1dGVzIGZvciBJUHY2IEFjY2VzcyBOZXR3b3JrcywgV29qY2ll aCBEZWMNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1yYWRleHQtaXB2 Ni1hY2Nlc3MNCj4gUHJlc2VudGVkIGJ5IE1hdXJpY2lvIFNhbmNoZXouDQo+IFNsaWRlZGVjazog aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84MS9zbGlkZXMvcmFkZXh0LTUucHB0DQo+ IFF1ZXN0aW9uczoNCj4gTGVhZiAgWWVoOiBJbiBuZXcgdmVyc2lvbiwgbmV3IGF0dHJpYnMuIE9u bHkgc2VuZHMgbmFtZSBvZiBwb29sLiBESENQIGFscmVhZHkgaGFzIGEgcG9vbC4NCg0KSSBtZWFu dCB0aGUgYXR0cmlidXRlIG9mIEZyYW1lZC1Qb29sICg4OCwgc2VjdGlvbiA1LjE4IG9mIFJGQzI4 NjkpIGhlcmUsIHdoaWNoIGlzIHVzZWQgdG8gc2VuZCB0aGUgcG9vbCBuYW1lIGZyb20gQUFBIHNl cnZlciB0byBOQVMgc2VydmVyLCB0byBpbmRpY2F0ZSB0aGUgcmlnaHQgcG9vbCBlbXBsb3llZCBv ciBjb25maWd1cmVkIG9uIE5BUy4NCg0KPiBEb2VzbqGvdCB0aGluayB0aGlzIGlzIG5lY2Vzc2Fy eS4gQXR0cmlidXRlcyBpbiB2NCBjYW4gYWxyZWFkeSBkbyB0aGlzLiBUaGVyZSBpcyBubyBuZWVk IHRvIGEgdjYgcG9vbCBuYW1lLg0KPiBMZWFmIGFncmVlZCB0byBzZW5kIGNvbmNlcm4gdG8gbGlz dA0KPiBSb2JlcnRhIE1hZ2xpb25lOiBJdCBpcyBqdXN0IGEgcG9vbCBuYW1lLiBTZW1hbnRpY3Mg YXJlIGRpZmZlcmVudC4NCj4gQmVybmFyZCBBZG9iYTogT25lIGlzIGEgcHJlZml4IHBvb2wgYW5k IHRoZSBvdGhlciBpcyBhbiBhZGRyZXNzIHBvb2wuIE1heSBuZWVkIHRvIGRvIGJvdGggYXQgb25j ZS4NCj4gTGVhZjogQnV0IGl0IGlzIG9ubHkgYSBzdHJpbmcuIFNvIERIQ1Agc2VydmVyIGNhbiB1 c2UgbmFtZSBmb3JtYXQgaXMgZGlzYW1iaWd1YXRlLg0KDQpJIG1lYW50IHRoZSBOQVMgY2FuIGlu dGVycHJlY3QgdGhlIHBvb2wgbmFtZSByZWNldml2ZWQgZnJvbSBBQUEgc2VydmVyIGZvciBlYWNo IGtpbmQgb2YgdXNhZ2UsIHN1Y2ggYXMgSVB2NCBQUFAgYWRkcmVzcyBwb29sLCBJUHY2IFNMQUFD IHByZWZpeCBwb29sLCBJUHY2IERIQ1B2NiBhZGRyZXNzIHBvb2wgb3IgREhDUHY2LVBEIHByZWZp eCBwb29sLg0KDQo+IE1hdXJpY2lvIFNhbmNoZXo6IFNvdW5kcyBsaWtlIHZhbGlkIHJlYXNvbiBm b3IgdGhlc2UgdHdvIGF0dHJpYnV0ZXMuIFBsZWFzZSBicmluZyBjb21tZW50cyB0bw0KbGlzdC4N Cg0KDQpCZXN0IFJlZ2FyZHMsDQpMZWFmDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0Kt6K8/sjLOiBvd25lci1yYWRpdXNleHRAb3BzLmlldGYub3JnIFtvd25l ci1yYWRpdXNleHRAb3BzLmlldGYub3JnXSC0+rHtIFNhbmNoZXosIE1hdXJpY2lvIChIUCBOZXR3 b3JraW5nKSBbbWF1cmljaW8uc2FuY2hlekBocC5jb21dDQq3osvNyrG85DogMjAxMcTqN9TCMjbI 1SA2OjI5DQq1vTogJ3JhZGl1c2V4dEBvcHMuaWV0Zi5vcmcnDQrW98ziOiBSQURFWFQgV0cgLSBJ RVRGIDgxIHByZWxpbWluYXJ5IG1lZXRpbmcgbm90ZXMNCg0KVGhlc2UgYXJlIHRoZSBwcmVsaW1p bmFyeSBub3RlcyBmb3IgSUVURiA4MS4gTWFueSB0aGFua3MgdG8gTWFyayBKb25lcyBmb3IgdGFr aW5nIG5vdGVzIHRoaXMgbW9ybmluZy4gIENvbW1lbnRzL2NvcnJlY3Rpb25zIHdlbGNvbWUuDQoN Ci1NUw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KUkFERVhUIFdHIE1pbnV0ZXMNCklFVEYgODENClF1ZWJlYywgQ2FuYWRhDQpNb25kYXks IEp1bHkgMjV0aCwgMjAxMQ0KTWVldGluZyBzdGFydGVkIDk6MDIgQU0gYW5kIGVuZGVkIDExOjI3 QU0gRURULiBBcHByb3hpbWF0ZWx5IDM1IGluZGl2aWR1YWxzIGluIG1lZXRpbmcNCg0KQ2hhaXJz Og0KSm91bmkgS29yaG9uZW4gPGpvdW5pLmtvcmhvbmVuQG5zbi5jb20+DQpNYXVyaWNpbyBTYW5j aGV6IDxtYXVyaWNpby5zYW5jaGV6QGhwLmNvbT4NCg0KMS4gUHJlbGltaW5hcmllcw0KDQpBZ2Vu ZGEgc2xpZGVzOiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgxL3NsaWRlcy9yYWRl eHQtMy5wcHR4DQoNCkF0dGVuZGVlczogQmx1ZXNoZWV0cyBjaXJjdWxhdGVkLg0KTm90ZSBXZWxs DQpOb3RlIFRha2Vycw0KLSBOb3RlIHZvbHVudGVlciBNYXJrIEpvbmVzDQpKYWJiZXIgc2NyaWJl DQotIEFsYW4gRGVLb2sgamFiYmVyIHNjcmliZQ0KQWdlbmRhIGJhc2gNCi0gSVB2NiwgZW5oYW5j ZW1lbnRzLCBzZWN1cml0eSBncm91cGVkIGl0ZW0uICBObyBjaGFuZ2VzIHRvIGFnZW5kYSBtYWRl DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioNCg0KMi4gUmFkaXVzIEV4dGVuc2lvbnMgZm9yIENHTiBDb25maWd1cmF0aW9u cywgRGVhbiBDaGVuZw0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1jaGVuZy1iZWhhdmUt Y2duLWNmZy1yYWRpdXMtZXh0LTAwLnR4dA0KDQpQcmVzZW50ZWQgYnkgRGVhbiBDaGVuZy4NClNs aWRlZGVjazogaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84MS9zbGlkZXMvcmFkZXh0 LTIucHB0DQpIYW5uZXMgVHNjaG9mZW5pZzogU2xpZGUgMzogRG8geW91IG5vdyBhc3N1bWUgREhD UCBiZXR3ZWVuIGVuZCBob3N0IGFuZCBOQVQ/DQpEZWFuIENoZW5nOiBTZXJ2aWNlIFJlcXVlc3Qg aXMgYSBnZW5lcmFsIHRlcm0gYnV0IG5vIGNoYW5nZS4NCkhhbm5lcyBUc2Nob2ZlbmlnOiBXaGF0 IGhhcHBlbnMgd2hlbiBOQVQgcnVucyBvdXQgb2YgcG9ydHM/DQpEZWFuIENoZW5nOiBOdW1iZXIg b2YgcG9ydHMgYXJlIGNvbmZpZ3VyZWQgb24gc2VydmVyLiBJdCBpcyB1c2VkIHRvIGxpbWl0Lg0K SGFubmVzIFRzY2hvZmVuaWc6IFdoYXQgaGFwcGVucyBpbiBmYWlsdXJlIGNhc2U/IGkuZS4geW91 IHJlYWNoIHJlc3RyaWN0aW9uLg0KRGVhbiBDaGVuZzogQUFBIG9ubHkgcmV0dXJucyBsaW1pdHMu IElmIHVzZSB3YW50cyBtb3JlIHBvcnRzLCBJQ01QIGNhbiBiZSB1c2VkIHRvIGluZGljYXRlDQpl cnJvci4NCkhhbm5lcyBUc2Nob2ZlbmlnOiBIb3cgZG8geW91IGVuc3VyZSBJQ01QIHJlYWNoZXMg ZW5kIGhvc3Q/DQpEZWFuIENoZW5nOiBPSy4gV2UgY2FuIGRpc2N1c3Mgb2ZmbGluZS4NCk1hdXJp Y2lvIFNhbmNoZXo6ICBTbGlkZSA1OiBEaWQgeW91IHJlYWQgUkZDNjE1OCBSQURJVVMgR3VpZGVs aW5lcw0KRGVhbiBDaGVuZzogWWVzLiBOZWVkIHNvbWUgaGVscCBvbiB0aGVzZSBlbmNvZGluZyB3 cnQgUkFESVVTIGd1aWRlbGluZXMuDQotLS0NClF1ZXN0aW9uczoNCk1hdXJpY2lvIFNhbmNoZXo6 IFdoZXJlIGlzIHRoaXMgaW4gQkVIQVZFIFdHPw0KRGVhbjogUmVzdWx0IG9mIG1lcmdlIG9mIHR3 byBkcmFmdHMgdG8gQkVIQVZFLiBDaGFpciBzdWdnZXN0ZWQgdG8gcHJlc2VudCBpbiBSQURFWFQg YmVjYXVzZQ0KY29tbWVudHMgcmVjZWl2ZWQgd2VyZSBvbiBSQURJVVMgYXNwZWN0cw0KRGFuIFJv bWFuYXNjdTogSXMgdGhpcyBhIGNoYXJ0ZXIgaXRlbSBpbiBCRUhBVkUuDQpEZWFuOiBOby4gU3Rp bGwgYmUgY2hhcnRlcmVkLiBDaGFpciBzYWlkIGl0IGlzIHdpdGhpbiBzY29wZSBvZiBCRUhBVkUu DQpEYW46IFdoYXQgZG8geW91IG5lZWQgZnJvbSBSQURFWFQ/IEFkdmlzb3I/IFdHTEM/DQpEZWFu OiBCRUhBVkUgc3VnZ2VzdCB0byBwcmVzZW50IGluIFJBREVYVCB0byBnZXQgY29tbWVudHMuDQpE YW46IEluIGRyYWZ0LCBuZWVkIHRvIGV4cGFuZCBhY3Jvbnltcy4NCkhhbm5lczogKDEpIE5lZWQg dG8gZGVmaW5lIGJpZ2dlciBwaWN0dXJlLiBOQVQgYmVoYXZpb3VyIHdoZW4gaXQgcnVucyBvdXQg b2YgcmVzb3VyY2VzLiBOZWVkIHRvIGtub3cgd2h5IGl0IGZhaWxzLiAoMikgQUFBIGNsaWVudCBk b2VzIG5vdCBsaXZlIG9uIE5BVC4gREhDUCBhbmQgTkFUIGFyZSBtYXNoZWQgdG9nZXRoZXIgYnV0 IGl0IGRlcGVuZHMgaG93IHRoZXNlIGFyZSByZWxhdGVkLg0KRGVhbjogQUFBIGNsaWVudCBpcyBu b3QgY2hhbmdlZC4gTkFUNDQgbXVzdCBiZSBjby1sb2NhdGVkIHdpdGggQk5HLg0KSGFubmVzOiBW ZXJ5IHNwZWNpYWwgc2NlbmFyaW8uDQpEZWFuOiBJZiBDTkcgKE5BVDQ0KSBub3QgY29sbyB3aXRo IEJORyB0aGlzIGZhbGxzIGFwYXJ0Lg0KRGFuOiBBbnkgb3RoZXIgbWVjaGFuaXNtcyB0byBjb25m aWd1cmUgQ05HIG90aGVyIHRoYW4gdGhpcyBkcmFmdD8NCkRlYW46IE5vIGNoYW5nZS4gT25seSBs ZXZlcmFnZXMgZXhpc3RpbmcgZGVwbG95bWVudC4NCg0KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQozLiBSQURJVVMgQXR0 cmlidXRlcyBmb3IgSVB2NiBBY2Nlc3MgTmV0d29ya3MsIFdvamNpZWggRGVjDQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzcw0KUHJlc2VudGVk IGJ5IE1hdXJpY2lvIFNhbmNoZXouDQpTbGlkZWRlY2s6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvODEvc2xpZGVzL3JhZGV4dC01LnBwdA0KUXVlc3Rpb25zOg0KTGVhZiAgWWVoOiBJ biBuZXcgdmVyc2lvbiwgbmV3IGF0dHJpYnMuIE9ubHkgc2VuZHMgbmFtZSBvZiBwb29sLiBESENQ IGFscmVhZHkgaGFzIGEgcG9vbC4NCkRvZXNuoa90IHRoaW5rIHRoaXMgaXMgbmVjZXNzYXJ5LiBB dHRyaWJ1dGVzIGluIHY0IGNhbiBhbHJlYWR5IGRvIHRoaXMuIFRoZXJlIGlzIG5vIG5lZWQgdG8g YSB2NiBwb29sIG5hbWUuDQpMZWFmIGFncmVlZCB0byBzZW5kIGNvbmNlcm4gdG8gbGlzdA0KUm9i ZXJ0YSBNYWdsaW9uZTogSXQgaXMganVzdCBhIHBvb2wgbmFtZS4gU2VtYW50aWNzIGFyZSBkaWZm ZXJlbnQuDQpCZXJuYXJkIEFkb2JhOiBPbmUgaXMgYSBwcmVmaXggcG9vbCBhbmQgdGhlIG90aGVy IGlzIGFuIGFkZHJlc3MgcG9vbC4gTWF5IG5lZWQgdG8gZG8gYm90aCBhdA0Kb25jZS4NCkxlYWY6 IEJ1dCBpdCBpcyBvbmx5IGEgc3RyaW5nLiBTbyBESENQIHNlcnZlciBjYW4gdXNlIG5hbWUgZm9y bWF0IGlzIGRpc2FtYmlndWF0ZS4NCk1hdXJpY2lvIFNhbmNoZXo6IFNvdW5kcyBsaWtlIHZhbGlk IHJlYXNvbiBmb3IgdGhlc2UgdHdvIGF0dHJpYnV0ZXMuIFBsZWFzZSBicmluZyBjb21tZW50cyB0 bw0KbGlzdC4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioNCjQuIFJBRElVUyBhY2NvdW50aW5nIGZvciB0cmFmZmljIGNsYXNz ZXMsIFN0ZWZhbiBXaW50ZXINCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbnRl ci1yYWRleHQtZmFuY3lhY2NvdW50aW5nDQpQcmVzZW50ZWQgcmVtb3RlbHkgYnkgU3RlZmFuIFdp bnRlci4NClNsaWRlZGVjazogaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84MS9zbGlk ZXMvcmFkZXh0LTQucGRmDQpPdGhlciBpc3N1ZXM6DQpNYXJrIEpvbmVzOiBXZSBkb26hr3QgbmVl ZCB0byBpbmNsdWRlIGZpbHRlciBkZWZpbml0aW9uIGluIGFjY291bnRpbmcgc3RyZWFtLiBKdXN0 IGluY2x1ZGUgZmlsdGVyIG5hbWUgKGJ1Y2tldCBsYWJlbCkgaW4gdGhlIGFjY291bnRpbmcgc3Ry ZWFtLg0KU3RlZmFuOiBPay4gTmljZSBhbmQgc2ltcGxlLiBXb3JrcyBmb3IgbWUuDQpEYW4gUm9t YW5hc2N1IDogUmV1c2UgZGVmaW5pdGlvbnMgZnJvbSBSRkM0ODk4DQpNYXVyaWNpbyBTYW5jaGV6 OiBDb25jZXJuZWQgYWJvdXQgbnVtYmVyIG9mIGRyYWZ0cyB0byBwcm9ncmVzcy4gRG9lcyBub3Qg d2FudCB0byBvdmVyc3Vic2NyaWJlIFdHLiBQb2xsOiBXaG8gaXMgaW50ZXJlc3RlZCBpbiB0aGlz IHdvcms/IFdobyB3aWxsIGhlbHAgb3V0IGlmIFdHIGl0ZW0/DQpTaG93IG9mIGhhbmRzIGluIHJv b206DQpSZWxldmFudCBhbmQgdXNlZnVsOiBObyBpbnRlcmVzdC4NClN0ZWZhbjogV2lsbCBsZXQg ZHJhZnQgZXhwaXJlIHVubGVzcyBzb21lb25lIGNvbWVzIGZvcndhcmQgd2l0aCBpbnRlcmVzdC4N Ck1hdXJpY2lvIFNhbmNoZXo6IFRoYW5rcyBmb3Igc3BlbmRpbmcgdGltZSBvbiB0aGlzLg0KDQoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQoNCjUuIER5bmFtaWMgUGVlciBEaXNjb3ZlcnksIFN0ZWZhbiBXaW50ZXINCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcmFkZXh0LWR5bmFtaWMtZGlzY292ZXJ5 DQpQcmVzZW50ZWQgYnkgU3RlZmFuIFdpbnRlci4NClNsaWRlZGVjazogaHR0cDovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy84MS9zbGlkZXMvcmFkZXh0LTAucGRmDQpTdGVmYW4gV2ludGVyOiBB c2tlZCBhYm91dCBJRVNHIGNvbW1lbnRzIG9uIERJTUUgZXF1aXYuDQpNYXJrIEpvbmVzOiBJRVNH IERJU0NVU1MgaXMgb24gZm9ybWF0IG9mIEFwcGxpY2F0aW9uIFByb3RvY29sIFRhZy4gQ29uY2Vy biB3YXMgdGhhdCB0aGUgY3VycmVudCBmb3JtYXQgaW5kaWNhdGVzIGEgc3RydWN0dXJlLg0KU3Rl ZmFuIFdpbnRlcjogQW55IElFU0cgY29tbWVudHMgb24gU2VydmljZSBUYWc/DQpNYXJrIEpvbmVz OiBOby4gSnVzdCBwcm90b2NvbCB0YWdzLg0KQ29tbWVudHMgb3IgcXVlc3Rpb25zOg0KRGFuIFJv bWFuYXNjdTogSm91bmksIENhbiB5b3UgY29tbWVudCBvbiBpc3N1ZXMgZW5jb3VudGVyZWQgaW4g RElNRT8NCkpvdW5pIEtvcmhvbmVuOiBOZWVkIHRvIHNvbHZlIHRoaXMgaW4gRElNRS4gTWFyayBn YXZlIHN1bW1hcnkgb2YgSUVTRyBjb25jZXJuLg0KRGFuIFJvbWFuYXNjdTogRG8gd2UgbmVlZCB0 byBzdG9wIHdvcmsgaW4gdGhpcz8NCkpvdW5pIEtvcmhvbmVuOiBOby4NCk1hcmsgSm9uZXM6IENv bmZpZGVudCB0aGF0IGxhYmVscyB3aWxsIGJlIHJlc29sdmVkLiBOb3QgZG9pbmcgYW55dGhpbmcg dW5uYXR1cmFsIHdpdGggb3VyIG9yaWdpbmFsIGxhYmVscy4gTm8gcmVhc29uIHRvIHN0b3Agd29y ayBvbiB0aGlzLg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KDQo2LiBSRkM0MjgyYmlzLCBBbGFuIERlS29rDQpQcmVzZW50 ZWQgYnkgQWxhbiBEZWtvaw0KU2xpZGVkZWNrOiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRp bmdzLzgxL3NsaWRlcy9yYWRleHQtNi5wcHQNCkRhbiBSb21hbmFzY3U6IFNvICA0MjgyYmlzIHN0 cmlwcyBvdXQgaW50ZXJuYXRpb25pemF0aW9uLCByaWdodD8gSG93IGlzIHRoaXMgc2VwYXJhdGlv biBiZWluZyBmb2xsb3dlZCBpbiBvdGhlciBncm91cHM/DQpBbGFuIERla29rOiBXb3JraW5nIHdp dGggUFJFQ0lTIG9uIHRoYXQgYXNwZWN0Lg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KNy4gUkFESVVTIFByb3RvY29sIEV4 dGVuc2lvbnMsIEFsYW4gRGVLb2sgKDEwIG1pbnV0ZXMpDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9ucw0KUHJlc2VudGVkIGJ5ICBB bGFuIERla29rLg0KU2xpZGVkZWNrOiAgaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84 MS9zbGlkZXMvcmFkZXh0LTgucHB0DQpEYW4gUm9tYW5hc2N1OiBTbyB0aGlzIGlzIGEgbmV3IHR5 cGUgYW5kIGlzIG5vdCBiYWNrd2FyZHMgY29tcGF0aWJsZT8NCkFsYW46IEJhY2t3YXJkcyBjb21w YXRpYmxlIGZvciBwcm94aWVzIHRoYXQgdHJlYXQgYXMgYW4gb3BhcXVlIGJsb2IuIElBTkEgc2F5 cyB0aGVzZSB0eXBlcyAoMjQxLTI0NCkgYXJlIG5vdCB1c2VkIGJ1dCB0aGV5IGFyZSB1c2VkIGlu IHRoZSByZWFsIHdvcmxkLiBUb3VnaC4NClNhbSBIYXJ0bWFuOiBJIGhhdmUgYSBkcmFmdCBpbiBh YmZhYiByZXF1aXJpbmcgdGhpcyBhbmQgd291bGQgbGlrZSB0byBzZWUgdGhpcyBnbyBmd2QuIFBs ZWFzZSBkb26hr3QgY2FsbCBpdCBhbiBPSUQgdGhvdWdoLg0KIEFsYW4gRGVrb2s6IEF1ZGl0IHNo b3dzIHRoYXQgdGhpcyBzaG91bGQgaGFuZGxlIGFsbG9jYXRpb24gbmVlZHMgZm9yIHRoZSBmb3Jl c2VlYWJsZSBmdXR1cmUuDQpTbyB3ZSBkb26hr3QgbmVlZCBhZGhvYyBmb3JtYXRzLiBKdXN0IGhl bHAgdGhlbSBpbXBsZW1lbnQgdGhpcyBuZXcgZm9ybWF0Lg0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQo4LiBSQURJVVMg b3ZlciBEVExTLCBBbGFuIERlS29rDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXJhZGV4dC1kdGxzDQpQcmVzZW50ZWQgYnkgIEFsYW4gRGVrb2suDQpTbGlkZWRlY2s6ICBo dHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgxL3NsaWRlcy9yYWRleHQtNy5wcHQNCk5v IHF1ZXN0aW9ucy4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCjkuIFJBRElVUyBvdmVyIFRMUywgU3RlZmFuIFdpbnRlciAo MTAgbWludXRlcykNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcmFkZXh0 LXJhZHNlYw0KUHJlc2VudGVkIHJlbW90ZWx5IGJ5IFN0ZWZhbiBXaW50ZXIuDQpTbGlkZWRlY2s6 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODEvc2xpZGVzL3JhZGV4dC0xLnBkZg0K TWF1cmljaW86IEFncmVlIHRoYXQgaXQgaXMgcmVhZHkgZm9yIFdHTEMuIEFueSBvdGhlciBjb21t ZW50cy9xdWVzdGlvbnM/DQpEYW4gUm9tYW5hc2N1OiBUQ1AgcG9ydCBhbGxvY2F0aW9uLiBJbnRl bnRpb24gaXMgdG8gcmV1c2UgcG9ydCBmb3IgcmFkc2VjLiBTbyBhcmUgdGhlcmUgYW55ICBiYWNr d2FyZHMgY29tcGF0YWJpbGl0eSBpc3N1ZXMuDQpTdGVmYW4gV2ludGVyOiBOby4gT2xkIHJhZHNl YyBpcyB0aGUgZm9ybWF0IGZvciBSQURJVVMvVExTLiBPQ1Mgc2FpZCBvbmNlIFJGQyBpcyBwdWJs aXNoZWQgdGhleSB3aWxsIGNoYW5nZSB0aGVpciBpbXBsZW1lbnRhdGlvbiB0byBkbyBpdCB0aGlz IHdheS4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KKE1hcmdhcmV0IHJlcXVlc3RlZCB0byBwcmVzZW50IGF0IFJBREVY VCBhZnRlciBhZ2VuZGEgYmFzaGluZyBoYWQgb2NjdXJyZWQgYW5kIFdHIGNoYWlycyBhY2NlcHRl ZCBwcmVzZW50YXRpb24gcmVxdWVzdCkNCg0KMTAuIE11bHRpaG9wIEZlZGVyYXRpb25zIChUcnVz dCBSb3V0ZXIpLg0KTWFyZ2FyZXQgV2Fzc2VybWFuDQpTbGlkZWRlY2s6IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvcHJvY2VlZGluZ3MvODEvc2xpZGVzL3JhZGV4dC05LnBwdHgNClBoaWxpcCBIYWxsYW0t QmFrZXI6IExvb2tzIGxpa2UgVVVDUC4gSXQgd2FzIHJlcGxhY2VkIHdpdGggRE5TLiBBbnl0aGlu ZyB0aGF0IGxvb2tzIGxpa2UgYSAgbmFtZXNwYWNlIHNob3VsZCBiZSB1c2luZyBETlMuIExvb2sg YXQgQnJpZGdlIENBcy4gVXNlZCBpbiBQS0kgc3BhY2UuIExvdHMgb2YgdW5pdiBhcmUgaW4gQnJp ZGdlIENhcy4gQ2FuIGFsc28gdXNlIFJ1bGVib29rIHN0cnVjdHVyZSBzbyBuZXZlciBuZWVkIGEg cGF0aCBvZiBtb3JlIHRoYW4gMiBzbyBkb26hr3QgbmVlZA0KQkdQLg0KTWFyZ2FyZXQgV2Fzc2Vy bWFuOiBUaGlzIGlzIG5vdCBhYm91dCBnZXR0aW5nIHRvIGV2ZXJ5IG5vZGUuIE9ubHkgYWJvdXQg Z2V0dGluZyBiZXR3ZWVuIG5vZGVzIGluIEFBQSBpbmZyYXN0cnVjdHVyZS4gVGhleSBhcmUgYWxs IElQIG5vZGVzIGFuZCBhbHJlYWR5IGluIEJHUA0KUGhpbGlwIEhhbGxhbS1CYWtlcjogWW91IHdp bGwgZmluZCB5b3UgdXNlIG9ubHkgMTAlIG9mIEJHUCBhbmQgbm90IHRoZSBpbnRlcmVzdGluZyBw YXJ0Lg0KSGFubmVzOiBEcmFmdCBhZGRyZXNzZXMgc29tZSBvZiB0aGUgaXNzdWVzLiBSZWxhdGlv bnNoaXAgYXJlIG5vdCBwdXJlbHkgbWVjaGFuaWNhbC4gRG9uoa90IHdhbnQgdG8gdGFsayB0byBl dmVyeW9uZS4gTGlrZSBTQU1MLCBMaWJlcnR5IEFsbGlhbmNlLiBDb21lIHVwIHdpdGggY2lyY2xl IG9mIHRydXN0LiBUaGV5IGV4aXN0IGluIEFBQSBzcGFjZS4gVGhlIFRydXN0IFJvdXRlciBzZXR1 cCBhbGxvd3Mgc2hvcnRjdXRzLg0KQWxhbiBEZWtvazogRWNobyBIYW5uZXMuIE5lZWQgdG8gcmVw cmVzZW50IGJpeiByZWxhdGlvbnNoaXBzOiBXaG8gdG8gdGFsayB0byBkZXBlbmRzIG9uIHdobyBp cyBhc2tpbmcuIFN0aWxsIGhhdmUgcXVlc3Rpb25zIG9uIHRoZSBkZXRhaWxzDQpNYXJnYXJldCBX YXNzZXJtYW46IFRoaXMgbGV0cyB5b3UgcHV0IHBvbGljeSBpbiBpbnRlcmVzdGluZyBwbGFjZXMg KGxvY2FsIHRydXN0IHJvdXRlcikuIEUuZy4gbm90IHJvdXRlIHNob3VsZCBSdXNzaWFuIG5vZGVz IGV2ZW4gaWYgdGhlIHJvdXRlIGlzIHNob3J0ZXIuDQpLbGFhcyBXaWVyZW5nYTogVGhpcyB3b3Jr IGlzIG1vdGl2YXRlZCBieSBwcm9ibGVtcyBzZWVuIGluIGxhcmdlIHNjYWxlIFNBTUwgZGVwbG95 bWVudHMuIEVzcCB0byBleHByZXNzIGNvbXBsZXggcG9saWNlcyBhcm91bmQgd2hvIHlvdSB3YW50 IHRvIHRydXN0LiBTaGFyZSBzb21lIG9mIFBoaWxpcHMgY29uY2VybnMNClBoaWxpcCBIYWxsYW0t QmFrZXI6IFdvcmtpbmcgb24gdGhpcyBwcm9ibGVtIGZvciAxNXlycy4gU2ltaWxhciB0byBvdGhl ciBhcHByb2FjaGVzIHRoYXQgaGF2ZSBhbHJlYWR5IGJlZW4gaW1wbGVtZW50ZWQuDQpTYW0gSGFy dG1hbjogVGhpcyBpcyBpbiB0aGUgZHJhZnQuDQpQaGlsaXA6IFdoeSBub3QgaW4gdGhlIHByZXNl bnRhdGlvbj8NCk1hcmdhcmV0IFdhc3Nlcm1hbjogTm90IGFjY2VwdGVkIGFzIFdHIGl0ZW0gaW4g YWJmYWIuIEZlZWRiYWNrIHJlcXVpcmVkIG9uIGFiZmFiIGxpc3QuDQpIYW5uZXM6IEFsc28gdGFs a2luZyB0byBWT0lQIGZvbGtzIHdobyBhcmUgcmV1c2luZyBCR1AgY29uY2VwdHMuDQpNYXJnYXJl dCBXYXNzZXJtYW46IHdlIGhhdmUgbm90IHdyaXR0ZW4gdGhlc2UgcHJvdG9jb2xzLiBJZiBhIGJl dHRlciB3YXksIHBsZWFzZSBleHBsYWluLg0KUGhpbGlwIEhhbGxhbS1CYWtlcjogVGhpbmtpbmcg YXMgYSBDQS4gU29tZW9uZSBoYXMgdG8gbWFuYWdlIGl0IGFuZCBtb25leSB3aWxsIGZsb3cgYXJv dW5kLiBUaGUgdGFzayBvZiBpbnRyb2R1Y3Rpb24gaXMgZ29pbmcgdG8gYmUgcGFpZC4gTWF5IHdh bnQgdG8gcGF5IHByZW1pdW0gdG8gZmluZCBhIHBhdGggd2l0aCBhIGhpZ2hlciBkZWdyZWUgb2Yg dHJ1c3QuDQpNYXJnYXJldCBXYXNzZXJtYW46IEFsbG93cyBmb3IgYml6IGludGVsbGlnZW5jZSBh dCBtYW55IGRpZmZlcmVudCBsYXllcnMuDQpQaGlsaXAgSGFsbGFtLUJha2VyOiBDb250cmFjdHMg d2lsbCBkZXRlcm1pbmUgdGhpcy4gRG9uoa90IG5lZWQgdGhpcyBob3AgYnkgaG9wLiBDYW4gdGFr ZSB0aGlzIG9mZmxpbmUuDQpNYXJnYXJldCBXYXNzZXJtYW46IFdvdWxkIGJlIGludGVyZXN0ZWQg aW4gdGhvc2UgcG9pbnRlcnMgdG8gYXBwcm9hY2hlcyBhbHJlYWR5IHRyaWVkLg0KS2xhYXMgV2ll cmVuZ2E6IFRoaXMgZ29lcyBiZXlvbmQgYWJmYWIuIFNvIEFEIHB1c2hlZCB1cyB0byBwcmVzZW50 IGluIG90aGVyIGdyb3VwcyB0aGF0IHNlZSB0aGUgc2FtZSB0eXBlIG9mIHByb2JsZW0uIFdlbGNv bWUgYSBicm9hZCBkaXNjdXNzaW9uLg0KTWFyZ2FyZXQgV2Fzc2VybWFuOiBPbiBhZ2VuZGEgaW4g YWJmYWIgb24gRnJpZGF5IG1vcm5pbmcuDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQoxMS4gRW1haWwgbGlzdCBz ZXJ2ZXIgbWlncmF0aW9uDQpEYW4gUm9tYW5hc2N1OiBQbGVhc2UgZXhwbGFpbiB3aGF0IGl0IG1l YW5zIGZvciBwZW9wbGUgb24gdGhlIGxpc3QuDQpNYXVyaWNpbzogTm90aGluZy4gU2hvdWxkIGJl IHRyYW5zcGFyZW50LiBHb3QgYSBwcm9jZXNzIGZvciBhcmNoaXZlIG1pZ3JhdGlvbi4NCkpvdW5p OiBBdXRvIG1vdmUgb2Ygc3Vic2NyaWJlcnMgdG8gbmV3IGxpc3QuIEVtYWlscyB3aWxsIGJlIGZv cndhcmRlZCBiZXR3ZWVuIGxpc3RzLg0KU2VjcmV0YXJ5IHdpbGwgbW92ZSBhcmNoaXZlcy4NCkRh bjogT24gYmVoYWxmIG9mIGRvdWJ0ZXJzOiBDYW4geW91IGV4cGxhaW4gbWlncmF0aW9uIG9mIGFy Y2hpdmVzPw0KTWF1cmljaW86IE90aGVycyAoRnJlZCBCYWtlcikgY3JlYXRlZCB0aGUgcHJvY2Vz cyBmb3IgcGFpbmxlc3MgbWlncmF0aW9uIG9mIGFyY2hpdmVzLiBTbyB3ZQ0KRGFuOiBEbyByZWZl cmVuY2VzIG9uIHRoZSB0cmFja2VyIG5lZWQgdG8gY2hhbmdlPw0KSm91bmk6IERpcmVjdCBsaW5r cyB0byBhcmNoaXZlcyBuZWVkIHRvIGJlIHVwZGF0ZWQuDQpNYXVyaWNpbzogV2lsbCBuZWVkIHRv IGxvb2sgaW50byB0aGF0IGFuZCBtYWtlIHN1cmUgaXQgaXMgcmVtZWRpZWQuDQoNCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN CjEyLiBOZXh0IFN0ZXBzOiBXRyBDaGFpcnMgJiBBRHMNCldHIEdvYWxzL01pbGVzdG9uZXMgc3Rh dHVzDQpObyBxdWVzdGlvbnMNCg== --Boundary_(ID_CTBeIIdVcoMZCGN4hjNyyA) Content-id: <09C347C69B4FF241B6D3D80E744F9EDC@huawei.com> Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

I've sent a question of clarification to the mailing= list agaisnt draft-ietf-radext-ipv6-access-05. Pls. refer to https://ops.ietf.org/lists/radiusext/2010/msg00959.html.

 

Sorry for my poor expression in the Radext session. = I'd like to clarify my words in the meeting notes here. 

 

 

> 3. RADIUS Attributes for IPv6 Access Networks, = Wojcieh Dec

> http://tools.ietf.org/html/draft-ietf-radext-ip= v6-access

> Presented by Mauricio Sanchez.

> Slidedeck: http://www.ietf.org/proceedings/81/s= lides/radext-5.ppt

> Questions:

> Leaf  Yeh: In new version, new attribs. On= ly sends name of pool. DHCP already has a pool.

 

I meant the attribute of Framed-Pool (88, section 5.= 18 of RFC2869) here, which is used to send the pool name from AAA server to= NAS server, to indicate the right pool employed or configured on NAS.

 

> Doesn=A1=AFt think this is necessary. Attribute= s in v4 can already do this. There is no need to a v6 pool name.

> Leaf agreed to send concern to list

> Roberta Maglione: It is just a pool name. Seman= tics are different.

> Bernard Adoba: One is a prefix pool and the oth= er is an address pool. May need to do both at once.

> Leaf: But it is only a string. So DHCP server can use name format is disambiguate.

 

I meant the NAS can interprect the pool name receviv= ed from AAA server for each kind of usage, such as IPv4 PPP addre= ss pool, IPv6 SLAAC prefix pool, IPv6 DHCPv6 address pool or DHCPv6-PD pref= ix pool. 

 

> Mauricio Sanchez: Sounds like valid reason for = these two attributes. Please bring comments to

list.

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB: owner-radiusext@ops.iet= f.org [owner-radiusext@ops.ietf.org] =B4=FA=B1=ED Sanchez, Mauricio (HP Net= working) [mauricio.sanchez@hp.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C226=C8=D5 6:29
=B5=BD: 'radiusext@ops.ietf.org'
=D6=F7=CC=E2: RADEXT WG - IETF 81 preliminary meeting notes

These are the preliminary notes for IETF 81. Many th= anks to Mark Jones for taking notes this morning.  Comments/correction= s welcome.

 

-MS

 

----------------------------------------------------= ----------------------------------------------------------

RADEXT WG Minutes

IETF 81

Quebec, Canada

Monday, July 25th, 2011

Meeting started 9:02 AM and ended 11:27AM EDT. Appro= ximately 35 individuals in meeting

 

Chairs:

Jouni Korhonen <jouni.korhonen@nsn.com>

Mauricio Sanchez <mauricio.sanchez@hp.com>

 

1. Preliminaries

 

Agenda slides: http://www.ietf.org/proceedings/81/sl= ides/radext-3.pptx

 

Attendees: Bluesheets circulated.

Note Well

Note Takers

- Note volunteer Mark Jones

Jabber scribe

- Alan DeKok jabber scribe

Agenda bash

- IPv6, enhancements, security grouped item.  N= o changes to agenda made

 

****************************************************= ************

 

2. Radius Extensions for CGN Configurations, Dean Ch= eng

http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-ra= dius-ext-00.txt

 

Presented by Dean Cheng.

Slidedeck: http://www.ietf.org/proceedings/81/slides= /radext-2.ppt

Hannes Tschofenig: Slide 3: Do you now assume DHCP b= etween end host and NAT?

Dean Cheng: Service Request is a general term but no= change.

Hannes Tschofenig: What happens when NAT runs out of= ports?

Dean Cheng: Number of ports are configured on server= . It is used to limit.

Hannes Tschofenig: What happens in failure case? i.e= . you reach restriction.

Dean Cheng: AAA only returns limits. If use wants mo= re ports, ICMP can be used to indicate

error.

Hannes Tschofenig: How do you ensure ICMP reaches en= d host?

Dean Cheng: OK. We can discuss offline.

Mauricio Sanchez:  Slide 5: Did you read RFC615= 8 RADIUS Guidelines

Dean Cheng: Yes. Need some help on these encoding wr= t RADIUS guidelines.

---

Questions:

Mauricio Sanchez: Where is this in BEHAVE WG?

Dean: Result of merge of two drafts to BEHAVE. Chair= suggested to present in RADEXT because

comments received were on RADIUS aspects

Dan Romanascu: Is this a charter item in BEHAVE.

Dean: No. Still be chartered. Chair said it is withi= n scope of BEHAVE.

Dan: What do you need from RADEXT? Advisor? WGLC?

Dean: BEHAVE suggest to present in RADEXT to get com= ments.

Dan: In draft, need to expand acronyms.

Hannes: (1) Need to define bigger picture. NAT behav= iour when it runs out of resources. Need to know why it fails. (2) AAA clie= nt does not live on NAT. DHCP and NAT are mashed together but it depends ho= w these are related.

Dean: AAA client is not changed. NAT44 must be co-lo= cated with BNG.

Hannes: Very special scenario.

Dean: If CNG (NAT44) not colo with BNG this falls ap= art.

Dan: Any other mechanisms to configure CNG other tha= n this draft?

Dean: No change. Only leverages existing deployment.=

 

****************************************************= ************

 

3. RADIUS Attributes for IPv6 Access Networks, Wojci= eh Dec

http://tools.ietf.org/html/draft-ietf-radext-ipv6-ac= cess

Presented by Mauricio Sanchez.

Slidedeck: http://www.ietf.org/proceedings/81/slides= /radext-5.ppt

Questions:

Leaf  Yeh: In new version, new attribs. Only se= nds name of pool. DHCP already has a pool.

Doesn=A1=AFt think this is necessary. Attributes in = v4 can already do this. There is no need to a v6 pool name.

Leaf agreed to send concern to list

Roberta Maglione: It is just a pool name. Semantics = are different.

Bernard Adoba: One is a prefix pool and the other is= an address pool. May need to do both at

once.

Leaf: But it is only a string. So DHCP server can us= e name format is disambiguate.

Mauricio Sanchez: Sounds like valid reason for these= two attributes. Please bring comments to

list.

****************************************************= ************

4. RADIUS accounting for traffic classes, Stefan Win= ter

http://tools.ietf.org/html/draft-winter-radext-fancy= accounting

Presented remotely by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings/81/slides= /radext-4.pdf

Other issues:

Mark Jones: We don=A1=AFt need to include filter def= inition in accounting stream. Just include filter name (bucket label) in th= e accounting stream.

Stefan: Ok. Nice and simple. Works for me.

Dan Romanascu : Reuse definitions from RFC4898

Mauricio Sanchez: Concerned about number of drafts t= o progress. Does not want to oversubscribe WG. Poll: Who is interested in t= his work? Who will help out if WG item?

Show of hands in room:

Relevant and useful: No interest.

Stefan: Will let draft expire unless someone comes f= orward with interest.

Mauricio Sanchez: Thanks for spending time on this. =

 

****************************************************= ************

 

5. Dynamic Peer Discovery, Stefan Winter

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

Presented by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings/81/slides= /radext-0.pdf

Stefan Winter: Asked about IESG comments on DIME equ= iv.

Mark Jones: IESG DISCUSS is on format of Application= Protocol Tag. Concern was that the current format indicates a structure.

Stefan Winter: Any IESG comments on Service Tag?

Mark Jones: No. Just protocol tags.

Comments or questions:

Dan Romanascu: Jouni, Can you comment on issues enco= untered in DIME?

Jouni Korhonen: Need to solve this in DIME. Mark gav= e summary of IESG concern.

Dan Romanascu: Do we need to stop work in this?

Jouni Korhonen: No.

Mark Jones: Confident that labels will be resolved. = Not doing anything unnatural with our original labels. No reason to stop wo= rk on this.

****************************************************= ************

 

6. RFC4282bis, Alan DeKok

Presented by Alan Dekok

Slidedeck: http://www.ietf.org/proceedings/81/slides= /radext-6.ppt

Dan Romanascu: So  4282bis strips out internati= onization, right? How is this separation being followed in other groups?

Alan Dekok: Working with PRECIS on that aspect.

****************************************************= ************

7. RADIUS Protocol Extensions, Alan DeKok (10 minute= s)

http://tools.ietf.org/html/draft-ietf-radext-radius-= extensions

Presented by  Alan Dekok.

Slidedeck:  http://www.ietf.org/proceedings/81/= slides/radext-8.ppt

Dan Romanascu: So this is a new type and is not back= wards compatible?

Alan: Backwards compatible for proxies that treat as= an opaque blob. IANA says these types (241-244) are not used but they are = used in the real world. Tough.

Sam Hartman: I have a draft in abfab requiring this = and would like to see this go fwd. Please don=A1=AFt call it an OID though.=  

 Alan Dekok: Audit shows that this should handl= e allocation needs for the foreseeable future.

So we don=A1=AFt need adhoc formats. Just help them = implement this new format.

****************************************************= ************

 

8. RADIUS over DTLS, Alan DeKok

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

Presented by  Alan Dekok.

Slidedeck:  http://www.ietf.org/proceedings/81/= slides/radext-7.ppt

No questions.

****************************************************= ************

9. RADIUS over TLS, Stefan Winter (10 minutes)

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

Presented remotely by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings/81/slides= /radext-1.pdf

Mauricio: Agree that it is ready for WGLC. Any other= comments/questions?

Dan Romanascu: TCP port allocation. Intention is to = reuse port for radsec. So are there any  backwards compatability issue= s.

Stefan Winter: No. Old radsec is the format for RADI= US/TLS. OCS said once RFC is published they will change their implementatio= n to do it this way.

 

****************************************************= ************

(Margaret requested to present at RADEXT after agend= a bashing had occurred and WG chairs accepted presentation request) 

 

10. Multihop Federations (Trust Router).

Margaret Wasserman

Slidedeck: http://www.ietf.org/proceedings/81/slides= /radext-9.pptx

Philip Hallam-Baker: Looks like UUCP. It was replace= d with DNS. Anything that looks like a  namespace should be using DNS.= Look at Bridge CAs. Used in PKI space. Lots of univ are in Bridge Cas. Can= also use Rulebook structure so never need a path of more than 2 so don=A1=AFt need

BGP.

Margaret Wasserman: This is not about getting to eve= ry node. Only about getting between nodes in AAA infrastructure. They are a= ll IP nodes and already in BGP

Philip Hallam-Baker: You will find you use only 10% = of BGP and not the interesting part.

Hannes: Draft addresses some of the issues. Relation= ship are not purely mechanical. Don=A1=AFt want to talk to everyone. Like S= AML, Liberty Alliance. Come up with circle of trust. They exist in AAA spac= e. The Trust Router setup allows shortcuts.

Alan Dekok: Echo Hannes. Need to represent biz relat= ionships: Who to talk to depends on who is asking. Still have questions on = the details

Margaret Wasserman: This lets you put policy in inte= resting places (local trust router). E.g. not route should Russian nodes ev= en if the route is shorter.

Klaas Wierenga: This work is motivated by problems s= een in large scale SAML deployments. Esp to express complex polices around = who you want to trust. Share some of Philips concerns

Philip Hallam-Baker: Working on this problem for 15y= rs. Similar to other approaches that have already been implemented.

Sam Hartman: This is in the draft.

Philip: Why not in the presentation?

Margaret Wasserman: Not accepted as WG item in abfab= . Feedback required on abfab list.

Hannes: Also talking to VOIP folks who are reusing B= GP concepts.

Margaret Wasserman: we have not written these protoc= ols. If a better way, please explain.

Philip Hallam-Baker: Thinking as a CA. Someone has t= o manage it and money will flow around. The task of introduction is going t= o be paid. May want to pay premium to find a path with a higher degree of t= rust.

Margaret Wasserman: Allows for biz intelligence at m= any different layers.

Philip Hallam-Baker: Contracts will determine this. = Don=A1=AFt need this hop by hop. Can take this offline.

Margaret Wasserman: Would be interested in those poi= nters to approaches already tried.

Klaas Wierenga: This goes beyond abfab. So AD pushed= us to present in other groups that see the same type of problem. Welcome a= broad discussion.

Margaret Wasserman: On agenda in abfab on Friday mor= ning.

 

 

****************************************************= ************

 

11. Email list server migration

Dan Romanascu: Please explain what it means for peop= le on the list.

Mauricio: Nothing. Should be transparent. Got a proc= ess for archive migration.

Jouni: Auto move of subscribers to new list. Emails = will be forwarded between lists. 

Secretary will move archives.

Dan: On behalf of doubters: Can you explain migratio= n of archives?

Mauricio: Others (Fred Baker) created the process fo= r painless migration of archives. So we

Dan: Do references on the tracker need to change?

Jouni: Direct links to archives need to be updated.<= /p>

Mauricio: Will need to look into that and make sure = it is remedied.

 

****************************************************= ************

12. Next Steps: WG Chairs & ADs

WG Goals/Milestones status

No questions

--Boundary_(ID_CTBeIIdVcoMZCGN4hjNyyA)-- -- to 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 Jul 26 07:26:09 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 8F55621F8C80 for ; Tue, 26 Jul 2011 07:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O67UbnWYZhY for ; Tue, 26 Jul 2011 07:26:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A283A21F8C5D for ; Tue, 26 Jul 2011 07:26:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QliXK-000IXo-Hm for radiusext-data0@psg.com; Tue, 26 Jul 2011 14:23:06 +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 1QliXI-000IXX-Lh for radiusext@ops.ietf.org; Tue, 26 Jul 2011 14:23:04 +0000 Received: from dhcp-12d2.meeting.ietf.org (dhcp-12d2.meeting.ietf.org [130.129.18.210]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 657E612340D7 for ; Tue, 26 Jul 2011 16:23:02 +0200 (CEST) Message-ID: <4E2ECDC5.5060207@deployingradius.com> Date: Tue, 26 Jul 2011 10:23:01 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: 'radext mailing list' Subject: Last call on 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: Can we do a last call on the extensions document? The list has had little discussion on it. I think the name will need to change, as RFC 2868 is already RADIUS extensions. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jul 26 08:30: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 7FDE321F8698 for ; Tue, 26 Jul 2011 08:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ipgDGOhUZab for ; Tue, 26 Jul 2011 08:30:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 97C8F21F8696 for ; Tue, 26 Jul 2011 08:30:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QljXc-000MVL-Qg for radiusext-data0@psg.com; Tue, 26 Jul 2011 15:27:28 +0000 Received: from g1t0029.austin.hp.com ([15.216.28.36]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QljXa-000MV6-Ci for radiusext@ops.ietf.org; Tue, 26 Jul 2011 15:27:26 +0000 Received: from G9W0369G.americas.hpqcorp.net (g9w0369g.houston.hp.com [16.216.193.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id 2A09A380B2; Tue, 26 Jul 2011 15:27:22 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G9W0369G.americas.hpqcorp.net (16.216.193.232) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 26 Jul 2011 15:26:18 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Tue, 26 Jul 2011 16:26:19 +0100 From: "Sanchez, Mauricio (HP Networking)" To: Alan DeKok CC: "'radiusext@ops.ietf.org'" Date: Tue, 26 Jul 2011 16:26:16 +0100 Subject: RE: Last call on extensions document? Thread-Topic: Last call on extensions document? Thread-Index: AcxLn6fLh8u7tcMKRWWzcveQ2fot6AAB7n/w Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C786AA943@GVW0671EXC.americas.hpqcorp.net> References: <4E2ECDC5.5060207@deployingradius.com> In-Reply-To: <4E2ECDC5.5060207@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: You mean RFC 2869? Nonetheless, I agree that name has to change and avoid = the collision with prior work. How about something like 'RADIUS Attribute = Extensions'? -MS =20 -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= Behalf Of Alan DeKok Sent: Tuesday, July 26, 2011 10:23 AM To: 'radext mailing list' Subject: Last call on extensions document? Can we do a last call on the extensions document? The list has had littl= e discussion on it. I think the name will need to change, as RFC 2868 is already RADIUS exten= sions. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the wo= rd 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jul 26 08:52:15 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 4798911E80DF for ; Tue, 26 Jul 2011 08:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTl6OeVRazFs for ; Tue, 26 Jul 2011 08:52:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 87F4311E80D8 for ; Tue, 26 Jul 2011 08:52:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qljtk-000NUp-Vw for radiusext-data0@psg.com; Tue, 26 Jul 2011 15:50:20 +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 1Qljtj-000NUg-6D for radiusext@ops.ietf.org; Tue, 26 Jul 2011 15:50:19 +0000 Received: from dhcp-12d2.meeting.ietf.org (dhcp-12d2.meeting.ietf.org [130.129.18.210]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 3695212340D7; Tue, 26 Jul 2011 17:50:17 +0200 (CEST) Message-ID: <4E2EE238.4040103@deployingradius.com> Date: Tue, 26 Jul 2011 11:50:16 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" CC: "'radiusext@ops.ietf.org'" Subject: Re: Last call on extensions document? References: <4E2ECDC5.5060207@deployingradius.com> <9BC2F7926B33FE4AB10D69891D58FC1C5C786AA943@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5C786AA943@GVW0671EXC.americas.hpqcorp.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Sanchez, Mauricio (HP Networking) wrote: > You mean RFC 2869? Nonetheless, I agree that name has to change and avoid the collision with prior work. How about something like 'RADIUS Attribute Extensions'? Sounds good to me. I'll make the change for the next rev of the document. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Jul 26 10:50: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 EDD2D11E810E for ; Tue, 26 Jul 2011 10:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=-0.993, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO9EyGJ24ycG for ; Tue, 26 Jul 2011 10:50:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 6974321F8A66 for ; Tue, 26 Jul 2011 10:50:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qllj1-0002OD-Vo for radiusext-data0@psg.com; Tue, 26 Jul 2011 17:47:23 +0000 Received: from mail-vx0-f180.google.com ([209.85.220.180]) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qllii-0002ML-OI for radiusext@ops.ietf.org; Tue, 26 Jul 2011 17:47:05 +0000 Received: by vxj12 with SMTP id 12so726008vxj.11 for ; Tue, 26 Jul 2011 10:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V/0mnh1fKJMYxVXAziywaH7GogROzO4GgbBP5cEMWzM=; b=QEdSbY78n6nw7IxDGyXZBM3/81IfHtlPrzcjreuH+9X3s+0uuxQwJpjvVM/r/6u7Fz QX48T64Tz5PnKcmX2KMNSQvSOp0HisWN+PHe2XKke1SUcptEtqMhjMI1pyRG+cWNDMIj xcBf+1oRYP79I2wJ4mLjnmUJylj/fDkzTsc8s= MIME-Version: 1.0 Received: by 10.52.90.226 with SMTP id bz2mr2781578vdb.271.1311702423624; Tue, 26 Jul 2011 10:47:03 -0700 (PDT) Received: by 10.52.115.9 with HTTP; Tue, 26 Jul 2011 10:47:03 -0700 (PDT) In-Reply-To: References: <9BC2F7926B33FE4AB10D69891D58FC1C5C78185121@GVW0671EXC.americas.hpqcorp.net> Date: Wed, 27 Jul 2011 01:47:03 +0800 Message-ID: Subject: Re: RADEXT WG - IETF 81 preliminary meeting notes From: Jacni Qin To: Leaf yeh Cc: "Sanchez, Mauricio (HP Networking)" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang , Behcet Sarikaya Content-Type: multipart/alternative; boundary=20cf307cff5402ddb004a8fc8508 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --20cf307cff5402ddb004a8fc8508 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi, A quick comment, I'm concerned by the "Stateful-IPv6-Address-Pool" attribute, why can't we re-use the Frame-* one? Cheers, Jacni 2011/7/26 Leaf yeh > I've sent a question of clarification to the mailing list agaisnt > draft-ietf-radext-ipv6-access-05. Pls. refer to > https://ops.ietf.org/lists/radiusext/2010/msg00959.html. > > > > Sorry for my poor expression in the Radext session. I'd like to clarify m= y > words in the meeting notes here. > > > > > > > 3. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec > > > http://tools.ietf.org/html/draft-ietf-radext-ipv6-access > > > Presented by Mauricio Sanchez. > > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-5.ppt > > > Questions: > > > Leaf Yeh: In new version, new attribs. Only sends name of pool. *DHCP*= already has a pool. > > > > I meant the attribute of Framed-Pool (88, section 5.18 of RFC2869) here, > which is used to send the pool name from AAA server to NAS server, to > indicate the right pool employed or configured on NAS. > > > > > Doesn=A1=AFt think this is necessary. Attributes in v4 can already do t= his. > There is no need to a v6 pool name. > > > Leaf agreed to send concern to list > > > Roberta Maglione: It is just a pool name. Semantics are different. > > > Bernard Adoba: One is a prefix pool and the other is an address pool. M= ay > need to do both at once. > > > Leaf: But it is only a string. So *DHCP server* can use name format is > disambiguate. > > > > I meant the NAS can interprect the pool name recevived from AAA > server for each kind of usage, such as IPv4 PPP address pool, IPv6 SLAAC > prefix pool, IPv6 DHCPv6 address pool or DHCPv6-PD prefix pool. > > > > > Mauricio Sanchez: Sounds like valid reason for these two attributes. > Please bring comments to > > list. > > > > > > Best Regards, > > Leaf > > > > > > ------------------------------ > > *=B7=A2=BC=FE=C8=CB:* owner-radiusext@ops.ietf.org [owner-radiusext@ops.i= etf.org] =B4=FA=B1=ED > Sanchez, Mauricio (HP Networking) [mauricio.sanchez@hp.com] > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2011=C4=EA7=D4=C226=C8=D5 6:29 > *=B5=BD:* 'radiusext@ops.ietf.org' > *=D6=F7=CC=E2:* RADEXT WG - IETF 81 preliminary meeting notes > > These are the preliminary notes for IETF 81. Many thanks to Mark Jones > for taking notes this morning. Comments/corrections welcome. > > > > -MS > > > > > -------------------------------------------------------------------------= ------------------------------------- > > RADEXT WG Minutes > > IETF 81 > > Quebec, Canada > > Monday, July 25th, 2011 > > Meeting started 9:02 AM and ended 11:27AM EDT. Approximately 35 individua= ls > in meeting > > > > Chairs: > > Jouni Korhonen > > Mauricio Sanchez > > > > 1. Preliminaries > > > > Agenda slides: http://www.ietf.org/proceedings/81/slides/radext-3.pptx > > > > Attendees: Bluesheets circulated. > > Note Well > > Note Takers > > - Note volunteer Mark Jones > > Jabber scribe > > - Alan DeKok jabber scribe > > Agenda bash > > - IPv6, enhancements, security grouped item. No changes to agenda made > > > > **************************************************************** > > > > 2. Radius Extensions for CGN Configurations, Dean Cheng > > http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-radius-ext-00.txt > > > > Presented by Dean Cheng. > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-2.ppt > > Hannes Tschofenig: Slide 3: Do you now assume DHCP between end host and > NAT? > > Dean Cheng: Service Request is a general term but no change. > > Hannes Tschofenig: What happens when NAT runs out of ports? > > Dean Cheng: Number of ports are configured on server. It is used to limit= . > > Hannes Tschofenig: What happens in failure case? i.e. you reach > restriction. > > Dean Cheng: AAA only returns limits. If use wants more ports, ICMP can be > used to indicate > > error. > > Hannes Tschofenig: How do you ensure ICMP reaches end host? > > Dean Cheng: OK. We can discuss offline. > > Mauricio Sanchez: Slide 5: Did you read RFC6158 RADIUS Guidelines > > Dean Cheng: Yes. Need some help on these encoding wrt RADIUS guidelines. > > --- > > Questions: > > Mauricio Sanchez: Where is this in BEHAVE WG? > > Dean: Result of merge of two drafts to BEHAVE. Chair suggested to present > in RADEXT because > > comments received were on RADIUS aspects > > Dan Romanascu: Is this a charter item in BEHAVE. > > Dean: No. Still be chartered. Chair said it is within scope of BEHAVE. > > Dan: What do you need from RADEXT? Advisor? WGLC? > > Dean: BEHAVE suggest to present in RADEXT to get comments. > > Dan: In draft, need to expand acronyms. > > Hannes: (1) Need to define bigger picture. NAT behaviour when it runs out > of resources. Need to know why it fails. (2) AAA client does not live on > NAT. DHCP and NAT are mashed together but it depends how these are relate= d. > > Dean: AAA client is not changed. NAT44 must be co-located with BNG. > > Hannes: Very special scenario. > > Dean: If CNG (NAT44) not colo with BNG this falls apart. > > Dan: Any other mechanisms to configure CNG other than this draft? > > Dean: No change. Only leverages existing deployment. > > > > **************************************************************** > > > > 3. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec > > http://tools.ietf.org/html/draft-ietf-radext-ipv6-access > > Presented by Mauricio Sanchez. > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-5.ppt > > Questions: > > Leaf Yeh: In new version, new attribs. Only sends name of pool. DHCP > already has a pool. > > Doesn=A1=AFt think this is necessary. Attributes in v4 can already do thi= s. > There is no need to a v6 pool name. > > Leaf agreed to send concern to list > > Roberta Maglione: It is just a pool name. Semantics are different. > > Bernard Adoba: One is a prefix pool and the other is an address pool. May > need to do both at > > once. > > Leaf: But it is only a string. So DHCP server can use name format is > disambiguate. > > Mauricio Sanchez: Sounds like valid reason for these two attributes. Plea= se > bring comments to > > list. > > **************************************************************** > > 4. RADIUS accounting for traffic classes, Stefan Winter > > http://tools.ietf.org/html/draft-winter-radext-fancyaccounting > > Presented remotely by Stefan Winter. > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-4.pdf > > Other issues: > > Mark Jones: We don=A1=AFt need to include filter definition in accounting > stream. Just include filter name (bucket label) in the accounting stream. > > Stefan: Ok. Nice and simple. Works for me. > > Dan Romanascu : Reuse definitions from RFC4898 > > Mauricio Sanchez: Concerned about number of drafts to progress. Does not > want to oversubscribe WG. Poll: Who is interested in this work? Who will > help out if WG item? > > Show of hands in room: > > Relevant and useful: No interest. > > Stefan: Will let draft expire unless someone comes forward with interest. > > Mauricio Sanchez: Thanks for spending time on this. > > > > **************************************************************** > > > > 5. Dynamic Peer Discovery, Stefan Winter > > http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery > > Presented by Stefan Winter. > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-0.pdf > > Stefan Winter: Asked about IESG comments on DIME equiv. > > Mark Jones: IESG DISCUSS is on format of Application Protocol Tag. Concer= n > was that the current format indicates a structure. > > Stefan Winter: Any IESG comments on Service Tag? > > Mark Jones: No. Just protocol tags. > > Comments or questions: > > Dan Romanascu: Jouni, Can you comment on issues encountered in DIME? > > Jouni Korhonen: Need to solve this in DIME. Mark gave summary of IESG > concern. > > Dan Romanascu: Do we need to stop work in this? > > Jouni Korhonen: No. > > Mark Jones: Confident that labels will be resolved. Not doing anything > unnatural with our original labels. No reason to stop work on this. > > **************************************************************** > > > > 6. RFC4282bis, Alan DeKok > > Presented by Alan Dekok > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-6.ppt > > Dan Romanascu: So 4282bis strips out internationization, right? How is > this separation being followed in other groups? > > Alan Dekok: Working with PRECIS on that aspect. > > **************************************************************** > > 7. RADIUS Protocol Extensions, Alan DeKok (10 minutes) > > http://tools.ietf.org/html/draft-ietf-radext-radius-extensions > > Presented by Alan Dekok. > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-8.ppt > > Dan Romanascu: So this is a new type and is not backwards compatible? > > Alan: Backwards compatible for proxies that treat as an opaque blob. IANA > says these types (241-244) are not used but they are used in the real wor= ld. > Tough. > > Sam Hartman: I have a draft in abfab requiring this and would like to see > this go fwd. Please don=A1=AFt call it an OID though. > > Alan Dekok: Audit shows that this should handle allocation needs for the > foreseeable future. > > So we don=A1=AFt need adhoc formats. Just help them implement this new fo= rmat. > > **************************************************************** > > > > 8. RADIUS over DTLS, Alan DeKok > > http://tools.ietf.org/html/draft-ietf-radext-dtls > > Presented by Alan Dekok. > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-7.ppt > > No questions. > > **************************************************************** > > 9. RADIUS over TLS, Stefan Winter (10 minutes) > > http://tools.ietf.org/html/draft-ietf-radext-radsec > > Presented remotely by Stefan Winter. > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-1.pdf > > Mauricio: Agree that it is ready for WGLC. Any other comments/questions? > > Dan Romanascu: TCP port allocation. Intention is to reuse port for radsec= . > So are there any backwards compatability issues. > > Stefan Winter: No. Old radsec is the format for RADIUS/TLS. OCS said once > RFC is published they will change their implementation to do it this way. > > > > **************************************************************** > > (Margaret requested to present at RADEXT after agenda bashing had occurre= d > and WG chairs accepted presentation request) > > > > 10. Multihop Federations (Trust Router). > > Margaret Wasserman > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-9.pptx > > Philip Hallam-Baker: Looks like UUCP. It was replaced with DNS. Anything > that looks like a namespace should be using DNS. Look at Bridge CAs. Use= d > in PKI space. Lots of univ are in Bridge Cas. Can also use Rulebook > structure so never need a path of more than 2 so don=A1=AFt need > > BGP. > > Margaret Wasserman: This is not about getting to every node. Only about > getting between nodes in AAA infrastructure. They are all IP nodes and > already in BGP > > Philip Hallam-Baker: You will find you use only 10% of BGP and not the > interesting part. > > Hannes: Draft addresses some of the issues. Relationship are not purely > mechanical. Don=A1=AFt want to talk to everyone. Like SAML, Liberty Allia= nce. > Come up with circle of trust. They exist in AAA space. The Trust Router > setup allows shortcuts. > > Alan Dekok: Echo Hannes. Need to represent biz relationships: Who to talk > to depends on who is asking. Still have questions on the details > > Margaret Wasserman: This lets you put policy in interesting places (local > trust router). E.g. not route should Russian nodes even if the route is > shorter. > > Klaas Wierenga: This work is motivated by problems seen in large scale SA= ML > deployments. Esp to express complex polices around who you want to trust. > Share some of Philips concerns > > Philip Hallam-Baker: Working on this problem for 15yrs. Similar to other > approaches that have already been implemented. > > Sam Hartman: This is in the draft. > > Philip: Why not in the presentation? > > Margaret Wasserman: Not accepted as WG item in abfab. Feedback required o= n > abfab list. > > Hannes: Also talking to VOIP folks who are reusing BGP concepts. > > Margaret Wasserman: we have not written these protocols. If a better way, > please explain. > > Philip Hallam-Baker: Thinking as a CA. Someone has to manage it and money > will flow around. The task of introduction is going to be paid. May want = to > pay premium to find a path with a higher degree of trust. > > Margaret Wasserman: Allows for biz intelligence at many different layers. > > Philip Hallam-Baker: Contracts will determine this. Don=A1=AFt need this = hop by > hop. Can take this offline. > > Margaret Wasserman: Would be interested in those pointers to approaches > already tried. > > Klaas Wierenga: This goes beyond abfab. So AD pushed us to present in oth= er > groups that see the same type of problem. Welcome a broad discussion. > > Margaret Wasserman: On agenda in abfab on Friday morning. > > > > > > **************************************************************** > > > > 11. Email list server migration > > Dan Romanascu: Please explain what it means for people on the list. > > Mauricio: Nothing. Should be transparent. Got a process for archive > migration. > > Jouni: Auto move of subscribers to new list. Emails will be forwarded > between lists. > > Secretary will move archives. > > Dan: On behalf of doubters: Can you explain migration of archives? > > Mauricio: Others (Fred Baker) created the process for painless migration = of > archives. So we > > Dan: Do references on the tracker need to change? > > Jouni: Direct links to archives need to be updated. > > Mauricio: Will need to look into that and make sure it is remedied. > > > > **************************************************************** > > 12. Next Steps: WG Chairs & ADs > > WG Goals/Milestones status > > No questions > --20cf307cff5402ddb004a8fc8508 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi,

A quick comment, I'm conc= erned by the "Stateful-IPv6-Address-Pool" attribute, why can'= t we re-use the Frame-* one?


Cheers,
Jacni

2011/7/26 Leaf yeh <leaf.y.yeh@huawei.com>

I've sent a question of clarification to the mai= ling list agaisnt draft-ietf-radext-ipv6-access-05. Pls. refer to https://ops.ietf.org/lists/radiusext/2010/msg00959.html.

 

Sorry for my poor expression in the Radext session. = I'd like to clarify my words in the meeting notes here. 

 

 

> 3. RADIUS Attributes for IPv6 Access Networks, = Wojcieh Dec

> http://tools.ietf.org/html/draft-ie= tf-radext-ipv6-access

> Presented by Mauricio Sanchez.

> Slidedeck: http://www.ietf.org/procee= dings/81/slides/radext-5.ppt

> Questions:

> Leaf  Yeh: In new version, new attribs. On= ly sends name of pool. DHCP already has a pool.

 

I meant the attribute of Framed-Pool (88, sect= ion 5.18 of RFC2869) here, which is used to send the pool name from AAA ser= ver to NAS server, to indicate the right pool employed or configured on NAS= .

 

> Doesn’t think this is necessary. Attribut= es in v4 can already do this. There is no need to a v6 pool name.

> Leaf agreed to send concern to list

> Roberta Maglione: It is just a pool name. Seman= tics are different.

> Bernard Adoba: One is a prefix pool and the oth= er is an address pool. May need to do both at once.

> Leaf: But it is only a string. So DHCP server can use name format is disambiguate.

 

I meant the NAS can interprect the pool name r= ecevived from AAA server for each kind of usage, such as IPv4 PPP= address pool, IPv6 SLAAC prefix pool, IPv6 DHCPv6 address pool or DHCPv6-P= D prefix pool. 

 

> Mauricio Sanchez: Sounds like valid reason for = these two attributes. Please bring comments to

list.

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB: owner-radiusext@ops.ietf.org [owner-radiusext@ops.ietf.= org] =B4=FA=B1=ED Sanchez, Mauricio (HP Networking) [mauricio.sanchez@hp.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C226=C8=D5 6:29
=B5=BD: 'radiusext@ops.ietf.org'
=D6=F7=CC=E2: RADEXT WG - IETF 81 preliminary meeting notes

These are the preliminary notes for IETF 81. Many th= anks to Mark Jones for taking notes this morning.  Comments/correction= s welcome.

 

-MS

 

----------------------------------------------------= ----------------------------------------------------------

RADEXT WG Minutes

IETF 81

Quebec, Canada

Monday, July 25th, 2011

Meeting started 9:02 AM and ended 11:27AM EDT. Appro= ximately 35 individuals in meeting

 

Chairs:

Jouni Korhonen <jouni.korhonen@nsn.com>

Mauricio Sanchez <mauricio.sanchez@hp.com>

 

1. Preliminaries

 

Agenda slides: http://www.ietf.org/procee= dings/81/slides/radext-3.pptx

 

Attendees: Bluesheets circulated.

Note Well

Note Takers

- Note volunteer Mark Jones

Jabber scribe

- Alan DeKok jabber scribe

Agenda bash

- IPv6, enhancements, security grouped item.  N= o changes to agenda made

 

****************************************************= ************

 

2. Radius Extensions for CGN Configurations, Dean Ch= eng

http://www.ietf.org/id/draft-= cheng-behave-cgn-cfg-radius-ext-00.txt

 

Presented by Dean Cheng.

Slidedeck: http://www.ietf.org/proceedings= /81/slides/radext-2.ppt

Hannes Tschofenig: Slide 3: Do you now assume DHCP b= etween end host and NAT?

Dean Cheng: Service Request is a general term but no= change.

Hannes Tschofenig: What happens when NAT runs out of= ports?

Dean Cheng: Number of ports are configured on server= . It is used to limit.

Hannes Tschofenig: What happens in failure case? i.e= . you reach restriction.

Dean Cheng: AAA only returns limits. If use wants mo= re ports, ICMP can be used to indicate

error.

Hannes Tschofenig: How do you ensure ICMP reaches en= d host?

Dean Cheng: OK. We can discuss offline.

Mauricio Sanchez:  Slide 5: Did you read RFC615= 8 RADIUS Guidelines

Dean Cheng: Yes. Need some help on these encoding wr= t RADIUS guidelines.

---

Questions:

Mauricio Sanchez: Where is this in BEHAVE WG?

Dean: Result of merge of two drafts to BEHAVE. Chair= suggested to present in RADEXT because

comments received were on RADIUS aspects

Dan Romanascu: Is this a charter item in BEHAVE.

Dean: No. Still be chartered. Chair said it is withi= n scope of BEHAVE.

Dan: What do you need from RADEXT? Advisor? WGLC?

Dean: BEHAVE suggest to present in RADEXT to get com= ments.

Dan: In draft, need to expand acronyms.

Hannes: (1) Need to define bigger picture. NAT behav= iour when it runs out of resources. Need to know why it fails. (2) AAA clie= nt does not live on NAT. DHCP and NAT are mashed together but it depends ho= w these are related.

Dean: AAA client is not changed. NAT44 must be co-lo= cated with BNG.

Hannes: Very special scenario.

Dean: If CNG (NAT44) not colo with BNG this falls ap= art.

Dan: Any other mechanisms to configure CNG other tha= n this draft?

Dean: No change. Only leverages existing deployment.=

 

****************************************************= ************

 

3. RADIUS Attributes for IPv6 Access Networks, Wojci= eh Dec

http://tools.ietf.org/html/draft-ietf-ra= dext-ipv6-access

Presented by Mauricio Sanchez.

Slidedeck: http://www.ietf.org/proceedings= /81/slides/radext-5.ppt

Questions:

Leaf  Yeh: In new version, new attribs. Only se= nds name of pool. DHCP already has a pool.

Doesn’t think this is necessary. Attributes in= v4 can already do this. There is no need to a v6 pool name.

Leaf agreed to send concern to list

Roberta Maglione: It is just a pool name. Semantics = are different.

Bernard Adoba: One is a prefix pool and the other is= an address pool. May need to do both at

once.

Leaf: But it is only a string. So DHCP server can us= e name format is disambiguate.

Mauricio Sanchez: Sounds like valid reason for these= two attributes. Please bring comments to

list.

****************************************************= ************

4. RADIUS accounting for traffic classes, Stefan Win= ter

http://tools.ietf.org/html/draft-w= inter-radext-fancyaccounting

Presented remotely by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings= /81/slides/radext-4.pdf

Other issues:

Mark Jones: We don’t need to include filter de= finition in accounting stream. Just include filter name (bucket label) in t= he accounting stream.

Stefan: Ok. Nice and simple. Works for me.

Dan Romanascu : Reuse definitions from RFC4898

Mauricio Sanchez: Concerned about number of drafts t= o progress. Does not want to oversubscribe WG. Poll: Who is interested in t= his work? Who will help out if WG item?

Show of hands in room:

Relevant and useful: No interest.

Stefan: Will let draft expire unless someone comes f= orward with interest.

Mauricio Sanchez: Thanks for spending time on this. =

 

****************************************************= ************

 

5. Dynamic Peer Discovery, Stefan Winter

http://tools.ietf.org/html/draft-i= etf-radext-dynamic-discovery

Presented by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings= /81/slides/radext-0.pdf

Stefan Winter: Asked about IESG comments on DIME equ= iv.

Mark Jones: IESG DISCUSS is on format of Application= Protocol Tag. Concern was that the current format indicates a structure.

Stefan Winter: Any IESG comments on Service Tag?

Mark Jones: No. Just protocol tags.

Comments or questions:

Dan Romanascu: Jouni, Can you comment on issues enco= untered in DIME?

Jouni Korhonen: Need to solve this in DIME. Mark gav= e summary of IESG concern.

Dan Romanascu: Do we need to stop work in this?

Jouni Korhonen: No.

Mark Jones: Confident that labels will be resolved. = Not doing anything unnatural with our original labels. No reason to stop wo= rk on this.

****************************************************= ************

 

6. RFC4282bis, Alan DeKok

Presented by Alan Dekok

Slidedeck: http://www.ietf.org/proceedings= /81/slides/radext-6.ppt

Dan Romanascu: So  4282bis strips out internati= onization, right? How is this separation being followed in other groups?

Alan Dekok: Working with PRECIS on that aspect.

****************************************************= ************

7. RADIUS Protocol Extensions, Alan DeKok (10 minute= s)

http://tools.ietf.org/html/draft-i= etf-radext-radius-extensions

Presented by  Alan Dekok.

Slidedeck:  http://www.ietf.org/proce= edings/81/slides/radext-8.ppt

Dan Romanascu: So this is a new type and is not back= wards compatible?

Alan: Backwards compatible for proxies that treat as= an opaque blob. IANA says these types (241-244) are not used but they are = used in the real world. Tough.

Sam Hartman: I have a draft in abfab requiring this = and would like to see this go fwd. Please don’t call it an OID though= . 

 Alan Dekok: Audit shows that this should handl= e allocation needs for the foreseeable future.

So we don’t need adhoc formats. Just help them= implement this new format.

****************************************************= ************

 

8. RADIUS over DTLS, Alan DeKok

http://tools.ietf.org/html/draft-ietf-radext-dt= ls

Presented by  Alan Dekok.

Slidedeck:  http://www.ietf.org/proce= edings/81/slides/radext-7.ppt

No questions.

****************************************************= ************

9. RADIUS over TLS, Stefan Winter (10 minutes)

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

Presented remotely by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings= /81/slides/radext-1.pdf

Mauricio: Agree that it is ready for WGLC. Any other= comments/questions?

Dan Romanascu: TCP port allocation. Intention is to = reuse port for radsec. So are there any  backwards compatability issue= s.

Stefan Winter: No. Old radsec is the format for RADI= US/TLS. OCS said once RFC is published they will change their implementatio= n to do it this way.

 

****************************************************= ************

(Margaret requested to present at RADEXT after agend= a bashing had occurred and WG chairs accepted presentation request) 

 

10. Multihop Federations (Trust Router).

Margaret Wasserman

Slidedeck: http://www.ietf.org/proceeding= s/81/slides/radext-9.pptx

Philip Hallam-Baker: Looks like UUCP. It was replace= d with DNS. Anything that looks like a  namespace should be using DNS.= Look at Bridge CAs. Used in PKI space. Lots of univ are in Bridge Cas. Can= also use Rulebook structure so never need a path of more than 2 so don’t need

BGP.

Margaret Wasserman: This is not about getting to eve= ry node. Only about getting between nodes in AAA infrastructure. They are a= ll IP nodes and already in BGP

Philip Hallam-Baker: You will find you use only 10% = of BGP and not the interesting part.

Hannes: Draft addresses some of the issues. Relation= ship are not purely mechanical. Don’t want to talk to everyone. Like = SAML, Liberty Alliance. Come up with circle of trust. They exist in AAA spa= ce. The Trust Router setup allows shortcuts.

Alan Dekok: Echo Hannes. Need to represent biz relat= ionships: Who to talk to depends on who is asking. Still have questions on = the details

Margaret Wasserman: This lets you put policy in inte= resting places (local trust router). E.g. not route should Russian nodes ev= en if the route is shorter.

Klaas Wierenga: This work is motivated by problems s= een in large scale SAML deployments. Esp to express complex polices around = who you want to trust. Share some of Philips concerns

Philip Hallam-Baker: Working on this problem for 15y= rs. Similar to other approaches that have already been implemented.

Sam Hartman: This is in the draft.

Philip: Why not in the presentation?

Margaret Wasserman: Not accepted as WG item in abfab= . Feedback required on abfab list.

Hannes: Also talking to VOIP folks who are reusing B= GP concepts.

Margaret Wasserman: we have not written these protoc= ols. If a better way, please explain.

Philip Hallam-Baker: Thinking as a CA. Someone has t= o manage it and money will flow around. The task of introduction is going t= o be paid. May want to pay premium to find a path with a higher degree of t= rust.

Margaret Wasserman: Allows for biz intelligence at m= any different layers.

Philip Hallam-Baker: Contracts will determine this. = Don’t need this hop by hop. Can take this offline.

Margaret Wasserman: Would be interested in those poi= nters to approaches already tried.

Klaas Wierenga: This goes beyond abfab. So AD pushed= us to present in other groups that see the same type of problem. Welcome a= broad discussion.

Margaret Wasserman: On agenda in abfab on Friday mor= ning.

 

 

****************************************************= ************

 

11. Email list server migration

Dan Romanascu: Please explain what it means for peop= le on the list.

Mauricio: Nothing. Should be transparent. Got a proc= ess for archive migration.

Jouni: Auto move of subscribers to new list. Emails = will be forwarded between lists. 

Secretary will move archives.

Dan: On behalf of doubters: Can you explain migratio= n of archives?

Mauricio: Others (Fred Baker) created the process fo= r painless migration of archives. So we

Dan: Do references on the tracker need to change?

Jouni: Direct links to archives need to be updated.<= /p>

Mauricio: Will need to look into that and make sure = it is remedied.

 

****************************************************= ************

12. Next Steps: WG Chairs & ADs

WG Goals/Milestones status

No questions


--20cf307cff5402ddb004a8fc8508-- -- to 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 Jul 26 10:57:53 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 0CA4611E810E for ; Tue, 26 Jul 2011 10:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.527 X-Spam-Level: X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[AWL=1.245, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1zU92tUCdM7 for ; Tue, 26 Jul 2011 10:57:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 325DE21F89CC for ; Tue, 26 Jul 2011 10:57:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qllqx-0002oh-OP for radiusext-data0@psg.com; Tue, 26 Jul 2011 17:55:35 +0000 Received: from grfedg702ba020.telecomitalia.it ([156.54.233.201]) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qllqt-0002oB-6t for radiusext@ops.ietf.org; Tue, 26 Jul 2011 17:55:31 +0000 Content-Type: multipart/mixed; boundary="_9c85e923-1310-465d-8460-a4865b7a6f28_" Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 26 Jul 2011 19:55:26 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 26 Jul 2011 19:55:26 +0200 From: Maglione Roberta To: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" CC: "fine_sz@huawei.com" , Qiujin , Wangshuxiang Date: Tue, 26 Jul 2011 19:55:26 +0200 Subject: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> References: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> In-Reply-To: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_9c85e923-1310-465d-8460-a4865b7a6f28_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56GRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56GRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Leaf, The different attributes proposed in this draft for the pools name have= all the same format (a string), but semantically they are different, as th= ey coved different scenarios. As you also summarized in your email below, Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time. If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic= to infer the semantic of that specific attribute from the assigned name. Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name. Thanks, Regards, Roberta ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= Behalf Of Leaf yeh Sent: luned=EC 25 luglio 2011 18.23 To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session Question for clarification: We already have the following Radius Attributes for the address/prefix pool= s: Framed-Pool (88, section 5.18 of RFC2869), Framed-IPv6-Pool (100, section 2.6 of RFC3162). http://www.iana.org/assignments/radius-types/radius-types.xml The foramt are the same as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools: Delegated-IPv6-Prefix-Pool, Stateful-IPv6-Address-Pool, the fomat of these 2 attributes are the same as the above one. Supposed the above attributes could be explained as follows: Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be= enough. In fact, the NAS take the role to interpret the meaning of the poo= k name, right? I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6? I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right? Best Regards, Leaf Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56GRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Leaf,

    The different attributes proposed in this draft = for the pools name have all the same format (a string), but semantically th= ey are different, as they coved different scenarios.

As you also summarized in your email below,

 

Framed-Pool was designed for the = IPv4 address pool; 

Framed-IPv6-Pool was designed for the IPv6 = SLAAC prefix pool;

Delegated-IPv6-Prefix-Pool is designed = for DHCPv6-PD prefix pool;

Stateful-IPv6-Address-Pool is designed = for DHCPv6 address pool;

 

So each attribute covers a different use-case/scenario and they can= appear in the same RADIUS packet at the same time.

If you want to use a single pool name use to cover all the 4 use ca= ses listed above, you would also need to define a standard format/syntax fo= r the pool name that allows the NAS to be able to disambiguate among the different scenarios and in or= der to do that the NAS would need to have an extra logic to infer the seman= tic of that specific attribute from the assigned name.

Instead if you have a specific attribute for each specific scenario= , the semantic is mapped to the attribute name, thus the NAS does not need = an extra logic to discovery the purpose of that pool and the pool name can be any string, no limitatio= n or special syntax is forced for the pool name.

 

 

Thanks,

Regards,

Roberta 

 

   

 

 

 

From: owne= r-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Leaf yeh
Sent: luned=EC 25 luglio 201= 1 18.23
To: draft-ietf-radext-ipv6-a= ccess@tools.ietf.org; radiusext@ops.ietf.org
Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of dra= ft-ietf-radext-ipv6-access after IETF81 radext session

 

Question for clarification:

 

We already have the following Radius Attrib= utes for the address/prefix pools:

 

Framed-Pool (88, section 5.18 of RFC2869),<= o:p>

Framed-IPv6-Pool (100, section 2.6 of RFC31= 62).

 

http://www.iana.org/assign= ments/radius-types/radius-types.xml

 

The foramt are the same as follows:

 

0       =             1 &= nbsp;           &nbs= p;     2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |  &= nbsp; Length     |     String... +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

 

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

 

the fomat of these 2 attributes are the same as the above one.

 

 

Supposed the above attributes could be expl= ained as follows:

 

Framed-Pool was designed for the = IPv4 address pool; 

Framed-IPv6-Pool was designed for the IPv6 = SLAAC prefix pool;

Delegated-IPv6-Prefix-Pool is designed = for DHCPv6-PD prefix pool;

Stateful-IPv6-Address-Pool is designed = for DHCPv6 address pool;

 

All above attributes are only used to provid= e the name of the address/prefix pools in a 'string'. I doubt the necessity to make so many 'name' or 'string' attri= butes for the different address/prefix pools to prevent the ambiguity.= I guess 1 attribute for the name of the address/prefix pools might be enough.= In fact, the NAS take the role to interpret the meaning of the pook name, = right?

 

I think Framed-Pool can be re-used for the = design purpose of Stateful-IPv6-Address-P= ool. Do we have any limitation on the usage of Framed-Pool for IPv6?

I think Framed-IPv6-Pool can be re-used for = the design purpose of Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6= prefix pool. I could even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 prefix/address= pool per the same logic. Am I right?

 

 

Best Regards,

Leaf

 

 

 


 

 


 

 

 

 

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56GRFMBX704BA02_-- --_9c85e923-1310-465d-8460-a4865b7a6f28_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_9c85e923-1310-465d-8460-a4865b7a6f28_-- -- to 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 Jul 26 11:05:46 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 4DE4211E811D for ; Tue, 26 Jul 2011 11:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.314 X-Spam-Level: X-Spam-Status: No, score=-3.314 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaBsYZ-zp4mo for ; Tue, 26 Jul 2011 11:05:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 41E6B21F887C for ; Tue, 26 Jul 2011 11:05:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qllyd-0003Vl-Of for radiusext-data0@psg.com; Tue, 26 Jul 2011 18:03:31 +0000 Received: from mail-vw0-f52.google.com ([209.85.212.52]) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QllyZ-0003VM-ED for radiusext@ops.ietf.org; Tue, 26 Jul 2011 18:03:27 +0000 Received: by vws16 with SMTP id 16so714720vws.11 for ; Tue, 26 Jul 2011 11:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N4JVJDiYEUi3UQUIIJQKIPHS1qM7K6zbX1w5p1ksrgs=; b=rmvJrsdKAgCU2qTlhcyedzieDOxEj9VkM2ESQNyM3YnkhNlqcbPku/QgjVAqhWqtMP /nuoWo75DQaeubWybR1fXMqeTGRYthpNBOK1KRRzWT9C2vFxa/5zeX5/b0Dy1cWx1pYa tT/v078DXtSMhi/OaTD3rdUZJO/srRQq92T3w= MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr2334820vdg.137.1311703405986; Tue, 26 Jul 2011 11:03:25 -0700 (PDT) Received: by 10.52.115.9 with HTTP; Tue, 26 Jul 2011 11:03:25 -0700 (PDT) In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> References: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> Date: Wed, 27 Jul 2011 02:03:25 +0800 Message-ID: Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session From: Jacni Qin To: Maglione Roberta Cc: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Content-Type: multipart/alternative; boundary=20cf3078118090851804a8fcbf46 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --20cf3078118090851804a8fcbf46 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roberta, I agree with you about the semantical logic, while "Stateful-IPv6-Address-Pool" is not necessary, IMHO. Cheers, Jacni On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta < roberta.maglione@telecomitalia.it> wrote: > ** > > Hello Leaf,**** > > The different attributes proposed in this draft for the pools name ha= ve > all the same format (a string), but semantically they are different, as t= hey > coved different scenarios.**** > > As you also summarized in your email below,**** > > ** ** > > Framed-Pool was designed for the IPv4 address pool; **** > > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;**** > > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;**** > > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;**** > > ** ** > > So each attribute covers a different use-case/scenario and they can appea= r > in the same RADIUS packet at the same time.**** > > If you want to use a single pool name use to cover all the 4 use cases > listed above, you would also need to define a standard format/syntax for = the > pool name that allows the NAS to be able to disambiguate among the differ= ent > scenarios and in order to do that the NAS would need to have an extra log= ic > to infer the semantic of that specific attribute from the assigned name. = * > *** > > Instead if you have a specific attribute for each specific scenario, the > semantic is mapped to the attribute name, thus the NAS does not need an > extra logic to discovery the purpose of that pool and the pool name can b= e > any string, no limitation or special syntax is forced for the pool name.*= * > ** > > ** ** > > ** ** > > Thanks,**** > > Regards,**** > > Roberta **** > > ** ** > > **** > > **** > > ** ** > > ** ** > ------------------------------ > > *From:* owner-**radiusext@ops.ietf.org** [mailto:owner-** > radiusext@ops.ietf.org**] *On Behalf Of *Leaf yeh > *Sent:* luned=EC 25 luglio 2011 18.23 > *To:* draft-ietf-radext-ipv6-access@tools.ietf.org; ** > radiusext@ops.ietf.org** > *Cc:* **fine_sz@huawei.com**; Qiujin; Wangshuxiang > *Subject:* Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 > radext session**** > > ** ** > > Question for clarification:**** > > **** > > We already have the following Radius Attributes for the address/prefix > pools:**** > > **** > > Framed-Pool (88, section 5.18 of RFC2869),**** > > Framed-IPv6-Pool (100, section 2.6 of RFC3162).**** > > **** > > http://www.iana.org/assignments/radius-types/radius-types.xml**** > > **** > > The foramt are the same as follows:**** > > **** > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | String... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for > address/prefix pools: **** > > **** > > Delegated-IPv6-Prefix-Pool, > Stateful-IPv6-Address-Pool,**** > > **** > > the fomat of these 2 attributes are the same as the above one.**** > > **** > > **** > > Supposed the above attributes could be explained as follows:**** > > **** > > Framed-Pool was designed for the IPv4 address pool; **** > > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;**** > > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;**** > > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;**** > > **** > > All above attributes are only used to provide the name of the > address/prefix pools in a 'string'. I doubt the necessity to make so many > 'name' or 'string' attributes for the different address/prefix pools > to prevent the ambiguity. I guess 1 attribute for the name of the > address/prefix pools might be enough. In fact, the NAS take the role to > interpret the meaning of the pook name, right?**** > > **** > > I think Framed-Pool can be re-used for the design purpose of Stateful-IPv= 6-Address-Pool. > Do we have any limitation on the usage of Framed-Pool for IPv6? **** > > I think Framed-IPv6-Pool can be re-used for the design purpose of > Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I coul= d > even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name = of > a IPv6 prefix/address pool per the same logic. Am I right?**** > > **** > > **** > > Best Regards,**** > > Leaf**** > > **** > > **** > > **** > > > **** > > **** > > > **** > > **** > > **** > > **** > > **** > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not = the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mai= l > se non =E8 necessario.* > > --20cf3078118090851804a8fcbf46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roberta,

I agree with you about= the semantical logic, while "Stateful-IPv6-Address-Pool" is not = necessary, IMHO.


Cheers,
Jacni

On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.maglione@telecomi= talia.it> wrote:

Hello Leaf,

=A0=A0=A0 The different attributes proposed in this = draft for the pools name have all the same format (a string), but semantica= lly they are different, as they coved different scenarios.

As you also summarized in your email below,

=A0

Framed-Pool=A0was designed for the= =A0IPv4 address pool;=A0

Framed-IPv6-Pool was designed for = the IPv6 SLAAC prefix pool;

Delegated-IPv6-Prefix-Pool=A0is desi= gned for DHCPv6-PD prefix pool;

Stateful-IPv6-Address-Pool=A0is desi= gned for DHCPv6 address pool;

=A0

So each attribute covers a different use-case/= scenario and they can appear in the same RADIUS packet at the same time.=

If you want to use a single pool name use to cover a= ll the 4 use cases listed above, you would also need to define a standard f= ormat/syntax for the pool name that allows the NAS to be able to disambiguate among the different scenarios and in or= der to do that the NAS would need to have an extra logic to infer the seman= tic of that specific attribute from the assigned name.

Instead if you have a specific attribute for each sp= ecific scenario, the semantic is mapped to the attribute name, thus the NAS= does not need an extra logic to discovery the purpose of that pool and the pool name can be any string, no limitatio= n or special syntax is forced for the pool name.

=A0

=A0

Thanks,

Regards,

Roberta=A0

=A0

=A0=A0=A0

=A0

=A0<= /span>

=A0<= /span>

From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.o= rg] On Behalf Of Leaf yeh
Sent: luned=EC 25 luglio 201= 1 18.23
To: draft-ietf-radext= -ipv6-access@tools.ietf.org; radiusex= t@ops.ietf.org
Cc: fine_sz@huawei.com; Qiuji= n; Wangshuxiang
Subject: Q on Ver.-05 of dra= ft-ietf-radext-ipv6-access after IETF81 radext session=

=A0

Question for clarification:=

=A0

We already have the following Radi= us Attributes for the address/prefix pools:

=A0

Framed-Pool (88, section 5.18 of R= FC2869),

Framed-IPv6-Pool (100, section 2.6= of RFC3162).

=A0

http://www.iana.o= rg/assignments/radius-types/radius-types.xml

=A0

The foramt are the same as follows= :

=A0

0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=A0=A0=A0=A0 Type=A0=A0=A0=A0=A0 |=A0=A0=A0 Length=A0=A0=A0=A0 |=A0=A0=A0= =A0 String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

=A0

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-P= ool,

=A0

the fomat of these 2 attributes are the same as the above one.

=A0

=A0

Supposed the above attributes coul= d be explained as follows:

=A0

Framed-Pool=A0was designed for the= =A0IPv4 address pool;=A0

Framed-IPv6-Pool was designed for = the IPv6 SLAAC prefix pool;

Delegated-IPv6-Prefix-Pool=A0is desi= gned for DHCPv6-PD prefix pool;

Stateful-IPv6-Address-Pool=A0is desi= gned for DHCPv6 address pool;

=A0

All above attributes are only used t= o provide the name=A0of the address/prefix pools in a 'string'. I doubt the necessity = to make so many 'name' or 'string' attributes for the diffe= rent address/prefix pools to=A0prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools=A0might be enough. In= fact, the NAS take the role to interpret the meaning of the pook name, rig= ht?

=A0

I think Framed-Pool can be re-used= for the design purpose of Stateful-IPv6-Address-P= ool. Do we have any limitation on the usage of Framed-Pool for IPv6? <= /font>

I think Framed-IPv6-Pool can be re-u= sed for the design purpose of Delegated-IPv6-Prefix-Pool to indicate a pool= of IPv6 prefix pool. I could even think=A0Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 prefix/address= pool per the same logic. Am I right?

=A0

=A0

Best Regards,

Leaf

=A0

=A0

=A0


=A0

=A0


=A0

=A0

=A0

=A0

=A0

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=A0is=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D=Rispetta l'ambient= e. Non stampare questa mail se non =E8 necessario.


--20cf3078118090851804a8fcbf46-- -- to 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 Jul 26 11:17:01 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 81B1A21F8A67 for ; Tue, 26 Jul 2011 11:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.402 X-Spam-Level: X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UixmDuTpUVY5 for ; Tue, 26 Jul 2011 11:16:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 822E15E8005 for ; Tue, 26 Jul 2011 11:16:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qlm8O-0003xL-4U for radiusext-data0@psg.com; Tue, 26 Jul 2011 18:13:36 +0000 Received: from grfedg702ba020.telecomitalia.it ([156.54.233.201]) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qlm8J-0003wu-KH for radiusext@ops.ietf.org; Tue, 26 Jul 2011 18:13:32 +0000 Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 26 Jul 2011 20:13:29 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Tue, 26 Jul 2011 20:13:29 +0200 From: Maglione Roberta To: 'Jacni Qin' CC: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Date: Tue, 26 Jul 2011 20:13:28 +0200 Subject: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Index: AcxLvlJ0Qx+z2Ps6RwO1/gA6tvoZHQAARHyA Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> References: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi Jacni, If you use the same attribute for both scenarios how does the NAS know i= f that pool is for SLAAC or for Stateful DHCPv6? Thanks, Regards, Roberta ________________________________________ From: Jacni Qin [mailto:jacniq@gmail.com] Sent: marted=EC 26 luglio 2011 20.03 To: Maglione Roberta Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session Hi Roberta, I agree with you about the semantical logic, while "Stateful-IPv6-Address-P= ool" is not necessary, IMHO. Cheers, Jacni On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta wrote: Hello Leaf, The different attributes proposed in this draft for the pools name have= all the same format (a string), but semantically they are different, as th= ey coved different scenarios. As you also summarized in your email below, Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time. If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic= to infer the semantic of that specific attribute from the assigned name. Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name. Thanks, Regards, Roberta ________________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= Behalf Of Leaf yeh Sent: luned=EC 25 luglio 2011 18.23 To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session Question for clarification: We already have the following Radius Attributes for the address/prefix pool= s: Framed-Pool (88, section 5.18 of RFC2869), Framed-IPv6-Pool (100, section 2.6 of RFC3162). http://www.iana.org/assignments/radius-types/radius-types.xml The foramt are the same as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=A0=A0=A0=A0 Type |=A0=A0=A0 Length |=A0=A0=A0=A0 String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools: Delegated-IPv6-Prefix-Pool, Stateful-IPv6-Address-Pool, the fomat of these 2 attributes are the same as the above one. Supposed the above attributes could be explained as follows: Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be= enough. In fact, the NAS take the role to interpret the meaning of the poo= k name, right? I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6? I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right? Best Regards, Leaf Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. -- to 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 Jul 26 11:24:50 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 9A91021F8686 for ; Tue, 26 Jul 2011 11:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.156 X-Spam-Level: X-Spam-Status: No, score=0.156 tagged_above=-999 required=5 tests=[AWL=-2.294, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gC8yyTAH0bgj for ; Tue, 26 Jul 2011 11:24:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id E224721F867E for ; Tue, 26 Jul 2011 11:24:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlmGg-0004JF-Br for radiusext-data0@psg.com; Tue, 26 Jul 2011 18:22:10 +0000 Received: from szxga03-in.huawei.com ([119.145.14.66]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlmGb-0004Hs-3o for radiusext@ops.ietf.org; Tue, 26 Jul 2011 18:22:05 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOY0044QDOPDS@szxga03-in.huawei.com> for radiusext@ops.ietf.org; Wed, 27 Jul 2011 02:22:01 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOY0025FDOPDR@szxga03-in.huawei.com> for radiusext@ops.ietf.org; Wed, 27 Jul 2011 02:22:01 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACP74586; Wed, 27 Jul 2011 02:22:01 +0800 (CST) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 27 Jul 2011 02:21:56 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Wed, 27 Jul 2011 02:21:58 +0800 Date: Tue, 26 Jul 2011 18:21:57 +0000 From: Leaf yeh Subject: =?gb2312?B?tPC4tDogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYt?= =?gb2312?Q?access_after_IETF81_radext_session?= In-reply-to: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> X-Originating-IP: [172.24.2.41] To: Maglione Roberta , 'Jacni Qin' Cc: "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Message-id: <5B27BA75-FA0F-4082-9C52-E2CBD2D63A98@mimectl> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UbXM7U5MVkvMlF4WkDxAaA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3s= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --Boundary_(ID_UbXM7U5MVkvMlF4WkDxAaA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 Um9iZXJ0YSAtIElmIHlvdSB1c2UgdGhlIHNhbWUgYXR0cmlidXRlIGZvciBib3RoIHNjZW5hcmlv cyBob3cgZG9lcyB0aGUgTkFTIGtub3cgaWYgdGhhdCBwb29sIGlzIGZvciBTTEFBQyBvciBmb3Ig U3RhdGVmdWwgREhDUHY2Pw0KDQpOQVMgYWxyZWFkeSBoYXMgdGhvc2UgcG9vbCBuYW1lcyBpbiBp dHMgY29uZmlndXJhdGlvbiwgcmlnaHQ/DQoNCk5BUyBkb2VzIGtub3cgd2hpY2ggb25lIGlzIGZv ciBTTEFBQyBwcmVmaXggcG9vbCwgd2hpY2ggb25lIGlzIGZvciBESENQdjYgYWRkcmVzcyBwb29s Lg0KDQoNCg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KTGVhZg0KDQoNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IE1hZ2xpb25lIFJvYmVydGEgW3JvYmVydGEu bWFnbGlvbmVAdGVsZWNvbWl0YWxpYS5pdF0NCreiy83KsbzkOiAyMDExxOo31MIyN8jVIDI6MTMN CrW9OiAnSmFjbmkgUWluJw0KQ2M6IExlYWYgeWVoOyBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFj Y2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZzsgZmluZV9zekBodWF3 ZWkuY29tOyBRaXVqaW47IFdhbmdzaHV4aWFuZw0K1vfM4jogUkU6IFEgb24gVmVyLi0wNSBvZiBk cmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2VzcyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb24N Cg0KSGkgSmFjbmksDQogICBJZiB5b3UgdXNlIHRoZSBzYW1lIGF0dHJpYnV0ZSBmb3IgYm90aCBz Y2VuYXJpb3MgaG93IGRvZXMgdGhlIE5BUyBrbm93IGlmIHRoYXQgcG9vbCBpcyBmb3IgU0xBQUMg b3IgZm9yIFN0YXRlZnVsIERIQ1B2Nj8NCg0KVGhhbmtzLA0KUmVnYXJkcywNClJvYmVydGENCg0K DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBK YWNuaSBRaW4gW21haWx0bzpqYWNuaXFAZ21haWwuY29tXQ0KU2VudDogbWFydGVkqKwgMjYgbHVn bGlvIDIwMTEgMjAuMDMNClRvOiBNYWdsaW9uZSBSb2JlcnRhDQpDYzogTGVhZiB5ZWg7IGRyYWZ0 LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmll dGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpTdWJqZWN0 OiBSZTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVy IElFVEY4MSByYWRleHQgc2Vzc2lvbg0KDQpIaSBSb2JlcnRhLA0KDQpJIGFncmVlIHdpdGggeW91 IGFib3V0IHRoZSBzZW1hbnRpY2FsIGxvZ2ljLCB3aGlsZSAiU3RhdGVmdWwtSVB2Ni1BZGRyZXNz LVBvb2wiIGlzIG5vdCBuZWNlc3NhcnksIElNSE8uDQoNCg0KQ2hlZXJzLA0KSmFjbmkNCk9uIFdl ZCwgSnVsIDI3LCAyMDExIGF0IDE6NTUgQU0sIE1hZ2xpb25lIFJvYmVydGEgPHJvYmVydGEubWFn bGlvbmVAdGVsZWNvbWl0YWxpYS5pdD4gd3JvdGU6DQpIZWxsbyBMZWFmLA0KICAgIFRoZSBkaWZm ZXJlbnQgYXR0cmlidXRlcyBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0IGZvciB0aGUgcG9vbHMgbmFt ZSBoYXZlIGFsbCB0aGUgc2FtZSBmb3JtYXQgKGEgc3RyaW5nKSwgYnV0IHNlbWFudGljYWxseSB0 aGV5IGFyZSBkaWZmZXJlbnQsIGFzIHRoZXkgY292ZWQgZGlmZmVyZW50IHNjZW5hcmlvcy4NCkFz IHlvdSBhbHNvIHN1bW1hcml6ZWQgaW4geW91ciBlbWFpbCBiZWxvdywNCg0KRnJhbWVkLVBvb2wg d2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NCBhZGRyZXNzIHBvb2w7DQpGcmFtZWQtSVB2Ni1Qb29s IHdhcyBkZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xBQUMgcHJlZml4IHBvb2w7DQpEZWxlZ2F0ZWQt SVB2Ni1QcmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2LVBEIHByZWZpeCBwb29sOw0K U3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgZGVzaWduZWQgZm9yIERIQ1B2NiBhZGRyZXNz IHBvb2w7DQoNClNvIGVhY2ggYXR0cmlidXRlIGNvdmVycyBhIGRpZmZlcmVudCB1c2UtY2FzZS9z Y2VuYXJpbyBhbmQgdGhleSBjYW4gYXBwZWFyIGluIHRoZSBzYW1lIFJBRElVUyBwYWNrZXQgYXQg dGhlIHNhbWUgdGltZS4NCklmIHlvdSB3YW50IHRvIHVzZSBhIHNpbmdsZSBwb29sIG5hbWUgdXNl IHRvIGNvdmVyIGFsbCB0aGUgNCB1c2UgY2FzZXMgbGlzdGVkIGFib3ZlLCB5b3Ugd291bGQgYWxz byBuZWVkIHRvIGRlZmluZSBhIHN0YW5kYXJkIGZvcm1hdC9zeW50YXggZm9yIHRoZSBwb29sIG5h bWUgdGhhdCBhbGxvd3MgdGhlIE5BUyB0byBiZSBhYmxlIHRvIGRpc2FtYmlndWF0ZSBhbW9uZyB0 aGUgZGlmZmVyZW50IHNjZW5hcmlvcyBhbmQgaW4gb3JkZXIgdG8gZG8gdGhhdCB0aGUgTkFTIHdv dWxkIG5lZWQgdG8gaGF2ZSBhbiBleHRyYSBsb2dpYyB0byBpbmZlciB0aGUgc2VtYW50aWMgb2Yg dGhhdCBzcGVjaWZpYyBhdHRyaWJ1dGUgZnJvbSB0aGUgYXNzaWduZWQgbmFtZS4NCkluc3RlYWQg aWYgeW91IGhhdmUgYSBzcGVjaWZpYyBhdHRyaWJ1dGUgZm9yIGVhY2ggc3BlY2lmaWMgc2NlbmFy aW8sIHRoZSBzZW1hbnRpYyBpcyBtYXBwZWQgdG8gdGhlIGF0dHJpYnV0ZSBuYW1lLCB0aHVzIHRo ZSBOQVMgZG9lcyBub3QgbmVlZCBhbiBleHRyYSBsb2dpYyB0byBkaXNjb3ZlcnkgdGhlIHB1cnBv c2Ugb2YgdGhhdCBwb29sIGFuZCB0aGUgcG9vbCBuYW1lIGNhbiBiZSBhbnkgc3RyaW5nLCBubyBs aW1pdGF0aW9uIG9yIHNwZWNpYWwgc3ludGF4IGlzIGZvcmNlZCBmb3IgdGhlIHBvb2wgbmFtZS4N Cg0KDQpUaGFua3MsDQpSZWdhcmRzLA0KUm9iZXJ0YQ0KDQoNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IG93bmVyLXJhZGl1c2V4dEBvcHMuaWV0 Zi5vcmcgW21haWx0bzpvd25lci1yYWRpdXNleHRAb3BzLmlldGYub3JnXSBPbiBCZWhhbGYgT2Yg TGVhZiB5ZWgNClNlbnQ6IGx1bmVkqKwgMjUgbHVnbGlvIDIwMTEgMTguMjMNClRvOiBkcmFmdC1p ZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRm Lm9yZw0KQ2M6IGZpbmVfc3pAaHVhd2VpLmNvbTsgUWl1amluOyBXYW5nc2h1eGlhbmcNClN1Ympl Y3Q6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2VzcyBhZnRlciBJ RVRGODEgcmFkZXh0IHNlc3Npb24NCg0KUXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb246DQoNCldl IGFscmVhZHkgaGF2ZSB0aGUgZm9sbG93aW5nIFJhZGl1cyBBdHRyaWJ1dGVzIGZvciB0aGUgYWRk cmVzcy9wcmVmaXggcG9vbHM6DQoNCkZyYW1lZC1Qb29sICg4OCwgc2VjdGlvbiA1LjE4IG9mIFJG QzI4NjkpLA0KRnJhbWVkLUlQdjYtUG9vbCAoMTAwLCBzZWN0aW9uIDIuNiBvZiBSRkMzMTYyKS4N Cg0KaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9yYWRpdXMtdHlwZXMvcmFkaXVzLXR5 cGVzLnhtbA0KDQpUaGUgZm9yYW10IGFyZSB0aGUgc2FtZSBhcyBmb2xsb3dzOg0KDQowICAgICAg ICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMg0KMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCnwgICAgIFR5cGUgICAgICB8ICAgIExlbmd0aCAgICAgfCAg ICAgU3RyaW5nLi4uDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQoNCmRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLTA1IGlzIHByb3Bvc2luZyAy IG5ldyBhdHRyaWJ1dGVzIGZvciBhZGRyZXNzL3ByZWZpeCBwb29sczoNCg0KRGVsZWdhdGVkLUlQ djYtUHJlZml4LVBvb2wsDQpTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCwNCg0KdGhlIGZvbWF0 IG9mIHRoZXNlIDIgYXR0cmlidXRlcyBhcmUgdGhlIHNhbWUgYXMgdGhlIGFib3ZlIG9uZS4NCg0K DQpTdXBwb3NlZCB0aGUgYWJvdmUgYXR0cmlidXRlcyBjb3VsZCBiZSBleHBsYWluZWQgYXMgZm9s bG93czoNCg0KRnJhbWVkLVBvb2wgd2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NCBhZGRyZXNzIHBv b2w7DQpGcmFtZWQtSVB2Ni1Qb29sIHdhcyBkZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xBQUMgcHJl Zml4IHBvb2w7DQpEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhD UHY2LVBEIHByZWZpeCBwb29sOw0KU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgZGVzaWdu ZWQgZm9yIERIQ1B2NiBhZGRyZXNzIHBvb2w7DQoNCkFsbCBhYm92ZSBhdHRyaWJ1dGVzIGFyZSBv bmx5IHVzZWQgdG8gcHJvdmlkZSB0aGUgbmFtZSBvZiB0aGUgYWRkcmVzcy9wcmVmaXggcG9vbHMg aW4gYSAnc3RyaW5nJy4gSSBkb3VidCB0aGUgbmVjZXNzaXR5IHRvIG1ha2Ugc28gbWFueSAnbmFt ZScgb3IgJ3N0cmluZycgYXR0cmlidXRlcyBmb3IgdGhlIGRpZmZlcmVudCBhZGRyZXNzL3ByZWZp eCBwb29scyB0byBwcmV2ZW50IHRoZSBhbWJpZ3VpdHkuIEkgZ3Vlc3MgMSBhdHRyaWJ1dGUgZm9y IHRoZSBuYW1lIG9mIHRoZSBhZGRyZXNzL3ByZWZpeCBwb29scyBtaWdodCBiZSBlbm91Z2guIElu IGZhY3QsIHRoZSBOQVMgdGFrZSB0aGUgcm9sZSB0byBpbnRlcnByZXQgdGhlIG1lYW5pbmcgb2Yg dGhlIHBvb2sgbmFtZSwgcmlnaHQ/DQoNCkkgdGhpbmsgRnJhbWVkLVBvb2wgY2FuIGJlIHJlLXVz ZWQgZm9yIHRoZSBkZXNpZ24gcHVycG9zZSBvZiBTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbC4g RG8gd2UgaGF2ZSBhbnkgbGltaXRhdGlvbiBvbiB0aGUgdXNhZ2Ugb2YgRnJhbWVkLVBvb2wgZm9y IElQdjY/DQpJIHRoaW5rIEZyYW1lZC1JUHY2LVBvb2wgY2FuIGJlIHJlLXVzZWQgZm9yIHRoZSBk ZXNpZ24gcHVycG9zZSBvZiBEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCB0byBpbmRpY2F0ZSBh IHBvb2wgb2YgSVB2NiBwcmVmaXggcG9vbC4gSSBjb3VsZCBldmVuIHRoaW5rIEZyYW1lZC1Qb29s IGNhbiByZXBsYWNlIEZyYW1lZC1JUHY2LVBvb2wgdG8gaW5kaWNhdGUgdGhlIG5hbWUgb2YgYSBJ UHY2IHByZWZpeC9hZGRyZXNzIHBvb2wgcGVyIHRoZSBzYW1lIGxvZ2ljLiBBbSBJIHJpZ2h0Pw0K DQoNCkJlc3QgUmVnYXJkcywNCkxlYWYNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClF1ZXN0byBt ZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50 ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNp IGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3Jt YXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1 dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRp IGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZl ZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KVGhpcyBlLW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlv biwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlz ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5 IHJldHVybiBlLW1haWwsIFRoYW5rcy4NClJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFy ZSBxdWVzdGEgbWFpbCBzZSBub24gqKggbmVjZXNzYXJpby4NCg0KDQpRdWVzdG8gbWVzc2FnZ2lv IGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBw ZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBh emlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBz b25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0 byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJu ZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxs YSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29w eWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVy biBlLW1haWwsIFRoYW5rcy4NCg0K --Boundary_(ID_UbXM7U5MVkvMlF4WkDxAaA) Content-id: Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Roberta - If you use the same attribute for both scenarios how does= the NAS know if that pool is for SLAAC or for Stateful DHCPv6?

NAS already has those pool names in its configuration, right?

NAS does know which one is for SLAAC prefix pool, which one is for = DHCPv6 address pool. 

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB: Maglione Roberta [roberta.maglione@telecomit= alia.it]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:13
=B5=BD: 'Jacni Qin'
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusex= t@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
=D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access afte= r IETF81 radext session

Hi Jacni,
   If you use the same attribute for both scenarios how does the = NAS know if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mail= to:jacniq@gmail.com]
Sent: marted=A8=AC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session

Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.maglione@tele= comitalia.it> wrote:
Hello Leaf,
    The different attributes proposed in this draft for the = pools name have all the same format (a string), but semantically they are d= ifferent, as they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Beha= lf Of Leaf yeh
Sent: luned=A8=AC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0            &n= bsp;      1      &nb= sp;            2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |  &= nbsp; Length     |     String... +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

--Boundary_(ID_UbXM7U5MVkvMlF4WkDxAaA)-- -- to 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 Jul 26 11:29: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 EA8AE21F888A for ; Tue, 26 Jul 2011 11:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.402 X-Spam-Level: ** X-Spam-Status: No, score=2.402 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+C0pWMor1mq for ; Tue, 26 Jul 2011 11:29:56 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9259621F873D for ; Tue, 26 Jul 2011 11:29:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlmLY-0004YF-TZ for radiusext-data0@psg.com; Tue, 26 Jul 2011 18:27:12 +0000 Received: from grfedg702ba020.telecomitalia.it ([156.54.233.201]) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlmLT-0004X9-Kk for radiusext@ops.ietf.org; Tue, 26 Jul 2011 18:27:08 +0000 Content-Type: multipart/mixed; boundary="_98bbf91d-e52e-4dd6-a3fb-b8f10260832e_" Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 26 Jul 2011 20:27:05 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 26 Jul 2011 20:27:05 +0200 From: Maglione Roberta To: 'Leaf yeh' , 'Jacni Qin' CC: "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Date: Tue, 26 Jul 2011 20:27:04 +0200 Subject: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIA== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D58@GRFMBX704BA020.griffon.local> References: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> <5B27BA75-FA0F-4082-9C52-E2CBD2D63A98@mimectl> In-Reply-To: <5B27BA75-FA0F-4082-9C52-E2CBD2D63A98@mimectl> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_98bbf91d-e52e-4dd6-a3fb-b8f10260832e_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D58GRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D58GRFMBX704BA02_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 UGxlYXNlIHNlZSBpbmxpbmUuDQoNCkJlc3QgcmVnYXJkcywNClJvYmVydGENCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IExlYWYgeWVoIFttYWlsdG86bGVhZi55Lnll aEBodWF3ZWkuY29tXQ0KU2VudDogbWFydGVkqKwgMjYgbHVnbGlvIDIwMTEgMjAuMjINClRvOiBN YWdsaW9uZSBSb2JlcnRhOyAnSmFjbmkgUWluJw0KQ2M6IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYt YWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3JnOyBmaW5lX3N6QGh1 YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpTdWJqZWN0OiC08Li0OiBRIG9uIFZlci4t MDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3MgYWZ0ZXIgSUVURjgxIHJhZGV4dCBz ZXNzaW9uDQoNCg0KUm9iZXJ0YSAtIElmIHlvdSB1c2UgdGhlIHNhbWUgYXR0cmlidXRlIGZvciBi b3RoIHNjZW5hcmlvcyBob3cgZG9lcyB0aGUgTkFTIGtub3cgaWYgdGhhdCBwb29sIGlzIGZvciBT TEFBQyBvciBmb3IgU3RhdGVmdWwgREhDUHY2Pw0KDQpOQVMgYWxyZWFkeSBoYXMgdGhvc2UgcG9v bCBuYW1lcyBpbiBpdHMgY29uZmlndXJhdGlvbiwgcmlnaHQ/DQoNCltSTV0geWVzIHBvb2xzIGFy ZSBhbHJlYWR5IGNvbmZpZ3VyZWQgaW4gdGhlIE5BUw0KDQoNCg0KTkFTIGRvZXMga25vdyB3aGlj aCBvbmUgaXMgZm9yIFNMQUFDIHByZWZpeCBwb29sLCB3aGljaCBvbmUgaXMgZm9yIERIQ1B2NiBh ZGRyZXNzIHBvb2wuDQoNCg0KDQpbUk1dIEFsbCB0aGUgY29uZmlndXJlZCBwb29scyBhcmUgdGhl IHNhbWUgZm9yIHRoZSBOQVMsIGluIHRoaXMgY2FzZSBhbiBleHRyYSBsb2dpYyB3b3VsZCBiZSBu ZWVkZWQgdG8gaW5zdHJ1Y3QgdGhlIE5BUyBhYm91dCB3aGljaCBwb29sIGlzIGZvciBTTEFBQyBh bmQgd2hpY2ggb25lIGlzIGZvciBESENQdjYNCg0KDQoNCg0KDQoNCg0KVGhhdKGvcyB3aHkgaW4g bXkgb3BpbmlvbiB0aGUgU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgcmVxdWlyZWQuDQoN Cg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpMZWFmDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCreivP7IyzogTWFnbGlvbmUgUm9iZXJ0YSBbcm9iZXJ0YS5tYWds aW9uZUB0ZWxlY29taXRhbGlhLml0XQ0Kt6LLzcqxvOQ6IDIwMTHE6jfUwjI3yNUgMjoxMw0Ktb06 ICdKYWNuaSBRaW4nDQpDYzogTGVhZiB5ZWg7IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNz QHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5j b207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQrW98ziOiBSRTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0 LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KSGkg SmFjbmksDQogICBJZiB5b3UgdXNlIHRoZSBzYW1lIGF0dHJpYnV0ZSBmb3IgYm90aCBzY2VuYXJp b3MgaG93IGRvZXMgdGhlIE5BUyBrbm93IGlmIHRoYXQgcG9vbCBpcyBmb3IgU0xBQUMgb3IgZm9y IFN0YXRlZnVsIERIQ1B2Nj8NCg0KVGhhbmtzLA0KUmVnYXJkcywNClJvYmVydGENCg0KDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBKYWNuaSBR aW4gW21haWx0bzpqYWNuaXFAZ21haWwuY29tXQ0KU2VudDogbWFydGVkqKwgMjYgbHVnbGlvIDIw MTEgMjAuMDMNClRvOiBNYWdsaW9uZSBSb2JlcnRhDQpDYzogTGVhZiB5ZWg7IGRyYWZ0LWlldGYt cmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3Jn OyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpTdWJqZWN0OiBSZTog USBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4 MSByYWRleHQgc2Vzc2lvbg0KDQpIaSBSb2JlcnRhLA0KDQpJIGFncmVlIHdpdGggeW91IGFib3V0 IHRoZSBzZW1hbnRpY2FsIGxvZ2ljLCB3aGlsZSAiU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wi IGlzIG5vdCBuZWNlc3NhcnksIElNSE8uDQoNCg0KQ2hlZXJzLA0KSmFjbmkNCk9uIFdlZCwgSnVs IDI3LCAyMDExIGF0IDE6NTUgQU0sIE1hZ2xpb25lIFJvYmVydGEgPHJvYmVydGEubWFnbGlvbmVA dGVsZWNvbWl0YWxpYS5pdD4gd3JvdGU6DQpIZWxsbyBMZWFmLA0KICAgIFRoZSBkaWZmZXJlbnQg YXR0cmlidXRlcyBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0IGZvciB0aGUgcG9vbHMgbmFtZSBoYXZl IGFsbCB0aGUgc2FtZSBmb3JtYXQgKGEgc3RyaW5nKSwgYnV0IHNlbWFudGljYWxseSB0aGV5IGFy ZSBkaWZmZXJlbnQsIGFzIHRoZXkgY292ZWQgZGlmZmVyZW50IHNjZW5hcmlvcy4NCkFzIHlvdSBh bHNvIHN1bW1hcml6ZWQgaW4geW91ciBlbWFpbCBiZWxvdywNCg0KRnJhbWVkLVBvb2wgd2FzIGRl c2lnbmVkIGZvciB0aGUgSVB2NCBhZGRyZXNzIHBvb2w7DQpGcmFtZWQtSVB2Ni1Qb29sIHdhcyBk ZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xBQUMgcHJlZml4IHBvb2w7DQpEZWxlZ2F0ZWQtSVB2Ni1Q cmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2LVBEIHByZWZpeCBwb29sOw0KU3RhdGVm dWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgZGVzaWduZWQgZm9yIERIQ1B2NiBhZGRyZXNzIHBvb2w7 DQoNClNvIGVhY2ggYXR0cmlidXRlIGNvdmVycyBhIGRpZmZlcmVudCB1c2UtY2FzZS9zY2VuYXJp byBhbmQgdGhleSBjYW4gYXBwZWFyIGluIHRoZSBzYW1lIFJBRElVUyBwYWNrZXQgYXQgdGhlIHNh bWUgdGltZS4NCklmIHlvdSB3YW50IHRvIHVzZSBhIHNpbmdsZSBwb29sIG5hbWUgdXNlIHRvIGNv dmVyIGFsbCB0aGUgNCB1c2UgY2FzZXMgbGlzdGVkIGFib3ZlLCB5b3Ugd291bGQgYWxzbyBuZWVk IHRvIGRlZmluZSBhIHN0YW5kYXJkIGZvcm1hdC9zeW50YXggZm9yIHRoZSBwb29sIG5hbWUgdGhh dCBhbGxvd3MgdGhlIE5BUyB0byBiZSBhYmxlIHRvIGRpc2FtYmlndWF0ZSBhbW9uZyB0aGUgZGlm ZmVyZW50IHNjZW5hcmlvcyBhbmQgaW4gb3JkZXIgdG8gZG8gdGhhdCB0aGUgTkFTIHdvdWxkIG5l ZWQgdG8gaGF2ZSBhbiBleHRyYSBsb2dpYyB0byBpbmZlciB0aGUgc2VtYW50aWMgb2YgdGhhdCBz cGVjaWZpYyBhdHRyaWJ1dGUgZnJvbSB0aGUgYXNzaWduZWQgbmFtZS4NCkluc3RlYWQgaWYgeW91 IGhhdmUgYSBzcGVjaWZpYyBhdHRyaWJ1dGUgZm9yIGVhY2ggc3BlY2lmaWMgc2NlbmFyaW8sIHRo ZSBzZW1hbnRpYyBpcyBtYXBwZWQgdG8gdGhlIGF0dHJpYnV0ZSBuYW1lLCB0aHVzIHRoZSBOQVMg ZG9lcyBub3QgbmVlZCBhbiBleHRyYSBsb2dpYyB0byBkaXNjb3ZlcnkgdGhlIHB1cnBvc2Ugb2Yg dGhhdCBwb29sIGFuZCB0aGUgcG9vbCBuYW1lIGNhbiBiZSBhbnkgc3RyaW5nLCBubyBsaW1pdGF0 aW9uIG9yIHNwZWNpYWwgc3ludGF4IGlzIGZvcmNlZCBmb3IgdGhlIHBvb2wgbmFtZS4NCg0KDQpU aGFua3MsDQpSZWdhcmRzLA0KUm9iZXJ0YQ0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkZyb206IG93bmVyLXJhZGl1c2V4dEBvcHMuaWV0Zi5vcmcg W21haWx0bzpvd25lci1yYWRpdXNleHRAb3BzLmlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGVhZiB5 ZWgNClNlbnQ6IGx1bmVkqKwgMjUgbHVnbGlvIDIwMTEgMTguMjMNClRvOiBkcmFmdC1pZXRmLXJh ZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZw0K Q2M6IGZpbmVfc3pAaHVhd2VpLmNvbTsgUWl1amluOyBXYW5nc2h1eGlhbmcNClN1YmplY3Q6IFEg b24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2VzcyBhZnRlciBJRVRGODEg cmFkZXh0IHNlc3Npb24NCg0KUXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb246DQoNCldlIGFscmVh ZHkgaGF2ZSB0aGUgZm9sbG93aW5nIFJhZGl1cyBBdHRyaWJ1dGVzIGZvciB0aGUgYWRkcmVzcy9w cmVmaXggcG9vbHM6DQoNCkZyYW1lZC1Qb29sICg4OCwgc2VjdGlvbiA1LjE4IG9mIFJGQzI4Njkp LA0KRnJhbWVkLUlQdjYtUG9vbCAoMTAwLCBzZWN0aW9uIDIuNiBvZiBSRkMzMTYyKS4NCg0KaHR0 cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9yYWRpdXMtdHlwZXMvcmFkaXVzLXR5cGVzLnht bA0KDQpUaGUgZm9yYW10IGFyZSB0aGUgc2FtZSBhcyBmb2xsb3dzOg0KDQowICAgICAgICAgICAg ICAgICAgIDEgICAgICAgICAgICAgICAgICAgMg0KMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCnwgICAgIFR5cGUgICAgICB8ICAgIExlbmd0aCAgICAgfCAgICAgU3Ry aW5nLi4uDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQoNCmRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLTA1IGlzIHByb3Bvc2luZyAyIG5ldyBh dHRyaWJ1dGVzIGZvciBhZGRyZXNzL3ByZWZpeCBwb29sczoNCg0KRGVsZWdhdGVkLUlQdjYtUHJl Zml4LVBvb2wsDQpTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCwNCg0KdGhlIGZvbWF0IG9mIHRo ZXNlIDIgYXR0cmlidXRlcyBhcmUgdGhlIHNhbWUgYXMgdGhlIGFib3ZlIG9uZS4NCg0KDQpTdXBw b3NlZCB0aGUgYWJvdmUgYXR0cmlidXRlcyBjb3VsZCBiZSBleHBsYWluZWQgYXMgZm9sbG93czoN Cg0KRnJhbWVkLVBvb2wgd2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NCBhZGRyZXNzIHBvb2w7DQpG cmFtZWQtSVB2Ni1Qb29sIHdhcyBkZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xBQUMgcHJlZml4IHBv b2w7DQpEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2LVBE IHByZWZpeCBwb29sOw0KU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgZGVzaWduZWQgZm9y IERIQ1B2NiBhZGRyZXNzIHBvb2w7DQoNCkFsbCBhYm92ZSBhdHRyaWJ1dGVzIGFyZSBvbmx5IHVz ZWQgdG8gcHJvdmlkZSB0aGUgbmFtZSBvZiB0aGUgYWRkcmVzcy9wcmVmaXggcG9vbHMgaW4gYSAn c3RyaW5nJy4gSSBkb3VidCB0aGUgbmVjZXNzaXR5IHRvIG1ha2Ugc28gbWFueSAnbmFtZScgb3Ig J3N0cmluZycgYXR0cmlidXRlcyBmb3IgdGhlIGRpZmZlcmVudCBhZGRyZXNzL3ByZWZpeCBwb29s cyB0byBwcmV2ZW50IHRoZSBhbWJpZ3VpdHkuIEkgZ3Vlc3MgMSBhdHRyaWJ1dGUgZm9yIHRoZSBu YW1lIG9mIHRoZSBhZGRyZXNzL3ByZWZpeCBwb29scyBtaWdodCBiZSBlbm91Z2guIEluIGZhY3Qs IHRoZSBOQVMgdGFrZSB0aGUgcm9sZSB0byBpbnRlcnByZXQgdGhlIG1lYW5pbmcgb2YgdGhlIHBv b2sgbmFtZSwgcmlnaHQ/DQoNCkkgdGhpbmsgRnJhbWVkLVBvb2wgY2FuIGJlIHJlLXVzZWQgZm9y IHRoZSBkZXNpZ24gcHVycG9zZSBvZiBTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbC4gRG8gd2Ug aGF2ZSBhbnkgbGltaXRhdGlvbiBvbiB0aGUgdXNhZ2Ugb2YgRnJhbWVkLVBvb2wgZm9yIElQdjY/ DQpJIHRoaW5rIEZyYW1lZC1JUHY2LVBvb2wgY2FuIGJlIHJlLXVzZWQgZm9yIHRoZSBkZXNpZ24g cHVycG9zZSBvZiBEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCB0byBpbmRpY2F0ZSBhIHBvb2wg b2YgSVB2NiBwcmVmaXggcG9vbC4gSSBjb3VsZCBldmVuIHRoaW5rIEZyYW1lZC1Qb29sIGNhbiBy ZXBsYWNlIEZyYW1lZC1JUHY2LVBvb2wgdG8gaW5kaWNhdGUgdGhlIG5hbWUgb2YgYSBJUHY2IHBy ZWZpeC9hZGRyZXNzIHBvb2wgcGVyIHRoZSBzYW1lIGxvZ2ljLiBBbSBJIHJpZ2h0Pw0KDQoNCkJl c3QgUmVnYXJkcywNCkxlYWYNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClF1ZXN0byBtZXNzYWdn aW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxl IHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJh IGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25p IHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVl c3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRh cm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBh bGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29w eWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVy biBlLW1haWwsIFRoYW5rcy4NClJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVz dGEgbWFpbCBzZSBub24gqKggbmVjZXNzYXJpby4NCg0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBz dW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25l IGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUg ZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJp Z29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1 bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1l ZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEg ZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBp cyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50 ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywg cHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1h aWwsIFRoYW5rcy4NClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRp cml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lv bmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3Nj ZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBR dWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRl IGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFs IG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0K DQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3Nl ZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55 Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBh bmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQpbY2lkOjAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAxQFRJLkRpc2NsYWltZXJdUmlzcGV0dGEgbCdh bWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiCoqCBuZWNlc3NhcmlvLg0K DQo= --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D58GRFMBX704BA02_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Please see inline.

 

Best regards,=

Roberta

 

From: Leaf= yeh [mailto:leaf.y.yeh@huawei.com]
Sent: marted=A8=AC 26 luglio= 2011 20.22
To: Maglione Roberta; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-a= ccess@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

 

Roberta - If you use the same attribut= e for both scenarios how does the NAS know if that pool is for SLAAC or for= Stateful DHCPv6?

NAS already has those pool names in its configuration, right?=

[RM] yes pools are already configured in the NAS

 

NAS does know which one is for SLAAC p= refix pool, which one is for DHCPv6 address pool. 

 

[RM] All the configured pools are the same for the NAS, i= n this case an extra logic would be needed to instruct the NAS about which = pool is for SLAAC and which one is for DHCPv6

 

 

 

That=A1=AFs why in my opinion the Stateful-IPv6-Address-P= ool is required.

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB: Maglione Roberta [roberta.magl= ione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1=BC=E4= : 2011=C4=EA7=D4=C227=C8=D5 2:13
=B5=BD: 'Jacni Qin'
Cc: Leaf yeh; draft-ietf-rad= ext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
=D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext sess= ion

Hi Jacni,
   If you use the same attribute for both scenarios how does the = NAS know if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mail= to:jacniq@gmail.com]
Sent: marted=A8=AC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_s= z@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session

Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Rober= ta <roberta.maglione@telecomitalia.it> wrote:
Hello Leaf,
    The different attributes proposed in this draft for the = pools name have all the same format (a string), but semantically they are d= ifferent, as they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: owner-radiusext@ops.ietf.org [mai= lto:owner-radiusext@ops.ietf.org] On Behalf Of Leaf yeh
Sent: luned=A8=AC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org
Cc: fine_sz@huawei.com; Qiujin= ; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0            &n= bsp;      1      &nb= sp;            2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |  &= nbsp; Length     |     String... +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =A8=A8 necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D58GRFMBX704BA02_-- --_98bbf91d-e52e-4dd6-a3fb-b8f10260832e_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_98bbf91d-e52e-4dd6-a3fb-b8f10260832e_-- -- to 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 Jul 26 11:36:01 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 0152F21F8B7A for ; Tue, 26 Jul 2011 11:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFVv000C+vv9 for ; Tue, 26 Jul 2011 11:35:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 17E7821F8AA8 for ; Tue, 26 Jul 2011 11:35:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlmR1-0004nQ-2L for radiusext-data0@psg.com; Tue, 26 Jul 2011 18:32:51 +0000 Received: from mail-vw0-f52.google.com ([209.85.212.52]) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlmQw-0004nD-Ht for radiusext@ops.ietf.org; Tue, 26 Jul 2011 18:32:46 +0000 Received: by vws16 with SMTP id 16so750272vws.11 for ; Tue, 26 Jul 2011 11:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EiwGmNxSsKPfDhAJCf36Nk7oWh60VVCGxKpjTECkk5Q=; b=rhZU8KfrExtqfWAxI4EcGOxpMC5tgthmB5STS35jUn3IdVUrWIi7le5ktaIQEOP37l cESG0AwYhKb9iaRQ3LG9MfGtntVQcSZOiNuV53/MCnNr+lHf/lVuX/R6qUT0gGyWkneb zk40mG9DVe8QI2Flk5lgGYam070YHEohl6vlM= MIME-Version: 1.0 Received: by 10.52.173.45 with SMTP id bh13mr6007582vdc.3.1311705164705; Tue, 26 Jul 2011 11:32:44 -0700 (PDT) Received: by 10.52.115.9 with HTTP; Tue, 26 Jul 2011 11:32:44 -0700 (PDT) In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> References: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> Date: Wed, 27 Jul 2011 02:32:44 +0800 Message-ID: Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session From: Jacni Qin To: Maglione Roberta Cc: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Content-Type: multipart/alternative; boundary=bcaec51b19f564718e04a8fd2855 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --bcaec51b19f564718e04a8fd2855 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi, That's what the "String" is for? :-) Cheers, Jacni On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta < roberta.maglione@telecomitalia.it> wrote: > Hi Jacni, > If you use the same attribute for both scenarios how does the NAS know = if > that pool is for SLAAC or for Stateful DHCPv6? > > Thanks, > Regards, > Roberta > > > > > > ________________________________________ > From: Jacni Qin [mailto:jacniq@gmail.com] > Sent: marted=EC 26 luglio 2011 20.03 > To: Maglione Roberta > Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; > radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang > Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 > radext session > > Hi Roberta, > > I agree with you about the semantical logic, while > "Stateful-IPv6-Address-Pool" is not necessary, IMHO. > > > Cheers, > Jacni > On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta < > roberta.maglione@telecomitalia.it> wrote: > Hello Leaf, > The different attributes proposed in this draft for the pools name hav= e > all the same format (a string), but semantically they are different, as t= hey > coved different scenarios. > As you also summarized in your email below, > > Framed-Pool was designed for the IPv4 address pool; > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; > > So each attribute covers a different use-case/scenario and they can appea= r > in the same RADIUS packet at the same time. > If you want to use a single pool name use to cover all the 4 use cases > listed above, you would also need to define a standard format/syntax for = the > pool name that allows the NAS to be able to disambiguate among the differ= ent > scenarios and in order to do that the NAS would need to have an extra log= ic > to infer the semantic of that specific attribute from the assigned name. > Instead if you have a specific attribute for each specific scenario, the > semantic is mapped to the attribute name, thus the NAS does not need an > extra logic to discovery the purpose of that pool and the pool name can b= e > any string, no limitation or special syntax is forced for the pool name. > > > Thanks, > Regards, > Roberta > > > > > > ________________________________________ > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Leaf yeh > Sent: luned=EC 25 luglio 2011 18.23 > To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org > Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang > Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radex= t > session > > Question for clarification: > > We already have the following Radius Attributes for the address/prefix > pools: > > Framed-Pool (88, section 5.18 of RFC2869), > Framed-IPv6-Pool (100, section 2.6 of RFC3162). > > http://www.iana.org/assignments/radius-types/radius-types.xml > > The foramt are the same as follows: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | String... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for > address/prefix pools: > > Delegated-IPv6-Prefix-Pool, > Stateful-IPv6-Address-Pool, > > the fomat of these 2 attributes are the same as the above one. > > > Supposed the above attributes could be explained as follows: > > Framed-Pool was designed for the IPv4 address pool; > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; > > All above attributes are only used to provide the name of the > address/prefix pools in a 'string'. I doubt the necessity to make so many > 'name' or 'string' attributes for the different address/prefix pools to > prevent the ambiguity. I guess 1 attribute for the name of the > address/prefix pools might be enough. In fact, the NAS take the role to > interpret the meaning of the pook name, right? > > I think Framed-Pool can be re-used for the design purpose of > Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of > Framed-Pool for IPv6? > I think Framed-IPv6-Pool can be re-used for the design purpose of > Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I coul= d > even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name = of > a IPv6 prefix/address pool per the same logic. Am I right? > > > Best Regards, > Leaf > > > > > > > > > > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks. > Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks. > > --bcaec51b19f564718e04a8fd2855 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi,

That's what the "Stri= ng" is for? :-)


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta <roberta.= maglione@telecomitalia.it> wrote:
Hi Jacni,
=A0 If you use the same attribute for both scenarios how does the NAS know= if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mailto:jacniq@gmail.co= m]
Sent: marted=EC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session

Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.maglione@telecomitalia.it> w= rote:
Hello Leaf,
=A0 =A0The different attributes proposed in this draft for the pools name = have all the same format (a string), but semantically they are different, a= s they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic= to infer the semantic of that specific attribute from the assigned name. Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: owner-radiusext@ops.i= etf.org [mailto:owner-r= adiusext@ops.ietf.org] On Behalf Of Leaf yeh
Sent: luned=EC 25 luglio 2011 18.23
To: draft-i= etf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org
Cc: fine_sz@huawei.com; Qiujin; W= angshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=A0=A0=A0=A0 Type =A0 =A0 =A0|=A0=A0=A0 Length =A0 =A0 |=A0=A0=A0=A0 Strin= g...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'n= ame' or 'string' attributes for the different address/prefix po= ols to prevent the ambiguity. I guess 1 attribute for the name of the addre= ss/prefix pools might be enough. In fact, the NAS take the role to interpre= t the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa = mail se non =E8 necessario.


Questo messaggio e i suoi allegati = sono indirizzati esclusivamente alle persone indicate. La diffusione, copia= o qualsiasi altra azione derivante dalla conoscenza di queste informazioni= sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per = errore siete cortesemente pregati di darne immediata comunicazione al mitte= nte e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.


--bcaec51b19f564718e04a8fd2855-- -- to 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 Jul 26 11:40:48 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 8F99121F8B9A for ; Tue, 26 Jul 2011 11:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.391 X-Spam-Level: X-Spam-Status: No, score=0.391 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0bxGvf6jzmQ for ; Tue, 26 Jul 2011 11:40:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 96D3D21F8B06 for ; Tue, 26 Jul 2011 11:40:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlmW6-00055g-LQ for radiusext-data0@psg.com; Tue, 26 Jul 2011 18:38:06 +0000 Received: from grfedg702ba020.telecomitalia.it ([156.54.233.201]) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlmW1-00055N-Ku for radiusext@ops.ietf.org; Tue, 26 Jul 2011 18:38:02 +0000 Content-Type: multipart/mixed; boundary="_9afb569b-83c5-40a7-943b-4bbd713a3360_" Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 26 Jul 2011 20:37:59 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Tue, 26 Jul 2011 20:37:59 +0200 From: Maglione Roberta To: 'Jacni Qin' CC: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Date: Tue, 26 Jul 2011 20:37:59 +0200 Subject: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Index: AcxLwmsj3QlAxoIFR1CPuEZgE9LR5gAAGxSA Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59@GRFMBX704BA020.griffon.local> References: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_9afb569b-83c5-40a7-943b-4bbd713a3360_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59GRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59GRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The string only contains a name, how does the NAS infer the semantic of tha= t pool name (meaning SLAAC or DHCPv6) from the name? Roberta ________________________________ From: Jacni Qin [mailto:jacniq@gmail.com] Sent: marted=EC 26 luglio 2011 20.33 To: Maglione Roberta Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session hi, That's what the "String" is for? :-) Cheers, Jacni On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta > wrote: Hi Jacni, If you use the same attribute for both scenarios how does the NAS know if= that pool is for SLAAC or for Stateful DHCPv6? Thanks, Regards, Roberta ________________________________________ From: Jacni Qin [mailto:jacniq@gmail.com] Sent: marted=EC 26 luglio 2011 20.03 To: Maglione Roberta Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wa= ngshuxiang Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session Hi Roberta, I agree with you about the semantical logic, while "Stateful-IPv6-Address-P= ool" is not necessary, IMHO. Cheers, Jacni On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta > wrote: Hello Leaf, The different attributes proposed in this draft for the pools name have = all the same format (a string), but semantically they are different, as the= y coved different scenarios. As you also summarized in your email below, Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time. If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic= to infer the semantic of that specific attribute from the assigned name. Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name. Thanks, Regards, Roberta ________________________________________ From: owner-radiusext@ops.ietf.org [ma= ilto:owner-radiusext@ops.ietf.org] On = Behalf Of Leaf yeh Sent: luned=EC 25 luglio 2011 18.23 To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session Question for clarification: We already have the following Radius Attributes for the address/prefix pool= s: Framed-Pool (88, section 5.18 of RFC2869), Framed-IPv6-Pool (100, section 2.6 of RFC3162). http://www.iana.org/assignments/radius-types/radius-types.xml The foramt are the same as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools: Delegated-IPv6-Prefix-Pool, Stateful-IPv6-Address-Pool, the fomat of these 2 attributes are the same as the above one. Supposed the above attributes could be explained as follows: Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be= enough. In fact, the NAS take the role to interpret the meaning of the poo= k name, right? I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6? I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right? Best Regards, Leaf Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59GRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The string only contains a name, how d= oes the NAS infer the semantic of that pool name (meaning SLAAC or DHCPv6) = from the name?

 

Roberta

 

From: Jacn= i Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 20= 11 20.33
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-rad= ext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of= draft-ietf-radext-ipv6-access after IETF81 radext session

 

hi,

That's what the "String" is for? :-)


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta <roberta.maglione@telecomitali= a.it> wrote:

Hi Jacni,
  If you use the same attribute for both scenarios how does the NAS kn= ow if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mailto:jacniq@gmail.co= m]
Sent: marted=EC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session


Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Rober= ta <roberta.maglione@telecomitalia.it> wrote:
Hello Leaf,
   The different attributes proposed in this draft for the pools = name have all the same format (a string), but semantically they are differe= nt, as they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: owner-radiusext@ops.i= etf.org [mailto:owner-r= adiusext@ops.ietf.org] On Behalf Of Leaf yeh
Sent: luned=EC 25 luglio 2011 18.23
To: draft-i= etf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org
Cc: fine_sz@huawei.com; Qiujin; W= angshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0                   1   &= nbsp;               2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |    Leng= th     |     String...
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. = Non stampare questa mail se non =E8 necessario.

Questo messaggio e i = suoi allegati sono indirizzati esclusivamente alle persone indicate. La dif= fusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualor= a abbiate ricevuto questo documento per errore siete cortesemente pregati d= i darne immediata comunicazione al mittente e di provvedere alla sua distru= zione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59GRFMBX704BA02_-- --_9afb569b-83c5-40a7-943b-4bbd713a3360_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_9afb569b-83c5-40a7-943b-4bbd713a3360_-- -- to 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 Jul 26 11:42: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 B654521F8BCF for ; Tue, 26 Jul 2011 11:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.341 X-Spam-Level: X-Spam-Status: No, score=-3.341 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je4RVRHZPaUX for ; Tue, 26 Jul 2011 11:42:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 8294B21F8B0A for ; Tue, 26 Jul 2011 11:42:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlmYB-0005DS-Hn for radiusext-data0@psg.com; Tue, 26 Jul 2011 18:40:15 +0000 Received: from mail-vx0-f180.google.com ([209.85.220.180]) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlmY6-0005Cw-Md for radiusext@ops.ietf.org; Tue, 26 Jul 2011 18:40:11 +0000 Received: by vxj12 with SMTP id 12so790986vxj.11 for ; Tue, 26 Jul 2011 11:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0tWPNTCPlzE7N5srdHniuxDbNu13IV2mUqTrVW/hWbc=; b=DwE/AvNL4Rut2AQUpc3+ZpGJY43CeNzQ826MVC7ECrAEX7XxuSFx8atRUzo/IJGbkL MQ9XgmLRH2QRFKdfHMfNoCbK428uxu+REE/DOGtwmzb9RYAYan1YwOr0L2uNyp53S1I9 I71DZ9i92a8ig3T5ANWmsm9q/mVkD/l9CR0hI= MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr2382695vdg.137.1311705609679; Tue, 26 Jul 2011 11:40:09 -0700 (PDT) Received: by 10.52.115.9 with HTTP; Tue, 26 Jul 2011 11:40:09 -0700 (PDT) In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59@GRFMBX704BA020.griffon.local> References: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59@GRFMBX704BA020.griffon.local> Date: Wed, 27 Jul 2011 02:40:09 +0800 Message-ID: Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session From: Jacni Qin To: Maglione Roberta Cc: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Content-Type: multipart/alternative; boundary=20cf30781180ea33fe04a8fd423b Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --20cf30781180ea33fe04a8fd423b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi, Here is an example from another perspective, What if I use DHCPv4? Then a corresponding attribute for IPv4 is needed? Cheers, Jacni On Wed, Jul 27, 2011 at 2:37 AM, Maglione Roberta < roberta.maglione@telecomitalia.it> wrote: > ** > > The string only contains a name, how does the NAS infer the semantic of > that pool name (meaning SLAAC or DHCPv6) from the name?**** > > ** ** > > Roberta**** > > ** ** > ------------------------------ > > *From:* Jacni Qin [mailto:jacniq@gmail.com] > *Sent:* marted=EC 26 luglio 2011 20.33 > > *To:* **Maglione Roberta** > *Cc:* Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; ** > radiusext@ops.ietf.org**; ** fine_sz@huawei.com**; Qiujin; Wangshuxiang > *Subject:* Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 > radext session > **** > > ** ** > > hi, > > That's what the "String" is for? :-) > > > Cheers, > Jacni**** > > On Wed, Jul 27, 2011 at 2:13 AM, **Maglione Roberta** < > roberta.maglione@telecomitalia.it> wrote:**** > > Hi Jacni, > If you use the same attribute for both scenarios how does the NAS know = if > that pool is for SLAAC or for Stateful DHCPv6? > > Thanks, > Regards, > Roberta > > > > > > ________________________________________ > From: Jacni Qin [mailto:jacniq@gmail.com] > Sent: marted=EC 26 luglio 2011 20.03 > To: **Maglione Roberta** > Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; > radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang > Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 > radext session**** > > > Hi Roberta, > > I agree with you about the semantical logic, while > "Stateful-IPv6-Address-Pool" is not necessary, IMHO. > > > Cheers, > Jacni > On Wed, Jul 27, 2011 at 1:55 AM, **Maglione Roberta** < > roberta.maglione@telecomitalia.it> wrote: > Hello Leaf, > The different attributes proposed in this draft for the pools name hav= e > all the same format (a string), but semantically they are different, as t= hey > coved different scenarios. > As you also summarized in your email below, > > Framed-Pool was designed for the IPv4 address pool; > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; > > So each attribute covers a different use-case/scenario and they can appea= r > in the same RADIUS packet at the same time. > If you want to use a single pool name use to cover all the 4 use cases > listed above, you would also need to define a standard format/syntax for = the > pool name that allows the NAS to be able to disambiguate among the differ= ent > scenarios and in order to do that the NAS would need to have an extra log= ic > to infer the semantic of that specific attribute from the assigned name. > Instead if you have a specific attribute for each specific scenario, the > semantic is mapped to the attribute name, thus the NAS does not need an > extra logic to discovery the purpose of that pool and the pool name can b= e > any string, no limitation or special syntax is forced for the pool name. > > > Thanks, > Regards, > Roberta > > > > > > ________________________________________ > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Leaf yeh > Sent: luned=EC 25 luglio 2011 18.23 > To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org > Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang > Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radex= t > session > > Question for clarification: > > We already have the following Radius Attributes for the address/prefix > pools: > > Framed-Pool (88, section 5.18 of RFC2869), > Framed-IPv6-Pool (100, section 2.6 of RFC3162). > > http://www.iana.org/assignments/radius-types/radius-types.xml > > The foramt are the same as follows: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | String... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for > address/prefix pools: > > Delegated-IPv6-Prefix-Pool, > Stateful-IPv6-Address-Pool, > > the fomat of these 2 attributes are the same as the above one. > > > Supposed the above attributes could be explained as follows: > > Framed-Pool was designed for the IPv4 address pool; > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; > > All above attributes are only used to provide the name of the > address/prefix pools in a 'string'. I doubt the necessity to make so many > 'name' or 'string' attributes for the different address/prefix pools to > prevent the ambiguity. I guess 1 attribute for the name of the > address/prefix pools might be enough. In fact, the NAS take the role to > interpret the meaning of the pook name, right? > > I think Framed-Pool can be re-used for the design purpose of > Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of > Framed-Pool for IPv6? > I think Framed-IPv6-Pool can be re-used for the design purpose of > Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I coul= d > even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name = of > a IPv6 prefix/address pool per the same logic. Am I right? > > > Best Regards, > Leaf > > > > > > > > > > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks.**** > > Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. > > **** > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks.**** > > ** ** > Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not = the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mai= l > se non =E8 necessario.* > > --20cf30781180ea33fe04a8fd423b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi,

Here is an example from anoth= er perspective,

What if I use DHCPv4? Then a corresponding attribute= for IPv4 is needed?


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:37 AM, Maglione Roberta <roberta.maglione@telecomi= talia.it> wrote:

The string only co= ntains a name, how does the NAS infer the semantic of that pool name (meani= ng SLAAC or DHCPv6) from the name?

=A0<= /span>

Roberta<= /u>

=A0<= /span>

From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 20= 11 20.33

=A0

hi,

That's what the "String" is for? :-)


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta <roberta.maglione@telecomitalia.it> wr= ote:

Hi Jacni,
=A0 If you use the same attribute for both scenarios how does the NAS know = if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session


Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.mag= lione@telecomitalia.it> wrote:
Hello Leaf,
=A0 =A0The different attributes proposed in this draft for the pools name h= ave all the same format (a string), but semantically they are different, as= they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: own= er-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of= Leaf yeh
Sent: luned=EC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org
Cc: fine_sz@huawei.= com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=A0=A0=A0=A0 Type =A0 =A0 =A0|=A0=A0=A0 Length =A0 =A0 |=A0=A0=A0=A0 Strin= g...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'n= ame' or 'string' attributes for the different address/prefix po= ols to prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

Rispetta l'ambien= te. Non stampare questa mail se non =E8 necessario.

Questo messaggio e i = suoi allegati sono indirizzati esclusivamente alle persone indicate. La dif= fusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualor= a abbiate ricevuto questo documento per errore siete cortesemente pregati d= i darne immediata comunicazione al mittente e di provvedere alla sua distru= zione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

=A0

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=A0is=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta l= 'ambiente. Non stampare questa mail se non =E8 necessario.


--20cf30781180ea33fe04a8fd423b-- -- to 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 Jul 26 11:45:51 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 741E721F8BDA for ; Tue, 26 Jul 2011 11:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.353 X-Spam-Level: X-Spam-Status: No, score=-3.353 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyT8YqfKjB9v for ; Tue, 26 Jul 2011 11:45:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2F23921F8BD8 for ; Tue, 26 Jul 2011 11:45:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlmbW-0005PV-F7 for radiusext-data0@psg.com; Tue, 26 Jul 2011 18:43:42 +0000 Received: from mail-vw0-f52.google.com ([209.85.212.52]) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlmbQ-0005PJ-Qj for radiusext@ops.ietf.org; Tue, 26 Jul 2011 18:43:37 +0000 Received: by vws16 with SMTP id 16so762914vws.11 for ; Tue, 26 Jul 2011 11:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AjsxMglhS3ngUurG6+ELKetAZd8B6ZnxGaeoVU0kgA8=; b=Sg4zoVTD4KGi5wlpXCdNzR+NS67oaJwXCCO16i2OTse9HvIe9vmUuM50qjOJ5Hnvzk ciPFGlQLfFbpJlj/10lf8Our7hwQt2UwRJlrxxlxBrI0uTjc18L156trKEHiMy8UbYxC q78X/gtaihVBtcd3J4kCFEn4rk2dNFKLxQGu8= MIME-Version: 1.0 Received: by 10.52.76.193 with SMTP id m1mr6493405vdw.204.1311705815761; Tue, 26 Jul 2011 11:43:35 -0700 (PDT) Received: by 10.52.115.9 with HTTP; Tue, 26 Jul 2011 11:43:35 -0700 (PDT) In-Reply-To: References: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59@GRFMBX704BA020.griffon.local> Date: Wed, 27 Jul 2011 02:43:35 +0800 Message-ID: Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session From: Jacni Qin To: Maglione Roberta Cc: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Content-Type: multipart/alternative; boundary=bcaec501603b32c28704a8fd4fd1 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --bcaec501603b32c28704a8fd4fd1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Re-, What I mean is the SLAAC and DHCPv6 can share the same pool. Cheers, Jacni On Wed, Jul 27, 2011 at 2:40 AM, Jacni Qin wrote: > hi, > > Here is an example from another perspective, > > What if I use DHCPv4? Then a corresponding attribute for IPv4 is needed? > > > Cheers, > Jacni > > On Wed, Jul 27, 2011 at 2:37 AM, Maglione Roberta < > roberta.maglione@telecomitalia.it> wrote: > >> ** >> >> The string only contains a name, how does the NAS infer the semantic of >> that pool name (meaning SLAAC or DHCPv6) from the name?**** >> >> ** ** >> >> Roberta**** >> >> ** ** >> ------------------------------ >> >> *From:* Jacni Qin [mailto:jacniq@gmail.com] >> *Sent:* marted=EC 26 luglio 2011 20.33 >> >> *To:* **Maglione Roberta** >> *Cc:* Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; ** >> radiusext@ops.ietf.org**; ** fine_sz@huawei.com**; Qiujin; Wangshuxiang >> *Subject:* Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF8= 1 >> radext session >> **** >> >> ** ** >> >> hi, >> >> That's what the "String" is for? :-) >> >> >> Cheers, >> Jacni**** >> >> On Wed, Jul 27, 2011 at 2:13 AM, **Maglione Roberta** < >> roberta.maglione@telecomitalia.it> wrote:**** >> >> Hi Jacni, >> If you use the same attribute for both scenarios how does the NAS know >> if that pool is for SLAAC or for Stateful DHCPv6? >> >> Thanks, >> Regards, >> Roberta >> >> >> >> >> >> ________________________________________ >> From: Jacni Qin [mailto:jacniq@gmail.com] >> Sent: marted=EC 26 luglio 2011 20.03 >> To: **Maglione Roberta** >> Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; >> radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang >> Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 >> radext session**** >> >> >> Hi Roberta, >> >> I agree with you about the semantical logic, while >> "Stateful-IPv6-Address-Pool" is not necessary, IMHO. >> >> >> Cheers, >> Jacni >> On Wed, Jul 27, 2011 at 1:55 AM, **Maglione Roberta** < >> roberta.maglione@telecomitalia.it> wrote: >> Hello Leaf, >> The different attributes proposed in this draft for the pools name ha= ve >> all the same format (a string), but semantically they are different, as = they >> coved different scenarios. >> As you also summarized in your email below, >> >> Framed-Pool was designed for the IPv4 address pool; >> Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; >> Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; >> Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; >> >> So each attribute covers a different use-case/scenario and they can appe= ar >> in the same RADIUS packet at the same time. >> If you want to use a single pool name use to cover all the 4 use cases >> listed above, you would also need to define a standard format/syntax for= the >> pool name that allows the NAS to be able to disambiguate among the diffe= rent >> scenarios and in order to do that the NAS would need to have an extra lo= gic >> to infer the semantic of that specific attribute from the assigned name. >> Instead if you have a specific attribute for each specific scenario, the >> semantic is mapped to the attribute name, thus the NAS does not need an >> extra logic to discovery the purpose of that pool and the pool name can = be >> any string, no limitation or special syntax is forced for the pool name. >> >> >> Thanks, >> Regards, >> Roberta >> >> >> >> >> >> ________________________________________ >> From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] >> On Behalf Of Leaf yeh >> Sent: luned=EC 25 luglio 2011 18.23 >> To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org >> Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang >> Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rade= xt >> session >> >> Question for clarification: >> >> We already have the following Radius Attributes for the address/prefix >> pools: >> >> Framed-Pool (88, section 5.18 of RFC2869), >> Framed-IPv6-Pool (100, section 2.6 of RFC3162). >> >> http://www.iana.org/assignments/radius-types/radius-types.xml >> >> The foramt are the same as follows: >> >> 0 1 2 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | String... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for >> address/prefix pools: >> >> Delegated-IPv6-Prefix-Pool, >> Stateful-IPv6-Address-Pool, >> >> the fomat of these 2 attributes are the same as the above one. >> >> >> Supposed the above attributes could be explained as follows: >> >> Framed-Pool was designed for the IPv4 address pool; >> Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; >> Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; >> Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; >> >> All above attributes are only used to provide the name of the >> address/prefix pools in a 'string'. I doubt the necessity to make so man= y >> 'name' or 'string' attributes for the different address/prefix pools to >> prevent the ambiguity. I guess 1 attribute for the name of the >> address/prefix pools might be enough. In fact, the NAS take the role to >> interpret the meaning of the pook name, right? >> >> I think Framed-Pool can be re-used for the design purpose of >> Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of >> Framed-Pool for IPv6? >> I think Framed-IPv6-Pool can be re-used for the design purpose of >> Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I cou= ld >> even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name= of >> a IPv6 prefix/address pool per the same logic. Am I right? >> >> >> Best Regards, >> Leaf >> >> >> >> >> >> >> >> >> >> >> >> >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >> persone indicate. La diffusione, copia o qualsiasi altra azione derivant= e >> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qual= ora >> abbiate ricevuto questo documento per errore siete cortesemente pregati = di >> darne immediata comunicazione al mittente e di provvedere alla sua >> distruzione, Grazie. >> This e-mail and any attachments is confidential and may contain privileg= ed >> information intended for the addressee(s) only. Dissemination, copying, >> printing or use by anybody else is unauthorised. If you are not the inte= nded >> recipient, please delete this message and any attachments and advise the >> sender by return e-mail, Thanks.**** >> >> Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. >> >> **** >> >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >> persone indicate. La diffusione, copia o qualsiasi altra azione derivant= e >> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qual= ora >> abbiate ricevuto questo documento per errore siete cortesemente pregati = di >> darne immediata comunicazione al mittente e di provvedere alla sua >> distruzione, Grazie. >> >> This e-mail and any attachments is confidential and may contain privileg= ed >> information intended for the addressee(s) only. Dissemination, copying, >> printing or use by anybody else is unauthorised. If you are not the inte= nded >> recipient, please delete this message and any attachments and advise the >> sender by return e-mail, Thanks.**** >> >> ** ** >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente >> alle persone indicate. La diffusione, copia o qualsiasi altra azione >> derivante dalla conoscenza di queste informazioni sono rigorosamente >> vietate. Qualora abbiate ricevuto questo documento per errore siete >> cortesemente pregati di darne immediata comunicazione al mittente e di >> provvedere alla sua distruzione, Grazie. >> >> *This e-mail and any attachments** is **confidential and may contain >> privileged information intended for the addressee(s) only. Dissemination= , >> copying, printing or use by anybody else is unauthorised. If you are not= the >> intended recipient, please delete this message and any attachments and >> advise the sender by return e-mail, Thanks.* >> *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa >> mail se non =E8 necessario.* >> >> > --bcaec501603b32c28704a8fd4fd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Re-,

What I mean is the SLAAC and = DHCPv6 can share the same pool.


Cheers,
Jacni

<= div class=3D"gmail_quote">On Wed, Jul 27, 2011 at 2:40 AM, Jacni Qin <jacniq@gmail.com>= ; wrote:
hi,
<= br>Here is an example from another perspective,

What if I use DHCPv4= ? Then a corresponding attribute for IPv4 is needed?


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:37 AM, Maglione Roberta <roberta= .maglione@telecomitalia.it> wrote:

The string only co= ntains a name, how does the NAS infer the semantic of that pool name (meani= ng SLAAC or DHCPv6) from the name?

=A0<= /span>

Roberta<= /u>

=A0<= /span>

From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 20= 11 20.33

=A0

hi,

That's what the "String" is for? :-)


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta <roberta.maglione@telecomitalia.it> wr= ote:

Hi Jacni,
=A0 If you use the same attribute for both scenarios how does the NAS know = if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session


Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.mag= lione@telecomitalia.it> wrote:
Hello Leaf,
=A0 =A0The different attributes proposed in this draft for the pools name h= ave all the same format (a string), but semantically they are different, as= they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: own= er-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of= Leaf yeh
Sent: luned=EC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org
Cc: fine_sz@huawei.= com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=A0=A0=A0=A0 Type =A0 =A0 =A0|=A0=A0=A0 Length =A0 =A0 |=A0=A0=A0=A0 Strin= g...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'n= ame' or 'string' attributes for the different address/prefix po= ols to prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

Rispetta l'ambien= te. Non stampare questa mail se non =E8 necessario.

Questo messaggio e i = suoi allegati sono indirizzati esclusivamente alle persone indicate. La dif= fusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualor= a abbiate ricevuto questo documento per errore siete cortesemente pregati d= i darne immediata comunicazione al mittente e di provvedere alla sua distru= zione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

=A0

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=A0is=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta l= 'ambiente. Non stampare questa mail se non =E8 necessario.



--bcaec501603b32c28704a8fd4fd1-- -- to 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 Jul 26 11:50: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 7BC6821F863A for ; Tue, 26 Jul 2011 11:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.372 X-Spam-Level: X-Spam-Status: No, score=0.372 tagged_above=-999 required=5 tests=[AWL=0.956, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llCWtPDyst5y for ; Tue, 26 Jul 2011 11:50:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 50DE321F8BEA for ; Tue, 26 Jul 2011 11:50:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qlmdb-0005WK-Uy for radiusext-data0@psg.com; Tue, 26 Jul 2011 18:45:51 +0000 Received: from grfedg702ba020.telecomitalia.it ([156.54.233.201]) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlmdO-0005Vi-M6 for radiusext@ops.ietf.org; Tue, 26 Jul 2011 18:45:39 +0000 Content-Type: multipart/mixed; boundary="_71de0d15-7b26-4695-84f6-4e2b8460d388_" Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 26 Jul 2011 20:45:36 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Tue, 26 Jul 2011 20:45:36 +0200 From: Maglione Roberta To: 'Jacni Qin' CC: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Date: Tue, 26 Jul 2011 20:45:36 +0200 Subject: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Index: AcxLw3QWJ03KoQwARf+9rW+G190UxQAAGjbA Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5A@GRFMBX704BA020.griffon.local> References: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59@GRFMBX704BA020.griffon.local> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_71de0d15-7b26-4695-84f6-4e2b8460d388_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5AGRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5AGRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry I'm not sure I have fully understood your example: In IPv4 the client only gets one IPv4 address extracted from a pool and we = already have and attribute for that pool: Frame-Pool In IPv6 there are different scenarios (WAN and LAN side IPv6 prefix) descri= bed in the draft. Roberta ________________________________ From: Jacni Qin [mailto:jacniq@gmail.com] Sent: marted=EC 26 luglio 2011 20.40 To: Maglione Roberta Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session hi, Here is an example from another perspective, What if I use DHCPv4? Then a corresponding attribute for IPv4 is needed? Cheers, Jacni On Wed, Jul 27, 2011 at 2:37 AM, Maglione Roberta > wrote: The string only contains a name, how does the NAS infer the semantic of tha= t pool name (meaning SLAAC or DHCPv6) from the name? Roberta ________________________________ From: Jacni Qin [mailto:jacniq@gmail.com] Sent: marted=EC 26 luglio 2011 20.33 To: Maglione Roberta Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wa= ngshuxiang Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session hi, That's what the "String" is for? :-) Cheers, Jacni On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta > wrote: Hi Jacni, If you use the same attribute for both scenarios how does the NAS know if= that pool is for SLAAC or for Stateful DHCPv6? Thanks, Regards, Roberta ________________________________________ From: Jacni Qin [mailto:jacniq@gmail.com] Sent: marted=EC 26 luglio 2011 20.03 To: Maglione Roberta Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wa= ngshuxiang Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session Hi Roberta, I agree with you about the semantical logic, while "Stateful-IPv6-Address-P= ool" is not necessary, IMHO. Cheers, Jacni On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta > wrote: Hello Leaf, The different attributes proposed in this draft for the pools name have = all the same format (a string), but semantically they are different, as the= y coved different scenarios. As you also summarized in your email below, Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time. If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic= to infer the semantic of that specific attribute from the assigned name. Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name. Thanks, Regards, Roberta ________________________________________ From: owner-radiusext@ops.ietf.org [ma= ilto:owner-radiusext@ops.ietf.org] On = Behalf Of Leaf yeh Sent: luned=EC 25 luglio 2011 18.23 To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session Question for clarification: We already have the following Radius Attributes for the address/prefix pool= s: Framed-Pool (88, section 5.18 of RFC2869), Framed-IPv6-Pool (100, section 2.6 of RFC3162). http://www.iana.org/assignments/radius-types/radius-types.xml The foramt are the same as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools: Delegated-IPv6-Prefix-Pool, Stateful-IPv6-Address-Pool, the fomat of these 2 attributes are the same as the above one. Supposed the above attributes could be explained as follows: Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be= enough. In fact, the NAS take the role to interpret the meaning of the poo= k name, right? I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6? I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right? Best Regards, Leaf Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [%20]Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5AGRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sorry I’m not sure I have fully = understood your example:

In IPv4 the client only gets one IPv4 = address extracted from a pool and we already have and attribute for that po= ol: Frame-Pool

 

In IPv6 there are different scenarios = (WAN and LAN side IPv6 prefix) described in the draft.

Roberta

 

From: Jacn= i Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 20= 11 20.40
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-rad= ext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of= draft-ietf-radext-ipv6-access after IETF81 radext session

 

hi,

Here is an example from another perspective,

What if I use DHCPv4? Then a corresponding attribute for IPv4 is needed?

Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:37 AM, Maglione Roberta <roberta.maglione@telecomitali= a.it> wrote:

The string only contains a name, how does the NAS infer the sem= antic of that pool name (meaning SLAAC or DHCPv6) from the name?

 

Roberta

 

From: Jacni Qin [mailto:ja= cniq@gmail.com]
Sent: marted=EC 26 luglio 20= 11 20.33


To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of= draft-ietf-radext-ipv6-access after IETF81 radext session

 

hi,

That's what the "String" is for? :-)


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta <roberta.mag= lione@telecomitalia.it> wrote:

Hi Jacni,
  If you use the same attribute for both scenarios how does the NAS kn= ow if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session


Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Rober= ta <roberta.maglione@telecomitalia.it> wrote:
Hello Leaf,
   The different attributes proposed in this draft for the pools = name have all the same format (a string), but semantically they are differe= nt, as they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: own= er-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of= Leaf yeh
Sent: luned=EC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org
Cc: fine_sz@huawei.= com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0                   1   &= nbsp;               2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |    Leng= th     |     String...
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

 

Que= sto messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi alt= ra azione derivante dalla conoscenza di queste informazioni sono rigorosame= nte vietate. Qualora abbiate ricevuto questo documento per errore siete cor= tesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispe= tta l'ambiente. Non stampare questa mail se non =E8 necessario.<= /b>

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5AGRFMBX704BA02_-- --_71de0d15-7b26-4695-84f6-4e2b8460d388_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_71de0d15-7b26-4695-84f6-4e2b8460d388_-- -- to 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 Jul 26 11:53:26 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 80E5211E8126 for ; Tue, 26 Jul 2011 11:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.296 X-Spam-Level: X-Spam-Status: No, score=-3.296 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlO+5WiLmMnB for ; Tue, 26 Jul 2011 11:53:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1A98711E8124 for ; Tue, 26 Jul 2011 11:53:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qlmi6-0005oS-4B for radiusext-data0@psg.com; Tue, 26 Jul 2011 18:50:30 +0000 Received: from mail-vx0-f180.google.com ([209.85.220.180]) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qlmh5-0005kW-59 for radiusext@ops.ietf.org; Tue, 26 Jul 2011 18:49:27 +0000 Received: by vxj12 with SMTP id 12so801311vxj.11 for ; Tue, 26 Jul 2011 11:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5r0UxJpyKFohcXRQkto1/UVR8Jcv0GkL4UOmyAcLTnc=; b=HRCeVlKgx65RygHWtAEko+6A/DBTYXf7VqO4FTm8dnGiu+QfGMx3bqHX6vzpHqRjgk E9DasIHtvSbz6in80nJaHL3pW25FD43ISA52xnLhwe3NEJeqk7A0ucKdLi0qabjIA2Ig 7+jZXJaOmMRd9j/i8nO55bCMRmepY8EagOs7Q= MIME-Version: 1.0 Received: by 10.52.90.226 with SMTP id bz2mr2855337vdb.271.1311706166187; Tue, 26 Jul 2011 11:49:26 -0700 (PDT) Received: by 10.52.115.9 with HTTP; Tue, 26 Jul 2011 11:49:26 -0700 (PDT) In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5A@GRFMBX704BA020.griffon.local> References: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5A@GRFMBX704BA020.griffon.local> Date: Wed, 27 Jul 2011 02:49:26 +0800 Message-ID: Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session From: Jacni Qin To: Maglione Roberta Cc: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Content-Type: multipart/alternative; boundary=20cf307cff5415d88004a8fd647f Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --20cf307cff5415d88004a8fd647f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hi, PD is one case, which needs a special attribute, I agree with that. While the others are all "framed-*", no matter which approach is used for address assignment, SLAAC or DHCPv6. Cheers, Jacni On Wed, Jul 27, 2011 at 2:45 AM, Maglione Roberta < roberta.maglione@telecomitalia.it> wrote: > ** > > Sorry I=92m not sure I have fully understood your example:**** > > In IPv4 the client only gets one IPv4 address extracted from a pool and w= e > already have and attribute for that pool: Frame-Pool**** > > ** ** > > In IPv6 there are different scenarios (WAN and LAN side IPv6 prefix) > described in the draft.**** > > Roberta **** > > ** ** > ------------------------------ > > *From:* Jacni Qin [mailto:jacniq@gmail.com] > *Sent:* marted=EC 26 luglio 2011 20.40 > > *To:* **Maglione Roberta** > *Cc:* Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; ** > radiusext@ops.ietf.org**; ** fine_sz@huawei.com**; Qiujin; Wangshuxiang > *Subject:* Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 > radext session > **** > > ** ** > > hi, > > Here is an example from another perspective, > > What if I use DHCPv4? Then a corresponding attribute for IPv4 is needed? > > > Cheers, > Jacni**** > > On Wed, Jul 27, 2011 at 2:37 AM, **Maglione Roberta** < > roberta.maglione@telecomitalia.it> wrote:**** > > The string only contains a name, how does the NAS infer the semantic of > that pool name (meaning SLAAC or DHCPv6) from the name?**** > > **** > > Roberta**** > > **** > ------------------------------ > > *From:* Jacni Qin [mailto:jacniq@gmail.com] > *Sent:* marted=EC 26 luglio 2011 20.33**** > > > *To:* **Maglione Roberta** > *Cc:* Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; > radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang > *Subject:* Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 > radext session**** > > **** > > hi, > > That's what the "String" is for? :-) > > > Cheers, > Jacni**** > > On Wed, Jul 27, 2011 at 2:13 AM, **Maglione Roberta** < > roberta.maglione@telecomitalia.it> wrote:**** > > Hi Jacni, > If you use the same attribute for both scenarios how does the NAS know = if > that pool is for SLAAC or for Stateful DHCPv6? > > Thanks, > Regards, > Roberta > > > > > > ________________________________________ > From: Jacni Qin [mailto:jacniq@gmail.com] > Sent: marted=EC 26 luglio 2011 20.03 > To: **Maglione Roberta** > Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; > radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang > Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 > radext session**** > > > Hi Roberta, > > I agree with you about the semantical logic, while > "Stateful-IPv6-Address-Pool" is not necessary, IMHO. > > > Cheers, > Jacni > On Wed, Jul 27, 2011 at 1:55 AM, **Maglione Roberta** < > roberta.maglione@telecomitalia.it> wrote: > Hello Leaf, > The different attributes proposed in this draft for the pools name hav= e > all the same format (a string), but semantically they are different, as t= hey > coved different scenarios. > As you also summarized in your email below, > > Framed-Pool was designed for the IPv4 address pool; > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; > > So each attribute covers a different use-case/scenario and they can appea= r > in the same RADIUS packet at the same time. > If you want to use a single pool name use to cover all the 4 use cases > listed above, you would also need to define a standard format/syntax for = the > pool name that allows the NAS to be able to disambiguate among the differ= ent > scenarios and in order to do that the NAS would need to have an extra log= ic > to infer the semantic of that specific attribute from the assigned name. > Instead if you have a specific attribute for each specific scenario, the > semantic is mapped to the attribute name, thus the NAS does not need an > extra logic to discovery the purpose of that pool and the pool name can b= e > any string, no limitation or special syntax is forced for the pool name. > > > Thanks, > Regards, > Roberta > > > > > > ________________________________________ > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Leaf yeh > Sent: luned=EC 25 luglio 2011 18.23 > To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org > Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang > Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radex= t > session > > Question for clarification: > > We already have the following Radius Attributes for the address/prefix > pools: > > Framed-Pool (88, section 5.18 of RFC2869), > Framed-IPv6-Pool (100, section 2.6 of RFC3162). > > http://www.iana.org/assignments/radius-types/radius-types.xml > > The foramt are the same as follows: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | String... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for > address/prefix pools: > > Delegated-IPv6-Prefix-Pool, > Stateful-IPv6-Address-Pool, > > the fomat of these 2 attributes are the same as the above one. > > > Supposed the above attributes could be explained as follows: > > Framed-Pool was designed for the IPv4 address pool; > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; > > All above attributes are only used to provide the name of the > address/prefix pools in a 'string'. I doubt the necessity to make so many > 'name' or 'string' attributes for the different address/prefix pools to > prevent the ambiguity. I guess 1 attribute for the name of the > address/prefix pools might be enough. In fact, the NAS take the role to > interpret the meaning of the pook name, right? > > I think Framed-Pool can be re-used for the design purpose of > Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of > Framed-Pool for IPv6? > I think Framed-IPv6-Pool can be re-used for the design purpose of > Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I coul= d > even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name = of > a IPv6 prefix/address pool per the same logic. Am I right? > > > Best Regards, > Leaf > > > > > > > > > > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks.**** > > Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.**** > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks.**** > > **** > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. **** > > *This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not = the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks.* **** > > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mai= l > se non =E8 necessario.* **** > > ** ** > Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not = the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mai= l > se non =E8 necessario.* > > --20cf307cff5415d88004a8fd647f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hi,

PD is one case, which needs a = special attribute, I agree with that.
While the others are all "fra= med-*", no matter which approach is used for address assignment, SLAAC= or DHCPv6.


Cheers,
Jacni


--20cf307cff5415d88004a8fd647f-- -- to 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 Jul 26 12:52:30 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 AAA8E11E8088 for ; Tue, 26 Jul 2011 12:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.538 X-Spam-Level: X-Spam-Status: No, score=0.538 tagged_above=-999 required=5 tests=[AWL=-1.912, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyFjBcARUjUG for ; Tue, 26 Jul 2011 12:52:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id E9BA721F876F for ; Tue, 26 Jul 2011 12:52:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qlne7-0008k4-J7 for radiusext-data0@psg.com; Tue, 26 Jul 2011 19:50:27 +0000 Received: from szxga01-in.huawei.com ([119.145.14.64]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qlne2-0008jl-1Q for radiusext@ops.ietf.org; Tue, 26 Jul 2011 19:50:22 +0000 Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOY002SAHRV7N@szxga05-in.huawei.com> for radiusext@ops.ietf.org; Wed, 27 Jul 2011 03:50:19 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOY00LTVHRT06@szxga05-in.huawei.com> for radiusext@ops.ietf.org; Wed, 27 Jul 2011 03:50:19 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACP76431; Wed, 27 Jul 2011 03:50:17 +0800 (CST) Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 27 Jul 2011 03:50:12 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Wed, 27 Jul 2011 03:50:15 +0800 Date: Tue, 26 Jul 2011 19:50:14 +0000 From: Leaf yeh Subject: =?gb2312?B?tPC4tDogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYt?= =?gb2312?Q?access_after_IETF81_radext_session?= In-reply-to: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D58@GRFMBX704BA020.griffon.local> X-Originating-IP: [172.24.2.41] To: Maglione Roberta , 'Jacni Qin' Cc: "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Message-id: <4E3D9B58-B42A-4F2A-9396-0FBFF0A3C2C5@mimectl> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_sUmBhRfrYWdIbDeaDG8qOA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsM= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> <5B27BA75-FA0F-4082-9C52-E2CBD2D63A98@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D58@GRFMBX704BA020.griffon.local> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --Boundary_(ID_sUmBhRfrYWdIbDeaDG8qOA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 W1JNXSBBbGwgdGhlIGNvbmZpZ3VyZWQgcG9vbHMgYXJlIHRoZSBzYW1lIGZvciB0aGUgTkFTLCBp biB0aGlzIGNhc2UgYW4gZXh0cmEgbG9naWMgd291bGQgYmUgbmVlZGVkIHRvIGluc3RydWN0IHRo ZSBOQVMgYWJvdXQgd2hpY2ggcG9vbCBpcyBmb3IgU0xBQUMgYW5kIHdoaWNoIG9uZSBpcyBmb3Ig REhDUHY2DQoNCg0KDQpUaGUgcG9vbHMgY29uZmlndXJlZCBvbiB0aGUgTkFTIGFyZSBub3QgbmVj ZXNzYXJ5IHRvIGJlIHRoZSBzYW1lLiBBQUEgc2VydmVyIGRvZXNuJ3QgcmVhbGx5IG5lZWQgdG8g aW5zdHJ1Y3QgdGhlIE5BUyB0aGUgc3BlY2lmaWVkIHR5cGUgb2YgcG9vbHMsIHdoaWNoIGlzIGFs cmVhZHkgY29uZmlndXJlZCBvbiB0aGUgTkFTLiBSaWdodD8NCg0KDQoNCg0KDQpCZXN0IFJlZ2Fy ZHMsDQoNCkxlYWYNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCreivP7IyzogTWFnbGlvbmUgUm9iZXJ0YSBbcm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRh bGlhLml0XQ0Kt6LLzcqxvOQ6IDIwMTHE6jfUwjI3yNUgMjoyNw0Ktb06IExlYWYgeWVoOyAnSmFj bmkgUWluJw0KQ2M6IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3Jn OyByYWRpdXNleHRAb3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2Fu Z3NodXhpYW5nDQrW98ziOiBSRTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlw djYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KDQpQbGVhc2Ugc2VlIGlubGlu ZS4NCg0KQmVzdCByZWdhcmRzLA0KUm9iZXJ0YQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbTogTGVhZiB5ZWggW21haWx0bzpsZWFmLnkueWVoQGh1YXdlaS5jb21dDQpT ZW50OiBtYXJ0ZWSorCAyNiBsdWdsaW8gMjAxMSAyMC4yMg0KVG86IE1hZ2xpb25lIFJvYmVydGE7 ICdKYWNuaSBRaW4nDQpDYzogZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3NAdG9vbHMuaWV0 Zi5vcmc7IHJhZGl1c2V4dEBvcHMuaWV0Zi5vcmc7IGZpbmVfc3pAaHVhd2VpLmNvbTsgUWl1amlu OyBXYW5nc2h1eGlhbmcNClN1YmplY3Q6ILTwuLQ6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRm LXJhZGV4dC1pcHY2LWFjY2VzcyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb24NCg0KDQpSb2Jl cnRhIC0gSWYgeW91IHVzZSB0aGUgc2FtZSBhdHRyaWJ1dGUgZm9yIGJvdGggc2NlbmFyaW9zIGhv dyBkb2VzIHRoZSBOQVMga25vdyBpZiB0aGF0IHBvb2wgaXMgZm9yIFNMQUFDIG9yIGZvciBTdGF0 ZWZ1bCBESENQdjY/DQoNCk5BUyBhbHJlYWR5IGhhcyB0aG9zZSBwb29sIG5hbWVzIGluIGl0cyBj b25maWd1cmF0aW9uLCByaWdodD8NCg0KW1JNXSB5ZXMgcG9vbHMgYXJlIGFscmVhZHkgY29uZmln dXJlZCBpbiB0aGUgTkFTDQoNCg0KDQpOQVMgZG9lcyBrbm93IHdoaWNoIG9uZSBpcyBmb3IgU0xB QUMgcHJlZml4IHBvb2wsIHdoaWNoIG9uZSBpcyBmb3IgREhDUHY2IGFkZHJlc3MgcG9vbC4NCg0K DQoNCltSTV0gQWxsIHRoZSBjb25maWd1cmVkIHBvb2xzIGFyZSB0aGUgc2FtZSBmb3IgdGhlIE5B UywgaW4gdGhpcyBjYXNlIGFuIGV4dHJhIGxvZ2ljIHdvdWxkIGJlIG5lZWRlZCB0byBpbnN0cnVj dCB0aGUgTkFTIGFib3V0IHdoaWNoIHBvb2wgaXMgZm9yIFNMQUFDIGFuZCB3aGljaCBvbmUgaXMg Zm9yIERIQ1B2Ng0KDQoNCg0KDQoNCg0KDQpUaGF0oa9zIHdoeSBpbiBteSBvcGluaW9uIHRoZSBT dGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCBpcyByZXF1aXJlZC4NCg0KDQoNCg0KDQpCZXN0IFJl Z2FyZHMsDQoNCkxlYWYNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kt6K8/sjLOiBNYWdsaW9uZSBSb2JlcnRhIFtyb2JlcnRhLm1hZ2xpb25lQHRlbGVjb21pdGFs aWEuaXRdDQq3osvNyrG85DogMjAxMcTqN9TCMjfI1SAyOjEzDQq1vTogJ0phY25pIFFpbicNCkNj OiBMZWFmIHllaDsgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3NAdG9vbHMuaWV0Zi5vcmc7 IHJhZGl1c2V4dEBvcHMuaWV0Zi5vcmc7IGZpbmVfc3pAaHVhd2VpLmNvbTsgUWl1amluOyBXYW5n c2h1eGlhbmcNCtb3zOI6IFJFOiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2 Ni1hY2Nlc3MgYWZ0ZXIgSUVURjgxIHJhZGV4dCBzZXNzaW9uDQpIaSBKYWNuaSwNCiAgIElmIHlv dSB1c2UgdGhlIHNhbWUgYXR0cmlidXRlIGZvciBib3RoIHNjZW5hcmlvcyBob3cgZG9lcyB0aGUg TkFTIGtub3cgaWYgdGhhdCBwb29sIGlzIGZvciBTTEFBQyBvciBmb3IgU3RhdGVmdWwgREhDUHY2 Pw0KDQpUaGFua3MsDQpSZWdhcmRzLA0KUm9iZXJ0YQ0KDQoNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEphY25pIFFpbiBbbWFpbHRvOmphY25p cUBnbWFpbC5jb21dDQpTZW50OiBtYXJ0ZWSorCAyNiBsdWdsaW8gMjAxMSAyMC4wMw0KVG86IE1h Z2xpb25lIFJvYmVydGENCkNjOiBMZWFmIHllaDsgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nl c3NAdG9vbHMuaWV0Zi5vcmc7IHJhZGl1c2V4dEBvcHMuaWV0Zi5vcmc7IGZpbmVfc3pAaHVhd2Vp LmNvbTsgUWl1amluOyBXYW5nc2h1eGlhbmcNClN1YmplY3Q6IFJlOiBRIG9uIFZlci4tMDUgb2Yg ZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3MgYWZ0ZXIgSUVURjgxIHJhZGV4dCBzZXNzaW9u DQoNCkhpIFJvYmVydGEsDQoNCkkgYWdyZWUgd2l0aCB5b3UgYWJvdXQgdGhlIHNlbWFudGljYWwg bG9naWMsIHdoaWxlICJTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCIgaXMgbm90IG5lY2Vzc2Fy eSwgSU1ITy4NCg0KDQpDaGVlcnMsDQpKYWNuaQ0KT24gV2VkLCBKdWwgMjcsIDIwMTEgYXQgMTo1 NSBBTSwgTWFnbGlvbmUgUm9iZXJ0YSA8cm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0 PiB3cm90ZToNCkhlbGxvIExlYWYsDQogICAgVGhlIGRpZmZlcmVudCBhdHRyaWJ1dGVzIHByb3Bv c2VkIGluIHRoaXMgZHJhZnQgZm9yIHRoZSBwb29scyBuYW1lIGhhdmUgYWxsIHRoZSBzYW1lIGZv cm1hdCAoYSBzdHJpbmcpLCBidXQgc2VtYW50aWNhbGx5IHRoZXkgYXJlIGRpZmZlcmVudCwgYXMg dGhleSBjb3ZlZCBkaWZmZXJlbnQgc2NlbmFyaW9zLg0KQXMgeW91IGFsc28gc3VtbWFyaXplZCBp biB5b3VyIGVtYWlsIGJlbG93LA0KDQpGcmFtZWQtUG9vbCB3YXMgZGVzaWduZWQgZm9yIHRoZSBJ UHY0IGFkZHJlc3MgcG9vbDsNCkZyYW1lZC1JUHY2LVBvb2wgd2FzIGRlc2lnbmVkIGZvciB0aGUg SVB2NiBTTEFBQyBwcmVmaXggcG9vbDsNCkRlbGVnYXRlZC1JUHY2LVByZWZpeC1Qb29sIGlzIGRl c2lnbmVkIGZvciBESENQdjYtUEQgcHJlZml4IHBvb2w7DQpTdGF0ZWZ1bC1JUHY2LUFkZHJlc3Mt UG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2IGFkZHJlc3MgcG9vbDsNCg0KU28gZWFjaCBhdHRy aWJ1dGUgY292ZXJzIGEgZGlmZmVyZW50IHVzZS1jYXNlL3NjZW5hcmlvIGFuZCB0aGV5IGNhbiBh cHBlYXIgaW4gdGhlIHNhbWUgUkFESVVTIHBhY2tldCBhdCB0aGUgc2FtZSB0aW1lLg0KSWYgeW91 IHdhbnQgdG8gdXNlIGEgc2luZ2xlIHBvb2wgbmFtZSB1c2UgdG8gY292ZXIgYWxsIHRoZSA0IHVz ZSBjYXNlcyBsaXN0ZWQgYWJvdmUsIHlvdSB3b3VsZCBhbHNvIG5lZWQgdG8gZGVmaW5lIGEgc3Rh bmRhcmQgZm9ybWF0L3N5bnRheCBmb3IgdGhlIHBvb2wgbmFtZSB0aGF0IGFsbG93cyB0aGUgTkFT IHRvIGJlIGFibGUgdG8gZGlzYW1iaWd1YXRlIGFtb25nIHRoZSBkaWZmZXJlbnQgc2NlbmFyaW9z IGFuZCBpbiBvcmRlciB0byBkbyB0aGF0IHRoZSBOQVMgd291bGQgbmVlZCB0byBoYXZlIGFuIGV4 dHJhIGxvZ2ljIHRvIGluZmVyIHRoZSBzZW1hbnRpYyBvZiB0aGF0IHNwZWNpZmljIGF0dHJpYnV0 ZSBmcm9tIHRoZSBhc3NpZ25lZCBuYW1lLg0KSW5zdGVhZCBpZiB5b3UgaGF2ZSBhIHNwZWNpZmlj IGF0dHJpYnV0ZSBmb3IgZWFjaCBzcGVjaWZpYyBzY2VuYXJpbywgdGhlIHNlbWFudGljIGlzIG1h cHBlZCB0byB0aGUgYXR0cmlidXRlIG5hbWUsIHRodXMgdGhlIE5BUyBkb2VzIG5vdCBuZWVkIGFu IGV4dHJhIGxvZ2ljIHRvIGRpc2NvdmVyeSB0aGUgcHVycG9zZSBvZiB0aGF0IHBvb2wgYW5kIHRo ZSBwb29sIG5hbWUgY2FuIGJlIGFueSBzdHJpbmcsIG5vIGxpbWl0YXRpb24gb3Igc3BlY2lhbCBz eW50YXggaXMgZm9yY2VkIGZvciB0aGUgcG9vbCBuYW1lLg0KDQoNClRoYW5rcywNClJlZ2FyZHMs DQpSb2JlcnRhDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogb3duZXItcmFkaXVzZXh0QG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLXJh ZGl1c2V4dEBvcHMuaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMZWFmIHllaA0KU2VudDogbHVuZWSo rCAyNSBsdWdsaW8gMjAxMSAxOC4yMw0KVG86IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNz QHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3JnDQpDYzogZmluZV9zekBodWF3 ZWkuY29tOyBRaXVqaW47IFdhbmdzaHV4aWFuZw0KU3ViamVjdDogUSBvbiBWZXIuLTA1IG9mIGRy YWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0K DQpRdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbjoNCg0KV2UgYWxyZWFkeSBoYXZlIHRoZSBmb2xs b3dpbmcgUmFkaXVzIEF0dHJpYnV0ZXMgZm9yIHRoZSBhZGRyZXNzL3ByZWZpeCBwb29sczoNCg0K RnJhbWVkLVBvb2wgKDg4LCBzZWN0aW9uIDUuMTggb2YgUkZDMjg2OSksDQpGcmFtZWQtSVB2Ni1Q b29sICgxMDAsIHNlY3Rpb24gMi42IG9mIFJGQzMxNjIpLg0KDQpodHRwOi8vd3d3LmlhbmEub3Jn L2Fzc2lnbm1lbnRzL3JhZGl1cy10eXBlcy9yYWRpdXMtdHlwZXMueG1sDQoNClRoZSBmb3JhbXQg YXJlIHRoZSBzYW1lIGFzIGZvbGxvd3M6DQoNCjAgICAgICAgICAgICAgICAgICAgMSAgICAgICAg ICAgICAgICAgICAyDQowIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMw0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K fCAgICAgVHlwZSAgICAgIHwgICAgTGVuZ3RoICAgICB8ICAgICBTdHJpbmcuLi4NCistKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KZHJhZnQtaWV0Zi1y YWRleHQtaXB2Ni1hY2Nlc3MtMDUgaXMgcHJvcG9zaW5nIDIgbmV3IGF0dHJpYnV0ZXMgZm9yIGFk ZHJlc3MvcHJlZml4IHBvb2xzOg0KDQpEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCwNClN0YXRl ZnVsLUlQdjYtQWRkcmVzcy1Qb29sLA0KDQp0aGUgZm9tYXQgb2YgdGhlc2UgMiBhdHRyaWJ1dGVz IGFyZSB0aGUgc2FtZSBhcyB0aGUgYWJvdmUgb25lLg0KDQoNClN1cHBvc2VkIHRoZSBhYm92ZSBh dHRyaWJ1dGVzIGNvdWxkIGJlIGV4cGxhaW5lZCBhcyBmb2xsb3dzOg0KDQpGcmFtZWQtUG9vbCB3 YXMgZGVzaWduZWQgZm9yIHRoZSBJUHY0IGFkZHJlc3MgcG9vbDsNCkZyYW1lZC1JUHY2LVBvb2wg d2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NiBTTEFBQyBwcmVmaXggcG9vbDsNCkRlbGVnYXRlZC1J UHY2LVByZWZpeC1Qb29sIGlzIGRlc2lnbmVkIGZvciBESENQdjYtUEQgcHJlZml4IHBvb2w7DQpT dGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2IGFkZHJlc3Mg cG9vbDsNCg0KQWxsIGFib3ZlIGF0dHJpYnV0ZXMgYXJlIG9ubHkgdXNlZCB0byBwcm92aWRlIHRo ZSBuYW1lIG9mIHRoZSBhZGRyZXNzL3ByZWZpeCBwb29scyBpbiBhICdzdHJpbmcnLiBJIGRvdWJ0 IHRoZSBuZWNlc3NpdHkgdG8gbWFrZSBzbyBtYW55ICduYW1lJyBvciAnc3RyaW5nJyBhdHRyaWJ1 dGVzIGZvciB0aGUgZGlmZmVyZW50IGFkZHJlc3MvcHJlZml4IHBvb2xzIHRvIHByZXZlbnQgdGhl IGFtYmlndWl0eS4gSSBndWVzcyAxIGF0dHJpYnV0ZSBmb3IgdGhlIG5hbWUgb2YgdGhlIGFkZHJl c3MvcHJlZml4IHBvb2xzIG1pZ2h0IGJlIGVub3VnaC4gSW4gZmFjdCwgdGhlIE5BUyB0YWtlIHRo ZSByb2xlIHRvIGludGVycHJldCB0aGUgbWVhbmluZyBvZiB0aGUgcG9vayBuYW1lLCByaWdodD8N Cg0KSSB0aGluayBGcmFtZWQtUG9vbCBjYW4gYmUgcmUtdXNlZCBmb3IgdGhlIGRlc2lnbiBwdXJw b3NlIG9mIFN0YXRlZnVsLUlQdjYtQWRkcmVzcy1Qb29sLiBEbyB3ZSBoYXZlIGFueSBsaW1pdGF0 aW9uIG9uIHRoZSB1c2FnZSBvZiBGcmFtZWQtUG9vbCBmb3IgSVB2Nj8NCkkgdGhpbmsgRnJhbWVk LUlQdjYtUG9vbCBjYW4gYmUgcmUtdXNlZCBmb3IgdGhlIGRlc2lnbiBwdXJwb3NlIG9mIERlbGVn YXRlZC1JUHY2LVByZWZpeC1Qb29sIHRvIGluZGljYXRlIGEgcG9vbCBvZiBJUHY2IHByZWZpeCBw b29sLiBJIGNvdWxkIGV2ZW4gdGhpbmsgRnJhbWVkLVBvb2wgY2FuIHJlcGxhY2UgRnJhbWVkLUlQ djYtUG9vbCB0byBpbmRpY2F0ZSB0aGUgbmFtZSBvZiBhIElQdjYgcHJlZml4L2FkZHJlc3MgcG9v bCBwZXIgdGhlIHNhbWUgbG9naWMuIEFtIEkgcmlnaHQ/DQoNCg0KQmVzdCBSZWdhcmRzLA0KTGVh Zg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxl Z2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0 ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50 ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1l bnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBl ciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNv bXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXpp b25lLCBHcmF6aWUuDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVu dGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3Ig dGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBv ciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBh dHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtz Lg0KUmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiCo qCBuZWNlc3NhcmlvLg0KDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29u byBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRp ZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEg Y29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0 YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3Jl IHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXpp b25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3Jh emllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBh bmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFk ZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2Ug YnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2ht ZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KUXVl c3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2 YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFs c2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBp bmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSBy aWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHBy ZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBw cm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQoNClRoaXMgZS1tYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3Nl bWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5h dXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNl bmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQoNCltyaXNwZXR0YSBsJ2FtYmllbnRlXVJp c3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gqKggbmVj ZXNzYXJpby4NCg0K --Boundary_(ID_sUmBhRfrYWdIbDeaDG8qOA) Content-id: <5FC01589697C6740880F2E0E4A176D87@huawei.com> Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

[RM] All the configured pools are t= he same for the NAS, in this case an extra logic would be needed to instruc= t the NAS about which pool is for SLAAC and which one is for DHCPv6

 

The pools configured on the NAS ar= e not necessary to be the same. AAA server doesn't reall= y need to instruct the NAS the specified type = of pools, which is already configured on the NAS. Right?

 

 

Best Regards,

Leaf

 

 

 

=B7=A2=BC=FE=C8=CB: Maglione Roberta [robe= rta.maglione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:27
=B5=BD: Leaf yeh; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf= .org; fine_sz@huawei.com; Qiujin; Wangshuxiang
=D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access afte= r IETF81 radext session

Please see inli= ne.

&= nbsp;

Best regards,

Roberta<= /font>

&= nbsp;

From:= Leaf yeh [mailto:leaf.y.yeh@huawei.com]
Sent: marted=A8=AC 26 lugli= o 2011 20.22
To: Maglione Roberta; 'Jacn= i Qin'
Cc: draft-ietf-radext-ipv6-= access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; = Wangshuxiang
Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

 

Roberta - If you use the s= ame attribute for both scenarios how does the NAS know if that pool is for = SLAAC or for Stateful DHCPv6?

NAS already has those pool names in its configuration, right?=

[RM] yes pools are already configur= ed in the NAS

 

NAS does know which one is= for SLAAC prefix pool, which one is for DHCPv6 address pool. <= /font>

 

[RM] All the configured pools are t= he same for the NAS, in this case an extra logic would be needed to instruc= t the NAS about which pool is for SLAAC and which one is for DHCPv6

 

 

 

That=A1=AFs why in my opinion the S= tateful-IPv6-Address-Pool is required.

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB<= font color=3D"black" size=3D"2" face=3D"Tahoma">:<= /b> Maglione Roberta [roberta.maglione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1= =BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:13
=B5=BD= := 'Jacni Qin'
Cc: Leaf yeh; draft-ietf-ra= dext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com= ; Qiujin; Wangshuxiang
=D6=F7=CC=E2<= /font>= : RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext sess= ion

Hi Jacni,
   If you use the same attribute for both scenarios how does the = NAS know if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mail= to:jacniq@gmail.com]
Sent: marted=A8=AC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session

Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.maglione@tele= comitalia.it> wrote:
Hello Leaf,
    The different attributes proposed in this draft for the = pools name have all the same format (a string), but semantically they are d= ifferent, as they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Beha= lf Of Leaf yeh
Sent: luned=A8=AC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0            &n= bsp;      1      &nb= sp;            2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |  &= nbsp; Length     |     String... +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni= sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per = errore siete cortesemente pregati di darne immediata comunicazione al mitte= nte e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks. 3D"rispe=Rispetta l'ambiente. No= n stampare questa mail se non =A8=A8 necessario.

--Boundary_(ID_sUmBhRfrYWdIbDeaDG8qOA)-- -- to 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 Jul 26 12:58: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 8FEA911E8088 for ; Tue, 26 Jul 2011 12:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.405 X-Spam-Level: ** X-Spam-Status: No, score=2.405 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F5kMOovCBcC for ; Tue, 26 Jul 2011 12:58:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id B740A21F8844 for ; Tue, 26 Jul 2011 12:58:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlniV-00095m-N6 for radiusext-data0@psg.com; Tue, 26 Jul 2011 19:54:59 +0000 Received: from grfedg701ba020.telecomitalia.it ([156.54.233.200]) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlniP-00095G-Sz for radiusext@ops.ietf.org; Tue, 26 Jul 2011 19:54:54 +0000 Content-Type: multipart/mixed; boundary="_0a86fb72-cc1b-42cb-97a9-499601ef85ef_" Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 26 Jul 2011 21:54:50 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 26 Jul 2011 21:54:50 +0200 From: Maglione Roberta To: Leaf yeh , 'Jacni Qin' CC: "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Date: Tue, 26 Jul 2011 21:54:50 +0200 Subject: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsP///hb8A== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5B@GRFMBX704BA020.griffon.local> References: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> <5B27BA75-FA0F-4082-9C52-E2CBD2D63A98@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D58@GRFMBX704BA020.griffon.local> <4E3D9B58-B42A-4F2A-9396-0FBFF0A3C2C5@mimectl> In-Reply-To: <4E3D9B58-B42A-4F2A-9396-0FBFF0A3C2C5@mimectl> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_0a86fb72-cc1b-42cb-97a9-499601ef85ef_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5BGRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5BGRFMBX704BA02_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBMZWFmIHllaCBbbWFp bHRvOmxlYWYueS55ZWhAaHVhd2VpLmNvbV0NClNlbnQ6IG1hcnRlZKisIDI2IGx1Z2xpbyAyMDEx IDIxLjUwDQpUbzogTWFnbGlvbmUgUm9iZXJ0YTsgJ0phY25pIFFpbicNCkNjOiBkcmFmdC1pZXRm LXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9y ZzsgZmluZV9zekBodWF3ZWkuY29tOyBRaXVqaW47IFdhbmdzaHV4aWFuZw0KU3ViamVjdDogtPC4 tDogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElF VEY4MSByYWRleHQgc2Vzc2lvbg0KDQoNCltSTV0gQWxsIHRoZSBjb25maWd1cmVkIHBvb2xzIGFy ZSB0aGUgc2FtZSBmb3IgdGhlIE5BUywgaW4gdGhpcyBjYXNlIGFuIGV4dHJhIGxvZ2ljIHdvdWxk IGJlIG5lZWRlZCB0byBpbnN0cnVjdCB0aGUgTkFTIGFib3V0IHdoaWNoIHBvb2wgaXMgZm9yIFNM QUFDIGFuZCB3aGljaCBvbmUgaXMgZm9yIERIQ1B2Ng0KDQoNCg0KVGhlIHBvb2xzIGNvbmZpZ3Vy ZWQgb24gdGhlIE5BUyBhcmUgbm90IG5lY2Vzc2FyeSB0byBiZSB0aGUgc2FtZS4gQUFBIHNlcnZl ciBkb2Vzbid0IHJlYWxseSBuZWVkIHRvIGluc3RydWN0IHRoZSBOQVMgdGhlIHNwZWNpZmllZCB0 eXBlIG9mIHBvb2xzLCB3aGljaCBpcyBhbHJlYWR5IGNvbmZpZ3VyZWQgb24gdGhlIE5BUy4gUmln aHQ/DQoNCg0KDQpbUk1dIE5BUyBjYW4gaGF2ZSBtYW55IHBvb2xzIGNvbmZpZ3VyZWQgbG9jYWxs eTogaG93IGRvZXMgdGhlIE5BUyBrbm93IHdoaWNoIHBvb2wgaXMgZm9yIFNMQUFDIGFuZCB3aGlj aCBwb29sIGlzIGZvciBESENQdjY/DQoNCg0KDQpSb2JlcnRhDQoNCg0KDQpCZXN0IFJlZ2FyZHMs DQoNCkxlYWYNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CreivP7IyzogTWFnbGlvbmUgUm9iZXJ0YSBbcm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlh Lml0XQ0Kt6LLzcqxvOQ6IDIwMTHE6jfUwjI3yNUgMjoyNw0Ktb06IExlYWYgeWVoOyAnSmFjbmkg UWluJw0KQ2M6IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyBy YWRpdXNleHRAb3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3No dXhpYW5nDQrW98ziOiBSRTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYt YWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoN CkJlc3QgcmVnYXJkcywNClJvYmVydGENCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkZyb206IExlYWYgeWVoIFttYWlsdG86bGVhZi55LnllaEBodWF3ZWkuY29tXQ0KU2VudDog bWFydGVkqKwgMjYgbHVnbGlvIDIwMTEgMjAuMjINClRvOiBNYWdsaW9uZSBSb2JlcnRhOyAnSmFj bmkgUWluJw0KQ2M6IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3Jn OyByYWRpdXNleHRAb3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2Fu Z3NodXhpYW5nDQpTdWJqZWN0OiC08Li0OiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRl eHQtaXB2Ni1hY2Nlc3MgYWZ0ZXIgSUVURjgxIHJhZGV4dCBzZXNzaW9uDQoNCg0KUm9iZXJ0YSAt IElmIHlvdSB1c2UgdGhlIHNhbWUgYXR0cmlidXRlIGZvciBib3RoIHNjZW5hcmlvcyBob3cgZG9l cyB0aGUgTkFTIGtub3cgaWYgdGhhdCBwb29sIGlzIGZvciBTTEFBQyBvciBmb3IgU3RhdGVmdWwg REhDUHY2Pw0KDQpOQVMgYWxyZWFkeSBoYXMgdGhvc2UgcG9vbCBuYW1lcyBpbiBpdHMgY29uZmln dXJhdGlvbiwgcmlnaHQ/DQoNCltSTV0geWVzIHBvb2xzIGFyZSBhbHJlYWR5IGNvbmZpZ3VyZWQg aW4gdGhlIE5BUw0KDQoNCg0KTkFTIGRvZXMga25vdyB3aGljaCBvbmUgaXMgZm9yIFNMQUFDIHBy ZWZpeCBwb29sLCB3aGljaCBvbmUgaXMgZm9yIERIQ1B2NiBhZGRyZXNzIHBvb2wuDQoNCg0KDQpb Uk1dIEFsbCB0aGUgY29uZmlndXJlZCBwb29scyBhcmUgdGhlIHNhbWUgZm9yIHRoZSBOQVMsIGlu IHRoaXMgY2FzZSBhbiBleHRyYSBsb2dpYyB3b3VsZCBiZSBuZWVkZWQgdG8gaW5zdHJ1Y3QgdGhl IE5BUyBhYm91dCB3aGljaCBwb29sIGlzIGZvciBTTEFBQyBhbmQgd2hpY2ggb25lIGlzIGZvciBE SENQdjYNCg0KDQoNCg0KDQoNCg0KVGhhdKGvcyB3aHkgaW4gbXkgb3BpbmlvbiB0aGUgU3RhdGVm dWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgcmVxdWlyZWQuDQoNCg0KDQoNCg0KQmVzdCBSZWdhcmRz LA0KDQpMZWFmDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCrei vP7IyzogTWFnbGlvbmUgUm9iZXJ0YSBbcm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0 XQ0Kt6LLzcqxvOQ6IDIwMTHE6jfUwjI3yNUgMjoxMw0Ktb06ICdKYWNuaSBRaW4nDQpDYzogTGVh ZiB5ZWg7IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRp dXNleHRAb3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhp YW5nDQrW98ziOiBSRTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNj ZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KSGkgSmFjbmksDQogICBJZiB5b3UgdXNl IHRoZSBzYW1lIGF0dHJpYnV0ZSBmb3IgYm90aCBzY2VuYXJpb3MgaG93IGRvZXMgdGhlIE5BUyBr bm93IGlmIHRoYXQgcG9vbCBpcyBmb3IgU0xBQUMgb3IgZm9yIFN0YXRlZnVsIERIQ1B2Nj8NCg0K VGhhbmtzLA0KUmVnYXJkcywNClJvYmVydGENCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBKYWNuaSBRaW4gW21haWx0bzpqYWNuaXFAZ21h aWwuY29tXQ0KU2VudDogbWFydGVkqKwgMjYgbHVnbGlvIDIwMTEgMjAuMDMNClRvOiBNYWdsaW9u ZSBSb2JlcnRhDQpDYzogTGVhZiB5ZWg7IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRv b2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207 IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpTdWJqZWN0OiBSZTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0 LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KDQpI aSBSb2JlcnRhLA0KDQpJIGFncmVlIHdpdGggeW91IGFib3V0IHRoZSBzZW1hbnRpY2FsIGxvZ2lj LCB3aGlsZSAiU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wiIGlzIG5vdCBuZWNlc3NhcnksIElN SE8uDQoNCg0KQ2hlZXJzLA0KSmFjbmkNCk9uIFdlZCwgSnVsIDI3LCAyMDExIGF0IDE6NTUgQU0s IE1hZ2xpb25lIFJvYmVydGEgPHJvYmVydGEubWFnbGlvbmVAdGVsZWNvbWl0YWxpYS5pdD4gd3Jv dGU6DQpIZWxsbyBMZWFmLA0KICAgIFRoZSBkaWZmZXJlbnQgYXR0cmlidXRlcyBwcm9wb3NlZCBp biB0aGlzIGRyYWZ0IGZvciB0aGUgcG9vbHMgbmFtZSBoYXZlIGFsbCB0aGUgc2FtZSBmb3JtYXQg KGEgc3RyaW5nKSwgYnV0IHNlbWFudGljYWxseSB0aGV5IGFyZSBkaWZmZXJlbnQsIGFzIHRoZXkg Y292ZWQgZGlmZmVyZW50IHNjZW5hcmlvcy4NCkFzIHlvdSBhbHNvIHN1bW1hcml6ZWQgaW4geW91 ciBlbWFpbCBiZWxvdywNCg0KRnJhbWVkLVBvb2wgd2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NCBh ZGRyZXNzIHBvb2w7DQpGcmFtZWQtSVB2Ni1Qb29sIHdhcyBkZXNpZ25lZCBmb3IgdGhlIElQdjYg U0xBQUMgcHJlZml4IHBvb2w7DQpEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCBpcyBkZXNpZ25l ZCBmb3IgREhDUHY2LVBEIHByZWZpeCBwb29sOw0KU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wg aXMgZGVzaWduZWQgZm9yIERIQ1B2NiBhZGRyZXNzIHBvb2w7DQoNClNvIGVhY2ggYXR0cmlidXRl IGNvdmVycyBhIGRpZmZlcmVudCB1c2UtY2FzZS9zY2VuYXJpbyBhbmQgdGhleSBjYW4gYXBwZWFy IGluIHRoZSBzYW1lIFJBRElVUyBwYWNrZXQgYXQgdGhlIHNhbWUgdGltZS4NCklmIHlvdSB3YW50 IHRvIHVzZSBhIHNpbmdsZSBwb29sIG5hbWUgdXNlIHRvIGNvdmVyIGFsbCB0aGUgNCB1c2UgY2Fz ZXMgbGlzdGVkIGFib3ZlLCB5b3Ugd291bGQgYWxzbyBuZWVkIHRvIGRlZmluZSBhIHN0YW5kYXJk IGZvcm1hdC9zeW50YXggZm9yIHRoZSBwb29sIG5hbWUgdGhhdCBhbGxvd3MgdGhlIE5BUyB0byBi ZSBhYmxlIHRvIGRpc2FtYmlndWF0ZSBhbW9uZyB0aGUgZGlmZmVyZW50IHNjZW5hcmlvcyBhbmQg aW4gb3JkZXIgdG8gZG8gdGhhdCB0aGUgTkFTIHdvdWxkIG5lZWQgdG8gaGF2ZSBhbiBleHRyYSBs b2dpYyB0byBpbmZlciB0aGUgc2VtYW50aWMgb2YgdGhhdCBzcGVjaWZpYyBhdHRyaWJ1dGUgZnJv bSB0aGUgYXNzaWduZWQgbmFtZS4NCkluc3RlYWQgaWYgeW91IGhhdmUgYSBzcGVjaWZpYyBhdHRy aWJ1dGUgZm9yIGVhY2ggc3BlY2lmaWMgc2NlbmFyaW8sIHRoZSBzZW1hbnRpYyBpcyBtYXBwZWQg dG8gdGhlIGF0dHJpYnV0ZSBuYW1lLCB0aHVzIHRoZSBOQVMgZG9lcyBub3QgbmVlZCBhbiBleHRy YSBsb2dpYyB0byBkaXNjb3ZlcnkgdGhlIHB1cnBvc2Ugb2YgdGhhdCBwb29sIGFuZCB0aGUgcG9v bCBuYW1lIGNhbiBiZSBhbnkgc3RyaW5nLCBubyBsaW1pdGF0aW9uIG9yIHNwZWNpYWwgc3ludGF4 IGlzIGZvcmNlZCBmb3IgdGhlIHBvb2wgbmFtZS4NCg0KDQpUaGFua3MsDQpSZWdhcmRzLA0KUm9i ZXJ0YQ0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IG93bmVyLXJhZGl1c2V4dEBvcHMuaWV0Zi5vcmcgW21haWx0bzpvd25lci1yYWRpdXNl eHRAb3BzLmlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGVhZiB5ZWgNClNlbnQ6IGx1bmVkqKwgMjUg bHVnbGlvIDIwMTEgMTguMjMNClRvOiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29s cy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZw0KQ2M6IGZpbmVfc3pAaHVhd2VpLmNv bTsgUWl1amluOyBXYW5nc2h1eGlhbmcNClN1YmplY3Q6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1p ZXRmLXJhZGV4dC1pcHY2LWFjY2VzcyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb24NCg0KUXVl c3Rpb24gZm9yIGNsYXJpZmljYXRpb246DQoNCldlIGFscmVhZHkgaGF2ZSB0aGUgZm9sbG93aW5n IFJhZGl1cyBBdHRyaWJ1dGVzIGZvciB0aGUgYWRkcmVzcy9wcmVmaXggcG9vbHM6DQoNCkZyYW1l ZC1Qb29sICg4OCwgc2VjdGlvbiA1LjE4IG9mIFJGQzI4NjkpLA0KRnJhbWVkLUlQdjYtUG9vbCAo MTAwLCBzZWN0aW9uIDIuNiBvZiBSRkMzMTYyKS4NCg0KaHR0cDovL3d3dy5pYW5hLm9yZy9hc3Np Z25tZW50cy9yYWRpdXMtdHlwZXMvcmFkaXVzLXR5cGVzLnhtbA0KDQpUaGUgZm9yYW10IGFyZSB0 aGUgc2FtZSBhcyBmb2xsb3dzOg0KDQowICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAg ICAgICAgMg0KMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMN CistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCnwgICAg IFR5cGUgICAgICB8ICAgIExlbmd0aCAgICAgfCAgICAgU3RyaW5nLi4uDQorLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCmRyYWZ0LWlldGYtcmFkZXh0 LWlwdjYtYWNjZXNzLTA1IGlzIHByb3Bvc2luZyAyIG5ldyBhdHRyaWJ1dGVzIGZvciBhZGRyZXNz L3ByZWZpeCBwb29sczoNCg0KRGVsZWdhdGVkLUlQdjYtUHJlZml4LVBvb2wsDQpTdGF0ZWZ1bC1J UHY2LUFkZHJlc3MtUG9vbCwNCg0KdGhlIGZvbWF0IG9mIHRoZXNlIDIgYXR0cmlidXRlcyBhcmUg dGhlIHNhbWUgYXMgdGhlIGFib3ZlIG9uZS4NCg0KDQpTdXBwb3NlZCB0aGUgYWJvdmUgYXR0cmli dXRlcyBjb3VsZCBiZSBleHBsYWluZWQgYXMgZm9sbG93czoNCg0KRnJhbWVkLVBvb2wgd2FzIGRl c2lnbmVkIGZvciB0aGUgSVB2NCBhZGRyZXNzIHBvb2w7DQpGcmFtZWQtSVB2Ni1Qb29sIHdhcyBk ZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xBQUMgcHJlZml4IHBvb2w7DQpEZWxlZ2F0ZWQtSVB2Ni1Q cmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2LVBEIHByZWZpeCBwb29sOw0KU3RhdGVm dWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgZGVzaWduZWQgZm9yIERIQ1B2NiBhZGRyZXNzIHBvb2w7 DQoNCkFsbCBhYm92ZSBhdHRyaWJ1dGVzIGFyZSBvbmx5IHVzZWQgdG8gcHJvdmlkZSB0aGUgbmFt ZSBvZiB0aGUgYWRkcmVzcy9wcmVmaXggcG9vbHMgaW4gYSAnc3RyaW5nJy4gSSBkb3VidCB0aGUg bmVjZXNzaXR5IHRvIG1ha2Ugc28gbWFueSAnbmFtZScgb3IgJ3N0cmluZycgYXR0cmlidXRlcyBm b3IgdGhlIGRpZmZlcmVudCBhZGRyZXNzL3ByZWZpeCBwb29scyB0byBwcmV2ZW50IHRoZSBhbWJp Z3VpdHkuIEkgZ3Vlc3MgMSBhdHRyaWJ1dGUgZm9yIHRoZSBuYW1lIG9mIHRoZSBhZGRyZXNzL3By ZWZpeCBwb29scyBtaWdodCBiZSBlbm91Z2guIEluIGZhY3QsIHRoZSBOQVMgdGFrZSB0aGUgcm9s ZSB0byBpbnRlcnByZXQgdGhlIG1lYW5pbmcgb2YgdGhlIHBvb2sgbmFtZSwgcmlnaHQ/DQoNCkkg dGhpbmsgRnJhbWVkLVBvb2wgY2FuIGJlIHJlLXVzZWQgZm9yIHRoZSBkZXNpZ24gcHVycG9zZSBv ZiBTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbC4gRG8gd2UgaGF2ZSBhbnkgbGltaXRhdGlvbiBv biB0aGUgdXNhZ2Ugb2YgRnJhbWVkLVBvb2wgZm9yIElQdjY/DQpJIHRoaW5rIEZyYW1lZC1JUHY2 LVBvb2wgY2FuIGJlIHJlLXVzZWQgZm9yIHRoZSBkZXNpZ24gcHVycG9zZSBvZiBEZWxlZ2F0ZWQt SVB2Ni1QcmVmaXgtUG9vbCB0byBpbmRpY2F0ZSBhIHBvb2wgb2YgSVB2NiBwcmVmaXggcG9vbC4g SSBjb3VsZCBldmVuIHRoaW5rIEZyYW1lZC1Qb29sIGNhbiByZXBsYWNlIEZyYW1lZC1JUHY2LVBv b2wgdG8gaW5kaWNhdGUgdGhlIG5hbWUgb2YgYSBJUHY2IHByZWZpeC9hZGRyZXNzIHBvb2wgcGVy IHRoZSBzYW1lIGxvZ2ljLiBBbSBJIHJpZ2h0Pw0KDQoNCkJlc3QgUmVnYXJkcywNCkxlYWYNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkg c29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExh IGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFs bGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2 aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJy b3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmlj YXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwg R3JhemllLg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwg YW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBh ZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNl IGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNo bWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NClJp c3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gqKggbmVj ZXNzYXJpby4NCg0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5k aXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNp b25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9z Y2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4g UXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0 ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBh bCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4N Cg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1h eSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNz ZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFu eWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMg YW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NClF1ZXN0byBt ZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50 ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNp IGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3Jt YXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1 dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRp IGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZl ZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55 IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0 aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9y aXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIg YnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KWyUyMF1SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24g c3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIKioIG5lY2Vzc2FyaW8uDQoNCg0KUXVlc3RvIG1l c3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRl IGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kg YWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1h emlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0 byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkg ZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVk ZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRp b24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jp c2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBi eSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQoNCltjaWQ6MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDFAVEkuRGlzY2xhaW1lcl1SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUg cXVlc3RhIG1haWwgc2Ugbm9uIKioIG5lY2Vzc2FyaW8uDQoNCg== --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5BGRFMBX704BA02_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

 

 

From: Leaf yeh [mailto:leaf.y.yeh@hu= awei.com]
Sent: marted=A8=AC 26 luglio= 2011 21.50
To: Maglione Roberta; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

 

[RM] All the configured pools are the same for the NAS, i= n this case an extra logic would be needed to instruct the NAS about which = pool is for SLAAC and which one is for DHCPv6

 

The pools configured on the NAS are not necessa= ry to be the same. AAA server doesn't really need to instruct the NAS the s= pecified type of pools, which is already configured on the NAS. Right?

 

[RM] NAS can have many pools configured locally: how does= the NAS know which pool is for SLAAC and which pool is for DHCPv6?

 

Roberta

 

Best Regards,

Leaf

 

 

 

=B7=A2=BC=FE=C8=CB: Maglione Roberta [roberta.magl= ione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1=BC=E4= : 2011=C4=EA7=D4=C227=C8=D5 2:27
=B5=BD: Leaf yeh; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
=D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext sess= ion

Please see inline.

 

Best regards,

Roberta

 

= From: Leaf yeh [mailto:leaf.y.yeh@hu= awei.com]
Sent: marted=A8=AC 26 luglio= 2011 20.22
To: Maglione Roberta; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<= /span><= /span>

 

Roberta - If you use the same attribut= e for both scenarios how does the NAS know if that pool is for SLAAC or for= Stateful DHCPv6?

NAS already has those pool names in its configuration, right?

[RM] yes pools are already configured in the NAS

 

NAS does know which one is for SLAAC p= refix pool, which one is for DHCPv6 address pool. 

 

[RM] All the configured pools are the same for the NAS, i= n this case an extra logic would be needed to instruct the NAS about which = pool is for SLAAC and which one is for DHCPv6

 

 

 

That=A1=AFs why in my opinion the Stateful-IPv6-Address-P= ool is required.

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB: Maglione Roberta [roberta.magl= ione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1=BC=E4= : 2011=C4=EA7=D4=C227=C8=D5 2:13
=B5=BD: 'Jacni Qin'
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
=D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext sess= ion

Hi Jacni,
   If you use the same attribute for both scenarios how does the = NAS know if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mail= to:jacniq@gmail.com]
Sent: marted=A8=AC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_s= z@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session

Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Rober= ta <roberta.maglione@telecomitalia.it> wrote:
Hello Leaf,
    The different attributes proposed in this draft for the = pools name have all the same format (a string), but semantically they are d= ifferent, as they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: owner-radiusext@ops.ietf.org [mai= lto:owner-radiusext@ops.ietf.org] On Behalf Of Leaf yeh
Sent: luned=A8=AC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.or= g; radiusext@ops.ietf.org
Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0            &n= bsp;      1      &nb= sp;            2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |  &= nbsp; Length     |     String... +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.= =

Que= sto messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi alt= ra azione derivante dalla conoscenza di queste informazioni sono rigorosame= nte vietate. Qualora abbiate ricevuto questo documento per errore siete cor= tesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments = = is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispe= tta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =A8=A8 necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5BGRFMBX704BA02_-- --_0a86fb72-cc1b-42cb-97a9-499601ef85ef_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_0a86fb72-cc1b-42cb-97a9-499601ef85ef_-- -- to 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 Jul 26 13:55:56 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 C16C1228006 for ; Tue, 26 Jul 2011 13:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.311 X-Spam-Level: * X-Spam-Status: No, score=1.311 tagged_above=-999 required=5 tests=[AWL=-2.139, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvDgTGXggoZb for ; Tue, 26 Jul 2011 13:55:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0B621F8AD3 for ; Tue, 26 Jul 2011 13:55:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qlobc-000CmX-Af for radiusext-data0@psg.com; Tue, 26 Jul 2011 20:51:56 +0000 Received: from szxga01-in.huawei.com ([119.145.14.64]) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QlobV-000Clc-HM for radiusext@ops.ietf.org; Tue, 26 Jul 2011 20:51:50 +0000 Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOY00C46KMBIK@szxga05-in.huawei.com> for radiusext@ops.ietf.org; Wed, 27 Jul 2011 04:51:47 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOY00H81KM9VC@szxga05-in.huawei.com> for radiusext@ops.ietf.org; Wed, 27 Jul 2011 04:51:47 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACP77674; Wed, 27 Jul 2011 04:51:45 +0800 (CST) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 27 Jul 2011 04:51:41 +0800 Received: from SZXEML510-MBX.china.huawei.com ([169.254.7.200]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Wed, 27 Jul 2011 04:51:43 +0800 Date: Tue, 26 Jul 2011 20:51:42 +0000 From: Leaf yeh Subject: =?gb2312?B?tPC4tDogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYt?= =?gb2312?Q?access_after_IETF81_radext_session?= In-reply-to: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5B@GRFMBX704BA020.griffon.local> X-Originating-IP: [172.24.2.41] To: Maglione Roberta , 'Jacni Qin' Cc: "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Message-id: <53BB6F0B-2A09-49F7-BB3D-674D006F3BB5@mimectl> MIME-version: 1.0 Content-type: multipart/related; boundary="Boundary_(ID_ITUFOJQmyenezSW/dtU8EQ)"; type="multipart/alternative" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsP///hb8P//4L6o///A+qI= X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> <5B27BA75-FA0F-4082-9C52-E2CBD2D63A98@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D58@GRFMBX704BA020.griffon.local> <4E3D9B58-B42A-4F2A-9396-0FBFF0A3C2C5@mimectl> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5B@GRFMBX704BA020.griffon.local> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --Boundary_(ID_ITUFOJQmyenezSW/dtU8EQ) Content-type: multipart/alternative; boundary="Boundary_(ID_P+ORJX74LpewiGptGKjIvA)" --Boundary_(ID_P+ORJX74LpewiGptGKjIvA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 W1JNXSBOQVMgY2FuIGhhdmUgbWFueSBwb29scyBjb25maWd1cmVkIGxvY2FsbHk6IGhvdyBkb2Vz IHRoZSBOQVMga25vdyB3aGljaCBwb29sIGlzIGZvciBTTEFBQyBhbmQgd2hpY2ggcG9vbCBpcyBm b3IgREhDUHY2Pw0KDQoNCg0KSSBzdXBwb3NlZCB0aGUgbG9jYWwgY29uZmlndXJhdGlvbiBvbiB0 aGUgTkFTIHdpbGwgYW5zd2VyIHRoaXMgcXVlc3Rpb24uDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoN CkxlYWYNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQq3orz+ yMs6IE1hZ2xpb25lIFJvYmVydGEgW3JvYmVydGEubWFnbGlvbmVAdGVsZWNvbWl0YWxpYS5pdF0N Creiy83KsbzkOiAyMDExxOo31MIyN8jVIDM6NTQNCrW9OiBMZWFmIHllaDsgJ0phY25pIFFpbicN CkNjOiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVz ZXh0QG9wcy5pZXRmLm9yZzsgZmluZV9zekBodWF3ZWkuY29tOyBRaXVqaW47IFdhbmdzaHV4aWFu Zw0K1vfM4jogUkU6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vz cyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb24NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpGcm9tOiBMZWFmIHllaCBbbWFpbHRvOmxlYWYueS55ZWhAaHVhd2VpLmNv bV0NClNlbnQ6IG1hcnRlZKisIDI2IGx1Z2xpbyAyMDExIDIxLjUwDQpUbzogTWFnbGlvbmUgUm9i ZXJ0YTsgJ0phY25pIFFpbicNCkNjOiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29s cy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZzsgZmluZV9zekBodWF3ZWkuY29tOyBR aXVqaW47IFdhbmdzaHV4aWFuZw0KU3ViamVjdDogtPC4tDogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0 LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KDQoN CltSTV0gQWxsIHRoZSBjb25maWd1cmVkIHBvb2xzIGFyZSB0aGUgc2FtZSBmb3IgdGhlIE5BUywg aW4gdGhpcyBjYXNlIGFuIGV4dHJhIGxvZ2ljIHdvdWxkIGJlIG5lZWRlZCB0byBpbnN0cnVjdCB0 aGUgTkFTIGFib3V0IHdoaWNoIHBvb2wgaXMgZm9yIFNMQUFDIGFuZCB3aGljaCBvbmUgaXMgZm9y IERIQ1B2Ng0KDQoNCg0KVGhlIHBvb2xzIGNvbmZpZ3VyZWQgb24gdGhlIE5BUyBhcmUgbm90IG5l Y2Vzc2FyeSB0byBiZSB0aGUgc2FtZS4gQUFBIHNlcnZlciBkb2Vzbid0IHJlYWxseSBuZWVkIHRv IGluc3RydWN0IHRoZSBOQVMgdGhlIHNwZWNpZmllZCB0eXBlIG9mIHBvb2xzLCB3aGljaCBpcyBh bHJlYWR5IGNvbmZpZ3VyZWQgb24gdGhlIE5BUy4gUmlnaHQ/DQoNCg0KDQpbUk1dIE5BUyBjYW4g aGF2ZSBtYW55IHBvb2xzIGNvbmZpZ3VyZWQgbG9jYWxseTogaG93IGRvZXMgdGhlIE5BUyBrbm93 IHdoaWNoIHBvb2wgaXMgZm9yIFNMQUFDIGFuZCB3aGljaCBwb29sIGlzIGZvciBESENQdjY/DQoN Cg0KDQpSb2JlcnRhDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoNCkxlYWYNCg0KDQoNCg0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogTWFnbGlvbmUgUm9iZXJ0 YSBbcm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0XQ0Kt6LLzcqxvOQ6IDIwMTHE6jfU wjI3yNUgMjoyNw0Ktb06IExlYWYgeWVoOyAnSmFjbmkgUWluJw0KQ2M6IGRyYWZ0LWlldGYtcmFk ZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3JnOyBm aW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQrW98ziOiBSRTogUSBvbiBW ZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRl eHQgc2Vzc2lvbg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkJlc3QgcmVnYXJkcywNClJvYmVydGEN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IExlYWYgeWVoIFttYWls dG86bGVhZi55LnllaEBodWF3ZWkuY29tXQ0KU2VudDogbWFydGVkqKwgMjYgbHVnbGlvIDIwMTEg MjAuMjINClRvOiBNYWdsaW9uZSBSb2JlcnRhOyAnSmFjbmkgUWluJw0KQ2M6IGRyYWZ0LWlldGYt cmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3Jn OyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpTdWJqZWN0OiC08Li0 OiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3MgYWZ0ZXIgSUVU RjgxIHJhZGV4dCBzZXNzaW9uDQoNCg0KUm9iZXJ0YSAtIElmIHlvdSB1c2UgdGhlIHNhbWUgYXR0 cmlidXRlIGZvciBib3RoIHNjZW5hcmlvcyBob3cgZG9lcyB0aGUgTkFTIGtub3cgaWYgdGhhdCBw b29sIGlzIGZvciBTTEFBQyBvciBmb3IgU3RhdGVmdWwgREhDUHY2Pw0KDQpOQVMgYWxyZWFkeSBo YXMgdGhvc2UgcG9vbCBuYW1lcyBpbiBpdHMgY29uZmlndXJhdGlvbiwgcmlnaHQ/DQoNCltSTV0g eWVzIHBvb2xzIGFyZSBhbHJlYWR5IGNvbmZpZ3VyZWQgaW4gdGhlIE5BUw0KDQoNCg0KTkFTIGRv ZXMga25vdyB3aGljaCBvbmUgaXMgZm9yIFNMQUFDIHByZWZpeCBwb29sLCB3aGljaCBvbmUgaXMg Zm9yIERIQ1B2NiBhZGRyZXNzIHBvb2wuDQoNCg0KDQpbUk1dIEFsbCB0aGUgY29uZmlndXJlZCBw b29scyBhcmUgdGhlIHNhbWUgZm9yIHRoZSBOQVMsIGluIHRoaXMgY2FzZSBhbiBleHRyYSBsb2dp YyB3b3VsZCBiZSBuZWVkZWQgdG8gaW5zdHJ1Y3QgdGhlIE5BUyBhYm91dCB3aGljaCBwb29sIGlz IGZvciBTTEFBQyBhbmQgd2hpY2ggb25lIGlzIGZvciBESENQdjYNCg0KDQoNCg0KDQoNCg0KVGhh dKGvcyB3aHkgaW4gbXkgb3BpbmlvbiB0aGUgU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMg cmVxdWlyZWQuDQoNCg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpMZWFmDQoNCg0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogTWFnbGlvbmUgUm9iZXJ0YSBb cm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0XQ0Kt6LLzcqxvOQ6IDIwMTHE6jfUwjI3 yNUgMjoxMw0Ktb06ICdKYWNuaSBRaW4nDQpDYzogTGVhZiB5ZWg7IGRyYWZ0LWlldGYtcmFkZXh0 LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3JnOyBmaW5l X3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQrW98ziOiBSRTogUSBvbiBWZXIu LTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQg c2Vzc2lvbg0KSGkgSmFjbmksDQogICBJZiB5b3UgdXNlIHRoZSBzYW1lIGF0dHJpYnV0ZSBmb3Ig Ym90aCBzY2VuYXJpb3MgaG93IGRvZXMgdGhlIE5BUyBrbm93IGlmIHRoYXQgcG9vbCBpcyBmb3Ig U0xBQUMgb3IgZm9yIFN0YXRlZnVsIERIQ1B2Nj8NCg0KVGhhbmtzLA0KUmVnYXJkcywNClJvYmVy dGENCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpG cm9tOiBKYWNuaSBRaW4gW21haWx0bzpqYWNuaXFAZ21haWwuY29tXQ0KU2VudDogbWFydGVkqKwg MjYgbHVnbGlvIDIwMTEgMjAuMDMNClRvOiBNYWdsaW9uZSBSb2JlcnRhDQpDYzogTGVhZiB5ZWg7 IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRA b3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpT dWJqZWN0OiBSZTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNz IGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KDQpIaSBSb2JlcnRhLA0KDQpJIGFncmVlIHdp dGggeW91IGFib3V0IHRoZSBzZW1hbnRpY2FsIGxvZ2ljLCB3aGlsZSAiU3RhdGVmdWwtSVB2Ni1B ZGRyZXNzLVBvb2wiIGlzIG5vdCBuZWNlc3NhcnksIElNSE8uDQoNCg0KQ2hlZXJzLA0KSmFjbmkN Ck9uIFdlZCwgSnVsIDI3LCAyMDExIGF0IDE6NTUgQU0sIE1hZ2xpb25lIFJvYmVydGEgPHJvYmVy dGEubWFnbGlvbmVAdGVsZWNvbWl0YWxpYS5pdD4gd3JvdGU6DQpIZWxsbyBMZWFmLA0KICAgIFRo ZSBkaWZmZXJlbnQgYXR0cmlidXRlcyBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0IGZvciB0aGUgcG9v bHMgbmFtZSBoYXZlIGFsbCB0aGUgc2FtZSBmb3JtYXQgKGEgc3RyaW5nKSwgYnV0IHNlbWFudGlj YWxseSB0aGV5IGFyZSBkaWZmZXJlbnQsIGFzIHRoZXkgY292ZWQgZGlmZmVyZW50IHNjZW5hcmlv cy4NCkFzIHlvdSBhbHNvIHN1bW1hcml6ZWQgaW4geW91ciBlbWFpbCBiZWxvdywNCg0KRnJhbWVk LVBvb2wgd2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NCBhZGRyZXNzIHBvb2w7DQpGcmFtZWQtSVB2 Ni1Qb29sIHdhcyBkZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xBQUMgcHJlZml4IHBvb2w7DQpEZWxl Z2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2LVBEIHByZWZpeCBw b29sOw0KU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgZGVzaWduZWQgZm9yIERIQ1B2NiBh ZGRyZXNzIHBvb2w7DQoNClNvIGVhY2ggYXR0cmlidXRlIGNvdmVycyBhIGRpZmZlcmVudCB1c2Ut Y2FzZS9zY2VuYXJpbyBhbmQgdGhleSBjYW4gYXBwZWFyIGluIHRoZSBzYW1lIFJBRElVUyBwYWNr ZXQgYXQgdGhlIHNhbWUgdGltZS4NCklmIHlvdSB3YW50IHRvIHVzZSBhIHNpbmdsZSBwb29sIG5h bWUgdXNlIHRvIGNvdmVyIGFsbCB0aGUgNCB1c2UgY2FzZXMgbGlzdGVkIGFib3ZlLCB5b3Ugd291 bGQgYWxzbyBuZWVkIHRvIGRlZmluZSBhIHN0YW5kYXJkIGZvcm1hdC9zeW50YXggZm9yIHRoZSBw b29sIG5hbWUgdGhhdCBhbGxvd3MgdGhlIE5BUyB0byBiZSBhYmxlIHRvIGRpc2FtYmlndWF0ZSBh bW9uZyB0aGUgZGlmZmVyZW50IHNjZW5hcmlvcyBhbmQgaW4gb3JkZXIgdG8gZG8gdGhhdCB0aGUg TkFTIHdvdWxkIG5lZWQgdG8gaGF2ZSBhbiBleHRyYSBsb2dpYyB0byBpbmZlciB0aGUgc2VtYW50 aWMgb2YgdGhhdCBzcGVjaWZpYyBhdHRyaWJ1dGUgZnJvbSB0aGUgYXNzaWduZWQgbmFtZS4NCklu c3RlYWQgaWYgeW91IGhhdmUgYSBzcGVjaWZpYyBhdHRyaWJ1dGUgZm9yIGVhY2ggc3BlY2lmaWMg c2NlbmFyaW8sIHRoZSBzZW1hbnRpYyBpcyBtYXBwZWQgdG8gdGhlIGF0dHJpYnV0ZSBuYW1lLCB0 aHVzIHRoZSBOQVMgZG9lcyBub3QgbmVlZCBhbiBleHRyYSBsb2dpYyB0byBkaXNjb3ZlcnkgdGhl IHB1cnBvc2Ugb2YgdGhhdCBwb29sIGFuZCB0aGUgcG9vbCBuYW1lIGNhbiBiZSBhbnkgc3RyaW5n LCBubyBsaW1pdGF0aW9uIG9yIHNwZWNpYWwgc3ludGF4IGlzIGZvcmNlZCBmb3IgdGhlIHBvb2wg bmFtZS4NCg0KDQpUaGFua3MsDQpSZWdhcmRzLA0KUm9iZXJ0YQ0KDQoNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IG93bmVyLXJhZGl1c2V4dEBv cHMuaWV0Zi5vcmcgW21haWx0bzpvd25lci1yYWRpdXNleHRAb3BzLmlldGYub3JnXSBPbiBCZWhh bGYgT2YgTGVhZiB5ZWgNClNlbnQ6IGx1bmVkqKwgMjUgbHVnbGlvIDIwMTEgMTguMjMNClRvOiBk cmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9w cy5pZXRmLm9yZw0KQ2M6IGZpbmVfc3pAaHVhd2VpLmNvbTsgUWl1amluOyBXYW5nc2h1eGlhbmcN ClN1YmplY3Q6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2VzcyBh ZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb24NCg0KUXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb246 DQoNCldlIGFscmVhZHkgaGF2ZSB0aGUgZm9sbG93aW5nIFJhZGl1cyBBdHRyaWJ1dGVzIGZvciB0 aGUgYWRkcmVzcy9wcmVmaXggcG9vbHM6DQoNCkZyYW1lZC1Qb29sICg4OCwgc2VjdGlvbiA1LjE4 IG9mIFJGQzI4NjkpLA0KRnJhbWVkLUlQdjYtUG9vbCAoMTAwLCBzZWN0aW9uIDIuNiBvZiBSRkMz MTYyKS4NCg0KaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9yYWRpdXMtdHlwZXMvcmFk aXVzLXR5cGVzLnhtbA0KDQpUaGUgZm9yYW10IGFyZSB0aGUgc2FtZSBhcyBmb2xsb3dzOg0KDQow ICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMg0KMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMNCistKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCnwgICAgIFR5cGUgICAgICB8ICAgIExlbmd0aCAg ICAgfCAgICAgU3RyaW5nLi4uDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQoNCmRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLTA1IGlzIHByb3Bv c2luZyAyIG5ldyBhdHRyaWJ1dGVzIGZvciBhZGRyZXNzL3ByZWZpeCBwb29sczoNCg0KRGVsZWdh dGVkLUlQdjYtUHJlZml4LVBvb2wsDQpTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCwNCg0KdGhl IGZvbWF0IG9mIHRoZXNlIDIgYXR0cmlidXRlcyBhcmUgdGhlIHNhbWUgYXMgdGhlIGFib3ZlIG9u ZS4NCg0KDQpTdXBwb3NlZCB0aGUgYWJvdmUgYXR0cmlidXRlcyBjb3VsZCBiZSBleHBsYWluZWQg YXMgZm9sbG93czoNCg0KRnJhbWVkLVBvb2wgd2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NCBhZGRy ZXNzIHBvb2w7DQpGcmFtZWQtSVB2Ni1Qb29sIHdhcyBkZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xB QUMgcHJlZml4IHBvb2w7DQpEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBm b3IgREhDUHY2LVBEIHByZWZpeCBwb29sOw0KU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMg ZGVzaWduZWQgZm9yIERIQ1B2NiBhZGRyZXNzIHBvb2w7DQoNCkFsbCBhYm92ZSBhdHRyaWJ1dGVz IGFyZSBvbmx5IHVzZWQgdG8gcHJvdmlkZSB0aGUgbmFtZSBvZiB0aGUgYWRkcmVzcy9wcmVmaXgg cG9vbHMgaW4gYSAnc3RyaW5nJy4gSSBkb3VidCB0aGUgbmVjZXNzaXR5IHRvIG1ha2Ugc28gbWFu eSAnbmFtZScgb3IgJ3N0cmluZycgYXR0cmlidXRlcyBmb3IgdGhlIGRpZmZlcmVudCBhZGRyZXNz L3ByZWZpeCBwb29scyB0byBwcmV2ZW50IHRoZSBhbWJpZ3VpdHkuIEkgZ3Vlc3MgMSBhdHRyaWJ1 dGUgZm9yIHRoZSBuYW1lIG9mIHRoZSBhZGRyZXNzL3ByZWZpeCBwb29scyBtaWdodCBiZSBlbm91 Z2guIEluIGZhY3QsIHRoZSBOQVMgdGFrZSB0aGUgcm9sZSB0byBpbnRlcnByZXQgdGhlIG1lYW5p bmcgb2YgdGhlIHBvb2sgbmFtZSwgcmlnaHQ/DQoNCkkgdGhpbmsgRnJhbWVkLVBvb2wgY2FuIGJl IHJlLXVzZWQgZm9yIHRoZSBkZXNpZ24gcHVycG9zZSBvZiBTdGF0ZWZ1bC1JUHY2LUFkZHJlc3Mt UG9vbC4gRG8gd2UgaGF2ZSBhbnkgbGltaXRhdGlvbiBvbiB0aGUgdXNhZ2Ugb2YgRnJhbWVkLVBv b2wgZm9yIElQdjY/DQpJIHRoaW5rIEZyYW1lZC1JUHY2LVBvb2wgY2FuIGJlIHJlLXVzZWQgZm9y IHRoZSBkZXNpZ24gcHVycG9zZSBvZiBEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCB0byBpbmRp Y2F0ZSBhIHBvb2wgb2YgSVB2NiBwcmVmaXggcG9vbC4gSSBjb3VsZCBldmVuIHRoaW5rIEZyYW1l ZC1Qb29sIGNhbiByZXBsYWNlIEZyYW1lZC1JUHY2LVBvb2wgdG8gaW5kaWNhdGUgdGhlIG5hbWUg b2YgYSBJUHY2IHByZWZpeC9hZGRyZXNzIHBvb2wgcGVyIHRoZSBzYW1lIGxvZ2ljLiBBbSBJIHJp Z2h0Pw0KDQoNCkJlc3QgUmVnYXJkcywNCkxlYWYNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClF1 ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNp dmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVh bHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUg aW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUg cmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBw cmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkg cHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KVGhpcyBlLW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2Vt aW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1 dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2Vu ZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NClJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBz dGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gqKggbmVjZXNzYXJpby4NCg0KDQpRdWVzdG8gbWVz c2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUg YWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBh bHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6 aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRv IHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBk aSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRl cmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlv biwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlz ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5 IHJldHVybiBlLW1haWwsIFRoYW5rcy4NClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdh dGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUu IExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUg ZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50 ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIg ZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211 bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9u ZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVu dGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3Ig dGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBv ciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBh dHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtz Lg0KW3Jpc3BldHRhIGwnYW1iaWVudGVdUmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJl IHF1ZXN0YSBtYWlsIHNlIG5vbiCoqCBuZWNlc3NhcmlvLg0KDQoNClF1ZXN0byBtZXNzYWdnaW8g ZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBl cnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6 aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNv bm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3Rv IGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5l IGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxh IHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlv biBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5 aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJu IGUtbWFpbCwgVGhhbmtzLg0KDQpbcmlzcGV0dGEgbCdhbWJpZW50ZV1SaXNwZXR0YSBsJ2FtYmll bnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIKioIG5lY2Vzc2FyaW8uDQoNCg== --Boundary_(ID_P+ORJX74LpewiGptGKjIvA) Content-id: <5D310CAD16147C4EADB0D759F5D3F12A@huawei.com> Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

[RM] NAS can have many pools config= ured locally: how does the NAS know which pool is for SLAAC and which pool = is for DHCPv6?

 

I supposed the local configuration on the NAS will answer this question.=

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB: Maglione Roberta [robe= rta.maglione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 3:54
=B5=BD: Leaf yeh; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf= .org; fine_sz@huawei.com; Qiujin; Wangshuxiang
=D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access afte= r IETF81 radext session

&= nbsp;

&= nbsp;

From:= Leaf yeh [mailto:leaf.y.yeh@huawei.com]
Sent: marted=A8=AC 26 lugli= o 2011 21.50
To: Maglione Roberta; 'Jacn= i Qin'
Cc: draft-ietf-radext-ipv6-= access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; = Wangshuxiang
Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

 

[RM] All the configured pools are t= he same for the NAS, in this case an extra logic would be needed to instruc= t the NAS about which pool is for SLAAC and which one is for DHCPv6

 

The pools configured on t= he NAS are not necessary to be the same. AAA server doesn't really need to = instruct the NAS the specified type of pools, which is already configured on the NAS. Right?

 

[RM] NAS can have many pools config= ured locally: how does the NAS know which pool is for SLAAC and which pool = is for DHCPv6?

 

Roberta

 

Best Regards,

Leaf

 

 

 

=B7=A2=BC=FE=C8=CB<= font color=3D"black" size=3D"2" face=3D"Tahoma">:<= /b> Maglione Roberta [roberta.maglione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1= =BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:27
=B5=BD= := Leaf yeh; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-= access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; = Wangshuxiang
=D6=F7=CC=E2<= /font>= : RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext sess= ion

Please see inli= ne.=

 <= /p>

Best regards,

Roberta<= /font>

 <= /p>

= From: Leaf yeh [mailto:leaf.y.yeh@huawei.com]
Sent: marted=A8=AC 26 lugli= o 2011 20.22
To: Maglione Roberta; 'Jacn= i Qin'
Cc: draft-ietf-radext-ipv6-= access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; = Wangshuxiang
Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<= /span>

 <= /p>

Roberta - If you use the s= ame attribute for both scenarios how does the NAS know if that pool is for = SLAAC or for Stateful DHCPv6?

NAS already has those pool names in its configuration, right?=

[RM] yes pools are already configur= ed in the NAS=

 

NAS does know which one is= for SLAAC prefix pool, which one is for DHCPv6 address pool. <= /font>

 

[RM] All the configured pools are t= he same for the NAS, in this case an extra logic would be needed to instruc= t the NAS about which pool is for SLAAC and which one is for DHCPv6

 

 

 

That=A1=AFs why in my opinion the S= tateful-IPv6-Address-Pool is required.

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB<= font color=3D"black" size=3D"2" face=3D"Tahoma">:<= /b> Maglione Roberta [roberta.maglione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1= =BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:13
=B5=BD= := 'Jacni Qin'
Cc: Leaf yeh; draft-ietf-ra= dext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com= ; Qiujin; Wangshuxiang
=D6=F7=CC=E2<= /font>= : RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext sess= ion=

Hi Jacni,
   If you use the same attribute for both scenarios how does the = NAS know if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mail= to:jacniq@gmail.com]
Sent: marted=A8=AC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session

Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.maglione@tele= comitalia.it> wrote:
Hello Leaf,
    The different attributes proposed in this draft for the = pools name have all the same format (a string), but semantically they are d= ifferent, as they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Beha= lf Of Leaf yeh
Sent: luned=A8=AC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0            &n= bsp;      1      &nb= sp;            2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |  &= nbsp; Length     |     String... +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi alt= ra azione derivante dalla conoscenza di queste informazioni sono rigorosame= nte vietate. Qualora abbiate ricevuto questo documento per errore siete cor= tesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. =

This e-mail and any attachments <= /i>is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni= sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per = errore siete cortesemente pregati di darne immediata comunicazione al mitte= nte e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks. 3D"rispe=Rispetta l'ambiente. No= n stampare questa mail se non =A8=A8 necessario.

--Boundary_(ID_P+ORJX74LpewiGptGKjIvA)-- --Boundary_(ID_ITUFOJQmyenezSW/dtU8EQ) Content-id: <4191B73-8F41-44277-AB1E-350C448994@MimeCtl> Content-type: application/octet-stream; name=%20 Content-transfer-encoding: base64 Content-disposition: inline; filename=%20; creation-date="Tue, 26 Jul 2011 20:51:42 GMT"; modification-date="Tue, 26 Jul 2011 20:51:42 GMT" Content-description: %20 --Boundary_(ID_ITUFOJQmyenezSW/dtU8EQ)-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 20:52:28 +0000 Date: Tue, 26 Jul 2011 20:51:42 +0000 From: Leaf yeh Subject: =?gb2312?B?tPC4tDogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYt?= =?gb2312?Q?access_after_IETF81_radext_session?= To: Maglione Roberta , 'Jacni Qin' Cc: "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Message-id: <53BB6F0B-2A09-49F7-BB3D-674D006F3BB5@mimectl> MIME-version: 1.0 Content-type: multipart/related; boundary="Boundary_(ID_ITUFOJQmyenezSW/dtU8EQ)"; type="multipart/alternative" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsP///hb8P//4L6o///A+qI= --Boundary_(ID_ITUFOJQmyenezSW/dtU8EQ) Content-type: multipart/alternative; boundary="Boundary_(ID_P+ORJX74LpewiGptGKjIvA)" --Boundary_(ID_P+ORJX74LpewiGptGKjIvA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 W1JNXSBOQVMgY2FuIGhhdmUgbWFueSBwb29scyBjb25maWd1cmVkIGxvY2FsbHk6IGhvdyBkb2Vz IHRoZSBOQVMga25vdyB3aGljaCBwb29sIGlzIGZvciBTTEFBQyBhbmQgd2hpY2ggcG9vbCBpcyBm b3IgREhDUHY2Pw0KDQoNCg0KSSBzdXBwb3NlZCB0aGUgbG9jYWwgY29uZmlndXJhdGlvbiBvbiB0 aGUgTkFTIHdpbGwgYW5zd2VyIHRoaXMgcXVlc3Rpb24uDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoN CkxlYWYNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQq3orz+ yMs6IE1hZ2xpb25lIFJvYmVydGEgW3JvYmVydGEubWFnbGlvbmVAdGVsZWNvbWl0YWxpYS5pdF0N Creiy83KsbzkOiAyMDExxOo31MIyN8jVIDM6NTQNCrW9OiBMZWFmIHllaDsgJ0phY25pIFFpbicN CkNjOiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVz ZXh0QG9wcy5pZXRmLm9yZzsgZmluZV9zekBodWF3ZWkuY29tOyBRaXVqaW47IFdhbmdzaHV4aWFu Zw0K1vfM4jogUkU6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vz cyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb24NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpGcm9tOiBMZWFmIHllaCBbbWFpbHRvOmxlYWYueS55ZWhAaHVhd2VpLmNv bV0NClNlbnQ6IG1hcnRlZKisIDI2IGx1Z2xpbyAyMDExIDIxLjUwDQpUbzogTWFnbGlvbmUgUm9i ZXJ0YTsgJ0phY25pIFFpbicNCkNjOiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29s cy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZzsgZmluZV9zekBodWF3ZWkuY29tOyBR aXVqaW47IFdhbmdzaHV4aWFuZw0KU3ViamVjdDogtPC4tDogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0 LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KDQoN CltSTV0gQWxsIHRoZSBjb25maWd1cmVkIHBvb2xzIGFyZSB0aGUgc2FtZSBmb3IgdGhlIE5BUywg aW4gdGhpcyBjYXNlIGFuIGV4dHJhIGxvZ2ljIHdvdWxkIGJlIG5lZWRlZCB0byBpbnN0cnVjdCB0 aGUgTkFTIGFib3V0IHdoaWNoIHBvb2wgaXMgZm9yIFNMQUFDIGFuZCB3aGljaCBvbmUgaXMgZm9y IERIQ1B2Ng0KDQoNCg0KVGhlIHBvb2xzIGNvbmZpZ3VyZWQgb24gdGhlIE5BUyBhcmUgbm90IG5l Y2Vzc2FyeSB0byBiZSB0aGUgc2FtZS4gQUFBIHNlcnZlciBkb2Vzbid0IHJlYWxseSBuZWVkIHRv IGluc3RydWN0IHRoZSBOQVMgdGhlIHNwZWNpZmllZCB0eXBlIG9mIHBvb2xzLCB3aGljaCBpcyBh bHJlYWR5IGNvbmZpZ3VyZWQgb24gdGhlIE5BUy4gUmlnaHQ/DQoNCg0KDQpbUk1dIE5BUyBjYW4g aGF2ZSBtYW55IHBvb2xzIGNvbmZpZ3VyZWQgbG9jYWxseTogaG93IGRvZXMgdGhlIE5BUyBrbm93 IHdoaWNoIHBvb2wgaXMgZm9yIFNMQUFDIGFuZCB3aGljaCBwb29sIGlzIGZvciBESENQdjY/DQoN Cg0KDQpSb2JlcnRhDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoNCkxlYWYNCg0KDQoNCg0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogTWFnbGlvbmUgUm9iZXJ0 YSBbcm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0XQ0Kt6LLzcqxvOQ6IDIwMTHE6jfU wjI3yNUgMjoyNw0Ktb06IExlYWYgeWVoOyAnSmFjbmkgUWluJw0KQ2M6IGRyYWZ0LWlldGYtcmFk ZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3JnOyBm aW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQrW98ziOiBSRTogUSBvbiBW ZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRl eHQgc2Vzc2lvbg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkJlc3QgcmVnYXJkcywNClJvYmVydGEN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IExlYWYgeWVoIFttYWls dG86bGVhZi55LnllaEBodWF3ZWkuY29tXQ0KU2VudDogbWFydGVkqKwgMjYgbHVnbGlvIDIwMTEg MjAuMjINClRvOiBNYWdsaW9uZSBSb2JlcnRhOyAnSmFjbmkgUWluJw0KQ2M6IGRyYWZ0LWlldGYt cmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3Jn OyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpTdWJqZWN0OiC08Li0 OiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3MgYWZ0ZXIgSUVU RjgxIHJhZGV4dCBzZXNzaW9uDQoNCg0KUm9iZXJ0YSAtIElmIHlvdSB1c2UgdGhlIHNhbWUgYXR0 cmlidXRlIGZvciBib3RoIHNjZW5hcmlvcyBob3cgZG9lcyB0aGUgTkFTIGtub3cgaWYgdGhhdCBw b29sIGlzIGZvciBTTEFBQyBvciBmb3IgU3RhdGVmdWwgREhDUHY2Pw0KDQpOQVMgYWxyZWFkeSBo YXMgdGhvc2UgcG9vbCBuYW1lcyBpbiBpdHMgY29uZmlndXJhdGlvbiwgcmlnaHQ/DQoNCltSTV0g eWVzIHBvb2xzIGFyZSBhbHJlYWR5IGNvbmZpZ3VyZWQgaW4gdGhlIE5BUw0KDQoNCg0KTkFTIGRv ZXMga25vdyB3aGljaCBvbmUgaXMgZm9yIFNMQUFDIHByZWZpeCBwb29sLCB3aGljaCBvbmUgaXMg Zm9yIERIQ1B2NiBhZGRyZXNzIHBvb2wuDQoNCg0KDQpbUk1dIEFsbCB0aGUgY29uZmlndXJlZCBw b29scyBhcmUgdGhlIHNhbWUgZm9yIHRoZSBOQVMsIGluIHRoaXMgY2FzZSBhbiBleHRyYSBsb2dp YyB3b3VsZCBiZSBuZWVkZWQgdG8gaW5zdHJ1Y3QgdGhlIE5BUyBhYm91dCB3aGljaCBwb29sIGlz IGZvciBTTEFBQyBhbmQgd2hpY2ggb25lIGlzIGZvciBESENQdjYNCg0KDQoNCg0KDQoNCg0KVGhh dKGvcyB3aHkgaW4gbXkgb3BpbmlvbiB0aGUgU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMg cmVxdWlyZWQuDQoNCg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpMZWFmDQoNCg0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogTWFnbGlvbmUgUm9iZXJ0YSBb cm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0XQ0Kt6LLzcqxvOQ6IDIwMTHE6jfUwjI3 yNUgMjoxMw0Ktb06ICdKYWNuaSBRaW4nDQpDYzogTGVhZiB5ZWg7IGRyYWZ0LWlldGYtcmFkZXh0 LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3JnOyBmaW5l X3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQrW98ziOiBSRTogUSBvbiBWZXIu LTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQg c2Vzc2lvbg0KSGkgSmFjbmksDQogICBJZiB5b3UgdXNlIHRoZSBzYW1lIGF0dHJpYnV0ZSBmb3Ig Ym90aCBzY2VuYXJpb3MgaG93IGRvZXMgdGhlIE5BUyBrbm93IGlmIHRoYXQgcG9vbCBpcyBmb3Ig U0xBQUMgb3IgZm9yIFN0YXRlZnVsIERIQ1B2Nj8NCg0KVGhhbmtzLA0KUmVnYXJkcywNClJvYmVy dGENCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpG cm9tOiBKYWNuaSBRaW4gW21haWx0bzpqYWNuaXFAZ21haWwuY29tXQ0KU2VudDogbWFydGVkqKwg MjYgbHVnbGlvIDIwMTEgMjAuMDMNClRvOiBNYWdsaW9uZSBSb2JlcnRhDQpDYzogTGVhZiB5ZWg7 IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRA b3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpT dWJqZWN0OiBSZTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNz IGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KDQpIaSBSb2JlcnRhLA0KDQpJIGFncmVlIHdp dGggeW91IGFib3V0IHRoZSBzZW1hbnRpY2FsIGxvZ2ljLCB3aGlsZSAiU3RhdGVmdWwtSVB2Ni1B ZGRyZXNzLVBvb2wiIGlzIG5vdCBuZWNlc3NhcnksIElNSE8uDQoNCg0KQ2hlZXJzLA0KSmFjbmkN Ck9uIFdlZCwgSnVsIDI3LCAyMDExIGF0IDE6NTUgQU0sIE1hZ2xpb25lIFJvYmVydGEgPHJvYmVy dGEubWFnbGlvbmVAdGVsZWNvbWl0YWxpYS5pdD4gd3JvdGU6DQpIZWxsbyBMZWFmLA0KICAgIFRo ZSBkaWZmZXJlbnQgYXR0cmlidXRlcyBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0IGZvciB0aGUgcG9v bHMgbmFtZSBoYXZlIGFsbCB0aGUgc2FtZSBmb3JtYXQgKGEgc3RyaW5nKSwgYnV0IHNlbWFudGlj YWxseSB0aGV5IGFyZSBkaWZmZXJlbnQsIGFzIHRoZXkgY292ZWQgZGlmZmVyZW50IHNjZW5hcmlv cy4NCkFzIHlvdSBhbHNvIHN1bW1hcml6ZWQgaW4geW91ciBlbWFpbCBiZWxvdywNCg0KRnJhbWVk LVBvb2wgd2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NCBhZGRyZXNzIHBvb2w7DQpGcmFtZWQtSVB2 Ni1Qb29sIHdhcyBkZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xBQUMgcHJlZml4IHBvb2w7DQpEZWxl Z2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2LVBEIHByZWZpeCBw b29sOw0KU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgZGVzaWduZWQgZm9yIERIQ1B2NiBh ZGRyZXNzIHBvb2w7DQoNClNvIGVhY2ggYXR0cmlidXRlIGNvdmVycyBhIGRpZmZlcmVudCB1c2Ut Y2FzZS9zY2VuYXJpbyBhbmQgdGhleSBjYW4gYXBwZWFyIGluIHRoZSBzYW1lIFJBRElVUyBwYWNr ZXQgYXQgdGhlIHNhbWUgdGltZS4NCklmIHlvdSB3YW50IHRvIHVzZSBhIHNpbmdsZSBwb29sIG5h bWUgdXNlIHRvIGNvdmVyIGFsbCB0aGUgNCB1c2UgY2FzZXMgbGlzdGVkIGFib3ZlLCB5b3Ugd291 bGQgYWxzbyBuZWVkIHRvIGRlZmluZSBhIHN0YW5kYXJkIGZvcm1hdC9zeW50YXggZm9yIHRoZSBw b29sIG5hbWUgdGhhdCBhbGxvd3MgdGhlIE5BUyB0byBiZSBhYmxlIHRvIGRpc2FtYmlndWF0ZSBh bW9uZyB0aGUgZGlmZmVyZW50IHNjZW5hcmlvcyBhbmQgaW4gb3JkZXIgdG8gZG8gdGhhdCB0aGUg TkFTIHdvdWxkIG5lZWQgdG8gaGF2ZSBhbiBleHRyYSBsb2dpYyB0byBpbmZlciB0aGUgc2VtYW50 aWMgb2YgdGhhdCBzcGVjaWZpYyBhdHRyaWJ1dGUgZnJvbSB0aGUgYXNzaWduZWQgbmFtZS4NCklu c3RlYWQgaWYgeW91IGhhdmUgYSBzcGVjaWZpYyBhdHRyaWJ1dGUgZm9yIGVhY2ggc3BlY2lmaWMg c2NlbmFyaW8sIHRoZSBzZW1hbnRpYyBpcyBtYXBwZWQgdG8gdGhlIGF0dHJpYnV0ZSBuYW1lLCB0 aHVzIHRoZSBOQVMgZG9lcyBub3QgbmVlZCBhbiBleHRyYSBsb2dpYyB0byBkaXNjb3ZlcnkgdGhl IHB1cnBvc2Ugb2YgdGhhdCBwb29sIGFuZCB0aGUgcG9vbCBuYW1lIGNhbiBiZSBhbnkgc3RyaW5n LCBubyBsaW1pdGF0aW9uIG9yIHNwZWNpYWwgc3ludGF4IGlzIGZvcmNlZCBmb3IgdGhlIHBvb2wg bmFtZS4NCg0KDQpUaGFua3MsDQpSZWdhcmRzLA0KUm9iZXJ0YQ0KDQoNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IG93bmVyLXJhZGl1c2V4dEBv cHMuaWV0Zi5vcmcgW21haWx0bzpvd25lci1yYWRpdXNleHRAb3BzLmlldGYub3JnXSBPbiBCZWhh bGYgT2YgTGVhZiB5ZWgNClNlbnQ6IGx1bmVkqKwgMjUgbHVnbGlvIDIwMTEgMTguMjMNClRvOiBk cmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9w cy5pZXRmLm9yZw0KQ2M6IGZpbmVfc3pAaHVhd2VpLmNvbTsgUWl1amluOyBXYW5nc2h1eGlhbmcN ClN1YmplY3Q6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2VzcyBh ZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb24NCg0KUXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb246 DQoNCldlIGFscmVhZHkgaGF2ZSB0aGUgZm9sbG93aW5nIFJhZGl1cyBBdHRyaWJ1dGVzIGZvciB0 aGUgYWRkcmVzcy9wcmVmaXggcG9vbHM6DQoNCkZyYW1lZC1Qb29sICg4OCwgc2VjdGlvbiA1LjE4 IG9mIFJGQzI4NjkpLA0KRnJhbWVkLUlQdjYtUG9vbCAoMTAwLCBzZWN0aW9uIDIuNiBvZiBSRkMz MTYyKS4NCg0KaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9yYWRpdXMtdHlwZXMvcmFk aXVzLXR5cGVzLnhtbA0KDQpUaGUgZm9yYW10IGFyZSB0aGUgc2FtZSBhcyBmb2xsb3dzOg0KDQow ICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMg0KMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMNCistKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCnwgICAgIFR5cGUgICAgICB8ICAgIExlbmd0aCAg ICAgfCAgICAgU3RyaW5nLi4uDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQoNCmRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLTA1IGlzIHByb3Bv c2luZyAyIG5ldyBhdHRyaWJ1dGVzIGZvciBhZGRyZXNzL3ByZWZpeCBwb29sczoNCg0KRGVsZWdh dGVkLUlQdjYtUHJlZml4LVBvb2wsDQpTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCwNCg0KdGhl IGZvbWF0IG9mIHRoZXNlIDIgYXR0cmlidXRlcyBhcmUgdGhlIHNhbWUgYXMgdGhlIGFib3ZlIG9u ZS4NCg0KDQpTdXBwb3NlZCB0aGUgYWJvdmUgYXR0cmlidXRlcyBjb3VsZCBiZSBleHBsYWluZWQg YXMgZm9sbG93czoNCg0KRnJhbWVkLVBvb2wgd2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NCBhZGRy ZXNzIHBvb2w7DQpGcmFtZWQtSVB2Ni1Qb29sIHdhcyBkZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xB QUMgcHJlZml4IHBvb2w7DQpEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBm b3IgREhDUHY2LVBEIHByZWZpeCBwb29sOw0KU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMg ZGVzaWduZWQgZm9yIERIQ1B2NiBhZGRyZXNzIHBvb2w7DQoNCkFsbCBhYm92ZSBhdHRyaWJ1dGVz IGFyZSBvbmx5IHVzZWQgdG8gcHJvdmlkZSB0aGUgbmFtZSBvZiB0aGUgYWRkcmVzcy9wcmVmaXgg cG9vbHMgaW4gYSAnc3RyaW5nJy4gSSBkb3VidCB0aGUgbmVjZXNzaXR5IHRvIG1ha2Ugc28gbWFu eSAnbmFtZScgb3IgJ3N0cmluZycgYXR0cmlidXRlcyBmb3IgdGhlIGRpZmZlcmVudCBhZGRyZXNz L3ByZWZpeCBwb29scyB0byBwcmV2ZW50IHRoZSBhbWJpZ3VpdHkuIEkgZ3Vlc3MgMSBhdHRyaWJ1 dGUgZm9yIHRoZSBuYW1lIG9mIHRoZSBhZGRyZXNzL3ByZWZpeCBwb29scyBtaWdodCBiZSBlbm91 Z2guIEluIGZhY3QsIHRoZSBOQVMgdGFrZSB0aGUgcm9sZSB0byBpbnRlcnByZXQgdGhlIG1lYW5p bmcgb2YgdGhlIHBvb2sgbmFtZSwgcmlnaHQ/DQoNCkkgdGhpbmsgRnJhbWVkLVBvb2wgY2FuIGJl IHJlLXVzZWQgZm9yIHRoZSBkZXNpZ24gcHVycG9zZSBvZiBTdGF0ZWZ1bC1JUHY2LUFkZHJlc3Mt UG9vbC4gRG8gd2UgaGF2ZSBhbnkgbGltaXRhdGlvbiBvbiB0aGUgdXNhZ2Ugb2YgRnJhbWVkLVBv b2wgZm9yIElQdjY/DQpJIHRoaW5rIEZyYW1lZC1JUHY2LVBvb2wgY2FuIGJlIHJlLXVzZWQgZm9y IHRoZSBkZXNpZ24gcHVycG9zZSBvZiBEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCB0byBpbmRp Y2F0ZSBhIHBvb2wgb2YgSVB2NiBwcmVmaXggcG9vbC4gSSBjb3VsZCBldmVuIHRoaW5rIEZyYW1l ZC1Qb29sIGNhbiByZXBsYWNlIEZyYW1lZC1JUHY2LVBvb2wgdG8gaW5kaWNhdGUgdGhlIG5hbWUg b2YgYSBJUHY2IHByZWZpeC9hZGRyZXNzIHBvb2wgcGVyIHRoZSBzYW1lIGxvZ2ljLiBBbSBJIHJp Z2h0Pw0KDQoNCkJlc3QgUmVnYXJkcywNCkxlYWYNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClF1 ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNp dmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVh bHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUg aW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUg cmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBw cmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkg cHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KVGhpcyBlLW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2Vt aW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1 dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2Vu ZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NClJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBz dGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gqKggbmVjZXNzYXJpby4NCg0KDQpRdWVzdG8gbWVz c2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUg YWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBh bHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6 aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRv IHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBk aSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRl cmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlv biwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlz ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5 IHJldHVybiBlLW1haWwsIFRoYW5rcy4NClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdh dGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUu IExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUg ZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50 ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIg ZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211 bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9u ZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVu dGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3Ig dGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBv ciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBh dHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtz Lg0KW3Jpc3BldHRhIGwnYW1iaWVudGVdUmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJl IHF1ZXN0YSBtYWlsIHNlIG5vbiCoqCBuZWNlc3NhcmlvLg0KDQoNClF1ZXN0byBtZXNzYWdnaW8g ZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBl cnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6 aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNv bm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3Rv IGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5l IGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxh IHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlv biBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5 aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJu IGUtbWFpbCwgVGhhbmtzLg0KDQpbcmlzcGV0dGEgbCdhbWJpZW50ZV1SaXNwZXR0YSBsJ2FtYmll bnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIKioIG5lY2Vzc2FyaW8uDQoNCg== --Boundary_(ID_P+ORJX74LpewiGptGKjIvA) Content-id: <5D310CAD16147C4EADB0D759F5D3F12A@huawei.com> Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

[RM] NAS can have many pools config= ured locally: how does the NAS know which pool is for SLAAC and which pool = is for DHCPv6?

 

I supposed the local configuration on the NAS will answer this question.=

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB: Maglione Roberta [robe= rta.maglione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 3:54
=B5=BD: Leaf yeh; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf= .org; fine_sz@huawei.com; Qiujin; Wangshuxiang
=D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access afte= r IETF81 radext session

&= nbsp;

&= nbsp;

From:= Leaf yeh [mailto:leaf.y.yeh@huawei.com]
Sent: marted=A8=AC 26 lugli= o 2011 21.50
To: Maglione Roberta; 'Jacn= i Qin'
Cc: draft-ietf-radext-ipv6-= access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; = Wangshuxiang
Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

 

[RM] All the configured pools are t= he same for the NAS, in this case an extra logic would be needed to instruc= t the NAS about which pool is for SLAAC and which one is for DHCPv6

 

The pools configured on t= he NAS are not necessary to be the same. AAA server doesn't really need to = instruct the NAS the specified type of pools, which is already configured on the NAS. Right?

 

[RM] NAS can have many pools config= ured locally: how does the NAS know which pool is for SLAAC and which pool = is for DHCPv6?

 

Roberta

 

Best Regards,

Leaf

 

 

 

=B7=A2=BC=FE=C8=CB<= font color=3D"black" size=3D"2" face=3D"Tahoma">:<= /b> Maglione Roberta [roberta.maglione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1= =BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:27
=B5=BD= := Leaf yeh; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-= access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; = Wangshuxiang
=D6=F7=CC=E2<= /font>= : RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext sess= ion

Please see inli= ne.=

 <= /p>

Best regards,

Roberta<= /font>

 <= /p>

= From: Leaf yeh [mailto:leaf.y.yeh@huawei.com]
Sent: marted=A8=AC 26 lugli= o 2011 20.22
To: Maglione Roberta; 'Jacn= i Qin'
Cc: draft-ietf-radext-ipv6-= access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; = Wangshuxiang
Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<= /span>

 <= /p>

Roberta - If you use the s= ame attribute for both scenarios how does the NAS know if that pool is for = SLAAC or for Stateful DHCPv6?

NAS already has those pool names in its configuration, right?=

[RM] yes pools are already configur= ed in the NAS=

 

NAS does know which one is= for SLAAC prefix pool, which one is for DHCPv6 address pool. <= /font>

 

[RM] All the configured pools are t= he same for the NAS, in this case an extra logic would be needed to instruc= t the NAS about which pool is for SLAAC and which one is for DHCPv6

 

 

 

That=A1=AFs why in my opinion the S= tateful-IPv6-Address-Pool is required.

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB<= font color=3D"black" size=3D"2" face=3D"Tahoma">:<= /b> Maglione Roberta [roberta.maglione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1= =BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:13
=B5=BD= := 'Jacni Qin'
Cc: Leaf yeh; draft-ietf-ra= dext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com= ; Qiujin; Wangshuxiang
=D6=F7=CC=E2<= /font>= : RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext sess= ion=

Hi Jacni,
   If you use the same attribute for both scenarios how does the = NAS know if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mail= to:jacniq@gmail.com]
Sent: marted=A8=AC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session

Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.maglione@tele= comitalia.it> wrote:
Hello Leaf,
    The different attributes proposed in this draft for the = pools name have all the same format (a string), but semantically they are d= ifferent, as they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Beha= lf Of Leaf yeh
Sent: luned=A8=AC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0            &n= bsp;      1      &nb= sp;            2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |  &= nbsp; Length     |     String... +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi alt= ra azione derivante dalla conoscenza di queste informazioni sono rigorosame= nte vietate. Qualora abbiate ricevuto questo documento per errore siete cor= tesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. =

This e-mail and any attachments <= /i>is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

 

Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni= sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per = errore siete cortesemente pregati di darne immediata comunicazione al mitte= nte e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks. 3D"rispe=Rispetta l'ambiente. No= n stampare questa mail se non =A8=A8 necessario.

--Boundary_(ID_P+ORJX74LpewiGptGKjIvA)-- --Boundary_(ID_ITUFOJQmyenezSW/dtU8EQ) Content-id: <4191B73-8F41-44277-AB1E-350C448994@MimeCtl> Content-type: application/octet-stream; name=%20 Content-transfer-encoding: base64 Content-disposition: inline; filename=%20; creation-date="Tue, 26 Jul 2011 20:51:42 GMT"; modification-date="Tue, 26 Jul 2011 20:51:42 GMT" Content-description: %20 --Boundary_(ID_ITUFOJQmyenezSW/dtU8EQ)-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 19:55:12 +0000 Content-Type: multipart/mixed; boundary="_0a86fb72-cc1b-42cb-97a9-499601ef85ef_" From: Maglione Roberta To: Leaf yeh , 'Jacni Qin' CC: "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Date: Tue, 26 Jul 2011 21:54:50 +0200 Subject: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsP///hb8A== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5B@GRFMBX704BA020.griffon.local> Accept-Language: en-US, it-IT Content-Language: en-US acceptlanguage: en-US, it-IT MIME-Version: 1.0 --_0a86fb72-cc1b-42cb-97a9-499601ef85ef_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5BGRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5BGRFMBX704BA02_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBMZWFmIHllaCBbbWFp bHRvOmxlYWYueS55ZWhAaHVhd2VpLmNvbV0NClNlbnQ6IG1hcnRlZKisIDI2IGx1Z2xpbyAyMDEx IDIxLjUwDQpUbzogTWFnbGlvbmUgUm9iZXJ0YTsgJ0phY25pIFFpbicNCkNjOiBkcmFmdC1pZXRm LXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9y ZzsgZmluZV9zekBodWF3ZWkuY29tOyBRaXVqaW47IFdhbmdzaHV4aWFuZw0KU3ViamVjdDogtPC4 tDogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElF VEY4MSByYWRleHQgc2Vzc2lvbg0KDQoNCltSTV0gQWxsIHRoZSBjb25maWd1cmVkIHBvb2xzIGFy ZSB0aGUgc2FtZSBmb3IgdGhlIE5BUywgaW4gdGhpcyBjYXNlIGFuIGV4dHJhIGxvZ2ljIHdvdWxk IGJlIG5lZWRlZCB0byBpbnN0cnVjdCB0aGUgTkFTIGFib3V0IHdoaWNoIHBvb2wgaXMgZm9yIFNM QUFDIGFuZCB3aGljaCBvbmUgaXMgZm9yIERIQ1B2Ng0KDQoNCg0KVGhlIHBvb2xzIGNvbmZpZ3Vy ZWQgb24gdGhlIE5BUyBhcmUgbm90IG5lY2Vzc2FyeSB0byBiZSB0aGUgc2FtZS4gQUFBIHNlcnZl ciBkb2Vzbid0IHJlYWxseSBuZWVkIHRvIGluc3RydWN0IHRoZSBOQVMgdGhlIHNwZWNpZmllZCB0 eXBlIG9mIHBvb2xzLCB3aGljaCBpcyBhbHJlYWR5IGNvbmZpZ3VyZWQgb24gdGhlIE5BUy4gUmln aHQ/DQoNCg0KDQpbUk1dIE5BUyBjYW4gaGF2ZSBtYW55IHBvb2xzIGNvbmZpZ3VyZWQgbG9jYWxs eTogaG93IGRvZXMgdGhlIE5BUyBrbm93IHdoaWNoIHBvb2wgaXMgZm9yIFNMQUFDIGFuZCB3aGlj aCBwb29sIGlzIGZvciBESENQdjY/DQoNCg0KDQpSb2JlcnRhDQoNCg0KDQpCZXN0IFJlZ2FyZHMs DQoNCkxlYWYNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CreivP7IyzogTWFnbGlvbmUgUm9iZXJ0YSBbcm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlh Lml0XQ0Kt6LLzcqxvOQ6IDIwMTHE6jfUwjI3yNUgMjoyNw0Ktb06IExlYWYgeWVoOyAnSmFjbmkg UWluJw0KQ2M6IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyBy YWRpdXNleHRAb3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3No dXhpYW5nDQrW98ziOiBSRTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYt YWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoN CkJlc3QgcmVnYXJkcywNClJvYmVydGENCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkZyb206IExlYWYgeWVoIFttYWlsdG86bGVhZi55LnllaEBodWF3ZWkuY29tXQ0KU2VudDog bWFydGVkqKwgMjYgbHVnbGlvIDIwMTEgMjAuMjINClRvOiBNYWdsaW9uZSBSb2JlcnRhOyAnSmFj bmkgUWluJw0KQ2M6IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3Jn OyByYWRpdXNleHRAb3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2Fu Z3NodXhpYW5nDQpTdWJqZWN0OiC08Li0OiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRl eHQtaXB2Ni1hY2Nlc3MgYWZ0ZXIgSUVURjgxIHJhZGV4dCBzZXNzaW9uDQoNCg0KUm9iZXJ0YSAt IElmIHlvdSB1c2UgdGhlIHNhbWUgYXR0cmlidXRlIGZvciBib3RoIHNjZW5hcmlvcyBob3cgZG9l cyB0aGUgTkFTIGtub3cgaWYgdGhhdCBwb29sIGlzIGZvciBTTEFBQyBvciBmb3IgU3RhdGVmdWwg REhDUHY2Pw0KDQpOQVMgYWxyZWFkeSBoYXMgdGhvc2UgcG9vbCBuYW1lcyBpbiBpdHMgY29uZmln dXJhdGlvbiwgcmlnaHQ/DQoNCltSTV0geWVzIHBvb2xzIGFyZSBhbHJlYWR5IGNvbmZpZ3VyZWQg aW4gdGhlIE5BUw0KDQoNCg0KTkFTIGRvZXMga25vdyB3aGljaCBvbmUgaXMgZm9yIFNMQUFDIHBy ZWZpeCBwb29sLCB3aGljaCBvbmUgaXMgZm9yIERIQ1B2NiBhZGRyZXNzIHBvb2wuDQoNCg0KDQpb Uk1dIEFsbCB0aGUgY29uZmlndXJlZCBwb29scyBhcmUgdGhlIHNhbWUgZm9yIHRoZSBOQVMsIGlu IHRoaXMgY2FzZSBhbiBleHRyYSBsb2dpYyB3b3VsZCBiZSBuZWVkZWQgdG8gaW5zdHJ1Y3QgdGhl IE5BUyBhYm91dCB3aGljaCBwb29sIGlzIGZvciBTTEFBQyBhbmQgd2hpY2ggb25lIGlzIGZvciBE SENQdjYNCg0KDQoNCg0KDQoNCg0KVGhhdKGvcyB3aHkgaW4gbXkgb3BpbmlvbiB0aGUgU3RhdGVm dWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgcmVxdWlyZWQuDQoNCg0KDQoNCg0KQmVzdCBSZWdhcmRz LA0KDQpMZWFmDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCrei vP7IyzogTWFnbGlvbmUgUm9iZXJ0YSBbcm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0 XQ0Kt6LLzcqxvOQ6IDIwMTHE6jfUwjI3yNUgMjoxMw0Ktb06ICdKYWNuaSBRaW4nDQpDYzogTGVh ZiB5ZWg7IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRp dXNleHRAb3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhp YW5nDQrW98ziOiBSRTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNj ZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KSGkgSmFjbmksDQogICBJZiB5b3UgdXNl IHRoZSBzYW1lIGF0dHJpYnV0ZSBmb3IgYm90aCBzY2VuYXJpb3MgaG93IGRvZXMgdGhlIE5BUyBr bm93IGlmIHRoYXQgcG9vbCBpcyBmb3IgU0xBQUMgb3IgZm9yIFN0YXRlZnVsIERIQ1B2Nj8NCg0K VGhhbmtzLA0KUmVnYXJkcywNClJvYmVydGENCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBKYWNuaSBRaW4gW21haWx0bzpqYWNuaXFAZ21h aWwuY29tXQ0KU2VudDogbWFydGVkqKwgMjYgbHVnbGlvIDIwMTEgMjAuMDMNClRvOiBNYWdsaW9u ZSBSb2JlcnRhDQpDYzogTGVhZiB5ZWg7IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRv b2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207 IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpTdWJqZWN0OiBSZTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0 LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KDQpI aSBSb2JlcnRhLA0KDQpJIGFncmVlIHdpdGggeW91IGFib3V0IHRoZSBzZW1hbnRpY2FsIGxvZ2lj LCB3aGlsZSAiU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wiIGlzIG5vdCBuZWNlc3NhcnksIElN SE8uDQoNCg0KQ2hlZXJzLA0KSmFjbmkNCk9uIFdlZCwgSnVsIDI3LCAyMDExIGF0IDE6NTUgQU0s IE1hZ2xpb25lIFJvYmVydGEgPHJvYmVydGEubWFnbGlvbmVAdGVsZWNvbWl0YWxpYS5pdD4gd3Jv dGU6DQpIZWxsbyBMZWFmLA0KICAgIFRoZSBkaWZmZXJlbnQgYXR0cmlidXRlcyBwcm9wb3NlZCBp biB0aGlzIGRyYWZ0IGZvciB0aGUgcG9vbHMgbmFtZSBoYXZlIGFsbCB0aGUgc2FtZSBmb3JtYXQg KGEgc3RyaW5nKSwgYnV0IHNlbWFudGljYWxseSB0aGV5IGFyZSBkaWZmZXJlbnQsIGFzIHRoZXkg Y292ZWQgZGlmZmVyZW50IHNjZW5hcmlvcy4NCkFzIHlvdSBhbHNvIHN1bW1hcml6ZWQgaW4geW91 ciBlbWFpbCBiZWxvdywNCg0KRnJhbWVkLVBvb2wgd2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NCBh ZGRyZXNzIHBvb2w7DQpGcmFtZWQtSVB2Ni1Qb29sIHdhcyBkZXNpZ25lZCBmb3IgdGhlIElQdjYg U0xBQUMgcHJlZml4IHBvb2w7DQpEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCBpcyBkZXNpZ25l ZCBmb3IgREhDUHY2LVBEIHByZWZpeCBwb29sOw0KU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wg aXMgZGVzaWduZWQgZm9yIERIQ1B2NiBhZGRyZXNzIHBvb2w7DQoNClNvIGVhY2ggYXR0cmlidXRl IGNvdmVycyBhIGRpZmZlcmVudCB1c2UtY2FzZS9zY2VuYXJpbyBhbmQgdGhleSBjYW4gYXBwZWFy IGluIHRoZSBzYW1lIFJBRElVUyBwYWNrZXQgYXQgdGhlIHNhbWUgdGltZS4NCklmIHlvdSB3YW50 IHRvIHVzZSBhIHNpbmdsZSBwb29sIG5hbWUgdXNlIHRvIGNvdmVyIGFsbCB0aGUgNCB1c2UgY2Fz ZXMgbGlzdGVkIGFib3ZlLCB5b3Ugd291bGQgYWxzbyBuZWVkIHRvIGRlZmluZSBhIHN0YW5kYXJk IGZvcm1hdC9zeW50YXggZm9yIHRoZSBwb29sIG5hbWUgdGhhdCBhbGxvd3MgdGhlIE5BUyB0byBi ZSBhYmxlIHRvIGRpc2FtYmlndWF0ZSBhbW9uZyB0aGUgZGlmZmVyZW50IHNjZW5hcmlvcyBhbmQg aW4gb3JkZXIgdG8gZG8gdGhhdCB0aGUgTkFTIHdvdWxkIG5lZWQgdG8gaGF2ZSBhbiBleHRyYSBs b2dpYyB0byBpbmZlciB0aGUgc2VtYW50aWMgb2YgdGhhdCBzcGVjaWZpYyBhdHRyaWJ1dGUgZnJv bSB0aGUgYXNzaWduZWQgbmFtZS4NCkluc3RlYWQgaWYgeW91IGhhdmUgYSBzcGVjaWZpYyBhdHRy aWJ1dGUgZm9yIGVhY2ggc3BlY2lmaWMgc2NlbmFyaW8sIHRoZSBzZW1hbnRpYyBpcyBtYXBwZWQg dG8gdGhlIGF0dHJpYnV0ZSBuYW1lLCB0aHVzIHRoZSBOQVMgZG9lcyBub3QgbmVlZCBhbiBleHRy YSBsb2dpYyB0byBkaXNjb3ZlcnkgdGhlIHB1cnBvc2Ugb2YgdGhhdCBwb29sIGFuZCB0aGUgcG9v bCBuYW1lIGNhbiBiZSBhbnkgc3RyaW5nLCBubyBsaW1pdGF0aW9uIG9yIHNwZWNpYWwgc3ludGF4 IGlzIGZvcmNlZCBmb3IgdGhlIHBvb2wgbmFtZS4NCg0KDQpUaGFua3MsDQpSZWdhcmRzLA0KUm9i ZXJ0YQ0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IG93bmVyLXJhZGl1c2V4dEBvcHMuaWV0Zi5vcmcgW21haWx0bzpvd25lci1yYWRpdXNl eHRAb3BzLmlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGVhZiB5ZWgNClNlbnQ6IGx1bmVkqKwgMjUg bHVnbGlvIDIwMTEgMTguMjMNClRvOiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29s cy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZw0KQ2M6IGZpbmVfc3pAaHVhd2VpLmNv bTsgUWl1amluOyBXYW5nc2h1eGlhbmcNClN1YmplY3Q6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1p ZXRmLXJhZGV4dC1pcHY2LWFjY2VzcyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb24NCg0KUXVl c3Rpb24gZm9yIGNsYXJpZmljYXRpb246DQoNCldlIGFscmVhZHkgaGF2ZSB0aGUgZm9sbG93aW5n IFJhZGl1cyBBdHRyaWJ1dGVzIGZvciB0aGUgYWRkcmVzcy9wcmVmaXggcG9vbHM6DQoNCkZyYW1l ZC1Qb29sICg4OCwgc2VjdGlvbiA1LjE4IG9mIFJGQzI4NjkpLA0KRnJhbWVkLUlQdjYtUG9vbCAo MTAwLCBzZWN0aW9uIDIuNiBvZiBSRkMzMTYyKS4NCg0KaHR0cDovL3d3dy5pYW5hLm9yZy9hc3Np Z25tZW50cy9yYWRpdXMtdHlwZXMvcmFkaXVzLXR5cGVzLnhtbA0KDQpUaGUgZm9yYW10IGFyZSB0 aGUgc2FtZSBhcyBmb2xsb3dzOg0KDQowICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAg ICAgICAgMg0KMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMN CistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCnwgICAg IFR5cGUgICAgICB8ICAgIExlbmd0aCAgICAgfCAgICAgU3RyaW5nLi4uDQorLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCmRyYWZ0LWlldGYtcmFkZXh0 LWlwdjYtYWNjZXNzLTA1IGlzIHByb3Bvc2luZyAyIG5ldyBhdHRyaWJ1dGVzIGZvciBhZGRyZXNz L3ByZWZpeCBwb29sczoNCg0KRGVsZWdhdGVkLUlQdjYtUHJlZml4LVBvb2wsDQpTdGF0ZWZ1bC1J UHY2LUFkZHJlc3MtUG9vbCwNCg0KdGhlIGZvbWF0IG9mIHRoZXNlIDIgYXR0cmlidXRlcyBhcmUg dGhlIHNhbWUgYXMgdGhlIGFib3ZlIG9uZS4NCg0KDQpTdXBwb3NlZCB0aGUgYWJvdmUgYXR0cmli dXRlcyBjb3VsZCBiZSBleHBsYWluZWQgYXMgZm9sbG93czoNCg0KRnJhbWVkLVBvb2wgd2FzIGRl c2lnbmVkIGZvciB0aGUgSVB2NCBhZGRyZXNzIHBvb2w7DQpGcmFtZWQtSVB2Ni1Qb29sIHdhcyBk ZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xBQUMgcHJlZml4IHBvb2w7DQpEZWxlZ2F0ZWQtSVB2Ni1Q cmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2LVBEIHByZWZpeCBwb29sOw0KU3RhdGVm dWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgZGVzaWduZWQgZm9yIERIQ1B2NiBhZGRyZXNzIHBvb2w7 DQoNCkFsbCBhYm92ZSBhdHRyaWJ1dGVzIGFyZSBvbmx5IHVzZWQgdG8gcHJvdmlkZSB0aGUgbmFt ZSBvZiB0aGUgYWRkcmVzcy9wcmVmaXggcG9vbHMgaW4gYSAnc3RyaW5nJy4gSSBkb3VidCB0aGUg bmVjZXNzaXR5IHRvIG1ha2Ugc28gbWFueSAnbmFtZScgb3IgJ3N0cmluZycgYXR0cmlidXRlcyBm b3IgdGhlIGRpZmZlcmVudCBhZGRyZXNzL3ByZWZpeCBwb29scyB0byBwcmV2ZW50IHRoZSBhbWJp Z3VpdHkuIEkgZ3Vlc3MgMSBhdHRyaWJ1dGUgZm9yIHRoZSBuYW1lIG9mIHRoZSBhZGRyZXNzL3By ZWZpeCBwb29scyBtaWdodCBiZSBlbm91Z2guIEluIGZhY3QsIHRoZSBOQVMgdGFrZSB0aGUgcm9s ZSB0byBpbnRlcnByZXQgdGhlIG1lYW5pbmcgb2YgdGhlIHBvb2sgbmFtZSwgcmlnaHQ/DQoNCkkg dGhpbmsgRnJhbWVkLVBvb2wgY2FuIGJlIHJlLXVzZWQgZm9yIHRoZSBkZXNpZ24gcHVycG9zZSBv ZiBTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbC4gRG8gd2UgaGF2ZSBhbnkgbGltaXRhdGlvbiBv biB0aGUgdXNhZ2Ugb2YgRnJhbWVkLVBvb2wgZm9yIElQdjY/DQpJIHRoaW5rIEZyYW1lZC1JUHY2 LVBvb2wgY2FuIGJlIHJlLXVzZWQgZm9yIHRoZSBkZXNpZ24gcHVycG9zZSBvZiBEZWxlZ2F0ZWQt SVB2Ni1QcmVmaXgtUG9vbCB0byBpbmRpY2F0ZSBhIHBvb2wgb2YgSVB2NiBwcmVmaXggcG9vbC4g SSBjb3VsZCBldmVuIHRoaW5rIEZyYW1lZC1Qb29sIGNhbiByZXBsYWNlIEZyYW1lZC1JUHY2LVBv b2wgdG8gaW5kaWNhdGUgdGhlIG5hbWUgb2YgYSBJUHY2IHByZWZpeC9hZGRyZXNzIHBvb2wgcGVy IHRoZSBzYW1lIGxvZ2ljLiBBbSBJIHJpZ2h0Pw0KDQoNCkJlc3QgUmVnYXJkcywNCkxlYWYNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkg c29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExh IGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFs bGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2 aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJy b3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmlj YXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwg R3JhemllLg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwg YW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBh ZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNl IGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNo bWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NClJp c3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gqKggbmVj ZXNzYXJpby4NCg0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5k aXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNp b25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9z Y2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4g UXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0 ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBh bCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4N Cg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1h eSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNz ZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFu eWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMg YW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NClF1ZXN0byBt ZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50 ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNp IGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3Jt YXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1 dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRp IGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZl ZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55 IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0 aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9y aXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIg YnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KWyUyMF1SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24g c3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIKioIG5lY2Vzc2FyaW8uDQoNCg0KUXVlc3RvIG1l c3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRl IGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kg YWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1h emlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0 byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkg ZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVk ZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRp b24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jp c2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBi eSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQoNCltjaWQ6MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDFAVEkuRGlzY2xhaW1lcl1SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUg cXVlc3RhIG1haWwgc2Ugbm9uIKioIG5lY2Vzc2FyaW8uDQoNCg== --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5BGRFMBX704BA02_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

 

 

From: Leaf yeh [mailto:leaf.y.yeh@hu= awei.com]
Sent: marted=A8=AC 26 luglio= 2011 21.50
To: Maglione Roberta; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

 

[RM] All the configured pools are the same for the NAS, i= n this case an extra logic would be needed to instruct the NAS about which = pool is for SLAAC and which one is for DHCPv6

 

The pools configured on the NAS are not necessa= ry to be the same. AAA server doesn't really need to instruct the NAS the s= pecified type of pools, which is already configured on the NAS. Right?

 

[RM] NAS can have many pools configured locally: how does= the NAS know which pool is for SLAAC and which pool is for DHCPv6?

 

Roberta

 

Best Regards,

Leaf

 

 

 

=B7=A2=BC=FE=C8=CB: Maglione Roberta [roberta.magl= ione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1=BC=E4= : 2011=C4=EA7=D4=C227=C8=D5 2:27
=B5=BD: Leaf yeh; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
=D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext sess= ion

Please see inline.

 

Best regards,

Roberta

 

= From: Leaf yeh [mailto:leaf.y.yeh@hu= awei.com]
Sent: marted=A8=AC 26 luglio= 2011 20.22
To: Maglione Roberta; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<= /span><= /span>

 

Roberta - If you use the same attribut= e for both scenarios how does the NAS know if that pool is for SLAAC or for= Stateful DHCPv6?

NAS already has those pool names in its configuration, right?

[RM] yes pools are already configured in the NAS

 

NAS does know which one is for SLAAC p= refix pool, which one is for DHCPv6 address pool. 

 

[RM] All the configured pools are the same for the NAS, i= n this case an extra logic would be needed to instruct the NAS about which = pool is for SLAAC and which one is for DHCPv6

 

 

 

That=A1=AFs why in my opinion the Stateful-IPv6-Address-P= ool is required.

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB: Maglione Roberta [roberta.magl= ione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1=BC=E4= : 2011=C4=EA7=D4=C227=C8=D5 2:13
=B5=BD: 'Jacni Qin'
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
=D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext sess= ion

Hi Jacni,
   If you use the same attribute for both scenarios how does the = NAS know if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mail= to:jacniq@gmail.com]
Sent: marted=A8=AC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_s= z@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session

Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Rober= ta <roberta.maglione@telecomitalia.it> wrote:
Hello Leaf,
    The different attributes proposed in this draft for the = pools name have all the same format (a string), but semantically they are d= ifferent, as they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: owner-radiusext@ops.ietf.org [mai= lto:owner-radiusext@ops.ietf.org] On Behalf Of Leaf yeh
Sent: luned=A8=AC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.or= g; radiusext@ops.ietf.org
Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0            &n= bsp;      1      &nb= sp;            2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |  &= nbsp; Length     |     String... +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.= =

Que= sto messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi alt= ra azione derivante dalla conoscenza di queste informazioni sono rigorosame= nte vietate. Qualora abbiate ricevuto questo documento per errore siete cor= tesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments = = is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispe= tta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =A8=A8 necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5BGRFMBX704BA02_-- --_0a86fb72-cc1b-42cb-97a9-499601ef85ef_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_0a86fb72-cc1b-42cb-97a9-499601ef85ef_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 19:51:05 +0000 Date: Tue, 26 Jul 2011 19:50:14 +0000 From: Leaf yeh Subject: =?gb2312?B?tPC4tDogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYt?= =?gb2312?Q?access_after_IETF81_radext_session?= To: Maglione Roberta , 'Jacni Qin' Cc: "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Message-id: <4E3D9B58-B42A-4F2A-9396-0FBFF0A3C2C5@mimectl> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_sUmBhRfrYWdIbDeaDG8qOA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsM= --Boundary_(ID_sUmBhRfrYWdIbDeaDG8qOA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 W1JNXSBBbGwgdGhlIGNvbmZpZ3VyZWQgcG9vbHMgYXJlIHRoZSBzYW1lIGZvciB0aGUgTkFTLCBp biB0aGlzIGNhc2UgYW4gZXh0cmEgbG9naWMgd291bGQgYmUgbmVlZGVkIHRvIGluc3RydWN0IHRo ZSBOQVMgYWJvdXQgd2hpY2ggcG9vbCBpcyBmb3IgU0xBQUMgYW5kIHdoaWNoIG9uZSBpcyBmb3Ig REhDUHY2DQoNCg0KDQpUaGUgcG9vbHMgY29uZmlndXJlZCBvbiB0aGUgTkFTIGFyZSBub3QgbmVj ZXNzYXJ5IHRvIGJlIHRoZSBzYW1lLiBBQUEgc2VydmVyIGRvZXNuJ3QgcmVhbGx5IG5lZWQgdG8g aW5zdHJ1Y3QgdGhlIE5BUyB0aGUgc3BlY2lmaWVkIHR5cGUgb2YgcG9vbHMsIHdoaWNoIGlzIGFs cmVhZHkgY29uZmlndXJlZCBvbiB0aGUgTkFTLiBSaWdodD8NCg0KDQoNCg0KDQpCZXN0IFJlZ2Fy ZHMsDQoNCkxlYWYNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCreivP7IyzogTWFnbGlvbmUgUm9iZXJ0YSBbcm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRh bGlhLml0XQ0Kt6LLzcqxvOQ6IDIwMTHE6jfUwjI3yNUgMjoyNw0Ktb06IExlYWYgeWVoOyAnSmFj bmkgUWluJw0KQ2M6IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3Jn OyByYWRpdXNleHRAb3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2Fu Z3NodXhpYW5nDQrW98ziOiBSRTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlw djYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KDQpQbGVhc2Ugc2VlIGlubGlu ZS4NCg0KQmVzdCByZWdhcmRzLA0KUm9iZXJ0YQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbTogTGVhZiB5ZWggW21haWx0bzpsZWFmLnkueWVoQGh1YXdlaS5jb21dDQpT ZW50OiBtYXJ0ZWSorCAyNiBsdWdsaW8gMjAxMSAyMC4yMg0KVG86IE1hZ2xpb25lIFJvYmVydGE7 ICdKYWNuaSBRaW4nDQpDYzogZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3NAdG9vbHMuaWV0 Zi5vcmc7IHJhZGl1c2V4dEBvcHMuaWV0Zi5vcmc7IGZpbmVfc3pAaHVhd2VpLmNvbTsgUWl1amlu OyBXYW5nc2h1eGlhbmcNClN1YmplY3Q6ILTwuLQ6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRm LXJhZGV4dC1pcHY2LWFjY2VzcyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb24NCg0KDQpSb2Jl cnRhIC0gSWYgeW91IHVzZSB0aGUgc2FtZSBhdHRyaWJ1dGUgZm9yIGJvdGggc2NlbmFyaW9zIGhv dyBkb2VzIHRoZSBOQVMga25vdyBpZiB0aGF0IHBvb2wgaXMgZm9yIFNMQUFDIG9yIGZvciBTdGF0 ZWZ1bCBESENQdjY/DQoNCk5BUyBhbHJlYWR5IGhhcyB0aG9zZSBwb29sIG5hbWVzIGluIGl0cyBj b25maWd1cmF0aW9uLCByaWdodD8NCg0KW1JNXSB5ZXMgcG9vbHMgYXJlIGFscmVhZHkgY29uZmln dXJlZCBpbiB0aGUgTkFTDQoNCg0KDQpOQVMgZG9lcyBrbm93IHdoaWNoIG9uZSBpcyBmb3IgU0xB QUMgcHJlZml4IHBvb2wsIHdoaWNoIG9uZSBpcyBmb3IgREhDUHY2IGFkZHJlc3MgcG9vbC4NCg0K DQoNCltSTV0gQWxsIHRoZSBjb25maWd1cmVkIHBvb2xzIGFyZSB0aGUgc2FtZSBmb3IgdGhlIE5B UywgaW4gdGhpcyBjYXNlIGFuIGV4dHJhIGxvZ2ljIHdvdWxkIGJlIG5lZWRlZCB0byBpbnN0cnVj dCB0aGUgTkFTIGFib3V0IHdoaWNoIHBvb2wgaXMgZm9yIFNMQUFDIGFuZCB3aGljaCBvbmUgaXMg Zm9yIERIQ1B2Ng0KDQoNCg0KDQoNCg0KDQpUaGF0oa9zIHdoeSBpbiBteSBvcGluaW9uIHRoZSBT dGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCBpcyByZXF1aXJlZC4NCg0KDQoNCg0KDQpCZXN0IFJl Z2FyZHMsDQoNCkxlYWYNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kt6K8/sjLOiBNYWdsaW9uZSBSb2JlcnRhIFtyb2JlcnRhLm1hZ2xpb25lQHRlbGVjb21pdGFs aWEuaXRdDQq3osvNyrG85DogMjAxMcTqN9TCMjfI1SAyOjEzDQq1vTogJ0phY25pIFFpbicNCkNj OiBMZWFmIHllaDsgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3NAdG9vbHMuaWV0Zi5vcmc7 IHJhZGl1c2V4dEBvcHMuaWV0Zi5vcmc7IGZpbmVfc3pAaHVhd2VpLmNvbTsgUWl1amluOyBXYW5n c2h1eGlhbmcNCtb3zOI6IFJFOiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2 Ni1hY2Nlc3MgYWZ0ZXIgSUVURjgxIHJhZGV4dCBzZXNzaW9uDQpIaSBKYWNuaSwNCiAgIElmIHlv dSB1c2UgdGhlIHNhbWUgYXR0cmlidXRlIGZvciBib3RoIHNjZW5hcmlvcyBob3cgZG9lcyB0aGUg TkFTIGtub3cgaWYgdGhhdCBwb29sIGlzIGZvciBTTEFBQyBvciBmb3IgU3RhdGVmdWwgREhDUHY2 Pw0KDQpUaGFua3MsDQpSZWdhcmRzLA0KUm9iZXJ0YQ0KDQoNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEphY25pIFFpbiBbbWFpbHRvOmphY25p cUBnbWFpbC5jb21dDQpTZW50OiBtYXJ0ZWSorCAyNiBsdWdsaW8gMjAxMSAyMC4wMw0KVG86IE1h Z2xpb25lIFJvYmVydGENCkNjOiBMZWFmIHllaDsgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nl c3NAdG9vbHMuaWV0Zi5vcmc7IHJhZGl1c2V4dEBvcHMuaWV0Zi5vcmc7IGZpbmVfc3pAaHVhd2Vp LmNvbTsgUWl1amluOyBXYW5nc2h1eGlhbmcNClN1YmplY3Q6IFJlOiBRIG9uIFZlci4tMDUgb2Yg ZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3MgYWZ0ZXIgSUVURjgxIHJhZGV4dCBzZXNzaW9u DQoNCkhpIFJvYmVydGEsDQoNCkkgYWdyZWUgd2l0aCB5b3UgYWJvdXQgdGhlIHNlbWFudGljYWwg bG9naWMsIHdoaWxlICJTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCIgaXMgbm90IG5lY2Vzc2Fy eSwgSU1ITy4NCg0KDQpDaGVlcnMsDQpKYWNuaQ0KT24gV2VkLCBKdWwgMjcsIDIwMTEgYXQgMTo1 NSBBTSwgTWFnbGlvbmUgUm9iZXJ0YSA8cm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0 PiB3cm90ZToNCkhlbGxvIExlYWYsDQogICAgVGhlIGRpZmZlcmVudCBhdHRyaWJ1dGVzIHByb3Bv c2VkIGluIHRoaXMgZHJhZnQgZm9yIHRoZSBwb29scyBuYW1lIGhhdmUgYWxsIHRoZSBzYW1lIGZv cm1hdCAoYSBzdHJpbmcpLCBidXQgc2VtYW50aWNhbGx5IHRoZXkgYXJlIGRpZmZlcmVudCwgYXMg dGhleSBjb3ZlZCBkaWZmZXJlbnQgc2NlbmFyaW9zLg0KQXMgeW91IGFsc28gc3VtbWFyaXplZCBp biB5b3VyIGVtYWlsIGJlbG93LA0KDQpGcmFtZWQtUG9vbCB3YXMgZGVzaWduZWQgZm9yIHRoZSBJ UHY0IGFkZHJlc3MgcG9vbDsNCkZyYW1lZC1JUHY2LVBvb2wgd2FzIGRlc2lnbmVkIGZvciB0aGUg SVB2NiBTTEFBQyBwcmVmaXggcG9vbDsNCkRlbGVnYXRlZC1JUHY2LVByZWZpeC1Qb29sIGlzIGRl c2lnbmVkIGZvciBESENQdjYtUEQgcHJlZml4IHBvb2w7DQpTdGF0ZWZ1bC1JUHY2LUFkZHJlc3Mt UG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2IGFkZHJlc3MgcG9vbDsNCg0KU28gZWFjaCBhdHRy aWJ1dGUgY292ZXJzIGEgZGlmZmVyZW50IHVzZS1jYXNlL3NjZW5hcmlvIGFuZCB0aGV5IGNhbiBh cHBlYXIgaW4gdGhlIHNhbWUgUkFESVVTIHBhY2tldCBhdCB0aGUgc2FtZSB0aW1lLg0KSWYgeW91 IHdhbnQgdG8gdXNlIGEgc2luZ2xlIHBvb2wgbmFtZSB1c2UgdG8gY292ZXIgYWxsIHRoZSA0IHVz ZSBjYXNlcyBsaXN0ZWQgYWJvdmUsIHlvdSB3b3VsZCBhbHNvIG5lZWQgdG8gZGVmaW5lIGEgc3Rh bmRhcmQgZm9ybWF0L3N5bnRheCBmb3IgdGhlIHBvb2wgbmFtZSB0aGF0IGFsbG93cyB0aGUgTkFT IHRvIGJlIGFibGUgdG8gZGlzYW1iaWd1YXRlIGFtb25nIHRoZSBkaWZmZXJlbnQgc2NlbmFyaW9z IGFuZCBpbiBvcmRlciB0byBkbyB0aGF0IHRoZSBOQVMgd291bGQgbmVlZCB0byBoYXZlIGFuIGV4 dHJhIGxvZ2ljIHRvIGluZmVyIHRoZSBzZW1hbnRpYyBvZiB0aGF0IHNwZWNpZmljIGF0dHJpYnV0 ZSBmcm9tIHRoZSBhc3NpZ25lZCBuYW1lLg0KSW5zdGVhZCBpZiB5b3UgaGF2ZSBhIHNwZWNpZmlj IGF0dHJpYnV0ZSBmb3IgZWFjaCBzcGVjaWZpYyBzY2VuYXJpbywgdGhlIHNlbWFudGljIGlzIG1h cHBlZCB0byB0aGUgYXR0cmlidXRlIG5hbWUsIHRodXMgdGhlIE5BUyBkb2VzIG5vdCBuZWVkIGFu IGV4dHJhIGxvZ2ljIHRvIGRpc2NvdmVyeSB0aGUgcHVycG9zZSBvZiB0aGF0IHBvb2wgYW5kIHRo ZSBwb29sIG5hbWUgY2FuIGJlIGFueSBzdHJpbmcsIG5vIGxpbWl0YXRpb24gb3Igc3BlY2lhbCBz eW50YXggaXMgZm9yY2VkIGZvciB0aGUgcG9vbCBuYW1lLg0KDQoNClRoYW5rcywNClJlZ2FyZHMs DQpSb2JlcnRhDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogb3duZXItcmFkaXVzZXh0QG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLXJh ZGl1c2V4dEBvcHMuaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMZWFmIHllaA0KU2VudDogbHVuZWSo rCAyNSBsdWdsaW8gMjAxMSAxOC4yMw0KVG86IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNz QHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3JnDQpDYzogZmluZV9zekBodWF3 ZWkuY29tOyBRaXVqaW47IFdhbmdzaHV4aWFuZw0KU3ViamVjdDogUSBvbiBWZXIuLTA1IG9mIGRy YWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0K DQpRdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbjoNCg0KV2UgYWxyZWFkeSBoYXZlIHRoZSBmb2xs b3dpbmcgUmFkaXVzIEF0dHJpYnV0ZXMgZm9yIHRoZSBhZGRyZXNzL3ByZWZpeCBwb29sczoNCg0K RnJhbWVkLVBvb2wgKDg4LCBzZWN0aW9uIDUuMTggb2YgUkZDMjg2OSksDQpGcmFtZWQtSVB2Ni1Q b29sICgxMDAsIHNlY3Rpb24gMi42IG9mIFJGQzMxNjIpLg0KDQpodHRwOi8vd3d3LmlhbmEub3Jn L2Fzc2lnbm1lbnRzL3JhZGl1cy10eXBlcy9yYWRpdXMtdHlwZXMueG1sDQoNClRoZSBmb3JhbXQg YXJlIHRoZSBzYW1lIGFzIGZvbGxvd3M6DQoNCjAgICAgICAgICAgICAgICAgICAgMSAgICAgICAg ICAgICAgICAgICAyDQowIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMw0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K fCAgICAgVHlwZSAgICAgIHwgICAgTGVuZ3RoICAgICB8ICAgICBTdHJpbmcuLi4NCistKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KZHJhZnQtaWV0Zi1y YWRleHQtaXB2Ni1hY2Nlc3MtMDUgaXMgcHJvcG9zaW5nIDIgbmV3IGF0dHJpYnV0ZXMgZm9yIGFk ZHJlc3MvcHJlZml4IHBvb2xzOg0KDQpEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCwNClN0YXRl ZnVsLUlQdjYtQWRkcmVzcy1Qb29sLA0KDQp0aGUgZm9tYXQgb2YgdGhlc2UgMiBhdHRyaWJ1dGVz IGFyZSB0aGUgc2FtZSBhcyB0aGUgYWJvdmUgb25lLg0KDQoNClN1cHBvc2VkIHRoZSBhYm92ZSBh dHRyaWJ1dGVzIGNvdWxkIGJlIGV4cGxhaW5lZCBhcyBmb2xsb3dzOg0KDQpGcmFtZWQtUG9vbCB3 YXMgZGVzaWduZWQgZm9yIHRoZSBJUHY0IGFkZHJlc3MgcG9vbDsNCkZyYW1lZC1JUHY2LVBvb2wg d2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NiBTTEFBQyBwcmVmaXggcG9vbDsNCkRlbGVnYXRlZC1J UHY2LVByZWZpeC1Qb29sIGlzIGRlc2lnbmVkIGZvciBESENQdjYtUEQgcHJlZml4IHBvb2w7DQpT dGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2IGFkZHJlc3Mg cG9vbDsNCg0KQWxsIGFib3ZlIGF0dHJpYnV0ZXMgYXJlIG9ubHkgdXNlZCB0byBwcm92aWRlIHRo ZSBuYW1lIG9mIHRoZSBhZGRyZXNzL3ByZWZpeCBwb29scyBpbiBhICdzdHJpbmcnLiBJIGRvdWJ0 IHRoZSBuZWNlc3NpdHkgdG8gbWFrZSBzbyBtYW55ICduYW1lJyBvciAnc3RyaW5nJyBhdHRyaWJ1 dGVzIGZvciB0aGUgZGlmZmVyZW50IGFkZHJlc3MvcHJlZml4IHBvb2xzIHRvIHByZXZlbnQgdGhl IGFtYmlndWl0eS4gSSBndWVzcyAxIGF0dHJpYnV0ZSBmb3IgdGhlIG5hbWUgb2YgdGhlIGFkZHJl c3MvcHJlZml4IHBvb2xzIG1pZ2h0IGJlIGVub3VnaC4gSW4gZmFjdCwgdGhlIE5BUyB0YWtlIHRo ZSByb2xlIHRvIGludGVycHJldCB0aGUgbWVhbmluZyBvZiB0aGUgcG9vayBuYW1lLCByaWdodD8N Cg0KSSB0aGluayBGcmFtZWQtUG9vbCBjYW4gYmUgcmUtdXNlZCBmb3IgdGhlIGRlc2lnbiBwdXJw b3NlIG9mIFN0YXRlZnVsLUlQdjYtQWRkcmVzcy1Qb29sLiBEbyB3ZSBoYXZlIGFueSBsaW1pdGF0 aW9uIG9uIHRoZSB1c2FnZSBvZiBGcmFtZWQtUG9vbCBmb3IgSVB2Nj8NCkkgdGhpbmsgRnJhbWVk LUlQdjYtUG9vbCBjYW4gYmUgcmUtdXNlZCBmb3IgdGhlIGRlc2lnbiBwdXJwb3NlIG9mIERlbGVn YXRlZC1JUHY2LVByZWZpeC1Qb29sIHRvIGluZGljYXRlIGEgcG9vbCBvZiBJUHY2IHByZWZpeCBw b29sLiBJIGNvdWxkIGV2ZW4gdGhpbmsgRnJhbWVkLVBvb2wgY2FuIHJlcGxhY2UgRnJhbWVkLUlQ djYtUG9vbCB0byBpbmRpY2F0ZSB0aGUgbmFtZSBvZiBhIElQdjYgcHJlZml4L2FkZHJlc3MgcG9v bCBwZXIgdGhlIHNhbWUgbG9naWMuIEFtIEkgcmlnaHQ/DQoNCg0KQmVzdCBSZWdhcmRzLA0KTGVh Zg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxl Z2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0 ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50 ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1l bnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBl ciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNv bXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXpp b25lLCBHcmF6aWUuDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVu dGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3Ig dGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBv ciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBh dHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtz Lg0KUmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiCo qCBuZWNlc3NhcmlvLg0KDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29u byBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRp ZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEg Y29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0 YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3Jl IHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXpp b25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3Jh emllLg0KDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBh bmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFk ZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2Ug YnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2ht ZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KUXVl c3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2 YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFs c2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBp bmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSBy aWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHBy ZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBw cm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQoNClRoaXMgZS1tYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3Nl bWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5h dXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNl bmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQoNCltyaXNwZXR0YSBsJ2FtYmllbnRlXVJp c3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gqKggbmVj ZXNzYXJpby4NCg0K --Boundary_(ID_sUmBhRfrYWdIbDeaDG8qOA) Content-id: <5FC01589697C6740880F2E0E4A176D87@huawei.com> Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable --Boundary_(ID_sUmBhRfrYWdIbDeaDG8qOA)-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 18:50:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5r0UxJpyKFohcXRQkto1/UVR8Jcv0GkL4UOmyAcLTnc=; b=HRCeVlKgx65RygHWtAEko+6A/DBTYXf7VqO4FTm8dnGiu+QfGMx3bqHX6vzpHqRjgk E9DasIHtvSbz6in80nJaHL3pW25FD43ISA52xnLhwe3NEJeqk7A0ucKdLi0qabjIA2Ig 7+jZXJaOmMRd9j/i8nO55bCMRmepY8EagOs7Q= MIME-Version: 1.0 Date: Wed, 27 Jul 2011 02:49:26 +0800 Message-ID: Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session From: Jacni Qin To: Maglione Roberta Cc: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Content-Type: multipart/alternative; boundary=20cf307cff5415d88004a8fd647f --20cf307cff5415d88004a8fd647f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hi, PD is one case, which needs a special attribute, I agree with that. While the others are all "framed-*", no matter which approach is used for address assignment, SLAAC or DHCPv6. Cheers, Jacni On Wed, Jul 27, 2011 at 2:45 AM, Maglione Roberta < roberta.maglione@telecomitalia.it> wrote: > ** > > Sorry I=92m not sure I have fully understood your example:**** > > In IPv4 the client only gets one IPv4 address extracted from a pool and w= e > already have and attribute for that pool: Frame-Pool**** > > ** ** > > In IPv6 there are different scenarios (WAN and LAN side IPv6 prefix) > described in the draft.**** > > Roberta **** > > ** ** > ------------------------------ > > *From:* Jacni Qin [mailto:jacniq@gmail.com] > *Sent:* marted=EC 26 luglio 2011 20.40 > > *To:* **Maglione Roberta** > *Cc:* Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; ** > radiusext@ops.ietf.org**; ** fine_sz@huawei.com**; Qiujin; Wangshuxiang > *Subject:* Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 > radext session > **** > > ** ** > > hi, > > Here is an example from another perspective, > > What if I use DHCPv4? Then a corresponding attribute for IPv4 is needed? > > > Cheers, > Jacni**** > > On Wed, Jul 27, 2011 at 2:37 AM, **Maglione Roberta** < > roberta.maglione@telecomitalia.it> wrote:**** > > The string only contains a name, how does the NAS infer the semantic of > that pool name (meaning SLAAC or DHCPv6) from the name?**** > > **** > > Roberta**** > > **** > ------------------------------ > > *From:* Jacni Qin [mailto:jacniq@gmail.com] > *Sent:* marted=EC 26 luglio 2011 20.33**** > > > *To:* **Maglione Roberta** > *Cc:* Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; > radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang > *Subject:* Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 > radext session**** > > **** > > hi, > > That's what the "String" is for? :-) > > > Cheers, > Jacni**** > > On Wed, Jul 27, 2011 at 2:13 AM, **Maglione Roberta** < > roberta.maglione@telecomitalia.it> wrote:**** > > Hi Jacni, > If you use the same attribute for both scenarios how does the NAS know = if > that pool is for SLAAC or for Stateful DHCPv6? > > Thanks, > Regards, > Roberta > > > > > > ________________________________________ > From: Jacni Qin [mailto:jacniq@gmail.com] > Sent: marted=EC 26 luglio 2011 20.03 > To: **Maglione Roberta** > Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; > radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang > Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 > radext session**** > > > Hi Roberta, > > I agree with you about the semantical logic, while > "Stateful-IPv6-Address-Pool" is not necessary, IMHO. > > > Cheers, > Jacni > On Wed, Jul 27, 2011 at 1:55 AM, **Maglione Roberta** < > roberta.maglione@telecomitalia.it> wrote: > Hello Leaf, > The different attributes proposed in this draft for the pools name hav= e > all the same format (a string), but semantically they are different, as t= hey > coved different scenarios. > As you also summarized in your email below, > > Framed-Pool was designed for the IPv4 address pool; > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; > > So each attribute covers a different use-case/scenario and they can appea= r > in the same RADIUS packet at the same time. > If you want to use a single pool name use to cover all the 4 use cases > listed above, you would also need to define a standard format/syntax for = the > pool name that allows the NAS to be able to disambiguate among the differ= ent > scenarios and in order to do that the NAS would need to have an extra log= ic > to infer the semantic of that specific attribute from the assigned name. > Instead if you have a specific attribute for each specific scenario, the > semantic is mapped to the attribute name, thus the NAS does not need an > extra logic to discovery the purpose of that pool and the pool name can b= e > any string, no limitation or special syntax is forced for the pool name. > > > Thanks, > Regards, > Roberta > > > > > > ________________________________________ > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Leaf yeh > Sent: luned=EC 25 luglio 2011 18.23 > To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org > Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang > Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radex= t > session > > Question for clarification: > > We already have the following Radius Attributes for the address/prefix > pools: > > Framed-Pool (88, section 5.18 of RFC2869), > Framed-IPv6-Pool (100, section 2.6 of RFC3162). > > http://www.iana.org/assignments/radius-types/radius-types.xml > > The foramt are the same as follows: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | String... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for > address/prefix pools: > > Delegated-IPv6-Prefix-Pool, > Stateful-IPv6-Address-Pool, > > the fomat of these 2 attributes are the same as the above one. > > > Supposed the above attributes could be explained as follows: > > Framed-Pool was designed for the IPv4 address pool; > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; > > All above attributes are only used to provide the name of the > address/prefix pools in a 'string'. I doubt the necessity to make so many > 'name' or 'string' attributes for the different address/prefix pools to > prevent the ambiguity. I guess 1 attribute for the name of the > address/prefix pools might be enough. In fact, the NAS take the role to > interpret the meaning of the pook name, right? > > I think Framed-Pool can be re-used for the design purpose of > Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of > Framed-Pool for IPv6? > I think Framed-IPv6-Pool can be re-used for the design purpose of > Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I coul= d > even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name = of > a IPv6 prefix/address pool per the same logic. Am I right? > > > Best Regards, > Leaf > > > > > > > > > > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks.**** > > Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.**** > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks.**** > > **** > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. **** > > *This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not = the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks.* **** > > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mai= l > se non =E8 necessario.* **** > > ** ** > Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not = the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mai= l > se non =E8 necessario.* > > --20cf307cff5415d88004a8fd647f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hi,

PD is one case, which needs a = special attribute, I agree with that.
While the others are all "fra= med-*", no matter which approach is used for address assignment, SLAAC= or DHCPv6.


Cheers,
Jacni

On Wed, J= ul 27, 2011 at 2:45 AM, Maglione Roberta <roberta.maglione@telecomitalia.it<= /a>> wrote:

Sorry I=92m not su= re I have fully understood your example:

In IPv4 the client= only gets one IPv4 address extracted from a pool and we already have and a= ttribute for that pool: Frame-Pool

=A0<= /span>

In IPv6 there are = different scenarios (WAN and LAN side IPv6 prefix) described in the draft.<= u>

Roberta

=A0<= /span>

From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 20= 11 20.40

=A0

hi,

Here is an example from another perspective,

What if I use DHCPv4? Then a corresponding attribute for IPv4 is needed?

Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:37 AM, Maglione Roberta <roberta.maglione@telecomitalia.it> wr= ote:

The string only co= ntains a name, how does the NAS infer the semantic of that pool name (meaning SLAAC or DHCPv6) from the name?=

=A0<= u>

Roberta

=A0<= u>

From: Jacni Qin [mailto:ja= cniq@gmail.com]
Sent: marted=EC 26 luglio 20= 11 20.33


To: Maglione Roberta<= u>
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of= draft-ietf-radext-ipv6-access after IETF81 radext session=

=A0

hi,

That's what the "String" is for? :-)


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta <roberta.maglione@telecomitalia.it> wr= ote:

Hi Jacni,
=A0 If you use the same attribute for both scenarios how does the NAS know = if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session


Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.mag= lione@telecomitalia.it> wrote:
Hello Leaf,
=A0 =A0The different attributes proposed in this draft for the pools name h= ave all the same format (a string), but semantically they are different, as= they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: own= er-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of= Leaf yeh
Sent: luned=EC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org
Cc: fine_sz@huawei.= com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=A0=A0=A0=A0 Type =A0 =A0 =A0|=A0=A0=A0 Length =A0 =A0 |=A0=A0=A0=A0 Strin= g...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'n= ame' or 'string' attributes for the different address/prefix po= ols to prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

Rispetta l'ambien= te. Non stampare questa mail se non =E8 necessario.

Questo messaggio e i = suoi allegati sono indirizzati esclusivamente alle persone indicate. La dif= fusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

=A0

Questo messaggio e i s= uoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi alt= ra azione derivante dalla conoscenza di queste informazioni sono rigorosame= nte vietate. Qualora abbiate ricevuto questo documento per errore siete cor= tesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-m= ail and any attachments=A0is=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks. <= /span>

3D"rispettaRispetta l'ambiente. Non stampare questa mail se non =E8 necessario.

=A0

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=A0is=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D=Rispetta l'ambient= e. Non stampare questa mail se non =E8 necessario.


--20cf307cff5415d88004a8fd647f-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 18:46:08 +0000 Content-Type: multipart/mixed; boundary="_71de0d15-7b26-4695-84f6-4e2b8460d388_" From: Maglione Roberta To: 'Jacni Qin' CC: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Date: Tue, 26 Jul 2011 20:45:36 +0200 Subject: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Index: AcxLw3QWJ03KoQwARf+9rW+G190UxQAAGjbA Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5A@GRFMBX704BA020.griffon.local> Accept-Language: en-US, it-IT Content-Language: en-US acceptlanguage: en-US, it-IT MIME-Version: 1.0 --_71de0d15-7b26-4695-84f6-4e2b8460d388_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5AGRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5AGRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry I'm not sure I have fully understood your example: In IPv4 the client only gets one IPv4 address extracted from a pool and we = already have and attribute for that pool: Frame-Pool In IPv6 there are different scenarios (WAN and LAN side IPv6 prefix) descri= bed in the draft. Roberta ________________________________ From: Jacni Qin [mailto:jacniq@gmail.com] Sent: marted=EC 26 luglio 2011 20.40 To: Maglione Roberta Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session hi, Here is an example from another perspective, What if I use DHCPv4? Then a corresponding attribute for IPv4 is needed? Cheers, Jacni On Wed, Jul 27, 2011 at 2:37 AM, Maglione Roberta > wrote: The string only contains a name, how does the NAS infer the semantic of tha= t pool name (meaning SLAAC or DHCPv6) from the name? Roberta ________________________________ From: Jacni Qin [mailto:jacniq@gmail.com] Sent: marted=EC 26 luglio 2011 20.33 To: Maglione Roberta Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wa= ngshuxiang Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session hi, That's what the "String" is for? :-) Cheers, Jacni On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta > wrote: Hi Jacni, If you use the same attribute for both scenarios how does the NAS know if= that pool is for SLAAC or for Stateful DHCPv6? Thanks, Regards, Roberta ________________________________________ From: Jacni Qin [mailto:jacniq@gmail.com] Sent: marted=EC 26 luglio 2011 20.03 To: Maglione Roberta Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wa= ngshuxiang Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session Hi Roberta, I agree with you about the semantical logic, while "Stateful-IPv6-Address-P= ool" is not necessary, IMHO. Cheers, Jacni On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta > wrote: Hello Leaf, The different attributes proposed in this draft for the pools name have = all the same format (a string), but semantically they are different, as the= y coved different scenarios. As you also summarized in your email below, Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time. If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic= to infer the semantic of that specific attribute from the assigned name. Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name. Thanks, Regards, Roberta ________________________________________ From: owner-radiusext@ops.ietf.org [ma= ilto:owner-radiusext@ops.ietf.org] On = Behalf Of Leaf yeh Sent: luned=EC 25 luglio 2011 18.23 To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session Question for clarification: We already have the following Radius Attributes for the address/prefix pool= s: Framed-Pool (88, section 5.18 of RFC2869), Framed-IPv6-Pool (100, section 2.6 of RFC3162). http://www.iana.org/assignments/radius-types/radius-types.xml The foramt are the same as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools: Delegated-IPv6-Prefix-Pool, Stateful-IPv6-Address-Pool, the fomat of these 2 attributes are the same as the above one. Supposed the above attributes could be explained as follows: Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be= enough. In fact, the NAS take the role to interpret the meaning of the poo= k name, right? I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6? I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right? Best Regards, Leaf Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [%20]Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5AGRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sorry I’m not sure I have fully = understood your example:

In IPv4 the client only gets one IPv4 = address extracted from a pool and we already have and attribute for that po= ol: Frame-Pool

 

In IPv6 there are different scenarios = (WAN and LAN side IPv6 prefix) described in the draft.

Roberta

 

From: Jacn= i Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 20= 11 20.40
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-rad= ext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of= draft-ietf-radext-ipv6-access after IETF81 radext session

 

hi,

Here is an example from another perspective,

What if I use DHCPv4? Then a corresponding attribute for IPv4 is needed?

Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:37 AM, Maglione Roberta <roberta.maglione@telecomitali= a.it> wrote:

The string only contains a name, how does the NAS infer the sem= antic of that pool name (meaning SLAAC or DHCPv6) from the name?

 

Roberta

 

From: Jacni Qin [mailto:ja= cniq@gmail.com]
Sent: marted=EC 26 luglio 20= 11 20.33


To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of= draft-ietf-radext-ipv6-access after IETF81 radext session

 

hi,

That's what the "String" is for? :-)


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta <roberta.mag= lione@telecomitalia.it> wrote:

Hi Jacni,
  If you use the same attribute for both scenarios how does the NAS kn= ow if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session


Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Rober= ta <roberta.maglione@telecomitalia.it> wrote:
Hello Leaf,
   The different attributes proposed in this draft for the pools = name have all the same format (a string), but semantically they are differe= nt, as they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: own= er-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of= Leaf yeh
Sent: luned=EC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org
Cc: fine_sz@huawei.= com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0                   1   &= nbsp;               2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |    Leng= th     |     String...
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle = persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

 

Que= sto messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi alt= ra azione derivante dalla conoscenza di queste informazioni sono rigorosame= nte vietate. Qualora abbiate ricevuto questo documento per errore siete cor= tesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispe= tta l'ambiente. Non stampare questa mail se non =E8 necessario.<= /b>

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D5AGRFMBX704BA02_-- --_71de0d15-7b26-4695-84f6-4e2b8460d388_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_71de0d15-7b26-4695-84f6-4e2b8460d388_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 18:43:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AjsxMglhS3ngUurG6+ELKetAZd8B6ZnxGaeoVU0kgA8=; b=Sg4zoVTD4KGi5wlpXCdNzR+NS67oaJwXCCO16i2OTse9HvIe9vmUuM50qjOJ5Hnvzk ciPFGlQLfFbpJlj/10lf8Our7hwQt2UwRJlrxxlxBrI0uTjc18L156trKEHiMy8UbYxC q78X/gtaihVBtcd3J4kCFEn4rk2dNFKLxQGu8= MIME-Version: 1.0 Date: Wed, 27 Jul 2011 02:43:35 +0800 Message-ID: Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session From: Jacni Qin To: Maglione Roberta Cc: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Content-Type: multipart/alternative; boundary=bcaec501603b32c28704a8fd4fd1 --bcaec501603b32c28704a8fd4fd1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Re-, What I mean is the SLAAC and DHCPv6 can share the same pool. Cheers, Jacni On Wed, Jul 27, 2011 at 2:40 AM, Jacni Qin wrote: > hi, > > Here is an example from another perspective, > > What if I use DHCPv4? Then a corresponding attribute for IPv4 is needed? > > > Cheers, > Jacni > > On Wed, Jul 27, 2011 at 2:37 AM, Maglione Roberta < > roberta.maglione@telecomitalia.it> wrote: > >> ** >> >> The string only contains a name, how does the NAS infer the semantic of >> that pool name (meaning SLAAC or DHCPv6) from the name?**** >> >> ** ** >> >> Roberta**** >> >> ** ** >> ------------------------------ >> >> *From:* Jacni Qin [mailto:jacniq@gmail.com] >> *Sent:* marted=EC 26 luglio 2011 20.33 >> >> *To:* **Maglione Roberta** >> *Cc:* Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; ** >> radiusext@ops.ietf.org**; ** fine_sz@huawei.com**; Qiujin; Wangshuxiang >> *Subject:* Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF8= 1 >> radext session >> **** >> >> ** ** >> >> hi, >> >> That's what the "String" is for? :-) >> >> >> Cheers, >> Jacni**** >> >> On Wed, Jul 27, 2011 at 2:13 AM, **Maglione Roberta** < >> roberta.maglione@telecomitalia.it> wrote:**** >> >> Hi Jacni, >> If you use the same attribute for both scenarios how does the NAS know >> if that pool is for SLAAC or for Stateful DHCPv6? >> >> Thanks, >> Regards, >> Roberta >> >> >> >> >> >> ________________________________________ >> From: Jacni Qin [mailto:jacniq@gmail.com] >> Sent: marted=EC 26 luglio 2011 20.03 >> To: **Maglione Roberta** >> Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; >> radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang >> Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 >> radext session**** >> >> >> Hi Roberta, >> >> I agree with you about the semantical logic, while >> "Stateful-IPv6-Address-Pool" is not necessary, IMHO. >> >> >> Cheers, >> Jacni >> On Wed, Jul 27, 2011 at 1:55 AM, **Maglione Roberta** < >> roberta.maglione@telecomitalia.it> wrote: >> Hello Leaf, >> The different attributes proposed in this draft for the pools name ha= ve >> all the same format (a string), but semantically they are different, as = they >> coved different scenarios. >> As you also summarized in your email below, >> >> Framed-Pool was designed for the IPv4 address pool; >> Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; >> Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; >> Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; >> >> So each attribute covers a different use-case/scenario and they can appe= ar >> in the same RADIUS packet at the same time. >> If you want to use a single pool name use to cover all the 4 use cases >> listed above, you would also need to define a standard format/syntax for= the >> pool name that allows the NAS to be able to disambiguate among the diffe= rent >> scenarios and in order to do that the NAS would need to have an extra lo= gic >> to infer the semantic of that specific attribute from the assigned name. >> Instead if you have a specific attribute for each specific scenario, the >> semantic is mapped to the attribute name, thus the NAS does not need an >> extra logic to discovery the purpose of that pool and the pool name can = be >> any string, no limitation or special syntax is forced for the pool name. >> >> >> Thanks, >> Regards, >> Roberta >> >> >> >> >> >> ________________________________________ >> From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] >> On Behalf Of Leaf yeh >> Sent: luned=EC 25 luglio 2011 18.23 >> To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org >> Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang >> Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rade= xt >> session >> >> Question for clarification: >> >> We already have the following Radius Attributes for the address/prefix >> pools: >> >> Framed-Pool (88, section 5.18 of RFC2869), >> Framed-IPv6-Pool (100, section 2.6 of RFC3162). >> >> http://www.iana.org/assignments/radius-types/radius-types.xml >> >> The foramt are the same as follows: >> >> 0 1 2 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | String... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for >> address/prefix pools: >> >> Delegated-IPv6-Prefix-Pool, >> Stateful-IPv6-Address-Pool, >> >> the fomat of these 2 attributes are the same as the above one. >> >> >> Supposed the above attributes could be explained as follows: >> >> Framed-Pool was designed for the IPv4 address pool; >> Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; >> Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; >> Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; >> >> All above attributes are only used to provide the name of the >> address/prefix pools in a 'string'. I doubt the necessity to make so man= y >> 'name' or 'string' attributes for the different address/prefix pools to >> prevent the ambiguity. I guess 1 attribute for the name of the >> address/prefix pools might be enough. In fact, the NAS take the role to >> interpret the meaning of the pook name, right? >> >> I think Framed-Pool can be re-used for the design purpose of >> Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of >> Framed-Pool for IPv6? >> I think Framed-IPv6-Pool can be re-used for the design purpose of >> Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I cou= ld >> even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name= of >> a IPv6 prefix/address pool per the same logic. Am I right? >> >> >> Best Regards, >> Leaf >> >> >> >> >> >> >> >> >> >> >> >> >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >> persone indicate. La diffusione, copia o qualsiasi altra azione derivant= e >> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qual= ora >> abbiate ricevuto questo documento per errore siete cortesemente pregati = di >> darne immediata comunicazione al mittente e di provvedere alla sua >> distruzione, Grazie. >> This e-mail and any attachments is confidential and may contain privileg= ed >> information intended for the addressee(s) only. Dissemination, copying, >> printing or use by anybody else is unauthorised. If you are not the inte= nded >> recipient, please delete this message and any attachments and advise the >> sender by return e-mail, Thanks.**** >> >> Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. >> >> **** >> >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >> persone indicate. La diffusione, copia o qualsiasi altra azione derivant= e >> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qual= ora >> abbiate ricevuto questo documento per errore siete cortesemente pregati = di >> darne immediata comunicazione al mittente e di provvedere alla sua >> distruzione, Grazie. >> >> This e-mail and any attachments is confidential and may contain privileg= ed >> information intended for the addressee(s) only. Dissemination, copying, >> printing or use by anybody else is unauthorised. If you are not the inte= nded >> recipient, please delete this message and any attachments and advise the >> sender by return e-mail, Thanks.**** >> >> ** ** >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente >> alle persone indicate. La diffusione, copia o qualsiasi altra azione >> derivante dalla conoscenza di queste informazioni sono rigorosamente >> vietate. Qualora abbiate ricevuto questo documento per errore siete >> cortesemente pregati di darne immediata comunicazione al mittente e di >> provvedere alla sua distruzione, Grazie. >> >> *This e-mail and any attachments** is **confidential and may contain >> privileged information intended for the addressee(s) only. Dissemination= , >> copying, printing or use by anybody else is unauthorised. If you are not= the >> intended recipient, please delete this message and any attachments and >> advise the sender by return e-mail, Thanks.* >> *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa >> mail se non =E8 necessario.* >> >> > --bcaec501603b32c28704a8fd4fd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Re-,

What I mean is the SLAAC and = DHCPv6 can share the same pool.


Cheers,
Jacni

<= div class=3D"gmail_quote">On Wed, Jul 27, 2011 at 2:40 AM, Jacni Qin <jacniq@gmail.com>= ; wrote:

--bcaec501603b32c28704a8fd4fd1-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 18:40:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0tWPNTCPlzE7N5srdHniuxDbNu13IV2mUqTrVW/hWbc=; b=DwE/AvNL4Rut2AQUpc3+ZpGJY43CeNzQ826MVC7ECrAEX7XxuSFx8atRUzo/IJGbkL MQ9XgmLRH2QRFKdfHMfNoCbK428uxu+REE/DOGtwmzb9RYAYan1YwOr0L2uNyp53S1I9 I71DZ9i92a8ig3T5ANWmsm9q/mVkD/l9CR0hI= MIME-Version: 1.0 Date: Wed, 27 Jul 2011 02:40:09 +0800 Message-ID: Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session From: Jacni Qin To: Maglione Roberta Cc: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Content-Type: multipart/alternative; boundary=20cf30781180ea33fe04a8fd423b --20cf30781180ea33fe04a8fd423b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi, Here is an example from another perspective, What if I use DHCPv4? Then a corresponding attribute for IPv4 is needed? Cheers, Jacni On Wed, Jul 27, 2011 at 2:37 AM, Maglione Roberta < roberta.maglione@telecomitalia.it> wrote: > ** > > The string only contains a name, how does the NAS infer the semantic of > that pool name (meaning SLAAC or DHCPv6) from the name?**** > > ** ** > > Roberta**** > > ** ** > ------------------------------ > > *From:* Jacni Qin [mailto:jacniq@gmail.com] > *Sent:* marted=EC 26 luglio 2011 20.33 > > *To:* **Maglione Roberta** > *Cc:* Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; ** > radiusext@ops.ietf.org**; ** fine_sz@huawei.com**; Qiujin; Wangshuxiang > *Subject:* Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 > radext session > **** > > ** ** > > hi, > > That's what the "String" is for? :-) > > > Cheers, > Jacni**** > > On Wed, Jul 27, 2011 at 2:13 AM, **Maglione Roberta** < > roberta.maglione@telecomitalia.it> wrote:**** > > Hi Jacni, > If you use the same attribute for both scenarios how does the NAS know = if > that pool is for SLAAC or for Stateful DHCPv6? > > Thanks, > Regards, > Roberta > > > > > > ________________________________________ > From: Jacni Qin [mailto:jacniq@gmail.com] > Sent: marted=EC 26 luglio 2011 20.03 > To: **Maglione Roberta** > Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; > radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang > Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 > radext session**** > > > Hi Roberta, > > I agree with you about the semantical logic, while > "Stateful-IPv6-Address-Pool" is not necessary, IMHO. > > > Cheers, > Jacni > On Wed, Jul 27, 2011 at 1:55 AM, **Maglione Roberta** < > roberta.maglione@telecomitalia.it> wrote: > Hello Leaf, > The different attributes proposed in this draft for the pools name hav= e > all the same format (a string), but semantically they are different, as t= hey > coved different scenarios. > As you also summarized in your email below, > > Framed-Pool was designed for the IPv4 address pool; > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; > > So each attribute covers a different use-case/scenario and they can appea= r > in the same RADIUS packet at the same time. > If you want to use a single pool name use to cover all the 4 use cases > listed above, you would also need to define a standard format/syntax for = the > pool name that allows the NAS to be able to disambiguate among the differ= ent > scenarios and in order to do that the NAS would need to have an extra log= ic > to infer the semantic of that specific attribute from the assigned name. > Instead if you have a specific attribute for each specific scenario, the > semantic is mapped to the attribute name, thus the NAS does not need an > extra logic to discovery the purpose of that pool and the pool name can b= e > any string, no limitation or special syntax is forced for the pool name. > > > Thanks, > Regards, > Roberta > > > > > > ________________________________________ > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Leaf yeh > Sent: luned=EC 25 luglio 2011 18.23 > To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org > Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang > Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radex= t > session > > Question for clarification: > > We already have the following Radius Attributes for the address/prefix > pools: > > Framed-Pool (88, section 5.18 of RFC2869), > Framed-IPv6-Pool (100, section 2.6 of RFC3162). > > http://www.iana.org/assignments/radius-types/radius-types.xml > > The foramt are the same as follows: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | String... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for > address/prefix pools: > > Delegated-IPv6-Prefix-Pool, > Stateful-IPv6-Address-Pool, > > the fomat of these 2 attributes are the same as the above one. > > > Supposed the above attributes could be explained as follows: > > Framed-Pool was designed for the IPv4 address pool; > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; > > All above attributes are only used to provide the name of the > address/prefix pools in a 'string'. I doubt the necessity to make so many > 'name' or 'string' attributes for the different address/prefix pools to > prevent the ambiguity. I guess 1 attribute for the name of the > address/prefix pools might be enough. In fact, the NAS take the role to > interpret the meaning of the pook name, right? > > I think Framed-Pool can be re-used for the design purpose of > Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of > Framed-Pool for IPv6? > I think Framed-IPv6-Pool can be re-used for the design purpose of > Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I coul= d > even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name = of > a IPv6 prefix/address pool per the same logic. Am I right? > > > Best Regards, > Leaf > > > > > > > > > > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks.**** > > Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. > > **** > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks.**** > > ** ** > Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not = the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mai= l > se non =E8 necessario.* > > --20cf30781180ea33fe04a8fd423b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi,

Here is an example from anoth= er perspective,

What if I use DHCPv4? Then a corresponding attribute= for IPv4 is needed?


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:37 AM, Maglione Roberta <roberta.maglione@telecomi= talia.it> wrote:

The string only co= ntains a name, how does the NAS infer the semantic of that pool name (meani= ng SLAAC or DHCPv6) from the name?

=A0<= /span>

Roberta<= /u>

=A0<= /span>

From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 20= 11 20.33

=A0

hi,

That's what the "String" is for? :-)


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta <roberta.maglione@telecomitalia.it> wr= ote:

Hi Jacni,
=A0 If you use the same attribute for both scenarios how does the NAS know = if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session


Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.mag= lione@telecomitalia.it> wrote:
Hello Leaf,
=A0 =A0The different attributes proposed in this draft for the pools name h= ave all the same format (a string), but semantically they are different, as= they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: own= er-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of= Leaf yeh
Sent: luned=EC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org
Cc: fine_sz@huawei.= com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=A0=A0=A0=A0 Type =A0 =A0 =A0|=A0=A0=A0 Length =A0 =A0 |=A0=A0=A0=A0 Strin= g...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'n= ame' or 'string' attributes for the different address/prefix po= ols to prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

Rispetta l'ambien= te. Non stampare questa mail se non =E8 necessario.

Questo messaggio e i = suoi allegati sono indirizzati esclusivamente alle persone indicate. La dif= fusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualor= a abbiate ricevuto questo documento per errore siete cortesemente pregati d= i darne immediata comunicazione al mittente e di provvedere alla sua distru= zione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

=A0

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=A0is=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta l= 'ambiente. Non stampare questa mail se non =E8 necessario.


--20cf30781180ea33fe04a8fd423b-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 18:38:27 +0000 Content-Type: multipart/mixed; boundary="_9afb569b-83c5-40a7-943b-4bbd713a3360_" From: Maglione Roberta To: 'Jacni Qin' CC: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Date: Tue, 26 Jul 2011 20:37:59 +0200 Subject: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Index: AcxLwmsj3QlAxoIFR1CPuEZgE9LR5gAAGxSA Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59@GRFMBX704BA020.griffon.local> Accept-Language: en-US, it-IT Content-Language: en-US acceptlanguage: en-US, it-IT MIME-Version: 1.0 --_9afb569b-83c5-40a7-943b-4bbd713a3360_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59GRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59GRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The string only contains a name, how does the NAS infer the semantic of tha= t pool name (meaning SLAAC or DHCPv6) from the name? Roberta ________________________________ From: Jacni Qin [mailto:jacniq@gmail.com] Sent: marted=EC 26 luglio 2011 20.33 To: Maglione Roberta Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session hi, That's what the "String" is for? :-) Cheers, Jacni On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta > wrote: Hi Jacni, If you use the same attribute for both scenarios how does the NAS know if= that pool is for SLAAC or for Stateful DHCPv6? Thanks, Regards, Roberta ________________________________________ From: Jacni Qin [mailto:jacniq@gmail.com] Sent: marted=EC 26 luglio 2011 20.03 To: Maglione Roberta Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wa= ngshuxiang Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session Hi Roberta, I agree with you about the semantical logic, while "Stateful-IPv6-Address-P= ool" is not necessary, IMHO. Cheers, Jacni On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta > wrote: Hello Leaf, The different attributes proposed in this draft for the pools name have = all the same format (a string), but semantically they are different, as the= y coved different scenarios. As you also summarized in your email below, Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time. If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic= to infer the semantic of that specific attribute from the assigned name. Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name. Thanks, Regards, Roberta ________________________________________ From: owner-radiusext@ops.ietf.org [ma= ilto:owner-radiusext@ops.ietf.org] On = Behalf Of Leaf yeh Sent: luned=EC 25 luglio 2011 18.23 To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session Question for clarification: We already have the following Radius Attributes for the address/prefix pool= s: Framed-Pool (88, section 5.18 of RFC2869), Framed-IPv6-Pool (100, section 2.6 of RFC3162). http://www.iana.org/assignments/radius-types/radius-types.xml The foramt are the same as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools: Delegated-IPv6-Prefix-Pool, Stateful-IPv6-Address-Pool, the fomat of these 2 attributes are the same as the above one. Supposed the above attributes could be explained as follows: Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be= enough. In fact, the NAS take the role to interpret the meaning of the poo= k name, right? I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6? I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right? Best Regards, Leaf Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59GRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The string only contains a name, how d= oes the NAS infer the semantic of that pool name (meaning SLAAC or DHCPv6) = from the name?

 

Roberta

 

From: Jacn= i Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 20= 11 20.33
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-rad= ext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of= draft-ietf-radext-ipv6-access after IETF81 radext session

 

hi,

That's what the "String" is for? :-)


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta <roberta.maglione@telecomitali= a.it> wrote:

Hi Jacni,
  If you use the same attribute for both scenarios how does the NAS kn= ow if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mailto:jacniq@gmail.co= m]
Sent: marted=EC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session


Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Rober= ta <roberta.maglione@telecomitalia.it> wrote:
Hello Leaf,
   The different attributes proposed in this draft for the pools = name have all the same format (a string), but semantically they are differe= nt, as they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: owner-radiusext@ops.i= etf.org [mailto:owner-r= adiusext@ops.ietf.org] On Behalf Of Leaf yeh
Sent: luned=EC 25 luglio 2011 18.23
To: draft-i= etf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org
Cc: fine_sz@huawei.com; Qiujin; W= angshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0                   1   &= nbsp;               2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |    Leng= th     |     String...
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. = Non stampare questa mail se non =E8 necessario.

Questo messaggio e i = suoi allegati sono indirizzati esclusivamente alle persone indicate. La dif= fusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualor= a abbiate ricevuto questo documento per errore siete cortesemente pregati d= i darne immediata comunicazione al mittente e di provvedere alla sua distru= zione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D59GRFMBX704BA02_-- --_9afb569b-83c5-40a7-943b-4bbd713a3360_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_9afb569b-83c5-40a7-943b-4bbd713a3360_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 18:33:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EiwGmNxSsKPfDhAJCf36Nk7oWh60VVCGxKpjTECkk5Q=; b=rhZU8KfrExtqfWAxI4EcGOxpMC5tgthmB5STS35jUn3IdVUrWIi7le5ktaIQEOP37l cESG0AwYhKb9iaRQ3LG9MfGtntVQcSZOiNuV53/MCnNr+lHf/lVuX/R6qUT0gGyWkneb zk40mG9DVe8QI2Flk5lgGYam070YHEohl6vlM= MIME-Version: 1.0 Date: Wed, 27 Jul 2011 02:32:44 +0800 Message-ID: Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session From: Jacni Qin To: Maglione Roberta Cc: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Content-Type: multipart/alternative; boundary=bcaec51b19f564718e04a8fd2855 --bcaec51b19f564718e04a8fd2855 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi, That's what the "String" is for? :-) Cheers, Jacni On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta < roberta.maglione@telecomitalia.it> wrote: > Hi Jacni, > If you use the same attribute for both scenarios how does the NAS know = if > that pool is for SLAAC or for Stateful DHCPv6? > > Thanks, > Regards, > Roberta > > > > > > ________________________________________ > From: Jacni Qin [mailto:jacniq@gmail.com] > Sent: marted=EC 26 luglio 2011 20.03 > To: Maglione Roberta > Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; > radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang > Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 > radext session > > Hi Roberta, > > I agree with you about the semantical logic, while > "Stateful-IPv6-Address-Pool" is not necessary, IMHO. > > > Cheers, > Jacni > On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta < > roberta.maglione@telecomitalia.it> wrote: > Hello Leaf, > The different attributes proposed in this draft for the pools name hav= e > all the same format (a string), but semantically they are different, as t= hey > coved different scenarios. > As you also summarized in your email below, > > Framed-Pool was designed for the IPv4 address pool; > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; > > So each attribute covers a different use-case/scenario and they can appea= r > in the same RADIUS packet at the same time. > If you want to use a single pool name use to cover all the 4 use cases > listed above, you would also need to define a standard format/syntax for = the > pool name that allows the NAS to be able to disambiguate among the differ= ent > scenarios and in order to do that the NAS would need to have an extra log= ic > to infer the semantic of that specific attribute from the assigned name. > Instead if you have a specific attribute for each specific scenario, the > semantic is mapped to the attribute name, thus the NAS does not need an > extra logic to discovery the purpose of that pool and the pool name can b= e > any string, no limitation or special syntax is forced for the pool name. > > > Thanks, > Regards, > Roberta > > > > > > ________________________________________ > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Leaf yeh > Sent: luned=EC 25 luglio 2011 18.23 > To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org > Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang > Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radex= t > session > > Question for clarification: > > We already have the following Radius Attributes for the address/prefix > pools: > > Framed-Pool (88, section 5.18 of RFC2869), > Framed-IPv6-Pool (100, section 2.6 of RFC3162). > > http://www.iana.org/assignments/radius-types/radius-types.xml > > The foramt are the same as follows: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | String... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for > address/prefix pools: > > Delegated-IPv6-Prefix-Pool, > Stateful-IPv6-Address-Pool, > > the fomat of these 2 attributes are the same as the above one. > > > Supposed the above attributes could be explained as follows: > > Framed-Pool was designed for the IPv4 address pool; > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; > > All above attributes are only used to provide the name of the > address/prefix pools in a 'string'. I doubt the necessity to make so many > 'name' or 'string' attributes for the different address/prefix pools to > prevent the ambiguity. I guess 1 attribute for the name of the > address/prefix pools might be enough. In fact, the NAS take the role to > interpret the meaning of the pook name, right? > > I think Framed-Pool can be re-used for the design purpose of > Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of > Framed-Pool for IPv6? > I think Framed-IPv6-Pool can be re-used for the design purpose of > Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I coul= d > even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name = of > a IPv6 prefix/address pool per the same logic. Am I right? > > > Best Regards, > Leaf > > > > > > > > > > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks. > Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks. > > --bcaec51b19f564718e04a8fd2855 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi,

That's what the "Stri= ng" is for? :-)


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta <roberta.= maglione@telecomitalia.it> wrote:
Hi Jacni,
=A0 If you use the same attribute for both scenarios how does the NAS know= if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mailto:jacniq@gmail.co= m]
Sent: marted=EC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session

Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.maglione@telecomitalia.it> w= rote:
Hello Leaf,
=A0 =A0The different attributes proposed in this draft for the pools name = have all the same format (a string), but semantically they are different, a= s they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic= to infer the semantic of that specific attribute from the assigned name. Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: owner-radiusext@ops.i= etf.org [mailto:owner-r= adiusext@ops.ietf.org] On Behalf Of Leaf yeh
Sent: luned=EC 25 luglio 2011 18.23
To: draft-i= etf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org
Cc: fine_sz@huawei.com; Qiujin; W= angshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=A0=A0=A0=A0 Type =A0 =A0 =A0|=A0=A0=A0 Length =A0 =A0 |=A0=A0=A0=A0 Strin= g...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'n= ame' or 'string' attributes for the different address/prefix po= ols to prevent the ambiguity. I guess 1 attribute for the name of the addre= ss/prefix pools might be enough. In fact, the NAS take the role to interpre= t the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa = mail se non =E8 necessario.


Questo messaggio e i suoi allegati = sono indirizzati esclusivamente alle persone indicate. La diffusione, copia= o qualsiasi altra azione derivante dalla conoscenza di queste informazioni= sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per = errore siete cortesemente pregati di darne immediata comunicazione al mitte= nte e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.


--bcaec51b19f564718e04a8fd2855-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 18:27:29 +0000 Content-Type: multipart/mixed; boundary="_98bbf91d-e52e-4dd6-a3fb-b8f10260832e_" From: Maglione Roberta To: 'Leaf yeh' , 'Jacni Qin' CC: "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Date: Tue, 26 Jul 2011 20:27:04 +0200 Subject: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIA== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D58@GRFMBX704BA020.griffon.local> Accept-Language: en-US, it-IT Content-Language: en-US acceptlanguage: en-US, it-IT MIME-Version: 1.0 --_98bbf91d-e52e-4dd6-a3fb-b8f10260832e_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D58GRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D58GRFMBX704BA02_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 UGxlYXNlIHNlZSBpbmxpbmUuDQoNCkJlc3QgcmVnYXJkcywNClJvYmVydGENCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IExlYWYgeWVoIFttYWlsdG86bGVhZi55Lnll aEBodWF3ZWkuY29tXQ0KU2VudDogbWFydGVkqKwgMjYgbHVnbGlvIDIwMTEgMjAuMjINClRvOiBN YWdsaW9uZSBSb2JlcnRhOyAnSmFjbmkgUWluJw0KQ2M6IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYt YWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3JnOyBmaW5lX3N6QGh1 YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpTdWJqZWN0OiC08Li0OiBRIG9uIFZlci4t MDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3MgYWZ0ZXIgSUVURjgxIHJhZGV4dCBz ZXNzaW9uDQoNCg0KUm9iZXJ0YSAtIElmIHlvdSB1c2UgdGhlIHNhbWUgYXR0cmlidXRlIGZvciBi b3RoIHNjZW5hcmlvcyBob3cgZG9lcyB0aGUgTkFTIGtub3cgaWYgdGhhdCBwb29sIGlzIGZvciBT TEFBQyBvciBmb3IgU3RhdGVmdWwgREhDUHY2Pw0KDQpOQVMgYWxyZWFkeSBoYXMgdGhvc2UgcG9v bCBuYW1lcyBpbiBpdHMgY29uZmlndXJhdGlvbiwgcmlnaHQ/DQoNCltSTV0geWVzIHBvb2xzIGFy ZSBhbHJlYWR5IGNvbmZpZ3VyZWQgaW4gdGhlIE5BUw0KDQoNCg0KTkFTIGRvZXMga25vdyB3aGlj aCBvbmUgaXMgZm9yIFNMQUFDIHByZWZpeCBwb29sLCB3aGljaCBvbmUgaXMgZm9yIERIQ1B2NiBh ZGRyZXNzIHBvb2wuDQoNCg0KDQpbUk1dIEFsbCB0aGUgY29uZmlndXJlZCBwb29scyBhcmUgdGhl IHNhbWUgZm9yIHRoZSBOQVMsIGluIHRoaXMgY2FzZSBhbiBleHRyYSBsb2dpYyB3b3VsZCBiZSBu ZWVkZWQgdG8gaW5zdHJ1Y3QgdGhlIE5BUyBhYm91dCB3aGljaCBwb29sIGlzIGZvciBTTEFBQyBh bmQgd2hpY2ggb25lIGlzIGZvciBESENQdjYNCg0KDQoNCg0KDQoNCg0KVGhhdKGvcyB3aHkgaW4g bXkgb3BpbmlvbiB0aGUgU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgcmVxdWlyZWQuDQoN Cg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpMZWFmDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCreivP7IyzogTWFnbGlvbmUgUm9iZXJ0YSBbcm9iZXJ0YS5tYWds aW9uZUB0ZWxlY29taXRhbGlhLml0XQ0Kt6LLzcqxvOQ6IDIwMTHE6jfUwjI3yNUgMjoxMw0Ktb06 ICdKYWNuaSBRaW4nDQpDYzogTGVhZiB5ZWg7IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNz QHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5j b207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQrW98ziOiBSRTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0 LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KSGkg SmFjbmksDQogICBJZiB5b3UgdXNlIHRoZSBzYW1lIGF0dHJpYnV0ZSBmb3IgYm90aCBzY2VuYXJp b3MgaG93IGRvZXMgdGhlIE5BUyBrbm93IGlmIHRoYXQgcG9vbCBpcyBmb3IgU0xBQUMgb3IgZm9y IFN0YXRlZnVsIERIQ1B2Nj8NCg0KVGhhbmtzLA0KUmVnYXJkcywNClJvYmVydGENCg0KDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBKYWNuaSBR aW4gW21haWx0bzpqYWNuaXFAZ21haWwuY29tXQ0KU2VudDogbWFydGVkqKwgMjYgbHVnbGlvIDIw MTEgMjAuMDMNClRvOiBNYWdsaW9uZSBSb2JlcnRhDQpDYzogTGVhZiB5ZWg7IGRyYWZ0LWlldGYt cmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmlldGYub3Jn OyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpTdWJqZWN0OiBSZTog USBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4 MSByYWRleHQgc2Vzc2lvbg0KDQpIaSBSb2JlcnRhLA0KDQpJIGFncmVlIHdpdGggeW91IGFib3V0 IHRoZSBzZW1hbnRpY2FsIGxvZ2ljLCB3aGlsZSAiU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wi IGlzIG5vdCBuZWNlc3NhcnksIElNSE8uDQoNCg0KQ2hlZXJzLA0KSmFjbmkNCk9uIFdlZCwgSnVs IDI3LCAyMDExIGF0IDE6NTUgQU0sIE1hZ2xpb25lIFJvYmVydGEgPHJvYmVydGEubWFnbGlvbmVA dGVsZWNvbWl0YWxpYS5pdD4gd3JvdGU6DQpIZWxsbyBMZWFmLA0KICAgIFRoZSBkaWZmZXJlbnQg YXR0cmlidXRlcyBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0IGZvciB0aGUgcG9vbHMgbmFtZSBoYXZl IGFsbCB0aGUgc2FtZSBmb3JtYXQgKGEgc3RyaW5nKSwgYnV0IHNlbWFudGljYWxseSB0aGV5IGFy ZSBkaWZmZXJlbnQsIGFzIHRoZXkgY292ZWQgZGlmZmVyZW50IHNjZW5hcmlvcy4NCkFzIHlvdSBh bHNvIHN1bW1hcml6ZWQgaW4geW91ciBlbWFpbCBiZWxvdywNCg0KRnJhbWVkLVBvb2wgd2FzIGRl c2lnbmVkIGZvciB0aGUgSVB2NCBhZGRyZXNzIHBvb2w7DQpGcmFtZWQtSVB2Ni1Qb29sIHdhcyBk ZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xBQUMgcHJlZml4IHBvb2w7DQpEZWxlZ2F0ZWQtSVB2Ni1Q cmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2LVBEIHByZWZpeCBwb29sOw0KU3RhdGVm dWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgZGVzaWduZWQgZm9yIERIQ1B2NiBhZGRyZXNzIHBvb2w7 DQoNClNvIGVhY2ggYXR0cmlidXRlIGNvdmVycyBhIGRpZmZlcmVudCB1c2UtY2FzZS9zY2VuYXJp byBhbmQgdGhleSBjYW4gYXBwZWFyIGluIHRoZSBzYW1lIFJBRElVUyBwYWNrZXQgYXQgdGhlIHNh bWUgdGltZS4NCklmIHlvdSB3YW50IHRvIHVzZSBhIHNpbmdsZSBwb29sIG5hbWUgdXNlIHRvIGNv dmVyIGFsbCB0aGUgNCB1c2UgY2FzZXMgbGlzdGVkIGFib3ZlLCB5b3Ugd291bGQgYWxzbyBuZWVk IHRvIGRlZmluZSBhIHN0YW5kYXJkIGZvcm1hdC9zeW50YXggZm9yIHRoZSBwb29sIG5hbWUgdGhh dCBhbGxvd3MgdGhlIE5BUyB0byBiZSBhYmxlIHRvIGRpc2FtYmlndWF0ZSBhbW9uZyB0aGUgZGlm ZmVyZW50IHNjZW5hcmlvcyBhbmQgaW4gb3JkZXIgdG8gZG8gdGhhdCB0aGUgTkFTIHdvdWxkIG5l ZWQgdG8gaGF2ZSBhbiBleHRyYSBsb2dpYyB0byBpbmZlciB0aGUgc2VtYW50aWMgb2YgdGhhdCBz cGVjaWZpYyBhdHRyaWJ1dGUgZnJvbSB0aGUgYXNzaWduZWQgbmFtZS4NCkluc3RlYWQgaWYgeW91 IGhhdmUgYSBzcGVjaWZpYyBhdHRyaWJ1dGUgZm9yIGVhY2ggc3BlY2lmaWMgc2NlbmFyaW8sIHRo ZSBzZW1hbnRpYyBpcyBtYXBwZWQgdG8gdGhlIGF0dHJpYnV0ZSBuYW1lLCB0aHVzIHRoZSBOQVMg ZG9lcyBub3QgbmVlZCBhbiBleHRyYSBsb2dpYyB0byBkaXNjb3ZlcnkgdGhlIHB1cnBvc2Ugb2Yg dGhhdCBwb29sIGFuZCB0aGUgcG9vbCBuYW1lIGNhbiBiZSBhbnkgc3RyaW5nLCBubyBsaW1pdGF0 aW9uIG9yIHNwZWNpYWwgc3ludGF4IGlzIGZvcmNlZCBmb3IgdGhlIHBvb2wgbmFtZS4NCg0KDQpU aGFua3MsDQpSZWdhcmRzLA0KUm9iZXJ0YQ0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkZyb206IG93bmVyLXJhZGl1c2V4dEBvcHMuaWV0Zi5vcmcg W21haWx0bzpvd25lci1yYWRpdXNleHRAb3BzLmlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGVhZiB5 ZWgNClNlbnQ6IGx1bmVkqKwgMjUgbHVnbGlvIDIwMTEgMTguMjMNClRvOiBkcmFmdC1pZXRmLXJh ZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZw0K Q2M6IGZpbmVfc3pAaHVhd2VpLmNvbTsgUWl1amluOyBXYW5nc2h1eGlhbmcNClN1YmplY3Q6IFEg b24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2VzcyBhZnRlciBJRVRGODEg cmFkZXh0IHNlc3Npb24NCg0KUXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb246DQoNCldlIGFscmVh ZHkgaGF2ZSB0aGUgZm9sbG93aW5nIFJhZGl1cyBBdHRyaWJ1dGVzIGZvciB0aGUgYWRkcmVzcy9w cmVmaXggcG9vbHM6DQoNCkZyYW1lZC1Qb29sICg4OCwgc2VjdGlvbiA1LjE4IG9mIFJGQzI4Njkp LA0KRnJhbWVkLUlQdjYtUG9vbCAoMTAwLCBzZWN0aW9uIDIuNiBvZiBSRkMzMTYyKS4NCg0KaHR0 cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9yYWRpdXMtdHlwZXMvcmFkaXVzLXR5cGVzLnht bA0KDQpUaGUgZm9yYW10IGFyZSB0aGUgc2FtZSBhcyBmb2xsb3dzOg0KDQowICAgICAgICAgICAg ICAgICAgIDEgICAgICAgICAgICAgICAgICAgMg0KMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCnwgICAgIFR5cGUgICAgICB8ICAgIExlbmd0aCAgICAgfCAgICAgU3Ry aW5nLi4uDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQoNCmRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLTA1IGlzIHByb3Bvc2luZyAyIG5ldyBh dHRyaWJ1dGVzIGZvciBhZGRyZXNzL3ByZWZpeCBwb29sczoNCg0KRGVsZWdhdGVkLUlQdjYtUHJl Zml4LVBvb2wsDQpTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCwNCg0KdGhlIGZvbWF0IG9mIHRo ZXNlIDIgYXR0cmlidXRlcyBhcmUgdGhlIHNhbWUgYXMgdGhlIGFib3ZlIG9uZS4NCg0KDQpTdXBw b3NlZCB0aGUgYWJvdmUgYXR0cmlidXRlcyBjb3VsZCBiZSBleHBsYWluZWQgYXMgZm9sbG93czoN Cg0KRnJhbWVkLVBvb2wgd2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NCBhZGRyZXNzIHBvb2w7DQpG cmFtZWQtSVB2Ni1Qb29sIHdhcyBkZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xBQUMgcHJlZml4IHBv b2w7DQpEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2LVBE IHByZWZpeCBwb29sOw0KU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgZGVzaWduZWQgZm9y IERIQ1B2NiBhZGRyZXNzIHBvb2w7DQoNCkFsbCBhYm92ZSBhdHRyaWJ1dGVzIGFyZSBvbmx5IHVz ZWQgdG8gcHJvdmlkZSB0aGUgbmFtZSBvZiB0aGUgYWRkcmVzcy9wcmVmaXggcG9vbHMgaW4gYSAn c3RyaW5nJy4gSSBkb3VidCB0aGUgbmVjZXNzaXR5IHRvIG1ha2Ugc28gbWFueSAnbmFtZScgb3Ig J3N0cmluZycgYXR0cmlidXRlcyBmb3IgdGhlIGRpZmZlcmVudCBhZGRyZXNzL3ByZWZpeCBwb29s cyB0byBwcmV2ZW50IHRoZSBhbWJpZ3VpdHkuIEkgZ3Vlc3MgMSBhdHRyaWJ1dGUgZm9yIHRoZSBu YW1lIG9mIHRoZSBhZGRyZXNzL3ByZWZpeCBwb29scyBtaWdodCBiZSBlbm91Z2guIEluIGZhY3Qs IHRoZSBOQVMgdGFrZSB0aGUgcm9sZSB0byBpbnRlcnByZXQgdGhlIG1lYW5pbmcgb2YgdGhlIHBv b2sgbmFtZSwgcmlnaHQ/DQoNCkkgdGhpbmsgRnJhbWVkLVBvb2wgY2FuIGJlIHJlLXVzZWQgZm9y IHRoZSBkZXNpZ24gcHVycG9zZSBvZiBTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbC4gRG8gd2Ug aGF2ZSBhbnkgbGltaXRhdGlvbiBvbiB0aGUgdXNhZ2Ugb2YgRnJhbWVkLVBvb2wgZm9yIElQdjY/ DQpJIHRoaW5rIEZyYW1lZC1JUHY2LVBvb2wgY2FuIGJlIHJlLXVzZWQgZm9yIHRoZSBkZXNpZ24g cHVycG9zZSBvZiBEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCB0byBpbmRpY2F0ZSBhIHBvb2wg b2YgSVB2NiBwcmVmaXggcG9vbC4gSSBjb3VsZCBldmVuIHRoaW5rIEZyYW1lZC1Qb29sIGNhbiBy ZXBsYWNlIEZyYW1lZC1JUHY2LVBvb2wgdG8gaW5kaWNhdGUgdGhlIG5hbWUgb2YgYSBJUHY2IHBy ZWZpeC9hZGRyZXNzIHBvb2wgcGVyIHRoZSBzYW1lIGxvZ2ljLiBBbSBJIHJpZ2h0Pw0KDQoNCkJl c3QgUmVnYXJkcywNCkxlYWYNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClF1ZXN0byBtZXNzYWdn aW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxl IHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJh IGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25p IHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVl c3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRh cm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBh bGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29w eWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVy biBlLW1haWwsIFRoYW5rcy4NClJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVz dGEgbWFpbCBzZSBub24gqKggbmVjZXNzYXJpby4NCg0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBz dW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25l IGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUg ZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJp Z29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1 bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1l ZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEg ZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBp cyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50 ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywg cHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1h aWwsIFRoYW5rcy4NClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRp cml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lv bmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3Nj ZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBR dWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRl IGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFs IG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0K DQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3Nl ZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55 Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBh bmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQpbY2lkOjAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAxQFRJLkRpc2NsYWltZXJdUmlzcGV0dGEgbCdh bWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiCoqCBuZWNlc3NhcmlvLg0K DQo= --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D58GRFMBX704BA02_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
hi,
<= br>Here is an example from another perspective,

What if I use DHCPv4= ? Then a corresponding attribute for IPv4 is needed?


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:37 AM, Maglione Roberta <roberta= .maglione@telecomitalia.it> wrote:

The string only co= ntains a name, how does the NAS infer the semantic of that pool name (meani= ng SLAAC or DHCPv6) from the name?

=A0<= /span>

Roberta<= /u>

=A0<= /span>

From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 20= 11 20.33

=A0

hi,

That's what the "String" is for? :-)


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta <roberta.maglione@telecomitalia.it> wr= ote:

Hi Jacni,
=A0 If you use the same attribute for both scenarios how does the NAS know = if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session


Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.mag= lione@telecomitalia.it> wrote:
Hello Leaf,
=A0 =A0The different attributes proposed in this draft for the pools name h= ave all the same format (a string), but semantically they are different, as= they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: own= er-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of= Leaf yeh
Sent: luned=EC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org
Cc: fine_sz@huawei.= com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=A0=A0=A0=A0 Type =A0 =A0 =A0|=A0=A0=A0 Length =A0 =A0 |=A0=A0=A0=A0 Strin= g...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'n= ame' or 'string' attributes for the different address/prefix po= ols to prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

Rispetta l'ambien= te. Non stampare questa mail se non =E8 necessario.

Questo messaggio e i = suoi allegati sono indirizzati esclusivamente alle persone indicate. La dif= fusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualor= a abbiate ricevuto questo documento per errore siete cortesemente pregati d= i darne immediata comunicazione al mittente e di provvedere alla sua distru= zione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

=A0

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=A0is=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta l= 'ambiente. Non stampare questa mail se non =E8 necessario.


Please see inline.

 

Best regards,=

Roberta

 

From: Leaf= yeh [mailto:leaf.y.yeh@huawei.com]
Sent: marted=A8=AC 26 luglio= 2011 20.22
To: Maglione Roberta; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-a= ccess@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

 

Roberta - If you use the same attribut= e for both scenarios how does the NAS know if that pool is for SLAAC or for= Stateful DHCPv6?

NAS already has those pool names in its configuration, right?=

[RM] yes pools are already configured in the NAS

 

NAS does know which one is for SLAAC p= refix pool, which one is for DHCPv6 address pool. 

 

[RM] All the configured pools are the same for the NAS, i= n this case an extra logic would be needed to instruct the NAS about which = pool is for SLAAC and which one is for DHCPv6

 

 

 

That=A1=AFs why in my opinion the Stateful-IPv6-Address-P= ool is required.

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB: Maglione Roberta [roberta.magl= ione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1=BC=E4= : 2011=C4=EA7=D4=C227=C8=D5 2:13
=B5=BD: 'Jacni Qin'
Cc: Leaf yeh; draft-ietf-rad= ext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
=D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext sess= ion

Hi Jacni,
   If you use the same attribute for both scenarios how does the = NAS know if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mail= to:jacniq@gmail.com]
Sent: marted=A8=AC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_s= z@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session

Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Rober= ta <roberta.maglione@telecomitalia.it> wrote:
Hello Leaf,
    The different attributes proposed in this draft for the = pools name have all the same format (a string), but semantically they are d= ifferent, as they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: owner-radiusext@ops.ietf.org [mai= lto:owner-radiusext@ops.ietf.org] On Behalf Of Leaf yeh
Sent: luned=A8=AC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org
Cc: fine_sz@huawei.com; Qiujin= ; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0            &n= bsp;      1      &nb= sp;            2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |  &= nbsp; Length     |     String... +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =A8=A8 necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D58GRFMBX704BA02_-- --_98bbf91d-e52e-4dd6-a3fb-b8f10260832e_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_98bbf91d-e52e-4dd6-a3fb-b8f10260832e_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 18:22:27 +0000 Date: Tue, 26 Jul 2011 18:21:57 +0000 From: Leaf yeh Subject: =?gb2312?B?tPC4tDogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYt?= =?gb2312?Q?access_after_IETF81_radext_session?= To: Maglione Roberta , 'Jacni Qin' Cc: "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Message-id: <5B27BA75-FA0F-4082-9C52-E2CBD2D63A98@mimectl> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UbXM7U5MVkvMlF4WkDxAaA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3s= --Boundary_(ID_UbXM7U5MVkvMlF4WkDxAaA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 Um9iZXJ0YSAtIElmIHlvdSB1c2UgdGhlIHNhbWUgYXR0cmlidXRlIGZvciBib3RoIHNjZW5hcmlv cyBob3cgZG9lcyB0aGUgTkFTIGtub3cgaWYgdGhhdCBwb29sIGlzIGZvciBTTEFBQyBvciBmb3Ig U3RhdGVmdWwgREhDUHY2Pw0KDQpOQVMgYWxyZWFkeSBoYXMgdGhvc2UgcG9vbCBuYW1lcyBpbiBp dHMgY29uZmlndXJhdGlvbiwgcmlnaHQ/DQoNCk5BUyBkb2VzIGtub3cgd2hpY2ggb25lIGlzIGZv ciBTTEFBQyBwcmVmaXggcG9vbCwgd2hpY2ggb25lIGlzIGZvciBESENQdjYgYWRkcmVzcyBwb29s Lg0KDQoNCg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KTGVhZg0KDQoNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IE1hZ2xpb25lIFJvYmVydGEgW3JvYmVydGEu bWFnbGlvbmVAdGVsZWNvbWl0YWxpYS5pdF0NCreiy83KsbzkOiAyMDExxOo31MIyN8jVIDI6MTMN CrW9OiAnSmFjbmkgUWluJw0KQ2M6IExlYWYgeWVoOyBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFj Y2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZzsgZmluZV9zekBodWF3 ZWkuY29tOyBRaXVqaW47IFdhbmdzaHV4aWFuZw0K1vfM4jogUkU6IFEgb24gVmVyLi0wNSBvZiBk cmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2VzcyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb24N Cg0KSGkgSmFjbmksDQogICBJZiB5b3UgdXNlIHRoZSBzYW1lIGF0dHJpYnV0ZSBmb3IgYm90aCBz Y2VuYXJpb3MgaG93IGRvZXMgdGhlIE5BUyBrbm93IGlmIHRoYXQgcG9vbCBpcyBmb3IgU0xBQUMg b3IgZm9yIFN0YXRlZnVsIERIQ1B2Nj8NCg0KVGhhbmtzLA0KUmVnYXJkcywNClJvYmVydGENCg0K DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBK YWNuaSBRaW4gW21haWx0bzpqYWNuaXFAZ21haWwuY29tXQ0KU2VudDogbWFydGVkqKwgMjYgbHVn bGlvIDIwMTEgMjAuMDMNClRvOiBNYWdsaW9uZSBSb2JlcnRhDQpDYzogTGVhZiB5ZWg7IGRyYWZ0 LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRAb3BzLmll dGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpTdWJqZWN0 OiBSZTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVy IElFVEY4MSByYWRleHQgc2Vzc2lvbg0KDQpIaSBSb2JlcnRhLA0KDQpJIGFncmVlIHdpdGggeW91 IGFib3V0IHRoZSBzZW1hbnRpY2FsIGxvZ2ljLCB3aGlsZSAiU3RhdGVmdWwtSVB2Ni1BZGRyZXNz LVBvb2wiIGlzIG5vdCBuZWNlc3NhcnksIElNSE8uDQoNCg0KQ2hlZXJzLA0KSmFjbmkNCk9uIFdl ZCwgSnVsIDI3LCAyMDExIGF0IDE6NTUgQU0sIE1hZ2xpb25lIFJvYmVydGEgPHJvYmVydGEubWFn bGlvbmVAdGVsZWNvbWl0YWxpYS5pdD4gd3JvdGU6DQpIZWxsbyBMZWFmLA0KICAgIFRoZSBkaWZm ZXJlbnQgYXR0cmlidXRlcyBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0IGZvciB0aGUgcG9vbHMgbmFt ZSBoYXZlIGFsbCB0aGUgc2FtZSBmb3JtYXQgKGEgc3RyaW5nKSwgYnV0IHNlbWFudGljYWxseSB0 aGV5IGFyZSBkaWZmZXJlbnQsIGFzIHRoZXkgY292ZWQgZGlmZmVyZW50IHNjZW5hcmlvcy4NCkFz IHlvdSBhbHNvIHN1bW1hcml6ZWQgaW4geW91ciBlbWFpbCBiZWxvdywNCg0KRnJhbWVkLVBvb2wg d2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NCBhZGRyZXNzIHBvb2w7DQpGcmFtZWQtSVB2Ni1Qb29s IHdhcyBkZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xBQUMgcHJlZml4IHBvb2w7DQpEZWxlZ2F0ZWQt SVB2Ni1QcmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2LVBEIHByZWZpeCBwb29sOw0K U3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgZGVzaWduZWQgZm9yIERIQ1B2NiBhZGRyZXNz IHBvb2w7DQoNClNvIGVhY2ggYXR0cmlidXRlIGNvdmVycyBhIGRpZmZlcmVudCB1c2UtY2FzZS9z Y2VuYXJpbyBhbmQgdGhleSBjYW4gYXBwZWFyIGluIHRoZSBzYW1lIFJBRElVUyBwYWNrZXQgYXQg dGhlIHNhbWUgdGltZS4NCklmIHlvdSB3YW50IHRvIHVzZSBhIHNpbmdsZSBwb29sIG5hbWUgdXNl IHRvIGNvdmVyIGFsbCB0aGUgNCB1c2UgY2FzZXMgbGlzdGVkIGFib3ZlLCB5b3Ugd291bGQgYWxz byBuZWVkIHRvIGRlZmluZSBhIHN0YW5kYXJkIGZvcm1hdC9zeW50YXggZm9yIHRoZSBwb29sIG5h bWUgdGhhdCBhbGxvd3MgdGhlIE5BUyB0byBiZSBhYmxlIHRvIGRpc2FtYmlndWF0ZSBhbW9uZyB0 aGUgZGlmZmVyZW50IHNjZW5hcmlvcyBhbmQgaW4gb3JkZXIgdG8gZG8gdGhhdCB0aGUgTkFTIHdv dWxkIG5lZWQgdG8gaGF2ZSBhbiBleHRyYSBsb2dpYyB0byBpbmZlciB0aGUgc2VtYW50aWMgb2Yg dGhhdCBzcGVjaWZpYyBhdHRyaWJ1dGUgZnJvbSB0aGUgYXNzaWduZWQgbmFtZS4NCkluc3RlYWQg aWYgeW91IGhhdmUgYSBzcGVjaWZpYyBhdHRyaWJ1dGUgZm9yIGVhY2ggc3BlY2lmaWMgc2NlbmFy aW8sIHRoZSBzZW1hbnRpYyBpcyBtYXBwZWQgdG8gdGhlIGF0dHJpYnV0ZSBuYW1lLCB0aHVzIHRo ZSBOQVMgZG9lcyBub3QgbmVlZCBhbiBleHRyYSBsb2dpYyB0byBkaXNjb3ZlcnkgdGhlIHB1cnBv c2Ugb2YgdGhhdCBwb29sIGFuZCB0aGUgcG9vbCBuYW1lIGNhbiBiZSBhbnkgc3RyaW5nLCBubyBs aW1pdGF0aW9uIG9yIHNwZWNpYWwgc3ludGF4IGlzIGZvcmNlZCBmb3IgdGhlIHBvb2wgbmFtZS4N Cg0KDQpUaGFua3MsDQpSZWdhcmRzLA0KUm9iZXJ0YQ0KDQoNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IG93bmVyLXJhZGl1c2V4dEBvcHMuaWV0 Zi5vcmcgW21haWx0bzpvd25lci1yYWRpdXNleHRAb3BzLmlldGYub3JnXSBPbiBCZWhhbGYgT2Yg TGVhZiB5ZWgNClNlbnQ6IGx1bmVkqKwgMjUgbHVnbGlvIDIwMTEgMTguMjMNClRvOiBkcmFmdC1p ZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRm Lm9yZw0KQ2M6IGZpbmVfc3pAaHVhd2VpLmNvbTsgUWl1amluOyBXYW5nc2h1eGlhbmcNClN1Ympl Y3Q6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2VzcyBhZnRlciBJ RVRGODEgcmFkZXh0IHNlc3Npb24NCg0KUXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb246DQoNCldl IGFscmVhZHkgaGF2ZSB0aGUgZm9sbG93aW5nIFJhZGl1cyBBdHRyaWJ1dGVzIGZvciB0aGUgYWRk cmVzcy9wcmVmaXggcG9vbHM6DQoNCkZyYW1lZC1Qb29sICg4OCwgc2VjdGlvbiA1LjE4IG9mIFJG QzI4NjkpLA0KRnJhbWVkLUlQdjYtUG9vbCAoMTAwLCBzZWN0aW9uIDIuNiBvZiBSRkMzMTYyKS4N Cg0KaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9yYWRpdXMtdHlwZXMvcmFkaXVzLXR5 cGVzLnhtbA0KDQpUaGUgZm9yYW10IGFyZSB0aGUgc2FtZSBhcyBmb2xsb3dzOg0KDQowICAgICAg ICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMg0KMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCnwgICAgIFR5cGUgICAgICB8ICAgIExlbmd0aCAgICAgfCAg ICAgU3RyaW5nLi4uDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQoNCmRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLTA1IGlzIHByb3Bvc2luZyAy IG5ldyBhdHRyaWJ1dGVzIGZvciBhZGRyZXNzL3ByZWZpeCBwb29sczoNCg0KRGVsZWdhdGVkLUlQ djYtUHJlZml4LVBvb2wsDQpTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCwNCg0KdGhlIGZvbWF0 IG9mIHRoZXNlIDIgYXR0cmlidXRlcyBhcmUgdGhlIHNhbWUgYXMgdGhlIGFib3ZlIG9uZS4NCg0K DQpTdXBwb3NlZCB0aGUgYWJvdmUgYXR0cmlidXRlcyBjb3VsZCBiZSBleHBsYWluZWQgYXMgZm9s bG93czoNCg0KRnJhbWVkLVBvb2wgd2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NCBhZGRyZXNzIHBv b2w7DQpGcmFtZWQtSVB2Ni1Qb29sIHdhcyBkZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xBQUMgcHJl Zml4IHBvb2w7DQpEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhD UHY2LVBEIHByZWZpeCBwb29sOw0KU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgZGVzaWdu ZWQgZm9yIERIQ1B2NiBhZGRyZXNzIHBvb2w7DQoNCkFsbCBhYm92ZSBhdHRyaWJ1dGVzIGFyZSBv bmx5IHVzZWQgdG8gcHJvdmlkZSB0aGUgbmFtZSBvZiB0aGUgYWRkcmVzcy9wcmVmaXggcG9vbHMg aW4gYSAnc3RyaW5nJy4gSSBkb3VidCB0aGUgbmVjZXNzaXR5IHRvIG1ha2Ugc28gbWFueSAnbmFt ZScgb3IgJ3N0cmluZycgYXR0cmlidXRlcyBmb3IgdGhlIGRpZmZlcmVudCBhZGRyZXNzL3ByZWZp eCBwb29scyB0byBwcmV2ZW50IHRoZSBhbWJpZ3VpdHkuIEkgZ3Vlc3MgMSBhdHRyaWJ1dGUgZm9y IHRoZSBuYW1lIG9mIHRoZSBhZGRyZXNzL3ByZWZpeCBwb29scyBtaWdodCBiZSBlbm91Z2guIElu IGZhY3QsIHRoZSBOQVMgdGFrZSB0aGUgcm9sZSB0byBpbnRlcnByZXQgdGhlIG1lYW5pbmcgb2Yg dGhlIHBvb2sgbmFtZSwgcmlnaHQ/DQoNCkkgdGhpbmsgRnJhbWVkLVBvb2wgY2FuIGJlIHJlLXVz ZWQgZm9yIHRoZSBkZXNpZ24gcHVycG9zZSBvZiBTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbC4g RG8gd2UgaGF2ZSBhbnkgbGltaXRhdGlvbiBvbiB0aGUgdXNhZ2Ugb2YgRnJhbWVkLVBvb2wgZm9y IElQdjY/DQpJIHRoaW5rIEZyYW1lZC1JUHY2LVBvb2wgY2FuIGJlIHJlLXVzZWQgZm9yIHRoZSBk ZXNpZ24gcHVycG9zZSBvZiBEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCB0byBpbmRpY2F0ZSBh IHBvb2wgb2YgSVB2NiBwcmVmaXggcG9vbC4gSSBjb3VsZCBldmVuIHRoaW5rIEZyYW1lZC1Qb29s IGNhbiByZXBsYWNlIEZyYW1lZC1JUHY2LVBvb2wgdG8gaW5kaWNhdGUgdGhlIG5hbWUgb2YgYSBJ UHY2IHByZWZpeC9hZGRyZXNzIHBvb2wgcGVyIHRoZSBzYW1lIGxvZ2ljLiBBbSBJIHJpZ2h0Pw0K DQoNCkJlc3QgUmVnYXJkcywNCkxlYWYNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClF1ZXN0byBt ZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50 ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNp IGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3Jt YXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1 dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRp IGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZl ZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KVGhpcyBlLW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlv biwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlz ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5 IHJldHVybiBlLW1haWwsIFRoYW5rcy4NClJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFy ZSBxdWVzdGEgbWFpbCBzZSBub24gqKggbmVjZXNzYXJpby4NCg0KDQpRdWVzdG8gbWVzc2FnZ2lv IGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBw ZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBh emlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBz b25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0 byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJu ZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxs YSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29w eWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVy biBlLW1haWwsIFRoYW5rcy4NCg0K --Boundary_(ID_UbXM7U5MVkvMlF4WkDxAaA) Content-id: Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Roberta - If you use the same attribute for both scenarios how does= the NAS know if that pool is for SLAAC or for Stateful DHCPv6?

NAS already has those pool names in its configuration, right?

NAS does know which one is for SLAAC prefix pool, which one is for = DHCPv6 address pool. 

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB: Maglione Roberta [roberta.maglione@telecomit= alia.it]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:13
=B5=BD: 'Jacni Qin'
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusex= t@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
=D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access afte= r IETF81 radext session

Hi Jacni,
   If you use the same attribute for both scenarios how does the = NAS know if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mail= to:jacniq@gmail.com]
Sent: marted=A8=AC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session

Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.maglione@tele= comitalia.it> wrote:
Hello Leaf,
    The different attributes proposed in this draft for the = pools name have all the same format (a string), but semantically they are d= ifferent, as they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Beha= lf Of Leaf yeh
Sent: luned=A8=AC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0            &n= bsp;      1      &nb= sp;            2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |  &= nbsp; Length     |     String... +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

--Boundary_(ID_UbXM7U5MVkvMlF4WkDxAaA)-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 18:13:52 +0000 From: Maglione Roberta To: 'Jacni Qin' CC: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Date: Tue, 26 Jul 2011 20:13:28 +0200 Subject: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Index: AcxLvlJ0Qx+z2Ps6RwO1/gA6tvoZHQAARHyA Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D57@GRFMBX704BA020.griffon.local> Accept-Language: en-US, it-IT Content-Language: en-US acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi Jacni, If you use the same attribute for both scenarios how does the NAS know i= f that pool is for SLAAC or for Stateful DHCPv6? Thanks, Regards, Roberta ________________________________________ From: Jacni Qin [mailto:jacniq@gmail.com] Sent: marted=EC 26 luglio 2011 20.03 To: Maglione Roberta Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session Hi Roberta, I agree with you about the semantical logic, while "Stateful-IPv6-Address-P= ool" is not necessary, IMHO. Cheers, Jacni On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta wrote: Hello Leaf, The different attributes proposed in this draft for the pools name have= all the same format (a string), but semantically they are different, as th= ey coved different scenarios. As you also summarized in your email below, Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time. If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic= to infer the semantic of that specific attribute from the assigned name. Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name. Thanks, Regards, Roberta ________________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= Behalf Of Leaf yeh Sent: luned=EC 25 luglio 2011 18.23 To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session Question for clarification: We already have the following Radius Attributes for the address/prefix pool= s: Framed-Pool (88, section 5.18 of RFC2869), Framed-IPv6-Pool (100, section 2.6 of RFC3162). http://www.iana.org/assignments/radius-types/radius-types.xml The foramt are the same as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=A0=A0=A0=A0 Type |=A0=A0=A0 Length |=A0=A0=A0=A0 String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools: Delegated-IPv6-Prefix-Pool, Stateful-IPv6-Address-Pool, the fomat of these 2 attributes are the same as the above one. Supposed the above attributes could be explained as follows: Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be= enough. In fact, the NAS take the role to interpret the meaning of the poo= k name, right? I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6? I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right? Best Regards, Leaf Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 18:03:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N4JVJDiYEUi3UQUIIJQKIPHS1qM7K6zbX1w5p1ksrgs=; b=rmvJrsdKAgCU2qTlhcyedzieDOxEj9VkM2ESQNyM3YnkhNlqcbPku/QgjVAqhWqtMP /nuoWo75DQaeubWybR1fXMqeTGRYthpNBOK1KRRzWT9C2vFxa/5zeX5/b0Dy1cWx1pYa tT/v078DXtSMhi/OaTD3rdUZJO/srRQq92T3w= MIME-Version: 1.0 Date: Wed, 27 Jul 2011 02:03:25 +0800 Message-ID: Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session From: Jacni Qin To: Maglione Roberta Cc: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang Content-Type: multipart/alternative; boundary=20cf3078118090851804a8fcbf46 --20cf3078118090851804a8fcbf46 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roberta, I agree with you about the semantical logic, while "Stateful-IPv6-Address-Pool" is not necessary, IMHO. Cheers, Jacni On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta < roberta.maglione@telecomitalia.it> wrote: > ** > > Hello Leaf,**** > > The different attributes proposed in this draft for the pools name ha= ve > all the same format (a string), but semantically they are different, as t= hey > coved different scenarios.**** > > As you also summarized in your email below,**** > > ** ** > > Framed-Pool was designed for the IPv4 address pool; **** > > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;**** > > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;**** > > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;**** > > ** ** > > So each attribute covers a different use-case/scenario and they can appea= r > in the same RADIUS packet at the same time.**** > > If you want to use a single pool name use to cover all the 4 use cases > listed above, you would also need to define a standard format/syntax for = the > pool name that allows the NAS to be able to disambiguate among the differ= ent > scenarios and in order to do that the NAS would need to have an extra log= ic > to infer the semantic of that specific attribute from the assigned name. = * > *** > > Instead if you have a specific attribute for each specific scenario, the > semantic is mapped to the attribute name, thus the NAS does not need an > extra logic to discovery the purpose of that pool and the pool name can b= e > any string, no limitation or special syntax is forced for the pool name.*= * > ** > > ** ** > > ** ** > > Thanks,**** > > Regards,**** > > Roberta **** > > ** ** > > **** > > **** > > ** ** > > ** ** > ------------------------------ > > *From:* owner-**radiusext@ops.ietf.org** [mailto:owner-** > radiusext@ops.ietf.org**] *On Behalf Of *Leaf yeh > *Sent:* luned=EC 25 luglio 2011 18.23 > *To:* draft-ietf-radext-ipv6-access@tools.ietf.org; ** > radiusext@ops.ietf.org** > *Cc:* **fine_sz@huawei.com**; Qiujin; Wangshuxiang > *Subject:* Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 > radext session**** > > ** ** > > Question for clarification:**** > > **** > > We already have the following Radius Attributes for the address/prefix > pools:**** > > **** > > Framed-Pool (88, section 5.18 of RFC2869),**** > > Framed-IPv6-Pool (100, section 2.6 of RFC3162).**** > > **** > > http://www.iana.org/assignments/radius-types/radius-types.xml**** > > **** > > The foramt are the same as follows:**** > > **** > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | String... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for > address/prefix pools: **** > > **** > > Delegated-IPv6-Prefix-Pool, > Stateful-IPv6-Address-Pool,**** > > **** > > the fomat of these 2 attributes are the same as the above one.**** > > **** > > **** > > Supposed the above attributes could be explained as follows:**** > > **** > > Framed-Pool was designed for the IPv4 address pool; **** > > Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;**** > > Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;**** > > Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;**** > > **** > > All above attributes are only used to provide the name of the > address/prefix pools in a 'string'. I doubt the necessity to make so many > 'name' or 'string' attributes for the different address/prefix pools > to prevent the ambiguity. I guess 1 attribute for the name of the > address/prefix pools might be enough. In fact, the NAS take the role to > interpret the meaning of the pook name, right?**** > > **** > > I think Framed-Pool can be re-used for the design purpose of Stateful-IPv= 6-Address-Pool. > Do we have any limitation on the usage of Framed-Pool for IPv6? **** > > I think Framed-IPv6-Pool can be re-used for the design purpose of > Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I coul= d > even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name = of > a IPv6 prefix/address pool per the same logic. Am I right?**** > > **** > > **** > > Best Regards,**** > > Leaf**** > > **** > > **** > > **** > > > **** > > **** > > > **** > > **** > > **** > > **** > > **** > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not = the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mai= l > se non =E8 necessario.* > > --20cf3078118090851804a8fcbf46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roberta,

I agree with you about= the semantical logic, while "Stateful-IPv6-Address-Pool" is not = necessary, IMHO.


Cheers,
Jacni

On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.maglione@telecomi= talia.it> wrote:

Hello Leaf,

=A0=A0=A0 The different attributes proposed in this = draft for the pools name have all the same format (a string), but semantica= lly they are different, as they coved different scenarios.

As you also summarized in your email below,

=A0

Framed-Pool=A0was designed for the= =A0IPv4 address pool;=A0

Framed-IPv6-Pool was designed for = the IPv6 SLAAC prefix pool;

Delegated-IPv6-Prefix-Pool=A0is desi= gned for DHCPv6-PD prefix pool;

Stateful-IPv6-Address-Pool=A0is desi= gned for DHCPv6 address pool;

=A0

So each attribute covers a different use-case/= scenario and they can appear in the same RADIUS packet at the same time.=

If you want to use a single pool name use to cover a= ll the 4 use cases listed above, you would also need to define a standard f= ormat/syntax for the pool name that allows the NAS to be able to disambiguate among the different scenarios and in or= der to do that the NAS would need to have an extra logic to infer the seman= tic of that specific attribute from the assigned name.

Instead if you have a specific attribute for each sp= ecific scenario, the semantic is mapped to the attribute name, thus the NAS= does not need an extra logic to discovery the purpose of that pool and the pool name can be any string, no limitatio= n or special syntax is forced for the pool name.

=A0

=A0

Thanks,

Regards,

Roberta=A0

=A0

=A0=A0=A0

=A0

=A0<= /span>

=A0<= /span>

From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.o= rg] On Behalf Of Leaf yeh
Sent: luned=EC 25 luglio 201= 1 18.23
To: draft-ietf-radext= -ipv6-access@tools.ietf.org; radiusex= t@ops.ietf.org
Cc: fine_sz@huawei.com; Qiuji= n; Wangshuxiang
Subject: Q on Ver.-05 of dra= ft-ietf-radext-ipv6-access after IETF81 radext session=

=A0

Question for clarification:=

=A0

We already have the following Radi= us Attributes for the address/prefix pools:

=A0

Framed-Pool (88, section 5.18 of R= FC2869),

Framed-IPv6-Pool (100, section 2.6= of RFC3162).

=A0

http://www.iana.o= rg/assignments/radius-types/radius-types.xml

=A0

The foramt are the same as follows= :

=A0

0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=A0=A0=A0=A0 Type=A0=A0=A0=A0=A0 |=A0=A0=A0 Length=A0=A0=A0=A0 |=A0=A0=A0= =A0 String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

=A0

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-P= ool,

=A0

the fomat of these 2 attributes are the same as the above one.

=A0

=A0

Supposed the above attributes coul= d be explained as follows:

=A0

Framed-Pool=A0was designed for the= =A0IPv4 address pool;=A0

Framed-IPv6-Pool was designed for = the IPv6 SLAAC prefix pool;

Delegated-IPv6-Prefix-Pool=A0is desi= gned for DHCPv6-PD prefix pool;

Stateful-IPv6-Address-Pool=A0is desi= gned for DHCPv6 address pool;

=A0

All above attributes are only used t= o provide the name=A0of the address/prefix pools in a 'string'. I doubt the necessity = to make so many 'name' or 'string' attributes for the diffe= rent address/prefix pools to=A0prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools=A0might be enough. In= fact, the NAS take the role to interpret the meaning of the pook name, rig= ht?

=A0

I think Framed-Pool can be re-used= for the design purpose of Stateful-IPv6-Address-P= ool. Do we have any limitation on the usage of Framed-Pool for IPv6? <= /font>

I think Framed-IPv6-Pool can be re-u= sed for the design purpose of Delegated-IPv6-Prefix-Pool to indicate a pool= of IPv6 prefix pool. I could even think=A0Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 prefix/address= pool per the same logic. Am I right?

=A0

=A0

Best Regards,

Leaf

=A0

=A0

=A0


=A0

=A0


=A0

=A0

=A0

=A0

=A0

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=A0is=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D=Rispetta l'ambient= e. Non stampare questa mail se non =E8 necessario.


--20cf3078118090851804a8fcbf46-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 17:55:50 +0000 Content-Type: multipart/mixed; boundary="_9c85e923-1310-465d-8460-a4865b7a6f28_" From: Maglione Roberta To: Leaf yeh , "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" CC: "fine_sz@huawei.com" , Qiujin , Wangshuxiang Date: Tue, 26 Jul 2011 19:55:26 +0200 Subject: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-Index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56@GRFMBX704BA020.griffon.local> Accept-Language: en-US, it-IT Content-Language: en-US acceptlanguage: en-US, it-IT MIME-Version: 1.0 --_9c85e923-1310-465d-8460-a4865b7a6f28_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56GRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56GRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Leaf, The different attributes proposed in this draft for the pools name have= all the same format (a string), but semantically they are different, as th= ey coved different scenarios. As you also summarized in your email below, Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time. If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic= to infer the semantic of that specific attribute from the assigned name. Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name. Thanks, Regards, Roberta ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= Behalf Of Leaf yeh Sent: luned=EC 25 luglio 2011 18.23 To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session Question for clarification: We already have the following Radius Attributes for the address/prefix pool= s: Framed-Pool (88, section 5.18 of RFC2869), Framed-IPv6-Pool (100, section 2.6 of RFC3162). http://www.iana.org/assignments/radius-types/radius-types.xml The foramt are the same as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools: Delegated-IPv6-Prefix-Pool, Stateful-IPv6-Address-Pool, the fomat of these 2 attributes are the same as the above one. Supposed the above attributes could be explained as follows: Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be= enough. In fact, the NAS take the role to interpret the meaning of the poo= k name, right? I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6? I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right? Best Regards, Leaf Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56GRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Leaf,

    The different attributes proposed in this draft = for the pools name have all the same format (a string), but semantically th= ey are different, as they coved different scenarios.

As you also summarized in your email below,

 

Framed-Pool was designed for the = IPv4 address pool; 

Framed-IPv6-Pool was designed for the IPv6 = SLAAC prefix pool;

Delegated-IPv6-Prefix-Pool is designed = for DHCPv6-PD prefix pool;

Stateful-IPv6-Address-Pool is designed = for DHCPv6 address pool;

 

So each attribute covers a different use-case/scenario and they can= appear in the same RADIUS packet at the same time.

If you want to use a single pool name use to cover all the 4 use ca= ses listed above, you would also need to define a standard format/syntax fo= r the pool name that allows the NAS to be able to disambiguate among the different scenarios and in or= der to do that the NAS would need to have an extra logic to infer the seman= tic of that specific attribute from the assigned name.

Instead if you have a specific attribute for each specific scenario= , the semantic is mapped to the attribute name, thus the NAS does not need = an extra logic to discovery the purpose of that pool and the pool name can be any string, no limitatio= n or special syntax is forced for the pool name.

 

 

Thanks,

Regards,

Roberta 

 

   

 

 

 

From: owne= r-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Leaf yeh
Sent: luned=EC 25 luglio 201= 1 18.23
To: draft-ietf-radext-ipv6-a= ccess@tools.ietf.org; radiusext@ops.ietf.org
Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of dra= ft-ietf-radext-ipv6-access after IETF81 radext session

 

Question for clarification:

 

We already have the following Radius Attrib= utes for the address/prefix pools:

 

Framed-Pool (88, section 5.18 of RFC2869),<= o:p>

Framed-IPv6-Pool (100, section 2.6 of RFC31= 62).

 

http://www.iana.org/assign= ments/radius-types/radius-types.xml

 

The foramt are the same as follows:

 

0       =             1 &= nbsp;           &nbs= p;     2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |  &= nbsp; Length     |     String... +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

 

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

 

the fomat of these 2 attributes are the same as the above one.

 

 

Supposed the above attributes could be expl= ained as follows:

 

Framed-Pool was designed for the = IPv4 address pool; 

Framed-IPv6-Pool was designed for the IPv6 = SLAAC prefix pool;

Delegated-IPv6-Prefix-Pool is designed = for DHCPv6-PD prefix pool;

Stateful-IPv6-Address-Pool is designed = for DHCPv6 address pool;

 

All above attributes are only used to provid= e the name of the address/prefix pools in a 'string'. I doubt the necessity to make so many 'name' or 'string' attri= butes for the different address/prefix pools to prevent the ambiguity.= I guess 1 attribute for the name of the address/prefix pools might be enough.= In fact, the NAS take the role to interpret the meaning of the pook name, = right?

 

I think Framed-Pool can be re-used for the = design purpose of Stateful-IPv6-Address-P= ool. Do we have any limitation on the usage of Framed-Pool for IPv6?

I think Framed-IPv6-Pool can be re-used for = the design purpose of Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6= prefix pool. I could even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 prefix/address= pool per the same logic. Am I right?

 

 

Best Regards,

Leaf

 

 

 


 

 


 

 

 

 

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D56GRFMBX704BA02_-- --_9c85e923-1310-465d-8460-a4865b7a6f28_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_9c85e923-1310-465d-8460-a4865b7a6f28_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 17:48:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V/0mnh1fKJMYxVXAziywaH7GogROzO4GgbBP5cEMWzM=; b=QEdSbY78n6nw7IxDGyXZBM3/81IfHtlPrzcjreuH+9X3s+0uuxQwJpjvVM/r/6u7Fz QX48T64Tz5PnKcmX2KMNSQvSOp0HisWN+PHe2XKke1SUcptEtqMhjMI1pyRG+cWNDMIj xcBf+1oRYP79I2wJ4mLjnmUJylj/fDkzTsc8s= MIME-Version: 1.0 Date: Wed, 27 Jul 2011 01:47:03 +0800 Message-ID: Subject: Re: RADEXT WG - IETF 81 preliminary meeting notes From: Jacni Qin To: Leaf yeh Cc: "Sanchez, Mauricio (HP Networking)" , "radiusext@ops.ietf.org" , "fine_sz@huawei.com" , Qiujin , Wangshuxiang , Behcet Sarikaya Content-Type: multipart/alternative; boundary=20cf307cff5402ddb004a8fc8508 --20cf307cff5402ddb004a8fc8508 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi, A quick comment, I'm concerned by the "Stateful-IPv6-Address-Pool" attribute, why can't we re-use the Frame-* one? Cheers, Jacni 2011/7/26 Leaf yeh > I've sent a question of clarification to the mailing list agaisnt > draft-ietf-radext-ipv6-access-05. Pls. refer to > https://ops.ietf.org/lists/radiusext/2010/msg00959.html. > > > > Sorry for my poor expression in the Radext session. I'd like to clarify m= y > words in the meeting notes here. > > > > > > > 3. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec > > > http://tools.ietf.org/html/draft-ietf-radext-ipv6-access > > > Presented by Mauricio Sanchez. > > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-5.ppt > > > Questions: > > > Leaf Yeh: In new version, new attribs. Only sends name of pool. *DHCP*= already has a pool. > > > > I meant the attribute of Framed-Pool (88, section 5.18 of RFC2869) here, > which is used to send the pool name from AAA server to NAS server, to > indicate the right pool employed or configured on NAS. > > > > > Doesn=A1=AFt think this is necessary. Attributes in v4 can already do t= his. > There is no need to a v6 pool name. > > > Leaf agreed to send concern to list > > > Roberta Maglione: It is just a pool name. Semantics are different. > > > Bernard Adoba: One is a prefix pool and the other is an address pool. M= ay > need to do both at once. > > > Leaf: But it is only a string. So *DHCP server* can use name format is > disambiguate. > > > > I meant the NAS can interprect the pool name recevived from AAA > server for each kind of usage, such as IPv4 PPP address pool, IPv6 SLAAC > prefix pool, IPv6 DHCPv6 address pool or DHCPv6-PD prefix pool. > > > > > Mauricio Sanchez: Sounds like valid reason for these two attributes. > Please bring comments to > > list. > > > > > > Best Regards, > > Leaf > > > > > > ------------------------------ > > *=B7=A2=BC=FE=C8=CB:* owner-radiusext@ops.ietf.org [owner-radiusext@ops.i= etf.org] =B4=FA=B1=ED > Sanchez, Mauricio (HP Networking) [mauricio.sanchez@hp.com] > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2011=C4=EA7=D4=C226=C8=D5 6:29 > *=B5=BD:* 'radiusext@ops.ietf.org' > *=D6=F7=CC=E2:* RADEXT WG - IETF 81 preliminary meeting notes > > These are the preliminary notes for IETF 81. Many thanks to Mark Jones > for taking notes this morning. Comments/corrections welcome. > > > > -MS > > > > > -------------------------------------------------------------------------= ------------------------------------- > > RADEXT WG Minutes > > IETF 81 > > Quebec, Canada > > Monday, July 25th, 2011 > > Meeting started 9:02 AM and ended 11:27AM EDT. Approximately 35 individua= ls > in meeting > > > > Chairs: > > Jouni Korhonen > > Mauricio Sanchez > > > > 1. Preliminaries > > > > Agenda slides: http://www.ietf.org/proceedings/81/slides/radext-3.pptx > > > > Attendees: Bluesheets circulated. > > Note Well > > Note Takers > > - Note volunteer Mark Jones > > Jabber scribe > > - Alan DeKok jabber scribe > > Agenda bash > > - IPv6, enhancements, security grouped item. No changes to agenda made > > > > **************************************************************** > > > > 2. Radius Extensions for CGN Configurations, Dean Cheng > > http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-radius-ext-00.txt > > > > Presented by Dean Cheng. > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-2.ppt > > Hannes Tschofenig: Slide 3: Do you now assume DHCP between end host and > NAT? > > Dean Cheng: Service Request is a general term but no change. > > Hannes Tschofenig: What happens when NAT runs out of ports? > > Dean Cheng: Number of ports are configured on server. It is used to limit= . > > Hannes Tschofenig: What happens in failure case? i.e. you reach > restriction. > > Dean Cheng: AAA only returns limits. If use wants more ports, ICMP can be > used to indicate > > error. > > Hannes Tschofenig: How do you ensure ICMP reaches end host? > > Dean Cheng: OK. We can discuss offline. > > Mauricio Sanchez: Slide 5: Did you read RFC6158 RADIUS Guidelines > > Dean Cheng: Yes. Need some help on these encoding wrt RADIUS guidelines. > > --- > > Questions: > > Mauricio Sanchez: Where is this in BEHAVE WG? > > Dean: Result of merge of two drafts to BEHAVE. Chair suggested to present > in RADEXT because > > comments received were on RADIUS aspects > > Dan Romanascu: Is this a charter item in BEHAVE. > > Dean: No. Still be chartered. Chair said it is within scope of BEHAVE. > > Dan: What do you need from RADEXT? Advisor? WGLC? > > Dean: BEHAVE suggest to present in RADEXT to get comments. > > Dan: In draft, need to expand acronyms. > > Hannes: (1) Need to define bigger picture. NAT behaviour when it runs out > of resources. Need to know why it fails. (2) AAA client does not live on > NAT. DHCP and NAT are mashed together but it depends how these are relate= d. > > Dean: AAA client is not changed. NAT44 must be co-located with BNG. > > Hannes: Very special scenario. > > Dean: If CNG (NAT44) not colo with BNG this falls apart. > > Dan: Any other mechanisms to configure CNG other than this draft? > > Dean: No change. Only leverages existing deployment. > > > > **************************************************************** > > > > 3. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec > > http://tools.ietf.org/html/draft-ietf-radext-ipv6-access > > Presented by Mauricio Sanchez. > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-5.ppt > > Questions: > > Leaf Yeh: In new version, new attribs. Only sends name of pool. DHCP > already has a pool. > > Doesn=A1=AFt think this is necessary. Attributes in v4 can already do thi= s. > There is no need to a v6 pool name. > > Leaf agreed to send concern to list > > Roberta Maglione: It is just a pool name. Semantics are different. > > Bernard Adoba: One is a prefix pool and the other is an address pool. May > need to do both at > > once. > > Leaf: But it is only a string. So DHCP server can use name format is > disambiguate. > > Mauricio Sanchez: Sounds like valid reason for these two attributes. Plea= se > bring comments to > > list. > > **************************************************************** > > 4. RADIUS accounting for traffic classes, Stefan Winter > > http://tools.ietf.org/html/draft-winter-radext-fancyaccounting > > Presented remotely by Stefan Winter. > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-4.pdf > > Other issues: > > Mark Jones: We don=A1=AFt need to include filter definition in accounting > stream. Just include filter name (bucket label) in the accounting stream. > > Stefan: Ok. Nice and simple. Works for me. > > Dan Romanascu : Reuse definitions from RFC4898 > > Mauricio Sanchez: Concerned about number of drafts to progress. Does not > want to oversubscribe WG. Poll: Who is interested in this work? Who will > help out if WG item? > > Show of hands in room: > > Relevant and useful: No interest. > > Stefan: Will let draft expire unless someone comes forward with interest. > > Mauricio Sanchez: Thanks for spending time on this. > > > > **************************************************************** > > > > 5. Dynamic Peer Discovery, Stefan Winter > > http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery > > Presented by Stefan Winter. > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-0.pdf > > Stefan Winter: Asked about IESG comments on DIME equiv. > > Mark Jones: IESG DISCUSS is on format of Application Protocol Tag. Concer= n > was that the current format indicates a structure. > > Stefan Winter: Any IESG comments on Service Tag? > > Mark Jones: No. Just protocol tags. > > Comments or questions: > > Dan Romanascu: Jouni, Can you comment on issues encountered in DIME? > > Jouni Korhonen: Need to solve this in DIME. Mark gave summary of IESG > concern. > > Dan Romanascu: Do we need to stop work in this? > > Jouni Korhonen: No. > > Mark Jones: Confident that labels will be resolved. Not doing anything > unnatural with our original labels. No reason to stop work on this. > > **************************************************************** > > > > 6. RFC4282bis, Alan DeKok > > Presented by Alan Dekok > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-6.ppt > > Dan Romanascu: So 4282bis strips out internationization, right? How is > this separation being followed in other groups? > > Alan Dekok: Working with PRECIS on that aspect. > > **************************************************************** > > 7. RADIUS Protocol Extensions, Alan DeKok (10 minutes) > > http://tools.ietf.org/html/draft-ietf-radext-radius-extensions > > Presented by Alan Dekok. > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-8.ppt > > Dan Romanascu: So this is a new type and is not backwards compatible? > > Alan: Backwards compatible for proxies that treat as an opaque blob. IANA > says these types (241-244) are not used but they are used in the real wor= ld. > Tough. > > Sam Hartman: I have a draft in abfab requiring this and would like to see > this go fwd. Please don=A1=AFt call it an OID though. > > Alan Dekok: Audit shows that this should handle allocation needs for the > foreseeable future. > > So we don=A1=AFt need adhoc formats. Just help them implement this new fo= rmat. > > **************************************************************** > > > > 8. RADIUS over DTLS, Alan DeKok > > http://tools.ietf.org/html/draft-ietf-radext-dtls > > Presented by Alan Dekok. > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-7.ppt > > No questions. > > **************************************************************** > > 9. RADIUS over TLS, Stefan Winter (10 minutes) > > http://tools.ietf.org/html/draft-ietf-radext-radsec > > Presented remotely by Stefan Winter. > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-1.pdf > > Mauricio: Agree that it is ready for WGLC. Any other comments/questions? > > Dan Romanascu: TCP port allocation. Intention is to reuse port for radsec= . > So are there any backwards compatability issues. > > Stefan Winter: No. Old radsec is the format for RADIUS/TLS. OCS said once > RFC is published they will change their implementation to do it this way. > > > > **************************************************************** > > (Margaret requested to present at RADEXT after agenda bashing had occurre= d > and WG chairs accepted presentation request) > > > > 10. Multihop Federations (Trust Router). > > Margaret Wasserman > > Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-9.pptx > > Philip Hallam-Baker: Looks like UUCP. It was replaced with DNS. Anything > that looks like a namespace should be using DNS. Look at Bridge CAs. Use= d > in PKI space. Lots of univ are in Bridge Cas. Can also use Rulebook > structure so never need a path of more than 2 so don=A1=AFt need > > BGP. > > Margaret Wasserman: This is not about getting to every node. Only about > getting between nodes in AAA infrastructure. They are all IP nodes and > already in BGP > > Philip Hallam-Baker: You will find you use only 10% of BGP and not the > interesting part. > > Hannes: Draft addresses some of the issues. Relationship are not purely > mechanical. Don=A1=AFt want to talk to everyone. Like SAML, Liberty Allia= nce. > Come up with circle of trust. They exist in AAA space. The Trust Router > setup allows shortcuts. > > Alan Dekok: Echo Hannes. Need to represent biz relationships: Who to talk > to depends on who is asking. Still have questions on the details > > Margaret Wasserman: This lets you put policy in interesting places (local > trust router). E.g. not route should Russian nodes even if the route is > shorter. > > Klaas Wierenga: This work is motivated by problems seen in large scale SA= ML > deployments. Esp to express complex polices around who you want to trust. > Share some of Philips concerns > > Philip Hallam-Baker: Working on this problem for 15yrs. Similar to other > approaches that have already been implemented. > > Sam Hartman: This is in the draft. > > Philip: Why not in the presentation? > > Margaret Wasserman: Not accepted as WG item in abfab. Feedback required o= n > abfab list. > > Hannes: Also talking to VOIP folks who are reusing BGP concepts. > > Margaret Wasserman: we have not written these protocols. If a better way, > please explain. > > Philip Hallam-Baker: Thinking as a CA. Someone has to manage it and money > will flow around. The task of introduction is going to be paid. May want = to > pay premium to find a path with a higher degree of trust. > > Margaret Wasserman: Allows for biz intelligence at many different layers. > > Philip Hallam-Baker: Contracts will determine this. Don=A1=AFt need this = hop by > hop. Can take this offline. > > Margaret Wasserman: Would be interested in those pointers to approaches > already tried. > > Klaas Wierenga: This goes beyond abfab. So AD pushed us to present in oth= er > groups that see the same type of problem. Welcome a broad discussion. > > Margaret Wasserman: On agenda in abfab on Friday morning. > > > > > > **************************************************************** > > > > 11. Email list server migration > > Dan Romanascu: Please explain what it means for people on the list. > > Mauricio: Nothing. Should be transparent. Got a process for archive > migration. > > Jouni: Auto move of subscribers to new list. Emails will be forwarded > between lists. > > Secretary will move archives. > > Dan: On behalf of doubters: Can you explain migration of archives? > > Mauricio: Others (Fred Baker) created the process for painless migration = of > archives. So we > > Dan: Do references on the tracker need to change? > > Jouni: Direct links to archives need to be updated. > > Mauricio: Will need to look into that and make sure it is remedied. > > > > **************************************************************** > > 12. Next Steps: WG Chairs & ADs > > WG Goals/Milestones status > > No questions > --20cf307cff5402ddb004a8fc8508 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi,

A quick comment, I'm conc= erned by the "Stateful-IPv6-Address-Pool" attribute, why can'= t we re-use the Frame-* one?


Cheers,
Jacni

2011/7/26 Leaf yeh <leaf.y.yeh@huawei.com>

I've sent a question of clarification to the mai= ling list agaisnt draft-ietf-radext-ipv6-access-05. Pls. refer to https://ops.ietf.org/lists/radiusext/2010/msg00959.html.

 

Sorry for my poor expression in the Radext session. = I'd like to clarify my words in the meeting notes here. 

 

 

> 3. RADIUS Attributes for IPv6 Access Networks, = Wojcieh Dec

> http://tools.ietf.org/html/draft-ie= tf-radext-ipv6-access

> Presented by Mauricio Sanchez.

> Slidedeck: http://www.ietf.org/procee= dings/81/slides/radext-5.ppt

> Questions:

> Leaf  Yeh: In new version, new attribs. On= ly sends name of pool. DHCP already has a pool.

 

I meant the attribute of Framed-Pool (88, sect= ion 5.18 of RFC2869) here, which is used to send the pool name from AAA ser= ver to NAS server, to indicate the right pool employed or configured on NAS= .

 

> Doesn’t think this is necessary. Attribut= es in v4 can already do this. There is no need to a v6 pool name.

> Leaf agreed to send concern to list

> Roberta Maglione: It is just a pool name. Seman= tics are different.

> Bernard Adoba: One is a prefix pool and the oth= er is an address pool. May need to do both at once.

> Leaf: But it is only a string. So DHCP server can use name format is disambiguate.

 

I meant the NAS can interprect the pool name r= ecevived from AAA server for each kind of usage, such as IPv4 PPP= address pool, IPv6 SLAAC prefix pool, IPv6 DHCPv6 address pool or DHCPv6-P= D prefix pool. 

 

> Mauricio Sanchez: Sounds like valid reason for = these two attributes. Please bring comments to

list.

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB: owner-radiusext@ops.ietf.org [owner-radiusext@ops.ietf.= org] =B4=FA=B1=ED Sanchez, Mauricio (HP Networking) [mauricio.sanchez@hp.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C226=C8=D5 6:29
=B5=BD: 'radiusext@ops.ietf.org'
=D6=F7=CC=E2: RADEXT WG - IETF 81 preliminary meeting notes

These are the preliminary notes for IETF 81. Many th= anks to Mark Jones for taking notes this morning.  Comments/correction= s welcome.

 

-MS

 

----------------------------------------------------= ----------------------------------------------------------

RADEXT WG Minutes

IETF 81

Quebec, Canada

Monday, July 25th, 2011

Meeting started 9:02 AM and ended 11:27AM EDT. Appro= ximately 35 individuals in meeting

 

Chairs:

Jouni Korhonen <jouni.korhonen@nsn.com>

Mauricio Sanchez <mauricio.sanchez@hp.com>

 

1. Preliminaries

 

Agenda slides: http://www.ietf.org/procee= dings/81/slides/radext-3.pptx

 

Attendees: Bluesheets circulated.

Note Well

Note Takers

- Note volunteer Mark Jones

Jabber scribe

- Alan DeKok jabber scribe

Agenda bash

- IPv6, enhancements, security grouped item.  N= o changes to agenda made

 

****************************************************= ************

 

2. Radius Extensions for CGN Configurations, Dean Ch= eng

http://www.ietf.org/id/draft-= cheng-behave-cgn-cfg-radius-ext-00.txt

 

Presented by Dean Cheng.

Slidedeck: http://www.ietf.org/proceedings= /81/slides/radext-2.ppt

Hannes Tschofenig: Slide 3: Do you now assume DHCP b= etween end host and NAT?

Dean Cheng: Service Request is a general term but no= change.

Hannes Tschofenig: What happens when NAT runs out of= ports?

Dean Cheng: Number of ports are configured on server= . It is used to limit.

Hannes Tschofenig: What happens in failure case? i.e= . you reach restriction.

Dean Cheng: AAA only returns limits. If use wants mo= re ports, ICMP can be used to indicate

error.

Hannes Tschofenig: How do you ensure ICMP reaches en= d host?

Dean Cheng: OK. We can discuss offline.

Mauricio Sanchez:  Slide 5: Did you read RFC615= 8 RADIUS Guidelines

Dean Cheng: Yes. Need some help on these encoding wr= t RADIUS guidelines.

---

Questions:

Mauricio Sanchez: Where is this in BEHAVE WG?

Dean: Result of merge of two drafts to BEHAVE. Chair= suggested to present in RADEXT because

comments received were on RADIUS aspects

Dan Romanascu: Is this a charter item in BEHAVE.

Dean: No. Still be chartered. Chair said it is withi= n scope of BEHAVE.

Dan: What do you need from RADEXT? Advisor? WGLC?

Dean: BEHAVE suggest to present in RADEXT to get com= ments.

Dan: In draft, need to expand acronyms.

Hannes: (1) Need to define bigger picture. NAT behav= iour when it runs out of resources. Need to know why it fails. (2) AAA clie= nt does not live on NAT. DHCP and NAT are mashed together but it depends ho= w these are related.

Dean: AAA client is not changed. NAT44 must be co-lo= cated with BNG.

Hannes: Very special scenario.

Dean: If CNG (NAT44) not colo with BNG this falls ap= art.

Dan: Any other mechanisms to configure CNG other tha= n this draft?

Dean: No change. Only leverages existing deployment.=

 

****************************************************= ************

 

3. RADIUS Attributes for IPv6 Access Networks, Wojci= eh Dec

http://tools.ietf.org/html/draft-ietf-ra= dext-ipv6-access

Presented by Mauricio Sanchez.

Slidedeck: http://www.ietf.org/proceedings= /81/slides/radext-5.ppt

Questions:

Leaf  Yeh: In new version, new attribs. Only se= nds name of pool. DHCP already has a pool.

Doesn’t think this is necessary. Attributes in= v4 can already do this. There is no need to a v6 pool name.

Leaf agreed to send concern to list

Roberta Maglione: It is just a pool name. Semantics = are different.

Bernard Adoba: One is a prefix pool and the other is= an address pool. May need to do both at

once.

Leaf: But it is only a string. So DHCP server can us= e name format is disambiguate.

Mauricio Sanchez: Sounds like valid reason for these= two attributes. Please bring comments to

list.

****************************************************= ************

4. RADIUS accounting for traffic classes, Stefan Win= ter

http://tools.ietf.org/html/draft-w= inter-radext-fancyaccounting

Presented remotely by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings= /81/slides/radext-4.pdf

Other issues:

Mark Jones: We don’t need to include filter de= finition in accounting stream. Just include filter name (bucket label) in t= he accounting stream.

Stefan: Ok. Nice and simple. Works for me.

Dan Romanascu : Reuse definitions from RFC4898

Mauricio Sanchez: Concerned about number of drafts t= o progress. Does not want to oversubscribe WG. Poll: Who is interested in t= his work? Who will help out if WG item?

Show of hands in room:

Relevant and useful: No interest.

Stefan: Will let draft expire unless someone comes f= orward with interest.

Mauricio Sanchez: Thanks for spending time on this. =

 

****************************************************= ************

 

5. Dynamic Peer Discovery, Stefan Winter

http://tools.ietf.org/html/draft-i= etf-radext-dynamic-discovery

Presented by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings= /81/slides/radext-0.pdf

Stefan Winter: Asked about IESG comments on DIME equ= iv.

Mark Jones: IESG DISCUSS is on format of Application= Protocol Tag. Concern was that the current format indicates a structure.

Stefan Winter: Any IESG comments on Service Tag?

Mark Jones: No. Just protocol tags.

Comments or questions:

Dan Romanascu: Jouni, Can you comment on issues enco= untered in DIME?

Jouni Korhonen: Need to solve this in DIME. Mark gav= e summary of IESG concern.

Dan Romanascu: Do we need to stop work in this?

Jouni Korhonen: No.

Mark Jones: Confident that labels will be resolved. = Not doing anything unnatural with our original labels. No reason to stop wo= rk on this.

****************************************************= ************

 

6. RFC4282bis, Alan DeKok

Presented by Alan Dekok

Slidedeck: http://www.ietf.org/proceedings= /81/slides/radext-6.ppt

Dan Romanascu: So  4282bis strips out internati= onization, right? How is this separation being followed in other groups?

Alan Dekok: Working with PRECIS on that aspect.

****************************************************= ************

7. RADIUS Protocol Extensions, Alan DeKok (10 minute= s)

http://tools.ietf.org/html/draft-i= etf-radext-radius-extensions

Presented by  Alan Dekok.

Slidedeck:  http://www.ietf.org/proce= edings/81/slides/radext-8.ppt

Dan Romanascu: So this is a new type and is not back= wards compatible?

Alan: Backwards compatible for proxies that treat as= an opaque blob. IANA says these types (241-244) are not used but they are = used in the real world. Tough.

Sam Hartman: I have a draft in abfab requiring this = and would like to see this go fwd. Please don’t call it an OID though= . 

 Alan Dekok: Audit shows that this should handl= e allocation needs for the foreseeable future.

So we don’t need adhoc formats. Just help them= implement this new format.

****************************************************= ************

 

8. RADIUS over DTLS, Alan DeKok

http://tools.ietf.org/html/draft-ietf-radext-dt= ls

Presented by  Alan Dekok.

Slidedeck:  http://www.ietf.org/proce= edings/81/slides/radext-7.ppt

No questions.

****************************************************= ************

9. RADIUS over TLS, Stefan Winter (10 minutes)

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

Presented remotely by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings= /81/slides/radext-1.pdf

Mauricio: Agree that it is ready for WGLC. Any other= comments/questions?

Dan Romanascu: TCP port allocation. Intention is to = reuse port for radsec. So are there any  backwards compatability issue= s.

Stefan Winter: No. Old radsec is the format for RADI= US/TLS. OCS said once RFC is published they will change their implementatio= n to do it this way.

 

****************************************************= ************

(Margaret requested to present at RADEXT after agend= a bashing had occurred and WG chairs accepted presentation request) 

 

10. Multihop Federations (Trust Router).

Margaret Wasserman

Slidedeck: http://www.ietf.org/proceeding= s/81/slides/radext-9.pptx

Philip Hallam-Baker: Looks like UUCP. It was replace= d with DNS. Anything that looks like a  namespace should be using DNS.= Look at Bridge CAs. Used in PKI space. Lots of univ are in Bridge Cas. Can= also use Rulebook structure so never need a path of more than 2 so don’t need

BGP.

Margaret Wasserman: This is not about getting to eve= ry node. Only about getting between nodes in AAA infrastructure. They are a= ll IP nodes and already in BGP

Philip Hallam-Baker: You will find you use only 10% = of BGP and not the interesting part.

Hannes: Draft addresses some of the issues. Relation= ship are not purely mechanical. Don’t want to talk to everyone. Like = SAML, Liberty Alliance. Come up with circle of trust. They exist in AAA spa= ce. The Trust Router setup allows shortcuts.

Alan Dekok: Echo Hannes. Need to represent biz relat= ionships: Who to talk to depends on who is asking. Still have questions on = the details

Margaret Wasserman: This lets you put policy in inte= resting places (local trust router). E.g. not route should Russian nodes ev= en if the route is shorter.

Klaas Wierenga: This work is motivated by problems s= een in large scale SAML deployments. Esp to express complex polices around = who you want to trust. Share some of Philips concerns

Philip Hallam-Baker: Working on this problem for 15y= rs. Similar to other approaches that have already been implemented.

Sam Hartman: This is in the draft.

Philip: Why not in the presentation?

Margaret Wasserman: Not accepted as WG item in abfab= . Feedback required on abfab list.

Hannes: Also talking to VOIP folks who are reusing B= GP concepts.

Margaret Wasserman: we have not written these protoc= ols. If a better way, please explain.

Philip Hallam-Baker: Thinking as a CA. Someone has t= o manage it and money will flow around. The task of introduction is going t= o be paid. May want to pay premium to find a path with a higher degree of t= rust.

Margaret Wasserman: Allows for biz intelligence at m= any different layers.

Philip Hallam-Baker: Contracts will determine this. = Don’t need this hop by hop. Can take this offline.

Margaret Wasserman: Would be interested in those poi= nters to approaches already tried.

Klaas Wierenga: This goes beyond abfab. So AD pushed= us to present in other groups that see the same type of problem. Welcome a= broad discussion.

Margaret Wasserman: On agenda in abfab on Friday mor= ning.

 

 

****************************************************= ************

 

11. Email list server migration

Dan Romanascu: Please explain what it means for peop= le on the list.

Mauricio: Nothing. Should be transparent. Got a proc= ess for archive migration.

Jouni: Auto move of subscribers to new list. Emails = will be forwarded between lists. 

Secretary will move archives.

Dan: On behalf of doubters: Can you explain migratio= n of archives?

Mauricio: Others (Fred Baker) created the process fo= r painless migration of archives. So we

Dan: Do references on the tracker need to change?

Jouni: Direct links to archives need to be updated.<= /p>

Mauricio: Will need to look into that and make sure = it is remedied.

 

****************************************************= ************

12. Next Steps: WG Chairs & ADs

WG Goals/Milestones status

No questions


--20cf307cff5402ddb004a8fc8508-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 15:50:48 +0000 Message-ID: <4E2EE238.4040103@deployingradius.com> Date: Tue, 26 Jul 2011 11:50:16 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" CC: "'radiusext@ops.ietf.org'" Subject: Re: Last call on extensions document? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sanchez, Mauricio (HP Networking) wrote: > You mean RFC 2869? Nonetheless, I agree that name has to change and avoid the collision with prior work. How about something like 'RADIUS Attribute Extensions'? Sounds good to me. I'll make the change for the next rev of the document. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 15:28:06 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Alan DeKok CC: "'radiusext@ops.ietf.org'" Date: Tue, 26 Jul 2011 16:26:16 +0100 Subject: RE: Last call on extensions document? Thread-Topic: Last call on extensions document? Thread-Index: AcxLn6fLh8u7tcMKRWWzcveQ2fot6AAB7n/w Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C786AA943@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 You mean RFC 2869? Nonetheless, I agree that name has to change and avoid = the collision with prior work. How about something like 'RADIUS Attribute = Extensions'? -MS =20 -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On= Behalf Of Alan DeKok Sent: Tuesday, July 26, 2011 10:23 AM To: 'radext mailing list' Subject: Last call on extensions document? Can we do a last call on the extensions document? The list has had littl= e discussion on it. I think the name will need to change, as RFC 2868 is already RADIUS exten= sions. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the wo= rd 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 14:23:44 +0000 Message-ID: <4E2ECDC5.5060207@deployingradius.com> Date: Tue, 26 Jul 2011 10:23:01 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: 'radext mailing list' Subject: Last call on extensions document? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Can we do a last call on the extensions document? The list has had little discussion on it. I think the name will need to change, as RFC 2868 is already RADIUS extensions. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 26 Jul 2011 11:39:01 +0000 Date: Tue, 26 Jul 2011 11:37:41 +0000 From: Leaf yeh Subject: Re: RADEXT WG - IETF 81 preliminary meeting notes To: "Sanchez, Mauricio (HP Networking)" , "'radiusext@ops.ietf.org'" Cc: "fine_sz@huawei.com" , Qiujin , Wangshuxiang , Behcet Sarikaya Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_CTBeIIdVcoMZCGN4hjNyyA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: RADEXT WG - IETF 81 preliminary meeting notes Thread-index: AcxLGaaSIMWqzBhyQQq096RhZBECsgAKk+UAABEeaxY= --Boundary_(ID_CTBeIIdVcoMZCGN4hjNyyA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SSd2ZSBzZW50IGEgcXVlc3Rpb24gb2YgY2xhcmlmaWNhdGlvbiB0byB0aGUgbWFpbGluZyBsaXN0 IGFnYWlzbnQgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3MtMDUuIFBscy4gcmVmZXIgdG8g aHR0cHM6Ly9vcHMuaWV0Zi5vcmcvbGlzdHMvcmFkaXVzZXh0LzIwMTAvbXNnMDA5NTkuaHRtbC4N Cg0KU29ycnkgZm9yIG15IHBvb3IgZXhwcmVzc2lvbiBpbiB0aGUgUmFkZXh0IHNlc3Npb24uIEkn ZCBsaWtlIHRvIGNsYXJpZnkgbXkgd29yZHMgaW4gdGhlIG1lZXRpbmcgbm90ZXMgaGVyZS4NCg0K DQo+IDMuIFJBRElVUyBBdHRyaWJ1dGVzIGZvciBJUHY2IEFjY2VzcyBOZXR3b3JrcywgV29qY2ll aCBEZWMNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1yYWRleHQtaXB2 Ni1hY2Nlc3MNCj4gUHJlc2VudGVkIGJ5IE1hdXJpY2lvIFNhbmNoZXouDQo+IFNsaWRlZGVjazog aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84MS9zbGlkZXMvcmFkZXh0LTUucHB0DQo+ IFF1ZXN0aW9uczoNCj4gTGVhZiAgWWVoOiBJbiBuZXcgdmVyc2lvbiwgbmV3IGF0dHJpYnMuIE9u bHkgc2VuZHMgbmFtZSBvZiBwb29sLiBESENQIGFscmVhZHkgaGFzIGEgcG9vbC4NCg0KSSBtZWFu dCB0aGUgYXR0cmlidXRlIG9mIEZyYW1lZC1Qb29sICg4OCwgc2VjdGlvbiA1LjE4IG9mIFJGQzI4 NjkpIGhlcmUsIHdoaWNoIGlzIHVzZWQgdG8gc2VuZCB0aGUgcG9vbCBuYW1lIGZyb20gQUFBIHNl cnZlciB0byBOQVMgc2VydmVyLCB0byBpbmRpY2F0ZSB0aGUgcmlnaHQgcG9vbCBlbXBsb3llZCBv ciBjb25maWd1cmVkIG9uIE5BUy4NCg0KPiBEb2VzbqGvdCB0aGluayB0aGlzIGlzIG5lY2Vzc2Fy eS4gQXR0cmlidXRlcyBpbiB2NCBjYW4gYWxyZWFkeSBkbyB0aGlzLiBUaGVyZSBpcyBubyBuZWVk IHRvIGEgdjYgcG9vbCBuYW1lLg0KPiBMZWFmIGFncmVlZCB0byBzZW5kIGNvbmNlcm4gdG8gbGlz dA0KPiBSb2JlcnRhIE1hZ2xpb25lOiBJdCBpcyBqdXN0IGEgcG9vbCBuYW1lLiBTZW1hbnRpY3Mg YXJlIGRpZmZlcmVudC4NCj4gQmVybmFyZCBBZG9iYTogT25lIGlzIGEgcHJlZml4IHBvb2wgYW5k IHRoZSBvdGhlciBpcyBhbiBhZGRyZXNzIHBvb2wuIE1heSBuZWVkIHRvIGRvIGJvdGggYXQgb25j ZS4NCj4gTGVhZjogQnV0IGl0IGlzIG9ubHkgYSBzdHJpbmcuIFNvIERIQ1Agc2VydmVyIGNhbiB1 c2UgbmFtZSBmb3JtYXQgaXMgZGlzYW1iaWd1YXRlLg0KDQpJIG1lYW50IHRoZSBOQVMgY2FuIGlu dGVycHJlY3QgdGhlIHBvb2wgbmFtZSByZWNldml2ZWQgZnJvbSBBQUEgc2VydmVyIGZvciBlYWNo IGtpbmQgb2YgdXNhZ2UsIHN1Y2ggYXMgSVB2NCBQUFAgYWRkcmVzcyBwb29sLCBJUHY2IFNMQUFD IHByZWZpeCBwb29sLCBJUHY2IERIQ1B2NiBhZGRyZXNzIHBvb2wgb3IgREhDUHY2LVBEIHByZWZp eCBwb29sLg0KDQo+IE1hdXJpY2lvIFNhbmNoZXo6IFNvdW5kcyBsaWtlIHZhbGlkIHJlYXNvbiBm b3IgdGhlc2UgdHdvIGF0dHJpYnV0ZXMuIFBsZWFzZSBicmluZyBjb21tZW50cyB0bw0KbGlzdC4N Cg0KDQpCZXN0IFJlZ2FyZHMsDQpMZWFmDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0Kt6K8/sjLOiBvd25lci1yYWRpdXNleHRAb3BzLmlldGYub3JnIFtvd25l ci1yYWRpdXNleHRAb3BzLmlldGYub3JnXSC0+rHtIFNhbmNoZXosIE1hdXJpY2lvIChIUCBOZXR3 b3JraW5nKSBbbWF1cmljaW8uc2FuY2hlekBocC5jb21dDQq3osvNyrG85DogMjAxMcTqN9TCMjbI 1SA2OjI5DQq1vTogJ3JhZGl1c2V4dEBvcHMuaWV0Zi5vcmcnDQrW98ziOiBSQURFWFQgV0cgLSBJ RVRGIDgxIHByZWxpbWluYXJ5IG1lZXRpbmcgbm90ZXMNCg0KVGhlc2UgYXJlIHRoZSBwcmVsaW1p bmFyeSBub3RlcyBmb3IgSUVURiA4MS4gTWFueSB0aGFua3MgdG8gTWFyayBKb25lcyBmb3IgdGFr aW5nIG5vdGVzIHRoaXMgbW9ybmluZy4gIENvbW1lbnRzL2NvcnJlY3Rpb25zIHdlbGNvbWUuDQoN Ci1NUw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KUkFERVhUIFdHIE1pbnV0ZXMNCklFVEYgODENClF1ZWJlYywgQ2FuYWRhDQpNb25kYXks IEp1bHkgMjV0aCwgMjAxMQ0KTWVldGluZyBzdGFydGVkIDk6MDIgQU0gYW5kIGVuZGVkIDExOjI3 QU0gRURULiBBcHByb3hpbWF0ZWx5IDM1IGluZGl2aWR1YWxzIGluIG1lZXRpbmcNCg0KQ2hhaXJz Og0KSm91bmkgS29yaG9uZW4gPGpvdW5pLmtvcmhvbmVuQG5zbi5jb20+DQpNYXVyaWNpbyBTYW5j aGV6IDxtYXVyaWNpby5zYW5jaGV6QGhwLmNvbT4NCg0KMS4gUHJlbGltaW5hcmllcw0KDQpBZ2Vu ZGEgc2xpZGVzOiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgxL3NsaWRlcy9yYWRl eHQtMy5wcHR4DQoNCkF0dGVuZGVlczogQmx1ZXNoZWV0cyBjaXJjdWxhdGVkLg0KTm90ZSBXZWxs DQpOb3RlIFRha2Vycw0KLSBOb3RlIHZvbHVudGVlciBNYXJrIEpvbmVzDQpKYWJiZXIgc2NyaWJl DQotIEFsYW4gRGVLb2sgamFiYmVyIHNjcmliZQ0KQWdlbmRhIGJhc2gNCi0gSVB2NiwgZW5oYW5j ZW1lbnRzLCBzZWN1cml0eSBncm91cGVkIGl0ZW0uICBObyBjaGFuZ2VzIHRvIGFnZW5kYSBtYWRl DQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioNCg0KMi4gUmFkaXVzIEV4dGVuc2lvbnMgZm9yIENHTiBDb25maWd1cmF0aW9u cywgRGVhbiBDaGVuZw0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1jaGVuZy1iZWhhdmUt Y2duLWNmZy1yYWRpdXMtZXh0LTAwLnR4dA0KDQpQcmVzZW50ZWQgYnkgRGVhbiBDaGVuZy4NClNs aWRlZGVjazogaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84MS9zbGlkZXMvcmFkZXh0 LTIucHB0DQpIYW5uZXMgVHNjaG9mZW5pZzogU2xpZGUgMzogRG8geW91IG5vdyBhc3N1bWUgREhD UCBiZXR3ZWVuIGVuZCBob3N0IGFuZCBOQVQ/DQpEZWFuIENoZW5nOiBTZXJ2aWNlIFJlcXVlc3Qg aXMgYSBnZW5lcmFsIHRlcm0gYnV0IG5vIGNoYW5nZS4NCkhhbm5lcyBUc2Nob2ZlbmlnOiBXaGF0 IGhhcHBlbnMgd2hlbiBOQVQgcnVucyBvdXQgb2YgcG9ydHM/DQpEZWFuIENoZW5nOiBOdW1iZXIg b2YgcG9ydHMgYXJlIGNvbmZpZ3VyZWQgb24gc2VydmVyLiBJdCBpcyB1c2VkIHRvIGxpbWl0Lg0K SGFubmVzIFRzY2hvZmVuaWc6IFdoYXQgaGFwcGVucyBpbiBmYWlsdXJlIGNhc2U/IGkuZS4geW91 IHJlYWNoIHJlc3RyaWN0aW9uLg0KRGVhbiBDaGVuZzogQUFBIG9ubHkgcmV0dXJucyBsaW1pdHMu IElmIHVzZSB3YW50cyBtb3JlIHBvcnRzLCBJQ01QIGNhbiBiZSB1c2VkIHRvIGluZGljYXRlDQpl cnJvci4NCkhhbm5lcyBUc2Nob2ZlbmlnOiBIb3cgZG8geW91IGVuc3VyZSBJQ01QIHJlYWNoZXMg ZW5kIGhvc3Q/DQpEZWFuIENoZW5nOiBPSy4gV2UgY2FuIGRpc2N1c3Mgb2ZmbGluZS4NCk1hdXJp Y2lvIFNhbmNoZXo6ICBTbGlkZSA1OiBEaWQgeW91IHJlYWQgUkZDNjE1OCBSQURJVVMgR3VpZGVs aW5lcw0KRGVhbiBDaGVuZzogWWVzLiBOZWVkIHNvbWUgaGVscCBvbiB0aGVzZSBlbmNvZGluZyB3 cnQgUkFESVVTIGd1aWRlbGluZXMuDQotLS0NClF1ZXN0aW9uczoNCk1hdXJpY2lvIFNhbmNoZXo6 IFdoZXJlIGlzIHRoaXMgaW4gQkVIQVZFIFdHPw0KRGVhbjogUmVzdWx0IG9mIG1lcmdlIG9mIHR3 byBkcmFmdHMgdG8gQkVIQVZFLiBDaGFpciBzdWdnZXN0ZWQgdG8gcHJlc2VudCBpbiBSQURFWFQg YmVjYXVzZQ0KY29tbWVudHMgcmVjZWl2ZWQgd2VyZSBvbiBSQURJVVMgYXNwZWN0cw0KRGFuIFJv bWFuYXNjdTogSXMgdGhpcyBhIGNoYXJ0ZXIgaXRlbSBpbiBCRUhBVkUuDQpEZWFuOiBOby4gU3Rp bGwgYmUgY2hhcnRlcmVkLiBDaGFpciBzYWlkIGl0IGlzIHdpdGhpbiBzY29wZSBvZiBCRUhBVkUu DQpEYW46IFdoYXQgZG8geW91IG5lZWQgZnJvbSBSQURFWFQ/IEFkdmlzb3I/IFdHTEM/DQpEZWFu OiBCRUhBVkUgc3VnZ2VzdCB0byBwcmVzZW50IGluIFJBREVYVCB0byBnZXQgY29tbWVudHMuDQpE YW46IEluIGRyYWZ0LCBuZWVkIHRvIGV4cGFuZCBhY3Jvbnltcy4NCkhhbm5lczogKDEpIE5lZWQg dG8gZGVmaW5lIGJpZ2dlciBwaWN0dXJlLiBOQVQgYmVoYXZpb3VyIHdoZW4gaXQgcnVucyBvdXQg b2YgcmVzb3VyY2VzLiBOZWVkIHRvIGtub3cgd2h5IGl0IGZhaWxzLiAoMikgQUFBIGNsaWVudCBk b2VzIG5vdCBsaXZlIG9uIE5BVC4gREhDUCBhbmQgTkFUIGFyZSBtYXNoZWQgdG9nZXRoZXIgYnV0 IGl0IGRlcGVuZHMgaG93IHRoZXNlIGFyZSByZWxhdGVkLg0KRGVhbjogQUFBIGNsaWVudCBpcyBu b3QgY2hhbmdlZC4gTkFUNDQgbXVzdCBiZSBjby1sb2NhdGVkIHdpdGggQk5HLg0KSGFubmVzOiBW ZXJ5IHNwZWNpYWwgc2NlbmFyaW8uDQpEZWFuOiBJZiBDTkcgKE5BVDQ0KSBub3QgY29sbyB3aXRo IEJORyB0aGlzIGZhbGxzIGFwYXJ0Lg0KRGFuOiBBbnkgb3RoZXIgbWVjaGFuaXNtcyB0byBjb25m aWd1cmUgQ05HIG90aGVyIHRoYW4gdGhpcyBkcmFmdD8NCkRlYW46IE5vIGNoYW5nZS4gT25seSBs ZXZlcmFnZXMgZXhpc3RpbmcgZGVwbG95bWVudC4NCg0KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQozLiBSQURJVVMgQXR0 cmlidXRlcyBmb3IgSVB2NiBBY2Nlc3MgTmV0d29ya3MsIFdvamNpZWggRGVjDQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzcw0KUHJlc2VudGVk IGJ5IE1hdXJpY2lvIFNhbmNoZXouDQpTbGlkZWRlY2s6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvODEvc2xpZGVzL3JhZGV4dC01LnBwdA0KUXVlc3Rpb25zOg0KTGVhZiAgWWVoOiBJ biBuZXcgdmVyc2lvbiwgbmV3IGF0dHJpYnMuIE9ubHkgc2VuZHMgbmFtZSBvZiBwb29sLiBESENQ IGFscmVhZHkgaGFzIGEgcG9vbC4NCkRvZXNuoa90IHRoaW5rIHRoaXMgaXMgbmVjZXNzYXJ5LiBB dHRyaWJ1dGVzIGluIHY0IGNhbiBhbHJlYWR5IGRvIHRoaXMuIFRoZXJlIGlzIG5vIG5lZWQgdG8g YSB2NiBwb29sIG5hbWUuDQpMZWFmIGFncmVlZCB0byBzZW5kIGNvbmNlcm4gdG8gbGlzdA0KUm9i ZXJ0YSBNYWdsaW9uZTogSXQgaXMganVzdCBhIHBvb2wgbmFtZS4gU2VtYW50aWNzIGFyZSBkaWZm ZXJlbnQuDQpCZXJuYXJkIEFkb2JhOiBPbmUgaXMgYSBwcmVmaXggcG9vbCBhbmQgdGhlIG90aGVy IGlzIGFuIGFkZHJlc3MgcG9vbC4gTWF5IG5lZWQgdG8gZG8gYm90aCBhdA0Kb25jZS4NCkxlYWY6 IEJ1dCBpdCBpcyBvbmx5IGEgc3RyaW5nLiBTbyBESENQIHNlcnZlciBjYW4gdXNlIG5hbWUgZm9y bWF0IGlzIGRpc2FtYmlndWF0ZS4NCk1hdXJpY2lvIFNhbmNoZXo6IFNvdW5kcyBsaWtlIHZhbGlk IHJlYXNvbiBmb3IgdGhlc2UgdHdvIGF0dHJpYnV0ZXMuIFBsZWFzZSBicmluZyBjb21tZW50cyB0 bw0KbGlzdC4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioNCjQuIFJBRElVUyBhY2NvdW50aW5nIGZvciB0cmFmZmljIGNsYXNz ZXMsIFN0ZWZhbiBXaW50ZXINCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbnRl ci1yYWRleHQtZmFuY3lhY2NvdW50aW5nDQpQcmVzZW50ZWQgcmVtb3RlbHkgYnkgU3RlZmFuIFdp bnRlci4NClNsaWRlZGVjazogaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84MS9zbGlk ZXMvcmFkZXh0LTQucGRmDQpPdGhlciBpc3N1ZXM6DQpNYXJrIEpvbmVzOiBXZSBkb26hr3QgbmVl ZCB0byBpbmNsdWRlIGZpbHRlciBkZWZpbml0aW9uIGluIGFjY291bnRpbmcgc3RyZWFtLiBKdXN0 IGluY2x1ZGUgZmlsdGVyIG5hbWUgKGJ1Y2tldCBsYWJlbCkgaW4gdGhlIGFjY291bnRpbmcgc3Ry ZWFtLg0KU3RlZmFuOiBPay4gTmljZSBhbmQgc2ltcGxlLiBXb3JrcyBmb3IgbWUuDQpEYW4gUm9t YW5hc2N1IDogUmV1c2UgZGVmaW5pdGlvbnMgZnJvbSBSRkM0ODk4DQpNYXVyaWNpbyBTYW5jaGV6 OiBDb25jZXJuZWQgYWJvdXQgbnVtYmVyIG9mIGRyYWZ0cyB0byBwcm9ncmVzcy4gRG9lcyBub3Qg d2FudCB0byBvdmVyc3Vic2NyaWJlIFdHLiBQb2xsOiBXaG8gaXMgaW50ZXJlc3RlZCBpbiB0aGlz IHdvcms/IFdobyB3aWxsIGhlbHAgb3V0IGlmIFdHIGl0ZW0/DQpTaG93IG9mIGhhbmRzIGluIHJv b206DQpSZWxldmFudCBhbmQgdXNlZnVsOiBObyBpbnRlcmVzdC4NClN0ZWZhbjogV2lsbCBsZXQg ZHJhZnQgZXhwaXJlIHVubGVzcyBzb21lb25lIGNvbWVzIGZvcndhcmQgd2l0aCBpbnRlcmVzdC4N Ck1hdXJpY2lvIFNhbmNoZXo6IFRoYW5rcyBmb3Igc3BlbmRpbmcgdGltZSBvbiB0aGlzLg0KDQoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQoNCjUuIER5bmFtaWMgUGVlciBEaXNjb3ZlcnksIFN0ZWZhbiBXaW50ZXINCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcmFkZXh0LWR5bmFtaWMtZGlzY292ZXJ5 DQpQcmVzZW50ZWQgYnkgU3RlZmFuIFdpbnRlci4NClNsaWRlZGVjazogaHR0cDovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy84MS9zbGlkZXMvcmFkZXh0LTAucGRmDQpTdGVmYW4gV2ludGVyOiBB c2tlZCBhYm91dCBJRVNHIGNvbW1lbnRzIG9uIERJTUUgZXF1aXYuDQpNYXJrIEpvbmVzOiBJRVNH IERJU0NVU1MgaXMgb24gZm9ybWF0IG9mIEFwcGxpY2F0aW9uIFByb3RvY29sIFRhZy4gQ29uY2Vy biB3YXMgdGhhdCB0aGUgY3VycmVudCBmb3JtYXQgaW5kaWNhdGVzIGEgc3RydWN0dXJlLg0KU3Rl ZmFuIFdpbnRlcjogQW55IElFU0cgY29tbWVudHMgb24gU2VydmljZSBUYWc/DQpNYXJrIEpvbmVz OiBOby4gSnVzdCBwcm90b2NvbCB0YWdzLg0KQ29tbWVudHMgb3IgcXVlc3Rpb25zOg0KRGFuIFJv bWFuYXNjdTogSm91bmksIENhbiB5b3UgY29tbWVudCBvbiBpc3N1ZXMgZW5jb3VudGVyZWQgaW4g RElNRT8NCkpvdW5pIEtvcmhvbmVuOiBOZWVkIHRvIHNvbHZlIHRoaXMgaW4gRElNRS4gTWFyayBn YXZlIHN1bW1hcnkgb2YgSUVTRyBjb25jZXJuLg0KRGFuIFJvbWFuYXNjdTogRG8gd2UgbmVlZCB0 byBzdG9wIHdvcmsgaW4gdGhpcz8NCkpvdW5pIEtvcmhvbmVuOiBOby4NCk1hcmsgSm9uZXM6IENv bmZpZGVudCB0aGF0IGxhYmVscyB3aWxsIGJlIHJlc29sdmVkLiBOb3QgZG9pbmcgYW55dGhpbmcg dW5uYXR1cmFsIHdpdGggb3VyIG9yaWdpbmFsIGxhYmVscy4gTm8gcmVhc29uIHRvIHN0b3Agd29y ayBvbiB0aGlzLg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKg0KDQo2LiBSRkM0MjgyYmlzLCBBbGFuIERlS29rDQpQcmVzZW50 ZWQgYnkgQWxhbiBEZWtvaw0KU2xpZGVkZWNrOiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRp bmdzLzgxL3NsaWRlcy9yYWRleHQtNi5wcHQNCkRhbiBSb21hbmFzY3U6IFNvICA0MjgyYmlzIHN0 cmlwcyBvdXQgaW50ZXJuYXRpb25pemF0aW9uLCByaWdodD8gSG93IGlzIHRoaXMgc2VwYXJhdGlv biBiZWluZyBmb2xsb3dlZCBpbiBvdGhlciBncm91cHM/DQpBbGFuIERla29rOiBXb3JraW5nIHdp dGggUFJFQ0lTIG9uIHRoYXQgYXNwZWN0Lg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KNy4gUkFESVVTIFByb3RvY29sIEV4 dGVuc2lvbnMsIEFsYW4gRGVLb2sgKDEwIG1pbnV0ZXMpDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXJhZGV4dC1yYWRpdXMtZXh0ZW5zaW9ucw0KUHJlc2VudGVkIGJ5ICBB bGFuIERla29rLg0KU2xpZGVkZWNrOiAgaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84 MS9zbGlkZXMvcmFkZXh0LTgucHB0DQpEYW4gUm9tYW5hc2N1OiBTbyB0aGlzIGlzIGEgbmV3IHR5 cGUgYW5kIGlzIG5vdCBiYWNrd2FyZHMgY29tcGF0aWJsZT8NCkFsYW46IEJhY2t3YXJkcyBjb21w YXRpYmxlIGZvciBwcm94aWVzIHRoYXQgdHJlYXQgYXMgYW4gb3BhcXVlIGJsb2IuIElBTkEgc2F5 cyB0aGVzZSB0eXBlcyAoMjQxLTI0NCkgYXJlIG5vdCB1c2VkIGJ1dCB0aGV5IGFyZSB1c2VkIGlu IHRoZSByZWFsIHdvcmxkLiBUb3VnaC4NClNhbSBIYXJ0bWFuOiBJIGhhdmUgYSBkcmFmdCBpbiBh YmZhYiByZXF1aXJpbmcgdGhpcyBhbmQgd291bGQgbGlrZSB0byBzZWUgdGhpcyBnbyBmd2QuIFBs ZWFzZSBkb26hr3QgY2FsbCBpdCBhbiBPSUQgdGhvdWdoLg0KIEFsYW4gRGVrb2s6IEF1ZGl0IHNo b3dzIHRoYXQgdGhpcyBzaG91bGQgaGFuZGxlIGFsbG9jYXRpb24gbmVlZHMgZm9yIHRoZSBmb3Jl c2VlYWJsZSBmdXR1cmUuDQpTbyB3ZSBkb26hr3QgbmVlZCBhZGhvYyBmb3JtYXRzLiBKdXN0IGhl bHAgdGhlbSBpbXBsZW1lbnQgdGhpcyBuZXcgZm9ybWF0Lg0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQo4LiBSQURJVVMg b3ZlciBEVExTLCBBbGFuIERlS29rDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXJhZGV4dC1kdGxzDQpQcmVzZW50ZWQgYnkgIEFsYW4gRGVrb2suDQpTbGlkZWRlY2s6ICBo dHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgxL3NsaWRlcy9yYWRleHQtNy5wcHQNCk5v IHF1ZXN0aW9ucy4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioNCjkuIFJBRElVUyBvdmVyIFRMUywgU3RlZmFuIFdpbnRlciAo MTAgbWludXRlcykNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcmFkZXh0 LXJhZHNlYw0KUHJlc2VudGVkIHJlbW90ZWx5IGJ5IFN0ZWZhbiBXaW50ZXIuDQpTbGlkZWRlY2s6 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODEvc2xpZGVzL3JhZGV4dC0xLnBkZg0K TWF1cmljaW86IEFncmVlIHRoYXQgaXQgaXMgcmVhZHkgZm9yIFdHTEMuIEFueSBvdGhlciBjb21t ZW50cy9xdWVzdGlvbnM/DQpEYW4gUm9tYW5hc2N1OiBUQ1AgcG9ydCBhbGxvY2F0aW9uLiBJbnRl bnRpb24gaXMgdG8gcmV1c2UgcG9ydCBmb3IgcmFkc2VjLiBTbyBhcmUgdGhlcmUgYW55ICBiYWNr d2FyZHMgY29tcGF0YWJpbGl0eSBpc3N1ZXMuDQpTdGVmYW4gV2ludGVyOiBOby4gT2xkIHJhZHNl YyBpcyB0aGUgZm9ybWF0IGZvciBSQURJVVMvVExTLiBPQ1Mgc2FpZCBvbmNlIFJGQyBpcyBwdWJs aXNoZWQgdGhleSB3aWxsIGNoYW5nZSB0aGVpciBpbXBsZW1lbnRhdGlvbiB0byBkbyBpdCB0aGlz IHdheS4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KKE1hcmdhcmV0IHJlcXVlc3RlZCB0byBwcmVzZW50IGF0IFJBREVY VCBhZnRlciBhZ2VuZGEgYmFzaGluZyBoYWQgb2NjdXJyZWQgYW5kIFdHIGNoYWlycyBhY2NlcHRl ZCBwcmVzZW50YXRpb24gcmVxdWVzdCkNCg0KMTAuIE11bHRpaG9wIEZlZGVyYXRpb25zIChUcnVz dCBSb3V0ZXIpLg0KTWFyZ2FyZXQgV2Fzc2VybWFuDQpTbGlkZWRlY2s6IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvcHJvY2VlZGluZ3MvODEvc2xpZGVzL3JhZGV4dC05LnBwdHgNClBoaWxpcCBIYWxsYW0t QmFrZXI6IExvb2tzIGxpa2UgVVVDUC4gSXQgd2FzIHJlcGxhY2VkIHdpdGggRE5TLiBBbnl0aGlu ZyB0aGF0IGxvb2tzIGxpa2UgYSAgbmFtZXNwYWNlIHNob3VsZCBiZSB1c2luZyBETlMuIExvb2sg YXQgQnJpZGdlIENBcy4gVXNlZCBpbiBQS0kgc3BhY2UuIExvdHMgb2YgdW5pdiBhcmUgaW4gQnJp ZGdlIENhcy4gQ2FuIGFsc28gdXNlIFJ1bGVib29rIHN0cnVjdHVyZSBzbyBuZXZlciBuZWVkIGEg cGF0aCBvZiBtb3JlIHRoYW4gMiBzbyBkb26hr3QgbmVlZA0KQkdQLg0KTWFyZ2FyZXQgV2Fzc2Vy bWFuOiBUaGlzIGlzIG5vdCBhYm91dCBnZXR0aW5nIHRvIGV2ZXJ5IG5vZGUuIE9ubHkgYWJvdXQg Z2V0dGluZyBiZXR3ZWVuIG5vZGVzIGluIEFBQSBpbmZyYXN0cnVjdHVyZS4gVGhleSBhcmUgYWxs IElQIG5vZGVzIGFuZCBhbHJlYWR5IGluIEJHUA0KUGhpbGlwIEhhbGxhbS1CYWtlcjogWW91IHdp bGwgZmluZCB5b3UgdXNlIG9ubHkgMTAlIG9mIEJHUCBhbmQgbm90IHRoZSBpbnRlcmVzdGluZyBw YXJ0Lg0KSGFubmVzOiBEcmFmdCBhZGRyZXNzZXMgc29tZSBvZiB0aGUgaXNzdWVzLiBSZWxhdGlv bnNoaXAgYXJlIG5vdCBwdXJlbHkgbWVjaGFuaWNhbC4gRG9uoa90IHdhbnQgdG8gdGFsayB0byBl dmVyeW9uZS4gTGlrZSBTQU1MLCBMaWJlcnR5IEFsbGlhbmNlLiBDb21lIHVwIHdpdGggY2lyY2xl IG9mIHRydXN0LiBUaGV5IGV4aXN0IGluIEFBQSBzcGFjZS4gVGhlIFRydXN0IFJvdXRlciBzZXR1 cCBhbGxvd3Mgc2hvcnRjdXRzLg0KQWxhbiBEZWtvazogRWNobyBIYW5uZXMuIE5lZWQgdG8gcmVw cmVzZW50IGJpeiByZWxhdGlvbnNoaXBzOiBXaG8gdG8gdGFsayB0byBkZXBlbmRzIG9uIHdobyBp cyBhc2tpbmcuIFN0aWxsIGhhdmUgcXVlc3Rpb25zIG9uIHRoZSBkZXRhaWxzDQpNYXJnYXJldCBX YXNzZXJtYW46IFRoaXMgbGV0cyB5b3UgcHV0IHBvbGljeSBpbiBpbnRlcmVzdGluZyBwbGFjZXMg KGxvY2FsIHRydXN0IHJvdXRlcikuIEUuZy4gbm90IHJvdXRlIHNob3VsZCBSdXNzaWFuIG5vZGVz IGV2ZW4gaWYgdGhlIHJvdXRlIGlzIHNob3J0ZXIuDQpLbGFhcyBXaWVyZW5nYTogVGhpcyB3b3Jr IGlzIG1vdGl2YXRlZCBieSBwcm9ibGVtcyBzZWVuIGluIGxhcmdlIHNjYWxlIFNBTUwgZGVwbG95 bWVudHMuIEVzcCB0byBleHByZXNzIGNvbXBsZXggcG9saWNlcyBhcm91bmQgd2hvIHlvdSB3YW50 IHRvIHRydXN0LiBTaGFyZSBzb21lIG9mIFBoaWxpcHMgY29uY2VybnMNClBoaWxpcCBIYWxsYW0t QmFrZXI6IFdvcmtpbmcgb24gdGhpcyBwcm9ibGVtIGZvciAxNXlycy4gU2ltaWxhciB0byBvdGhl ciBhcHByb2FjaGVzIHRoYXQgaGF2ZSBhbHJlYWR5IGJlZW4gaW1wbGVtZW50ZWQuDQpTYW0gSGFy dG1hbjogVGhpcyBpcyBpbiB0aGUgZHJhZnQuDQpQaGlsaXA6IFdoeSBub3QgaW4gdGhlIHByZXNl bnRhdGlvbj8NCk1hcmdhcmV0IFdhc3Nlcm1hbjogTm90IGFjY2VwdGVkIGFzIFdHIGl0ZW0gaW4g YWJmYWIuIEZlZWRiYWNrIHJlcXVpcmVkIG9uIGFiZmFiIGxpc3QuDQpIYW5uZXM6IEFsc28gdGFs a2luZyB0byBWT0lQIGZvbGtzIHdobyBhcmUgcmV1c2luZyBCR1AgY29uY2VwdHMuDQpNYXJnYXJl dCBXYXNzZXJtYW46IHdlIGhhdmUgbm90IHdyaXR0ZW4gdGhlc2UgcHJvdG9jb2xzLiBJZiBhIGJl dHRlciB3YXksIHBsZWFzZSBleHBsYWluLg0KUGhpbGlwIEhhbGxhbS1CYWtlcjogVGhpbmtpbmcg YXMgYSBDQS4gU29tZW9uZSBoYXMgdG8gbWFuYWdlIGl0IGFuZCBtb25leSB3aWxsIGZsb3cgYXJv dW5kLiBUaGUgdGFzayBvZiBpbnRyb2R1Y3Rpb24gaXMgZ29pbmcgdG8gYmUgcGFpZC4gTWF5IHdh bnQgdG8gcGF5IHByZW1pdW0gdG8gZmluZCBhIHBhdGggd2l0aCBhIGhpZ2hlciBkZWdyZWUgb2Yg dHJ1c3QuDQpNYXJnYXJldCBXYXNzZXJtYW46IEFsbG93cyBmb3IgYml6IGludGVsbGlnZW5jZSBh dCBtYW55IGRpZmZlcmVudCBsYXllcnMuDQpQaGlsaXAgSGFsbGFtLUJha2VyOiBDb250cmFjdHMg d2lsbCBkZXRlcm1pbmUgdGhpcy4gRG9uoa90IG5lZWQgdGhpcyBob3AgYnkgaG9wLiBDYW4gdGFr ZSB0aGlzIG9mZmxpbmUuDQpNYXJnYXJldCBXYXNzZXJtYW46IFdvdWxkIGJlIGludGVyZXN0ZWQg aW4gdGhvc2UgcG9pbnRlcnMgdG8gYXBwcm9hY2hlcyBhbHJlYWR5IHRyaWVkLg0KS2xhYXMgV2ll cmVuZ2E6IFRoaXMgZ29lcyBiZXlvbmQgYWJmYWIuIFNvIEFEIHB1c2hlZCB1cyB0byBwcmVzZW50 IGluIG90aGVyIGdyb3VwcyB0aGF0IHNlZSB0aGUgc2FtZSB0eXBlIG9mIHByb2JsZW0uIFdlbGNv bWUgYSBicm9hZCBkaXNjdXNzaW9uLg0KTWFyZ2FyZXQgV2Fzc2VybWFuOiBPbiBhZ2VuZGEgaW4g YWJmYWIgb24gRnJpZGF5IG1vcm5pbmcuDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQoxMS4gRW1haWwgbGlzdCBz ZXJ2ZXIgbWlncmF0aW9uDQpEYW4gUm9tYW5hc2N1OiBQbGVhc2UgZXhwbGFpbiB3aGF0IGl0IG1l YW5zIGZvciBwZW9wbGUgb24gdGhlIGxpc3QuDQpNYXVyaWNpbzogTm90aGluZy4gU2hvdWxkIGJl IHRyYW5zcGFyZW50LiBHb3QgYSBwcm9jZXNzIGZvciBhcmNoaXZlIG1pZ3JhdGlvbi4NCkpvdW5p OiBBdXRvIG1vdmUgb2Ygc3Vic2NyaWJlcnMgdG8gbmV3IGxpc3QuIEVtYWlscyB3aWxsIGJlIGZv cndhcmRlZCBiZXR3ZWVuIGxpc3RzLg0KU2VjcmV0YXJ5IHdpbGwgbW92ZSBhcmNoaXZlcy4NCkRh bjogT24gYmVoYWxmIG9mIGRvdWJ0ZXJzOiBDYW4geW91IGV4cGxhaW4gbWlncmF0aW9uIG9mIGFy Y2hpdmVzPw0KTWF1cmljaW86IE90aGVycyAoRnJlZCBCYWtlcikgY3JlYXRlZCB0aGUgcHJvY2Vz cyBmb3IgcGFpbmxlc3MgbWlncmF0aW9uIG9mIGFyY2hpdmVzLiBTbyB3ZQ0KRGFuOiBEbyByZWZl cmVuY2VzIG9uIHRoZSB0cmFja2VyIG5lZWQgdG8gY2hhbmdlPw0KSm91bmk6IERpcmVjdCBsaW5r cyB0byBhcmNoaXZlcyBuZWVkIHRvIGJlIHVwZGF0ZWQuDQpNYXVyaWNpbzogV2lsbCBuZWVkIHRv IGxvb2sgaW50byB0aGF0IGFuZCBtYWtlIHN1cmUgaXQgaXMgcmVtZWRpZWQuDQoNCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN CjEyLiBOZXh0IFN0ZXBzOiBXRyBDaGFpcnMgJiBBRHMNCldHIEdvYWxzL01pbGVzdG9uZXMgc3Rh dHVzDQpObyBxdWVzdGlvbnMNCg== --Boundary_(ID_CTBeIIdVcoMZCGN4hjNyyA) Content-id: <09C347C69B4FF241B6D3D80E744F9EDC@huawei.com> Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

I've sent a question of clarification to the mailing= list agaisnt draft-ietf-radext-ipv6-access-05. Pls. refer to https://ops.ietf.org/lists/radiusext/2010/msg00959.html.

 

Sorry for my poor expression in the Radext session. = I'd like to clarify my words in the meeting notes here. 

 

 

> 3. RADIUS Attributes for IPv6 Access Networks, = Wojcieh Dec

> http://tools.ietf.org/html/draft-ietf-radext-ip= v6-access

> Presented by Mauricio Sanchez.

> Slidedeck: http://www.ietf.org/proceedings/81/s= lides/radext-5.ppt

> Questions:

> Leaf  Yeh: In new version, new attribs. On= ly sends name of pool. DHCP already has a pool.

 

I meant the attribute of Framed-Pool (88, section 5.= 18 of RFC2869) here, which is used to send the pool name from AAA server to= NAS server, to indicate the right pool employed or configured on NAS.

 

> Doesn=A1=AFt think this is necessary. Attribute= s in v4 can already do this. There is no need to a v6 pool name.

> Leaf agreed to send concern to list

> Roberta Maglione: It is just a pool name. Seman= tics are different.

> Bernard Adoba: One is a prefix pool and the oth= er is an address pool. May need to do both at once.

> Leaf: But it is only a string. So DHCP server can use name format is disambiguate.

 

I meant the NAS can interprect the pool name receviv= ed from AAA server for each kind of usage, such as IPv4 PPP addre= ss pool, IPv6 SLAAC prefix pool, IPv6 DHCPv6 address pool or DHCPv6-PD pref= ix pool. 

 

> Mauricio Sanchez: Sounds like valid reason for = these two attributes. Please bring comments to

list.

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB: owner-radiusext@ops.iet= f.org [owner-radiusext@ops.ietf.org] =B4=FA=B1=ED Sanchez, Mauricio (HP Net= working) [mauricio.sanchez@hp.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C226=C8=D5 6:29
=B5=BD: 'radiusext@ops.ietf.org'
=D6=F7=CC=E2: RADEXT WG - IETF 81 preliminary meeting notes

These are the preliminary notes for IETF 81. Many th= anks to Mark Jones for taking notes this morning.  Comments/correction= s welcome.

 

-MS

 

----------------------------------------------------= ----------------------------------------------------------

RADEXT WG Minutes

IETF 81

Quebec, Canada

Monday, July 25th, 2011

Meeting started 9:02 AM and ended 11:27AM EDT. Appro= ximately 35 individuals in meeting

 

Chairs:

Jouni Korhonen <jouni.korhonen@nsn.com>

Mauricio Sanchez <mauricio.sanchez@hp.com>

 

1. Preliminaries

 

Agenda slides: http://www.ietf.org/proceedings/81/sl= ides/radext-3.pptx

 

Attendees: Bluesheets circulated.

Note Well

Note Takers

- Note volunteer Mark Jones

Jabber scribe

- Alan DeKok jabber scribe

Agenda bash

- IPv6, enhancements, security grouped item.  N= o changes to agenda made

 

****************************************************= ************

 

2. Radius Extensions for CGN Configurations, Dean Ch= eng

http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-ra= dius-ext-00.txt

 

Presented by Dean Cheng.

Slidedeck: http://www.ietf.org/proceedings/81/slides= /radext-2.ppt

Hannes Tschofenig: Slide 3: Do you now assume DHCP b= etween end host and NAT?

Dean Cheng: Service Request is a general term but no= change.

Hannes Tschofenig: What happens when NAT runs out of= ports?

Dean Cheng: Number of ports are configured on server= . It is used to limit.

Hannes Tschofenig: What happens in failure case? i.e= . you reach restriction.

Dean Cheng: AAA only returns limits. If use wants mo= re ports, ICMP can be used to indicate

error.

Hannes Tschofenig: How do you ensure ICMP reaches en= d host?

Dean Cheng: OK. We can discuss offline.

Mauricio Sanchez:  Slide 5: Did you read RFC615= 8 RADIUS Guidelines

Dean Cheng: Yes. Need some help on these encoding wr= t RADIUS guidelines.

---

Questions:

Mauricio Sanchez: Where is this in BEHAVE WG?

Dean: Result of merge of two drafts to BEHAVE. Chair= suggested to present in RADEXT because

comments received were on RADIUS aspects

Dan Romanascu: Is this a charter item in BEHAVE.

Dean: No. Still be chartered. Chair said it is withi= n scope of BEHAVE.

Dan: What do you need from RADEXT? Advisor? WGLC?

Dean: BEHAVE suggest to present in RADEXT to get com= ments.

Dan: In draft, need to expand acronyms.

Hannes: (1) Need to define bigger picture. NAT behav= iour when it runs out of resources. Need to know why it fails. (2) AAA clie= nt does not live on NAT. DHCP and NAT are mashed together but it depends ho= w these are related.

Dean: AAA client is not changed. NAT44 must be co-lo= cated with BNG.

Hannes: Very special scenario.

Dean: If CNG (NAT44) not colo with BNG this falls ap= art.

Dan: Any other mechanisms to configure CNG other tha= n this draft?

Dean: No change. Only leverages existing deployment.=

 

****************************************************= ************

 

3. RADIUS Attributes for IPv6 Access Networks, Wojci= eh Dec

http://tools.ietf.org/html/draft-ietf-radext-ipv6-ac= cess

Presented by Mauricio Sanchez.

Slidedeck: http://www.ietf.org/proceedings/81/slides= /radext-5.ppt

Questions:

Leaf  Yeh: In new version, new attribs. Only se= nds name of pool. DHCP already has a pool.

Doesn=A1=AFt think this is necessary. Attributes in = v4 can already do this. There is no need to a v6 pool name.

Leaf agreed to send concern to list

Roberta Maglione: It is just a pool name. Semantics = are different.

Bernard Adoba: One is a prefix pool and the other is= an address pool. May need to do both at

once.

Leaf: But it is only a string. So DHCP server can us= e name format is disambiguate.

Mauricio Sanchez: Sounds like valid reason for these= two attributes. Please bring comments to

list.

****************************************************= ************

4. RADIUS accounting for traffic classes, Stefan Win= ter

http://tools.ietf.org/html/draft-winter-radext-fancy= accounting

Presented remotely by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings/81/slides= /radext-4.pdf

Other issues:

Mark Jones: We don=A1=AFt need to include filter def= inition in accounting stream. Just include filter name (bucket label) in th= e accounting stream.

Stefan: Ok. Nice and simple. Works for me.

Dan Romanascu : Reuse definitions from RFC4898

Mauricio Sanchez: Concerned about number of drafts t= o progress. Does not want to oversubscribe WG. Poll: Who is interested in t= his work? Who will help out if WG item?

Show of hands in room:

Relevant and useful: No interest.

Stefan: Will let draft expire unless someone comes f= orward with interest.

Mauricio Sanchez: Thanks for spending time on this. =

 

****************************************************= ************

 

5. Dynamic Peer Discovery, Stefan Winter

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

Presented by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings/81/slides= /radext-0.pdf

Stefan Winter: Asked about IESG comments on DIME equ= iv.

Mark Jones: IESG DISCUSS is on format of Application= Protocol Tag. Concern was that the current format indicates a structure.

Stefan Winter: Any IESG comments on Service Tag?

Mark Jones: No. Just protocol tags.

Comments or questions:

Dan Romanascu: Jouni, Can you comment on issues enco= untered in DIME?

Jouni Korhonen: Need to solve this in DIME. Mark gav= e summary of IESG concern.

Dan Romanascu: Do we need to stop work in this?

Jouni Korhonen: No.

Mark Jones: Confident that labels will be resolved. = Not doing anything unnatural with our original labels. No reason to stop wo= rk on this.

****************************************************= ************

 

6. RFC4282bis, Alan DeKok

Presented by Alan Dekok

Slidedeck: http://www.ietf.org/proceedings/81/slides= /radext-6.ppt

Dan Romanascu: So  4282bis strips out internati= onization, right? How is this separation being followed in other groups?

Alan Dekok: Working with PRECIS on that aspect.

****************************************************= ************

7. RADIUS Protocol Extensions, Alan DeKok (10 minute= s)

http://tools.ietf.org/html/draft-ietf-radext-radius-= extensions

Presented by  Alan Dekok.

Slidedeck:  http://www.ietf.org/proceedings/81/= slides/radext-8.ppt

Dan Romanascu: So this is a new type and is not back= wards compatible?

Alan: Backwards compatible for proxies that treat as= an opaque blob. IANA says these types (241-244) are not used but they are = used in the real world. Tough.

Sam Hartman: I have a draft in abfab requiring this = and would like to see this go fwd. Please don=A1=AFt call it an OID though.=  

 Alan Dekok: Audit shows that this should handl= e allocation needs for the foreseeable future.

So we don=A1=AFt need adhoc formats. Just help them = implement this new format.

****************************************************= ************

 

8. RADIUS over DTLS, Alan DeKok

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

Presented by  Alan Dekok.

Slidedeck:  http://www.ietf.org/proceedings/81/= slides/radext-7.ppt

No questions.

****************************************************= ************

9. RADIUS over TLS, Stefan Winter (10 minutes)

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

Presented remotely by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings/81/slides= /radext-1.pdf

Mauricio: Agree that it is ready for WGLC. Any other= comments/questions?

Dan Romanascu: TCP port allocation. Intention is to = reuse port for radsec. So are there any  backwards compatability issue= s.

Stefan Winter: No. Old radsec is the format for RADI= US/TLS. OCS said once RFC is published they will change their implementatio= n to do it this way.

 

****************************************************= ************

(Margaret requested to present at RADEXT after agend= a bashing had occurred and WG chairs accepted presentation request) 

 

10. Multihop Federations (Trust Router).

Margaret Wasserman

Slidedeck: http://www.ietf.org/proceedings/81/slides= /radext-9.pptx

Philip Hallam-Baker: Looks like UUCP. It was replace= d with DNS. Anything that looks like a  namespace should be using DNS.= Look at Bridge CAs. Used in PKI space. Lots of univ are in Bridge Cas. Can= also use Rulebook structure so never need a path of more than 2 so don=A1=AFt need

BGP.

Margaret Wasserman: This is not about getting to eve= ry node. Only about getting between nodes in AAA infrastructure. They are a= ll IP nodes and already in BGP

Philip Hallam-Baker: You will find you use only 10% = of BGP and not the interesting part.

Hannes: Draft addresses some of the issues. Relation= ship are not purely mechanical. Don=A1=AFt want to talk to everyone. Like S= AML, Liberty Alliance. Come up with circle of trust. They exist in AAA spac= e. The Trust Router setup allows shortcuts.

Alan Dekok: Echo Hannes. Need to represent biz relat= ionships: Who to talk to depends on who is asking. Still have questions on = the details

Margaret Wasserman: This lets you put policy in inte= resting places (local trust router). E.g. not route should Russian nodes ev= en if the route is shorter.

Klaas Wierenga: This work is motivated by problems s= een in large scale SAML deployments. Esp to express complex polices around = who you want to trust. Share some of Philips concerns

Philip Hallam-Baker: Working on this problem for 15y= rs. Similar to other approaches that have already been implemented.

Sam Hartman: This is in the draft.

Philip: Why not in the presentation?

Margaret Wasserman: Not accepted as WG item in abfab= . Feedback required on abfab list.

Hannes: Also talking to VOIP folks who are reusing B= GP concepts.

Margaret Wasserman: we have not written these protoc= ols. If a better way, please explain.

Philip Hallam-Baker: Thinking as a CA. Someone has t= o manage it and money will flow around. The task of introduction is going t= o be paid. May want to pay premium to find a path with a higher degree of t= rust.

Margaret Wasserman: Allows for biz intelligence at m= any different layers.

Philip Hallam-Baker: Contracts will determine this. = Don=A1=AFt need this hop by hop. Can take this offline.

Margaret Wasserman: Would be interested in those poi= nters to approaches already tried.

Klaas Wierenga: This goes beyond abfab. So AD pushed= us to present in other groups that see the same type of problem. Welcome a= broad discussion.

Margaret Wasserman: On agenda in abfab on Friday mor= ning.

 

 

****************************************************= ************

 

11. Email list server migration

Dan Romanascu: Please explain what it means for peop= le on the list.

Mauricio: Nothing. Should be transparent. Got a proc= ess for archive migration.

Jouni: Auto move of subscribers to new list. Emails = will be forwarded between lists. 

Secretary will move archives.

Dan: On behalf of doubters: Can you explain migratio= n of archives?

Mauricio: Others (Fred Baker) created the process fo= r painless migration of archives. So we

Dan: Do references on the tracker need to change?

Jouni: Direct links to archives need to be updated.<= /p>

Mauricio: Will need to look into that and make sure = it is remedied.

 

****************************************************= ************

12. Next Steps: WG Chairs & ADs

WG Goals/Milestones status

No questions

--Boundary_(ID_CTBeIIdVcoMZCGN4hjNyyA)-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 25 Jul 2011 22:31:48 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" Date: Mon, 25 Jul 2011 23:29:42 +0100 Subject: RADEXT WG - IETF 81 preliminary meeting notes Thread-Topic: RADEXT WG - IETF 81 preliminary meeting notes Thread-Index: AcxLGaaSIMWqzBhyQQq096RhZBECsg== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C78185121@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78185121GVW0671EXCame_" MIME-Version: 1.0 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78185121GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These are the preliminary notes for IETF 81. Many thanks to Mark Jones for = taking notes this morning. Comments/corrections welcome. -MS ---------------------------------------------------------------------------= ----------------------------------- RADEXT WG Minutes IETF 81 Quebec, Canada Monday, July 25th, 2011 Meeting started 9:02 AM and ended 11:27AM EDT. Approximately 35 individuals= in meeting Chairs: Jouni Korhonen Mauricio Sanchez 1. Preliminaries Agenda slides: http://www.ietf.org/proceedings/81/slides/radext-3.pptx Attendees: Bluesheets circulated. Note Well Note Takers - Note volunteer Mark Jones Jabber scribe - Alan DeKok jabber scribe Agenda bash - IPv6, enhancements, security grouped item. No changes to agenda made **************************************************************** 2. Radius Extensions for CGN Configurations, Dean Cheng http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-radius-ext-00.txt Presented by Dean Cheng. Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-2.ppt Hannes Tschofenig: Slide 3: Do you now assume DHCP between end host and NAT= ? Dean Cheng: Service Request is a general term but no change. Hannes Tschofenig: What happens when NAT runs out of ports? Dean Cheng: Number of ports are configured on server. It is used to limit. Hannes Tschofenig: What happens in failure case? i.e. you reach restriction= . Dean Cheng: AAA only returns limits. If use wants more ports, ICMP can be u= sed to indicate error. Hannes Tschofenig: How do you ensure ICMP reaches end host? Dean Cheng: OK. We can discuss offline. Mauricio Sanchez: Slide 5: Did you read RFC6158 RADIUS Guidelines Dean Cheng: Yes. Need some help on these encoding wrt RADIUS guidelines. --- Questions: Mauricio Sanchez: Where is this in BEHAVE WG? Dean: Result of merge of two drafts to BEHAVE. Chair suggested to present i= n RADEXT because comments received were on RADIUS aspects Dan Romanascu: Is this a charter item in BEHAVE. Dean: No. Still be chartered. Chair said it is within scope of BEHAVE. Dan: What do you need from RADEXT? Advisor? WGLC? Dean: BEHAVE suggest to present in RADEXT to get comments. Dan: In draft, need to expand acronyms. Hannes: (1) Need to define bigger picture. NAT behaviour when it runs out o= f resources. Need to know why it fails. (2) AAA client does not live on NAT= . DHCP and NAT are mashed together but it depends how these are related. Dean: AAA client is not changed. NAT44 must be co-located with BNG. Hannes: Very special scenario. Dean: If CNG (NAT44) not colo with BNG this falls apart. Dan: Any other mechanisms to configure CNG other than this draft? Dean: No change. Only leverages existing deployment. **************************************************************** 3. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec http://tools.ietf.org/html/draft-ietf-radext-ipv6-access Presented by Mauricio Sanchez. Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-5.ppt Questions: Leaf Yeh: In new version, new attribs. Only sends name of pool. DHCP alrea= dy has a pool. Doesn't think this is necessary. Attributes in v4 can already do this. Ther= e is no need to a v6 pool name. Leaf agreed to send concern to list Roberta Maglione: It is just a pool name. Semantics are different. Bernard Adoba: One is a prefix pool and the other is an address pool. May n= eed to do both at once. Leaf: But it is only a string. So DHCP server can use name format is disamb= iguate. Mauricio Sanchez: Sounds like valid reason for these two attributes. Please= bring comments to list. **************************************************************** 4. RADIUS accounting for traffic classes, Stefan Winter http://tools.ietf.org/html/draft-winter-radext-fancyaccounting Presented remotely by Stefan Winter. Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-4.pdf Other issues: Mark Jones: We don't need to include filter definition in accounting stream= . Just include filter name (bucket label) in the accounting stream. Stefan: Ok. Nice and simple. Works for me. Dan Romanascu : Reuse definitions from RFC4898 Mauricio Sanchez: Concerned about number of drafts to progress. Does not wa= nt to oversubscribe WG. Poll: Who is interested in this work? Who will help= out if WG item? Show of hands in room: Relevant and useful: No interest. Stefan: Will let draft expire unless someone comes forward with interest. Mauricio Sanchez: Thanks for spending time on this. **************************************************************** 5. Dynamic Peer Discovery, Stefan Winter http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery Presented by Stefan Winter. Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-0.pdf Stefan Winter: Asked about IESG comments on DIME equiv. Mark Jones: IESG DISCUSS is on format of Application Protocol Tag. Concern = was that the current format indicates a structure. Stefan Winter: Any IESG comments on Service Tag? Mark Jones: No. Just protocol tags. Comments or questions: Dan Romanascu: Jouni, Can you comment on issues encountered in DIME? Jouni Korhonen: Need to solve this in DIME. Mark gave summary of IESG conce= rn. Dan Romanascu: Do we need to stop work in this? Jouni Korhonen: No. Mark Jones: Confident that labels will be resolved. Not doing anything unna= tural with our original labels. No reason to stop work on this. **************************************************************** 6. RFC4282bis, Alan DeKok Presented by Alan Dekok Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-6.ppt Dan Romanascu: So 4282bis strips out internationization, right? How is thi= s separation being followed in other groups? Alan Dekok: Working with PRECIS on that aspect. **************************************************************** 7. RADIUS Protocol Extensions, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions Presented by Alan Dekok. Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-8.ppt Dan Romanascu: So this is a new type and is not backwards compatible? Alan: Backwards compatible for proxies that treat as an opaque blob. IANA s= ays these types (241-244) are not used but they are used in the real world.= Tough. Sam Hartman: I have a draft in abfab requiring this and would like to see t= his go fwd. Please don't call it an OID though. Alan Dekok: Audit shows that this should handle allocation needs for the f= oreseeable future. So we don't need adhoc formats. Just help them implement this new format. **************************************************************** 8. RADIUS over DTLS, Alan DeKok http://tools.ietf.org/html/draft-ietf-radext-dtls Presented by Alan Dekok. Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-7.ppt No questions. **************************************************************** 9. RADIUS over TLS, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec Presented remotely by Stefan Winter. Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-1.pdf Mauricio: Agree that it is ready for WGLC. Any other comments/questions? Dan Romanascu: TCP port allocation. Intention is to reuse port for radsec. = So are there any backwards compatability issues. Stefan Winter: No. Old radsec is the format for RADIUS/TLS. OCS said once R= FC is published they will change their implementation to do it this way. **************************************************************** (Margaret requested to present at RADEXT after agenda bashing had occurred = and WG chairs accepted presentation request) 10. Multihop Federations (Trust Router). Margaret Wasserman Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-9.pptx Philip Hallam-Baker: Looks like UUCP. It was replaced with DNS. Anything th= at looks like a namespace should be using DNS. Look at Bridge CAs. Used in= PKI space. Lots of univ are in Bridge Cas. Can also use Rulebook structure= so never need a path of more than 2 so don't need BGP. Margaret Wasserman: This is not about getting to every node. Only about get= ting between nodes in AAA infrastructure. They are all IP nodes and already= in BGP Philip Hallam-Baker: You will find you use only 10% of BGP and not the inte= resting part. Hannes: Draft addresses some of the issues. Relationship are not purely mec= hanical. Don't want to talk to everyone. Like SAML, Liberty Alliance. Come = up with circle of trust. They exist in AAA space. The Trust Router setup al= lows shortcuts. Alan Dekok: Echo Hannes. Need to represent biz relationships: Who to talk t= o depends on who is asking. Still have questions on the details Margaret Wasserman: This lets you put policy in interesting places (local t= rust router). E.g. not route should Russian nodes even if the route is shor= ter. Klaas Wierenga: This work is motivated by problems seen in large scale SAML= deployments. Esp to express complex polices around who you want to trust. = Share some of Philips concerns Philip Hallam-Baker: Working on this problem for 15yrs. Similar to other ap= proaches that have already been implemented. Sam Hartman: This is in the draft. Philip: Why not in the presentation? Margaret Wasserman: Not accepted as WG item in abfab. Feedback required on = abfab list. Hannes: Also talking to VOIP folks who are reusing BGP concepts. Margaret Wasserman: we have not written these protocols. If a better way, p= lease explain. Philip Hallam-Baker: Thinking as a CA. Someone has to manage it and money w= ill flow around. The task of introduction is going to be paid. May want to = pay premium to find a path with a higher degree of trust. Margaret Wasserman: Allows for biz intelligence at many different layers. Philip Hallam-Baker: Contracts will determine this. Don't need this hop by = hop. Can take this offline. Margaret Wasserman: Would be interested in those pointers to approaches alr= eady tried. Klaas Wierenga: This goes beyond abfab. So AD pushed us to present in other= groups that see the same type of problem. Welcome a broad discussion. Margaret Wasserman: On agenda in abfab on Friday morning. **************************************************************** 11. Email list server migration Dan Romanascu: Please explain what it means for people on the list. Mauricio: Nothing. Should be transparent. Got a process for archive migrati= on. Jouni: Auto move of subscribers to new list. Emails will be forwarded betwe= en lists. Secretary will move archives. Dan: On behalf of doubters: Can you explain migration of archives? Mauricio: Others (Fred Baker) created the process for painless migration of= archives. So we Dan: Do references on the tracker need to change? Jouni: Direct links to archives need to be updated. Mauricio: Will need to look into that and make sure it is remedied. **************************************************************** 12. Next Steps: WG Chairs & ADs WG Goals/Milestones status No questions --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78185121GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These are the pr= eliminary notes for IETF 81. Many thanks to Mark Jones for taking notes thi= s morning.  Comments/corrections welcome.

 

-MS

 

-------------------= ---------------------------------------------------------------------------= ----------------

RADEXT WG Minutes<= /o:p>

IETF 81

Qu= ebec, Canada

Monday, July 25th, 2011

Meeting started 9:02 AM and ended 11:27AM = EDT. Approximately 35 individuals in meeting

 

Chairs:

Jouni Korhonen <jouni.korhonen@nsn.com>

=

Mauricio Sanchez <mauricio.sanchez@hp.com><= /o:p>

&nb= sp;

1. Preliminaries

 

Agenda slides: http:= //www.ietf.org/proceedings/81/slides/radext-3.pptx

 

Attendees: Bluesheet= s circulated.

Note Well

Note Takers

- Note vo= lunteer Mark Jones

Jabber scribe

- Alan DeKok jabber scribe

Agenda bash

- IPv6, enha= ncements, security grouped item.  No changes to agenda made=

 

********= ********************************************************

 

2. Radius Extens= ions for CGN Configurations, Dean Cheng

http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-radius-ext-00.txt

 

Pres= ented by Dean Cheng.

Slidedeck: http://w= ww.ietf.org/proceedings/81/slides/radext-2.ppt

Hannes Tschofenig: Slide 3: Do you now assume DHCP between end host = and NAT?

Dean Cheng: Service Request is= a general term but no change.

Hannes Ts= chofenig: What happens when NAT runs out of ports?

Dean Cheng: Number of ports are configured on server. It is us= ed to limit.

Hannes Tschofenig: What hap= pens in failure case? i.e. you reach restriction.

Dean Cheng: AAA only returns limits. If use wants more ports, ICM= P can be used to indicate

error.

Hannes Tsc= hofenig: How do you ensure ICMP reaches end host?

Dean Cheng: OK. We can discuss offline.

Mauricio Sanchez:  Slide 5: Did you read RFC6158 RADIUS Guid= elines

Dean Cheng: Yes. Need some help o= n these encoding wrt RADIUS guidelines.

=

---

Questions:

Mauricio Sanchez: Where is this in BEHAVE WG?

Dean: Result of merge of two drafts to BEHAVE. Chair suggest= ed to present in RADEXT because

comments received were on RADIUS aspects<= /o:p>

Dan Romanascu: Is this a charter item in BEHA= VE.

Dean: No. Still be chartered. Chair = said it is within scope of BEHAVE.

Dan:= What do you need from RADEXT? Advisor? WGLC?

Dean: BEHAVE suggest to present in RADEXT to get comments.=

Dan: In draft, need to expand acronyms.=

Hannes: (1) Need to define bigger picture. NAT beh= aviour when it runs out of resources. Need to know why it fails. (2) AAA cl= ient does not live on NAT. DHCP and NAT are mashed together but it depends = how these are related.

Dean: AAA client= is not changed. NAT44 must be co-located with BNG.

Hannes: Very special scenario.

Dean: If CNG (NAT44) not colo with BNG this falls apart.

Dan: Any other mechanisms to configure CNG other than= this draft?

Dean: No change. Only lever= ages existing deployment.

 

***********************************************= *****************

 

=

3. RADIUS Attributes for IPv6 Access Networks, Wojcieh= Dec

http://tools.ietf.org/html/draft-i= etf-radext-ipv6-access

<= p class=3DMsoNormal>Presented by Mauricio Sanchez.

Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-5.= ppt

Questions:

Leaf  Yeh: In new vers= ion, new attribs. Only sends name of pool. DHCP already has a pool.

Doesn’t think this is necessary. Attribu= tes in v4 can already do this. There is no need to a v6 pool name.

Leaf agreed to send concern to list<= /p>

Roberta Maglione: It is just a pool name. Semantics= are different.

Bernard Adoba: One is a= prefix pool and the other is an address pool. May need to do both at =

once.

Lea= f: But it is only a string. So DHCP server can use name format is disambigu= ate.

Mauricio Sanchez: Sounds like valid= reason for these two attributes. Please bring comments to

<= p class=3DMsoNormal>list.

****************************************************= ************

4. RADIUS accounting for traffic classes, Stefan Winter

http://tools.ietf.org/html/draft-winter-radext-f= ancyaccounting

Presented remotely by Ste= fan Winter.

Slidedeck: http://www.ietf.o= rg/proceedings/81/slides/radext-4.pdf

<= o:p>

Other issues:

Mark Jones: We don’t ne= ed to include filter definition in accounting stream. Just include filter n= ame (bucket label) in the accounting stream.

Stefan: Ok. Nice and simple. Works for me.

Dan Romanascu : Reuse definitions from RFC4898

Mauricio Sanchez: Conce= rned about number of drafts to progress. Does not want to oversubscribe WG.= Poll: Who is interested in this work? Who will help out if WG item?

Show of hands in room:

Relevant and useful: No interest.

Stefan: Will let draft expire unless someone comes forward with inte= rest.

Mauricio Sanchez: Thanks for spend= ing time on this.

 

=

******************************************************= **********

 

5. Dynamic Peer Discovery, Stefan Winter

http://tools.ietf.org/html/draft-ietf-radext-dynamic-discove= ry

Presented by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings/81/sl= ides/radext-0.pdf

Stefan Winter: Asked about IESG comments on DIME equiv.=

Mark Jones: IESG DISCUSS is on format of App= lication Protocol Tag. Concern was that the current format indicates a stru= cture.

Stefan Winter: Any IESG comments = on Service Tag?

Mark Jones: No. Just pro= tocol tags.

Comments or questions:

Dan Roma= nascu: Jouni, Can you comment on issues encountered in DIME?

=

Jouni Korhonen: Need to solve this in DIME. Mark gave = summary of IESG concern.

Dan Romanascu: = Do we need to stop work in this?

Jouni K= orhonen: No.

Mark Jones: Confident that= labels will be resolved. Not doing anything unnatural with our original la= bels. No reason to stop work on this.

<= o:p>

****************************************= ************************

 

6. RFC4282bis, Alan DeKok

Presented by Alan Dekok

Sl= idedeck: http://www.ietf.org/proceedings/81/slides/radext-6.ppt<= /p>

Dan Romanascu:= So  4282bis strips out internationization, right? How is this separat= ion being followed in other groups?

Alan= Dekok: Working with PRECIS on that aspect.

**********************************= ******************************

7. RADIUS Protocol Extensions, Alan DeKok (10 m= inutes)

http://tools.ietf.org/html/draft= -ietf-radext-radius-extensions

Presented= by  Alan Dekok.

Slidedeck:  h= ttp://www.ietf.org/proceedings/81/slides/radext-8.ppt

Dan Romanascu: So this i= s a new type and is not backwards compatible?

Alan: Backwards compatible for proxies that treat as an opaque blob. = IANA says these types (241-244) are not used but they are used in the real = world. Tough.

Sam Hartman: I have a draf= t in abfab requiring this and would like to see this go fwd. Please donR= 17;t call it an OID though. 

 = ;Alan Dekok: Audit shows that this should handle allocation needs for the f= oreseeable future.

So we don’t ne= ed adhoc formats. Just help them implement this new format.

<= p class=3DMsoNormal>

******************= **********************************************

 

8. RADIUS over DTLS, Alan = DeKok

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

Presented by  Alan= Dekok.

Slidedeck:  http://www.ietf= .org/proceedings/81/slides/radext-7.ppt

= No questions.

**************************************************************= **

= 9. RADIUS over TLS, Stefan Winter (10 minutes)

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

Presented remotely by Stefan Winter.

Slidedeck: http://www.ietf.org/proceedings/81/slides/radext= -1.pdf

Mauricio: Agree that it is ready for WGLC. Any other comments/questions= ?

Dan Romanascu: TCP port allocation. In= tention is to reuse port for radsec. So are there any  backwards compa= tability issues.

Stefan Winter: No. Old= radsec is the format for RADIUS/TLS. OCS said once RFC is published they w= ill change their implementation to do it this way.

 

********************= ********************************************

(Margaret requested to present at RADEXT after agenda bashing had occu= rred and WG chairs accepted presentation request) 

 

10. Multihop Fed= erations (Trust Router).

Margaret Wasserman

Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-9.pptx

Philip Hal= lam-Baker: Looks like UUCP. It was replaced with DNS. Anything that looks l= ike a  namespace should be using DNS. Look at Bridge CAs. Used in PKI = space. Lots of univ are in Bridge Cas. Can also use Rulebook structure so n= ever need a path of more than 2 so don’t need

BGP.

Margaret Wasserman: T= his is not about getting to every node. Only about getting between nodes in= AAA infrastructure. They are all IP nodes and already in BGP

Philip Hallam-Baker: You will find you use only 10% o= f BGP and not the interesting part.

Hann= es: Draft addresses some of the issues. Relationship are not purely mechani= cal. Don’t want to talk to everyone. Like SAML, Liberty Alliance. Com= e up with circle of trust. They exist in AAA space. The Trust Router setup = allows shortcuts.

Alan Dekok: Echo Hanne= s. Need to represent biz relationships: Who to talk to depends on who is as= king. Still have questions on the details

Margaret Wasserman: This lets you put policy in interesting places (local= trust router). E.g. not route should Russian nodes even if the route is sh= orter.

Klaas Wierenga: This work is moti= vated by problems seen in large scale SAML deployments. Esp to express comp= lex polices around who you want to trust. Share some of Philips concerns

Philip Hallam-Baker: Working on this probl= em for 15yrs. Similar to other approaches that have already been implemente= d.

Sam Hartman: This is in the draft.

Philip: Why not in the presentation?=

Margaret Wasserman: Not accepted as WG item = in abfab. Feedback required on abfab list.

Hannes: Also talking to VOIP folks who are reusing BGP concepts.

Margaret Wasserman: we have not written these = protocols. If a better way, please explain.

Philip Hallam-Baker: Thinking as a CA. Someone has to manage it and mon= ey will flow around. The task of introduction is going to be paid. May want= to pay premium to find a path with a higher degree of trust.

Margaret Wasserman: Allows for biz intelligence at ma= ny different layers.

Philip Hallam-Baker= : Contracts will determine this. Don’t need this hop by hop. Can take= this offline.

Margaret Wasserman: Would= be interested in those pointers to approaches already tried.

Klaas Wierenga: This goes beyond abfab. So AD pushed = us to present in other groups that see the same type of problem. Welcome a = broad discussion.

Margaret Wasserman: On= agenda in abfab on Friday morning.

 

 

****************************************************************<= /o:p>

 

11.= Email list server migration

Dan Romana= scu: Please explain what it means for people on the list.

Mauricio: Nothing. Should be transparent. Got a process f= or archive migration.

Jouni: Auto move o= f subscribers to new list. Emails will be forwarded between lists. 

Secre= tary will move archives.

Dan: On behalf = of doubters: Can you explain migration of archives?

Mauricio: Others (Fred Baker) created the process for painless= migration of archives. So we

Dan: Do r= eferences on the tracker need to change?

Jouni: Direct links to archives need to be updated.

Mauricio: Will need to look into that and make sure it is reme= died.

 

****************************************************************

12. N= ext Steps: WG Chairs & ADs

WG Goals/= Milestones status

No questions

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78185121GVW0671EXCame_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 25 Jul 2011 16:24:12 +0000 Date: Mon, 25 Jul 2011 16:23:18 +0000 From: Leaf yeh Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session To: "draft-ietf-radext-ipv6-access@tools.ietf.org" , "radiusext@ops.ietf.org" Cc: "fine_sz@huawei.com" , Qiujin , Wangshuxiang Message-id: <2AB86B3E-7923-4B78-A7A6-3D7416CC1757@mimectl> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_3EPHcbtLqW3BaZvu8m4QXw)" Content-language: zh-CN Content-class: urn:content-classes:message Accept-Language: zh-CN, en-US Thread-topic: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3Tw== --Boundary_(ID_3EPHcbtLqW3BaZvu8m4QXw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Question for clarification: We already have the following Radius Attributes for the address/prefix pools: Framed-Pool (88, section 5.18 of RFC2869), Framed-IPv6-Pool (100, section 2.6 of RFC3162). http://www.iana.org/assignments/radius-types/radius-types.xml The foramt are the same as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/prefix pools: Delegated-IPv6-Prefix-Pool, Stateful-IPv6-Address-Pool, the fomat of these 2 attributes are the same as the above one. Supposed the above attributes could be explained as follows: Framed-Pool was designed for the IPv4 address pool; Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool; Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool; Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool; All above attributes are only used to provide the name of the address/prefix pools in a 'string'. I doubt the necessity to make so many 'name' or 'string' attributes for the different address/prefix pools to prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take the role to interpret the meaning of the pook name, right? I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv6? I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 prefix/address pool per the same logic. Am I right? Best Regards, Leaf --Boundary_(ID_3EPHcbtLqW3BaZvu8m4QXw) Content-id: Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

Question for clarification:

 

We already have the following Radius Attributes for the address/prefix pools:

 

Framed-Pool (88, section 5.18 of RFC2869),

Framed-IPv6-Pool (100, section 2.6 of RFC3162).

 

http://www.iana.org/assignments/radius-types/radius-types.xml

 

The foramt are the same as follows:

 

0                   1                   2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/prefix pools:

 

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

 

the fomat of these 2 attributes are the same as the above one.

 

 

Supposed the above attributes could be explained as follows:

 

Framed-Pool was designed for the IPv4 address pool; 

Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;

Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;

Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

 

All above attributes are only used to provide the name of the address/prefix pools in a 'string'. I doubt the necessity to make so many 'name' or 'string' attributes for the different address/prefix pools to prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take the role to interpret the meaning of the pook name, right?

 

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv6?

I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated-IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even think Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 prefix/address pool per the same logic. Am I right?

 

 

Best Regards,

Leaf

 

 

 


 

 


 

 

 

 

 

--Boundary_(ID_3EPHcbtLqW3BaZvu8m4QXw)-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 25 Jul 2011 13:46:38 +0000 Date: Mon, 25 Jul 2011 13:46:14 +0000 From: Jiangsheng Subject: Reviewing is appreciated on draft-ietf-softwire-6rd-radius-attrib-02 To: "radiusext@ops.ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B920121DB47@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-GB Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: Reviewing is appreciated on draft-ietf-softwire-6rd-radius-attrib-02 Thread-index: AcxK0SHX8H25pQ1dSC2uR41GAm6gJw== Hi, all, This draft is now under the WGLC in softwire WG. We would like to also get reviewing from Radext WG. This draft was presented in IETF 80 meeting and received valuable comments. It has modified according to these comments. http://tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib-02 The WGLC in softwire is end Aug 02. Comments before that date are appreciated. Best regards, Sheng -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 25 Jul 2011 13:33:36 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action: draft-ietf-radext-crypto-agility-requirements-07.txt Message-ID: <20110725133246.6845.44158.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 06:32:46 -0700 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. Title : Crypto-Agility Requirements for Remote Dial-In User Serv= ice (RADIUS) Author(s) : David B. Nelson Filename : draft-ietf-radext-crypto-agility-requirements-07.txt Pages : 12 Date : 2011-07-11 This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requir= ements-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-require= ments-07.txt -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 25 Jul 2011 02:42:03 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" Date: Mon, 25 Jul 2011 03:38:29 +0100 Subject: RADEXT WG Agenda for IETF 81 - Final Thread-Topic: RADEXT WG Agenda for IETF 81 - Final Thread-Index: AcxKc9HxGVHl6BtCTGamuwz9N7M1mw== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C78184A51@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78184A51GVW0671EXCame_" MIME-Version: 1.0 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78184A51GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Final agenda. See everyone tomorrow. -MS ----------------------------------------------- RADEXT WG IETF 81 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Monday, July 25, 2011 0900 - 1130 Room 2101 9:00 - 09:20 AM, Preliminaries (20 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status IPv6 items (45 minutes) 9:20 - 9:35 AM Radius Extensions for CGN Configurations, Dean Cheng (15 min= utes) http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-radius-ext-00.txt 9:35 - 9:50 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec (15 = minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access 9:50 - 10:05 AM RADIUS accounting for traffic classes, Stefan Winter (15 mi= n) http://tools.ietf.org/html/draft-winter-radext-fancyaccounting Enhancement items (30 minutes) 10:05 AM - 10:15 AM Dynamic Peer Discovery, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery 10:15 - 10:25 AM RFC4282bis, Alan DeKok (10 minutes) 10:25 - 10:35 AM RADIUS Protocol Extensions, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions Security items (20 minutes) 10:35 - 10:45 AM RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls 10:45 - 10:55 AM RADIUS over TLS, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec Discussion and Wrap-up (35 minutes) 10:55 - 11:15 AM Discussion (20 minutes) Email list server migration 11:15 - 11:30 AM Next Steps: WG Chairs & ADs (15 minutes) WG Goals/Milestones status --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78184A51GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Final agenda.&nb= sp; See everyone tomorrow.

 

-MS

&n= bsp;

----------------------------------------= -------

 

 

RADEXT WG IETF 81 Agend= a

 

Chairs:

Jouni Korhonen <jouni.kor= honen at nsn.com>

Mauricio Sanchez &l= t;mauricio.sanchez at hp.com>

&n= bsp;

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

 

Monday, July 25, 2011

090= 0 - 1130

Room 2101

 

9:00 - 09:20 AM, P= reliminaries (20 minutes)

Audio/Video &a= mp; Remote Presentation Debugging

Note W= ell

Note Takers

Jabber scribe

Agenda bash

Document Status

 

 

IPv6 items (45 minutes)

 

9:20 - 9:35 AM Radius Extensio= ns for CGN Configurations, Dean Cheng (15 minutes)

http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-radius-ext-0= 0.txt

 

9:35 - 9:50 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh = Dec (15 minutes)

http://tools.ietf.org/h= tml/draft-ietf-radext-ipv6-access

&= nbsp;

9:50 - 10:05 AM RADIUS accounting for t= raffic classes, Stefan Winter (15 min)

= http://tools.ietf.org/html/draft-winter-radext-fancyaccounting

 

 = ;

Enhancement items (30 minutes)

 

10:05 AM -= 10:15 AM Dynamic Peer Discovery, Stefan Winter (10 minutes)

=

http://tools.ietf.org/html/draft-ietf-radext-dynamic-d= iscovery

 

10:15 - 10:25 AM RFC4282bis, Alan DeKok (10 minutes)

 

10:25 -= 10:35 AM RADIUS Protocol Extensions, Alan DeKok (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-radius-e= xtensions

 

 

Security items (20 m= inutes)

 

10:35  - 10:45 AM RADIUS over DTLS, Alan DeKok (10 minutes)<= o:p>

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

 

10:45  - 10:55 AM RADIUS over TLS, Stefan Winter (10 minu= tes)

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

 

 

Discussion and= Wrap-up (35 minutes)

 <= /p>

10:55 – 11:15 AM Discussion (20 minutes)=

Email list server migration

<= p class=3DMsoNormal> 

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

WG Goals/Milestones status

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C78184A51GVW0671EXCame_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 23 Jul 2011 23:32:06 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" CC: "jouni.korhonen@nsn.com" Date: Sun, 24 Jul 2011 00:30:40 +0100 Subject: IETF 81 - Remote attendees Thread-Topic: IETF 81 - Remote attendees Thread-Index: AcxJkCCtwezNUcLrRFWMOdpMZSemyg== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C781849DC@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849DCGVW0671EXCame_" MIME-Version: 1.0 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849DCGVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below is the email from IETF regarding remote attendance options. At this = time, we only plan to use audio streaming, but no WebEx. For those of you presenting on Monday that will be remote, we will specific= instructions through in another email. -MS Greetings! We're two weeks out from the beginning of meeting streaming. For those inte= rested in monitoring sessions or participating remotely the following infor= mation may prove useful. - -Audio Streaming- All 8 parallel tracks at the IETF 81 meeting will be broadcast starting wit= h the commencement of working group sessions on Monday, July 25, 2011 at 09= 00 EDT (GMT-4) and continue until Friday, July 29 at 1515 EDT. Because we have been asked several times in the past, note that if you wish= to use the rooms that are being recorded for impromptu meeting during unsc= heduled sessions or lunch breaks that you can invite remote participants to= tune in to the appropriate stream. Recording cannot be guaranteed for unsc= heduled sessions. Conversely, it should never be assumed that recording or = observation is not occurring on open microphones, they are after all connec= ted to the Internet. The links for streaming sources and the schedule are best retrieved from th= e IETF tools agenda, which as per Standard operating procedure will be loca= ted here: http://tools.ietf.org/agenda/81/ - -Jabber/XMPP- For information on IETF Jabber participation see: http://www.ietf.org/jabber/index.html or click on the Jabber links in the tools team agenda once you have a prope= rly configured jabber/xmpp messaging client. - -Webex- Webex screen sharing participation is possible for a limited number of sess= ions. Consult with your working-group chair or the secretariat for more inf= ormation. - -Ticketing- For prompt access to the meeting trouble desk, the email address is: mtd@ietf.org For streaming related issues please send email to ietf-streaming@verilan.co= m with info including the current time a= nd affected streaming channel. Regards, --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849DCGVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Below is the email from IETF regarding rem= ote attendance options.  At this time, we only plan to use audio strea= ming, but no WebEx.  

 

For those of you presenting on Monday that will be remote, we wi= ll specific instructions through in another email.=

<= o:p> 

-MS

 

 

 =

 

 =

G= reetings!

We're two weeks out fr= om the beginning of meeting streaming. For those interested in monitoring sessions or participating re= motely the following information may prove useful.

- -Audio Streaming-

All 8 parallel t= racks at the IETF 81 m= eeting will be broadcast starting with the commencement of working group se= ssions on Monday, July 25, 2011 at 0900 EDT (GMT-4) and continue until Frid= ay, July 29 at 1515 EDT.

Becau= se we have been asked several times in the past, note that if you wish to u= se the rooms that are being recorded for impromptu meeting during unschedul= ed sessions or lunch breaks that you can invite remote participants to tune= in to the appropriate stream. Recording cannot be guaranteed for unschedul= ed sessions. Conversely, it should never be assumed that recording or obser= vation is not occurring on open microphones, they are after all connected t= o the Internet.

The links for&= nbsp;streaming sources and = the schedule are best retrieved from the IETF tools agenda, which as per Standard operating pro= cedure will be located here:

<= a href=3D"http://tools.ietf.org/agenda/80/" target=3D"_blank">http://tools.ietf.org/agenda/81/

= - -Jabber/XMPP-

For informatio= n on IETF Jabber parti= cipation see:

http://www.ietf.org/jabber= /index.html

or clic= k on the Jabber links in the tools team agenda once you have a properly con= figured jabber/xmpp messaging client.

- -Webex-

Webex screen= sharing participation is possible for a limited number of sessions. Consul= t with your working-group chair or the secretariat for more information.

- -Ticketing-

For prompt access to the meeting trouble desk, t= he email address is:

mtd@ietf= .org

For streaming related issues please send email to ietf-streaming<= /span>@verilan.com with info = including the current time and affected streaming channel.

Regards,

 =

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849DCGVW0671EXCame_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 23 Jul 2011 22:19:48 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" CC: "jouni.korhonen@nsn.com" Date: Sat, 23 Jul 2011 23:13:35 +0100 Subject: RE: IETF 81 meeting slides - second call Thread-Topic: IETF 81 meeting slides - second call Thread-Index: AcxJhaC6LZDIiBirTqKduW/zA3KEYw== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C781849CA@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849CAGVW0671EXCame_" MIME-Version: 1.0 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849CAGVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks if you have submitted your slides. If you have not, please do so AS= AP. Our meeting is Monday morning. Thanks, Mauricio --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849CAGVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Thanks if yo= u have submitted your slides.  If you have not, please do so ASAP. &nb= sp;Our meeting is Monday morning.

 

T= hanks,

Mauricio

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C781849CAGVW0671EXCame_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 20 Jul 2011 20:25:57 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" CC: "jouni.korhonen@nsn.com" Date: Wed, 20 Jul 2011 21:23:48 +0100 Subject: IETF 81 meeting slides Thread-Topic: IETF 81 meeting slides Thread-Index: AcxHGu6eQ2kx3SC3SECHFw6irHYPiw== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C7791D959@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C7791D959GVW0671EXCame_" MIME-Version: 1.0 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C7791D959GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you are presenting and have not submitted to co-chairs your slides, plea= se do so at your earliest convenience. This time around we are in at the= start of the week, so slides are due earlier than in past meetings. Thanks, Mauricio --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C7791D959GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you are prese= nting and have not submitted to co-chairs your slides, please do so at your= earliest convenience.    This time around we are in at the = start of the week, so slides are due earlier than in past meetings.

 

Than= ks,

Mauricio

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C7791D959GVW0671EXCame_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 14 Jul 2011 15:49:43 +0000 Message-ID: <4E1F0FCF.2010602@deployingradius.com> Date: Thu, 14 Jul 2011 17:48:31 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" CC: "Sanchez, Mauricio (HP Networking)" , Klaas Wierenga , Dave Nelson , radiusext@ops.ietf.org Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Romascanu, Dan (Dan) wrote: > Before proceeding I think that it is important to hear also from Alan > who was the first who introduced in the discussion (and subject line of > the thread) the idea of an appeal. Alan, please clarify whether you > intent to continue with a formal and detailed appeal to the WG chairs. I've discussed this with Mauricio privately. I won't be filing a formal appeal. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 14 Jul 2011 05:50:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Date: Thu, 14 Jul 2011 07:49:39 +0200 Message-ID: Thread-Topic: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acw/1jK5VK4bNVSmTG2ucH/9AjIlawBryv9gABhBZmA= From: "Romascanu, Dan (Dan)" To: "Sanchez, Mauricio (HP Networking)" , "Klaas Wierenga" , "Dave Nelson" Cc: "Alan DeKok" , Hi,=20 Thanks to all for the opinions and advice.=20 Before proceeding I think that it is important to hear also from Alan who was the first who introduced in the discussion (and subject line of the thread) the idea of an appeal. Alan, please clarify whether you intent to continue with a formal and detailed appeal to the WG chairs. If the answer is yes I would kindly ask that you describes exactly in your own words what you are appealing and which actions of the WG chairs would satisfy your concerns. If there is no intention to continue with a formal appeal this should also be made clear, and the WG can discuss if everybody is OK with the proposal and commitment of the WG chair (Mauricio).=20 Thanks and Regards, Dan=20 > -----Original Message----- > From: Sanchez, Mauricio (HP Networking) > [mailto:mauricio.sanchez@hp.com] > Sent: Wednesday, July 13, 2011 9:06 PM > To: Klaas Wierenga; Dave Nelson > Cc: Romascanu, Dan (Dan); Alan DeKok; radiusext@ops.ietf.org > Subject: RE: APPEAL: Re: Conclusion of RADEXT WG call for consensus > poll for IANA #409959 NAS-Port-Type value request >=20 > Klaas, > Apologies for my lack of response as I have been taking some time off > these last couple of weeks and I've clearly let RADEXT fall through the > cracks. As I stated in my response to Dave, this situation was > discussed between the chairs and AD and we all agreed that we could > move forward in this particular instance. Unless guidance differs from > the AD, I've taken note that in future discussions we should not be as > tolerant of non-standard comments. >=20 > As for the flash mob effect, I've been in IETF long enough to see it > happen. They do happen and will continue to happen. It's the nature of > our business. However, I fully agree with you that crystal clear > transparency and timeliness is necessary. You have my commitment > moving forward. >=20 > BTW, the official minutes for IETF 80 RADEXT state that you had no > opinion on this IANA request, so at least from the minutes there's no > clear indication of your approval or disapproval. In hindsight, > Bernard and I should have done a hum poll or such during the meeting. >=20 > -MS >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Klaas Wierenga [mailto:klaas@wierenga.net] > Sent: Monday, July 11, 2011 7:24 AM > To: Dave Nelson > Cc: Romascanu, Dan (Dan); Alan DeKok; Sanchez, Mauricio (HP > Networking); radiusext@ops.ietf.org > Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus > poll for IANA #409959 NAS-Port-Type value request >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Dave, >=20 > > It appears to me that the only thing that is in dispute is the > process > > issue of accepting comments not properly received on the RADEXT WG > > email list, and forwarded to the list as part of the decision > > announcement. >=20 > true, and the unwillingness of the chair to respond to critique and > questions... >=20 > > Now, it's true that old-time IETF'ers tend to disdain "flash mob > > voting", meaning a flurry of postings from individuals outside the WG > > core membership, at the behest of the proponent of a particular > > proposal. That appears to have been the case here, and explains why > > postings were sent to the "request" address, rather that the list > > itself. However, I don't believe that this form of input is > > officially distinguished from any other form input under the IETF > > process. >=20 > ehm, I am not so sure about that. The request address is *not* a public > address, and as such is different from the radext mailing list or a > statement at the IETF meeting. If the chair can at his discretion pull > out extra votes (why was my objection for example not noted, after all > it is in the minutes of the IETF meeting?) >=20 > > What's been demonstrated is that there are numerically more > supporters > > of this particular proposal outside the core RADEXT WG (or > > IETF) than opponents to it inside the core RADEXT WG. Given that > this > > proposal have been languishing for quite some time, perhaps we need > to > > let it slide. While I agree that the usage in this proposal not good >=20 > I don't mind letting it slide, if you read my earlier message, I just > asked Mauricio to in the future refrain from these practises and at the > very least forward the messages prior to the close of the call (hey, I > might want to organize my own "flash mob" if that is the new style ;-) > I was willing to put this on the chairs inexperience, and a simple > apology and promise not to use these shady tactics in the future would > have made me perfectly happy. Our chair however decided to completely > ignore any voices of concern. I find that rather insulting to those > that do show up at the meetings and discuss on the mailing list. >=20 > > RADIUS "form", the suggested alternatives all require the > > specification of a new RADIUS attribute. That would have been a good > > path to follow when the reuest was initially presented. >=20 > Indeed >=20 > Klaas >=20 > > > > Regards, > > > > Dave > > > > David B. Nelson Sr. Software Architect Elbrys Networks, Inc. > > www.elbrys.com +1.603.570.2636 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk4bB3kACgkQH2Wy/p4XeFK4zgCgjAQfRf1q9EOPRRZouXrUhBQk > 9zUAoMFJbQuKDvcbVwbBdsOtuZbw8lNi > =3DZvi3 > -----END PGP SIGNATURE----- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 13 Jul 2011 22:41:16 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" Date: Wed, 13 Jul 2011 23:37:16 +0100 Subject: RADEXT WG Agenda for IETF 81 - Take One Thread-Topic: RADEXT WG Agenda for IETF 81 - Take One Thread-Index: AcxBrUXPycXZ1yytT/CP9jOm6NKG+A== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C777D3CF5@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D3CF5GVW0671EXCame_" MIME-Version: 1.0 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D3CF5GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RADEXT WG IETF 81 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Monday, July 25, 2011 0900 - 1130 Room 2101 9:00 - 09:20 AM, Preliminaries (20 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status IPv6 items (45 minutes) 9:20 - 9:35 AM Radius Extensions for CGN Configurations, Dean Cheng (15 min= utes) http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-radius-ext-00.txt 9:35 - 9:50 AM RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec (15 = minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access 9:50 - 10:05 AM RADIUS accounting for traffic classes, Stefan Winter (15 mi= n) http://tools.ietf.org/html/draft-winter-radext-fancyaccounting Enhancement items (30 minutes) 10:05 AM - 10:15 AM Dynamic Peer Discovery, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery 10:15 - 10:25 AM RFC4282bis, Alan DeKok (10 minutes) 10:25 - 10:35 AM RADIUS Protocol Extensions, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions Security items (20 minutes) 10:35 - 10:45 AM RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls 10:45 - 10:55 AM RADIUS over TLS, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec Discussion and Wrap-up (35 minutes) 10:55 - 11:15 AM Discussion (20 minutes) 11:15 - 11:30 AM Next Steps: WG Chairs & ADs (15 minutes) --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D3CF5GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RADEXT WG IETF 8= 1 Agenda

 

Chairs:

Jouni Korhonen <= jouni.korhonen at nsn.com>

Mauricio S= anchez <mauricio.sanchez at hp.com>

 

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

 <= /p>

Monday, July 25, 2011

0900 - 1130

Room 2101<= /p>

 

9:00 - 09= :20 AM, Preliminaries (20 minutes)

=  

Audio/Video & Remote Presentation = Debugging

Note Well

Note Takers

Jabber scribe=

Agenda bash

Document Status

 

IPv6 items (45 minutes)

 

9:20 - 9:35 AM Radius E= xtensions for CGN Configurations, Dean Cheng (15 minutes)

http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-ra= dius-ext-00.txt

 

9:35 - 9:50 AM RADIUS Attributes for IPv6 Access Netw= orks, Wojcieh Dec (15 minutes)

http://tools.= ietf.org/html/draft-ietf-radext-ipv6-access

 

9:50 - 10:05 AM RADIUS ac= counting for traffic classes, Stefan Winter (15 min)

http://tools.ietf.org/html/draft-winter-radext-fancyaccountin= g

 

Enhancement items (30 minutes)

<= o:p> 

10:05 AM - 10:15 AM Dynamic Peer D= iscovery, Stefan Winter (10 minutes)

htt= p://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery<= /p>

 

10:15 - 1= 0:25 AM RFC4282bis, Alan DeKok (10 minutes)

 

10:25 - 10:35 AM RADIUS Proto= col Extensions, Alan DeKok (10 minutes)

= = http://tools.ietf.org/html/draft-ietf-radext-radius-extensions

 

Securi= ty items (20 minutes)

 <= /p>

10:35  - 10:45 AM RADIUS over DTLS, Alan DeKok= (10 minutes)

http://tools.ietf.org/html/draft-ietf-r= adext-dtls

 

10:45  - 10:55 AM RADIUS over TLS, Stefan Winter (10 = minutes)

http://tools.ietf.org/html/draft-ietf-rade= xt-radsec

 

Discussion and Wrap-up (35 minutes)

 

10:55 – 11:15 = AM Discussion (20 minutes)

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

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D3CF5GVW0671EXCame_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 13 Jul 2011 18:12:19 +0000 Mime-Version: 1.0 (iPad Mail 8J3) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <7E90A15D-210A-4B92-BE0F-E8F3F6F39FB1@wierenga.net> Cc: Dave Nelson , "Romascanu, Dan (Dan)" , Alan DeKok , "radiusext@ops.ietf.org" From: Klaas Wierenga Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Date: Wed, 13 Jul 2011 20:12:18 +0200 To: "Sanchez, Mauricio (HP Networking)" Mauricio, Thanks for the clarification and for the assurance that this is a one off oc= casion. Klaas On Jul 13, 2011, at 8:05 PM, "Sanchez, Mauricio (HP Networking)" wrote: > Klaas, > Apologies for my lack of response as I have been taking some time off thes= e last couple of weeks and I've clearly let RADEXT fall through the cracks. = As I stated in my response to Dave, this situation was discussed between th= e chairs and AD and we all agreed that we could move forward in this particu= lar instance. Unless guidance differs from the AD, I've taken note that in f= uture discussions we should not be as tolerant of non-standard comments. =20= >=20 > As for the flash mob effect, I've been in IETF long enough to see it happe= n. They do happen and will continue to happen. It's the nature of our busin= ess. However, I fully agree with you that crystal clear transparency and ti= meliness is necessary. You have my commitment moving forward.=20 >=20 > BTW, the official minutes for IETF 80 RADEXT state that you had no opinion= on this IANA request, so at least from the minutes there's no clear indicat= ion of your approval or disapproval. In hindsight, Bernard and I should hav= e done a hum poll or such during the meeting.=20 >=20 > -MS=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Klaas Wierenga [mailto:klaas@wierenga.net]=20 > Sent: Monday, July 11, 2011 7:24 AM > To: Dave Nelson > Cc: Romascanu, Dan (Dan); Alan DeKok; Sanchez, Mauricio (HP Networking); r= adiusext@ops.ietf.org > Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll f= or IANA #409959 NAS-Port-Type value request >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Dave, >=20 >> It appears to me that the only thing that is in dispute is the process=20= >> issue of accepting comments not properly received on the RADEXT WG=20 >> email list, and forwarded to the list as part of the decision=20 >> announcement. >=20 > true, and the unwillingness of the chair to respond to critique and questi= ons... >=20 >> Now, it's true that old-time IETF'ers tend to disdain "flash mob=20 >> voting", meaning a flurry of postings from individuals outside the WG=20 >> core membership, at the behest of the proponent of a particular=20 >> proposal. That appears to have been the case here, and explains why=20 >> postings were sent to the "request" address, rather that the list=20 >> itself. However, I don't believe that this form of input is=20 >> officially distinguished from any other form input under the IETF=20 >> process. >=20 > ehm, I am not so sure about that. The request address is *not* a public ad= dress, and as such is different from the radext mailing list or a statement a= t the IETF meeting. If the chair can at his discretion pull out extra votes (= why was my objection for example not noted, after all it is in the minutes o= f the IETF meeting?) >=20 >> What's been demonstrated is that there are numerically more supporters=20= >> of this particular proposal outside the core RADEXT WG (or >> IETF) than opponents to it inside the core RADEXT WG. Given that this=20= >> proposal have been languishing for quite some time, perhaps we need to=20= >> let it slide. While I agree that the usage in this proposal not good >=20 > I don't mind letting it slide, if you read my earlier message, I just aske= d Mauricio to in the future refrain from these practises and at the very lea= st forward the messages prior to the close of the call (hey, I might want to= organize my own "flash mob" if that is the new style ;-) I was willing to p= ut this on the chairs inexperience, and a simple apology and promise not to u= se these shady tactics in the future would have made me perfectly happy. Our= chair however decided to completely ignore any voices of concern. I find th= at rather insulting to those that do show up at the meetings and discuss on t= he mailing list. >=20 >> RADIUS "form", the suggested alternatives all require the=20 >> specification of a new RADIUS attribute. That would have been a good=20 >> path to follow when the reuest was initially presented. >=20 > Indeed >=20 > Klaas >=20 >>=20 >> Regards, >>=20 >> Dave >>=20 >> David B. Nelson Sr. Software Architect Elbrys Networks, Inc.=20 >> www.elbrys.com +1.603.570.2636 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk4bB3kACgkQH2Wy/p4XeFK4zgCgjAQfRf1q9EOPRRZouXrUhBQk > 9zUAoMFJbQuKDvcbVwbBdsOtuZbw8lNi > =3DZvi3 > -----END PGP SIGNATURE----- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 13 Jul 2011 18:07:46 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Klaas Wierenga , Dave Nelson CC: "Romascanu, Dan (Dan)" , Alan DeKok , "radiusext@ops.ietf.org" Date: Wed, 13 Jul 2011 19:05:32 +0100 Subject: RE: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Topic: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acw/1jK5VK4bNVSmTG2ucH/9AjIlawBryv9g Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C777D3A03@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Klaas, Apologies for my lack of response as I have been taking some time off these= last couple of weeks and I've clearly let RADEXT fall through the cracks. = As I stated in my response to Dave, this situation was discussed between t= he chairs and AD and we all agreed that we could move forward in this parti= cular instance. Unless guidance differs from the AD, I've taken note that = in future discussions we should not be as tolerant of non-standard comments= . =20 As for the flash mob effect, I've been in IETF long enough to see it happen= . They do happen and will continue to happen. It's the nature of our busin= ess. However, I fully agree with you that crystal clear transparency and t= imeliness is necessary. You have my commitment moving forward.=20 BTW, the official minutes for IETF 80 RADEXT state that you had no opinion = on this IANA request, so at least from the minutes there's no clear indicat= ion of your approval or disapproval. In hindsight, Bernard and I should ha= ve done a hum poll or such during the meeting.=20 -MS=20 =20 -----Original Message----- From: Klaas Wierenga [mailto:klaas@wierenga.net]=20 Sent: Monday, July 11, 2011 7:24 AM To: Dave Nelson Cc: Romascanu, Dan (Dan); Alan DeKok; Sanchez, Mauricio (HP Networking); ra= diusext@ops.ietf.org Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll fo= r IANA #409959 NAS-Port-Type value request -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dave, > It appears to me that the only thing that is in dispute is the process=20 > issue of accepting comments not properly received on the RADEXT WG=20 > email list, and forwarded to the list as part of the decision=20 > announcement. true, and the unwillingness of the chair to respond to critique and questio= ns... > Now, it's true that old-time IETF'ers tend to disdain "flash mob=20 > voting", meaning a flurry of postings from individuals outside the WG=20 > core membership, at the behest of the proponent of a particular=20 > proposal. That appears to have been the case here, and explains why=20 > postings were sent to the "request" address, rather that the list=20 > itself. However, I don't believe that this form of input is=20 > officially distinguished from any other form input under the IETF=20 > process. ehm, I am not so sure about that. The request address is *not* a public add= ress, and as such is different from the radext mailing list or a statement = at the IETF meeting. If the chair can at his discretion pull out extra vote= s (why was my objection for example not noted, after all it is in the minut= es of the IETF meeting?) > What's been demonstrated is that there are numerically more supporters=20 > of this particular proposal outside the core RADEXT WG (or > IETF) than opponents to it inside the core RADEXT WG. Given that this=20 > proposal have been languishing for quite some time, perhaps we need to=20 > let it slide. While I agree that the usage in this proposal not good I don't mind letting it slide, if you read my earlier message, I just asked= Mauricio to in the future refrain from these practises and at the very lea= st forward the messages prior to the close of the call (hey, I might want t= o organize my own "flash mob" if that is the new style ;-) I was willing to= put this on the chairs inexperience, and a simple apology and promise not = to use these shady tactics in the future would have made me perfectly happy= . Our chair however decided to completely ignore any voices of concern. I f= ind that rather insulting to those that do show up at the meetings and disc= uss on the mailing list. > RADIUS "form", the suggested alternatives all require the=20 > specification of a new RADIUS attribute. That would have been a good=20 > path to follow when the reuest was initially presented. Indeed Klaas >=20 > Regards, >=20 > Dave >=20 > David B. Nelson Sr. Software Architect Elbrys Networks, Inc.=20 > www.elbrys.com +1.603.570.2636 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4bB3kACgkQH2Wy/p4XeFK4zgCgjAQfRf1q9EOPRRZouXrUhBQk 9zUAoMFJbQuKDvcbVwbBdsOtuZbw8lNi =3DZvi3 -----END PGP SIGNATURE----- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 13 Jul 2011 17:53:03 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Dave Nelson , "Romascanu, Dan (Dan)" CC: Alan DeKok , Klaas Wierenga , "radiusext@ops.ietf.org" Date: Wed, 13 Jul 2011 18:50:13 +0100 Subject: RE: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Topic: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acw/0Kq0dRgTkdnoRTOF5QwqcYIycQBsrArw Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C777D39DA@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D39DAGVW0671EXCame_" MIME-Version: 1.0 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D39DAGVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As I stated in my previous message, this situation of incorrect list addres= s usage was discussed between the chairs and the AD. Given the fact that t= his proposal had been languishing for some time, that the request wasn't an= egregious violation of RADIUS, alternatives would require a new attribute,= industry was waiting for an answer from RADEXT, the chairs and AD felt tha= t we could proceed forward in counting these non-standard votes of approval= . There are times to be pedantic and times where we should not be, and so = we made the call to let this one "slide". Unless the AD has different guidance, I intend to be stricter in future ins= tances and not let non-standard votes be considered. -MS From: Dave Nelson [mailto:dnelson@elbrys.com] Sent: Monday, July 11, 2011 6:45 AM To: Romascanu, Dan (Dan) Cc: Alan DeKok; Klaas Wierenga; Sanchez, Mauricio (HP Networking); radiusex= t@ops.ietf.org Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll fo= r IANA #409959 NAS-Port-Type value request On Mon, Jul 11, 2011 at 5:55 AM, Romascanu, Dan (Dan) > wrote: > All appeals must include a detailed and specific description of the > facts of the dispute. It appears to me that the only thing that is in dispute is the process issu= e of accepting comments not properly received on the RADEXT WG email list, = and forwarded to the list as part of the decision announcement. Now, it's true that old-time IETF'ers tend to disdain "flash mob voting", m= eaning a flurry of postings from individuals outside the WG core membership= , at the behest of the proponent of a particular proposal. That appears to= have been the case here, and explains why postings were sent to the "reque= st" address, rather that the list itself. However, I don't believe that th= is form of input is officially distinguished from any other form input unde= r the IETF process. What's been demonstrated is that there are numerically more supporters of t= his particular proposal outside the core RADEXT WG (or IETF) than opponents= to it inside the core RADEXT WG. Given that this proposal have been langu= ishing for quite some time, perhaps we need to let it slide. While I agree= that the usage in this proposal not good RADIUS "form", the suggested alte= rnatives all require the specification of a new RADIUS attribute. That wou= ld have been a good path to follow when the reuest was initially presented. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D39DAGVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As I stat= ed in my previous message, this situation of incorrect list address usage w= as discussed between the chairs and the AD.  Given the fact that this = proposal had been languishing for some time, that the request wasn’t = an egregious violation of RADIUS, alternatives would require a new attribut= e, industry was waiting for an answer from RADEXT, the chairs and AD felt t= hat we could proceed forward in counting these non-standard votes of approv= al.  There are times to be pedantic and times where we should not be, = and so we made the call to let this one “slide”.

 

Unless the AD has different guidance, I intend to be stric= ter in future instances and not let non-standard votes be considered. =

 

-MS

 

 

 

From: Dave Nelson [mailto:dnelson@elbrys.com]
Sent: Monday, July 11, 2011 6:45 AM
To: Romascanu, Dan (Dan)
Cc= : Alan DeKok; Klaas Wierenga; Sanchez, Mauricio (HP Networking); radius= ext@ops.ietf.org
Subject: Re: APPEAL: Re: Conclusion of RADEXT WG= call for consensus poll for IANA #409959 NAS-Port-Type value request<= /o:p>

 

On Mon, Jul 11, 2011 at 5:55 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:


>    All appeals must include a detailed and specific des= cription of the
>    facts of the dispute.

 

It appears to me that the only thing that is in dispute is t= he process issue of accepting comments not properly received = ;on the RADEXT WG email list, and forwarded to the list= as part of the decision announcement.

 

Now, it= 's true that old-time IETF'ers tend to disdain "flash mob voting"= , meaning a flurry of postings from individuals outside the WG core members= hip, at the behest of the proponent of a particular proposal.  That ap= pears to have been the case here, and explains why postings were sent to th= e "request" address, rather that the list itself.  However, = I don't believe that this form of input is officially distin= guished from any other form input under the IETF process.

 

What's been demonstrated is that there are = numerically more supporters of this particular proposal outside the core RA= DEXT WG (or IETF) than opponents to it inside the core RADEXT WG.=  Given that this proposal have been languishing f= or quite some time, perhaps we need to let it slide.  While I agree th= at the usage in this proposal not good RADIUS "form", the suggest= ed alternatives all require the specification of a new RADIUS att= ribute.  That would have been a good path to follow whe= n the reuest was initially presented.

 

Regards,

Dave

David B. Nelson
Sr. Software ArchitectElbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C777D39DAGVW0671EXCame_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 13 Jul 2011 17:33:26 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Klaas Wierenga CC: "'radiusext@ops.ietf.org'" Date: Wed, 13 Jul 2011 18:30:50 +0100 Subject: RE: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Topic: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acwz/CvBj0gBcTiJTlCXwzX2wH9ubQNgWw+w Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C777D39B1@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Klaas, It was during discussion between the chairs and AD after the close of the p= oll that we determined that responses had not been sent to the correct emai= l. I was copied directly on each email, so I didn't notice that emails wer= e going to the incorrect address during the polling period. Otherwise, I w= ould have immediately forwarded emails to the email list. This point of em= ails not going to the correct email was discussed between chairs and AD and= for just this particular request and situation, we decided that we would c= ount the approvals sent to incorrect email as part of establishing rough c= onsensus to approve the request. Moreover, we, the chairs and AD, felt tha= t given (a)the minor misalignment between these new types and the attribute= definition and (b) the industry support for this request, that we could pr= oceed forward. =20 You are right that it doesn't matter what companies individuals represent. = I included company names purely as informational and should not be interpr= eted in any way.=20 For this particular consensus poll, we actually went through two consensus = polling periods. The first was on April 4 and the second was on May 17. = We did the second because the first was inconclusive. Did you not receive = both? The chairs and AD have the good intentions of RADEXT in mind and we will de= finitely keep the group appropriately engaged moving forward. =20 -MS=20 -----Original Message----- From: Klaas Wierenga [mailto:klaas@wierenga.net]=20 Sent: Sunday, June 26, 2011 5:26 AM To: Sanchez, Mauricio (HP Networking) Cc: 'radiusext@ops.ietf.org' Subject: Re: Conclusion of RADEXT WG call for consensus poll for IANA #4099= 59 NAS-Port-Type value request -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/24/11 9:42 PM, Sanchez, Mauricio (HP Networking) wrote: Mauricio, I find this procedure rather odd. I think at the very least you should have= forwarded the replies to the proper list before the poll closed. Far be it from me to suggest any conspiracy, but I find it inappropriate to= come up with a rabbit from the hat trick after the poll has closed. I thou= ght consensus was gauged on the list, not at some private alias? I have seen no discussion on the list, apart from Avi's responses (thanks f= or that!), where do all these people all of a sudden come from? And does it matter what company they represent? I was under the impression = that "we are all individuals"..... Can I ask for some more openness in future consensus polls? Klaas (who is ashamed that after expressing his opinion in the meeting, the= n on the list, he missed the final consensus call) > After discussion between current chairs and AD, the conclusion we have=20 > reached is to approve this request as we believe rough consensus for=20 > approval has been achieved. The situation is bit peculiar in that a=20 > number of industry individuals expressed themselves in favor of=20 > approving the request, but sent their email to the incorrect email=20 > address (owner-radiusext@ops.ietf.org rather than=20 > radiusext@ops.ietf.org). I have attached the emails for all those=20 > individuals who used the incorrect address. >=20 > The chairs appreciate the spirited conversation arising from this=20 > topic and do agree with the long-term RADIUS experts that these new=20 > types are not entirely in-line given the definition and past usage of > the attribute. However, the chairs feel the misalignment between > these new types and the attribute definition is not sufficiently large=20 > to warrant disallowing the allocation. We also took into account the=20 > industry support for immediate usage of these types into account. >=20 > So as to improve the usability of these new values, we will be asking=20 > IANA to include references to the appropriate WiMAX standards (and > sections if available) in the IANA registry. Avi: We'd appreciate > your assistance in getting us the right information to include. >=20 > If after this decision the WG would like to continue exploring a=20 > generalized solution to similar use cases, the chairs and AD are=20 > supportive. >=20 > -MS >=20 > ---------------------------------------------------------------------- > ---------------------------- > > Final count In Favor Clearwire - Dave McGiniss, David Holmes ZTE -=20 > Chu Li Alcatel - Pertez Feder Intel - Muthiah Venkatachala Huawei -=20 > Ronal Mao Samsun - Jungshin Park NSN - Seyeedi Shahab Sprint - Mark=20 > Lipford, Brent Hirschman Bridgewater - Avi Lior >=20 > Opposed Alan DeKok Stefan Winter Bernard Aboba Dave Nelson -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4HJUMACgkQH2Wy/p4XeFJpOwCdF+yKyZdjhuZdRLGkGrCdsj68 weEAnAiv2I8hkMYF0bQsk096qjFTi/69 =3DZmUy -----END PGP SIGNATURE----- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Jul 2011 18:20:46 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action: draft-ietf-radext-ipv6-access-05.txt Message-ID: <20110711181952.26274.22717.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 11:19:52 -0700 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. Title : RADIUS attributes for IPv6 Access Networks Author(s) : Benoit Lourdelet Wojciech Dec Behcet Sarikaya Glen Zorn David Miles Filename : draft-ietf-radext-ipv6-access-05.txt Pages : 15 Date : 2011-07-11 This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement; assignment of a named IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host DHCPv6 addressing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-ipv6-access-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-ipv6-access-05.txt -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Jul 2011 18:20:39 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: draft-ietf-radext-ipv6-access@tools.ietf.org, wdec@cisco.com Date: Mon, 11 Jul 2011 18:20:16 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #102: Comments on draft-ietf-radext-ipv6-access-04 Message-ID: <083.739796f0493290be957231da890d400a@trac.tools.ietf.org> #102: Comments on draft-ietf-radext-ipv6-access-04 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved with editorial changes into draft ver -05 -- -----------------------------------------------+---------------------------- Reporter: roberta.maglione@… | Owner: draft-ietf-radext-ipv6-access@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------------------+---------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Jul 2011 15:57:28 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com, bernard_aboba@hotmail.com Date: Mon, 11 Jul 2011 15:57:13 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #61: DNS attribute for IPv4? Message-ID: <075.b6bd94c1e4d7b1d5d697751c7ab5b65b@trac.tools.ietf.org> #61: DNS attribute for IPv4? Changes (by wdec@…): * status: assigned => closed * resolution: => fixed Comment: resolved as proposed. -- ---------------------------------------+------------------------------------ Reporter: aland@… | Owner: wdec@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: ipv6-access | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Jul 2011 15:56:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com, bernard_aboba@hotmail.com Date: Mon, 11 Jul 2011 15:56:04 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #71: Section 2.3 and 3.3 Message-ID: <075.f59b262e6544f845776c41915bc40df8@trac.tools.ietf.org> #71: Section 2.3 and 3.3 Changes (by wdec@…): * status: assigned => closed * resolution: => fixed Comment: accepted. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Jul 2011 15:47:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com, bernard_aboba@hotmail.com Date: Mon, 11 Jul 2011 15:46:42 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #69: Section 1 Message-ID: <075.f34b47229a63ef9fe0f777cf35f9eaea@trac.tools.ietf.org> #69: Section 1 Changes (by wdec@…): * status: assigned => closed * resolution: => fixed Comment: resolved as proposed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Jul 2011 14:25:00 +0000 Message-ID: <4E1B0779.1040302@wierenga.net> Date: Mon, 11 Jul 2011 16:23:53 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Dave Nelson CC: "Romascanu, Dan (Dan)" , Alan DeKok , "Sanchez, Mauricio (HP Networking)" , radiusext@ops.ietf.org Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dave, > It appears to me that the only thing that is in dispute is the > process issue of accepting comments not properly received on the > RADEXT WG email list, and forwarded to the list as part of the > decision announcement. true, and the unwillingness of the chair to respond to critique and questions... > Now, it's true that old-time IETF'ers tend to disdain "flash mob > voting", meaning a flurry of postings from individuals outside the > WG core membership, at the behest of the proponent of a particular > proposal. That appears to have been the case here, and explains why > postings were sent to the "request" address, rather that the list > itself. However, I don't believe that this form of input is > officially distinguished from any other form input under the IETF > process. ehm, I am not so sure about that. The request address is *not* a public address, and as such is different from the radext mailing list or a statement at the IETF meeting. If the chair can at his discretion pull out extra votes (why was my objection for example not noted, after all it is in the minutes of the IETF meeting?) > What's been demonstrated is that there are numerically more > supporters of this particular proposal outside the core RADEXT WG (or > IETF) than opponents to it inside the core RADEXT WG. Given that > this proposal have been languishing for quite some time, perhaps we > need to let it slide. While I agree that the usage in this proposal > not good I don't mind letting it slide, if you read my earlier message, I just asked Mauricio to in the future refrain from these practises and at the very least forward the messages prior to the close of the call (hey, I might want to organize my own "flash mob" if that is the new style ;-) I was willing to put this on the chairs inexperience, and a simple apology and promise not to use these shady tactics in the future would have made me perfectly happy. Our chair however decided to completely ignore any voices of concern. I find that rather insulting to those that do show up at the meetings and discuss on the mailing list. > RADIUS "form", the suggested alternatives all require the > specification of a new RADIUS attribute. That would have been a good > path to follow when the reuest was initially presented. Indeed Klaas > > Regards, > > Dave > > David B. Nelson Sr. Software Architect Elbrys Networks, Inc. > www.elbrys.com +1.603.570.2636 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4bB3kACgkQH2Wy/p4XeFK4zgCgjAQfRf1q9EOPRRZouXrUhBQk 9zUAoMFJbQuKDvcbVwbBdsOtuZbw8lNi =Zvi3 -----END PGP SIGNATURE----- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Jul 2011 09:55:42 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Date: Mon, 11 Jul 2011 11:55:24 +0200 Message-ID: Thread-Topic: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acw/qZTU08scupyOSUq4fRHZO+bQZwABskgw From: "Romascanu, Dan (Dan)" To: "Alan DeKok" , "Klaas Wierenga" Cc: "Sanchez, Mauricio (HP Networking)" , Hi Alan,=20 If this is a formal appeal to the WG chairs, please formulate it in a more detailed manner. I recommend that you read RFC 2026, section 6.5, and especially 6.5.1 and 6.5.4 to start with.=20 As per 6.5.4:=20 > All appeals must include a detailed and specific description of the facts of the dispute. =20 Thanks and Regards, Dan=20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Monday, July 11, 2011 12:04 PM > To: Klaas Wierenga > Cc: Sanchez, Mauricio (HP Networking); Romascanu, Dan (Dan); > 'radiusext@ops.ietf.org' > Subject: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll > for IANA #409959 NAS-Port-Type value request >=20 > Klaas Wierenga wrote: > > Is it too much to expect a response to my e-mail? It is not even that > I > > care *that* much about the issue at hand, but I find the style of > > communication (or rather the lack thereof) extremely > disappointing..... >=20 > I concur. >=20 > I'd like to appeal the decision. >=20 > Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Jul 2011 09:51:49 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Date: Mon, 11 Jul 2011 11:50:10 +0200 Message-ID: Thread-Topic: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acw/qGroPLRPVVIuT92exsJYRojJRgABr5tA From: "Romascanu, Dan (Dan)" To: "Klaas Wierenga" , "Sanchez, Mauricio (HP Networking)" Cc: Hi Mauricio,=20 I believe that Klaas has a point here. As WG chair you and/or your co-chair should respond to Klaas's mail and address his concerns about the way the consensus call was conducted. =20 Thanks and Regards, Dan=20 > -----Original Message----- > From: Klaas Wierenga [mailto:klaas@wierenga.net] > Sent: Monday, July 11, 2011 11:56 AM > To: Sanchez, Mauricio (HP Networking); Romascanu, Dan (Dan) > Cc: 'radiusext@ops.ietf.org' > Subject: Re: Conclusion of RADEXT WG call for consensus poll for IANA > #409959 NAS-Port-Type value request >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Mauricio, Dan, >=20 > Is it too much to expect a response to my e-mail? It is not even that I > care *that* much about the issue at hand, but I find the style of > communication (or rather the lack thereof) extremely disappointing..... >=20 > Klaas >=20 > On 6/26/11 2:25 PM, Klaas Wierenga wrote: > > On 6/24/11 9:42 PM, Sanchez, Mauricio (HP Networking) wrote: > > > > Mauricio, > > > > I find this procedure rather odd. I think at the very least you > > should have forwarded the replies to the proper list before the poll > > closed. Far be it from me to suggest any conspiracy, but I find it > > inappropriate to come up with a rabbit from the hat trick after the > > poll has closed. I thought consensus was gauged on the list, not at > > some private alias? I have seen no discussion on the list, apart from > > Avi's responses (thanks for that!), where do all these people all of > > a sudden come from? And does it matter what company they represent? I > > was under the impression that "we are all individuals"..... > > > > Can I ask for some more openness in future consensus polls? > > > > Klaas (who is ashamed that after expressing his opinion in the > > meeting, then on the list, he missed the final consensus call) > > > > > >> After discussion between current chairs and AD, the conclusion we > >> have reached is to approve this request as we believe rough > >> consensus for approval has been achieved. The situation is bit > >> peculiar in that a number of industry individuals expressed > >> themselves in favor of approving the request, but sent their email > >> to the incorrect email address (owner-radiusext@ops.ietf.org rather > >> than radiusext@ops.ietf.org). I have attached the emails for all > >> those individuals who used the incorrect address. > > > >> The chairs appreciate the spirited conversation arising from this > >> topic and do agree with the long-term RADIUS experts that these > >> new types are not entirely in-line given the definition and past > >> usage of the attribute. However, the chairs feel the misalignment > >> between these new types and the attribute definition is not > >> sufficiently large to warrant disallowing the allocation. We also > >> took into account the industry support for immediate usage of these > >> types into account. > > > >> So as to improve the usability of these new values, we will be > >> asking IANA to include references to the appropriate WiMAX > >> standards (and sections if available) in the IANA registry. Avi: > >> We'd appreciate your assistance in getting us the right information > >> to include. > > > >> If after this decision the WG would like to continue exploring a > >> generalized solution to similar use cases, the chairs and AD are > >> supportive. > > > >> -MS > > > >> -------------------------------------------------------------------- > ------------------------------ > > > >> Final count In Favor Clearwire - Dave McGiniss, David Holmes ZTE > >> - Chu Li Alcatel - Pertez Feder Intel - Muthiah Venkatachala Huawei > >> - Ronal Mao Samsun - Jungshin Park NSN - Seyeedi Shahab Sprint - > >> Mark Lipford, Brent Hirschman Bridgewater - Avi Lior > > > >> Opposed Alan DeKok Stefan Winter Bernard Aboba Dave Nelson > > > > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org > > with the word 'unsubscribe' in a single line as the message text > > body. archive: >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk4aurEACgkQH2Wy/p4XeFJqngCfXBDweUhBoECg7CnT1VQQk69z > Kc0AoKbsOhLXz1HhrKZpNnn6roZaZpIK > =3DpNbq > -----END PGP SIGNATURE----- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Jul 2011 09:04:32 +0000 Message-ID: <4E1ABC91.6020209@deployingradius.com> Date: Mon, 11 Jul 2011 11:04:17 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Klaas Wierenga CC: "Sanchez, Mauricio (HP Networking)" , "Romascanu, Dan (Dan)" , "'radiusext@ops.ietf.org'" Subject: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Klaas Wierenga wrote: > Is it too much to expect a response to my e-mail? It is not even that I > care *that* much about the issue at hand, but I find the style of > communication (or rather the lack thereof) extremely disappointing..... I concur. I'd like to appeal the decision. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Jul 2011 08:57:09 +0000 Message-ID: <4E1ABAB2.70401@wierenga.net> Date: Mon, 11 Jul 2011 10:56:18 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" , "Romascanu, Dan (Dan)" CC: "'radiusext@ops.ietf.org'" Subject: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mauricio, Dan, Is it too much to expect a response to my e-mail? It is not even that I care *that* much about the issue at hand, but I find the style of communication (or rather the lack thereof) extremely disappointing..... Klaas On 6/26/11 2:25 PM, Klaas Wierenga wrote: > On 6/24/11 9:42 PM, Sanchez, Mauricio (HP Networking) wrote: > > Mauricio, > > I find this procedure rather odd. I think at the very least you > should have forwarded the replies to the proper list before the poll > closed. Far be it from me to suggest any conspiracy, but I find it > inappropriate to come up with a rabbit from the hat trick after the > poll has closed. I thought consensus was gauged on the list, not at > some private alias? I have seen no discussion on the list, apart from > Avi's responses (thanks for that!), where do all these people all of > a sudden come from? And does it matter what company they represent? I > was under the impression that "we are all individuals"..... > > Can I ask for some more openness in future consensus polls? > > Klaas (who is ashamed that after expressing his opinion in the > meeting, then on the list, he missed the final consensus call) > > >> After discussion between current chairs and AD, the conclusion we >> have reached is to approve this request as we believe rough >> consensus for approval has been achieved. The situation is bit >> peculiar in that a number of industry individuals expressed >> themselves in favor of approving the request, but sent their email >> to the incorrect email address (owner-radiusext@ops.ietf.org rather >> than radiusext@ops.ietf.org). I have attached the emails for all >> those individuals who used the incorrect address. > >> The chairs appreciate the spirited conversation arising from this >> topic and do agree with the long-term RADIUS experts that these >> new types are not entirely in-line given the definition and past >> usage of the attribute. However, the chairs feel the misalignment >> between these new types and the attribute definition is not >> sufficiently large to warrant disallowing the allocation. We also >> took into account the industry support for immediate usage of these >> types into account. > >> So as to improve the usability of these new values, we will be >> asking IANA to include references to the appropriate WiMAX >> standards (and sections if available) in the IANA registry. Avi: >> We'd appreciate your assistance in getting us the right information >> to include. > >> If after this decision the WG would like to continue exploring a >> generalized solution to similar use cases, the chairs and AD are >> supportive. > >> -MS > >> -------------------------------------------------------------------------------------------------- > >> Final count In Favor Clearwire - Dave McGiniss, David Holmes ZTE >> - Chu Li Alcatel - Pertez Feder Intel - Muthiah Venkatachala Huawei >> - Ronal Mao Samsun - Jungshin Park NSN - Seyeedi Shahab Sprint - >> Mark Lipford, Brent Hirschman Bridgewater - Avi Lior > >> Opposed Alan DeKok Stefan Winter Bernard Aboba Dave Nelson > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org > with the word 'unsubscribe' in a single line as the message text > body. archive: -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4aurEACgkQH2Wy/p4XeFJqngCfXBDweUhBoECg7CnT1VQQk69z Kc0AoKbsOhLXz1HhrKZpNnn6roZaZpIK =pNbq -----END PGP SIGNATURE----- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Jul 2011 07:37:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: draft-ietf-radext-ipv6-access@tools.ietf.org, roberta.maglione@telecomitalia.it Date: Mon, 11 Jul 2011 07:36:24 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #102: Comments on draft-ietf-radext-ipv6-access-04 Message-ID: <074.87f6e6ae0de4961fd9bfd0855312923b@trac.tools.ietf.org> #102: Comments on draft-ietf-radext-ipv6-access-04 Hello, I read this document and I have some comments. This draft, in section 2.1, introduces Framed-IPv6-Address Attribute to be used for providing a DHCPv6 server residing on a NAS with one or more IPv6 addresses to be assigned to the clients. An alternative way to achieve a similar result is to extract an IPv6 address to be assigned, from a pool of addresses locally configured on the NAS. In my opinion it would be useful to add in this document a new attribute to allow the RADIUS server to convey a pool name to be used for DHCPv6 based addressing, when a single IPv6 address needs to be assigned to a host, to a NAS hosting a DHCPv6 server. I wrote an initial proposal in order to add the new attribute in the current draft, please see attached file. Any comments or feedback from the authors and from the group are welcome. Thanks, Best regards, Roberta Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. -- -----------------------------------------------+---------------------------- Reporter: roberta.maglione@… | Owner: draft-ietf-radext-ipv6-access@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: Active WG Document | Keywords: -----------------------------------------------+---------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Jul 2011 07:17:35 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Mon, 11 Jul 2011 07:17:12 -0000 Reply-To: radiusext@ops.ietf.org Subject: =?utf-8?q?Re=3A_=5Bradext=5D_=23101=3A_Secdir_review_of_draft-ie?= =?utf-8?q?tf-radext-crypto-agility-requirements-06=E2=80=8F?= Message-ID: <072.d6fc1008cb1475645509bf3e77d286c0@trac.tools.ietf.org> #101: Secdir review of draft-ietf-radext-crypto-agility-requirements-06‏ Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Proposed resolution is as follows: In Section 2 change "MUST NOT introduce new capabilities negotiation features" to "MUST NOT introduce generic new capabilities negotiation features". Change Section 4.3 to the following: 4.3. Backwards Compatibility Solutions MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both crypto-agility and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). While backward compatibility is needed to ease the transition between legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is only appropriate prior to the compromise of those mechanisms. After legacy mechanisms have been compromised, secure algorithms MUST be used, so that backward compatibility is no longer possible. Since RADIUS is a request/response protocol, the ability to negotiate cryptographic algorithms within a single RADIUS exchange is inherently limited. Prior to receipt of a response, a requester will not know what algorithms are supported by the responder. Therefore, while a RADIUS request can provide a list of supported cryptographic algorithms which can be selected for use within a response, prior to the receipt of a response, the cryptographic algorithms utilized to provide security services within an initial request will need to be pre-determined. In order to enable a request to be handled both by legacy as well as crypto-agile implementations, a request can be secured with legacy algorithms was well as with attributes providing security services using more secure algorithms. This approach allows a RADIUS packet to be processed by legacy implementations as well as by crypto-agile implementations, and does not result in additional response delays. If this technique is used, credentials used with legacy algorithms MUST be cryptographically independent of the credentials used with the more secure algorithms, so that compromise of the legacy credentials does not result in compromise of the credentials used with more secure algorithms. In this approach to backward compatibility, legacy mechanisms are initially used in requests sent between crypto-agile implementations. However, if the responder indicates support for crypto-agility, future requests can use more secure mechanisms. Note that if a responder is upgraded and then subsequently needs to be downgraded (e.g. due to bugs), this could result in requesters being unable to communicate with the downgraded responder unless a mechanism is provided to configure the requester to re-enable use of legacy algorithms. Probing techniques can be used to avoid the use of legacy algorithms in requests sent between crypto-agile implementations. For example, an initial request can omit use of legacy mechanisms. If a response is received, then the recipient can be assumed to be crypto-agile and future requests to that recipient can utilize secure mechanisms. Similarly, the responder can assume that the requester supports crypto-agility and can prohibit use of legacy mechanisms in future requests. Note that if a requester is upgraded and then subsequently needs to be downgraded (e.g. due to bugs), this could result in the requester being unable to interpret responses, unless a mechanism is provided to configure the responder to re-enable use of legacy algorithms. If a response is not received, in the absence of information indicating responder support for crypto-agility (such as pre- configuration or previous receipt of a crypto-agile response), a new request can be composed utilizing legacy mechanisms. Since legacy implementations not supporting crypto-agility will silently discard requests not protected by legacy algorithms rather than returning an error, repeated requests can be required to distinguish lack of support for crypto-agility from packet loss or other failure conditions. Therefore probing techniques can delay initial communication between crypto-agile requesters and legacy responders. This can be addressed by upgrading the responders (e.g. RADIUS servers) first. -- ------------------------------------+--------------------------------------- Reporter: charliek@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Jul 2011 07:03:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Mon, 11 Jul 2011 07:02:42 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #100: Gen-ART Review Message-ID: <076.dc584d681dcb4a8ac9bd857299019c1e@trac.tools.ietf.org> #100: Gen-ART Review Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Proposed resolution is as follows: - Change: OLD: This memo, when approved, reflects the consensus of the RADIUS Extensions (RADEXT) Working Group of the IETF as to the features, properties and limitations of the crypto-agility work item for RADIUS. NEW: This memo describes the features, properties and limitations of the crypto-agility solution for RADIUS. - Introduction,second paragraph. In this situation, there has apparently been some confusion about the history, so articulating the background is important. - Section 1.3 has been deleted. - Section 2. First sentence has been deleted. - Section 2, 4th paragraph. SHOULD NOT upgraded to MUST NOT. - Section 4.2, 5th paragraph, 1st sentence. Change to: " Support for encryption of individual RADIUS attributes is OPTIONAL for solutions that provide encryption of entire RADIUS packets." - Section 4.2, "Limit key scope" paragraph. Change to: Support for end-to-end confidentiality of RADIUS attributes is OPTIONAL. Change Section 4.3 to: 4.3. Backwards Compatibility Solutions MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both crypto-agility and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). While backward compatibility is needed to ease the transition between legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is only appropriate prior to the compromise of those mechanisms. After legacy mechanisms have been compromised, secure algorithms MUST be used, so that backward compatibility is no longer possible. Since RADIUS is a request/response protocol, the ability to negotiate cryptographic algorithms within a single RADIUS exchange is inherently limited. Prior to receipt of a response, a requester will not know what algorithms are supported by the responder. Therefore, while a RADIUS request can provide a list of supported cryptographic algorithms which can be selected for use within a response, prior to the receipt of a response, the cryptographic algorithms utilized to provide security services within an initial request will need to be pre-determined. In order to enable a request to be handled both by legacy as well as crypto-agile implementations, a request can be secured with legacy algorithms was well as with attributes providing security services using more secure algorithms. This approach allows a RADIUS packet to be processed by legacy implementations as well as by crypto-agile implementations, and does not result in additional response delays. If this technique is used, credentials used with legacy algorithms MUST be cryptographically independent of the credentials used with the more secure algorithms. In this approach to backward compatibility, legacy mechanisms are initially used in requests sent between crypto-agile implementations. However, if the responder indicates support for crypto-agility, future requests can use more secure mechanisms. Probing techniques can be used to avoid the use of legacy algorithms in requests sent between crypto-agile implementations. For example, an initial request can omit use of legacy mechanisms. If a response is received, then the recipient can be assumed to be crypto-agile and future requests to that recipient can utilize secure mechanisms. Similarly, the responder can assume that the requester supports crypto-agility and can prohibit use of legacy mechanisms in future requests. If a response is not received, in the absence of information indicating responder support for crypto-agility (such as pre- configuration or previous receipt of a crypto-agile response), a new request can be composed utilizing legacy mechanisms. Since legacy implementations not supporting crypto-agility will silently discard requests not protected by legacy algorithms rather than returning an error, repeated requests can be required to distinguish lack of support for crypto-agility from packet loss or other failure conditions. Therefore probing techniques can delay initial communication between crypto-agile requesters and legacy responders. This can be addressed by upgrading the responders (e.g. RADIUS servers) first. - Section 4.6. Change OLD: At the IETF-70 meeting, and leading up to that meeting, the RADEXT WG debated whether or not RFC 4107 would require a RADIUS Crypto-Agility solution to feature Automated Key Management (AKM). The working group determined that AKM was not inherently required for RADIUS based on the following points: NEW: Consideration was given as to whether or not RFC 4107 would require a RADIUS Crypto-Agility solution to feature Automated Key Management (AKM). It was determined that AKM was not inherently required for RADIUS based on the following points: Nits: - Section 4.6, 1st paragraph after the bulleted list: Change .., the same time, … -> …, at the same time,... -- ----------------------------------------+----------------------------------- Reporter: mary.ietf.barnes@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Jul 2011 06:52:14 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Mon, 11 Jul 2011 06:51:12 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #99: AD Review of RADIUS Crypto-Agility Requirements Message-ID: <068.f96612faed9b2cc3e94bb5a6bdd7e2b0@trac.tools.ietf.org> #99: AD Review of RADIUS Crypto-Agility Requirements Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Proposed resolution is as follows: T1. This language appears to be boilerplate in AAA requirements RFCs and BCPs (see RFC 2989 Section 1.1, RFC 4962 Section 1.1, etc.). No change suggested. T2. Recommended change in 4.2 is: Guidance on acceptable algorithms can be found in [NIST-SP800-131A]. It is RECOMMENDED that mandatory-to-implement cryptographic algorithms be chosen from among those classified as "Acceptable" with no known deprecation date from within this or successor documents. T3. This is a typo. It should refer to Section 3. E1. A newer notice should be used. E2. Recommend combining Section 1.3 and 1.1 as follows: 1.1. General At the IETF-66 meeting, the RADIUS Extensions (RADEXT) Working Group was asked by members of the Security Area Directorate to prepare a formal description of a crypto-agility work item, and corresponding charter milestones. After consultation with one of the Security Area Directors, Russ Housley, text was initially proposed on the RADEXT WG mailing list on October 26, 2006: The RADEXT WG will review the security requirements for crypto- agility in IETF protocols, and identify the deficiencies of the existing RADIUS protocol specifications against these requirements. Specific attention will be paid to RFC 4962 [RFC4962]. The RADEXT WG will propose one or more specifications to remediate any identified deficiencies in the crypto-agility properties of the RADIUS protocol. The known deficiencies include the issue of negotiation of substitute algorithms for the message digest functions, the key-wrap functions, and the password-hiding function. Additionally, at least one mandatory to implement cryptographic algorithm will be defined in each of these areas, as required. This document describes the features, properties and limitations of RADIUS crypto-agility solutions, as well as defining the term "crypto-agility" as used in this context, and providing the motivations for this work. The requirements defined in this memo have been developed based on e- mail messages posted to the RADEXT WG mailing list, which may be found in the archives of that list. The purpose of framing the requirements in this memo is to formalize and memorialize them for future reference, and to bring them explicitly to the attention of the IESG and the IETF Community, as we proceed with this work. E3. The typo should be corrected. -- -----------------------------------+---------------------------------------- Reporter: dromasca@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 08 Jul 2011 18:01:21 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" Date: Fri, 8 Jul 2011 18:58:43 +0100 Subject: Agenda items for IETF 81 Thread-Topic: Agenda items for IETF 81 Thread-Index: Acw9mKrikl2IG9vJQm61mjzlsSnEJg== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C766D3409@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C766D3409GVW0671EXCame_" MIME-Version: 1.0 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C766D3409GVW0671EXCame_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RADEXT has been given a 2 =BD hour time slot on Monday morning (7/25) from = 09:00 to 11:30. Please send any requests for agenda slots to chairs. Thank you, Mauricio --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C766D3409GVW0671EXCame_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

RADEXT has been = given a 2 =BD hour time slot on Monday morning (7/25) from 09:00 to 11:30. =

 

Please send any requests for agenda slots to chairs.=A0

<= p class=3DMsoNormal> 

Thank you,

Mauricio

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C766D3409GVW0671EXCame_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 08 Jul 2011 13:10:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: stefan.winter@restena.lu Date: Fri, 08 Jul 2011 13:09:46 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #13: Review Message-ID: <075.815075c76d2d5bbc3224ea7ec92d35d1@trac.tools.ietf.org> #13: Review Changes (by stefan.winter@…): * status: new => closed * resolution: => fixed Comment: 1. regarding abstract and references: -09 now has no references in the abstract. The scope has been clarified to "RADIUS over TLS and DTLS". 2. the term RadSec has been replaced with RADIUS/TLS and RADIUS/DTLS 3. SRV labels have been changed. 4. Examples have been changed. 5. RFC4282 is not referenced any longer. 6. explanatory text for "name resultion library != DNS" has been added. A reference to the IDNAbis Protocol RFC has been added. 7. IPv6 usage has been mentioned; but the guidance is limited to "according to the host system's IP stack capabilities". It's difficult to be more specific. 8. regarding: when is dynamic discovery useful. Primarily for X.509 based operations yes, but there may be cases where an out-of-band mechanism delivers PSK keys "just in time" (abfab KNP may be an example). So I'm hesitant to scope the usefulness of this draft too tightly. I think this closes all the discussed points in this issue; please re-open if you think this is not the case. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: stefan.winter@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dynamic-discovery | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 08 Jul 2011 13:00:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: stefan.winter@restena.lu Date: Fri, 08 Jul 2011 13:00:37 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #93: Compliance with Crypto-Agility Requirements Message-ID: <075.a2bad8cf8ce347cb0b0ec7386aa51788@trac.tools.ietf.org> #93: Compliance with Crypto-Agility Requirements Changes (by stefan.winter@…): * status: new => closed * resolution: => fixed Comment: The newest rev -09 now contains Appendix C with this information. That should close the issue. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: radsec | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 08 Jul 2011 13:00:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: stefan.winter@restena.lu Date: Fri, 08 Jul 2011 12:59:45 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #14: DDNS Application Message-ID: <072.5a598b7253246b45cac01589cd57f704@trac.tools.ietf.org> #14: DDNS Application Changes (by stefan.winter@…): * status: new => closed * resolution: => fixed Comment: The current rev (-03) of the draft uses S-NAPTR definitions "aaa+auth" "aaa+acct" and "aaa+dynauth" along with the protocol fields "radius.tls" and "radius.dtls". This should close the issue. -- ------------------------------------+--------------------------------------- Reporter: leslie@… | Owner: stefan.winter@… Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: dynamic-discovery | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 08 Jul 2011 12:57:03 +0000 Message-ID: <4E16FE8D.5090508@restena.lu> Date: Fri, 08 Jul 2011 14:56:45 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: I-D Action: draft-ietf-radext-dynamic-discovery-03.txt Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig989042A4944CC0213E0F1B43" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig989042A4944CC0213E0F1B43 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, this revision uses service tags aaa+auth aaa+acct aaa+dynauth as S-NAPTR labels; it's the only major change to rev -02. Greetings, Stefan Winter Am 08.07.2011 14:53, schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the RADIUS EXTensions Working Group= of the IETF. > > Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and = RADIUS/DTLS > Author(s) : Stefan Winter > Mike McCauley > Filename : draft-ietf-radext-dynamic-discovery-03.txt > Pages : 9 > Date : 2011-07-08 > > This document specifies a means to find authoritative RADIUS servers= > for a given realm. It can be used in conjunction with RADIUS/TLS an= d > RADIUS/DTLS. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-radext-dynamic-discovery= -03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-dynamic-discovery-= 03.txt > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig989042A4944CC0213E0F1B43 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4W/o0ACgkQ+jm90f8eFWZ2XgCeJxvlQUFpnbp7o823RckBioqq OScAnjjhN/wv369pIBMiQi6YhZKRU4O/ =JYVb -----END PGP SIGNATURE----- --------------enig989042A4944CC0213E0F1B43-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 08 Jul 2011 12:56:01 +0000 Message-ID: <4E16FE52.1040004@restena.lu> Date: Fri, 08 Jul 2011 14:55:46 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 CC: radiusext@ops.ietf.org Subject: Re: I-D Action: draft-ietf-radext-radsec-09.txt Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4ACBD71D56C2BE88B5F721E0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4ACBD71D56C2BE88B5F721E0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, this revision includes - a new Appendix C: Compliance with crypto-agility requirements - wordsmithing regarding Connecting Client Identity - condensed packet types list This closes all tracker issues on the draft. I think it might be the time for (another) WG last call. Greetings, Stefan Winter Am 08.07.2011 14:04, schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the RADIUS EXTensions Working Group= of the IETF. > > Title : TLS encryption for RADIUS > Author(s) : Stefan Winter > Mike McCauley > Stig Venaas > Klaas Wierenga > Filename : draft-ietf-radext-radsec-09.txt > Pages : 21 > Date : 2011-07-08 > > This document specifies security on the transport layer (TLS) for th= e > RADIUS protocol when transmitted over TCP. This enables dynamic > trust relationships between RADIUS servers. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-09.txt > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig4ACBD71D56C2BE88B5F721E0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4W/lYACgkQ+jm90f8eFWYrlwCeOTzhsKWaG95l6oUmA0w8uIaE Dz8AniWTqXQGKRqlzpaHn4QV9k7aq7Ko =SFzo -----END PGP SIGNATURE----- --------------enig4ACBD71D56C2BE88B5F721E0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 08 Jul 2011 12:53:45 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action: draft-ietf-radext-dynamic-discovery-03.txt Message-ID: <20110708125316.10485.28224.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 05:53:16 -0700 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADI= US/DTLS Author(s) : Stefan Winter Mike McCauley Filename : draft-ietf-radext-dynamic-discovery-03.txt Pages : 9 Date : 2011-07-08 This document specifies a means to find authoritative RADIUS servers for a given realm. It can be used in conjunction with RADIUS/TLS and RADIUS/DTLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-dynamic-discovery-03.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-dynamic-discovery-03.t= xt -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 08 Jul 2011 12:05:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action: draft-ietf-radext-radsec-09.txt Message-ID: <20110708120423.25749.93529.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 05:04:23 -0700 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. Title : TLS encryption for RADIUS Author(s) : Stefan Winter Mike McCauley Stig Venaas Klaas Wierenga Filename : draft-ietf-radext-radsec-09.txt Pages : 21 Date : 2011-07-08 This document specifies security on the transport layer (TLS) for the RADIUS protocol when transmitted over TCP. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-09.txt -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 07 Jul 2011 21:40:13 +0000 From: Jouni Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Fwd: [Softwires] WG last call on RADIUS Attribute for 6rd Date: Fri, 8 Jul 2011 00:39:04 +0300 To: radiusext@ops.ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) FYI Begin forwarded message: > From: Yong Cui > Date: July 7, 2011 11:37:54 AM GMT+03:00 > To: Softwires-wg list > Cc: Yong Cui > Subject: [Softwires] WG last call on RADIUS Attribute for 6rd >=20 > The chairs of the Softwire WG would like to start a 2-week working > group last call on =B3RADIUS Attribute for 6rd=B2. > http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ >=20 > Please send substantive comments to the list and editorial comments > to the authors. >=20 > The wg last call ends on July 21 at 9am EST. >=20 > - Alain & Yong >=20 >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive:

[RM] All the configured pools are t= he same for the NAS, in this case an extra logic would be needed to instruc= t the NAS about which pool is for SLAAC and which one is for DHCPv6

 

The pools configured on the NAS ar= e not necessary to be the same. AAA server doesn't reall= y need to instruct the NAS the specified type = of pools, which is already configured on the NAS. Right?

 

 

Best Regards,

Leaf

 

 

 

=B7=A2=BC=FE=C8=CB: Maglione Roberta [robe= rta.maglione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:27
=B5=BD: Leaf yeh; 'Jacni Qin'
Cc: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf= .org; fine_sz@huawei.com; Qiujin; Wangshuxiang
=D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access afte= r IETF81 radext session

Please see inli= ne.

&= nbsp;

Best regards,

Roberta<= /font>

&= nbsp;

From:= Leaf yeh [mailto:leaf.y.yeh@huawei.com]
Sent: marted=A8=AC 26 lugli= o 2011 20.22
To: Maglione Roberta; 'Jacn= i Qin'
Cc: draft-ietf-radext-ipv6-= access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; = Wangshuxiang
Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

 

Roberta - If you use the s= ame attribute for both scenarios how does the NAS know if that pool is for = SLAAC or for Stateful DHCPv6?

NAS already has those pool names in its configuration, right?=

[RM] yes pools are already configur= ed in the NAS

 

NAS does know which one is= for SLAAC prefix pool, which one is for DHCPv6 address pool. <= /font>

 

[RM] All the configured pools are t= he same for the NAS, in this case an extra logic would be needed to instruc= t the NAS about which pool is for SLAAC and which one is for DHCPv6

 

 

 

That=A1=AFs why in my opinion the S= tateful-IPv6-Address-Pool is required.

 

 

Best Regards,

Leaf

 

 

=B7=A2=BC=FE=C8=CB<= font color=3D"black" size=3D"2" face=3D"Tahoma">:<= /b> Maglione Roberta [roberta.maglione@telecomitalia.it]
=B7=A2=CB=CD=CA=B1= =BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:13
=B5=BD= := 'Jacni Qin'
Cc: Leaf yeh; draft-ietf-ra= dext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com= ; Qiujin; Wangshuxiang
=D6=F7=CC=E2<= /font>= : RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext sess= ion

Hi Jacni,
   If you use the same attribute for both scenarios how does the = NAS know if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mail= to:jacniq@gmail.com]
Sent: marted=A8=AC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.i= etf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session

Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.maglione@tele= comitalia.it> wrote:
Hello Leaf,
    The different attributes proposed in this draft for the = pools name have all the same format (a string), but semantically they are d= ifferent, as they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Beha= lf Of Leaf yeh
Sent: luned=A8=AC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org Cc: fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0            &n= bsp;      1      &nb= sp;            2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br> |     Type      |  &= nbsp; Length     |     String... +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+<= br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'name' or 'str= ing' attributes for the different address/prefix pools to prevent the ambig= uity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non =A8=A8 necessario.


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni= sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per = errore siete cortesemente pregati di darne immediata comunicazione al mitte= nte e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks. 3D"rispe=Rispetta l'ambiente. No= n stampare questa mail se non =A8=A8 necessario.

On Wed, J= ul 27, 2011 at 2:45 AM, Maglione Roberta <roberta.maglione@telecomitalia.it<= /a>> wrote:

Sorry I=92m not su= re I have fully understood your example:

In IPv4 the client= only gets one IPv4 address extracted from a pool and we already have and a= ttribute for that pool: Frame-Pool

=A0<= /span>

In IPv6 there are = different scenarios (WAN and LAN side IPv6 prefix) described in the draft.<= u>

Roberta

=A0<= /span>

From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 20= 11 20.40

=A0

hi,

Here is an example from another perspective,

What if I use DHCPv4? Then a corresponding attribute for IPv4 is needed?

Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:37 AM, Maglione Roberta <roberta.maglione@telecomitalia.it> wr= ote:

The string only co= ntains a name, how does the NAS infer the semantic of that pool name (meaning SLAAC or DHCPv6) from the name?=

=A0<= u>

Roberta

=A0<= u>

From: Jacni Qin [mailto:ja= cniq@gmail.com]
Sent: marted=EC 26 luglio 20= 11 20.33


To: Maglione Roberta<= u>
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of= draft-ietf-radext-ipv6-access after IETF81 radext session=

=A0

hi,

That's what the "String" is for? :-)


Cheers,
Jacni

On Wed, Jul 27, 2011 at 2:13 AM, Maglione Roberta <roberta.maglione@telecomitalia.it> wr= ote:

Hi Jacni,
=A0 If you use the same attribute for both scenarios how does the NAS know = if that pool is for SLAAC or for Stateful DHCPv6?

Thanks,
Regards,
Roberta





________________________________________
From: Jacni Qin [mailto:jacniq@gmail.com]
Sent: marted=EC 26 luglio 2011 20.03
To: Maglione Roberta
Cc: Leaf yeh; draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org; fine_sz@huawei.com; Qiujin; Wangshuxiang
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad= ext session


Hi Roberta,

I agree with you about the semantical logic, while "Stateful-IPv6-Addr= ess-Pool" is not necessary, IMHO.


Cheers,
Jacni
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta <roberta.mag= lione@telecomitalia.it> wrote:
Hello Leaf,
=A0 =A0The different attributes proposed in this draft for the pools name h= ave all the same format (a string), but semantically they are different, as= they coved different scenarios.
As you also summarized in your email below,

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

So each attribute covers a different use-case/scenario and they can appear = in the same RADIUS packet at the same time.
If you want to use a single pool name use to cover all the 4 use cases list= ed above, you would also need to define a standard format/syntax for the po= ol name that allows the NAS to be able to disambiguate among the different = scenarios and in order to do that the NAS would need to have an extra logic to infer the semantic of that sp= ecific attribute from the assigned name.
Instead if you have a specific attribute for each specific scenario, the se= mantic is mapped to the attribute name, thus the NAS does not need an extra= logic to discovery the purpose of that pool and the pool name can be any s= tring, no limitation or special syntax is forced for the pool name.


Thanks,
Regards,
Roberta





________________________________________
From: own= er-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of= Leaf yeh
Sent: luned=EC 25 luglio 2011 18.23
To: draft-ietf-radext-ipv6-access@tools.ietf.org; radiusext@ops.ietf.org
Cc: fine_sz@huawei.= com; Qiujin; Wangshuxiang
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext = session

Question for clarification:

We already have the following Radius Attributes for the address/prefix pool= s:

Framed-Pool (88, section 5.18 of RFC2869),
Framed-IPv6-Pool (100, section 2.6 of RFC3162).

http://www.iana.org/assignments/radius-types/radius-types.= xml

The foramt are the same as follows:

0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|=A0=A0=A0=A0 Type =A0 =A0 =A0|=A0=A0=A0 Length =A0 =A0 |=A0=A0=A0=A0 Strin= g...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/= prefix pools:

Delegated-IPv6-Prefix-Pool,
Stateful-IPv6-Address-Pool,

the fomat of these 2 attributes are the same as the above one.


Supposed the above attributes could be explained as follows:

Framed-Pool was designed for the IPv4 address pool;
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;

All above attributes are only used to provide the name of the address/prefi= x pools in a 'string'. I doubt the necessity to make so many 'n= ame' or 'string' attributes for the different address/prefix po= ols to prevent the ambiguity. I guess 1 attribute for the name of the address/prefix pools might be enough. In fact, the NAS take th= e role to interpret the meaning of the pook name, right?

I think Framed-Pool can be re-used for the design purpose of Stateful-IPv6-= Address-Pool. Do we have any limitation on the usage of Framed-Pool for IPv= 6?
I think Framed-IPv6-Pool can be re-used for the design purpose of Delegated= -IPv6-Prefix-Pool to indicate a pool of IPv6 prefix pool. I could even thin= k Framed-Pool can replace Framed-IPv6-Pool to indicate the name of a IPv6 p= refix/address pool per the same logic. Am I right?


Best Regards,
Leaf












Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mitt= ente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

Rispetta l'ambien= te. Non stampare questa mail se non =E8 necessario.

Questo messaggio e i = suoi allegati sono indirizzati esclusivamente alle persone indicate. La dif= fusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=

=A0

Questo messaggio e i s= uoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi alt= ra azione derivante dalla conoscenza di queste informazioni sono rigorosame= nte vietate. Qualora abbiate ricevuto questo documento per errore siete cor= tesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-m= ail and any attachments=A0is=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks. <= /span>

3D"rispettaRispetta l'ambiente. Non stampare questa mail se non =E8 necessario.

=A0

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=A0is=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D=Rispetta l'ambient= e. Non stampare questa mail se non =E8 necessario.