Fwd: Nomcom 2011-2012: Call for Nominations

[jouni korhonen <[e-mail]>]

We encourage you to participate.

The chairs.

Begin forwarded message:

> From: NomCom Chair <[e-mail]>
> Date: August 23, 2011 1:32:18 AM GMT+03:00
> To: IETF Announcement list <[e-mail]>
> Cc: [e-mail]
> Subject: Nomcom 2011-2012: Call for Nominations 
> 
> Hi All,
> 
> The 2011-2012 Nominating committee is seeking nominations from now 
> until October 2, 2011. The list of open positions can be found at:
> 
> https://www.ietf.org/group/nomcom/2011/
> 
> Nominations may be made directly on the NomCom 2011-2012 pages by 
> selecting the Nominate link at the top of the page.  The URL for
> NomCom 2011-2012 pages is: 
> 
> https://www.ietf.org/group/nomcom/2011/
> 
> Nominations may also be made by email to [e-mail].
> If you do so, please include the word "Nominate" in the Subject and 
> indicate in the email who is being nominated, their email address (to
> confirm acceptance of the nomination), and the position for which you 
> are making the nomination. If you wish to nominate someone via email 
> for more than one position, please use separate emails to do so.
> 
> Self nomination is welcome. 
> 
> NomCom 2011-2012 will follow the policy for "Open Disclosure of Willing 
> Nominees" described in RFC 5680.  As stated in RFC 5680: "The list of 
> nominees willing to be considered for positions under review in the 
> current NomCom cycle is not confidential". Willing Nominees for each 
> position will be publicly listed.  The public nominee list will be 
> updated at least once a week and possibly more often as nominations are 
> received.
> 
> With the exception of publicly listing willing nominees, the 
> confidentiality requirements of RFC 3777 remain in effect.  All 
> feedback and NomCom deliberations will remain confidential and not 
> disclosed. 
> 
> Because the list of nominees this year is public, we will accept 
> feedback on the nominees starting August 23, 2011. Per RFC 5680, we 
> will accept feedback from the entire IETF community on all the nominees. 
> 
> If you wish to provide anonymous feedback, the chair or any of the 
> members will be happy to handle this for you.  The Nominating Committee 
> chair can be reached at [e-mail] and the entire nominating 
> committee can be reached at [e-mail]. The email addresses of 
> individual NomCom members is also on the NomCom 2011-2012 pages.
> 
> In addition to nominations, the Nominating Committee is actively
> seeking community input on the jobs that need to be filled.  We have
> received the job descriptions from the IAB, IESG, and IAOC and they can
> be found at:
> 
> https://www.ietf.org/group/nomcom/2011/iab-requirements
> https://www.ietf.org/group/nomcom/2011/iesg-requirements
> https://www.ietf.org/group/nomcom/2011/iaoc-requirements
> 
> However, we also need the community's views and input on the jobs 
> within each organization. If you have ideas on job responsibilities 
> (more, less, different), please let us know.  Please send suggestions 
> and feedback to [e-mail]. 
> 
> Thank you,
> 
> Suresh Krishnan
> Chair, NomCom 2011-2012
> [e-mail]
> [e-mail]
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-announce


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [e-mail]
Delivery-date: Wed, 24 Aug 2011 10:30:36 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=fQVWsGlUWDQQ55e9hrWRWxD/dTpmqQABqIpg5uXj3tw=; b=Tdoz/chamhKIn0e1dMiJcZzJBtA/Z91DiCAqvfc1Whwi0ctS2x2+8DQtKkT10hgUog kgNOgxBuhDMEU7x+C+L4donWcoTb+vkpu+SSrtbmidqz1EUyNTkwpAHjtXCD1nfeB5jU JBrutSEu3fkTOzOvfc9MvAyuVtMwh15xzx9Iw=
From: jouni korhonen <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Fwd: Nomcom 2011-2012: Call for Nominations 
Date: Wed, 24 Aug 2011 13:29:24 +0300
To: [e-mail], [e-mail]
Message-Id: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v1084)

We encourage you to participate.

The chairs.

Begin forwarded message:

> From: NomCom Chair <[e-mail]>
> Date: August 23, 2011 1:32:18 AM GMT+03:00
> To: IETF Announcement list <[e-mail]>
> Cc: [e-mail]
> Subject: Nomcom 2011-2012: Call for Nominations 
> 
> Hi All,
> 
> The 2011-2012 Nominating committee is seeking nominations from now 
> until October 2, 2011. The list of open positions can be found at:
> 
> https://www.ietf.org/group/nomcom/2011/
> 
> Nominations may be made directly on the NomCom 2011-2012 pages by 
> selecting the Nominate link at the top of the page.  The URL for
> NomCom 2011-2012 pages is: 
> 
> https://www.ietf.org/group/nomcom/2011/
> 
> Nominations may also be made by email to [e-mail].
> If you do so, please include the word "Nominate" in the Subject and 
> indicate in the email who is being nominated, their email address (to
> confirm acceptance of the nomination), and the position for which you 
> are making the nomination. If you wish to nominate someone via email 
> for more than one position, please use separate emails to do so.
> 
> Self nomination is welcome. 
> 
> NomCom 2011-2012 will follow the policy for "Open Disclosure of Willing 
> Nominees" described in RFC 5680.  As stated in RFC 5680: "The list of 
> nominees willing to be considered for positions under review in the 
> current NomCom cycle is not confidential". Willing Nominees for each 
> position will be publicly listed.  The public nominee list will be 
> updated at least once a week and possibly more often as nominations are 
> received.
> 
> With the exception of publicly listing willing nominees, the 
> confidentiality requirements of RFC 3777 remain in effect.  All 
> feedback and NomCom deliberations will remain confidential and not 
> disclosed. 
> 
> Because the list of nominees this year is public, we will accept 
> feedback on the nominees starting August 23, 2011. Per RFC 5680, we 
> will accept feedback from the entire IETF community on all the nominees. 
> 
> If you wish to provide anonymous feedback, the chair or any of the 
> members will be happy to handle this for you.  The Nominating Committee 
> chair can be reached at [e-mail] and the entire nominating 
> committee can be reached at [e-mail]. The email addresses of 
> individual NomCom members is also on the NomCom 2011-2012 pages.
> 
> In addition to nominations, the Nominating Committee is actively
> seeking community input on the jobs that need to be filled.  We have
> received the job descriptions from the IAB, IESG, and IAOC and they can
> be found at:
> 
> https://www.ietf.org/group/nomcom/2011/iab-requirements
> https://www.ietf.org/group/nomcom/2011/iesg-requirements
> https://www.ietf.org/group/nomcom/2011/iaoc-requirements
> 
> However, we also need the community's views and input on the jobs 
> within each organization. If you have ideas on job responsibilities 
> (more, less, different), please let us know.  Please send suggestions 
> and feedback to [e-mail]. 
> 
> Thank you,
> 
> Suresh Krishnan
> Chair, NomCom 2011-2012
> [e-mail]
> [e-mail]
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-announce


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Thu, 18 Aug 2011 02:43:10 +0000
Date: Thu, 18 Aug 2011 02:42:42 +0000
From: Leaf yeh <[e-mail]>
Subject: =?utf-8?B?UkU6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: "[e-mail]" <[e-mail]>
Cc: Dave Nelson <[e-mail]>, "David B. Nelson" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: =?utf-8?B?562U5aSNOiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2?= =?utf-8?Q?6-access_after_IETF81_radext_session?=
Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsP///hb8P//4L6o///A+qL/9rzAo//ro/OA/8mB5lD/jIfrZf8ZYB+A/jK3ogD8Y/LsAPjGgdyg8Yy7vqjjGcr+gMYyDgJAjGQZFIA=

RllJIGFuZCB0aGUgcmVjb3JkcyBpbiB0aGUgTUwgb2YgUmFkZXh0LiBTb21lIG90aGVyIGNvbW1l
bnRzIGluIHRoZSBvdGhlciBzZXBhcmF0ZSBlbWFpbHMgZnJvbSBEYXZlIHNlZW0gdG8gaGF2ZSBu
b3QgcmVjb3JkZWQgaW4gdGhpcyBNYWlsaW5nIExpc3QuIChodHRwczovL29wcy5pZXRmLm9yZy9s
aXN0cy9yYWRpdXNleHQvMjAxMC9tYWlsbGlzdC5odG1sIzAxMDA1ICkuDQoNCg0KQmVzdCBSZWdh
cmRzLA0KTGVhZg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMZWFmIHll
aCANClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTgsIDIwMTEgMTA6NDAgQU0NClRvOiByYWRpdXNl
eHRAb3BzLmlldGYub3JnDQpDYzogRGF2ZSBOZWxzb247IERhdmlkIEIuIE5lbHNvbg0KU3ViamVj
dDogRlc6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNj
ZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KDQpGWUkgYW5kIHRoZSByZWNvcmRzIGlu
IHRoZSBNTCBvZiBSYWRleHQuIFNvbWUgb3RoZXIgY29tbWVudHMgaW4gdGhlIG90aGVyIHNlcGFy
YXRlIGVtYWlscyBmcm9tIERhdmUgc2VlbSB0byBoYXZlIG5vdCByZWNvcmRlZCBpbiB0aGlzIE1M
Lg0KDQoNCkZyb206IERhdmUgTmVsc29uIFttYWlsdG86ZG5lbHNvbkBlbGJyeXMuY29tXSANClNl
bnQ6IFdlZG5lc2RheSwgQXVndXN0IDE3LCAyMDExIDc6MDcgUE0NClRvOiBXb2pjaWVjaCBEZWMN
CkNjOiBMZWFmIHllaDsgRGF2aWQgQi4gTmVsc29uOyBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFj
Y2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZzsgZmluZSBzejsgUWl1
amluOyBXYW5nc2h1eGlhbmc7IGRyYWZ0LXRhbi12Nm9wcy1mYXN0Ni1hYWFAdG9vbHMuaWV0Zi5v
cmc7IHJvYmVydGEgbWFnbGlvbmU7IGphY25pcUBnbWFpbC5jb207IEJlcm5hcmQgQWJvYmENClN1
YmplY3Q6IFJlOiDnrZTlpI06IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2
LWFjY2VzcyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb24NCg0KT24gV2VkLCBBdWcgMTcsIDIw
MTEgYXQgNDowNSBBTSwgV29qY2llY2ggRGVjIDx3ZGVjQGNpc2NvLmNvbT4gd3JvdGU6DQo+DQo+
IE9uIDE3LzA4LzIwMTEgMDk6MTAsICJMZWFmIHllaCIgPGxlYWYueS55ZWhAaHVhd2VpLmNvbT4g
d3JvdGU6DQo+DQo+PiBNeSBpc3N1ZSBpcyB3aGVuIHdlDQo+PiB0cnkgdG8gbWl4IGluIGEgZml4
ZWQgc2V0IG9mIGFkZHJlc3MgYXNzaWdubWVudCBtZXRob2RzIHdpdGggdGhlIHBvb2wNCj4+IG5h
bWVzLiDCoFNlcGFyYXRpb24gb2YgY29uY2VybnMuDQo+DQo+IFRoaXMgaXMgaW50ZXJlc3Rpbmcs
IGdpdmVuIHRoYXQgdGhlIHJvb3Qgb2YgdGhpcyB0aHJlYWQgaXMgeW91ciBlbWFpbA0KPiBwcm9w
b3NhbCBmb3IganVzdCB0aGF0Og0KPiBodHRwczovL29wcy5pZXRmLm9yZy9saXN0cy9yYWRpdXNl
eHQvMjAxMC9tc2cwMDk1OS5odG1sDQoNCkFjdHVhbGx5LCB0aGUgdGV4dCB5b3UndmUgYXR0cmli
dXRlZCB0byBMZWFmIHdhcyBteSBjb21tZW50Lg0KDQpSZWdhcmRzLA0KDQpEYXZlDQoNCkRhdmlk
IEIuIE5lbHNvbg0KU3IuIFNvZnR3YXJlIEFyY2hpdGVjdA0KRWxicnlzIE5ldHdvcmtzLCBJbmMu
DQp3d3cuZWxicnlzLmNvbQ0KKzEuNjAzLjU3MC4yNjM2DQo=

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Thu, 18 Aug 2011 02:41:52 +0000
Date: Thu, 18 Aug 2011 02:39:39 +0000
From: Leaf yeh <[e-mail]>
Subject: =?utf-8?B?Rlc6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: "[e-mail]" <[e-mail]>
Cc: Dave Nelson <[e-mail]>, "David B. Nelson" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: =?utf-8?B?562U5aSNOiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2?= =?utf-8?Q?6-access_after_IETF81_radext_session?=
Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsP///hb8P//4L6o///A+qL/9rzAo//ro/OA/8mB5lD/jIfrZf8ZYB+A/jK3ogD8Y/LsAPjGgdyg8Yy7vqjjGcr+gMYyDgJA

RllJIGFuZCB0aGUgcmVjb3JkcyBpbiB0aGUgTUwgb2YgUmFkZXh0LiBTb21lIG90aGVyIGNvbW1l
bnRzIGluIHRoZSBvdGhlciBzZXBhcmF0ZSBlbWFpbHMgZnJvbSBEYXZlIHNlZW0gdG8gaGF2ZSBu
b3QgcmVjb3JkZWQgaW4gdGhpcyBNTC4NCg0KDQpGcm9tOiBEYXZlIE5lbHNvbiBbbWFpbHRvOmRu
ZWxzb25AZWxicnlzLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxNywgMjAxMSA3OjA3
IFBNDQpUbzogV29qY2llY2ggRGVjDQpDYzogTGVhZiB5ZWg7IERhdmlkIEIuIE5lbHNvbjsgZHJh
ZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3NAdG9vbHMuaWV0Zi5vcmc7IHJhZGl1c2V4dEBvcHMu
aWV0Zi5vcmc7IGZpbmUgc3o7IFFpdWppbjsgV2FuZ3NodXhpYW5nOyBkcmFmdC10YW4tdjZvcHMt
ZmFzdDYtYWFhQHRvb2xzLmlldGYub3JnOyByb2JlcnRhIG1hZ2xpb25lOyBqYWNuaXFAZ21haWwu
Y29tOyBCZXJuYXJkIEFib2JhDQpTdWJqZWN0OiBSZTog562U5aSNOiBRIG9uIFZlci4tMDUgb2Yg
ZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3MgYWZ0ZXIgSUVURjgxIHJhZGV4dCBzZXNzaW9u
DQoNCk9uIFdlZCwgQXVnIDE3LCAyMDExIGF0IDQ6MDUgQU0sIFdvamNpZWNoIERlYyA8d2RlY0Bj
aXNjby5jb20+IHdyb3RlOg0KPg0KPiBPbiAxNy8wOC8yMDExIDA5OjEwLCAiTGVhZiB5ZWgiIDxs
ZWFmLnkueWVoQGh1YXdlaS5jb20+IHdyb3RlOg0KPg0KPj4gTXkgaXNzdWUgaXMgd2hlbiB3ZQ0K
Pj4gdHJ5IHRvIG1peCBpbiBhIGZpeGVkIHNldCBvZiBhZGRyZXNzIGFzc2lnbm1lbnQgbWV0aG9k
cyB3aXRoIHRoZSBwb29sDQo+PiBuYW1lcy4gwqBTZXBhcmF0aW9uIG9mIGNvbmNlcm5zLg0KPg0K
PiBUaGlzIGlzIGludGVyZXN0aW5nLCBnaXZlbiB0aGF0IHRoZSByb290IG9mIHRoaXMgdGhyZWFk
IGlzIHlvdXIgZW1haWwNCj4gcHJvcG9zYWwgZm9yIGp1c3QgdGhhdDoNCj4gaHR0cHM6Ly9vcHMu
aWV0Zi5vcmcvbGlzdHMvcmFkaXVzZXh0LzIwMTAvbXNnMDA5NTkuaHRtbA0KDQpBY3R1YWxseSwg
dGhlIHRleHQgeW91J3ZlIGF0dHJpYnV0ZWQgdG8gTGVhZiB3YXMgbXkgY29tbWVudC4NCg0KUmVn
YXJkcywNCg0KRGF2ZQ0KDQpEYXZpZCBCLiBOZWxzb24NClNyLiBTb2Z0d2FyZSBBcmNoaXRlY3QN
CkVsYnJ5cyBOZXR3b3JrcywgSW5jLg0Kd3d3LmVsYnJ5cy5jb20NCisxLjYwMy41NzAuMjYzNg0K

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2011 08:06:26 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=[e-mail]; l=892; q=dns/txt; s=iport; t=1313568351; x=1314777951; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=MPJqTINKYkEqByUVcdJ9DB++I44qIO6vpYZnLeG6LTQ=; b=RUmcWfh/WZc0vtifV4P2WdkwhVlGPkDY63r/1wLDsn0phiHdFiX3ASnP SxoIc0hxATwYNGfcYEogoOlqbq+2FYLxoxDUMfI42eMt+oIFCmY1HkgNX dTxIqHO41PKrp44lPiwgLIFo/h2wlUtzhWh5+HE9TIvcXhwib5mmKDgBz 4=;
User-Agent: Microsoft-Entourage/12.29.0.110113
Date: Wed, 17 Aug 2011 10:05:42 +0200
Subject: Re: =?Big5?B?tarOYA==?=: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: Wojciech Dec <[e-mail]>
To: Leaf yeh <[e-mail]>, Dave Nelson <[e-mail]>
CC: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, fine sz <[e-mail]>, Qiujin <[e-mail]>, Wangshuxiang <[e-mail]>, "[e-mail]" <[e-mail]>, roberta maglione <[e-mail]>, "[e-mail]" <[e-mail]>, Bernard Aboba <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: =?Big5?B?tarOYA==?=: 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+qL/9rzAo//ro/OA/8mB5lD/jIfrZf8ZYB+A/jK3ogD8Y/LsAPjGgdyg8Yy7vqg=
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

On 17/08/2011 09:10, "Leaf yeh" <[e-mail]> wrote:

>  My issue is when we
> try to mix in a fixed set of address assignment methods with the pool
> names.  Separation of concerns.

This is interesting, given that the root of this thread is your email
proposal for just that:
https://ops.ietf.org/lists/radiusext/2010/msg00959.html

Quote from the above:
" 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=A0Framed-Pool can replace Framed-IPv6-Pool to indicate the name of
a IPv6 prefix/address pool per the same logic"

draft-ietf-radext-ipv6-access-05 has no such issues does not mix pool namin=
g
with addressing method. It defines separate string attributes for each
addressing method, and allows arbitrary pool name(s) for each.

Thanks,
Woj.


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2011 07:12:27 +0000
Date: Wed, 17 Aug 2011 07:12:06 +0000
From: Leaf yeh <[e-mail]>
Subject: =?utf-8?B?UkU6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: Wojciech Dec <[e-mail]>, Dave Nelson <[e-mail]>
Cc: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, fine sz <[e-mail]>, Qiujin <[e-mail]>, Wangshuxiang <[e-mail]>, "[e-mail]" <[e-mail]>, roberta maglione <[e-mail]>, "[e-mail]" <[e-mail]>, Bernard Aboba <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: =?utf-8?B?562U5aSNOiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2?= =?utf-8?Q?6-access_after_IETF81_radext_session?=
Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsP///hb8P//4L6o///A+qL/9rzAo//ro/OA/8mB5lD/jIfrZf8ZYB+A/jK3ogD8Y/LsAPjH3x8A8Y5fYmA=

V29qIC0gPj4gU2hvdWxkIGFuIG9wZXJhdG9yIGNob29zZSB0byBzYXkgYXNzaWduIDIgcHJlZml4
ZXMgdG8gYSBzdWJzY3JpYmVyDQo+PiBmb3IgREhDUC1QRCwgYnV0IG9uZSBmb3IgU0xBQUMsIHRo
ZXkgd291bGQgbmVlZCB0bw0KPj4gZ2V0IGFuIElBTkEgY29kZSBwb2ludC4uLg0KPiANCkRhdmUg
LSA+IEkgZG9uJ3QgdGhpbmsgdGhhdCBzcGVjaWZpYyB2YWx1ZXMgZm9yICpjb21iaW5hdGlvbnMq
IG9mIG9wdGlvbnMgaXMgYQ0KPiBnb29kIHdheSB0byBnby4NCg0KV29qIC0gSXQncyByYXRoZXIg
Y2xlYXIgdGhhdCBhbiBlbnVtZXJhdGVkIGF0dHJpYnV0ZSBjYW5ub3QgaGFuZGxlIHRoaXMgY2Fz
ZS4NCg0KRm9yIHRoZSBhYm92ZSBjYXNlLCAnQWNjZXNzL0FkZHJlc3MtQXNzaWdubWVudC9Vc2Vy
LVR5cGUnIFtmb3IgQ3VzdG9tZXIgUm91dGVyIChOdW1iZXJlZCBieSBTTEFBQykgXSArIDMqJ0Zy
YW1lZC1Qb29sJygyIGZvciBESENQdjYtUEQgcG9vbCBuYW1lLCAxIGZvciBTTEFDQyBwb29sIG5h
bWUpIHdpbGwgYmUgYXV0aG9yaXplZCBieSBBQUEgc2VydmVyIGZvciB1c2Vycy4gUmlnaHQ/DQoN
CkJlc3QgUmVnYXJkcywNCkxlYWYNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv
bTogV29qY2llY2ggRGVjIFttYWlsdG86d2RlY0BjaXNjby5jb21dIA0KU2VudDogVHVlc2RheSwg
QXVndXN0IDE2LCAyMDExIDEwOjU4IFBNDQpUbzogRGF2ZSBOZWxzb24NCkNjOiBEYXZpZCBCLiBO
ZWxzb247IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRp
dXNleHRAb3BzLmlldGYub3JnOyBmaW5lIHN6OyBRaXVqaW47IFdhbmdzaHV4aWFuZzsgZHJhZnQt
dGFuLXY2b3BzLWZhc3Q2LWFhYUB0b29scy5pZXRmLm9yZzsgTGVhZiB5ZWg7IHJvYmVydGEgbWFn
bGlvbmU7IGphY25pcUBnbWFpbC5jb207IEJlcm5hcmQgQWJvYmENClN1YmplY3Q6IFJlOiDnrZTl
pI06IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2VzcyBhZnRlciBJ
RVRGODEgcmFkZXh0IHNlc3Npb24NCg0KDQoNCg0KT24gMTYvMDgvMjAxMSAxNjozMywgIkRhdmUg
TmVsc29uIiA8ZG5lbHNvbkBlbGJyeXMuY29tPiB3cm90ZToNCg0KDQo+IA0KPiBJIGhhdmUgbm8g
cHJvYmxlbSB3aXRoIHN0cmluZyBlbmNvZGluZ3Mgb2YgcG9vbCBuYW1lcy4gICBTaW5jZSBwb29s
cw0KPiBjYW4gYmUgbmFtZWQgYXJiaXRyYXJpbHkgYnkgdGhlIE5BUyBzeXN0ZW0gYWRtaW5pc3Ry
YXRvciwgYW55dGhpbmcNCj4gb3RoZXIgdGhhbiBhIHN0cmluZyBlbmNvZGluZyB3b3VsZCBiZSB1
bm5hdHVyYWwuICBNeSBpc3N1ZSBpcyB3aGVuIHdlDQo+IHRyeSB0byBtaXggaW4gYSBmaXhlZCBz
ZXQgb2YgYWRkcmVzcyBhc3NpZ25tZW50IG1ldGhvZHMgd2l0aCB0aGUgcG9vbA0KPiBuYW1lcy4g
IFNlcGFyYXRpb24gb2YgY29uY2VybnMuDQoNCldlbGwsIEkgdGhpbmsgd2UncmUgaW4gYWdyZWVt
ZW50IGFuZCB3aGVuIHlvdSBjb21lIHRvIHJlYWQgdGhlIFdHIHByb3Bvc2FsDQppbiBkcmFmdC1p
ZXRmLXJhZGV4dC1pcHY2IHlvdSB3aWxsIGZpbmQgaXQgTk9UIHRvIGhhdmUgdGhlIGFib3ZlIGlz
c3VlLg0KVGhlIG9yaWdpbiBvZiB0aGlzIGVtYWlsIHRocmVhZCwgaXQgc2VlbXMgYXBwcm9wcmlh
dGUgdG8gcmVjYWxsIGl0LCBpcyB0aGF0DQpzb21lIGZvbGtzIGNsYWltZWQgdGhhdCB0aGUgcHJv
cG9zYWwgaW4gdGhlIGRyYWZ0IGlzIG5vdCBuZWVkZWQgYW5kIHRoYXQNCnNvbHZpbmcgdGhlIGNh
c2UgYnkgb3ZlcmxvYWRpbmcgcG9vbCBuYW1pbmcgaXMgYmV0dGVyLCBmb2xsb3dlZCBvbiBieSBh
DQpzZWNvbmQgcHJvcG9zYWwgZm9yIHRoZSBlbnVtZXJhdGVkIHR5cGUuDQoNCj4gDQo+PiBTdXJl
LiBXZSBhcHBlYXIgdG8gYmUgdGFsa2luZyBhYm91dCBjb2RlLXBvaW50cyBmb3IgdmFsdWVzIHdp
dGhpbiBhIHNpbmdsZQ0KPj4gYXR0cmlidXRlLCBmaW5lIGV4YW1wbGVzLCAoIGZvciB3aGljaCBu
byBJQU5BIGNvZGUgcG9pbnRzIHdlcmUgYXNzaWduZWQpDQo+PiBpbmNsdWRlIHRoZSBleGlzdGlu
ZyBTZXJ2aWNlLVR5cGUgYW5kIEVycm9yLUNhdXNlIGF0dHJpYnV0ZXMuDQo+PiBJbiBlbnVtZXJh
dGluZyB0aGlzLCBieSBkZWZpbml0aW9uIHRoZXJlIGlzIGEgcmVzdHJpY3Rpb24gd2hpY2ggaXMg
bm90DQo+PiBjYWxsZWQgZm9yIGluIHRoaXMgc2l0dWF0aW9uLg0KPiANCj4gV2h5IG5vdD8NCg0K
RXhhbXBsZSBnaXZlbiBiZWxvdywgYW5kIGl0IGlzIG9uZSB0aGF0IGlzIHBlcmZlY3RseSBsZWdp
dGltYXRlLg0KDQo+IA0KPj4gU2hvdWxkIGFuIG9wZXJhdG9yIGNob29zZSB0byBzYXkgYXNzaWdu
IDIgcHJlZml4ZXMgdG8gYSBzdWJzY3JpYmVyDQo+PiBmb3IgREhDUC1QRCwgYnV0IG9uZSBmb3Ig
U0xBQUMsIHRoZXkgd291bGQgbmVlZCB0bw0KPj4gZ2V0IGFuIElBTkEgY29kZSBwb2ludC4uLg0K
PiANCj4gSSBkb24ndCB0aGluayB0aGF0IHNwZWNpZmljIHZhbHVlcyBmb3IgKmNvbWJpbmF0aW9u
cyogb2Ygb3B0aW9ucyBpcyBhDQo+IGdvb2Qgd2F5IHRvIGdvLg0KDQpJdCdzIHJhdGhlciBjbGVh
ciB0aGF0IGFuIGVudW1lcmF0ZWQgYXR0cmlidXRlIGNhbm5vdCBoYW5kbGUgdGhpcyBjYXNlLg0K
DQo+IA0KPj4gQmVmb3JlIGdvaW5nIGZ1cnRoZXIsIHBlcmhhcHMgeW91IGNvdWxkIGNvbnNpZGVy
L2NvbW1lbnQgb24gdGhlIGN1cnJlbnQNCj4+IHByb3Bvc2FsIGluOiBodHRwOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzcy0wNQ0KPiANCj4gSSdsbCBm
aW5kIHNvbWUgdGltZSB0byBkbyB0aGF0LCBzb29uLg0KDQpQbGVhc2UgZG8uIEkgdGhpbmsgd2Un
cmUgaW4gYWdyZWVtZW50IGhlcmUgYW5kIHRoZXJlIGlzIG5vIG5lZWQgb2YgY2hhbmdlcy4NCg0K
UmVnYXJkcywNCldvai4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBEYXZlDQo+IA0KPiBEYXZpZCBC
LiBOZWxzb24NCj4gU3IuIFNvZnR3YXJlIEFyY2hpdGVjdA0KPiBFbGJyeXMgTmV0d29ya3MsIElu
Yy4NCj4gd3d3LmVsYnJ5cy5jb20NCj4gKzEuNjAzLjU3MC4yNjM2DQoNCg==

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2011 07:11:16 +0000
Date: Wed, 17 Aug 2011 07:10:10 +0000
From: Leaf yeh <[e-mail]>
Subject: =?utf-8?B?UkU6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: Dave Nelson <[e-mail]>, Wojciech Dec <[e-mail]>
Cc: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, fine sz <[e-mail]>, Qiujin <[e-mail]>, Wangshuxiang <[e-mail]>, "[e-mail]" <[e-mail]>, roberta maglione <[e-mail]>, "[e-mail]" <[e-mail]>, Bernard Aboba <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: =?utf-8?B?562U5aSNOiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2?= =?utf-8?Q?6-access_after_IETF81_radext_session?=
Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsP///hb8P//4L6o///A+qL/9rzAo//ro/OA/8mB5lD/jIfrZf8ZYB+A/jK3ogD8Y/LsAPjGgdyg

RGF2ZSAtIElmIHRoZXJlIGFyZSBpbiBmYWN0IHR3byBpbmRlcGVuZGVudCB2YXJpYWJsZXMgYXQg
cGxheSAoYSkgYWRkcmVzcw0KYXNzaWdubWVudCBtZXRob2QgYW5kIChiKSBhZHJlc3MgcG9vbCBz
ZWxlY3Rpb24sIHRoZW4gaXQgc2VlbXMgdG8gbWUNCnRoYXQgd2UgbmVlZCBvbmUgYXR0cmlidXRl
IChvciBzZXQgb2YgYXR0cmlidXRlcykgdG8gbmFtZSB0aGUgcG9vbCBhbmQNCmEgc2Vjb25kIG9u
ZSB0byBuYW1lIHRoZSBhZGRyZXNzIGFzc2lnbm1lbnQgbWV0aG9kLg0KDQpEYXZlIC0gSSdtIHBy
b3Bvc2luZyB0aGF0IHRoZSAoYWQtaG9jKSBwcmVjZWRlbnQgaXMgYSBiYWQNCmRlc2lnbiBjaG9p
Y2UgYW5kIHRoYXQgaW4gc3RhbmRhcmRpemluZyB0aGlzIGZlYXR1cmUgd2UgcGVyaGFwcyBzaG91
bGQNCm1ha2UgYW5vdGhlciBjaG9pY2UuICBJIGFsd2F5cyBwcmVmZXIgYW4gZW51bWVyYXRlZCB0
eXBlIGVuY29kaW5nIG92ZXINCmEgc3RyaW5nIGVuY29kaW5nIHdoZW4gdGhlIHVuZGVybHlpbmcg
c2VtYW50aWNzIGFuZCBkYXRhIG1vZGVsIG9mIHRoZQ0Kb2JqZWN0IGlzIGEgc2V0IG9mIGRpc2Ny
ZWV0IGNob2ljZXMuDQoNCkRhdmUgLSBJIGhhdmUgbm8gcHJvYmxlbSB3aXRoIHN0cmluZyBlbmNv
ZGluZ3Mgb2YgcG9vbCBuYW1lcy4gICBTaW5jZSBwb29scw0KY2FuIGJlIG5hbWVkIGFyYml0cmFy
aWx5IGJ5IHRoZSBOQVMgc3lzdGVtIGFkbWluaXN0cmF0b3IsIGFueXRoaW5nDQpvdGhlciB0aGFu
IGEgc3RyaW5nIGVuY29kaW5nIHdvdWxkIGJlIHVubmF0dXJhbC4gIE15IGlzc3VlIGlzIHdoZW4g
d2UNCnRyeSB0byBtaXggaW4gYSBmaXhlZCBzZXQgb2YgYWRkcmVzcyBhc3NpZ25tZW50IG1ldGhv
ZHMgd2l0aCB0aGUgcG9vbA0KbmFtZXMuICBTZXBhcmF0aW9uIG9mIGNvbmNlcm5zLg0KDQpJIHRo
aW5rIHRoZSBhYm92ZSBleHBsYW5hdGlvbnMgYXJlIGdvb2QgZW5vdWdoIGZyb20gdGhlIHN0YW5k
IHBvaW50cyBvZiBteSB2aWV3Lg0KDQoNCkJlc3QgUmVnYXJkcywNCkxlYWYNCg0KDQotLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGF2ZSBOZWxzb24gW21haWx0bzpkbmVsc29uQGVs
YnJ5cy5jb21dIA0KU2VudDogVHVlc2RheSwgQXVndXN0IDE2LCAyMDExIDEwOjM0IFBNDQpUbzog
V29qY2llY2ggRGVjDQpDYzogRGF2aWQgQi4gTmVsc29uOyBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2
LWFjY2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZzsgZmluZSBzejsg
UWl1amluOyBXYW5nc2h1eGlhbmc7IGRyYWZ0LXRhbi12Nm9wcy1mYXN0Ni1hYWFAdG9vbHMuaWV0
Zi5vcmc7IExlYWYgeWVoOyByb2JlcnRhIG1hZ2xpb25lOyBqYWNuaXFAZ21haWwuY29tOyBCZXJu
YXJkIEFib2JhDQpTdWJqZWN0OiBSZTog562U5aSNOiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0
Zi1yYWRleHQtaXB2Ni1hY2Nlc3MgYWZ0ZXIgSUVURjgxIHJhZGV4dCBzZXNzaW9uDQoNCj4gSG93
IGRvZXMgdGhlIE5BUyBwaWNrICB0aGUgcmlnaHQgcG9vbCBiYXNlZCBvbiByZWNlaXZpbmcgYSBz
aW5nbGUNCj4gYXR0cmlidXRlIGNvbnRhaW5pbmcgYW4gZW51bWVyYXRlZCBjb2RlLXBvaW50IGZv
ciBGb28tYmFyPw0KDQpJZiB0aGVyZSBhcmUgaW4gZmFjdCB0d28gaW5kZXBlbmRlbnQgdmFyaWFi
bGVzIGF0IHBsYXkgKGEpIGFkZHJlc3MNCmFzc2lnbm1lbnQgbWV0aG9kIGFuZCAoYikgYWRyZXNz
IHBvb2wgc2VsZWN0aW9uLCB0aGVuIGl0IHNlZW1zIHRvIG1lDQp0aGF0IHdlIG5lZWQgb25lIGF0
dHJpYnV0ZSAob3Igc2V0IG9mIGF0dHJpYnV0ZXMpIHRvIG5hbWUgdGhlIHBvb2wgYW5kDQphIHNl
Y29uZCBvbmUgdG8gbmFtZSB0aGUgYWRkcmVzcyBhc3NpZ25tZW50IG1ldGhvZC4NCg0KPiBUaGUg
YWx0ZXJuYXRpdmUsIHdoaWNoIGlzIHdoYXQgSSBhbmQgb3RoZXJzIGFyZSBwcm9wb3NpbmcgaXMg
dG8gZm9sbG93DQo+IHByZWNlZGVudCBhbmQgdXNlIHNlcGFyYXRlIHN0cmluZyBhdHRyaWJ1dGVz
IGZvciB0aGVpciByb2xlIC0gKmFzIHByb3Bvc2VkKg0KPiBpbiB0aGUgY3VycmVudCBpcHY2LWFj
Y2VzcyBkcmFmdC4NCg0KSSB1bmRlcnN0YW5kLiBJJ20gcHJvcG9zaW5nIHRoYXQgdGhlIChhZC1o
b2MpIHByZWNlZGVudCBpcyBhIGJhZA0KZGVzaWduIGNob2ljZSBhbmQgdGhhdCBpbiBzdGFuZGFy
ZGl6aW5nIHRoaXMgZmVhdHVyZSB3ZSBwZXJoYXBzIHNob3VsZA0KbWFrZSBhbm90aGVyIGNob2lj
ZS4gIEkgYWx3YXlzIHByZWZlciBhbiBlbnVtZXJhdGVkIHR5cGUgZW5jb2Rpbmcgb3Zlcg0KYSBz
dHJpbmcgZW5jb2Rpbmcgd2hlbiB0aGUgdW5kZXJseWluZyBzZW1hbnRpY3MgYW5kIGRhdGEgbW9k
ZWwgb2YgdGhlDQpvYmplY3QgaXMgYSBzZXQgb2YgZGlzY3JlZXQgY2hvaWNlcy4NCg0KPiBQcmVj
ZWRlbnQgPSByZmMzMTYyLCByZmM0ODE4LCBhbmQgZWFybGllciBub24gSVB2NiBvbmVzLCBlYWNo
IGRlZmluZSBuYW1lZA0KPiBwb29scyBmb3IgYSBzcGVjaWZpYyBwdXJwb3NlLg0KDQpJIGhhdmUg
bm8gcHJvYmxlbSB3aXRoIHN0cmluZyBlbmNvZGluZ3Mgb2YgcG9vbCBuYW1lcy4gICBTaW5jZSBw
b29scw0KY2FuIGJlIG5hbWVkIGFyYml0cmFyaWx5IGJ5IHRoZSBOQVMgc3lzdGVtIGFkbWluaXN0
cmF0b3IsIGFueXRoaW5nDQpvdGhlciB0aGFuIGEgc3RyaW5nIGVuY29kaW5nIHdvdWxkIGJlIHVu
bmF0dXJhbC4gIE15IGlzc3VlIGlzIHdoZW4gd2UNCnRyeSB0byBtaXggaW4gYSBmaXhlZCBzZXQg
b2YgYWRkcmVzcyBhc3NpZ25tZW50IG1ldGhvZHMgd2l0aCB0aGUgcG9vbA0KbmFtZXMuICBTZXBh
cmF0aW9uIG9mIGNvbmNlcm5zLg0KDQo+IFN1cmUuIFdlIGFwcGVhciB0byBiZSB0YWxraW5nIGFi
b3V0IGNvZGUtcG9pbnRzIGZvciB2YWx1ZXMgd2l0aGluIGEgc2luZ2xlDQo+IGF0dHJpYnV0ZSwg
ZmluZSBleGFtcGxlcywgKCBmb3Igd2hpY2ggbm8gSUFOQSBjb2RlIHBvaW50cyB3ZXJlIGFzc2ln
bmVkKQ0KPiBpbmNsdWRlIHRoZSBleGlzdGluZyBTZXJ2aWNlLVR5cGUgYW5kIEVycm9yLUNhdXNl
IGF0dHJpYnV0ZXMuDQo+IEluIGVudW1lcmF0aW5nIHRoaXMsIGJ5IGRlZmluaXRpb24gdGhlcmUg
aXMgYSByZXN0cmljdGlvbiB3aGljaCBpcyBub3QNCj4gY2FsbGVkIGZvciBpbiB0aGlzIHNpdHVh
dGlvbi4NCg0KV2h5IG5vdD8NCg0KPiBTaG91bGQgYW4gb3BlcmF0b3IgY2hvb3NlIHRvIHNheSBh
c3NpZ24gMiBwcmVmaXhlcyB0byBhIHN1YnNjcmliZXINCj4gZm9yIERIQ1AtUEQsIGJ1dCBvbmUg
Zm9yIFNMQUFDLCB0aGV5IHdvdWxkIG5lZWQgdG8NCj4gZ2V0IGFuIElBTkEgY29kZSBwb2ludC4u
Lg0KDQpJIGRvbid0IHRoaW5rIHRoYXQgc3BlY2lmaWMgdmFsdWVzIGZvciAqY29tYmluYXRpb25z
KiBvZiBvcHRpb25zIGlzIGENCmdvb2Qgd2F5IHRvIGdvLg0KDQo+IEJlZm9yZSBnb2luZyBmdXJ0
aGVyLCBwZXJoYXBzIHlvdSBjb3VsZCBjb25zaWRlci9jb21tZW50IG9uIHRoZSBjdXJyZW50DQo+
IHByb3Bvc2FsIGluOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJhZGV4
dC1pcHY2LWFjY2Vzcy0wNQ0KDQpJJ2xsIGZpbmQgc29tZSB0aW1lIHRvIGRvIHRoYXQsIHNvb24u
DQoNClJlZ2FyZHMsDQoNCkRhdmUNCg0KRGF2aWQgQi4gTmVsc29uDQpTci4gU29mdHdhcmUgQXJj
aGl0ZWN0DQpFbGJyeXMgTmV0d29ya3MsIEluYy4NCnd3dy5lbGJyeXMuY29tDQorMS42MDMuNTcw
LjI2MzYNCg==

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 17 Aug 2011 07:10:57 +0000
Date: Wed, 17 Aug 2011 07:09:36 +0000
From: Leaf yeh <[e-mail]>
Subject: =?utf-8?B?UkU6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: Dave Nelson <[e-mail]>
Cc: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: =?utf-8?B?562U5aSNOiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2?= =?utf-8?Q?6-access_after_IETF81_radext_session?=
Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsP///hb8P//4L6o///A+qL/9rzAo//ro/OA/8mB5lD/jRU1gP8YXBBA/jD2goD8YFS38A==

VGhlIG9yaWdpbmFsIGRlc2lnbiBvZiAnVXNlci1UeXBlJyBkZWZpbmVkIGluIHRoZSBzZWN0aW9u
IDQuMSBvZiBkcmFmdC15ZWgtcmFkZXh0LWR1YWwtc3RhY2stYWNjZXNzLTAyIGluY2x1ZGVzIHRo
ZSBkaWZmZXJlbnRpYXRpb24gYmV0d2VlbiBQUFBvRSAmIElQb0UgdGhyb3VnaCBkaWZmZXJlbnQg
YXR0cmlidXRlLWNvZGUtdmFsdWUuIFRob3VnaCAnQWRkcmVzcy1Bc3NpZ25tZW50LVR5cGUnIHNv
dW5kcyBub3QgaGF2ZSB0aGlzIGRpZmZlcmVudGlhdGlvbiwgaXQgaXMgc3RpbGwgZmluZSB0byBt
ZS4gSXQgZG9lcyBjYXRlZ29yaXplIHRoZSB1c2VycyBieSB0aGUgcHJlZml4L2FkZHJlc3MgYXNz
aWdubWVudCwgd2hpY2ggaXMgdGhlIG1vc3QgaW1wb3J0YW50IHBhcnQgb2YgdGhlIGF1dGhvcml6
YXRpb24uIENvdWxkIHdlIGhhdmUgYSBiZXR0ZXIgY2hvaWNlPyBPciAnQWNjZXNzLUFkZHJlc3Mt
QXNzaWdubWVudC1UeXBlJz8NCg0KDQpCZXN0IFJlZ2FyZHMsDQpMZWFmDQoNCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERhdmUgTmVsc29uIFttYWlsdG86ZG5lbHNvbkBlbGJy
eXMuY29tXSANClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAxNiwgMjAxMSA3OjM1IFBNDQpUbzogTGVh
ZiB5ZWgNCkNjOiBEYXZpZCBCLiBOZWxzb247IHJhZGl1c2V4dEBvcHMuaWV0Zi5vcmc7IGRyYWZ0
LXRhbi12Nm9wcy1mYXN0Ni1hYWFAdG9vbHMuaWV0Zi5vcmc7IEJlcm5hcmQgQWJvYmENClN1Ympl
Y3Q6IFJlOiDnrZTlpI06IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFj
Y2VzcyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb24NCg0KPiBIb3cgYWJvdXQgdGhlIHJlcGxh
Y2VtZW50IG9mICdOb2RlLXR5cGUnIG9yICdBY2Nlc3MtdHlwZSc/IMKgb3IgYW55IG90aGVyIHN1
Z2dlc3Rpb24/DQoNCklmIHRoZSBpbnRlbnQgb2YgdGhpcyBhdHRyaWJ1dGUgaXMgc29sZWx5IHRv
IGNvbnRyb2wgdmFyaW91cyB0eXBlcyBvZg0KSVAgYWRkcmVzcyBhbmQvb3IgcHJlZml4IGFzc2ln
bm1lbnQgbWV0aG9kcyBmcm9tIGEgbnVtYmVyIG9mDQpwcmUtY29uZmlndXJlZCBwb29scyB3aXRo
aW4gdGhlIE5BUywgdGhlbiBJJ2Qgc3VnZ2VzdCBzb21ldGhpbmcgbW9yZQ0Kc3BlY2lmaWMuICBQ
ZXJoYXBzICdBZGRyZXNzLUFzc2lnbm1lbnQtVHlwZScuICBJIHdvdWxkbid0IHdvcnJ5IGFib3V0
DQprZWVwaW5nIGl0IHZlcnkgc2hvcnQsIGFuZCBJIHdvdWxkbid0IG5hbWUgaXQgb3Zlcmx5IGJy
b2FkbHksIGxlc3QNCmZ1dHVyZSBkZXZlbG9wZXJzIGJlIHRlbXB0ZWQgdG8gY29uZmxhdGUgb3Ro
ZXIgTkFTIHByb3BlcnRpZXMgaW50byB0aGUNCnNhbWUgYXR0cmlidXRlLg0KDQpSZWdhcmRzLA0K
DQpEYXZlDQoNCkRhdmlkIEIuIE5lbHNvbg0KU3IuIFNvZnR3YXJlIEFyY2hpdGVjdA0KRWxicnlz
IE5ldHdvcmtzLCBJbmMuDQp3d3cuZWxicnlzLmNvbQ0KKzEuNjAzLjU3MC4yNjM2DQo=

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 16 Aug 2011 15:43:04 +0000
Date: Tue, 16 Aug 2011 15:42:08 +0000
From: Leaf yeh <[e-mail]>
Subject: =?utf-8?B?UkU6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: Wojciech Dec <[e-mail]>, "David B. Nelson" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, fine sz <[e-mail]>, Qiujin <[e-mail]>, Wangshuxiang <[e-mail]>, "[e-mail]" <[e-mail]>, Bernard Aboba <[e-mail]>
Message-id: <E6CA1FED-0FC6-4142-B7B7-A4801B68DFF6@mimectl>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_uCjQEmRTm/NCae5CCZJxmg)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: =?utf-8?B?562U5aSNOiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2?= =?utf-8?Q?6-access_after_IETF81_radext_session?=
Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsP///hb8P//4L6o///A+qL/9rzAo//ro/OA/8mB5lD/jIfrZf8ZYB+A/jK3ogD8ZCVCEPjHfvZQ

--Boundary_(ID_uCjQEmRTm/NCae5CCZJxmg)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: base64

V29qY2llY2ggLSBPay4gU28gaGVscCBtZSBvdXQgaGVyZTogQW4gb3BlcmF0b3IgaGFzIHR3byBw
b29scywgQSBmb3IgYnVzaW5lc3MNCmN1c3RvbWVycywgQiBmb3IgcmVzaWRlbnRpYWwuIEluIGJv
dGggY2FzZXMgdGhlIG9wZXJhdG9yIGV4cGVjdHMgRm9vLWJhcg0KYWRkcmVzc2luZyBtZXRob2Qg
dG8gYmUgdXNlZCBhbmQgY3VzdG9tZXJzIGluIEEgb3IgQi4gSG93IGRvZXMgdGhlIE5BUyBwaWNr
DQp0aGUgcmlnaHQgcG9vbCBiYXNlZCBvbiByZWNlaXZpbmcgYSBzaW5nbGUgYXR0cmlidXRlIGNv
bnRhaW5pbmcgYW4NCmVudW1lcmF0ZWQgY29kZS1wb2ludCBmb3IgRm9vLWJhcj8NCg0KVGhlIGRl
ZmF1bHQgYmVoYXZpb3IgY29uZmlndXJlZCBvbiB0aGUgTkFTIHdpbGwgcGljayB0aGUgcmlnaHQg
YWRkcmVzcy9wcmVmaXggcG9vbHMgcGVyIHRoZSAnVXNlci1UeXBlJyAob3IgTm9kZS9BY2Nlc3Mt
VHlwZSksIGlmIGl0IGhhcyBub3QgcmVjZWl2ZWQgdGhlIGF0dHJpYnV0ZXMgb2YgcG9vbC1uYW1l
IGF0dHJpYnV0ZXMgKEZyYW1lZC1Qb29sLCBGcmFtZWQtSVB2Ni1Qb29sLCBvciBEZWxlZ2F0ZWQt
SVB2Ni1QcmVmaXgtUG9vbCwgU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgKSBmcm9tIEFBQSBz
ZXJ2ZXIuDQoNClRoZSAybmQgdXNlIGNhc2Ugb2YgJ1VzZXIvTm9kZS9BY2Nlc3MtVHlwZScgaXMg
dGhhdCB0aGUgYXR0cmlidXRlcyBjb21iaW5hdGlvbiBvZiAnVXNlci9Ob2RlL0FjY2Vzcy1UeXBl
JyArIHNpbmdsZSAob3IgbXVsdGlwbGUpIGF0dHJpYnV0ZXMgb2YgJ0ZyYW1lZC1Qb29sJyBbIG9y
IEZyYW1lZC1JUHY2LVBvb2wnIChpZiB3ZSdkIGxpa2UgdG8ga2VlcCB0aGlzIGF0dHJpYnV0ZSkg
b3IgJ0RlbGVnYXRlZC1JUHY2LVByZWZpeC1Qb29sJyAoaWYgd2UgaW5zaXN0IG9uIHVzaW5nIHRo
aXMgYXR0cmlidXRlKSBvciAnU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wnIChpZiB3ZSBpbnNp
c3Qgb24gdXNpbmcgdGhpcyBhdHRyaWJ1dGUpIF0gY2FuIGJlIHVzZWQgdG8gaW5kaWNhdGUgdGhl
IHJpZ2h0IGFkZHJlc3MvcHJlZml4IHBvb2xzIGZvciB0aGF0IHNwZWNpZmllZCB1c2VyIGFmdGVy
IGF1dGhlbnRpY2F0aW9uLg0KDQpJbiB0aGUgY2FzZSBkZWZpbmVkIGFib3ZlLCB0aGUgYXR0cmli
dXRlcyBhdXRob3JpemVkIGJ5IEFBQSBzZXJ2ZXIgY2FuIGJlICdVc2VyL05vZGUvQWNjZXNzLVR5
cGUnICsgJ0ZyYW1lZC1Qb29sJyBjb250YWluaW5nIEEgb3IgJ1VzZXIvTm9kZS9BY2Nlc3MtVHlw
ZSAnICsgJ0ZyYW1lZC1Qb29sJyBjb250YWluaW5nIEIuIEJ1dCBpZiB0aGUgcG9vbCBCIGlzIGlu
IHRoZSBkZWZhdWx0IGNvbmZpZ3VyYXRpb24gb2YgTkFTLCB0aGUgYXR0cmlidXRlIGF1dGhvcml6
ZWQgYnkgQUFBIHNlcnZlciBjYW4gb25seSBpbmNsdWRlICdVc2VyL05vZGUvQWNjZXNzLVR5cGUn
Lg0KDQpJbiBhbnkgY2FzZSwgdGhlIEFBQSBzZXJ2ZXIgbmVlZCBkZWZpbml0ZWx5IHVuZGVyc3Rh
bmQgdGhlIG5hbWUgJiB0eXBlICYgcHVycG9zZSBvZiB0aGUgdmFyaW91cyB0eXBlIG9mIHBvb2xz
IGNvbmRpZnVyZWQgb24gdGhlIE5BUyBiZWZvcmUgdGhlIGF1dGhvcml6YXRpb24gZm9yIHRoZSB1
c2Vycy4gTkFTIG5lZWQgZGVmaW5pdGVseSBpbnRlcnByZXQgdGhvc2UgbmFtZSBzdHJpbmdzIGNv
bnRhaW5pbmcgaW4gdGhlIHBvb2wtbmFtZSBhdHRyaWJ1dGVzIChGcmFtZWQtUG9vbCBvciBldGMp
IHJlY2VpdmVkIGZyb20gdGhlIEFBQSBzZXJ2ZXIuDQoNClRoYXQgbWlnaHQgbWVhbnMgd2UgZG9u
J3QgcmVhbGx5IG5lZWQgdG8gaW5kaWNhdGUgdGhlIGNhdGVnb3J5IChvciB0eXBlKSBvZiB0aGUg
cG9vbCBuYW1lcy4NCg0KDQpXb2pjaWVjaCAtIFByZWNlZGVudCA9IHJmYzMxNjIsIHJmYzQ4MTgs
IGFuZCBlYXJsaWVyIG5vbiBJUHY2IG9uZXMsIGVhY2ggZGVmaW5lIG5hbWVkIHBvb2xzIGZvciBh
IHNwZWNpZmljIHB1cnBvc2UuDQoNClJGQzQ4MTggaGFzIG5vdCBkZWZpbmVkIGFueSBjb25jZXB0
IGZvciBwb29scy4NCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvcmZjNDgxOC8/aW5j
bHVkZV90ZXh0PTENCmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvcmFkaXVzLXR5cGVz
L3JhZGl1cy10eXBlcy54bWwNCg0KDQpCZXN0IFJlZ2FyZHMsDQoNCkxlYWYNCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdvamNpZWNoIERlYyBbbWFpbHRvOndkZWNAY2lzY28u
Y29tXQ0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTUsIDIwMTEgMTE6NTMgUE0NClRvOiBEYXZpZCBC
LiBOZWxzb24NCkNjOiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9y
ZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZzsgZmluZSBzejsgUWl1amluOyBXYW5nc2h1eGlhbmc7
IGRyYWZ0LXRhbi12Nm9wcy1mYXN0Ni1hYWFAdG9vbHMuaWV0Zi5vcmc7IExlYWYgeWVoOyByb2Jl
cnRhIG1hZ2xpb25lOyBqYWNuaXFAZ21haWwuY29tOyBCZXJuYXJkIEFib2JhDQpTdWJqZWN0OiBS
ZTog562U5aSNOiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3Mg
YWZ0ZXIgSUVURjgxIHJhZGV4dCBzZXNzaW9uDQoNCg0KDQoNCk9uIDE1LzA4LzIwMTEgMTc6MjEs
ICJEYXZpZCBCLiBOZWxzb24iIDxkLmIubmVsc29uQGNvbWNhc3QubmV0PiB3cm90ZToNCg0KPj4g
Li4uIGl0IGxvb2tzIHZlcnkgbXVjaCBhcyByZWx5aW5nIG9uIHRoZSBzcGVjaWFsIE5BUyBmZWF0
dXJlDQo+PiB0byBpbnRlcnByZXQgKnRoZSBjb250ZW50cyogb2YgdGhlIGF0dHJpYnV0ZSBhcyB0
byB0aGUgcG9vbHMuLi4NCj4NCj4gU3BlY2lhbCBOQVMgZmVhdHVyZT8gIFdoeSBpcyB0aGUgaW50
ZXJwcmV0YXRpb24gb2YgdGhpcyBwcm9wb3NlZCBSQURJVVMNCj4gYXR0cmlidXRlIGFueSBtb3Jl
IHNwZWNpYWwgdGhhbiBOQVMgYmVoYXZpb3IgdGhhdCBpbnRlcnByZXRzIGFueSBvdGhlcg0KPiBh
dHRyaWJ1dGU/ICBJdCdzIGFsbW9zdCBhbHdheXMgdGhlICpjb250ZW50cyogb2YgYXR0cmlidXRl
cyB0aGF0IGlzDQo+IGludGVycHJldGVkIGJ5IHRoZSBOQVMsDQoNCk9rLiBTbyBoZWxwIG1lIG91
dCBoZXJlOiBBbiBvcGVyYXRvciBoYXMgdHdvIHBvb2xzLCBBIGZvciBidXNpbmVzcw0KY3VzdG9t
ZXJzLCBCIGZvciByZXNpZGVudGlhbC4gSW4gYm90aCBjYXNlcyB0aGUgb3BlcmF0b3IgZXhwZWN0
cyBGb28tYmFyDQphZGRyZXNzaW5nIG1ldGhvZCB0byBiZSB1c2VkIGFuZCBjdXN0b21lcnMgaW4g
QSBvciBCLiBIb3cgZG9lcyB0aGUgTkFTIHBpY2sNCnRoZSByaWdodCBwb29sIGJhc2VkIG9uIHJl
Y2VpdmluZyBhIHNpbmdsZSBhdHRyaWJ1dGUgY29udGFpbmluZyBhbg0KZW51bWVyYXRlZCBjb2Rl
LXBvaW50IGZvciBGb28tYmFyPw0KDQoNCj4NCj4+IC4uLnRvIGJlIHVzZWQsIG9ubHkgdGhpcyB0
aW1lIHdpdGggdGhlIGNvbnRlbnRzIGJlaW5nIGxhaWQgZG93biBhcw0KPj4gdGhlIGVudW1lcmF0
ZWQgdHlwZSBjb2RlIHBvaW50cyBpbiBhIGRyYWZ0Lg0KPg0KPiBJIHRoaW5rIGFuIGVudW1lcmF0
ZWQgdHlwZSBpcyBwcmVmZXJhYmxlIHRvIHBhcnNpbmcgc3RyaW5ncyB3aGVuIHRoZSBzZW1hbnRp
Y3MNCj4gb2YgdGhlIGF0dHJpYnVlcyBpcyB0byBhcHBseSBvbmUgb2YgYSBsaW1pdGVkIG51bWJl
ciBvZiBkaXNjcmVldCBjaG9pY2VzLg0KDQpUaGUgYWx0ZXJuYXRpdmUsIHdoaWNoIGlzIHdoYXQg
SSBhbmQgb3RoZXJzIGFyZSBwcm9wb3NpbmcgaXMgdG8gZm9sbG93DQpwcmVjZWRlbnQgYW5kIHVz
ZSBzZXBhcmF0ZSBzdHJpbmcgYXR0cmlidXRlcyBmb3IgdGhlaXIgcm9sZSAtICphcyBwcm9wb3Nl
ZCoNCmluIHRoZSBjdXJyZW50IGlwdjYtYWNjZXNzIGRyYWZ0Lg0KPg0KPj4gVGhpcyBkb2VzIG5v
dCBoZWxwIGdpdmVuIGEpIHBhc3QgcHJlY2VkZW50IGluIHRlcm1zIG9mIFJhZGl1cw0KPj4gcG9v
bCBkZWZpbml0aW9ucyAodGhlcmUgYXJlIGFscmVhZHkgMiBwb29scywgYW5kIHRoZXkgYXJlIGJl
aW5nDQo+PiB1c2VkKSwgbm9yIGIpIGdpdmUgdGhlIG9wZXJhdG9yIGFuIGV4cGxpY2l0IGluZGlj
YXRpb24gcmVnYXJkaW5nDQo+PiB0aGUgdXNlIG9mIGEgcG9vbCwgcmF0aGVyIHRoYW4gaW1wbGlj
aXQuDQo+DQo+IEkgZG9uJ3QgdW5kZXJ0YW5kIGVpdGhlciBvZiB0aGVzZSBwb2ludHMuICBXaGF0
ICpSQURJVVMqIHByZWNlZGVudCBleGlzdHMsIGFuZA0KPiBieSB0aGF0IEkgbWVhbiBhIHByZWNl
ZGVudCBpbiBub3JtYXRpdmUgdGV4dD8gIElmIHlvdSdyZSByZWZlcnJpbmcgdG8gYWQtaG9jDQo+
IGltcGxlbWVudGF0aW9uIHByYWN0aWNlLCBpbiB0aGUgYWJzZW5jZSBvZiBhbnkgbm9ybWF0aXZl
IGd1aWRhbmNlLCBJIHN1Z2dlc3QNCj4gdGhhdCBpbiBzdGFuZGFyZGl6aW5nIGEgc29sdXRpb24g
dG8gdGhhdCBzb3J0IG9mIGdhcCBpbiB0aGUgcHJvdG9jb2wsIG9uZQ0KPiB3b3VsZCBub3QgYmUg
dW5kdWx5IGluZmx1ZW5jZWQgYnkgdGhlIGZhY3QgdGhhdCB2YXJpb3VzIGFkLWhvYyBzb2x1dGlv
bnMgaGFkDQo+IGJlZW4gaW1wbGVtZW50ZWQuICBUaGF0IHdvdWxkIGRlZmVhdCB0aGUgcHVycG9z
ZSBvZiBzdGFuZGFyZGl6aW5nIGJlaGF2aW9yLg0KDQpQcmVjZWRlbnQgPSByZmMzMTYyLCByZmM0
ODE4LCBhbmQgZWFybGllciBub24gSVB2NiBvbmVzLCBlYWNoIGRlZmluZSBuYW1lZA0KcG9vbHMg
Zm9yIGEgc3BlY2lmaWMgcHVycG9zZS4NCg0KDQo+DQo+PiBCZXNpZGVzIHRoZSBhYm92ZSwgYXMg
d2l0aCBhbnkgZW51bWVyYXRlZCB0eXBlLCBpc3N1ZXMgd2lsbCBzdGFydA0KPj4gc2hvdWxkIHRo
ZXJlIGJlIGFub3RoZXIgY29tYmluYXRpb24gdGhhdCBzb21lb25lIGNvbWVzIHVwIHdpdGggb3IN
Cj4+IHdhbnRzLi4uDQo+DQo+IFRoZSBJQU5BIGNvZGUgcG9pbnQgYWxsb2NhdGlvbiBwcm9jZWR1
cmVzIHNob3VsZCBiZSBzdWZmaWNpZW50bHkgb3BlbiB0bw0KPiBwZXJtaXQgYWRkaW5nIGFkZGl0
aW9uYWwgImZsYXZvcnMiIHdpdGhvdXQgaW52b2tpbmcgSUVURiBjb25zZW5zdXMgb3IgV0cNCj4g
YXBwcm92YWxzLg0KDQpTdXJlLiBXZSBhcHBlYXIgdG8gYmUgdGFsa2luZyBhYm91dCBjb2RlLXBv
aW50cyBmb3IgdmFsdWVzIHdpdGhpbiBhIHNpbmdsZQ0KYXR0cmlidXRlLCBmaW5lIGV4YW1wbGVz
LCAoIGZvciB3aGljaCBubyBJQU5BIGNvZGUgcG9pbnRzIHdlcmUgYXNzaWduZWQpDQppbmNsdWRl
IHRoZSBleGlzdGluZyBTZXJ2aWNlLVR5cGUgYW5kIEVycm9yLUNhdXNlIGF0dHJpYnV0ZXMuDQpJ
biBlbnVtZXJhdGluZyB0aGlzLCBieSBkZWZpbml0aW9uIHRoZXJlIGlzIGEgcmVzdHJpY3Rpb24g
d2hpY2ggaXMgbm90DQpjYWxsZWQgZm9yIGluIHRoaXMgc2l0dWF0aW9uLiBTaG91bGQgYW4gb3Bl
cmF0b3IgY2hvb3NlIHRvIHNheSBhc3NpZ24gMg0KcHJlZml4ZXMgdG8gYSBzdWJzY3JpYmVyIGZv
ciBESENQLVBELCBidXQgb25lIGZvciBTTEFBQywgdGhleSB3b3VsZCBuZWVkIHRvDQpnZXQgYW4g
SUFOQSBjb2RlIHBvaW50Li4uIEFuZCB0aGVuIGhhdmUgdGhlIHZlbmRvcihzKSBzdXBwb3J0IHRo
YXQsIGV0Yy4NCk5ldmVyIG1pbmQgb3BlbiBJQU5BIGNvZGUgcG9pbnQgYWxsb2NhdGlvbiBwcm9j
ZWR1cmVzIC0gdGhpcyBsb29rcyB0byBiZQ0KcHJhY3RpY2FsbHkgdW53aXNlLg0KDQo+DQo+PiBG
cmFua2x5LCBvdGhlciB0aGFuIGl0IGJlaW5nIGFub3RoZXIgd2F5IG9mIGRvaW5nIHRoaW5ncywg
SSBwZXJzb25hbGx5DQo+PiBkb27CuXQgc2VlIG11Y2ggb2YgYSBiZW5lZml0Lg0KPg0KPiBJZiB5
b3UgYXJlIGludmVzdGVkIGluIGFuIGV4aXN0aW5nIGltcGxlbWVudGF0aW9uIHVzaW5nIGFub3Ro
ZXIgYXBwcm9hY2ggSSBjYW4NCj4gdW5kZXJzdGFuZCB0aGF0LCBidXQgYSBjbGVhcmx5IGRlZmlu
ZWQsIGVudW1lcmF0ZWQgdmFsdWUgYXR0cmlidXRlIHNlZW1zIG1vcmUNCj4gYXR0cmFjdGl2ZSB0
byBtZS4NCg0KQmVmb3JlIGdvaW5nIGZ1cnRoZXIsIHBlcmhhcHMgeW91IGNvdWxkIGNvbnNpZGVy
L2NvbW1lbnQgb24gdGhlIGN1cnJlbnQNCnByb3Bvc2FsIGluOiBodHRwOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzcy0wNQ0KDQpUaGFua3MsDQpXb2pj
aWVjaC4NCj4NCj4gLS0gRGF2ZQ0KDQoNCg==

--Boundary_(ID_uCjQEmRTm/NCae5CCZJxmg)
Content-id: <[e-mail]>
Content-type: text/html; charset=utf-8
Content-transfer-encoding: base64

PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi
IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgaWQ9Im93YVBhcmFT
dHlsZSI+UCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NCjwvc3R5
bGU+DQo8L2hlYWQ+DQo8Ym9keSBvY3NpPSIwIiBmUFN0eWxlPSIxIj4NCjxkaXYgc3R5bGU9IkZP
TlQtRkFNSUxZOiBUYWhvbWE7IERJUkVDVElPTjogbHRyOyBDT0xPUjogIzAwMDAwMDsgRk9OVC1T
SVpFOiAxMHB0Ij4NCjxwcmUgc3R5bGU9IldPUkQtV1JBUDogYnJlYWstd29yZCI+V29qY2llY2gg
LSBPay4gU28gaGVscCBtZSBvdXQgaGVyZTogQW4gb3BlcmF0b3IgaGFzIHR3byBwb29scywgQSBm
b3IgYnVzaW5lc3MNCmN1c3RvbWVycywgQiBmb3IgcmVzaWRlbnRpYWwuIEluIGJvdGggY2FzZXMg
dGhlIG9wZXJhdG9yIGV4cGVjdHMgRm9vLWJhcg0KYWRkcmVzc2luZyBtZXRob2QgdG8gYmUgdXNl
ZCBhbmQgY3VzdG9tZXJzIGluIEEgb3IgQi4gSG93IGRvZXMgdGhlIE5BUyBwaWNrDQp0aGUgcmln
aHQgcG9vbCBiYXNlZCBvbiByZWNlaXZpbmcgYSBzaW5nbGUgYXR0cmlidXRlIGNvbnRhaW5pbmcg
YW4NCmVudW1lcmF0ZWQgY29kZS1wb2ludCBmb3IgRm9vLWJhcj8NCg0KVGhlIGRlZmF1bHQgYmVo
YXZpb3IgY29uZmlndXJlZCBvbiB0aGUgTkFTIHdpbGwgcGljayB0aGUgcmlnaHQgYWRkcmVzcy9w
cmVmaXggcG9vbHMgcGVyIHRoZSAnVXNlci1UeXBlJyAob3IgTm9kZS9BY2Nlc3MtVHlwZSksIGlm
IGl0IGhhcyBub3QgcmVjZWl2ZWQgdGhlIGF0dHJpYnV0ZXMgb2YgcG9vbC1uYW1lIGF0dHJpYnV0
ZXMgKEZyYW1lZC1Qb29sLCBGcmFtZWQtSVB2Ni1Qb29sLCBvciBEZWxlZ2F0ZWQtSVB2Ni1QcmVm
aXgtUG9vbCwgU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgKSBmcm9tIEFBQSBzZXJ2ZXIuDQoN
ClRoZSAybmQgdXNlIGNhc2Ugb2YgJ1VzZXIvTm9kZS9BY2Nlc3MtVHlwZScgaXMgdGhhdCB0aGUg
YXR0cmlidXRlcyBjb21iaW5hdGlvbiBvZiAnVXNlci9Ob2RlL0FjY2Vzcy1UeXBlJyAmIzQzOyBz
aW5nbGUgKG9yIG11bHRpcGxlKSBhdHRyaWJ1dGVzIG9mICdGcmFtZWQtUG9vbCcgWyBvciBGcmFt
ZWQtSVB2Ni1Qb29sJyAoaWYgd2UnZCBsaWtlIHRvIGtlZXAgdGhpcyBhdHRyaWJ1dGUpIG9yICdE
ZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCcgKGlmIHdlIGluc2lzdCBvbiB1c2luZyB0aGlzIGF0
dHJpYnV0ZSkgb3IgJ1N0YXRlZnVsLUlQdjYtQWRkcmVzcy1Qb29sJyAoaWYgd2UgaW5zaXN0IG9u
IHVzaW5nIHRoaXMgYXR0cmlidXRlKSBdIGNhbiBiZSB1c2VkIHRvIGluZGljYXRlIHRoZSByaWdo
dCBhZGRyZXNzL3ByZWZpeCBwb29scyBmb3IgdGhhdCBzcGVjaWZpZWQgdXNlciBhZnRlciBhdXRo
ZW50aWNhdGlvbi4NCg0KSW4gdGhlIGNhc2UgZGVmaW5lZCBhYm92ZSwgdGhlIGF0dHJpYnV0ZXMg
YXV0aG9yaXplZCBieSBBQUEgc2VydmVyIGNhbiBiZSAnVXNlci9Ob2RlL0FjY2Vzcy1UeXBlJyAm
IzQzOyAnRnJhbWVkLVBvb2wnIGNvbnRhaW5pbmcgQSBvciAnVXNlci9Ob2RlL0FjY2Vzcy1UeXBl
ICcgJiM0MzsgJ0ZyYW1lZC1Qb29sJyBjb250YWluaW5nIEIuIEJ1dCBpZiB0aGUgcG9vbCBCIGlz
IGluIHRoZSBkZWZhdWx0IGNvbmZpZ3VyYXRpb24gb2YgTkFTLCB0aGUgYXR0cmlidXRlIGF1dGhv
cml6ZWQgYnkgQUFBIHNlcnZlciBjYW4gb25seSBpbmNsdWRlICdVc2VyL05vZGUvQWNjZXNzLVR5
cGUnLiANCg0KSW4gYW55IGNhc2UsIHRoZSBBQUEgc2VydmVyIG5lZWQgZGVmaW5pdGVseSB1bmRl
cnN0YW5kIHRoZSBuYW1lICZhbXA7IHR5cGUgJmFtcDsgcHVycG9zZSBvZiB0aGUgdmFyaW91cyB0
eXBlIG9mIHBvb2xzIGNvbmRpZnVyZWQgb24gdGhlIE5BUyBiZWZvcmUgdGhlIGF1dGhvcml6YXRp
b24gZm9yIHRoZSB1c2Vycy4gTkFTIG5lZWQgZGVmaW5pdGVseSBpbnRlcnByZXQgdGhvc2UgbmFt
ZSBzdHJpbmdzIGNvbnRhaW5pbmcgaW4gdGhlIHBvb2wtbmFtZSBhdHRyaWJ1dGVzIChGcmFtZWQt
UG9vbCBvciBldGMpIHJlY2VpdmVkIGZyb20gdGhlIEFBQSBzZXJ2ZXIuIDwvcHJlPg0KPHByZSBz
dHlsZT0iV09SRC1XUkFQOiBicmVhay13b3JkIj5UaGF0IG1pZ2h0IG1lYW5zIHdlIGRvbid0IHJl
YWxseSBuZWVkIHRvIGluZGljYXRlIHRoZSBjYXRlZ29yeSAob3IgdHlwZSkgb2YgdGhlIHBvb2wg
bmFtZXMuDQoNCg0KV29qY2llY2ggLSBQcmVjZWRlbnQgPSByZmMzMTYyLCByZmM0ODE4LCBhbmQg
ZWFybGllciBub24gSVB2NiBvbmVzLCBlYWNoIGRlZmluZSBuYW1lZCBwb29scyBmb3IgYSBzcGVj
aWZpYyBwdXJwb3NlLg0KDQpSRkM0ODE4IGhhcyBub3QgZGVmaW5lZCBhbnkgY29uY2VwdCBmb3Ig
cG9vbHMuDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzQ4MTgvP2luY2x1ZGVf
dGV4dD0xIA0KaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9yYWRpdXMtdHlwZXMvcmFk
aXVzLXR5cGVzLnhtbA0KPC9wcmU+DQo8cHJlIHN0eWxlPSJXT1JELVdSQVA6IGJyZWFrLXdvcmQi
PkJlc3QgUmVnYXJkcyw8L3ByZT4NCjxwcmUgc3R5bGU9IldPUkQtV1JBUDogYnJlYWstd29yZCI+
TGVhZjwvcHJlPg0KPHByZSBzdHlsZT0iV09SRC1XUkFQOiBicmVhay13b3JkIj4tLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogV29qY2llY2ggRGVjIFttYWlsdG86d2RlY0BjaXNjby5j
b21dIA0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTUsIDIwMTEgMTE6NTMgUE0NClRvOiBEYXZpZCBC
LiBOZWxzb24NCkNjOiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9y
ZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZzsgZmluZSBzejsgUWl1amluOyBXYW5nc2h1eGlhbmc7
IGRyYWZ0LXRhbi12Nm9wcy1mYXN0Ni1hYWFAdG9vbHMuaWV0Zi5vcmc7IExlYWYgeWVoOyByb2Jl
cnRhIG1hZ2xpb25lOyBqYWNuaXFAZ21haWwuY29tOyBCZXJuYXJkIEFib2JhDQpTdWJqZWN0OiBS
ZTog562U5aSNOiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3Mg
YWZ0ZXIgSUVURjgxIHJhZGV4dCBzZXNzaW9uDQoNCg0KDQoNCk9uIDE1LzA4LzIwMTEgMTc6MjEs
ICZxdW90O0RhdmlkIEIuIE5lbHNvbiZxdW90OyAmbHQ7ZC5iLm5lbHNvbkBjb21jYXN0Lm5ldCZn
dDsgd3JvdGU6DQoNCiZndDsmZ3Q7IC4uLiBpdCBsb29rcyB2ZXJ5IG11Y2ggYXMgcmVseWluZyBv
biB0aGUgc3BlY2lhbCBOQVMgZmVhdHVyZQ0KJmd0OyZndDsgdG8gaW50ZXJwcmV0ICp0aGUgY29u
dGVudHMqIG9mIHRoZSBhdHRyaWJ1dGUgYXMgdG8gdGhlIHBvb2xzLi4uDQomZ3Q7IA0KJmd0OyBT
cGVjaWFsIE5BUyBmZWF0dXJlPyAgV2h5IGlzIHRoZSBpbnRlcnByZXRhdGlvbiBvZiB0aGlzIHBy
b3Bvc2VkIFJBRElVUw0KJmd0OyBhdHRyaWJ1dGUgYW55IG1vcmUgc3BlY2lhbCB0aGFuIE5BUyBi
ZWhhdmlvciB0aGF0IGludGVycHJldHMgYW55IG90aGVyDQomZ3Q7IGF0dHJpYnV0ZT8gIEl0J3Mg
YWxtb3N0IGFsd2F5cyB0aGUgKmNvbnRlbnRzKiBvZiBhdHRyaWJ1dGVzIHRoYXQgaXMNCiZndDsg
aW50ZXJwcmV0ZWQgYnkgdGhlIE5BUywNCg0KT2suIFNvIGhlbHAgbWUgb3V0IGhlcmU6IEFuIG9w
ZXJhdG9yIGhhcyB0d28gcG9vbHMsIEEgZm9yIGJ1c2luZXNzDQpjdXN0b21lcnMsIEIgZm9yIHJl
c2lkZW50aWFsLiBJbiBib3RoIGNhc2VzIHRoZSBvcGVyYXRvciBleHBlY3RzIEZvby1iYXINCmFk
ZHJlc3NpbmcgbWV0aG9kIHRvIGJlIHVzZWQgYW5kIGN1c3RvbWVycyBpbiBBIG9yIEIuIEhvdyBk
b2VzIHRoZSBOQVMgcGljaw0KdGhlIHJpZ2h0IHBvb2wgYmFzZWQgb24gcmVjZWl2aW5nIGEgc2lu
Z2xlIGF0dHJpYnV0ZSBjb250YWluaW5nIGFuDQplbnVtZXJhdGVkIGNvZGUtcG9pbnQgZm9yIEZv
by1iYXI/DQoNCg0KJmd0OyANCiZndDsmZ3Q7IC4uLnRvIGJlIHVzZWQsIG9ubHkgdGhpcyB0aW1l
IHdpdGggdGhlIGNvbnRlbnRzIGJlaW5nIGxhaWQgZG93biBhcw0KJmd0OyZndDsgdGhlIGVudW1l
cmF0ZWQgdHlwZSBjb2RlIHBvaW50cyBpbiBhIGRyYWZ0Lg0KJmd0OyANCiZndDsgSSB0aGluayBh
biBlbnVtZXJhdGVkIHR5cGUgaXMgcHJlZmVyYWJsZSB0byBwYXJzaW5nIHN0cmluZ3Mgd2hlbiB0
aGUgc2VtYW50aWNzDQomZ3Q7IG9mIHRoZSBhdHRyaWJ1ZXMgaXMgdG8gYXBwbHkgb25lIG9mIGEg
bGltaXRlZCBudW1iZXIgb2YgZGlzY3JlZXQgY2hvaWNlcy4NCg0KVGhlIGFsdGVybmF0aXZlLCB3
aGljaCBpcyB3aGF0IEkgYW5kIG90aGVycyBhcmUgcHJvcG9zaW5nIGlzIHRvIGZvbGxvdw0KcHJl
Y2VkZW50IGFuZCB1c2Ugc2VwYXJhdGUgc3RyaW5nIGF0dHJpYnV0ZXMgZm9yIHRoZWlyIHJvbGUg
LSAqYXMgcHJvcG9zZWQqDQppbiB0aGUgY3VycmVudCBpcHY2LWFjY2VzcyBkcmFmdC4NCiZndDsg
DQomZ3Q7Jmd0OyBUaGlzIGRvZXMgbm90IGhlbHAgZ2l2ZW4gYSkgcGFzdCBwcmVjZWRlbnQgaW4g
dGVybXMgb2YgUmFkaXVzDQomZ3Q7Jmd0OyBwb29sIGRlZmluaXRpb25zICh0aGVyZSBhcmUgYWxy
ZWFkeSAyIHBvb2xzLCBhbmQgdGhleSBhcmUgYmVpbmcNCiZndDsmZ3Q7IHVzZWQpLCBub3IgYikg
Z2l2ZSB0aGUgb3BlcmF0b3IgYW4gZXhwbGljaXQgaW5kaWNhdGlvbiByZWdhcmRpbmcNCiZndDsm
Z3Q7IHRoZSB1c2Ugb2YgYSBwb29sLCByYXRoZXIgdGhhbiBpbXBsaWNpdC4NCiZndDsgDQomZ3Q7
IEkgZG9uJ3QgdW5kZXJ0YW5kIGVpdGhlciBvZiB0aGVzZSBwb2ludHMuICBXaGF0ICpSQURJVVMq
IHByZWNlZGVudCBleGlzdHMsIGFuZA0KJmd0OyBieSB0aGF0IEkgbWVhbiBhIHByZWNlZGVudCBp
biBub3JtYXRpdmUgdGV4dD8gIElmIHlvdSdyZSByZWZlcnJpbmcgdG8gYWQtaG9jDQomZ3Q7IGlt
cGxlbWVudGF0aW9uIHByYWN0aWNlLCBpbiB0aGUgYWJzZW5jZSBvZiBhbnkgbm9ybWF0aXZlIGd1
aWRhbmNlLCBJIHN1Z2dlc3QNCiZndDsgdGhhdCBpbiBzdGFuZGFyZGl6aW5nIGEgc29sdXRpb24g
dG8gdGhhdCBzb3J0IG9mIGdhcCBpbiB0aGUgcHJvdG9jb2wsIG9uZQ0KJmd0OyB3b3VsZCBub3Qg
YmUgdW5kdWx5IGluZmx1ZW5jZWQgYnkgdGhlIGZhY3QgdGhhdCB2YXJpb3VzIGFkLWhvYyBzb2x1
dGlvbnMgaGFkDQomZ3Q7IGJlZW4gaW1wbGVtZW50ZWQuICBUaGF0IHdvdWxkIGRlZmVhdCB0aGUg
cHVycG9zZSBvZiBzdGFuZGFyZGl6aW5nIGJlaGF2aW9yLg0KDQpQcmVjZWRlbnQgPSByZmMzMTYy
LCByZmM0ODE4LCBhbmQgZWFybGllciBub24gSVB2NiBvbmVzLCBlYWNoIGRlZmluZSBuYW1lZA0K
cG9vbHMgZm9yIGEgc3BlY2lmaWMgcHVycG9zZS4NCg0KDQomZ3Q7IA0KJmd0OyZndDsgQmVzaWRl
cyB0aGUgYWJvdmUsIGFzIHdpdGggYW55IGVudW1lcmF0ZWQgdHlwZSwgaXNzdWVzIHdpbGwgc3Rh
cnQNCiZndDsmZ3Q7IHNob3VsZCB0aGVyZSBiZSBhbm90aGVyIGNvbWJpbmF0aW9uIHRoYXQgc29t
ZW9uZSBjb21lcyB1cCB3aXRoIG9yDQomZ3Q7Jmd0OyB3YW50cy4uLg0KJmd0OyANCiZndDsgVGhl
IElBTkEgY29kZSBwb2ludCBhbGxvY2F0aW9uIHByb2NlZHVyZXMgc2hvdWxkIGJlIHN1ZmZpY2ll
bnRseSBvcGVuIHRvDQomZ3Q7IHBlcm1pdCBhZGRpbmcgYWRkaXRpb25hbCAmcXVvdDtmbGF2b3Jz
JnF1b3Q7IHdpdGhvdXQgaW52b2tpbmcgSUVURiBjb25zZW5zdXMgb3IgV0cNCiZndDsgYXBwcm92
YWxzLg0KDQpTdXJlLiBXZSBhcHBlYXIgdG8gYmUgdGFsa2luZyBhYm91dCBjb2RlLXBvaW50cyBm
b3IgdmFsdWVzIHdpdGhpbiBhIHNpbmdsZQ0KYXR0cmlidXRlLCBmaW5lIGV4YW1wbGVzLCAoIGZv
ciB3aGljaCBubyBJQU5BIGNvZGUgcG9pbnRzIHdlcmUgYXNzaWduZWQpDQppbmNsdWRlIHRoZSBl
eGlzdGluZyBTZXJ2aWNlLVR5cGUgYW5kIEVycm9yLUNhdXNlIGF0dHJpYnV0ZXMuDQpJbiBlbnVt
ZXJhdGluZyB0aGlzLCBieSBkZWZpbml0aW9uIHRoZXJlIGlzIGEgcmVzdHJpY3Rpb24gd2hpY2gg
aXMgbm90DQpjYWxsZWQgZm9yIGluIHRoaXMgc2l0dWF0aW9uLiBTaG91bGQgYW4gb3BlcmF0b3Ig
Y2hvb3NlIHRvIHNheSBhc3NpZ24gMg0KcHJlZml4ZXMgdG8gYSBzdWJzY3JpYmVyIGZvciBESENQ
LVBELCBidXQgb25lIGZvciBTTEFBQywgdGhleSB3b3VsZCBuZWVkIHRvDQpnZXQgYW4gSUFOQSBj
b2RlIHBvaW50Li4uIEFuZCB0aGVuIGhhdmUgdGhlIHZlbmRvcihzKSBzdXBwb3J0IHRoYXQsIGV0
Yy4NCk5ldmVyIG1pbmQgb3BlbiBJQU5BIGNvZGUgcG9pbnQgYWxsb2NhdGlvbiBwcm9jZWR1cmVz
IC0gdGhpcyBsb29rcyB0byBiZQ0KcHJhY3RpY2FsbHkgdW53aXNlLg0KDQomZ3Q7IA0KJmd0OyZn
dDsgRnJhbmtseSwgb3RoZXIgdGhhbiBpdCBiZWluZyBhbm90aGVyIHdheSBvZiBkb2luZyB0aGlu
Z3MsIEkgcGVyc29uYWxseQ0KJmd0OyZndDsgZG9uwrl0IHNlZSBtdWNoIG9mIGEgYmVuZWZpdC4N
CiZndDsgDQomZ3Q7IElmIHlvdSBhcmUgaW52ZXN0ZWQgaW4gYW4gZXhpc3RpbmcgaW1wbGVtZW50
YXRpb24gdXNpbmcgYW5vdGhlciBhcHByb2FjaCBJIGNhbg0KJmd0OyB1bmRlcnN0YW5kIHRoYXQs
IGJ1dCBhIGNsZWFybHkgZGVmaW5lZCwgZW51bWVyYXRlZCB2YWx1ZSBhdHRyaWJ1dGUgc2VlbXMg
bW9yZQ0KJmd0OyBhdHRyYWN0aXZlIHRvIG1lLg0KDQpCZWZvcmUgZ29pbmcgZnVydGhlciwgcGVy
aGFwcyB5b3UgY291bGQgY29uc2lkZXIvY29tbWVudCBvbiB0aGUgY3VycmVudA0KcHJvcG9zYWwg
aW46IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNj
ZXNzLTA1DQoNClRoYW5rcywNCldvamNpZWNoLg0KJmd0OyANCiZndDsgLS0gRGF2ZQ0KDQo8L3By
ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--Boundary_(ID_uCjQEmRTm/NCae5CCZJxmg)--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 16 Aug 2011 15:34:05 +0000
Date: Tue, 16 Aug 2011 15:33:02 +0000
From: Leaf yeh <[e-mail]>
Subject: =?gb2312?B?UkU6ILTwuLQ6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1p?= =?gb2312?Q?pv6-access_after_IETF81_radext_session?=
To: "David B. Nelson" <[e-mail]>, Wojciech Dec <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, fine sz <[e-mail]>, Qiujin <[e-mail]>, Wangshuxiang <[e-mail]>, "[e-mail]" <[e-mail]>, roberta maglione <[e-mail]>, "[e-mail]" <[e-mail]>, Bernard Aboba <[e-mail]>
Message-id: <382D9B71-9EE2-4E56-AACE-EE1C2C982F6A@mimectl>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_UAFKLvEiFiAN8FyfF5KR4A)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: =?gb2312?B?tPC4tDogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYt?= =?gb2312?Q?access_after_IETF81_radext_session?=
Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsP///hb8P//4L6o///A+qL/9rzAo//ro/OA/8mB5lD/jIfrZf8ZYB+A/jEiMMD8YcbOyg==

--Boundary_(ID_UAFKLvEiFiAN8FyfF5KR4A)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: base64

RGF2aWQgLSBJdCdzIGFsbW9zdCBhbHdheXMgdGhlICpjb250ZW50cyogb2YgYXR0cmlidXRlcyB0
aGF0IGlzIGludGVycHJldGVkIGJ5IHRoZSBOQVMuLi4NCg0KSSBhZ3JlZS4NCg0KSSB0aG91Z2h0
IEFBQSBzZXJ2ZXIganVzdCBuZWVkIHRvIGluZGljYXRlIHNpbmdsZSBvciBtdWx0aXBsZSBwb29s
IG5hbWVzLCB3aG9zZSBtZWFuaW5nICYgcHVycG9zZSBzaG91bGQgZGVmaW5pdGVseSBiZSBrbm93
biBpbiBhZHZhbmNlZCBieSBBQUEgc2VydmVyLg0KDQpJIGRvdWJ0ZWQgdGhlIGF0dHJpYnV0ZXMg
b2YgJ0RlbGVnYXRlZC1JUHY2LVByZWZpeC1Qb29sJyBhbmQgJ1N0YXRlZnVsLUlQdjYtQWRkcmVz
cy1Qb29sJyB3aWxsIG1ha2UgTkFTJ3MgbGlmZSBlYXNpZXIgdGhhbiBiZWZvcmUuIDotKSBJIGJl
bGlldmUgTkFTIHdpbGwgZG91YmxlIGNoZWNrIHRoZSB0eXBlIG9mIHBvb2wgYWdhaW5zdCB0aGUg
bmFtZSBzdHJpbmcgaW4gdGhlIGRpZmZlcmVudCB0eXBlIGNvbnRhaW5lciBvZiB0aGUgYXR0cmli
dXRlcyAob3IgcHJvcG9zZWQgYXR0cmlidXRlcykgaW5jbHVkaW5nIEZyYW1lZC1Qb29sLCBGcmFt
ZWQtSVB2Ni1Qb29sLCBEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCBhbmQgU3RhdGVmdWwtSVB2
Ni1BZGRyZXNzLVBvb2wuIFJpZ2h0Pw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG
cm9tOiBEYXZpZCBCLiBOZWxzb24gW21haWx0bzpkLmIubmVsc29uQGNvbWNhc3QubmV0XQ0KU2Vu
dDogTW9uZGF5LCBBdWd1c3QgMTUsIDIwMTEgMTE6MjIgUE0NClRvOiBXb2pjaWVjaCBEZWMNCkNj
OiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVzZXh0
QG9wcy5pZXRmLm9yZzsgZmluZSBzejsgUWl1amluOyBXYW5nc2h1eGlhbmc7IGRyYWZ0LXRhbi12
Nm9wcy1mYXN0Ni1hYWFAdG9vbHMuaWV0Zi5vcmc7IExlYWYgeWVoOyByb2JlcnRhIG1hZ2xpb25l
OyBqYWNuaXFAZ21haWwuY29tOyBCZXJuYXJkIEFib2JhDQpTdWJqZWN0OiBSZTogtPC4tDogUSBv
biBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSBy
YWRleHQgc2Vzc2lvbg0KDQo+IC4uLiBpdCBsb29rcyB2ZXJ5IG11Y2ggYXMgcmVseWluZyBvbiB0
aGUgc3BlY2lhbCBOQVMgZmVhdHVyZQ0KPiB0byBpbnRlcnByZXQgKnRoZSBjb250ZW50cyogb2Yg
dGhlIGF0dHJpYnV0ZSBhcyB0byB0aGUgcG9vbHMuLi4NCg0KU3BlY2lhbCBOQVMgZmVhdHVyZT8g
IFdoeSBpcyB0aGUgaW50ZXJwcmV0YXRpb24gb2YgdGhpcyBwcm9wb3NlZCBSQURJVVMgYXR0cmli
dXRlIGFueSBtb3JlIHNwZWNpYWwgdGhhbiBOQVMgYmVoYXZpb3IgdGhhdCBpbnRlcnByZXRzIGFu
eSBvdGhlciBhdHRyaWJ1dGU/ICBJdCdzIGFsbW9zdCBhbHdheXMgdGhlICpjb250ZW50cyogb2Yg
YXR0cmlidXRlcyB0aGF0IGlzIGludGVycHJldGVkIGJ5IHRoZSBOQVMsDQoNCj4gLi4udG8gYmUg
dXNlZCwgb25seSB0aGlzIHRpbWUgd2l0aCB0aGUgY29udGVudHMgYmVpbmcgbGFpZCBkb3duIGFz
DQo+IHRoZSBlbnVtZXJhdGVkIHR5cGUgY29kZSBwb2ludHMgaW4gYSBkcmFmdC4NCg0KSSB0aGlu
ayBhbiBlbnVtZXJhdGVkIHR5cGUgaXMgcHJlZmVyYWJsZSB0byBwYXJzaW5nIHN0cmluZ3Mgd2hl
biB0aGUgc2VtYW50aWNzIG9mIHRoZSBhdHRyaWJ1ZXMgaXMgdG8gYXBwbHkgb25lIG9mIGEgbGlt
aXRlZCBudW1iZXIgb2YgZGlzY3JlZXQgY2hvaWNlcy4NCg0KPiBUaGlzIGRvZXMgbm90IGhlbHAg
Z2l2ZW4gYSkgcGFzdCBwcmVjZWRlbnQgaW4gdGVybXMgb2YgUmFkaXVzDQo+IHBvb2wgZGVmaW5p
dGlvbnMgKHRoZXJlIGFyZSBhbHJlYWR5IDIgcG9vbHMsIGFuZCB0aGV5IGFyZSBiZWluZw0KPiB1
c2VkKSwgbm9yIGIpIGdpdmUgdGhlIG9wZXJhdG9yIGFuIGV4cGxpY2l0IGluZGljYXRpb24gcmVn
YXJkaW5nDQo+IHRoZSB1c2Ugb2YgYSBwb29sLCByYXRoZXIgdGhhbiBpbXBsaWNpdC4NCg0KSSBk
b24ndCB1bmRlcnRhbmQgZWl0aGVyIG9mIHRoZXNlIHBvaW50cy4gIFdoYXQgKlJBRElVUyogcHJl
Y2VkZW50IGV4aXN0cywgYW5kIGJ5IHRoYXQgSSBtZWFuIGEgcHJlY2VkZW50IGluIG5vcm1hdGl2
ZSB0ZXh0PyAgSWYgeW91J3JlIHJlZmVycmluZyB0byBhZC1ob2MgaW1wbGVtZW50YXRpb24gcHJh
Y3RpY2UsIGluIHRoZSBhYnNlbmNlIG9mIGFueSBub3JtYXRpdmUgZ3VpZGFuY2UsIEkgc3VnZ2Vz
dCB0aGF0IGluIHN0YW5kYXJkaXppbmcgYSBzb2x1dGlvbiB0byB0aGF0IHNvcnQgb2YgZ2FwIGlu
IHRoZSBwcm90b2NvbCwgb25lIHdvdWxkIG5vdCBiZSB1bmR1bHkgaW5mbHVlbmNlZCBieSB0aGUg
ZmFjdCB0aGF0IHZhcmlvdXMgYWQtaG9jIHNvbHV0aW9ucyBoYWQgYmVlbiBpbXBsZW1lbnRlZC4g
IFRoYXQgd291bGQgZGVmZWF0IHRoZSBwdXJwb3NlIG9mIHN0YW5kYXJkaXppbmcgYmVoYXZpb3Iu
DQoNCj4gQmVzaWRlcyB0aGUgYWJvdmUsIGFzIHdpdGggYW55IGVudW1lcmF0ZWQgdHlwZSwgaXNz
dWVzIHdpbGwgc3RhcnQNCj4gc2hvdWxkIHRoZXJlIGJlIGFub3RoZXIgY29tYmluYXRpb24gdGhh
dCBzb21lb25lIGNvbWVzIHVwIHdpdGggb3INCj4gd2FudHMuLi4NCg0KVGhlIElBTkEgY29kZSBw
b2ludCBhbGxvY2F0aW9uIHByb2NlZHVyZXMgc2hvdWxkIGJlIHN1ZmZpY2llbnRseSBvcGVuIHRv
IHBlcm1pdCBhZGRpbmcgYWRkaXRpb25hbCAiZmxhdm9ycyIgd2l0aG91dCBpbnZva2luZyBJRVRG
IGNvbnNlbnN1cyBvciBXRyBhcHByb3ZhbHMuDQoNCj4gRnJhbmtseSwgb3RoZXIgdGhhbiBpdCBi
ZWluZyBhbm90aGVyIHdheSBvZiBkb2luZyB0aGluZ3MsIEkgcGVyc29uYWxseQ0KPiBkb26hr3Qg
c2VlIG11Y2ggb2YgYSBiZW5lZml0Lg0KDQpJZiB5b3UgYXJlIGludmVzdGVkIGluIGFuIGV4aXN0
aW5nIGltcGxlbWVudGF0aW9uIHVzaW5nIGFub3RoZXIgYXBwcm9hY2ggSSBjYW4gdW5kZXJzdGFu
ZCB0aGF0LCBidXQgYSBjbGVhcmx5IGRlZmluZWQsIGVudW1lcmF0ZWQgdmFsdWUgYXR0cmlidXRl
IHNlZW1zIG1vcmUgYXR0cmFjdGl2ZSB0byBtZS4NCg0KLS0gRGF2ZQ0KDQo=

--Boundary_(ID_UAFKLvEiFiAN8FyfF5KR4A)
Content-id: <[e-mail]>
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable

<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<style id=3D"owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body ocsi=3D"0" fPStyle=3D"1">
<div style=3D"FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZ=
E: 10pt">
<pre style=3D"WORD-WRAP: break-word">David - It's almost always the *conten=
ts* of attributes that is interpreted by the NAS...

I agree.=20

I thought AAA server just need to indicate single or multiple pool names, w=
hose meaning &amp; purpose should definitely be known in advanced by AAA se=
rver.=20

I doubted the attributes of 'Delegated-IPv6-Prefix-Pool' and 'Stateful-IPv6=
-Address-Pool' will make NAS's life easier than before. :-) I believe NAS w=
ill double check the type of pool against the name string in the different =
type container of the attributes (or proposed attributes) including Framed-=
Pool, Framed-IPv6-Pool, Delegated-IPv6-Prefix-Pool and Stateful-IPv6-Addres=
s-Pool. Right?


-----Original Message-----
From: David B. Nelson [mailto:[e-mail]]=20
Sent: Monday, August 15, 2011 11:22 PM
To: Wojciech Dec
Cc: [e-mail]; [e-mail]; f=
ine sz; Qiujin; Wangshuxiang; [e-mail]; Lea=
f yeh; roberta maglione; [e-mail]; Bernard Aboba
Subject: Re: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access af=
ter IETF81 radext session

&gt; ... it looks very much as relying on the special NAS feature
&gt; to interpret *the contents* of the attribute as to the pools...

Special NAS feature?  Why is the interpretation of this proposed RADIUS att=
ribute any more special than NAS behavior that interprets any other attribu=
te?  It's almost always the *contents* of attributes that is interpreted by=
 the NAS,

&gt; ...to be used, only this time with the contents being laid down as
&gt; the enumerated type code points in a draft.=20

I think an enumerated type is preferable to parsing strings when the semant=
ics of the attribues is to apply one of a limited number of discreet choice=
s.

&gt; This does not help given a) past precedent in terms of Radius
&gt; pool definitions (there are already 2 pools, and they are being
&gt; used), nor b) give the operator an explicit indication regarding
&gt; the use of a pool, rather than implicit.

I don't undertand either of these points.  What *RADIUS* precedent exists, =
and by that I mean a precedent in normative text?  If you're referring to a=
d-hoc implementation practice, in the absence of any normative guidance, I =
suggest that in standardizing a solution to that sort of gap in the protoco=
l, one would not be unduly influenced by the fact that various ad-hoc solut=
ions had been implemented.  That would defeat the purpose of standardizing =
behavior.

&gt; Besides the above, as with any enumerated type, issues will start
&gt; should there be another combination that someone comes up with or
&gt; wants...

The IANA code point allocation procedures should be sufficiently open to pe=
rmit adding additional &quot;flavors&quot; without invoking IETF consensus =
or WG approvals.

&gt; Frankly, other than it being another way of doing things, I personally
&gt; don=A1=AFt see much of a benefit.

If you are invested in an existing implementation using another approach I =
can understand that, but a clearly defined, enumerated value attribute seem=
s more attractive to me.

-- Dave
</pre>
</div>
</body>
</html>

--Boundary_(ID_UAFKLvEiFiAN8FyfF5KR4A)--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 16 Aug 2011 14:59:33 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=[e-mail]; l=2012; q=dns/txt; s=iport; t=1313506688; x=1314716288; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=XZdVAawb6zMUjXs75Doooudm1xCMklcP7HJ6UvfCfgs=; b=S3fe9O2vozGEW2FXCmmBO2Yccbk21ivxD/6Y0ajNzqOLusuYMuj5cUF9 WsnBt88Y0PfXmAfC0oSSr5cRabvZgrpZB0MEAvfT0/rF/LHpIoGM2wI60 CdEBOJEXgOnVNpQdG4FM2RFff0Om/kB8zmFTk5AudW+NUiTalWAP1Br9f w=;
User-Agent: Microsoft-Entourage/12.29.0.110113
Date: Tue, 16 Aug 2011 16:58:02 +0200
Subject: Re: =?Big5?B?tarOYA==?=: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: Wojciech Dec <[e-mail]>
To: Dave Nelson <[e-mail]>
CC: "David B. Nelson" <[e-mail]>, <[e-mail]>, <[e-mail]>, fine sz <[e-mail]>, Qiujin <[e-mail]>, Wangshuxiang <[e-mail]>, <[e-mail]>, Leaf yeh <[e-mail]>, roberta maglione <[e-mail]>, <[e-mail]>, Bernard Aboba <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: =?Big5?B?tarOYA==?=: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
Thread-Index: AcxcJOUmyoB1dt1vHkCJw1xk4lI1yA==
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

On 16/08/2011 16:33, "Dave Nelson" <[e-mail]> wrote:


> 
> I have no problem with string encodings of pool names.   Since pools
> can be named arbitrarily by the NAS system administrator, anything
> other than a string encoding would be unnatural.  My issue is when we
> try to mix in a fixed set of address assignment methods with the pool
> names.  Separation of concerns.

Well, I think we're in agreement and when you come to read the WG proposal
in draft-ietf-radext-ipv6 you will find it NOT to have the above issue.
The origin of this email thread, it seems appropriate to recall it, is that
some folks claimed that the proposal in the draft is not needed and that
solving the case by overloading pool naming is better, followed on by a
second proposal for the enumerated type.

> 
>> Sure. We appear to be talking about code-points for values within a single
>> attribute, fine examples, ( for which no IANA code points were assigned)
>> include the existing Service-Type and Error-Cause attributes.
>> In enumerating this, by definition there is a restriction which is not
>> called for in this situation.
> 
> Why not?

Example given below, and it is one that is perfectly legitimate.

> 
>> Should an operator choose to say assign 2 prefixes to a subscriber
>> for DHCP-PD, but one for SLAAC, they would need to
>> get an IANA code point...
> 
> I don't think that specific values for *combinations* of options is a
> good way to go.

It's rather clear that an enumerated attribute cannot handle this case.

> 
>> Before going further, perhaps you could consider/comment on the current
>> proposal in: http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-05
> 
> I'll find some time to do that, soon.

Please do. I think we're in agreement here and there is no need of changes.

Regards,
Woj.
> 
> Regards,
> 
> Dave
> 
> David B. Nelson
> Sr. Software Architect
> Elbrys Networks, Inc.
> www.elbrys.com
> +1.603.570.2636


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 16 Aug 2011 07:29:48 +0000
Date: Tue, 16 Aug 2011 07:27:22 +0000
From: Leaf yeh <[e-mail]>
Subject: =?utf-8?B?UkU6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: "David B. Nelson" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Bernard Aboba <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: =?utf-8?B?562U5aSNOiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2?= =?utf-8?Q?6-access_after_IETF81_radext_session?=
Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsP///hb8P//4L6o///A+qL/9rzAo//ro/OA/8mB5lD/jRU1gP8YXBBA

SG93IGFib3V0IHRoZSByZXBsYWNlbWVudCBvZiAnTm9kZS10eXBlJyBvciAnQWNjZXNzLXR5cGUn
PyAgb3IgYW55IG90aGVyIHN1Z2dlc3Rpb24/DQoNCg0KQmVzdCBSZWdhcmRzLA0KTGVhZg0KDQpQ
Uy4gaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9yYWRpdXMtdHlwZXMvcmFkaXVzLXR5
cGVzLnhtbCANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGF2aWQgQi4g
TmVsc29uIFttYWlsdG86ZC5iLm5lbHNvbkBjb21jYXN0Lm5ldF0gDQpTZW50OiBNb25kYXksIEF1
Z3VzdCAxNSwgMjAxMSA3OjQ0IFBNDQpUbzogTGVhZiB5ZWgNCkNjOiBkcmFmdC1pZXRmLXJhZGV4
dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZzsgZmlu
ZSBzejsgUWl1amluOyBXYW5nc2h1eGlhbmc7IGRyYWZ0LXRhbi12Nm9wcy1mYXN0Ni1hYWFAdG9v
bHMuaWV0Zi5vcmc7IHdkZWNAY2lzY28uY29tOyByb2JlcnRhIG1hZ2xpb25lOyBqYWNuaXFAZ21h
aWwuY29tOyBCZXJuYXJkIEFib2JhDQpTdWJqZWN0OiBSZTog562U5aSNOiBRIG9uIFZlci4tMDUg
b2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3MgYWZ0ZXIgSUVURjgxIHJhZGV4dCBzZXNz
aW9uDQoNCj4gVGhlIOKAmFVzZXItVHlwZeKAmSBjYW4gY292ZXIgdGhlIGZvbGxvd2luZyBjYXNl
cyBmb3IgYm90aA0KPiBQUFBvRSBhbmQgSVBvRSBhY2Nlc3MgbW9kZWwgYnkgbm93Lg0KDQpUaGUg
cHJvcG9zZWQgdmFsdWVzIGZvciB0aGlzIGF0dHJpYnV0ZSBzZWVtIHRvIGRlc2NyaWJlIHByb3Bl
cnRpZXMgb2YgdGhlIGF0dGFjaGVkIGhvc3QuICBJbiBSQURJVVMsIHRoZSB0ZXJtICJ1c2VyIiBy
ZWZlcnMgdG8gYSBodW1hbiwgZm9yIHdob20gYWNjb3VudCBhbmQgc2VydmljZSBwcm92aXNpb25p
bmcgaGFzIGJlZW4gZXN0YWJsaXNoZWQuICBJIHdvdWxkIHN1Z2dlc3QgY2FsbGluZyB0aGlzIHBy
b3Bvc2VkIGF0dHJpYnV0ZSBzb21ldGhpbmcgZWxzZSwgbW9yZSBhY2N1cmF0ZWx5IGRlc2NyaXB0
aXZlLiANCg==

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 15 Aug 2011 15:53:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=[e-mail]; l=3581; q=dns/txt; s=iport; t=1313423570; x=1314633170; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Z40DNle+yahOxRBopU12/Fxit4rgXDf9EsLQY6f1tqk=; b=Afr11huXiOD6tNkGDZh/tt4dTImdN7TpT6Ww/RSa0NCw5n6OxxQr8s3k X8C+RorLYqroIwPQX9g5/vZQam7Zr4yNsLxsAwpffClx4EjraWzjE0gF2 Z7Ez8byyBfv8+ugs5zZSbXv6z1opc4Wc7NvxwPEclDIcoLDmkqMw/piTy Q=;
User-Agent: Microsoft-Entourage/12.29.0.110113
Date: Mon, 15 Aug 2011 17:52:40 +0200
Subject: Re: =?Big5?B?tarOYA==?=: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: Wojciech Dec <[e-mail]>
To: "David B. Nelson" <[e-mail]>
CC: <[e-mail]>, <[e-mail]>, fine sz <[e-mail]>, Qiujin <[e-mail]>, Wangshuxiang <[e-mail]>, <[e-mail]>, Leaf yeh <[e-mail]>, roberta maglione <[e-mail]>, <[e-mail]>, Bernard Aboba <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: =?Big5?B?tarOYA==?=: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
Thread-Index: AcxbY1yUkAUnRjeJZ0Cjiyow3+ZqQA==
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

On 15/08/2011 17:21, "David B. Nelson" <[e-mail]> wrote:

>> ... it looks very much as relying on the special NAS feature
>> to interpret *the contents* of the attribute as to the pools...
>=20
> Special NAS feature?  Why is the interpretation of this proposed RADIUS
> attribute any more special than NAS behavior that interprets any other
> attribute?  It's almost always the *contents* of attributes that is
> interpreted by the NAS,

Ok. So help me out here: An operator has two pools, A for business
customers, B for residential. In both cases the operator expects Foo-bar
addressing method to be used and customers in A or B. How does the NAS pick
the right pool based on receiving a single attribute containing an
enumerated code-point for Foo-bar?


>=20
>> ...to be used, only this time with the contents being laid down as
>> the enumerated type code points in a draft.
>=20
> I think an enumerated type is preferable to parsing strings when the sema=
ntics
> of the attribues is to apply one of a limited number of discreet choices.

The alternative, which is what I and others are proposing is to follow
precedent and use separate string attributes for their role - *as proposed*
in the current ipv6-access draft.
>=20
>> This does not help given a) past precedent in terms of Radius
>> pool definitions (there are already 2 pools, and they are being
>> used), nor b) give the operator an explicit indication regarding
>> the use of a pool, rather than implicit.
>=20
> I don't undertand either of these points.  What *RADIUS* precedent exists=
, and
> by that I mean a precedent in normative text?  If you're referring to ad-=
hoc
> implementation practice, in the absence of any normative guidance, I sugg=
est
> that in standardizing a solution to that sort of gap in the protocol, one
> would not be unduly influenced by the fact that various ad-hoc solutions =
had
> been implemented.  That would defeat the purpose of standardizing behavio=
r.

Precedent =3D rfc3162, rfc4818, and earlier non IPv6 ones, each define named
pools for a specific purpose.


>=20
>> Besides the above, as with any enumerated type, issues will start
>> should there be another combination that someone comes up with or
>> wants...
>=20
> The IANA code point allocation procedures should be sufficiently open to
> permit adding additional "flavors" without invoking IETF consensus or WG
> approvals.

Sure. We appear to be talking about code-points for values within a single
attribute, fine examples, ( for which no IANA code points were assigned)
include the existing Service-Type and Error-Cause attributes.
In enumerating this, by definition there is a restriction which is not
called for in this situation. Should an operator choose to say assign 2
prefixes to a subscriber for DHCP-PD, but one for SLAAC, they would need to
get an IANA code point... And then have the vendor(s) support that, etc.
Never mind open IANA code point allocation procedures - this looks to be
practically unwise.

>=20
>> Frankly, other than it being another way of doing things, I personally
>> don=B9t see much of a benefit.
>=20
> If you are invested in an existing implementation using another approach =
I can
> understand that, but a clearly defined, enumerated value attribute seems =
more
> attractive to me.

Before going further, perhaps you could consider/comment on the current
proposal in: http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-05

Thanks,
Wojciech.
>=20
> -- Dave


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 15 Aug 2011 15:22:44 +0000
Date: Mon, 15 Aug 2011 15:21:51 +0000 (UTC)
From: "David B. Nelson" <[e-mail]>
To: Wojciech Dec <[e-mail]>
Cc: [e-mail], [e-mail],  fine sz <[e-mail]>, Qiujin <[e-mail]>,  Wangshuxiang <[e-mail]>,  [e-mail],  Leaf yeh <[e-mail]>,  roberta maglione <[e-mail]>,  [e-mail], Bernard Aboba <[e-mail]>
Message-ID: <[e-mail]>
Subject: =?utf-8?Q?Re:_=E7=AD=94=E5=A4=8D:_Q_on_Ver.-05_of_draft-ietf-radex?= =?utf-8?Q?t-ipv6-access_after_IETF81_radext_session?=
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

> ... it looks very much as relying on the special NAS feature
> to interpret *the contents* of the attribute as to the pools...

Special NAS feature?  Why is the interpretation of this proposed RADIUS att=
ribute any more special than NAS behavior that interprets any other attribu=
te?  It's almost always the *contents* of attributes that is interpreted by=
 the NAS,

> ...to be used, only this time with the contents being laid down as
> the enumerated type code points in a draft.=20

I think an enumerated type is preferable to parsing strings when the semant=
ics of the attribues is to apply one of a limited number of discreet choice=
s.

> This does not help given a) past precedent in terms of Radius
> pool definitions (there are already 2 pools, and they are being
> used), nor b) give the operator an explicit indication regarding
> the use of a pool, rather than implicit.

I don't undertand either of these points.  What *RADIUS* precedent exists, =
and by that I mean a precedent in normative text?  If you're referring to a=
d-hoc implementation practice, in the absence of any normative guidance, I =
suggest that in standardizing a solution to that sort of gap in the protoco=
l, one would not be unduly influenced by the fact that various ad-hoc solut=
ions had been implemented.  That would defeat the purpose of standardizing =
behavior.

> Besides the above, as with any enumerated type, issues will start
> should there be another combination that someone comes up with or
> wants...

The IANA code point allocation procedures should be sufficiently open to pe=
rmit adding additional "flavors" without invoking IETF consensus or WG appr=
ovals.

> Frankly, other than it being another way of doing things, I personally
> don=E2=80=99t see much of a benefit.

If you are invested in an existing implementation using another approach I =
can understand that, but a clearly defined, enumerated value attribute seem=
s more attractive to me.

-- Dave

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 15 Aug 2011 12:10:29 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=[e-mail]; l=51318; q=dns/txt; s=iport; t=1313410160; x=1314619760; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=x58Qck+hLHzTiQKVY+rUwHTMTlyZ3QdOAYWdYiqtzDE=; b=e4wqF6Bo2VbyzZb8PkBNHRi9p2TnGNVWxw8UudUKgwc81Tw4OdQVaZMo PLMjrCOYcCnwYDlggJ0QChlpz6S6fq51Jrq4+eNuGZLozMr77n9dXCVBW rzoyKMWi6JucXfKwUo7z2HIbmJ3PyRmGEoU6AS/dO6OjjEUuBUJC/VEFv g=;
User-Agent: Microsoft-Entourage/12.29.0.110113
Date: Mon, 15 Aug 2011 14:09:12 +0200
Subject: Re: =?Big5?B?tarOYA==?=: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: Wojciech Dec <[e-mail]>
To: Leaf yeh <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Bernard Aboba <[e-mail]>
CC:  "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Qiujin <[e-mail]>, Wangshuxiang <[e-mail]>, "[e-mail]" <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: =?Big5?B?tarOYA==?=: 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+qL/9rzAo//ro/OA/8mB5lD/jIfrZQ==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3396262154_11243562"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3396262154_11243562
Content-type: text/plain;
	charset="GB2312"
Content-transfer-encoding: quoted-printable

Hello Leaf,

If I understand it correctly, you=A1=AFre proposing that the end user/host type=
s
be enumerated as part of a new attribute, which would then drive the
addressing behavior, eg selection of pools. If so, it looks very much as
relying on the special NAS feature to interpret *the contents* of the
attribute as to the pools to be used, only this time with the contents bein=
g
laid down as the enumerated type code points in a draft. This does not help
given a) past precedent in terms of Radius pool definitions (there are
already 2 pools, and they are being used), nor b) give  the operator an
explicit indication regarding the use of a pool, rather than implicit.
Besides the above, as with any enumerated type, issues will start should
there be another combination that someone comes up with or wants...

Frankly, other than it being another way of doing things, I personally don=A1=
=AFt
see much of a benefit.

Regards,
Woj.


On 15/08/2011 13:19, "Leaf yeh" <[e-mail]> wrote:

> Wojciech - There is little that disallows a vendor from implementing just=
 one
> named pool for all protocols and all methods of assignment ( the Framed-P=
ool
> appears to have been envisaged for that ) and then using some implementat=
ion
> specific logic (eg parsing for a name) to figure out/how it=A1=AFs to be used=
.
> =20
> I agree.
> =20
> Wojciech - Since the Radius specification is NOT about specifying
> implementation the only reliable/unambiguous manner in which different
> pools/methods can be utilized would appear to be using different attribut=
es as
> proposed in the current draft. Are there any other options/solutions avai=
lable
> that do not call on implicit features being there?
>=20
>=20
> A new attribute designed to indicate the =A1=AEUser-Type=A1=AF sounds a more stra=
ight
> manner and will have the potential extensibility to prevent this kind of
> ambiguity, which has been proposed in  section 4.1 of
> draft-yeh-radext-dual-stack-access-02.
> =20
> The =A1=AEUser-Type=A1=AF can cover the following cases for both PPPoE and IPoE a=
ccess
> model by now.
> =20
> IPv4-only Host
> IPv6-only Host(Numbered by SLAAC)
> IPv6-only Host(Numbered by DHCPv6)
> IPv6-only Customer Router(Unnumbered)
> IPv6-only Customer Router(Numbered by SLAAC)
> IPv6-only Customer Router(Numbered by DHCPv6)
> Dual stack - IPv4 Host + IPv6 Host(Numbered by SLAAC)
> Dual stack - IPv4 Host + IPv6 Host(Numbered by DHCPv6)
> Dual stack - IPv4 Host + IPv6 Customer Router(Unnumbered)
> Dual stack - IPv4 Host + IPv6 Customer Router(Numbered by SLAAC)
> Dual stack - IPv4 Host + IPv6 Customer Router(Numbered by DHCPv6)
> =20
> Another usage (or design purpose) of =A1=AEUser-Type=A1=AF is for the default beh=
avior
> of the NAS. When the NAS has not received the pool-name attributes
> (Framed-Pool, Framed-IPv6-Pool, etc) from AAA server, it can directly ass=
ign
> the address/prefix from the default pools.
> =20
> Section 4.1 of draft-tan-v6ops-fast6-aaa-01 might give us a new reference=
.
> "User-Type" attribute can simplify the way how BRAS determines the user t=
ype.
> In addition, BRAS can allocate appropriate IP addresses for the user even
> without the address pool attribute sent by RADIUS serve, if default addre=
ss
> pool is defined by BRAS.
> =20
> =20
> Best Regards,
> Leaf
> =20
> =20
> =20
>=20
> From: Bernard Aboba [mailto:[e-mail]]
> Sent: Wednesday, August 03, 2011 6:48 AM
> To: [e-mail]; Leaf yeh; [e-mail];
> [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]; Qiujin; Wangshuxiang
> Subject: RE: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IE=
TF81
> radext session
> =20
>=20
> In general, the concern that has lead to defining these distinct pools is=
 the
> possibility that multiple pool types might be enabled for a single sessio=
n.
> For example, it's possible that an IPv6 address might be assigned from a =
pool,
> and at the same time that a Prefix might be delegated from a pool, for th=
e
> same user and session.  In such a situation,  using the same pool name fo=
r
> multiple purposes could be ambiguous and/or under-specified.
>=20
> A note about Woj's concern about errors.  With respect to a server sendin=
g an
> attribute that a client does not understand, RFC 5080 Section 2.5 provide=
s
> guidance:
>    In general, it is best for a RADIUS client to err on the side of
>    caution.  On receiving an Access-Accept including an attribute of
>    known Type for an unimplemented service, a RADIUS client MUST treat
>    it as an Access-Reject, as directed in [RFC2865] Section 1.1
> <http://tools.ietf.org/html/rfc2865#section-1.1> .  On
>    receiving an Access-Accept including an attribute of unknown Type, a
>    RADIUS client SHOULD assume that it is a potential service
>    definition, and treat it as an Access-Reject.  Unknown VSAs SHOULD be
>    ignored by RADIUS clients.
> As a result, it is possible that a client not implementing the IPv6 Acces=
s RFC
> will ignore the attributes (e.g. not implement the SHOULD) rather than
> refusing to provide service.
>=20
>=20
> Date: Mon, 1 Aug 2011 12:47:38 -0400
> Subject: Re: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IE=
TF81
> radext session
> From: [e-mail]
> To: [e-mail]; [e-mail]; jacniq@gmai=
l.com
> CC: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
>=20
> Hi All,
>=20
> Allow me to share some comments:
> * There is precedent of multiple =A1=B0specific=A1=B1 named pools; Framed-Pool,
> Framed-IPv6-Pool, and the uncontested Delegated-IPv6-Prefix-Pool. There i=
s
> also a special code in the Framed-IPX-Network attribute that conveys it p=
ool
> like characteristics.
> * There is little that disallows a vendor from implementing just one name=
d
> pool for all protocols and all methods of assignment ( the Framed-Pool ap=
pears
> to have been envisaged for that ) and then using some implementation spec=
ific
> logic (eg parsing for a name) to figure out/how it=A1=AFs to be used.
> * The problem with relying on implementation specific features riding on
> standard Attributes, as opposed to say VSAs, is that nothing indicates to=
 the
> server/client if the recipient actually supports such special features an=
d
> assures correct interpretation. Eg if we used the Framed-Pool as the ONE =
named
> pool attribute, with a carried string =A1=B0IPv4=A1=B1, =A1=B0IPv6=A1=B1 or =A1=B0DHCPv6-PD=A1=B1=
, etc,
> parsed/whatever to indicate the role, it would be all doable, but a likel=
y
> mess should anything go wrong (eg a device not supporting some mode), wit=
hout
> clear indication of error.
>=20
> Since the Radius specification is NOT about specifying implementation the=
 only
> reliable/unambiguous manner in which different pools/methods can be utili=
zed
> would appear to be using different attributes as proposed in the current
> draft. Time (precedent) also appears to have proved this as a desirable
> protocol characteristic.
> Are there any other options/solutions available that do not call on impli=
cit
> features being there?
>=20
> Regards,
> Wojciech.
>=20
>=20
> On 26/07/2011 22:51, "Leaf yeh" <[e-mail]
> <http://[e-mail]> > wrote:
> [RM] NAS can have many pools configured locally: how does the NAS know wh=
ich
> pool is for SLAAC and which pool is for DHCPv6?
>=20
> =20
>=20
> I supposed the local configuration on the NAS will answer this question.
>=20
> =20
>=20
> Best Regards,
>=20
> Leaf
>=20
> =20
>=20
> =20
>=20
>=20
> =B7=A2=BC=FE=C8=CB: Maglione Roberta [[e-mail]
> <http://[e-mail]> ]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 3:54
> =B5=BD: Leaf yeh; 'Jacni Qin'
> Cc: [e-mail]
> <http://[e-mail]> ; [e-mail]=
f.org
> <http://[e-mail]> ; [e-mail]
> <http://[e-mail]> ; Qiujin; Wangshuxiang
> =D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rade=
xt
> session
>=20
>=20
> =20
>=20
>=20
> From: Leaf yeh [mailto:[e-mail]]
> Sent: marted=A8=AC 26 luglio 2011 21.50
> To: Maglione Roberta; 'Jacni Qin'
> Cc: [e-mail]
> <http://[e-mail]> ; [e-mail]=
f.org
> <http://[e-mail]> ; [e-mail]
> <http://[e-mail]> ; Qiujin; Wangshuxiang
> Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext
> session
>=20
>=20
> [RM] All the configured pools are the same for the NAS, in this case an e=
xtra
> logic would be needed to instruct the NAS about which pool is for SLAAC a=
nd
> which one is for DHCPv6
>=20
> =20
>=20
> The pools configured on the NAS are not necessary to be the same. AAA ser=
ver
> doesn't really need to instruct the NAS the specified type of pools, whic=
h is
> already configured on the NAS. Right?
>=20
> =20
>=20
> [RM] NAS can have many pools configured locally: how does the NAS know wh=
ich
> pool is for SLAAC and which pool is for DHCPv6?
>=20
> =20
>=20
> Roberta
>=20
> =20
>=20
> Best Regards,
>=20
> Leaf
>=20
> =20
>=20
> =20
>=20
> =20
>=20
>=20
> =B7=A2=BC=FE=C8=CB: Maglione Roberta [[e-mail]
> <http://[e-mail]> ]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:27
> =B5=BD: Leaf yeh; 'Jacni Qin'
> Cc: [e-mail]
> <http://[e-mail]> ; [e-mail]=
f.org
> <http://[e-mail]> ; [e-mail]
> <http://[e-mail]> ; Qiujin; Wangshuxiang
> =D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rade=
xt
> session
>=20
> Please see inline.
>=20
> Best regards,
> Roberta
>=20
>=20
> From: Leaf yeh [mailto:[e-mail]]
> Sent: marted=A8=AC 26 luglio 2011 20.22
> To: Maglione Roberta; 'Jacni Qin'
> Cc: [e-mail]
> <http://[e-mail]> ; [e-mail]=
f.org
> <http://[e-mail]> ; [e-mail]
> <http://[e-mail]> ; Qiujin; Wangshuxiang
> Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext
> session
>=20
>=20
> Roberta - If you use the same attribute for both scenarios how does the N=
AS
> know if that pool is for SLAAC or for Stateful DHCPv6?
>=20
> NAS already has those pool names in its configuration, right?
>=20
> [RM] yes pools are already configured in the NAS
>=20
> =20
>=20
> NAS does know which one is for SLAAC prefix pool, which one is for DHCPv6
> address pool.=20
>=20
> =20
>=20
> [RM] All the configured pools are the same for the NAS, in this case an e=
xtra
> logic would be needed to instruct the NAS about which pool is for SLAAC a=
nd
> which one is for DHCPv6
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> That=A1=AFs why in my opinion the Stateful-IPv6-Address-Pool is required.
>=20
> =20
>=20
> =20
>=20
> Best Regards,
>=20
> Leaf
>=20
> =20
>=20
> =20
>=20
>=20
> =B7=A2=BC=FE=C8=CB: Maglione Roberta [[e-mail]
> <http://[e-mail]> ]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:13
> =B5=BD: 'Jacni Qin'
> Cc: Leaf yeh; [e-mail]
> <http://[e-mail]> ; [e-mail]=
f.org
> <http://[e-mail]> ; [e-mail]
> <http://[e-mail]> ; Qiujin; Wangshuxiang
> =D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rade=
xt
> session
>=20
> 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?
>=20
> Thanks,
> Regards,
> Roberta
>=20
>=20
>=20
>=20
>=20
> ________________________________________
> From: Jacni Qin [mailto:[e-mail]]
> Sent: marted=A8=AC 26 luglio 2011 20.03
> To: Maglione Roberta
> Cc: Leaf yeh; [e-mail]
> <http://[e-mail]> ; [e-mail]=
f.org
> <http://[e-mail]> ; [e-mail]
> <http://[e-mail]> ; Qiujin; Wangshuxiang
> Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 r=
adext
> session
>=20
> Hi Roberta,
>=20
> I agree with you about the semantical logic, while
> "Stateful-IPv6-Address-Pool" is not necessary, IMHO.
>=20
>=20
> Cheers,
> Jacni
> On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta
> <[e-mail] <http://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,
>=20
> 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;
>=20
> 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 li=
sted
> above, you would also need to define a standard format/syntax for the poo=
l
> 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 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 e=
xtra
> 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.
>=20
>=20
> Thanks,
> Regards,
> Roberta
>=20
>=20
>=20
>=20
>=20
> ________________________________________
> From: [e-mail] <http://[e-mail]>
> [mailto:[e-mail]] On Behalf Of Leaf yeh
> Sent: luned=A8=AC 25 luglio 2011 18.23
> To: [e-mail]
> <http://[e-mail]> ; [e-mail]=
f.org
> <http://[e-mail]>
> Cc: [e-mail] <http://[e-mail]> ; Qiujin; Wangshuxiang
> Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radex=
t
> session
>=20
> Question for clarification:
>=20
> We already have the following Radius Attributes for the address/prefix po=
ols:
>=20
> Framed-Pool (88, section 5.18 of RFC2869),
> Framed-IPv6-Pool (100, section 2.6 of RFC3162).
>=20
> http://www.iana.org/assignments/radius-types/radius-types.xml
>=20
> The foramt are the same as follows:
>=20
> 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...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for
> address/prefix pools:
>=20
> Delegated-IPv6-Prefix-Pool,
> Stateful-IPv6-Address-Pool,
>=20
> the fomat of these 2 attributes are the same as the above one.
>=20
>=20
> Supposed the above attributes could be explained as follows:
>=20
> 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;
>=20
> All above attributes are only used to provide the name of the address/pre=
fix
> 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 ambiguit=
y. I
> guess 1 attribute for the name of the address/prefix pools might be enoug=
h. In
> fact, the NAS take the role to interpret the meaning of the pook name, ri=
ght?
>=20
> 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?
>=20
>=20
> Best Regards,
> Leaf
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> 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 =A8=A8 necessario.
>=20
>=20
> 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.
>=20
> 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.
>=20
> 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 =A8=A8 necessario.
>=20
> 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 =A8=A8 necessario.
>=20
>=20


--B_3396262154_11243562
Content-type: text/html;
	charset="GB2312"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext session</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Hello Leaf,<BR>
<BR>
If I understand it correctly, you&#8217;re proposing that the end user/host=
 types be enumerated as part of a new attribute, which would then drive the =
addressing behavior, eg selection of pools. If so, it looks very much as rel=
ying on the special NAS feature to interpret *the contents* of the attribute=
 as to the pools to be used, only this time with the contents being laid dow=
n as the enumerated type code points in a draft. This does not help given a)=
 past precedent in terms of Radius pool definitions (there are already 2 poo=
ls, and they are being used), nor b) give &nbsp;the operator an explicit ind=
ication regarding the use of a pool, rather than implicit. <BR>
Besides the above, as with any enumerated type, issues will start should th=
ere be another combination that someone comes up with or wants...<BR>
<BR>
Frankly, other than it being another way of doing things, I personally don&=
#8217;t see much of a benefit.<BR>
<BR>
Regards,<BR>
Woj.<BR>
<BR>
<BR>
On 15/08/2011 13:19, &quot;Leaf yeh&quot; &lt;<a href=3D"[e-mail]=
m">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>Wojciech - There is little that d=
isallows a vendor from implementing just one named pool for all protocols an=
d all methods of assignment ( the Framed-Pool appears to have been envisaged=
 for that ) and then using some implementation specific logic (eg parsing fo=
r a name) to figure out/how it&#8217;s to be used. <BR>
&nbsp;<BR>
I agree.<BR>
&nbsp;<BR>
Wojciech - Since the Radius specification is NOT about specifying implement=
ation the only reliable/unambiguous manner in which different pools/methods =
can be utilized would appear to be using different attributes as proposed in=
 the current draft. Are there any other options/solutions available that do =
not call on implicit features being there?<BR>
<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>A new attribute designed=
 to indicate the &#8216;User-Type&#8217; sounds a more straight manner and w=
ill have the potential extensibility to prevent this kind of ambiguity, whic=
h has been proposed in &nbsp;section 4.1 of draft-yeh-radext-dual-stack-acce=
ss-02.<BR>
&nbsp;<BR>
The &#8216;User-Type&#8217; can cover the following cases for both PPPoE an=
d IPoE access model by now.<BR>
&nbsp;<BR>
IPv4-only Host<BR>
IPv6-only Host(Numbered by SLAAC)<BR>
IPv6-only Host(Numbered by DHCPv6)<BR>
IPv6-only Customer Router(Unnumbered)<BR>
IPv6-only Customer Router(Numbered by SLAAC)<BR>
IPv6-only Customer Router(Numbered by DHCPv6)<BR>
Dual stack - IPv4 Host + IPv6 Host(Numbered by SLAAC)<BR>
Dual stack - IPv4 Host + IPv6 Host(Numbered by DHCPv6)<BR>
Dual stack - IPv4 Host + IPv6 Customer Router(Unnumbered)<BR>
Dual stack - IPv4 Host + IPv6 Customer Router(Numbered by SLAAC)<BR>
Dual stack - IPv4 Host + IPv6 Customer Router(Numbered by DHCPv6)<BR>
&nbsp;<BR>
Another usage (or design purpose) of &#8216;User-Type&#8217; is for the def=
ault behavior of the NAS. When the NAS has not received the pool-name attrib=
utes (Framed-Pool, Framed-IPv6-Pool, etc) from AAA server, it can directly a=
ssign the address/prefix from the default pools. <BR>
&nbsp;<BR>
Section 4.1 of draft-tan-v6ops-fast6-aaa-01 might give us a new reference.<=
BR>
&quot;User-Type&quot; attribute can simplify the way how BRAS determines th=
e user type. &nbsp;In addition, BRAS can allocate appropriate IP addresses f=
or the user even without the address pool attribute sent by RADIUS serve, if=
 default address pool is defined by BRAS.<BR>
&nbsp;<BR>
&nbsp;<BR>
Best Regards,<BR>
Leaf<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Bernard Abo=
ba [<a href=3D"mailto:[e-mail]">mailto:bernard_aboba@hotmail.=
com</a>] <BR>
<B>Sent:</B> Wednesday, August 03, 2011 6:48 AM<BR>
<B>To:</B> <a href=3D"[e-mail]">[e-mail]</a>; Leaf yeh; <a href=3D"=
[e-mail]">[e-mail]</a>; <a=
 href=3D"[e-mail]">[e-mail]</a><BR>
<B>Cc:</B> <a href=3D"[e-mail]">draft-iet=
[e-mail]</a>; <a href=3D"[e-mail]">ra=
[e-mail]</a>; <a href=3D"[e-mail]">[e-mail]</a=
>; Qiujin; Wangshuxiang<BR>
<B>Subject:</B> RE: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access aft=
er IETF81 radext session<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> <BR>
</SPAN><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>In general, the concern =
that has lead to defining these distinct pools is the possibility that multi=
ple pool types might be enabled for a single session. &nbsp;For example, it'=
s possible that an IPv6 address might be assigned from a pool, and at the sa=
me time that a Prefix might be delegated from a pool, for the same user and =
session. &nbsp;In such a situation, &nbsp;using the same pool name for multi=
ple purposes could be ambiguous and/or under-specified. &nbsp;<BR>
<BR>
A note about Woj's concern about errors. &nbsp;With respect to a server sen=
ding an attribute that a client does not understand, RFC 5080 Section 2.5 pr=
ovides guidance:<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'> &nbsp;&nbsp;In general, it is b=
est for a RADIUS client to err on the side of<BR>
&nbsp;&nbsp;&nbsp;caution. &nbsp;On receiving an Access-Accept including an=
 attribute of<BR>
&nbsp;&nbsp;&nbsp;known Type for an unimplemented service, a RADIUS client =
MUST treat<BR>
&nbsp;&nbsp;&nbsp;it as an Access-Reject, as directed in [RFC2865] Section =
1.1 &lt;<a href=3D"http://tools.ietf.org/html/rfc2865#section-1.1">http://tool=
s.ietf.org/html/rfc2865#section-1.1</a>&gt; . &nbsp;On<BR>
&nbsp;&nbsp;&nbsp;receiving an Access-Accept including an attribute of unkn=
own Type, a<BR>
&nbsp;&nbsp;&nbsp;RADIUS client SHOULD assume that it is a potential servic=
e<BR>
&nbsp;&nbsp;&nbsp;definition, and treat it as an Access-Reject. &nbsp;Unkno=
wn VSAs SHOULD be<BR>
&nbsp;&nbsp;&nbsp;ignored by RADIUS clients.<BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>As a result, it is possi=
ble that a client not implementing the IPv6 Access RFC will ignore the attri=
butes (e.g. not implement the SHOULD) rather than refusing to provide servic=
e. <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'>
</SPAN></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'><HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"100%"></SPAN></FONT></FONT=
>
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'>Date: Mon, 1 Aug 2011 12:47:38 -0400<BR>
Subject: Re: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF=
81 radext session<BR>
From: <a href=3D"[e-mail]">[e-mail]</a><BR>
To: <a href=3D"[e-mail]">[e-mail]</a>; <a href=3D"rob=
[e-mail]">[e-mail]</a>; <a hr=
ef=3D"[e-mail]">[e-mail]</a><BR>
CC: <a href=3D"[e-mail]">draft-ietf-radex=
[e-mail]</a>; <a href=3D"[e-mail]">radiusext=
@ops.ietf.org</a>; <a href=3D"[e-mail]">[e-mail]</a>; <a h=
ref=3D"[e-mail]">[e-mail]</a>; <a href=3D"wangshuxiang@huawei.=
com">[e-mail]</a><BR>
<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'>Hi All,<BR>
<BR>
Allow me to share some comments:<BR>
</SPAN></FONT><UL><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=
 STYLE=3D'font-size:11pt'>There is precedent of multiple &#8220;specific&#8221=
; named pools; Framed-Pool, Framed-IPv6-Pool, and the uncontested Delegated-=
IPv6-Prefix-Pool. There is also a special code in the Framed-IPX-Network att=
ribute that conveys it pool like characteristics.=20
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>There is little that disallows a vendor from implementin=
g just one named pool for all protocols and all methods of assignment ( the =
Framed-Pool appears to have been envisaged for that ) and then using some im=
plementation specific logic (eg parsing for a name) to figure out/how it&#82=
17;s to be used.=20
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>The problem with relying on implementation specific feat=
ures riding on standard Attributes, as opposed to say VSAs, is that nothing =
indicates to the server/client if the recipient actually supports such speci=
al features and assures correct interpretation. Eg if we used the Framed-Poo=
l as the ONE named pool attribute, with a carried string &#8220;IPv4&#8221;,=
 &#8220;IPv6&#8221; or &#8220;DHCPv6-PD&#8221;, etc, parsed/whatever to indi=
cate the role, it would be all doable, but a likely mess should anything go =
wrong (eg a device not supporting some mode), without clear indication of er=
ror.<BR>
</SPAN></FONT></UL><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN ST=
YLE=3D'font-size:11pt'><BR>
Since the Radius specification is NOT about specifying implementation the o=
nly reliable/unambiguous manner in which different pools/methods can be util=
ized would appear to be using different attributes as proposed in the curren=
t draft. Time (precedent) also appears to have proved this as a desirable pr=
otocol characteristic. <BR>
Are there any other options/solutions available that do not call on implici=
t features being there?<BR>
<BR>
Regards,<BR>
Wojciech.<BR>
<BR>
<BR>
On 26/07/2011 22:51, &quot;Leaf yeh&quot; &lt;<a href=3D"[e-mail]=
m">[e-mail]</a> &lt;<a href=3D"http://[e-mail]">http=
://[e-mail]</a>&gt; &gt; wrote:<BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>[RM] NAS can have many p=
ools configured locally: how does the NAS know which pool is for SLAAC and w=
hich pool is for DHCPv6?<BR>
<BR>
&nbsp;<BR>
<BR>
I supposed the local configuration on the NAS will answer this question.<BR=
>
<BR>
&nbsp;<BR>
<BR>
Best Regards,<BR>
<BR>
Leaf<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;
</SPAN></FONT></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'><HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"100%"></SPAN></FONT></FONT=
>
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
<B>=B7=A2=BC=FE=C8=CB:</B></SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> Maglione =
Roberta [<a href=3D"[e-mail]">roberta.maglione@teleco=
mitalia.it</a> &lt;<a href=3D"http://[e-mail]">http:/=
/[e-mail]</a>&gt; ]<BR>
<B>=B7=A2=CB=CD=CA=B1=BC=E4:</B> 2011=C4=EA7=D4=C227=C8=D5 3:54<BR>
<B>=B5=BD:</B> Leaf yeh; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[e-mail]">draft-iet=
[e-mail]</a> &lt;<a href=3D"http://draft-ietf-radex=
[e-mail]">http://[e-mail]=
f.org</a>&gt; ; <a href=3D"[e-mail]">[e-mail]</a> =
&lt;<a href=3D"http://[e-mail]">http://[e-mail]</a=
>&gt; ; <a href=3D"[e-mail]">[e-mail]</a> &lt;<a href=3D"htt=
p://[e-mail]">http://[e-mail]</a>&gt; ; Qiujin; Wangshux=
iang<BR>
<B>=D6=F7=CC=E2:</B> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext session<BR>
<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><BR>
&nbsp;
</SPAN></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT></FONT=
>
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Leaf yeh [<=
a href=3D"mailto:[e-mail]">mailto:[e-mail]</a>] <BR>
<B>Sent:</B> marted&igrave; 26 luglio 2011 21.50<BR>
<B>To:</B> Maglione Roberta; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[e-mail]">draft-iet=
[e-mail]</a> &lt;<a href=3D"http://draft-ietf-radex=
[e-mail]">http://[e-mail]=
f.org</a>&gt; ; <a href=3D"[e-mail]">[e-mail]</a> =
&lt;<a href=3D"http://[e-mail]">http://[e-mail]</a=
>&gt; ; <a href=3D"[e-mail]">[e-mail]</a> &lt;<a href=3D"htt=
p://[e-mail]">http://[e-mail]</a>&gt; ; Qiujin; Wangshux=
iang<BR>
<B>Subject:</B> =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after I=
ETF81 radext session<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><BR>
[RM] All the configured pools are the same for the NAS, in this case an ext=
ra logic would be needed to instruct the NAS about which pool is for SLAAC a=
nd which one is for DHCPv6<BR>
<BR>
&nbsp;<BR>
<BR>
The pools configured on the NAS are not necessary to be the same. AAA serve=
r doesn't really need to instruct the NAS the specified type of pools, which=
 is already configured on the NAS. Right?<BR>
<BR>
&nbsp;<BR>
<BR>
[RM] NAS can have many pools configured locally: how does the NAS know whic=
h pool is for SLAAC and which pool is for DHCPv6?<BR>
<BR>
&nbsp;<BR>
<BR>
Roberta<BR>
<BR>
&nbsp;<BR>
<BR>
Best Regards,<BR>
<BR>
Leaf<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;
</SPAN></FONT></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT></FONT=
>
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>=B7=A2=BC=FE=C8=CB:</B> Maglione =
Roberta [<a href=3D"[e-mail]">roberta.maglione@teleco=
mitalia.it</a> &lt;<a href=3D"http://[e-mail]">http:/=
/[e-mail]</a>&gt; ]<BR>
<B>=B7=A2=CB=CD=CA=B1=BC=E4:</B> 2011=C4=EA7=D4=C227=C8=D5 2:27<BR>
<B>=B5=BD:</B> Leaf yeh; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[e-mail]">draft-iet=
[e-mail]</a> &lt;<a href=3D"http://draft-ietf-radex=
[e-mail]">http://[e-mail]=
f.org</a>&gt; ; <a href=3D"[e-mail]">[e-mail]</a> =
&lt;<a href=3D"http://[e-mail]">http://[e-mail]</a=
>&gt; ; <a href=3D"[e-mail]">[e-mail]</a> &lt;<a href=3D"htt=
p://[e-mail]">http://[e-mail]</a>&gt; ; Qiujin; Wangshux=
iang<BR>
<B>=D6=F7=CC=E2:</B> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext session<BR>
<BR>
Please see inline.<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>Best regards,<BR>
Roberta<BR>

</SPAN></FONT></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT></FONT=
>
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'><B>From:</B> Leaf yeh [<a href=3D"mailto:[e-mail]=
m">mailto:[e-mail]</a>] <BR>
<B>Sent:</B> marted&igrave; 26 luglio 2011 20.22<BR>
<B>To:</B> Maglione Roberta; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[e-mail]">draft-iet=
[e-mail]</a> &lt;<a href=3D"http://draft-ietf-radex=
[e-mail]">http://[e-mail]=
f.org</a>&gt; ; <a href=3D"[e-mail]">[e-mail]</a> =
&lt;<a href=3D"http://[e-mail]">http://[e-mail]</a=
>&gt; ; <a href=3D"[e-mail]">[e-mail]</a> &lt;<a href=3D"htt=
p://[e-mail]">http://[e-mail]</a>&gt; ; Qiujin; Wangshux=
iang<BR>
<B>Subject:</B> =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after I=
ETF81 radext session<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><BR>
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?<BR>
<BR>
NAS already has those pool names in its configuration, right?<BR>
<BR>
[RM] yes pools are already configured in the NAS<BR>
<BR>
&nbsp;<BR>
<BR>
NAS does know which one is for SLAAC prefix pool, which one is for DHCPv6 a=
ddress pool. <BR>
<BR>
&nbsp;<BR>
<BR>
[RM] All the configured pools are the same for the NAS, in this case an ext=
ra logic would be needed to instruct the NAS about which pool is for SLAAC a=
nd which one is for DHCPv6<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
That&#8217;s why in my opinion the Stateful-IPv6-Address-Pool is required.<=
BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
Best Regards,<BR>
<BR>
Leaf<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;
</SPAN></FONT></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><FONT SIZE=3D"2"><SPAN STYLE=3D=
'font-size:10pt'><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT></FONT=
>
<P>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><B>=B7=A2=BC=FE=C8=CB:</B> Maglione =
Roberta [<a href=3D"[e-mail]">roberta.maglione@teleco=
mitalia.it</a> &lt;<a href=3D"http://[e-mail]">http:/=
/[e-mail]</a>&gt; ]<BR>
<B>=B7=A2=CB=CD=CA=B1=BC=E4:</B> 2011=C4=EA7=D4=C227=C8=D5 2:13<BR>
<B>=B5=BD:</B> 'Jacni Qin'<BR>
<B>Cc:</B> Leaf yeh; <a href=3D"[e-mail]"=
>[e-mail]</a> &lt;<a href=3D"http://draft-=
[e-mail]">http://draft-ietf-radext-ipv6-access=
@tools.ietf.org</a>&gt; ; <a href=3D"[e-mail]">[e-mail]=
f.org</a> &lt;<a href=3D"http://[e-mail]">http://radiusext@ops.i=
etf.org</a>&gt; ; <a href=3D"[e-mail]">[e-mail]</a> &lt;<a=
 href=3D"http://[e-mail]">http://[e-mail]</a>&gt; ; Qiujin=
; Wangshuxiang<BR>
<B>=D6=F7=CC=E2:</B> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext session<BR>
<BR>
Hi Jacni,<BR>
&nbsp;&nbsp;&nbsp;If you use the same attribute for both scenarios how does=
 the NAS know if that pool is for SLAAC or for Stateful DHCPv6?<BR>
<BR>
Thanks,<BR>
Regards,<BR>
Roberta<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
________________________________________<BR>
From: Jacni Qin [<a href=3D"mailto:[e-mail]">mailto:[e-mail]<=
/a>]<BR>
Sent: marted&igrave; 26 luglio 2011 20.03<BR>
To: Maglione Roberta<BR>
Cc: Leaf yeh; <a href=3D"[e-mail]">draft-=
[e-mail]</a> &lt;<a href=3D"http://draft-ietf-ra=
[e-mail]">http://draft-ietf-radext-ipv6-access@tools.=
ietf.org</a>&gt; ; <a href=3D"[e-mail]">[e-mail]</=
a> &lt;<a href=3D"http://[e-mail]">http://[e-mail]=
</a>&gt; ; <a href=3D"[e-mail]">[e-mail]</a> &lt;<a href=3D"=
http://[e-mail]">http://[e-mail]</a>&gt; ; Qiujin; Wangs=
huxiang<BR>
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad=
ext session<BR>
<BR>
Hi Roberta,<BR>
<BR>
I agree with you about the semantical logic, while &quot;Stateful-IPv6-Addr=
ess-Pool&quot; is not necessary, IMHO.<BR>
<BR>
<BR>
Cheers,<BR>
Jacni<BR>
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta &lt;<a href=3D"roberta.magl=
[e-mail]">[e-mail]</a> &lt;<a href=3D"ht=
tp://[e-mail]">http://roberta.maglione@telecomitali=
a.it</a>&gt; &gt; wrote:<BR>
Hello Leaf,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;The different attributes proposed in this draft for=
 the pools name have all the same format (a string), but semantically they a=
re different, as they coved different scenarios.<BR>
As you also summarized in your email below,<BR>
<BR>
Framed-Pool was designed for the IPv4 address pool;<BR>
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;<BR>
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;<BR>
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;<BR>
<BR>
So each attribute covers a different use-case/scenario and they can appear =
in the same RADIUS packet at the same time.<BR>
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 poo=
l name that allows the NAS to be able to disambiguate among the different sc=
enarios 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.<BR>
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 str=
ing, no limitation or special syntax is forced for the pool name.<BR>
<BR>
<BR>
Thanks,<BR>
Regards,<BR>
Roberta<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
________________________________________<BR>
From: <a href=3D"[e-mail]">[e-mail]</=
a> &lt;<a href=3D"http://[e-mail]">http://owner-radiusext@=
ops.ietf.org</a>&gt; &nbsp;[<a href=3D"mailto:[e-mail]">ma=
ilto:[e-mail]</a>] On Behalf Of Leaf yeh<BR>
Sent: luned&igrave; 25 luglio 2011 18.23<BR>
To: <a href=3D"[e-mail]">draft-ietf-radex=
[e-mail]</a> &lt;<a href=3D"http://draft-ietf-radext-ipv6-=
[e-mail]">http://[e-mail]</=
a>&gt; ; <a href=3D"[e-mail]">[e-mail]</a> &lt;<a =
href=3D"http://[e-mail]">http://[e-mail]</a>&gt; <=
BR>
Cc: <a href=3D"[e-mail]">[e-mail]</a> &lt;<a href=3D"http:/=
/[e-mail]">http://[e-mail]</a>&gt; ; Qiujin; Wangshuxian=
g<BR>
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext =
session<BR>
<BR>
Question for clarification:<BR>
<BR>
We already have the following Radius Attributes for the address/prefix pool=
s:<BR>
<BR>
Framed-Pool (88, section 5.18 of RFC2869),<BR>
Framed-IPv6-Pool (100, section 2.6 of RFC3162).<BR>
<BR>
<a href=3D"http://www.iana.org/assignments/radius-types/radius-types.xml">htt=
p://www.iana.org/assignments/radius-types/radius-types.xml</a><BR>
<BR>
The foramt are the same as follows:<BR>
<BR>
0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2<BR>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3<BR>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>
| &nbsp;&nbsp;&nbsp;&nbsp;Type &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;=
&nbsp;Length &nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;&nbsp;&nbsp;String...<BR>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>
<BR>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/=
prefix pools:<BR>
<BR>
Delegated-IPv6-Prefix-Pool,<BR>
Stateful-IPv6-Address-Pool,<BR>
<BR>
the fomat of these 2 attributes are the same as the above one.<BR>
<BR>
<BR>
Supposed the above attributes could be explained as follows:<BR>
<BR>
Framed-Pool was designed for the IPv4 address pool;<BR>
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;<BR>
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;<BR>
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;<BR>
<BR>
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 'stri=
ng' attributes for the different address/prefix pools to prevent the ambigui=
ty. I guess 1 attribute for the name of the address/prefix pools might be en=
ough. In fact, the NAS take the role to interpret the meaning of the pook na=
me, right?<BR>
<BR>
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=
?<BR>
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 pre=
fix/address pool per the same logic. Am I right?<BR>
<BR>
<BR>
Best Regards,<BR>
Leaf<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
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 rigorosamente vietate. Qualora abbia=
te ricevuto questo documento per errore siete cortesemente pregati di darne =
immediata comunicazione al mittente e di provvedere alla sua distruzione, Gr=
azie.<BR>
This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, prin=
ting or use by anybody else is unauthorised. If you are not the intended rec=
ipient, please delete this message and any attachments and advise the sender=
 by return e-mail, Thanks.<BR>
Rispetta l'ambiente. Non stampare questa mail se non &egrave; necessario.<B=
R>
<BR>
<BR>
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 rigorosamente vietate. Qualora abbia=
te ricevuto questo documento per errore siete cortesemente pregati di darne =
immediata comunicazione al mittente e di provvedere alla sua distruzione, Gr=
azie.<BR>
<BR>
This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, prin=
ting or use by anybody else is unauthorised. If you are not the intended rec=
ipient, please delete this message and any attachments and advise the sender=
 by return e-mail, Thanks.<BR>
<BR>
</SPAN></FONT><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:7pt'>Questo messaggio e=
 i suoi allegati sono indirizzati esclusivamente alle persone indicate. La d=
iffusione, copia o qualsiasi altra azione derivante dalla conoscenza di ques=
te informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo =
documento per errore siete cortesemente pregati di darne immediata comunicaz=
ione al mittente e di provvedere alla sua distruzione, Grazie. <BR>
<I>This e-mail and any attachments is confidential and may contain privileg=
ed information intended for the addressee(s) only. Dissemination, copying, p=
rinting or use by anybody else is unauthorised. If you are not the intended =
recipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.</I></SPAN><SPAN STYLE=3D'font-size:9pt'> </SPAN>=
<SPAN STYLE=3D'font-size:7pt'><B>Rispetta l'ambiente. Non stampare questa mail=
 se non &egrave; necessario.</B></SPAN><SPAN STYLE=3D'font-size:9pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'><BR>
</SPAN><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:7pt'>Questo messaggio e i suoi=
 allegati sono indirizzati esclusivamente alle persone indicate. La diffusio=
ne, copia o qualsiasi altra azione derivante dalla conoscenza di queste info=
rmazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documen=
to per errore siete cortesemente pregati di darne immediata comunicazione al=
 mittente e di provvedere alla sua distruzione, Grazie. <BR>
<I>This e-mail and any attachments is confidential and may contain privileg=
ed information intended for the addressee(s) only. Dissemination, copying, p=
rinting or use by anybody else is unauthorised. If you are not the intended =
recipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.</I></SPAN><SPAN STYLE=3D'font-size:9pt'> </SPAN>=
<SPAN STYLE=3D'font-size:7pt'><B>Rispetta l'ambiente. Non stampare questa mail=
 se non &egrave; necessario.</B></SPAN><SPAN STYLE=3D'font-size:9pt'> <BR>
<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3396262154_11243562--


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 15 Aug 2011 11:44:52 +0000
Date: Mon, 15 Aug 2011 11:43:31 +0000 (UTC)
From: "David B. Nelson" <[e-mail]>
To: Leaf yeh <[e-mail]>
Cc: [e-mail], [e-mail],  fine sz <[e-mail]>, Qiujin <[e-mail]>,  Wangshuxiang <[e-mail]>,  [e-mail], [e-mail],  roberta maglione <[e-mail]>,  [e-mail], Bernard Aboba <[e-mail]>
Message-ID: <[e-mail]>
Subject: =?utf-8?Q?Re:_=E7=AD=94=E5=A4=8D:_Q_on_Ver.-05_of_draft-ietf-radex?= =?utf-8?Q?t-ipv6-access_after_IETF81_radext_session?=
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

> The =E2=80=98User-Type=E2=80=99 can cover the following cases for both
> PPPoE and IPoE access model by now.

The proposed values for this attribute seem to describe properties of the a=
ttached host.  In RADIUS, the term "user" refers to a human, for whom accou=
nt and service provisioning has been established.  I would suggest calling =
this proposed attribute something else, more accurately descriptive.=20

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 15 Aug 2011 11:20:49 +0000
Date: Mon, 15 Aug 2011 11:19:20 +0000
From: Leaf yeh <[e-mail]>
Subject: =?utf-8?B?UkU6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0?= =?utf-8?Q?-ipv6-access_after_IETF81_radext_session?=
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Bernard Aboba <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Qiujin <[e-mail]>, Wangshuxiang <[e-mail]>, "[e-mail]" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_5sIeYiGktUaGsI5b0WMdKQ)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: =?utf-8?B?562U5aSNOiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2?= =?utf-8?Q?6-access_after_IETF81_radext_session?=
Thread-index: AcxK5yu3GGjTmDXYQN+8DXe4n1z3TwA1YP+A//99JICAAALPAIAAhpWC///+E3v///vpIIAAHSBY///8hsP///hb8P//4L6o///A+qL/9rzAo//ro/OA/8mB5lA=

--Boundary_(ID_5sIeYiGktUaGsI5b0WMdKQ)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: base64

V29qY2llY2ggLSBUaGVyZSBpcyBsaXR0bGUgdGhhdCBkaXNhbGxvd3MgYSB2ZW5kb3IgZnJvbSBp
bXBsZW1lbnRpbmcganVzdCBvbmUgbmFtZWQgcG9vbCBmb3IgYWxsIHByb3RvY29scyBhbmQgYWxs
IG1ldGhvZHMgb2YgYXNzaWdubWVudCAoIHRoZSBGcmFtZWQtUG9vbCBhcHBlYXJzIHRvIGhhdmUg
YmVlbiBlbnZpc2FnZWQgZm9yIHRoYXQgKSBhbmQgdGhlbiB1c2luZyBzb21lIGltcGxlbWVudGF0
aW9uIHNwZWNpZmljIGxvZ2ljIChlZyBwYXJzaW5nIGZvciBhIG5hbWUpIHRvIGZpZ3VyZSBvdXQv
aG93IGl04oCZcyB0byBiZSB1c2VkLg0KDQpJIGFncmVlLg0KDQpXb2pjaWVjaCAtIFNpbmNlIHRo
ZSBSYWRpdXMgc3BlY2lmaWNhdGlvbiBpcyBOT1QgYWJvdXQgc3BlY2lmeWluZyBpbXBsZW1lbnRh
dGlvbiB0aGUgb25seSByZWxpYWJsZS91bmFtYmlndW91cyBtYW5uZXIgaW4gd2hpY2ggZGlmZmVy
ZW50IHBvb2xzL21ldGhvZHMgY2FuIGJlIHV0aWxpemVkIHdvdWxkIGFwcGVhciB0byBiZSB1c2lu
ZyBkaWZmZXJlbnQgYXR0cmlidXRlcyBhcyBwcm9wb3NlZCBpbiB0aGUgY3VycmVudCBkcmFmdC4g
QXJlIHRoZXJlIGFueSBvdGhlciBvcHRpb25zL3NvbHV0aW9ucyBhdmFpbGFibGUgdGhhdCBkbyBu
b3QgY2FsbCBvbiBpbXBsaWNpdCBmZWF0dXJlcyBiZWluZyB0aGVyZT8NCg0KQSBuZXcgYXR0cmli
dXRlIGRlc2lnbmVkIHRvIGluZGljYXRlIHRoZSDigJhVc2VyLVR5cGXigJkgc291bmRzIGEgbW9y
ZSBzdHJhaWdodCBtYW5uZXIgYW5kIHdpbGwgaGF2ZSB0aGUgcG90ZW50aWFsIGV4dGVuc2liaWxp
dHkgdG8gcHJldmVudCB0aGlzIGtpbmQgb2YgYW1iaWd1aXR5LCB3aGljaCBoYXMgYmVlbiBwcm9w
b3NlZCBpbiAgc2VjdGlvbiA0LjEgb2YgZHJhZnQteWVoLXJhZGV4dC1kdWFsLXN0YWNrLWFjY2Vz
cy0wMi4NCg0KVGhlIOKAmFVzZXItVHlwZeKAmSBjYW4gY292ZXIgdGhlIGZvbGxvd2luZyBjYXNl
cyBmb3IgYm90aCBQUFBvRSBhbmQgSVBvRSBhY2Nlc3MgbW9kZWwgYnkgbm93Lg0KDQpJUHY0LW9u
bHkgSG9zdA0KSVB2Ni1vbmx5IEhvc3QoTnVtYmVyZWQgYnkgU0xBQUMpDQpJUHY2LW9ubHkgSG9z
dChOdW1iZXJlZCBieSBESENQdjYpDQpJUHY2LW9ubHkgQ3VzdG9tZXIgUm91dGVyKFVubnVtYmVy
ZWQpDQpJUHY2LW9ubHkgQ3VzdG9tZXIgUm91dGVyKE51bWJlcmVkIGJ5IFNMQUFDKQ0KSVB2Ni1v
bmx5IEN1c3RvbWVyIFJvdXRlcihOdW1iZXJlZCBieSBESENQdjYpDQpEdWFsIHN0YWNrIC0gSVB2
NCBIb3N0ICsgSVB2NiBIb3N0KE51bWJlcmVkIGJ5IFNMQUFDKQ0KRHVhbCBzdGFjayAtIElQdjQg
SG9zdCArIElQdjYgSG9zdChOdW1iZXJlZCBieSBESENQdjYpDQpEdWFsIHN0YWNrIC0gSVB2NCBI
b3N0ICsgSVB2NiBDdXN0b21lciBSb3V0ZXIoVW5udW1iZXJlZCkNCkR1YWwgc3RhY2sgLSBJUHY0
IEhvc3QgKyBJUHY2IEN1c3RvbWVyIFJvdXRlcihOdW1iZXJlZCBieSBTTEFBQykNCkR1YWwgc3Rh
Y2sgLSBJUHY0IEhvc3QgKyBJUHY2IEN1c3RvbWVyIFJvdXRlcihOdW1iZXJlZCBieSBESENQdjYp
DQoNCkFub3RoZXIgdXNhZ2UgKG9yIGRlc2lnbiBwdXJwb3NlKSBvZiDigJhVc2VyLVR5cGXigJkg
aXMgZm9yIHRoZSBkZWZhdWx0IGJlaGF2aW9yIG9mIHRoZSBOQVMuIFdoZW4gdGhlIE5BUyBoYXMg
bm90IHJlY2VpdmVkIHRoZSBwb29sLW5hbWUgYXR0cmlidXRlcyAoRnJhbWVkLVBvb2wsIEZyYW1l
ZC1JUHY2LVBvb2wsIGV0YykgZnJvbSBBQUEgc2VydmVyLCBpdCBjYW4gZGlyZWN0bHkgYXNzaWdu
IHRoZSBhZGRyZXNzL3ByZWZpeCBmcm9tIHRoZSBkZWZhdWx0IHBvb2xzLg0KDQpTZWN0aW9uIDQu
MSBvZiBkcmFmdC10YW4tdjZvcHMtZmFzdDYtYWFhLTAxIG1pZ2h0IGdpdmUgdXMgYSBuZXcgcmVm
ZXJlbmNlLg0KIlVzZXItVHlwZSIgYXR0cmlidXRlIGNhbiBzaW1wbGlmeSB0aGUgd2F5IGhvdyBC
UkFTIGRldGVybWluZXMgdGhlIHVzZXIgdHlwZS4gIEluIGFkZGl0aW9uLCBCUkFTIGNhbiBhbGxv
Y2F0ZSBhcHByb3ByaWF0ZSBJUCBhZGRyZXNzZXMgZm9yIHRoZSB1c2VyIGV2ZW4gd2l0aG91dCB0
aGUgYWRkcmVzcyBwb29sIGF0dHJpYnV0ZSBzZW50IGJ5IFJBRElVUyBzZXJ2ZSwgaWYgZGVmYXVs
dCBhZGRyZXNzIHBvb2wgaXMgZGVmaW5lZCBieSBCUkFTLg0KDQoNCkJlc3QgUmVnYXJkcywNCkxl
YWYNCg0KDQoNCkZyb206IEJlcm5hcmQgQWJvYmEgW21haWx0bzpiZXJuYXJkX2Fib2JhQGhvdG1h
aWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMDMsIDIwMTEgNjo0OCBBTQ0KVG86IHdk
ZWNAY2lzY28uY29tOyBMZWFmIHllaDsgcm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0
OyBqYWNuaXFAZ21haWwuY29tDQpDYzogZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3NAdG9v
bHMuaWV0Zi5vcmc7IHJhZGl1c2V4dEBvcHMuaWV0Zi5vcmc7IGZpbmVfc3pAaHVhd2VpLmNvbTsg
UWl1amluOyBXYW5nc2h1eGlhbmcNClN1YmplY3Q6IFJFOiDnrZTlpI06IFEgb24gVmVyLi0wNSBv
ZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2VzcyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Np
b24NCg0KSW4gZ2VuZXJhbCwgdGhlIGNvbmNlcm4gdGhhdCBoYXMgbGVhZCB0byBkZWZpbmluZyB0
aGVzZSBkaXN0aW5jdCBwb29scyBpcyB0aGUgcG9zc2liaWxpdHkgdGhhdCBtdWx0aXBsZSBwb29s
IHR5cGVzIG1pZ2h0IGJlIGVuYWJsZWQgZm9yIGEgc2luZ2xlIHNlc3Npb24uICBGb3IgZXhhbXBs
ZSwgaXQncyBwb3NzaWJsZSB0aGF0IGFuIElQdjYgYWRkcmVzcyBtaWdodCBiZSBhc3NpZ25lZCBm
cm9tIGEgcG9vbCwgYW5kIGF0IHRoZSBzYW1lIHRpbWUgdGhhdCBhIFByZWZpeCBtaWdodCBiZSBk
ZWxlZ2F0ZWQgZnJvbSBhIHBvb2wsIGZvciB0aGUgc2FtZSB1c2VyIGFuZCBzZXNzaW9uLiAgSW4g
c3VjaCBhIHNpdHVhdGlvbiwgIHVzaW5nIHRoZSBzYW1lIHBvb2wgbmFtZSBmb3IgbXVsdGlwbGUg
cHVycG9zZXMgY291bGQgYmUgYW1iaWd1b3VzIGFuZC9vciB1bmRlci1zcGVjaWZpZWQuDQoNCkEg
bm90ZSBhYm91dCBXb2oncyBjb25jZXJuIGFib3V0IGVycm9ycy4gIFdpdGggcmVzcGVjdCB0byBh
IHNlcnZlciBzZW5kaW5nIGFuIGF0dHJpYnV0ZSB0aGF0IGEgY2xpZW50IGRvZXMgbm90IHVuZGVy
c3RhbmQsIFJGQyA1MDgwIFNlY3Rpb24gMi41IHByb3ZpZGVzIGd1aWRhbmNlOg0KDQogICBJbiBn
ZW5lcmFsLCBpdCBpcyBiZXN0IGZvciBhIFJBRElVUyBjbGllbnQgdG8gZXJyIG9uIHRoZSBzaWRl
IG9mDQoNCiAgIGNhdXRpb24uICBPbiByZWNlaXZpbmcgYW4gQWNjZXNzLUFjY2VwdCBpbmNsdWRp
bmcgYW4gYXR0cmlidXRlIG9mDQoNCiAgIGtub3duIFR5cGUgZm9yIGFuIHVuaW1wbGVtZW50ZWQg
c2VydmljZSwgYSBSQURJVVMgY2xpZW50IE1VU1QgdHJlYXQNCg0KICAgaXQgYXMgYW4gQWNjZXNz
LVJlamVjdCwgYXMgZGlyZWN0ZWQgaW4gW1JGQzI4NjVdIFNlY3Rpb24gMS4xPGh0dHA6Ly90b29s
cy5pZXRmLm9yZy9odG1sL3JmYzI4NjUjc2VjdGlvbi0xLjE+LiAgT24NCg0KICAgcmVjZWl2aW5n
IGFuIEFjY2Vzcy1BY2NlcHQgaW5jbHVkaW5nIGFuIGF0dHJpYnV0ZSBvZiB1bmtub3duIFR5cGUs
IGENCg0KICAgUkFESVVTIGNsaWVudCBTSE9VTEQgYXNzdW1lIHRoYXQgaXQgaXMgYSBwb3RlbnRp
YWwgc2VydmljZQ0KDQogICBkZWZpbml0aW9uLCBhbmQgdHJlYXQgaXQgYXMgYW4gQWNjZXNzLVJl
amVjdC4gIFVua25vd24gVlNBcyBTSE9VTEQgYmUNCg0KICAgaWdub3JlZCBieSBSQURJVVMgY2xp
ZW50cy4NCkFzIGEgcmVzdWx0LCBpdCBpcyBwb3NzaWJsZSB0aGF0IGEgY2xpZW50IG5vdCBpbXBs
ZW1lbnRpbmcgdGhlIElQdjYgQWNjZXNzIFJGQyB3aWxsIGlnbm9yZSB0aGUgYXR0cmlidXRlcyAo
ZS5nLiBub3QgaW1wbGVtZW50IHRoZSBTSE9VTEQpIHJhdGhlciB0aGFuIHJlZnVzaW5nIHRvIHBy
b3ZpZGUgc2VydmljZS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEYXRlOiBN
b24sIDEgQXVnIDIwMTEgMTI6NDc6MzggLTA0MDANClN1YmplY3Q6IFJlOiDnrZTlpI06IFEgb24g
VmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2VzcyBhZnRlciBJRVRGODEgcmFk
ZXh0IHNlc3Npb24NCkZyb206IHdkZWNAY2lzY28uY29tDQpUbzogbGVhZi55LnllaEBodWF3ZWku
Y29tOyByb2JlcnRhLm1hZ2xpb25lQHRlbGVjb21pdGFsaWEuaXQ7IGphY25pcUBnbWFpbC5jb20N
CkNDOiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzsgcmFkaXVz
ZXh0QG9wcy5pZXRmLm9yZzsgZmluZV9zekBodWF3ZWkuY29tOyBxaXVqaW5AaHVhd2VpLmNvbTsg
d2FuZ3NodXhpYW5nQGh1YXdlaS5jb20NCg0KSGkgQWxsLA0KDQpBbGxvdyBtZSB0byBzaGFyZSBz
b21lIGNvbW1lbnRzOg0KDQogICogICBUaGVyZSBpcyBwcmVjZWRlbnQgb2YgbXVsdGlwbGUg4oCc
c3BlY2lmaWPigJ0gbmFtZWQgcG9vbHM7IEZyYW1lZC1Qb29sLCBGcmFtZWQtSVB2Ni1Qb29sLCBh
bmQgdGhlIHVuY29udGVzdGVkIERlbGVnYXRlZC1JUHY2LVByZWZpeC1Qb29sLiBUaGVyZSBpcyBh
bHNvIGEgc3BlY2lhbCBjb2RlIGluIHRoZSBGcmFtZWQtSVBYLU5ldHdvcmsgYXR0cmlidXRlIHRo
YXQgY29udmV5cyBpdCBwb29sIGxpa2UgY2hhcmFjdGVyaXN0aWNzLg0KICAqICAgVGhlcmUgaXMg
bGl0dGxlIHRoYXQgZGlzYWxsb3dzIGEgdmVuZG9yIGZyb20gaW1wbGVtZW50aW5nIGp1c3Qgb25l
IG5hbWVkIHBvb2wgZm9yIGFsbCBwcm90b2NvbHMgYW5kIGFsbCBtZXRob2RzIG9mIGFzc2lnbm1l
bnQgKCB0aGUgRnJhbWVkLVBvb2wgYXBwZWFycyB0byBoYXZlIGJlZW4gZW52aXNhZ2VkIGZvciB0
aGF0ICkgYW5kIHRoZW4gdXNpbmcgc29tZSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBsb2dpYyAo
ZWcgcGFyc2luZyBmb3IgYSBuYW1lKSB0byBmaWd1cmUgb3V0L2hvdyBpdOKAmXMgdG8gYmUgdXNl
ZC4NCiAgKiAgIFRoZSBwcm9ibGVtIHdpdGggcmVseWluZyBvbiBpbXBsZW1lbnRhdGlvbiBzcGVj
aWZpYyBmZWF0dXJlcyByaWRpbmcgb24gc3RhbmRhcmQgQXR0cmlidXRlcywgYXMgb3Bwb3NlZCB0
byBzYXkgVlNBcywgaXMgdGhhdCBub3RoaW5nIGluZGljYXRlcyB0byB0aGUgc2VydmVyL2NsaWVu
dCBpZiB0aGUgcmVjaXBpZW50IGFjdHVhbGx5IHN1cHBvcnRzIHN1Y2ggc3BlY2lhbCBmZWF0dXJl
cyBhbmQgYXNzdXJlcyBjb3JyZWN0IGludGVycHJldGF0aW9uLiBFZyBpZiB3ZSB1c2VkIHRoZSBG
cmFtZWQtUG9vbCBhcyB0aGUgT05FIG5hbWVkIHBvb2wgYXR0cmlidXRlLCB3aXRoIGEgY2Fycmll
ZCBzdHJpbmcg4oCcSVB2NOKAnSwg4oCcSVB2NuKAnSBvciDigJxESENQdjYtUETigJ0sIGV0Yywg
cGFyc2VkL3doYXRldmVyIHRvIGluZGljYXRlIHRoZSByb2xlLCBpdCB3b3VsZCBiZSBhbGwgZG9h
YmxlLCBidXQgYSBsaWtlbHkgbWVzcyBzaG91bGQgYW55dGhpbmcgZ28gd3JvbmcgKGVnIGEgZGV2
aWNlIG5vdCBzdXBwb3J0aW5nIHNvbWUgbW9kZSksIHdpdGhvdXQgY2xlYXIgaW5kaWNhdGlvbiBv
ZiBlcnJvci4NCg0KU2luY2UgdGhlIFJhZGl1cyBzcGVjaWZpY2F0aW9uIGlzIE5PVCBhYm91dCBz
cGVjaWZ5aW5nIGltcGxlbWVudGF0aW9uIHRoZSBvbmx5IHJlbGlhYmxlL3VuYW1iaWd1b3VzIG1h
bm5lciBpbiB3aGljaCBkaWZmZXJlbnQgcG9vbHMvbWV0aG9kcyBjYW4gYmUgdXRpbGl6ZWQgd291
bGQgYXBwZWFyIHRvIGJlIHVzaW5nIGRpZmZlcmVudCBhdHRyaWJ1dGVzIGFzIHByb3Bvc2VkIGlu
IHRoZSBjdXJyZW50IGRyYWZ0LiBUaW1lIChwcmVjZWRlbnQpIGFsc28gYXBwZWFycyB0byBoYXZl
IHByb3ZlZCB0aGlzIGFzIGEgZGVzaXJhYmxlIHByb3RvY29sIGNoYXJhY3RlcmlzdGljLg0KQXJl
IHRoZXJlIGFueSBvdGhlciBvcHRpb25zL3NvbHV0aW9ucyBhdmFpbGFibGUgdGhhdCBkbyBub3Qg
Y2FsbCBvbiBpbXBsaWNpdCBmZWF0dXJlcyBiZWluZyB0aGVyZT8NCg0KUmVnYXJkcywNCldvamNp
ZWNoLg0KDQoNCk9uIDI2LzA3LzIwMTEgMjI6NTEsICJMZWFmIHllaCIgPGxlYWYueS55ZWhAaHVh
d2VpLmNvbTxodHRwOi8vbGVhZi55LnllaEBodWF3ZWkuY29tPj4gd3JvdGU6DQpbUk1dIE5BUyBj
YW4gaGF2ZSBtYW55IHBvb2xzIGNvbmZpZ3VyZWQgbG9jYWxseTogaG93IGRvZXMgdGhlIE5BUyBr
bm93IHdoaWNoIHBvb2wgaXMgZm9yIFNMQUFDIGFuZCB3aGljaCBwb29sIGlzIGZvciBESENQdjY/
DQoNCg0KDQpJIHN1cHBvc2VkIHRoZSBsb2NhbCBjb25maWd1cmF0aW9uIG9uIHRoZSBOQVMgd2ls
bCBhbnN3ZXIgdGhpcyBxdWVzdGlvbi4NCg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KTGVhZg0KDQoN
Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K5Y+R5Lu25Lq6OiBNYWdsaW9u
ZSBSb2JlcnRhIFtyb2JlcnRhLm1hZ2xpb25lQHRlbGVjb21pdGFsaWEuaXQ8aHR0cDovL3JvYmVy
dGEubWFnbGlvbmVAdGVsZWNvbWl0YWxpYS5pdD5dDQrlj5HpgIHml7bpl7Q6IDIwMTHlubQ35pyI
Mjfml6UgMzo1NA0K5YiwOiBMZWFmIHllaDsgJ0phY25pIFFpbicNCkNjOiBkcmFmdC1pZXRmLXJh
ZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzxodHRwOi8vZHJhZnQtaWV0Zi1yYWRleHQt
aXB2Ni1hY2Nlc3NAdG9vbHMuaWV0Zi5vcmc+OyByYWRpdXNleHRAb3BzLmlldGYub3JnPGh0dHA6
Ly9yYWRpdXNleHRAb3BzLmlldGYub3JnPjsgZmluZV9zekBodWF3ZWkuY29tPGh0dHA6Ly9maW5l
X3N6QGh1YXdlaS5jb20+OyBRaXVqaW47IFdhbmdzaHV4aWFuZw0K5Li76aKYOiBSRTogUSBvbiBW
ZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRl
eHQgc2Vzc2lvbg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206
IExlYWYgeWVoIFttYWlsdG86bGVhZi55LnllaEBodWF3ZWkuY29tXQ0KU2VudDogbWFydGVkw6wg
MjYgbHVnbGlvIDIwMTEgMjEuNTANClRvOiBNYWdsaW9uZSBSb2JlcnRhOyAnSmFjbmkgUWluJw0K
Q2M6IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnPGh0dHA6Ly9k
cmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZz47IHJhZGl1c2V4dEBv
cHMuaWV0Zi5vcmc8aHR0cDovL3JhZGl1c2V4dEBvcHMuaWV0Zi5vcmc+OyBmaW5lX3N6QGh1YXdl
aS5jb208aHR0cDovL2ZpbmVfc3pAaHVhd2VpLmNvbT47IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpT
dWJqZWN0OiDnrZTlpI06IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFj
Y2VzcyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb24NCg0KDQpbUk1dIEFsbCB0aGUgY29uZmln
dXJlZCBwb29scyBhcmUgdGhlIHNhbWUgZm9yIHRoZSBOQVMsIGluIHRoaXMgY2FzZSBhbiBleHRy
YSBsb2dpYyB3b3VsZCBiZSBuZWVkZWQgdG8gaW5zdHJ1Y3QgdGhlIE5BUyBhYm91dCB3aGljaCBw
b29sIGlzIGZvciBTTEFBQyBhbmQgd2hpY2ggb25lIGlzIGZvciBESENQdjYNCg0KDQoNClRoZSBw
b29scyBjb25maWd1cmVkIG9uIHRoZSBOQVMgYXJlIG5vdCBuZWNlc3NhcnkgdG8gYmUgdGhlIHNh
bWUuIEFBQSBzZXJ2ZXIgZG9lc24ndCByZWFsbHkgbmVlZCB0byBpbnN0cnVjdCB0aGUgTkFTIHRo
ZSBzcGVjaWZpZWQgdHlwZSBvZiBwb29scywgd2hpY2ggaXMgYWxyZWFkeSBjb25maWd1cmVkIG9u
IHRoZSBOQVMuIFJpZ2h0Pw0KDQoNCg0KW1JNXSBOQVMgY2FuIGhhdmUgbWFueSBwb29scyBjb25m
aWd1cmVkIGxvY2FsbHk6IGhvdyBkb2VzIHRoZSBOQVMga25vdyB3aGljaCBwb29sIGlzIGZvciBT
TEFBQyBhbmQgd2hpY2ggcG9vbCBpcyBmb3IgREhDUHY2Pw0KDQoNCg0KUm9iZXJ0YQ0KDQoNCg0K
QmVzdCBSZWdhcmRzLA0KDQpMZWFmDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0K5Y+R5Lu25Lq6OiBNYWdsaW9uZSBSb2JlcnRhIFtyb2JlcnRhLm1hZ2xpb25l
QHRlbGVjb21pdGFsaWEuaXQ8aHR0cDovL3JvYmVydGEubWFnbGlvbmVAdGVsZWNvbWl0YWxpYS5p
dD5dDQrlj5HpgIHml7bpl7Q6IDIwMTHlubQ35pyIMjfml6UgMjoyNw0K5YiwOiBMZWFmIHllaDsg
J0phY25pIFFpbicNCkNjOiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRm
Lm9yZzxodHRwOi8vZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3NAdG9vbHMuaWV0Zi5vcmc+
OyByYWRpdXNleHRAb3BzLmlldGYub3JnPGh0dHA6Ly9yYWRpdXNleHRAb3BzLmlldGYub3JnPjsg
ZmluZV9zekBodWF3ZWkuY29tPGh0dHA6Ly9maW5lX3N6QGh1YXdlaS5jb20+OyBRaXVqaW47IFdh
bmdzaHV4aWFuZw0K5Li76aKYOiBSRTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWlldGYtcmFkZXh0
LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KDQpQbGVhc2Ugc2VlIGlu
bGluZS4NCg0KQmVzdCByZWdhcmRzLA0KUm9iZXJ0YQ0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KRnJvbTogTGVhZiB5ZWggW21haWx0bzpsZWFmLnkueWVoQGh1YXdlaS5jb21d
DQpTZW50OiBtYXJ0ZWTDrCAyNiBsdWdsaW8gMjAxMSAyMC4yMg0KVG86IE1hZ2xpb25lIFJvYmVy
dGE7ICdKYWNuaSBRaW4nDQpDYzogZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3NAdG9vbHMu
aWV0Zi5vcmc8aHR0cDovL2RyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYu
b3JnPjsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZzxodHRwOi8vcmFkaXVzZXh0QG9wcy5pZXRmLm9y
Zz47IGZpbmVfc3pAaHVhd2VpLmNvbTxodHRwOi8vZmluZV9zekBodWF3ZWkuY29tPjsgUWl1amlu
OyBXYW5nc2h1eGlhbmcNClN1YmplY3Q6IOetlOWkjTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0LWll
dGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KDQoNClJv
YmVydGEgLSBJZiB5b3UgdXNlIHRoZSBzYW1lIGF0dHJpYnV0ZSBmb3IgYm90aCBzY2VuYXJpb3Mg
aG93IGRvZXMgdGhlIE5BUyBrbm93IGlmIHRoYXQgcG9vbCBpcyBmb3IgU0xBQUMgb3IgZm9yIFN0
YXRlZnVsIERIQ1B2Nj8NCg0KTkFTIGFscmVhZHkgaGFzIHRob3NlIHBvb2wgbmFtZXMgaW4gaXRz
IGNvbmZpZ3VyYXRpb24sIHJpZ2h0Pw0KDQpbUk1dIHllcyBwb29scyBhcmUgYWxyZWFkeSBjb25m
aWd1cmVkIGluIHRoZSBOQVMNCg0KDQoNCk5BUyBkb2VzIGtub3cgd2hpY2ggb25lIGlzIGZvciBT
TEFBQyBwcmVmaXggcG9vbCwgd2hpY2ggb25lIGlzIGZvciBESENQdjYgYWRkcmVzcyBwb29sLg0K
DQoNCg0KW1JNXSBBbGwgdGhlIGNvbmZpZ3VyZWQgcG9vbHMgYXJlIHRoZSBzYW1lIGZvciB0aGUg
TkFTLCBpbiB0aGlzIGNhc2UgYW4gZXh0cmEgbG9naWMgd291bGQgYmUgbmVlZGVkIHRvIGluc3Ry
dWN0IHRoZSBOQVMgYWJvdXQgd2hpY2ggcG9vbCBpcyBmb3IgU0xBQUMgYW5kIHdoaWNoIG9uZSBp
cyBmb3IgREhDUHY2DQoNCg0KDQoNCg0KDQoNClRoYXTigJlzIHdoeSBpbiBteSBvcGluaW9uIHRo
ZSBTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCBpcyByZXF1aXJlZC4NCg0KDQoNCg0KDQpCZXN0
IFJlZ2FyZHMsDQoNCkxlYWYNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCuWPkeS7tuS6ujogTWFnbGlvbmUgUm9iZXJ0YSBbcm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29t
aXRhbGlhLml0PGh0dHA6Ly9yb2JlcnRhLm1hZ2xpb25lQHRlbGVjb21pdGFsaWEuaXQ+XQ0K5Y+R
6YCB5pe26Ze0OiAyMDEx5bm0N+aciDI35pelIDI6MTMNCuWIsDogJ0phY25pIFFpbicNCkNjOiBM
ZWFmIHllaDsgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3NAdG9vbHMuaWV0Zi5vcmc8aHR0
cDovL2RyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnPjsgcmFkaXVz
ZXh0QG9wcy5pZXRmLm9yZzxodHRwOi8vcmFkaXVzZXh0QG9wcy5pZXRmLm9yZz47IGZpbmVfc3pA
aHVhd2VpLmNvbTxodHRwOi8vZmluZV9zekBodWF3ZWkuY29tPjsgUWl1amluOyBXYW5nc2h1eGlh
bmcNCuS4u+mimDogUkU6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFj
Y2VzcyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb24NCg0KSGkgSmFjbmksDQogICBJZiB5b3Ug
dXNlIHRoZSBzYW1lIGF0dHJpYnV0ZSBmb3IgYm90aCBzY2VuYXJpb3MgaG93IGRvZXMgdGhlIE5B
UyBrbm93IGlmIHRoYXQgcG9vbCBpcyBmb3IgU0xBQUMgb3IgZm9yIFN0YXRlZnVsIERIQ1B2Nj8N
Cg0KVGhhbmtzLA0KUmVnYXJkcywNClJvYmVydGENCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBKYWNuaSBRaW4gW21haWx0bzpqYWNuaXFA
Z21haWwuY29tXQ0KU2VudDogbWFydGVkw6wgMjYgbHVnbGlvIDIwMTEgMjAuMDMNClRvOiBNYWds
aW9uZSBSb2JlcnRhDQpDYzogTGVhZiB5ZWg7IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNz
QHRvb2xzLmlldGYub3JnPGh0dHA6Ly9kcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29s
cy5pZXRmLm9yZz47IHJhZGl1c2V4dEBvcHMuaWV0Zi5vcmc8aHR0cDovL3JhZGl1c2V4dEBvcHMu
aWV0Zi5vcmc+OyBmaW5lX3N6QGh1YXdlaS5jb208aHR0cDovL2ZpbmVfc3pAaHVhd2VpLmNvbT47
IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpTdWJqZWN0OiBSZTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0
LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbg0KDQpI
aSBSb2JlcnRhLA0KDQpJIGFncmVlIHdpdGggeW91IGFib3V0IHRoZSBzZW1hbnRpY2FsIGxvZ2lj
LCB3aGlsZSAiU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wiIGlzIG5vdCBuZWNlc3NhcnksIElN
SE8uDQoNCg0KQ2hlZXJzLA0KSmFjbmkNCk9uIFdlZCwgSnVsIDI3LCAyMDExIGF0IDE6NTUgQU0s
IE1hZ2xpb25lIFJvYmVydGEgPHJvYmVydGEubWFnbGlvbmVAdGVsZWNvbWl0YWxpYS5pdDxodHRw
Oi8vcm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0Pj4gd3JvdGU6DQpIZWxsbyBMZWFm
LA0KICAgIFRoZSBkaWZmZXJlbnQgYXR0cmlidXRlcyBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0IGZv
ciB0aGUgcG9vbHMgbmFtZSBoYXZlIGFsbCB0aGUgc2FtZSBmb3JtYXQgKGEgc3RyaW5nKSwgYnV0
IHNlbWFudGljYWxseSB0aGV5IGFyZSBkaWZmZXJlbnQsIGFzIHRoZXkgY292ZWQgZGlmZmVyZW50
IHNjZW5hcmlvcy4NCkFzIHlvdSBhbHNvIHN1bW1hcml6ZWQgaW4geW91ciBlbWFpbCBiZWxvdywN
Cg0KRnJhbWVkLVBvb2wgd2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NCBhZGRyZXNzIHBvb2w7DQpG
cmFtZWQtSVB2Ni1Qb29sIHdhcyBkZXNpZ25lZCBmb3IgdGhlIElQdjYgU0xBQUMgcHJlZml4IHBv
b2w7DQpEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2LVBE
IHByZWZpeCBwb29sOw0KU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgZGVzaWduZWQgZm9y
IERIQ1B2NiBhZGRyZXNzIHBvb2w7DQoNClNvIGVhY2ggYXR0cmlidXRlIGNvdmVycyBhIGRpZmZl
cmVudCB1c2UtY2FzZS9zY2VuYXJpbyBhbmQgdGhleSBjYW4gYXBwZWFyIGluIHRoZSBzYW1lIFJB
RElVUyBwYWNrZXQgYXQgdGhlIHNhbWUgdGltZS4NCklmIHlvdSB3YW50IHRvIHVzZSBhIHNpbmds
ZSBwb29sIG5hbWUgdXNlIHRvIGNvdmVyIGFsbCB0aGUgNCB1c2UgY2FzZXMgbGlzdGVkIGFib3Zl
LCB5b3Ugd291bGQgYWxzbyBuZWVkIHRvIGRlZmluZSBhIHN0YW5kYXJkIGZvcm1hdC9zeW50YXgg
Zm9yIHRoZSBwb29sIG5hbWUgdGhhdCBhbGxvd3MgdGhlIE5BUyB0byBiZSBhYmxlIHRvIGRpc2Ft
YmlndWF0ZSBhbW9uZyB0aGUgZGlmZmVyZW50IHNjZW5hcmlvcyBhbmQgaW4gb3JkZXIgdG8gZG8g
dGhhdCB0aGUgTkFTIHdvdWxkIG5lZWQgdG8gaGF2ZSBhbiBleHRyYSBsb2dpYyB0byBpbmZlciB0
aGUgc2VtYW50aWMgb2YgdGhhdCBzcGVjaWZpYyBhdHRyaWJ1dGUgZnJvbSB0aGUgYXNzaWduZWQg
bmFtZS4NCkluc3RlYWQgaWYgeW91IGhhdmUgYSBzcGVjaWZpYyBhdHRyaWJ1dGUgZm9yIGVhY2gg
c3BlY2lmaWMgc2NlbmFyaW8sIHRoZSBzZW1hbnRpYyBpcyBtYXBwZWQgdG8gdGhlIGF0dHJpYnV0
ZSBuYW1lLCB0aHVzIHRoZSBOQVMgZG9lcyBub3QgbmVlZCBhbiBleHRyYSBsb2dpYyB0byBkaXNj
b3ZlcnkgdGhlIHB1cnBvc2Ugb2YgdGhhdCBwb29sIGFuZCB0aGUgcG9vbCBuYW1lIGNhbiBiZSBh
bnkgc3RyaW5nLCBubyBsaW1pdGF0aW9uIG9yIHNwZWNpYWwgc3ludGF4IGlzIGZvcmNlZCBmb3Ig
dGhlIHBvb2wgbmFtZS4NCg0KDQpUaGFua3MsDQpSZWdhcmRzLA0KUm9iZXJ0YQ0KDQoNCg0KDQoN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IG93bmVyLXJh
ZGl1c2V4dEBvcHMuaWV0Zi5vcmc8aHR0cDovL293bmVyLXJhZGl1c2V4dEBvcHMuaWV0Zi5vcmc+
IFttYWlsdG86b3duZXItcmFkaXVzZXh0QG9wcy5pZXRmLm9yZ10gT24gQmVoYWxmIE9mIExlYWYg
eWVoDQpTZW50OiBsdW5lZMOsIDI1IGx1Z2xpbyAyMDExIDE4LjIzDQpUbzogZHJhZnQtaWV0Zi1y
YWRleHQtaXB2Ni1hY2Nlc3NAdG9vbHMuaWV0Zi5vcmc8aHR0cDovL2RyYWZ0LWlldGYtcmFkZXh0
LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnPjsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZzxodHRw
Oi8vcmFkaXVzZXh0QG9wcy5pZXRmLm9yZz4NCkNjOiBmaW5lX3N6QGh1YXdlaS5jb208aHR0cDov
L2ZpbmVfc3pAaHVhd2VpLmNvbT47IFFpdWppbjsgV2FuZ3NodXhpYW5nDQpTdWJqZWN0OiBRIG9u
IFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3MgYWZ0ZXIgSUVURjgxIHJh
ZGV4dCBzZXNzaW9uDQoNClF1ZXN0aW9uIGZvciBjbGFyaWZpY2F0aW9uOg0KDQpXZSBhbHJlYWR5
IGhhdmUgdGhlIGZvbGxvd2luZyBSYWRpdXMgQXR0cmlidXRlcyBmb3IgdGhlIGFkZHJlc3MvcHJl
Zml4IHBvb2xzOg0KDQpGcmFtZWQtUG9vbCAoODgsIHNlY3Rpb24gNS4xOCBvZiBSRkMyODY5KSwN
CkZyYW1lZC1JUHY2LVBvb2wgKDEwMCwgc2VjdGlvbiAyLjYgb2YgUkZDMzE2MikuDQoNCmh0dHA6
Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvcmFkaXVzLXR5cGVzL3JhZGl1cy10eXBlcy54bWwN
Cg0KVGhlIGZvcmFtdCBhcmUgdGhlIHNhbWUgYXMgZm9sbG93czoNCg0KMCAgICAgICAgICAgICAg
ICAgICAxICAgICAgICAgICAgICAgICAgIDINCjAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0
IDUgNiA3IDggOSAwIDEgMiAzDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rDQp8ICAgICBUeXBlICAgICAgfCAgICBMZW5ndGggICAgIHwgICAgIFN0cmlu
Zy4uLg0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K
DQpkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzcy0wNSBpcyBwcm9wb3NpbmcgMiBuZXcgYXR0
cmlidXRlcyBmb3IgYWRkcmVzcy9wcmVmaXggcG9vbHM6DQoNCkRlbGVnYXRlZC1JUHY2LVByZWZp
eC1Qb29sLA0KU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wsDQoNCnRoZSBmb21hdCBvZiB0aGVz
ZSAyIGF0dHJpYnV0ZXMgYXJlIHRoZSBzYW1lIGFzIHRoZSBhYm92ZSBvbmUuDQoNCg0KU3VwcG9z
ZWQgdGhlIGFib3ZlIGF0dHJpYnV0ZXMgY291bGQgYmUgZXhwbGFpbmVkIGFzIGZvbGxvd3M6DQoN
CkZyYW1lZC1Qb29sIHdhcyBkZXNpZ25lZCBmb3IgdGhlIElQdjQgYWRkcmVzcyBwb29sOw0KRnJh
bWVkLUlQdjYtUG9vbCB3YXMgZGVzaWduZWQgZm9yIHRoZSBJUHY2IFNMQUFDIHByZWZpeCBwb29s
Ow0KRGVsZWdhdGVkLUlQdjYtUHJlZml4LVBvb2wgaXMgZGVzaWduZWQgZm9yIERIQ1B2Ni1QRCBw
cmVmaXggcG9vbDsNClN0YXRlZnVsLUlQdjYtQWRkcmVzcy1Qb29sIGlzIGRlc2lnbmVkIGZvciBE
SENQdjYgYWRkcmVzcyBwb29sOw0KDQpBbGwgYWJvdmUgYXR0cmlidXRlcyBhcmUgb25seSB1c2Vk
IHRvIHByb3ZpZGUgdGhlIG5hbWUgb2YgdGhlIGFkZHJlc3MvcHJlZml4IHBvb2xzIGluIGEgJ3N0
cmluZycuIEkgZG91YnQgdGhlIG5lY2Vzc2l0eSB0byBtYWtlIHNvIG1hbnkgJ25hbWUnIG9yICdz
dHJpbmcnIGF0dHJpYnV0ZXMgZm9yIHRoZSBkaWZmZXJlbnQgYWRkcmVzcy9wcmVmaXggcG9vbHMg
dG8gcHJldmVudCB0aGUgYW1iaWd1aXR5LiBJIGd1ZXNzIDEgYXR0cmlidXRlIGZvciB0aGUgbmFt
ZSBvZiB0aGUgYWRkcmVzcy9wcmVmaXggcG9vbHMgbWlnaHQgYmUgZW5vdWdoLiBJbiBmYWN0LCB0
aGUgTkFTIHRha2UgdGhlIHJvbGUgdG8gaW50ZXJwcmV0IHRoZSBtZWFuaW5nIG9mIHRoZSBwb29r
IG5hbWUsIHJpZ2h0Pw0KDQpJIHRoaW5rIEZyYW1lZC1Qb29sIGNhbiBiZSByZS11c2VkIGZvciB0
aGUgZGVzaWduIHB1cnBvc2Ugb2YgU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wuIERvIHdlIGhh
dmUgYW55IGxpbWl0YXRpb24gb24gdGhlIHVzYWdlIG9mIEZyYW1lZC1Qb29sIGZvciBJUHY2Pw0K
SSB0aGluayBGcmFtZWQtSVB2Ni1Qb29sIGNhbiBiZSByZS11c2VkIGZvciB0aGUgZGVzaWduIHB1
cnBvc2Ugb2YgRGVsZWdhdGVkLUlQdjYtUHJlZml4LVBvb2wgdG8gaW5kaWNhdGUgYSBwb29sIG9m
IElQdjYgcHJlZml4IHBvb2wuIEkgY291bGQgZXZlbiB0aGluayBGcmFtZWQtUG9vbCBjYW4gcmVw
bGFjZSBGcmFtZWQtSVB2Ni1Qb29sIHRvIGluZGljYXRlIHRoZSBuYW1lIG9mIGEgSVB2NiBwcmVm
aXgvYWRkcmVzcyBwb29sIHBlciB0aGUgc2FtZSBsb2dpYy4gQW0gSSByaWdodD8NCg0KDQpCZXN0
IFJlZ2FyZHMsDQpMZWFmDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpRdWVzdG8gbWVzc2FnZ2lv
IGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBw
ZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBh
emlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBz
b25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0
byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJu
ZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxs
YSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVu
dHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9u
IGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlp
bmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5
b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVz
c2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4g
ZS1tYWlsLCBUaGFua3MuDQpSaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3Rh
IG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uDQoNCg0KUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3Vv
aSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBp
bmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lIGRl
cml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdv
cm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1l
bnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRp
YXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRp
c3RydXppb25lLCBHcmF6aWUuDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMg
Y29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVu
ZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHBy
aW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJl
IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBh
bmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWls
LCBUaGFua3MuDQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRp
cml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lv
bmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3Nj
ZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBR
dWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRl
IGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFs
IG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0K
VGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBj
b250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUo
cykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJv
ZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp
cGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5k
IGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4gUmlzcGV0dGEgbCdh
bWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3NhcmlvLg0K
DQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNj
bHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBv
IHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVl
c3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJp
YXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVu
dGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBl
IGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4NClRoaXMgZS1tYWls
IGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2
aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERp
c3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMg
dW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh
c2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhl
IHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuIFJpc3BldHRhIGwnYW1iaWVudGUuIE5v
biBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4NCg0K

--Boundary_(ID_5sIeYiGktUaGsI5b0WMdKQ)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPg0KPHRpdGxlPlJlOiDnrZTlpI06IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRm
LXJhZGV4dC1pcHY2LWFjY2VzcyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb248L3RpdGxlPg0K
PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEg
MTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x
OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp
Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh
Y2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg
MSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDEx
IDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6
MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46
MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OuWui+S9kzt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmi
hOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp
bms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNw
YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw
RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0
O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46
NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX
b3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxp
c3QtaWQ6MTM4MTUxMzA1MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTIyMjI1NDM5Mjt9DQpA
bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s
ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv
bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0
b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx
MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg
Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh
bmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT
ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5Xb2pjaWVjaCAtIFRoZXJlIGlzIGxpdHRsZSB0aGF0IGRpc2FsbG93
cyBhIHZlbmRvciBmcm9tIGltcGxlbWVudGluZyBqdXN0IG9uZSBuYW1lZCBwb29sIGZvciBhbGwg
cHJvdG9jb2xzIGFuZCBhbGwgbWV0aG9kcyBvZiBhc3NpZ25tZW50ICggdGhlIEZyYW1lZC1Qb29s
IGFwcGVhcnMNCiB0byBoYXZlIGJlZW4gZW52aXNhZ2VkIGZvciB0aGF0ICkgYW5kIHRoZW4gdXNp
bmcgc29tZSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBsb2dpYyAoZWcgcGFyc2luZyBmb3IgYSBu
YW1lKSB0byBmaWd1cmUgb3V0L2hvdyBpdOKAmXMgdG8gYmUgdXNlZC4NCjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldvamNpZWNoIC0gU2luY2Ug
dGhlIFJhZGl1cyBzcGVjaWZpY2F0aW9uIGlzIE5PVCBhYm91dCBzcGVjaWZ5aW5nIGltcGxlbWVu
dGF0aW9uIHRoZSBvbmx5IHJlbGlhYmxlL3VuYW1iaWd1b3VzIG1hbm5lciBpbiB3aGljaCBkaWZm
ZXJlbnQgcG9vbHMvbWV0aG9kcyBjYW4gYmUNCiB1dGlsaXplZCB3b3VsZCBhcHBlYXIgdG8gYmUg
dXNpbmcgZGlmZmVyZW50IGF0dHJpYnV0ZXMgYXMgcHJvcG9zZWQgaW4gdGhlIGN1cnJlbnQgZHJh
ZnQuIEFyZSB0aGVyZSBhbnkgb3RoZXIgb3B0aW9ucy9zb2x1dGlvbnMgYXZhaWxhYmxlIHRoYXQg
ZG8gbm90IGNhbGwgb24gaW1wbGljaXQgZmVhdHVyZXMgYmVpbmcgdGhlcmU/PGJyPg0KPGJyPg0K
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
ImxpbmUtaGVpZ2h0OjE0LjRwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkEgbmV3IGF0dHJpYnV0ZSBkZXNp
Z25lZCB0byBpbmRpY2F0ZSB0aGUg4oCYVXNlci1UeXBl4oCZIHNvdW5kcyBhIG1vcmUgc3RyYWln
aHQgbWFubmVyIGFuZCB3aWxsIGhhdmUgdGhlDQogcG90ZW50aWFsIGV4dGVuc2liaWxpdHkgdG8g
cHJldmVudCB0aGlzIGtpbmQgb2YgYW1iaWd1aXR5LCB3aGljaCBoYXMgYmVlbiBwcm9wb3NlZCBp
biAmbmJzcDtzZWN0aW9uIDQuMSBvZiBkcmFmdC15ZWgtcmFkZXh0LWR1YWwtc3RhY2stYWNjZXNz
LTAyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs
aW5lLWhlaWdodDoxNC40cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0O2Jh
Y2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+VGhlIOKAmFVzZXItVHlwZeKAmSBjYW4gY292ZXIgdGhlIGZvbGxvd2lu
ZyBjYXNlcyBmb3IgYm90aCBQUFBvRSBhbmQgSVBvRSBhY2Nlc3MgbW9kZWwgYnkgbm93LjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo
dDoxNC40cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0O2JhY2tncm91bmQ6
d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+SVB2NC1vbmx5IEhvc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SVB2Ni1v
bmx5IEhvc3QoTnVtYmVyZWQgYnkgU0xBQUMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdDtiYWNrZ3JvdW5kOndoaXRl
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PklQdjYtb25seSBIb3N0KE51bWJlcmVkIGJ5IERIQ1B2Nik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0O2JhY2tncm91
bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+SVB2Ni1vbmx5IEN1c3RvbWVyIFJvdXRlcihVbm51bWJlcmVkKTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40
cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5JUHY2LW9ubHkgQ3VzdG9tZXIgUm91dGVyKE51bWJlcmVkIGJ5
IFNMQUFDKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJsaW5lLWhlaWdodDoxNC40cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JUHY2LW9ubHkgQ3VzdG9tZXIg
Um91dGVyKE51bWJlcmVkIGJ5IERIQ1B2Nik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0O2JhY2tncm91bmQ6d2hpdGUi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
RHVhbCBzdGFjayAtIElQdjQgSG9zdCAmIzQzOyBJUHY2IEhvc3QoTnVtYmVyZWQgYnkgU0xBQUMp
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt
aGVpZ2h0OjE0LjRwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkR1YWwgc3RhY2sgLSBJUHY0IEhvc3QgJiM0
MzsgSVB2NiBIb3N0KE51bWJlcmVkIGJ5IERIQ1B2Nik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0O2JhY2tncm91bmQ6
d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+RHVhbCBzdGFjayAtIElQdjQgSG9zdCAmIzQzOyBJUHY2IEN1c3RvbWVyIFJvdXRlcihV
bm51bWJlcmVkKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJsaW5lLWhlaWdodDoxNC40cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EdWFsIHN0YWNrIC0gSVB2
NCBIb3N0ICYjNDM7IElQdjYgQ3VzdG9tZXIgUm91dGVyKE51bWJlcmVkIGJ5IFNMQUFDKTxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo
dDoxNC40cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EdWFsIHN0YWNrIC0gSVB2NCBIb3N0ICYjNDM7IElQ
djYgQ3VzdG9tZXIgUm91dGVyKE51bWJlcmVkIGJ5IERIQ1B2Nik8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQ7YmFja2dyb3VuZDp3
aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5Bbm90aGVyIHVzYWdlIChvciBkZXNpZ24gcHVycG9zZSkgb2Yg4oCYVXNlci1UeXBl4oCZ
IGlzIGZvciB0aGUgZGVmYXVsdCBiZWhhdmlvciBvZiB0aGUgTkFTLiBXaGVuIHRoZSBOQVMNCiBo
YXMgbm90IHJlY2VpdmVkIHRoZSBwb29sLW5hbWUgYXR0cmlidXRlcyAoRnJhbWVkLVBvb2wsIEZy
YW1lZC1JUHY2LVBvb2wsIGV0YykgZnJvbSBBQUEgc2VydmVyLCBpdCBjYW4gZGlyZWN0bHkgYXNz
aWduIHRoZSBhZGRyZXNzL3ByZWZpeCBmcm9tIHRoZSBkZWZhdWx0IHBvb2xzLg0KPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0
LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gNC4xIG9mIGRyYWZ0LXRhbi12Nm9wcy1m
YXN0Ni1hYWEtMDEgbWlnaHQgZ2l2ZSB1cyBhIG5ldyByZWZlcmVuY2UuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVvdDtVc2VyLVR5cGUmcXVvdDsgYXR0cmlidXRlIGNh
biBzaW1wbGlmeSB0aGUgd2F5IGhvdyBCUkFTIGRldGVybWluZXMgdGhlIHVzZXIgdHlwZS4mbmJz
cDsgSW4gYWRkaXRpb24sIEJSQVMgY2FuIGFsbG9jYXRlIGFwcHJvcHJpYXRlIElQIGFkZHJlc3Nl
cyBmb3INCiB0aGUgdXNlciBldmVuIHdpdGhvdXQgdGhlIGFkZHJlc3MgcG9vbCBhdHRyaWJ1dGUg
c2VudCBieSBSQURJVVMgc2VydmUsIGlmIGRlZmF1bHQgYWRkcmVzcyBwb29sIGlzIGRlZmluZWQg
YnkgQlJBUy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMs
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MZWFmPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw
YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJlcm5hcmQgQWJvYmEgW21haWx0
bzpiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh
eSwgQXVndXN0IDAzLCAyMDExIDY6NDggQU08YnI+DQo8Yj5Ubzo8L2I+IHdkZWNAY2lzY28uY29t
OyBMZWFmIHllaDsgcm9iZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0OyBqYWNuaXFAZ21h
aWwuY29tPGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29s
cy5pZXRmLm9yZzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZzsgZmluZV9zekBodWF3ZWkuY29tOyBR
aXVqaW47IFdhbmdzaHV4aWFuZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7nrZTlpI08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4
dC1pcHY2LWFjY2VzcyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb248bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+SW4gZ2VuZXJhbCwgdGhlIGNvbmNlcm4gdGhhdCBoYXMgbGVh
ZCB0byBkZWZpbmluZyB0aGVzZSBkaXN0aW5jdCBwb29scyBpcyB0aGUgcG9zc2liaWxpdHkgdGhh
dCBtdWx0aXBsZSBwb29sIHR5cGVzIG1pZ2h0IGJlIGVuYWJsZWQNCiBmb3IgYSBzaW5nbGUgc2Vz
c2lvbi4mbmJzcDsgRm9yIGV4YW1wbGUsIGl0J3MgcG9zc2libGUgdGhhdCBhbiBJUHY2IGFkZHJl
c3MgbWlnaHQgYmUgYXNzaWduZWQgZnJvbSBhIHBvb2wsIGFuZCBhdCB0aGUgc2FtZSB0aW1lIHRo
YXQgYSBQcmVmaXggbWlnaHQgYmUgZGVsZWdhdGVkIGZyb20gYSBwb29sLCBmb3IgdGhlIHNhbWUg
dXNlciBhbmQgc2Vzc2lvbi4mbmJzcDsgSW4gc3VjaCBhIHNpdHVhdGlvbiwmbmJzcDsgdXNpbmcg
dGhlIHNhbWUgcG9vbCBuYW1lIGZvciBtdWx0aXBsZQ0KIHB1cnBvc2VzIGNvdWxkIGJlIGFtYmln
dW91cyBhbmQvb3IgdW5kZXItc3BlY2lmaWVkLiZuYnNwOyA8YnI+DQo8YnI+DQpBIG5vdGUgYWJv
dXQgV29qJ3MgY29uY2VybiBhYm91dCBlcnJvcnMuJm5ic3A7IFdpdGggcmVzcGVjdCB0byBhIHNl
cnZlciBzZW5kaW5nIGFuIGF0dHJpYnV0ZSB0aGF0IGEgY2xpZW50IGRvZXMgbm90IHVuZGVyc3Rh
bmQsIFJGQyA1MDgwIFNlY3Rpb24gMi41IHByb3ZpZGVzIGd1aWRhbmNlOjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBJbiBnZW5lcmFs
LCBpdCBpcyBiZXN0IGZvciBhIFJBRElVUyBjbGllbnQgdG8gZXJyIG9uIHRoZSBzaWRlIG9mPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz
cDsgY2F1dGlvbi4mbmJzcDsgT24gcmVjZWl2aW5nIGFuIEFjY2Vzcy1BY2NlcHQgaW5jbHVkaW5n
IGFuIGF0dHJpYnV0ZSBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGtub3duIFR5cGUgZm9yIGFuIHVuaW1wbGVtZW50ZWQgc2Vy
dmljZSwgYSBSQURJVVMgY2xpZW50IE1VU1QgdHJlYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBpdCBhcyBhbiBBY2Nlc3MtUmVq
ZWN0LCBhcyBkaXJlY3RlZCBpbiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y
ZmMyODY1I3NlY3Rpb24tMS4xIj5bUkZDMjg2NV0gU2VjdGlvbiZuYnNwOzEuMTwvYT4uJm5ic3A7
IE9uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz
cDsmbmJzcDsgcmVjZWl2aW5nIGFuIEFjY2Vzcy1BY2NlcHQgaW5jbHVkaW5nIGFuIGF0dHJpYnV0
ZSBvZiB1bmtub3duIFR5cGUsIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBSQURJVVMgY2xpZW50IFNIT1VMRCBhc3N1bWUgdGhh
dCBpdCBpcyBhIHBvdGVudGlhbCBzZXJ2aWNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgZGVmaW5pdGlvbiwgYW5kIHRyZWF0IGl0
IGFzIGFuIEFjY2Vzcy1SZWplY3QuJm5ic3A7IFVua25vd24gVlNBcyBTSE9VTEQgYmU8bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBp
Z25vcmVkIGJ5IFJBRElVUyBjbGllbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFzIGEgcmVzdWx0LCBpdCBpcyBwb3NzaWJsZSB0
aGF0IGEgY2xpZW50IG5vdCBpbXBsZW1lbnRpbmcgdGhlIElQdjYgQWNjZXNzIFJGQyB3aWxsIGln
bm9yZSB0aGUgYXR0cmlidXRlcyAoZS5nLiBub3QgaW1wbGVtZW50IHRoZQ0KIFNIT1VMRCkgcmF0
aGVyIHRoYW4gcmVmdXNpbmcgdG8gcHJvdmlkZSBzZXJ2aWNlLiA8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i
dGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiIGlkPSJzdG9wU3Bl
bGxpbmciPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PkRhdGU6IE1vbiwgMSBBdWcgMjAxMSAxMjo0NzozOCAtMDQwMDxicj4NClN1YmplY3Q6IFJlOiA8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuetlOWkjTwvc3Bhbj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0
LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbjxicj4N
CkZyb206IHdkZWNAY2lzY28uY29tPGJyPg0KVG86IGxlYWYueS55ZWhAaHVhd2VpLmNvbTsgcm9i
ZXJ0YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0OyBqYWNuaXFAZ21haWwuY29tPGJyPg0KQ0M6
IGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnOyByYWRpdXNleHRA
b3BzLmlldGYub3JnOyBmaW5lX3N6QGh1YXdlaS5jb207IHFpdWppbkBodWF3ZWkuY29tOyB3YW5n
c2h1eGlhbmdAaHVhd2VpLmNvbTxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBBbGwsPGJyPg0KPGJyPg0KQWxsb3cgbWUgdG8gc2hh
cmUgc29tZSBjb21tZW50czo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZXJlIGlzIHByZWNlZGVudCBvZiBtdWx0aXBs
ZSDigJxzcGVjaWZpY+KAnSBuYW1lZCBwb29sczsgRnJhbWVkLVBvb2wsIEZyYW1lZC1JUHY2LVBv
b2wsIGFuZCB0aGUgdW5jb250ZXN0ZWQgRGVsZWdhdGVkLUlQdjYtUHJlZml4LVBvb2wuIFRoZXJl
IGlzIGFsc28gYSBzcGVjaWFsIGNvZGUgaW4gdGhlIEZyYW1lZC1JUFgtTmV0d29yaw0KIGF0dHJp
YnV0ZSB0aGF0IGNvbnZleXMgaXQgcG9vbCBsaWtlIGNoYXJhY3RlcmlzdGljcy4gPC9zcGFuPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+
PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZXJlIGlzIGxpdHRsZSB0
aGF0IGRpc2FsbG93cyBhIHZlbmRvciBmcm9tIGltcGxlbWVudGluZyBqdXN0IG9uZSBuYW1lZCBw
b29sIGZvciBhbGwgcHJvdG9jb2xzIGFuZCBhbGwgbWV0aG9kcyBvZiBhc3NpZ25tZW50ICggdGhl
IEZyYW1lZC1Qb29sIGFwcGVhcnMgdG8gaGF2ZSBiZWVuIGVudmlzYWdlZCBmb3INCiB0aGF0ICkg
YW5kIHRoZW4gdXNpbmcgc29tZSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBsb2dpYyAoZWcgcGFy
c2luZyBmb3IgYSBuYW1lKSB0byBmaWd1cmUgb3V0L2hvdyBpdOKAmXMgdG8gYmUgdXNlZC4NCjwv
c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+
PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZv
MSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgcHJvYmxl
bSB3aXRoIHJlbHlpbmcgb24gaW1wbGVtZW50YXRpb24gc3BlY2lmaWMgZmVhdHVyZXMgcmlkaW5n
IG9uIHN0YW5kYXJkIEF0dHJpYnV0ZXMsIGFzIG9wcG9zZWQgdG8gc2F5IFZTQXMsIGlzIHRoYXQg
bm90aGluZyBpbmRpY2F0ZXMgdG8gdGhlIHNlcnZlci9jbGllbnQgaWYgdGhlIHJlY2lwaWVudA0K
IGFjdHVhbGx5IHN1cHBvcnRzIHN1Y2ggc3BlY2lhbCBmZWF0dXJlcyBhbmQgYXNzdXJlcyBjb3Jy
ZWN0IGludGVycHJldGF0aW9uLiBFZyBpZiB3ZSB1c2VkIHRoZSBGcmFtZWQtUG9vbCBhcyB0aGUg
T05FIG5hbWVkIHBvb2wgYXR0cmlidXRlLCB3aXRoIGEgY2FycmllZCBzdHJpbmcg4oCcSVB2NOKA
nSwg4oCcSVB2NuKAnSBvciDigJxESENQdjYtUETigJ0sIGV0YywgcGFyc2VkL3doYXRldmVyIHRv
IGluZGljYXRlIHRoZSByb2xlLCBpdCB3b3VsZCBiZSBhbGwgZG9hYmxlLA0KIGJ1dCBhIGxpa2Vs
eSBtZXNzIHNob3VsZCBhbnl0aGluZyBnbyB3cm9uZyAoZWcgYSBkZXZpY2Ugbm90IHN1cHBvcnRp
bmcgc29tZSBtb2RlKSwgd2l0aG91dCBjbGVhciBpbmRpY2F0aW9uIG9mIGVycm9yLjwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu
PjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KU2lu
Y2UgdGhlIFJhZGl1cyBzcGVjaWZpY2F0aW9uIGlzIE5PVCBhYm91dCBzcGVjaWZ5aW5nIGltcGxl
bWVudGF0aW9uIHRoZSBvbmx5IHJlbGlhYmxlL3VuYW1iaWd1b3VzIG1hbm5lciBpbiB3aGljaCBk
aWZmZXJlbnQgcG9vbHMvbWV0aG9kcyBjYW4gYmUgdXRpbGl6ZWQgd291bGQgYXBwZWFyIHRvIGJl
IHVzaW5nIGRpZmZlcmVudCBhdHRyaWJ1dGVzIGFzIHByb3Bvc2VkIGluIHRoZSBjdXJyZW50IGRy
YWZ0LiBUaW1lIChwcmVjZWRlbnQpIGFsc28NCiBhcHBlYXJzIHRvIGhhdmUgcHJvdmVkIHRoaXMg
YXMgYSBkZXNpcmFibGUgcHJvdG9jb2wgY2hhcmFjdGVyaXN0aWMuIDxicj4NCkFyZSB0aGVyZSBh
bnkgb3RoZXIgb3B0aW9ucy9zb2x1dGlvbnMgYXZhaWxhYmxlIHRoYXQgZG8gbm90IGNhbGwgb24g
aW1wbGljaXQgZmVhdHVyZXMgYmVpbmcgdGhlcmU/PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpX
b2pjaWVjaC48YnI+DQo8YnI+DQo8YnI+DQpPbiAyNi8wNy8yMDExIDIyOjUxLCAmcXVvdDtMZWFm
IHllaCZxdW90OyAmbHQ7PGEgaHJlZj0iaHR0cDovL2xlYWYueS55ZWhAaHVhd2VpLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPmxlYWYueS55ZWhAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+W1JNXSBO
QVMgY2FuIGhhdmUgbWFueSBwb29scyBjb25maWd1cmVkIGxvY2FsbHk6IGhvdyBkb2VzIHRoZSBO
QVMga25vdyB3aGljaCBwb29sIGlzIGZvciBTTEFBQyBhbmQgd2hpY2ggcG9vbCBpcyBmb3IgREhD
UHY2Pzxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
Pjxicj4NCiZuYnNwOzxicj4NCjxicj4NCkkgc3VwcG9zZWQgdGhlIGxvY2FsIGNvbmZpZ3VyYXRp
b24gb24gdGhlIE5BUyB3aWxsIGFuc3dlciB0aGlzIHF1ZXN0aW9uLjxicj4NCjxicj4NCiZuYnNw
Ozxicj4NCjxicj4NCkJlc3QgUmVnYXJkcyw8YnI+DQo8YnI+DQpMZWFmPGJyPg0KPGJyPg0KJm5i
c3A7PGJyPg0KPGJyPg0KJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0i
TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8aHIgc2l6ZT0iMyIgd2lkdGg9
IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuWPkeS7tuS6ujwvc3Bhbj48L2I+
PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46PC9zcGFuPjwvYj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYWdsaW9uZSBSb2JlcnRh
DQogWzxhIGhyZWY9Imh0dHA6Ly9yb2JlcnRhLm1hZ2xpb25lQHRlbGVjb21pdGFsaWEuaXQiIHRh
cmdldD0iX2JsYW5rIj5yb2JlcnRhLm1hZ2xpb25lQHRlbGVjb21pdGFsaWEuaXQ8L2E+XTxicj4N
Cjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PC9z
cGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjo8L3Nw
YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IDIwMTE8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuW5tDwvc3Bhbj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQiPuaciDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPjI3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7ml6U8L3NwYW4+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiAzOjU0PGJyPg0KPC9zcGFu
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7liLA8L3NwYW4+PC9iPjxiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTGVhZiB5ZWg7ICdKYWNuaSBRaW4nPGJy
Pg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJodHRwOi8vZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nl
c3NAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYtcmFkZXh0LWlw
djYtYWNjZXNzQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0iaHR0cDovL3JhZGl1c2V4dEBv
cHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnJhZGl1c2V4dEBvcHMuaWV0Zi5vcmc8L2E+
OyA8YSBocmVmPSJodHRwOi8vZmluZV9zekBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+Zmlu
ZV9zekBodWF3ZWkuY29tPC9hPjsgUWl1amluOyBXYW5nc2h1eGlhbmc8YnI+DQo8L3NwYW4+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuS4u+mimDwvc3Bhbj48L2I+PGI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSRTogUSBvbiBWZXIuLTA1IG9mIGRyYWZ0
LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzDQogYWZ0ZXIgSUVURjgxIHJhZGV4dCBzZXNzaW9uPGJy
Pg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQombmJzcDs8L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0
ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExlYWYgeWVoIFs8YSBo
cmVmPSJtYWlsdG86bGVhZi55LnllaEBodWF3ZWkuY29tIj5tYWlsdG86bGVhZi55LnllaEBodWF3
ZWkuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBtYXJ0ZWTDrCAyNiBsdWdsaW8gMjAxMSAy
MS41MDxicj4NCjxiPlRvOjwvYj4gTWFnbGlvbmUgUm9iZXJ0YTsgJ0phY25pIFFpbic8YnI+DQo8
Yj5DYzo8L2I+IDxhIGhyZWY9Imh0dHA6Ly9kcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0
b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1h
Y2Nlc3NAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJodHRwOi8vcmFkaXVzZXh0QG9wcy5p
ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KcmFkaXVzZXh0QG9wcy5pZXRmLm9yZzwvYT47IDxh
IGhyZWY9Imh0dHA6Ly9maW5lX3N6QGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5maW5lX3N6
QGh1YXdlaS5jb208L2E+OyBRaXVqaW47IFdhbmdzaHV4aWFuZzxicj4NCjxiPlN1YmplY3Q6PC9i
PiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuetlOWkjTwvc3Bhbj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjogUSBvbiBWZXIuLTA1IG9mIGRy
YWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzIGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbjxi
cj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPltSTV0gQWxsIHRoZSBjb25m
aWd1cmVkIHBvb2xzIGFyZSB0aGUgc2FtZSBmb3IgdGhlIE5BUywgaW4gdGhpcyBjYXNlIGFuIGV4
dHJhIGxvZ2ljIHdvdWxkIGJlIG5lZWRlZCB0byBpbnN0cnVjdCB0aGUgTkFTIGFib3V0IHdoaWNo
IHBvb2wgaXMgZm9yIFNMQUFDIGFuZCB3aGljaCBvbmUNCiBpcyBmb3IgREhDUHY2PGJyPg0KPC9z
cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KJm5ic3A7
PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOm5hdnkiPlRoZSBwb29scyBjb25maWd1cmVkIG9uIHRoZSBOQVMgYXJlIG5vdCBuZWNl
c3NhcnkgdG8gYmUgdGhlIHNhbWUuIEFBQSBzZXJ2ZXIgZG9lc24ndCByZWFsbHkgbmVlZCB0byBp
bnN0cnVjdCB0aGUgTkFTIHRoZSBzcGVjaWZpZWQgdHlwZSBvZiBwb29scywgd2hpY2ggaXMgYWxy
ZWFkeQ0KIGNvbmZpZ3VyZWQgb24gdGhlIE5BUy4gUmlnaHQ/PGJyPg0KPC9zcGFuPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KJm5ic3A7PGJyPg0KPGJyPg0K
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnki
PltSTV0gTkFTIGNhbiBoYXZlIG1hbnkgcG9vbHMgY29uZmlndXJlZCBsb2NhbGx5OiBob3cgZG9l
cyB0aGUgTkFTIGtub3cgd2hpY2ggcG9vbCBpcyBmb3IgU0xBQUMgYW5kIHdoaWNoIHBvb2wgaXMg
Zm9yIERIQ1B2Nj88YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij48YnI+DQombmJzcDs8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+Um9iZXJ0YTxicj4NCjwvc3Bhbj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCiZuYnNwOzxicj4NCjxi
cj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpu
YXZ5Ij5CZXN0IFJlZ2FyZHMsPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOm5hdnkiPkxlYWY8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQombmJzcDs8YnI+DQo8YnI+DQombmJzcDs8YnI+
DQo8YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3Jt
YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIg
YWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
Ij7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij4NCiBNYWdsaW9uZSBSb2JlcnRhIFs8YSBocmVmPSJodHRwOi8vcm9iZXJ0YS5tYWdsaW9u
ZUB0ZWxlY29taXRhbGlhLml0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0YS5tYWdsaW9uZUB0ZWxl
Y29taXRhbGlhLml0PC9hPl08YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQiPuWPkemAgeaXtumXtDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPiAyMDExPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7l
ubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij43PC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7mnIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yNzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdCI+5pelPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+DQogMjoyNzxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+
5YiwPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
Pjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExl
YWYgeWVoOyAnSmFjbmkgUWluJzxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0iaHR0cDovL2RyYWZ0
LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
DQpkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzwvYT47IDxhIGhy
ZWY9Imh0dHA6Ly9yYWRpdXNleHRAb3BzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpyYWRp
dXNleHRAb3BzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0iaHR0cDovL2ZpbmVfc3pAaHVhd2VpLmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPmZpbmVfc3pAaHVhd2VpLmNvbTwvYT47IFFpdWppbjsgV2FuZ3No
dXhpYW5nPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7kuLvp
opg8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUkU6
IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzcw0KIGFmdGVyIElF
VEY4MSByYWRleHQgc2Vzc2lvbjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij5QbGVhc2Ugc2VlIGlubGluZS48YnI+DQo8
L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij5CZXN0IHJlZ2FyZHMsPGJyPg0K
Um9iZXJ0YTxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIg
YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGln
bj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4gTGVhZiB5ZWggWzxhIGhyZWY9Im1haWx0bzpsZWFmLnkueWVoQGh1YXdlaS5jb20i
Pm1haWx0bzpsZWFmLnkueWVoQGh1YXdlaS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IG1h
cnRlZMOsIDI2IGx1Z2xpbyAyMDExIDIwLjIyPGJyPg0KPGI+VG86PC9iPiBNYWdsaW9uZSBSb2Jl
cnRhOyAnSmFjbmkgUWluJzxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0iaHR0cDovL2RyYWZ0LWll
dGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpk
cmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzwvYT47IDxhIGhyZWY9
Imh0dHA6Ly9yYWRpdXNleHRAb3BzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpyYWRpdXNl
eHRAb3BzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0iaHR0cDovL2ZpbmVfc3pAaHVhd2VpLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPmZpbmVfc3pAaHVhd2VpLmNvbTwvYT47IFFpdWppbjsgV2FuZ3NodXhp
YW5nPGJyPg0KPGI+U3ViamVjdDo8L2I+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdCI+562U5aSNPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+OiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3MgYWZ0ZXIg
SUVURjgxIHJhZGV4dCBzZXNzaW9uPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48
YnI+DQpSb2JlcnRhIC0gSWYgeW91IHVzZSB0aGUgc2FtZSBhdHRyaWJ1dGUgZm9yIGJvdGggc2Nl
bmFyaW9zIGhvdyBkb2VzIHRoZSBOQVMga25vdyBpZiB0aGF0IHBvb2wgaXMgZm9yIFNMQUFDIG9y
IGZvciBTdGF0ZWZ1bCBESENQdjY/PGJyPg0KPGJyPg0KTkFTIGFscmVhZHkgaGFzIHRob3NlIHBv
b2wgbmFtZXMgaW4gaXRzIGNvbmZpZ3VyYXRpb24sIHJpZ2h0Pzxicj4NCjxicj4NCjwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij5bUk1dIHll
cyBwb29scyBhcmUgYWxyZWFkeSBjb25maWd1cmVkIGluIHRoZSBOQVM8YnI+DQo8L3NwYW4+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQombmJzcDs8YnI+DQo8
YnI+DQpOQVMgZG9lcyBrbm93IHdoaWNoIG9uZSBpcyBmb3IgU0xBQUMgcHJlZml4IHBvb2wsIHdo
aWNoIG9uZSBpcyBmb3IgREhDUHY2IGFkZHJlc3MgcG9vbC4NCjxicj4NCjxicj4NCiZuYnNwOzxi
cj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjpuYXZ5Ij5bUk1dIEFsbCB0aGUgY29uZmlndXJlZCBwb29scyBhcmUgdGhlIHNhbWUgZm9y
IHRoZSBOQVMsIGluIHRoaXMgY2FzZSBhbiBleHRyYSBsb2dpYyB3b3VsZCBiZSBuZWVkZWQgdG8g
aW5zdHJ1Y3QgdGhlIE5BUyBhYm91dCB3aGljaCBwb29sIGlzIGZvciBTTEFBQyBhbmQgd2hpY2gg
b25lDQogaXMgZm9yIERIQ1B2Njxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPjxicj4NCiZuYnNwOzxicj4NCjxicj4NCiZuYnNwOzxicj4NCjxicj4N
CiZuYnNwOzxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjpuYXZ5Ij5UaGF04oCZcyB3aHkgaW4gbXkgb3BpbmlvbiB0aGUgU3RhdGVm
dWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgcmVxdWlyZWQuPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KJm5ic3A7PGJyPg0KPGJyPg0KJm5i
c3A7PGJyPg0KPGJyPg0KQmVzdCBSZWdhcmRzLDxicj4NCjxicj4NCkxlYWY8YnI+DQo8YnI+DQom
bmJzcDs8YnI+DQo8YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNz
PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxociBzaXplPSIyIiB3aWR0
aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0Ij7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij4NCiBNYWdsaW9uZSBSb2JlcnRhIFs8YSBocmVmPSJodHRwOi8vcm9iZXJ0
YS5tYWdsaW9uZUB0ZWxlY29taXRhbGlhLml0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0YS5tYWds
aW9uZUB0ZWxlY29taXRhbGlhLml0PC9hPl08YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQiPuWPkemAgeaXtumXtDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPiAyMDExPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0Ij7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij43PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7mnIg8L3NwYW4+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yNzwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdCI+5pelPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+DQogMjoxMzxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdCI+5YiwPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+ICdKYWNuaSBRaW4nPGJyPg0KPGI+Q2M6PC9iPiBMZWFmIHllaDsgPGEgaHJlZj0iaHR0
cDovL2RyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayI+DQpkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZzwv
YT47IDxhIGhyZWY9Imh0dHA6Ly9yYWRpdXNleHRAb3BzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu
ayI+DQpyYWRpdXNleHRAb3BzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0iaHR0cDovL2ZpbmVfc3pA
aHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZpbmVfc3pAaHVhd2VpLmNvbTwvYT47IFFpdWpp
bjsgV2FuZ3NodXhpYW5nPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0Ij7kuLvpopg8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij4gUkU6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4dC1pcHY2LWFjY2Vzcw0K
IGFmdGVyIElFVEY4MSByYWRleHQgc2Vzc2lvbjxicj4NCjxicj4NCkhpIEphY25pLDxicj4NCiZu
YnNwOyZuYnNwOyZuYnNwO0lmIHlvdSB1c2UgdGhlIHNhbWUgYXR0cmlidXRlIGZvciBib3RoIHNj
ZW5hcmlvcyBob3cgZG9lcyB0aGUgTkFTIGtub3cgaWYgdGhhdCBwb29sIGlzIGZvciBTTEFBQyBv
ciBmb3IgU3RhdGVmdWwgREhDUHY2Pzxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpSZWdhcmRzLDxi
cj4NClJvYmVydGE8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRnJvbTogSmFjbmkgUWluIFs8YSBo
cmVmPSJtYWlsdG86amFjbmlxQGdtYWlsLmNvbSI+bWFpbHRvOmphY25pcUBnbWFpbC5jb208L2E+
XTxicj4NClNlbnQ6IG1hcnRlZMOsIDI2IGx1Z2xpbyAyMDExIDIwLjAzPGJyPg0KVG86IE1hZ2xp
b25lIFJvYmVydGE8YnI+DQpDYzogTGVhZiB5ZWg7IDxhIGhyZWY9Imh0dHA6Ly9kcmFmdC1pZXRm
LXJhZGV4dC1pcHY2LWFjY2Vzc0B0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJh
ZnQtaWV0Zi1yYWRleHQtaXB2Ni1hY2Nlc3NAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJo
dHRwOi8vcmFkaXVzZXh0QG9wcy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KcmFkaXVzZXh0
QG9wcy5pZXRmLm9yZzwvYT47IDxhIGhyZWY9Imh0dHA6Ly9maW5lX3N6QGh1YXdlaS5jb20iIHRh
cmdldD0iX2JsYW5rIj5maW5lX3N6QGh1YXdlaS5jb208L2E+OyBRaXVqaW47IFdhbmdzaHV4aWFu
Zzxicj4NClN1YmplY3Q6IFJlOiBRIG9uIFZlci4tMDUgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2
Ni1hY2Nlc3MgYWZ0ZXIgSUVURjgxIHJhZGV4dCBzZXNzaW9uPGJyPg0KPGJyPg0KSGkgUm9iZXJ0
YSw8YnI+DQo8YnI+DQpJIGFncmVlIHdpdGggeW91IGFib3V0IHRoZSBzZW1hbnRpY2FsIGxvZ2lj
LCB3aGlsZSAmcXVvdDtTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCZxdW90OyBpcyBub3QgbmVj
ZXNzYXJ5LCBJTUhPLjxicj4NCjxicj4NCjxicj4NCkNoZWVycyw8YnI+DQpKYWNuaTxicj4NCk9u
IFdlZCwgSnVsIDI3LCAyMDExIGF0IDE6NTUgQU0sIE1hZ2xpb25lIFJvYmVydGEgJmx0OzxhIGhy
ZWY9Imh0dHA6Ly9yb2JlcnRhLm1hZ2xpb25lQHRlbGVjb21pdGFsaWEuaXQiIHRhcmdldD0iX2Js
YW5rIj5yb2JlcnRhLm1hZ2xpb25lQHRlbGVjb21pdGFsaWEuaXQ8L2E+Jmd0OyB3cm90ZTo8YnI+
DQpIZWxsbyBMZWFmLDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSBkaWZmZXJlbnQg
YXR0cmlidXRlcyBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0IGZvciB0aGUgcG9vbHMgbmFtZSBoYXZl
IGFsbCB0aGUgc2FtZSBmb3JtYXQgKGEgc3RyaW5nKSwgYnV0IHNlbWFudGljYWxseSB0aGV5IGFy
ZSBkaWZmZXJlbnQsIGFzIHRoZXkgY292ZWQgZGlmZmVyZW50IHNjZW5hcmlvcy48YnI+DQpBcyB5
b3UgYWxzbyBzdW1tYXJpemVkIGluIHlvdXIgZW1haWwgYmVsb3csPGJyPg0KPGJyPg0KRnJhbWVk
LVBvb2wgd2FzIGRlc2lnbmVkIGZvciB0aGUgSVB2NCBhZGRyZXNzIHBvb2w7PGJyPg0KRnJhbWVk
LUlQdjYtUG9vbCB3YXMgZGVzaWduZWQgZm9yIHRoZSBJUHY2IFNMQUFDIHByZWZpeCBwb29sOzxi
cj4NCkRlbGVnYXRlZC1JUHY2LVByZWZpeC1Qb29sIGlzIGRlc2lnbmVkIGZvciBESENQdjYtUEQg
cHJlZml4IHBvb2w7PGJyPg0KU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgaXMgZGVzaWduZWQg
Zm9yIERIQ1B2NiBhZGRyZXNzIHBvb2w7PGJyPg0KPGJyPg0KU28gZWFjaCBhdHRyaWJ1dGUgY292
ZXJzIGEgZGlmZmVyZW50IHVzZS1jYXNlL3NjZW5hcmlvIGFuZCB0aGV5IGNhbiBhcHBlYXIgaW4g
dGhlIHNhbWUgUkFESVVTIHBhY2tldCBhdCB0aGUgc2FtZSB0aW1lLjxicj4NCklmIHlvdSB3YW50
IHRvIHVzZSBhIHNpbmdsZSBwb29sIG5hbWUgdXNlIHRvIGNvdmVyIGFsbCB0aGUgNCB1c2UgY2Fz
ZXMgbGlzdGVkIGFib3ZlLCB5b3Ugd291bGQgYWxzbyBuZWVkIHRvIGRlZmluZSBhIHN0YW5kYXJk
IGZvcm1hdC9zeW50YXggZm9yIHRoZSBwb29sIG5hbWUgdGhhdCBhbGxvd3MgdGhlIE5BUyB0byBi
ZSBhYmxlIHRvIGRpc2FtYmlndWF0ZSBhbW9uZyB0aGUgZGlmZmVyZW50IHNjZW5hcmlvcyBhbmQg
aW4gb3JkZXIgdG8gZG8gdGhhdA0KIHRoZSBOQVMgd291bGQgbmVlZCB0byBoYXZlIGFuIGV4dHJh
IGxvZ2ljIHRvIGluZmVyIHRoZSBzZW1hbnRpYyBvZiB0aGF0IHNwZWNpZmljIGF0dHJpYnV0ZSBm
cm9tIHRoZSBhc3NpZ25lZCBuYW1lLjxicj4NCkluc3RlYWQgaWYgeW91IGhhdmUgYSBzcGVjaWZp
YyBhdHRyaWJ1dGUgZm9yIGVhY2ggc3BlY2lmaWMgc2NlbmFyaW8sIHRoZSBzZW1hbnRpYyBpcyBt
YXBwZWQgdG8gdGhlIGF0dHJpYnV0ZSBuYW1lLCB0aHVzIHRoZSBOQVMgZG9lcyBub3QgbmVlZCBh
biBleHRyYSBsb2dpYyB0byBkaXNjb3ZlcnkgdGhlIHB1cnBvc2Ugb2YgdGhhdCBwb29sIGFuZCB0
aGUgcG9vbCBuYW1lIGNhbiBiZSBhbnkgc3RyaW5nLCBubyBsaW1pdGF0aW9uIG9yIHNwZWNpYWwN
CiBzeW50YXggaXMgZm9yY2VkIGZvciB0aGUgcG9vbCBuYW1lLjxicj4NCjxicj4NCjxicj4NClRo
YW5rcyw8YnI+DQpSZWdhcmRzLDxicj4NClJvYmVydGE8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8
YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K
RnJvbTogPGEgaHJlZj0iaHR0cDovL293bmVyLXJhZGl1c2V4dEBvcHMuaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj5vd25lci1yYWRpdXNleHRAb3BzLmlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFp
bHRvOm93bmVyLXJhZGl1c2V4dEBvcHMuaWV0Zi5vcmciPm1haWx0bzpvd25lci1yYWRpdXNleHRA
b3BzLmlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIExlYWYgeWVoPGJyPg0KU2VudDogbHVuZWTD
rCAyNSBsdWdsaW8gMjAxMSAxOC4yMzxicj4NClRvOiA8YSBocmVmPSJodHRwOi8vZHJhZnQtaWV0
Zi1yYWRleHQtaXB2Ni1hY2Nlc3NAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRy
YWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0i
aHR0cDovL3JhZGl1c2V4dEBvcHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnJhZGl1c2V4
dEBvcHMuaWV0Zi5vcmc8L2E+PGJyPg0KQ2M6IDxhIGhyZWY9Imh0dHA6Ly9maW5lX3N6QGh1YXdl
aS5jb20iIHRhcmdldD0iX2JsYW5rIj5maW5lX3N6QGh1YXdlaS5jb208L2E+OyBRaXVqaW47IFdh
bmdzaHV4aWFuZzxicj4NClN1YmplY3Q6IFEgb24gVmVyLi0wNSBvZiBkcmFmdC1pZXRmLXJhZGV4
dC1pcHY2LWFjY2VzcyBhZnRlciBJRVRGODEgcmFkZXh0IHNlc3Npb248YnI+DQo8YnI+DQpRdWVz
dGlvbiBmb3IgY2xhcmlmaWNhdGlvbjo8YnI+DQo8YnI+DQpXZSBhbHJlYWR5IGhhdmUgdGhlIGZv
bGxvd2luZyBSYWRpdXMgQXR0cmlidXRlcyBmb3IgdGhlIGFkZHJlc3MvcHJlZml4IHBvb2xzOjxi
cj4NCjxicj4NCkZyYW1lZC1Qb29sICg4OCwgc2VjdGlvbiA1LjE4IG9mIFJGQzI4NjkpLDxicj4N
CkZyYW1lZC1JUHY2LVBvb2wgKDEwMCwgc2VjdGlvbiAyLjYgb2YgUkZDMzE2MikuPGJyPg0KPGJy
Pg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9yYWRpdXMtdHlwZXMv
cmFkaXVzLXR5cGVzLnhtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNz
aWdubWVudHMvcmFkaXVzLXR5cGVzL3JhZGl1cy10eXBlcy54bWw8L2E+PGJyPg0KPGJyPg0KVGhl
IGZvcmFtdCBhcmUgdGhlIHNhbWUgYXMgZm9sbG93czo8YnI+DQo8YnI+DQowICZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzEgJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Mjxicj4NCjAgMSAyIDMgNCA1IDYg
NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzPGJyPg0KJiM0MzstJiM0MzstJiM0Mzst
JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0
MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst
JiM0MzstJiM0MzstJiM0Mzs8YnI+DQp8ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1R5cGUgJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCAmbmJzcDsmbmJzcDsmbmJzcDtMZW5ndGggJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTdHJpbmcuLi48
YnI+DQomIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz
Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m
IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxicj4NCjxicj4NCmRyYWZ0
LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLTA1IGlzIHByb3Bvc2luZyAyIG5ldyBhdHRyaWJ1dGVz
IGZvciBhZGRyZXNzL3ByZWZpeCBwb29sczo8YnI+DQo8YnI+DQpEZWxlZ2F0ZWQtSVB2Ni1QcmVm
aXgtUG9vbCw8YnI+DQpTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCw8YnI+DQo8YnI+DQp0aGUg
Zm9tYXQgb2YgdGhlc2UgMiBhdHRyaWJ1dGVzIGFyZSB0aGUgc2FtZSBhcyB0aGUgYWJvdmUgb25l
Ljxicj4NCjxicj4NCjxicj4NClN1cHBvc2VkIHRoZSBhYm92ZSBhdHRyaWJ1dGVzIGNvdWxkIGJl
IGV4cGxhaW5lZCBhcyBmb2xsb3dzOjxicj4NCjxicj4NCkZyYW1lZC1Qb29sIHdhcyBkZXNpZ25l
ZCBmb3IgdGhlIElQdjQgYWRkcmVzcyBwb29sOzxicj4NCkZyYW1lZC1JUHY2LVBvb2wgd2FzIGRl
c2lnbmVkIGZvciB0aGUgSVB2NiBTTEFBQyBwcmVmaXggcG9vbDs8YnI+DQpEZWxlZ2F0ZWQtSVB2
Ni1QcmVmaXgtUG9vbCBpcyBkZXNpZ25lZCBmb3IgREhDUHY2LVBEIHByZWZpeCBwb29sOzxicj4N
ClN0YXRlZnVsLUlQdjYtQWRkcmVzcy1Qb29sIGlzIGRlc2lnbmVkIGZvciBESENQdjYgYWRkcmVz
cyBwb29sOzxicj4NCjxicj4NCkFsbCBhYm92ZSBhdHRyaWJ1dGVzIGFyZSBvbmx5IHVzZWQgdG8g
cHJvdmlkZSB0aGUgbmFtZSBvZiB0aGUgYWRkcmVzcy9wcmVmaXggcG9vbHMgaW4gYSAnc3RyaW5n
Jy4gSSBkb3VidCB0aGUgbmVjZXNzaXR5IHRvIG1ha2Ugc28gbWFueSAnbmFtZScgb3IgJ3N0cmlu
ZycgYXR0cmlidXRlcyBmb3IgdGhlIGRpZmZlcmVudCBhZGRyZXNzL3ByZWZpeCBwb29scyB0byBw
cmV2ZW50IHRoZSBhbWJpZ3VpdHkuIEkgZ3Vlc3MgMSBhdHRyaWJ1dGUgZm9yIHRoZQ0KIG5hbWUg
b2YgdGhlIGFkZHJlc3MvcHJlZml4IHBvb2xzIG1pZ2h0IGJlIGVub3VnaC4gSW4gZmFjdCwgdGhl
IE5BUyB0YWtlIHRoZSByb2xlIHRvIGludGVycHJldCB0aGUgbWVhbmluZyBvZiB0aGUgcG9vayBu
YW1lLCByaWdodD88YnI+DQo8YnI+DQpJIHRoaW5rIEZyYW1lZC1Qb29sIGNhbiBiZSByZS11c2Vk
IGZvciB0aGUgZGVzaWduIHB1cnBvc2Ugb2YgU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wuIERv
IHdlIGhhdmUgYW55IGxpbWl0YXRpb24gb24gdGhlIHVzYWdlIG9mIEZyYW1lZC1Qb29sIGZvciBJ
UHY2Pzxicj4NCkkgdGhpbmsgRnJhbWVkLUlQdjYtUG9vbCBjYW4gYmUgcmUtdXNlZCBmb3IgdGhl
IGRlc2lnbiBwdXJwb3NlIG9mIERlbGVnYXRlZC1JUHY2LVByZWZpeC1Qb29sIHRvIGluZGljYXRl
IGEgcG9vbCBvZiBJUHY2IHByZWZpeCBwb29sLiBJIGNvdWxkIGV2ZW4gdGhpbmsgRnJhbWVkLVBv
b2wgY2FuIHJlcGxhY2UgRnJhbWVkLUlQdjYtUG9vbCB0byBpbmRpY2F0ZSB0aGUgbmFtZSBvZiBh
IElQdjYgcHJlZml4L2FkZHJlc3MgcG9vbCBwZXIgdGhlIHNhbWUNCiBsb2dpYy4gQW0gSSByaWdo
dD88YnI+DQo8YnI+DQo8YnI+DQpCZXN0IFJlZ2FyZHMsPGJyPg0KTGVhZjxicj4NCjxicj4NCjxi
cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N
Cjxicj4NClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0
aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNv
cGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBk
aSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3Jh
IGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXINCiBlcnJvcmUgc2lldGUgY29y
dGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0
dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuPGJyPg0K
VGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBj
b250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUo
cykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJv
ZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp
cGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlDQogYW5kIGFueSBhdHRhY2htZW50cyBh
bmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLjxicj4NClJpc3Bl
dHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNz
YXJpby48YnI+DQo8YnI+DQo8YnI+DQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRp
IHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBM
YSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRh
bGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUg
dmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyDQog
ZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211
bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9u
ZSwgR3JhemllLjxicj4NCjxicj4NClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMg
Y29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVu
ZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHBy
aW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJl
IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZQ0K
IGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1h
aWwsIFRoYW5rcy48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5RdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5k
aXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNp
b25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9z
Y2VuemEgZGkgcXVlc3RlDQogaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRl
LiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNp
ZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25l
IGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3Jhemll
Lg0KPGJyPg0KPGk+VGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRp
YWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRo
ZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcgb3Ig
dXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp
bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcw0KIG1lc3NhZ2UgYW5kIGFueSBh
dHRhY2htZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtz
LjwvaT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjwv
c3Bhbj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZh
bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJpc3BldHRh
IGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJp
by48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8
YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk
YW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1
b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUg
aW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBk
ZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUNCiBpbmZvcm1hemlvbmkgc29ubyBy
aWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9j
dW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1t
ZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3Vh
IGRpc3RydXppb25lLCBHcmF6aWUuDQo8YnI+DQo8aT5UaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFj
aG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1h
dGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBj
b3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4g
SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlz
DQogbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSBy
ZXR1cm4gZS1tYWlsLCBUaGFua3MuPC9pPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+UmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWls
IHNlIG5vbiDDqCBuZWNlc3NhcmlvLjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--Boundary_(ID_5sIeYiGktUaGsI5b0WMdKQ)--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 05 Aug 2011 21:54:56 +0000
Message-ID: <[e-mail]>
Date: Fri, 05 Aug 2011 17:53:48 -0400
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Deacon <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Subject: Re: Last call on extensions document?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Deacon wrote:
> This was never my intention.  My intention was a couple of paragraphs to
> explain a new data type attribute designers may want to take advantage
> of for their *future* work while implementing new attributes in the new
> attribute space.

  If it's in the doc, people will use it.  We need to agree that it's a
good idea before it's standardized.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 05 Aug 2011 16:21:44 +0000
Date: Fri, 5 Aug 2011 09:20:49 -0700 (Pacific Daylight Time)
From: Peter Deacon <[e-mail]>
To: Avi Lior <[e-mail]>
cc: Alan DeKok <[e-mail]>,  'radext mailing list' <[e-mail]>
Subject: Re: Last call on extensions document?
Message-ID: <alpine.WNT.2.00.1108050907250.3484@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Fri, 5 Aug 2011, Avi Lior wrote:

> I also support the notion of having a "family-specific" attribute set.

I'm sorry for any confusion.  The intent was never to "take away" any 
options that already exist.  I certainly am not suggesting any current 
attributes be changed in any way.

All I suggested is that a new "data type" be specified allowing single IP 
Addresses to be conveyed in either IPv4 or IPv6 address family.

It would be up to the designer of a new attribute to weigh the pros and 
cons and select the appropriate data type.  This would simply be another 
tool in the extensions toolbox at their disposal.

> My reasons are somewhat different.
> In the case of carrying a "pure" IPv6 address and a pure IPv4 address then
> the argument for having a single attribute to carry both makes sense.

My recommendation is limited to anything that would currently fit in the 
IPv4 or IPv6 address data types.

regards,
Peter

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 05 Aug 2011 15:52:17 +0000
Date: Fri, 5 Aug 2011 08:51:19 -0700 (Pacific Daylight Time)
From: Peter Deacon <[e-mail]>
To: Alan DeKok <[e-mail]>
cc: 'radext mailing list' <[e-mail]>
Subject: Re: Last call on extensions document?
Message-ID: <alpine.WNT.2.00.1108050844590.3484@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Fri, 5 Aug 2011, Alan DeKok wrote:

>> Use of naming services to abstract network addresses is universal.  Kind
>> of the whole point of using these systems in the first place.

>  What I meant was that *unexpected* changes are a problem.  DNS is
> nice, and useful for many things.  RADIUS policies are usually
> relatively fixed.  Having them depend on DNS means that a non-RADIUS
> admin can effectively update the RADIUS policies.

>  I've seen this cause problems in practice, which makes me wary of it.

By specifying a name you delegate responsibility for resolution to the 
naming service.  This is always the case no matter where that name is 
stored.

>> Without combo IP the system needs *extra* intelligence to know the IPv4
>> and IPv6 analogue for each attribute.  With combo IP this is unnecessary
>> as the same attribute can be used and the system just works.

>  The main way I can see combo IP being useful is if family-specific
> attributes were to be deprecated.

>  Unless there's a groundswell of support for it on this list, I don't
> see combo-IP making it into the document.

This was never my intention.  My intention was a couple of paragraphs to 
explain a new data type attribute designers may want to take advantage of 
for their *future* work while implementing new attributes in the new 
attribute space.

regards,
Peter

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 05 Aug 2011 15:25:39 +0000
From: Avi Lior <[e-mail]>
To: Alan DeKok <[e-mail]>, Peter Deacon <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Date: Fri, 5 Aug 2011 11:24:46 -0400
Subject: Re: Last call on extensions document?
Thread-Topic: Last call on extensions document?
Thread-Index: AcxTg87Fq/LeDTevRzir+4wj4wBvVw==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.12.0.110505
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I also support the notion of having a "family-specific" attribute set.

My reasons are somewhat different.

In the case of carrying a "pure" IPv6 address and a pure IPv4 address then
the argument for having a single attribute to carry both makes sense.

However, IPv6 addresses have different flavours.  Sometime I want to carry
a "pure" IPv6 address, sometimes I want to convey just the prefix and
sometimes I want to convey the prefix and the interface and thus I need to
include the prefix length in the address.  There are examples of these
encodings already in the IETF.

A family-specific approach is good.  Thus if we want to create such a
beast for IPv6 addresses we should create an attribute that can meet all
the use cases or have an attribute type for each use case.

Avi

On 11-08-04 20:52 , "Alan DeKok" <[e-mail]> wrote:

>Peter Deacon wrote:
>> In most cases where an attribute of type IP Address needs to be defined
>> there will be a need for an IPv6 analogue of that same attribute.
>
>  OK.
>
>> There are implementation costs and operational costs associated with the
>> approach of segregating address families.  Costs can be reduced somewhat
>> with a ComboIP (Payload Len 4 =3D IPv4, 16 =3D IPv6) data type.
>>=20
>> Currently:
>>=20
>> 1. Multiple attributes need to be defined.
>
>  With 1000+ new attributes and TLVs, I'm not sure this is an issue.
>
>> 2. Operators entering an IP Address into fields need to make sure they
>> select the correct attribute based on the address family they are
>> targeting.
>
>  That's a UI problem.  The system in which they enter the IP should
>know (a) the address family, and (b) the relevant attribute.  There's no
>reason to force the admin to make those choices.
>
>> Operators may enter a hostname and have the system enter the resolved
>> address.  In this case the operator may have no knowledge of the address
>> family or it may change tomorrow!
>
>  Which is a disaster for maintainable systems.  Having the RADIUS
>response change because of modifications to DNS is terrible.  I strongly
>oppose that kind of setup.
>
>> The system will need to provide additional intelligence during the name
>> lookup process to select the proper attribute based on address family
>> for each instance.
>
>  It can send multiple attributes.  Foo-IPv4, Foo-IPv6, Foo-IPv4, etc.
>
>  Why select?  If the DNS lookup provides 2 IPv4s, and 1 IPv6, why not
>send that in RADIUS?
>
>> We can live without however much like gigawords I believe with the new
>> attribute space comes some opportunity to improve the standard framework
>> for future attributes.
>
>  Of course.
>
>  While adding "combo IP" seems OK for WiMAX, I'm not convinced that the
>above use-cases *require* it.  The same result can be achieved with
>family-specific attributes.
>
>  Alan DeKok.
>
>--
>to unsubscribe send a message to [e-mail] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 05 Aug 2011 11:48:32 +0000
Message-ID: <[e-mail]>
Date: Fri, 05 Aug 2011 07:47:32 -0400
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Deacon <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Subject: Re: Last call on extensions document?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Deacon wrote:
>>  Which is a disaster for maintainable systems.  Having the RADIUS
>> response change because of modifications to DNS is terrible.  I strongly
>> oppose that kind of setup.
> 
> Use of naming services to abstract network addresses is universal.  Kind
> of the whole point of using these systems in the first place.

  What I meant was that *unexpected* changes are a problem.  DNS is
nice, and useful for many things.  RADIUS policies are usually
relatively fixed.  Having them depend on DNS means that a non-RADIUS
admin can effectively update the RADIUS policies.

  I've seen this cause problems in practice, which makes me wary of it.

> Without combo IP the system needs *extra* intelligence to know the IPv4
> and IPv6 analogue for each attribute.  With combo IP this is unnecessary
> as the same attribute can be used and the system just works.

  The main way I can see combo IP being useful is if family-specific
attributes were to be deprecated.

  Unless there's a groundswell of support for it on this list, I don't
see combo-IP making it into the document.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 05 Aug 2011 04:57:48 +0000
Date: Thu, 4 Aug 2011 21:45:25 -0700 (Pacific Daylight Time)
From: Peter Deacon <[e-mail]>
To: Alan DeKok <[e-mail]>
cc: 'radext mailing list' <[e-mail]>
Subject: Re: Last call on extensions document?
Message-ID: <alpine.WNT.2.00.1108042112130.3484@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Thu, 4 Aug 2011, Alan DeKok wrote:

> Peter Deacon wrote:
>> In most cases where an attribute of type IP Address needs to be defined
>> there will be a need for an IPv6 analogue of that same attribute.

>> There are implementation costs and operational costs associated with the
>> approach of segregating address families.  Costs can be reduced somewhat
>> with a ComboIP (Payload Len 4 = IPv4, 16 = IPv6) data type.

>> Currently:
>> 1. Multiple attributes need to be defined.

>  With 1000+ new attributes and TLVs, I'm not sure this is an issue.

It is unecessary, redundant and wasteful.

>> 2. Operators entering an IP Address into fields need to make sure they
>> select the correct attribute based on the address family they are
>> targeting.

>  That's a UI problem.  The system in which they enter the IP should
> know (a) the address family, and (b) the relevant attribute.  There's no
> reason to force the admin to make those choices.

Its a problem that does not need to exist.  Regardless of where you punt 
for those attributes taking advantage of combo IP the issue goes away.

>> Operators may enter a hostname and have the system enter the resolved
>> address.  In this case the operator may have no knowledge of the address
>> family or it may change tomorrow!

>  Which is a disaster for maintainable systems.  Having the RADIUS
> response change because of modifications to DNS is terrible.  I strongly
> oppose that kind of setup.

Use of naming services to abstract network addresses is universal.  Kind 
of the whole point of using these systems in the first place.

>> The system will need to provide additional intelligence during the name
>> lookup process to select the proper attribute based on address family
>> for each instance.

>  It can send multiple attributes.  Foo-IPv4, Foo-IPv6, Foo-IPv4, etc.

>  Why select?  If the DNS lookup provides 2 IPv4s, and 1 IPv6, why not
> send that in RADIUS?

Of course you can enumerate the result of name lookups and send multiple 
attributes if there are multiple results.  I never suggested otherwise.

Without combo IP the system needs *extra* intelligence to know the IPv4 
and IPv6 analogue for each attribute.  With combo IP this is unnecessary as 
the same attribute can be used and the system just works.

>> We can live without however much like gigawords I believe with the new
>> attribute space comes some opportunity to improve the standard framework
>> for future attributes.
>
>  Of course.
>
>  While adding "combo IP" seems OK for WiMAX, I'm not convinced that the
> above use-cases *require* it.  The same result can be achieved with
> family-specific attributes.

64-bit integers are not required to convey 64-bit data types.  There are 
thousands of attributes available.  The same result can be achieved with 
gigawords.

*require* is not the point.  I think this was made pretty clear in the "we 
can live without" language used above.

regards,
Peter

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 05 Aug 2011 00:52:54 +0000
Message-ID: <[e-mail]>
Date: Thu, 04 Aug 2011 20:52:00 -0400
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Deacon <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Subject: Re: Last call on extensions document?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Deacon wrote:
> In most cases where an attribute of type IP Address needs to be defined
> there will be a need for an IPv6 analogue of that same attribute.

  OK.

> There are implementation costs and operational costs associated with the
> approach of segregating address families.  Costs can be reduced somewhat
> with a ComboIP (Payload Len 4 = IPv4, 16 = IPv6) data type.
> 
> Currently:
> 
> 1. Multiple attributes need to be defined.

  With 1000+ new attributes and TLVs, I'm not sure this is an issue.

> 2. Operators entering an IP Address into fields need to make sure they
> select the correct attribute based on the address family they are
> targeting.

  That's a UI problem.  The system in which they enter the IP should
know (a) the address family, and (b) the relevant attribute.  There's no
reason to force the admin to make those choices.

> Operators may enter a hostname and have the system enter the resolved
> address.  In this case the operator may have no knowledge of the address
> family or it may change tomorrow!

  Which is a disaster for maintainable systems.  Having the RADIUS
response change because of modifications to DNS is terrible.  I strongly
oppose that kind of setup.

> The system will need to provide additional intelligence during the name
> lookup process to select the proper attribute based on address family
> for each instance.

  It can send multiple attributes.  Foo-IPv4, Foo-IPv6, Foo-IPv4, etc.

  Why select?  If the DNS lookup provides 2 IPv4s, and 1 IPv6, why not
send that in RADIUS?

> We can live without however much like gigawords I believe with the new
> attribute space comes some opportunity to improve the standard framework
> for future attributes.

  Of course.

  While adding "combo IP" seems OK for WiMAX, I'm not convinced that the
above use-cases *require* it.  The same result can be achieved with
family-specific attributes.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Thu, 04 Aug 2011 17:54:52 +0000
Date: Thu, 4 Aug 2011 10:53:24 -0700 (Pacific Daylight Time)
From: Peter Deacon <[e-mail]>
To: Alan DeKok <[e-mail]>
cc: 'radext mailing list' <[e-mail]>
Subject: Re: Last call on extensions document?
Message-ID: <alpine.WNT.2.00.1108040938170.3484@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 2 Aug 2011, Alan DeKok wrote:

>> As IPv6 is deployed following the current scheme of keeping address
>> families separated into separate attributes wherever addresses are used
>> will become problematic as cases where the address family is not known
>> in advance creep up.

>  My $0.02 is that it would be better to use TLVs.  But I welcome an
> inspired discussion on the topic. :)

In most cases where an attribute of type IP Address needs to be defined 
there will be a need for an IPv6 analogue of that same attribute.

Some examples:

Naming services
Access control and filtering
Flow export and logging servers
Application proxies (smtp, web content filter..etc)
App specific services


There are implementation costs and operational costs associated with the 
approach of segregating address families.  Costs can be reduced somewhat 
with a ComboIP (Payload Len 4 = IPv4, 16 = IPv6) data type.

Currently:

1. Multiple attributes need to be defined.

2. Operators entering an IP Address into fields need to make sure they 
select the correct attribute based on the address family they are 
targeting.

Operators may enter a hostname and have the system enter the resolved 
address.  In this case the operator may have no knowledge of the address 
family or it may change tomorrow!

The system will need to provide additional intelligence during the name 
lookup process to select the proper attribute based on address family for 
each instance.





We can live without however much like gigawords I believe with the new 
attribute space comes some opportunity to improve the standard framework 
for future attributes.

regards,
Peter

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 03 Aug 2011 02:36:37 +0000
Message-ID: <[e-mail]>
Date: Tue, 02 Aug 2011 22:35:42 -0400
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>
Subject: i18n and RADIUS
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  As discussed at the last IETF, RFC 4282 has some problems.  My draft
(expired) describes the issues, and proposes a way to address them.

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

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

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

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

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 02 Aug 2011 22:49:24 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_9dea068e-fc81-4966-b73d-20faca6c3bed_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
CC: <[e-mail]>, "[e-mail]" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: =?gb2312?B?UkU6ILTwuLQ6IFEg?= =?gb2312?Q?on_Ver.-05?= =?gb2312?Q?_of_draft-?= =?gb2312?Q?ietf-radex?= =?gb2312?Q?t-ipv6-acc?= =?gb2312?Q?ess_after_?= =?gb2312?Q?IETF81_rad?= =?gb2312?Q?ext_sessio?= =?gb2312?Q?n?=
Date: Tue, 2 Aug 2011 15:48:13 -0700
MIME-Version: 1.0

--_9dea068e-fc81-4966-b73d-20faca6c3bed_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 8bit


In general, the concern that has lead to defining these distinct pools is the possibility that multiple pool types might be enabled for a single session.  For example, it's possible that an IPv6 address might be assigned from a pool, and at the same time that a Prefix might be delegated from a pool, for the same user and session.  In such a situation,  using the same pool name for multiple purposes could be ambiguous and/or under-specified.  

A note about Woj's concern about errors.  With respect to a server sending an attribute that a client does not understand, RFC 5080 Section 2.5 provides guidance:

   In general, it is best for a RADIUS client to err on the side of
   caution.  On receiving an Access-Accept including an attribute of
   known Type for an unimplemented service, a RADIUS client MUST treat
   it as an Access-Reject, as directed in [RFC2865] Section 1.1.  On
   receiving an Access-Accept including an attribute of unknown Type, a
   RADIUS client SHOULD assume that it is a potential service
   definition, and treat it as an Access-Reject.  Unknown VSAs SHOULD be
   ignored by RADIUS clients.As a result, it is possible that a client not implementing the IPv6 Access RFC will ignore the attributes (e.g. not implement the SHOULD) rather than refusing to provide service. 

Date: Mon, 1 Aug 2011 12:47:38 -0400
Subject: Re: ´ð¸´: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: [e-mail]
To: [e-mail]; [e-mail]; [e-mail]
CC: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]





Re: ´ð¸´: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session


Hi All,



Allow me to share some comments:



There is precedent of multiple ¡°specific¡± named pools; Framed-Pool, Framed-IPv6-Pool, and the uncontested Delegated-IPv6-Prefix-Pool. There is also a special code in the Framed-IPX-Network attribute that conveys it pool like characteristics. 
There is little that disallows a vendor from implementing just one named pool for all protocols and all methods of assignment ( the Framed-Pool appears to have been envisaged for that ) and then using some implementation specific logic (eg parsing for a name) to figure out/how it¡¯s to be used. 
The problem with relying on implementation specific features riding on standard Attributes, as opposed to say VSAs, is that nothing indicates to the server/client if the recipient actually supports such special features and assures correct interpretation. Eg if we used the Framed-Pool as the ONE named pool attribute, with a carried string ¡°IPv4¡±, ¡°IPv6¡± or ¡°DHCPv6-PD¡±, etc, parsed/whatever to indicate the role, it would be all doable, but a likely mess should anything go wrong (eg a device not supporting some mode), without clear indication of error.



Since the Radius specification is NOT about specifying implementation the only reliable/unambiguous manner in which different pools/methods can be utilized would appear to be using different attributes as proposed in the current draft. Time (precedent) also appears to have proved this as a desirable protocol characteristic. 

Are there any other options/solutions available that do not call on implicit features being there?



Regards,

Wojciech.





On 26/07/2011 22:51, "Leaf yeh" <[e-mail]> wrote:



[RM] NAS can have many pools configured 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



 



 



·¢¼þÈË: Maglione Roberta [[e-mail]]

·¢ËÍʱ¼ä: 2011Äê7ÔÂ27ÈÕ 3:54

µ½: Leaf yeh; 'Jacni Qin'

Cc: [e-mail]; [e-mail]; [e-mail]; Qiujin; Wangshuxiang

Ö÷Ìâ: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session



 

 






From: Leaf yeh [mailto:[e-mail]] 

Sent: marted¨¬ 26 luglio 2011 21.50

To: Maglione Roberta; 'Jacni Qin'

Cc: [e-mail]; [e-mail]; [e-mail]; Qiujin; Wangshuxiang

Subject: ´ð¸´: 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, in 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 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 configured locally: how does the NAS know which pool is for SLAAC and which pool is for DHCPv6?



 



Roberta



 



Best Regards,



Leaf



 



 



 






·¢¼þÈË: Maglione Roberta [[e-mail]]

·¢ËÍʱ¼ä: 2011Äê7ÔÂ27ÈÕ 2:27

µ½: Leaf yeh; 'Jacni Qin'

Cc: [e-mail]; [e-mail]; [e-mail]; Qiujin; Wangshuxiang

Ö÷Ìâ: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session



Please see inline.

 

Best regards,

Roberta

 






From: Leaf yeh [mailto:[e-mail]] 

Sent: marted¨¬ 26 luglio 2011 20.22

To: Maglione Roberta; 'Jacni Qin'

Cc: [e-mail]; [e-mail]; [e-mail]; Qiujin; Wangshuxiang

Subject: ´ð¸´: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session

 



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?



[RM] yes pools are already configured in the NAS



 



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



 



[RM] All the configured pools are the same for the NAS, in 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¡¯s why in my opinion the Stateful-IPv6-Address-Pool is required.



 



 



Best Regards,



Leaf



 



 






·¢¼þÈË: Maglione Roberta [[e-mail]]

·¢ËÍʱ¼ä: 2011Äê7ÔÂ27ÈÕ 2:13

µ½: 'Jacni Qin'

Cc: Leaf yeh; [e-mail]; [e-mail]; [e-mail]; Qiujin; Wangshuxiang

Ö÷Ìâ: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after 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 [mailto:[e-mail]]

Sent: marted¨¬ 26 luglio 2011 20.03

To: Maglione Roberta

Cc: Leaf yeh; [e-mail]; [e-mail]; [e-mail]; 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 <[e-mail]> 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 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 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 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 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: [e-mail] [mailto:[e-mail]] On Behalf Of Leaf yeh

Sent: luned¨¬ 25 luglio 2011 18.23

To: [e-mail]; [e-mail]

Cc: [e-mail]; 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-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

























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.

Rispetta l'ambiente. Non stampare questa mail se non ¨¨ 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 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.



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. Rispetta l'ambiente. Non stampare questa mail se non ¨¨ 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 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. Rispetta l'ambiente. Non stampare questa mail se non ¨¨ necessario. 



 		 	   		  
--_9dea068e-fc81-4966-b73d-20faca6c3bed_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: 8bit

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'><div dir='ltr'>
In general, the concern that has lead to defining these distinct pools is the possibility that multiple pool types might be enabled for a single session.&nbsp; For example, it's possible that an IPv6 address might be assigned from a pool, and at the same time that a Prefix might be delegated from a pool, for the same user and session.&nbsp; In such a situation,&nbsp; using the same pool name for multiple purposes could be ambiguous and/or under-specified.&nbsp; <br><br>A note about Woj's concern about errors.&nbsp; With respect to a server sending an attribute that a client does not understand, RFC 5080 Section 2.5 provides guidance:<br><br><pre class="newpage">   In general, it is best for a RADIUS client to err on the side of
   caution.  On receiving an Access-Accept including an attribute of
   known Type for an unimplemented service, a RADIUS client MUST treat
   it as an Access-Reject, as directed in <a href="http://tools.ietf.org/html/rfc2865#section-1.1">[RFC2865] Section&nbsp;1.1</a>.  On
   receiving an Access-Accept including an attribute of unknown Type, a
   RADIUS client SHOULD assume that it is a potential service
   definition, and treat it as an Access-Reject.  Unknown VSAs SHOULD be
   ignored by RADIUS clients.</pre>As a result, it is possible that a client not implementing the IPv6 Access RFC will ignore the attributes (e.g. not implement the SHOULD) rather than refusing to provide service. <br><br><div><hr id="stopSpelling">Date: Mon, 1 Aug 2011 12:47:38 -0400<br>Subject: Re: ´ð¸´: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>From: [e-mail]<br>To: [e-mail]; [e-mail]; [e-mail]<br>CC: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]<br><br>

<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<title>Re: ´ð¸´: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session</title>


<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">Hi All,<br>
<br>
Allow me to share some comments:<br>
<br>
</span></font><ul><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">There is precedent of multiple ¡°specific¡± named pools; Framed-Pool, Framed-IPv6-Pool, and the uncontested Delegated-IPv6-Prefix-Pool. There is also a special code in the Framed-IPX-Network attribute that conveys it pool like characteristics. 
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">There is little that disallows a vendor from implementing just one named pool for all protocols and all methods of assignment ( the Framed-Pool appears to have been envisaged for that ) and then using some implementation specific logic (eg parsing for a name) to figure out/how it¡¯s to be used. 
</span></font></li><li><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">The problem with relying on implementation specific features riding on standard Attributes, as opposed to say VSAs, is that nothing indicates to the server/client if the recipient actually supports such special features and assures correct interpretation. Eg if we used the Framed-Pool as the ONE named pool attribute, with a carried string ¡°IPv4¡±, ¡°IPv6¡± or ¡°DHCPv6-PD¡±, etc, parsed/whatever to indicate the role, it would be all doable, but a likely mess should anything go wrong (eg a device not supporting some mode), without clear indication of error.<br>
</span></font></li></ul><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><br>
Since the Radius specification is NOT about specifying implementation the only reliable/unambiguous manner in which different pools/methods can be utilized would appear to be using different attributes as proposed in the current draft. Time (precedent) also appears to have proved this as a desirable protocol characteristic. <br>
Are there any other options/solutions available that do not call on implicit features being there?<br>
<br>
Regards,<br>
Wojciech.<br>
<br>
<br>
On 26/07/2011 22:51, "Leaf yeh" &lt;<a href="http://[e-mail]" target="_blank">[e-mail]</a>&gt; wrote:<br>
<br>
</span></font><blockquote><font color="#000080"><font size="2"><font face="Arial"><span style="font-size:10pt">[RM] NAS can have many pools configured locally: how does the NAS know which pool is for SLAAC and which pool is for DHCPv6?<br>
</span></font></font></font><font size="2"><span style="font-size:10pt"><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
I supposed the local configuration on the NAS will answer this question.<br>
<br>
&nbsp;<br>
<br>
Best Regards,<br>
<br>
Leaf<br>
<br>
&nbsp;<br>
<br>
&nbsp;<br>
<br>
<hr align="CENTER" size="3" width="100%"></font></span></font><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:11pt"><b>·¢¼þÈË:</b></span><font size="2"><span style="font-size:10pt"> Maglione Roberta [<a href="http://[e-mail]" target="_blank">[e-mail]</a>]<br>
<b>·¢ËÍʱ¼ä:</b> 2011Äê7ÔÂ27ÈÕ 3:54<br>
<b>µ½:</b> Leaf yeh; 'Jacni Qin'<br>
<b>Cc:</b> <a href="http://[e-mail]" target="_blank">[e-mail]</a>; <a href="http://[e-mail]" target="_blank">[e-mail]</a>; <a href="http://[e-mail]" target="_blank">[e-mail]</a>; Qiujin; Wangshuxiang<br>
<b>Ö÷Ìâ:</b> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>
<br>
</span></font></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"> <br>
&nbsp;<br>
</span></font><font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt">
</span></font></font>
<p align="CENTER">
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"></span></font></p><hr align="CENTER" size="2" width="100%">

<font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt"><b>From:</b> Leaf yeh [<a href="mailto:[e-mail]">mailto:[e-mail]</a>] <br>
<b>Sent:</b> marted¨¬ 26 luglio 2011 21.50<br>
<b>To:</b> Maglione Roberta; 'Jacni Qin'<br>
<b>Cc:</b> <a href="http://[e-mail]" target="_blank">[e-mail]</a>; <a href="http://[e-mail]" target="_blank">[e-mail]</a>; <a href="http://[e-mail]" target="_blank">[e-mail]</a>; Qiujin; Wangshuxiang<br>
<b>Subject:</b> </span></font><span style="font-size:10pt"><font face="Calibri, Verdana, Helvetica, Arial">´ð¸´</font><font face="Tahoma, Verdana, Helvetica, Arial">: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>
</font></span></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"> <br>
</span></font><font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt"><br>
</span></font><span style="font-size:10pt"><font color="#000080"><font face="Arial">[RM] All the configured pools are the same for the NAS, in this case an extra logic would be needed to instruct the NAS about which pool is for SLAAC and which one is for DHCPv6<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
</font><font color="#000080"><font face="Arial">The pools configured on the 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?<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
</font><font color="#000080"><font face="Arial">[RM] NAS can have many pools configured locally: how does the NAS know which pool is for SLAAC and which pool is for DHCPv6?<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
</font><font color="#000080"><font face="Arial">Roberta<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
</font><font color="#000080"><font face="Arial">Best Regards,<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
</font><font color="#000080"><font face="Arial">Leaf<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
&nbsp;<br>
<br>
&nbsp;<br>

</font></span></font>
<BR><p align="CENTER">
<font size="2"><span style="font-size:10pt"><font face="Tahoma, Verdana, Helvetica, Arial"></font></span></font></p><hr align="CENTER" size="2" width="100%">

<font size="2"><span style="font-size:10pt"><font face="Calibri, Verdana, Helvetica, Arial"><b>·¢¼þÈË</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> Maglione Roberta [<a href="http://[e-mail]" target="_blank">[e-mail]</a>]<br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><b>·¢ËÍʱ¼ä</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> 2011</font><font face="Calibri, Verdana, Helvetica, Arial">Äê</font><font face="Tahoma, Verdana, Helvetica, Arial">7</font><font face="Calibri, Verdana, Helvetica, Arial">ÔÂ</font><font face="Tahoma, Verdana, Helvetica, Arial">27</font><font face="Calibri, Verdana, Helvetica, Arial">ÈÕ</font><font face="Tahoma, Verdana, Helvetica, Arial"> 2:27<br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><b>µ½</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> Leaf yeh; 'Jacni Qin'<br>
<b>Cc:</b> <a href="http://[e-mail]" target="_blank">[e-mail]</a>; <a href="http://[e-mail]" target="_blank">[e-mail]</a>; <a href="http://[e-mail]" target="_blank">[e-mail]</a>; Qiujin; Wangshuxiang<br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><b>Ö÷Ìâ</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>
<br>
</font><font color="#000080"><font face="Arial">Please see inline.<br>
</font></font></span></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"> <br>
</span></font><font color="#000080"><font size="2"><font face="Arial"><span style="font-size:10pt">Best regards,<br>
Roberta<br>
</span></font></font></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"> <br>
</span></font><font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt">
</span></font></font>
<BR><p align="CENTER">
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"></span></font></p><hr align="CENTER" size="2" width="100%">

<font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt"><b>From:</b> Leaf yeh [<a href="mailto:[e-mail]">mailto:[e-mail]</a>] <br>
<b>Sent:</b> marted¨¬ 26 luglio 2011 20.22<br>
<b>To:</b> Maglione Roberta; 'Jacni Qin'<br>
<b>Cc:</b> <a href="http://[e-mail]" target="_blank">[e-mail]</a>; <a href="http://[e-mail]" target="_blank">[e-mail]</a>; <a href="http://[e-mail]" target="_blank">[e-mail]</a>; Qiujin; Wangshuxiang<br>
<b>Subject:</b> </span></font><span style="font-size:10pt"><font face="Calibri, Verdana, Helvetica, Arial">´ð¸´</font><font face="Tahoma, Verdana, Helvetica, Arial">: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>
</font></span></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"> <br>
</span></font><font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt"><br>
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?<br>
<br>
NAS already has those pool names in its configuration, right?<br>
<br>
</span></font><span style="font-size:10pt"><font color="#000080"><font face="Arial">[RM] yes pools are already configured in the NAS<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
NAS does know which one is for SLAAC prefix pool, which one is for DHCPv6 address pool. <br>
<br>
&nbsp;<br>
<br>
</font><font color="#000080"><font face="Arial">[RM] All the configured pools are the same for the NAS, in this case an extra logic would be needed to instruct the NAS about which pool is for SLAAC and which one is for DHCPv6<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
&nbsp;<br>
<br>
&nbsp;<br>
<br>
</font><font color="#000080"><font face="Arial">That¡¯s why in my opinion the Stateful-IPv6-Address-Pool is required.<br>
</font></font><font face="Tahoma, Verdana, Helvetica, Arial"><br>
&nbsp;<br>
<br>
&nbsp;<br>
<br>
Best Regards,<br>
<br>
Leaf<br>
<br>
&nbsp;<br>
<br>
&nbsp;<br>

</font></span></font>
<BR><p align="CENTER">
<font size="2"><span style="font-size:10pt"><font face="Tahoma, Verdana, Helvetica, Arial"></font></span></font></p><hr align="CENTER" size="2" width="100%">

<font size="2"><span style="font-size:10pt"><font face="Calibri, Verdana, Helvetica, Arial"><b>·¢¼þÈË</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> Maglione Roberta [<a href="http://[e-mail]" target="_blank">[e-mail]</a>]<br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><b>·¢ËÍʱ¼ä</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> 2011</font><font face="Calibri, Verdana, Helvetica, Arial">Äê</font><font face="Tahoma, Verdana, Helvetica, Arial">7</font><font face="Calibri, Verdana, Helvetica, Arial">ÔÂ</font><font face="Tahoma, Verdana, Helvetica, Arial">27</font><font face="Calibri, Verdana, Helvetica, Arial">ÈÕ</font><font face="Tahoma, Verdana, Helvetica, Arial"> 2:13<br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><b>µ½</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> 'Jacni Qin'<br>
<b>Cc:</b> Leaf yeh; <a href="http://[e-mail]" target="_blank">[e-mail]</a>; <a href="http://[e-mail]" target="_blank">[e-mail]</a>; <a href="http://[e-mail]" target="_blank">[e-mail]</a>; Qiujin; Wangshuxiang<br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><b>Ö÷Ìâ</b></font><b><font face="Tahoma, Verdana, Helvetica, Arial">:</font></b><font face="Tahoma, Verdana, Helvetica, Arial"> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>
<br>
Hi Jacni,<br>
&nbsp;&nbsp;&nbsp;If you use the same attribute for both scenarios how does the NAS know if that pool is for SLAAC or for Stateful DHCPv6?<br>
<br>
Thanks,<br>
Regards,<br>
Roberta<br>
<br>
<br>
<br>
<br>
<br>
________________________________________<br>
From: Jacni Qin [<a href="mailto:[e-mail]">mailto:[e-mail]</a>]<br>
Sent: marted¨¬ 26 luglio 2011 20.03<br>
To: Maglione Roberta<br>
Cc: Leaf yeh; <a href="http://[e-mail]" target="_blank">[e-mail]</a>; <a href="http://[e-mail]" target="_blank">[e-mail]</a>; <a href="http://[e-mail]" target="_blank">[e-mail]</a>; Qiujin; Wangshuxiang<br>
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>
<br>
Hi Roberta,<br>
<br>
I agree with you about the semantical logic, while "Stateful-IPv6-Address-Pool" is not necessary, IMHO.<br>
<br>
<br>
Cheers,<br>
Jacni<br>
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta &lt;<a href="http://[e-mail]" target="_blank">[e-mail]</a>&gt; wrote:<br>
Hello Leaf,<br>
&nbsp;&nbsp;&nbsp;&nbsp;The different attributes proposed in this draft for the pools name have all the same format (a string), but semantically they are different, as they coved different scenarios.<br>
As you also summarized in your email below,<br>
<br>
Framed-Pool was designed for the IPv4 address pool;<br>
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;<br>
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;<br>
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;<br>
<br>
So each attribute covers a different use-case/scenario and they can appear in the same RADIUS packet at the same time.<br>
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 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.<br>
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.<br>
<br>
<br>
Thanks,<br>
Regards,<br>
Roberta<br>
<br>
<br>
<br>
<br>
<br>
________________________________________<br>
From: <a href="http://[e-mail]" target="_blank">[e-mail]</a> [<a href="mailto:[e-mail]">mailto:[e-mail]</a>] On Behalf Of Leaf yeh<br>
Sent: luned¨¬ 25 luglio 2011 18.23<br>
To: <a href="http://[e-mail]" target="_blank">[e-mail]</a>; <a href="http://[e-mail]" target="_blank">[e-mail]</a><br>
Cc: <a href="http://[e-mail]" target="_blank">[e-mail]</a>; Qiujin; Wangshuxiang<br>
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session<br>
<br>
Question for clarification:<br>
<br>
We already have the following Radius Attributes for the address/prefix pools:<br>
<br>
Framed-Pool (88, section 5.18 of RFC2869),<br>
Framed-IPv6-Pool (100, section 2.6 of RFC3162).<br>
<br>
<a href="http://www.iana.org/assignments/radius-types/radius-types.xml" target="_blank">http://www.iana.org/assignments/radius-types/radius-types.xml</a><br>
<br>
The foramt are the same as follows:<br>
<br>
0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2<br>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3<br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
| &nbsp;&nbsp;&nbsp;&nbsp;Type &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;&nbsp;Length &nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;&nbsp;&nbsp;String...<br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
<br>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/prefix pools:<br>
<br>
Delegated-IPv6-Prefix-Pool,<br>
Stateful-IPv6-Address-Pool,<br>
<br>
the fomat of these 2 attributes are the same as the above one.<br>
<br>
<br>
Supposed the above attributes could be explained as follows:<br>
<br>
Framed-Pool was designed for the IPv4 address pool;<br>
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;<br>
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;<br>
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;<br>
<br>
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?<br>
<br>
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?<br>
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?<br>
<br>
<br>
Best Regards,<br>
Leaf<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
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.<br>
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.<br>
Rispetta l'ambiente. Non stampare questa mail se non ¨¨ necessario.<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
</font></span></font><font size="1"><font face="Verdana, Helvetica, Arial"><span style="font-size:7pt">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. <br>
<i>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.</i></span><span style="font-size:9pt"> </span><span style="font-size:7pt"><b>Rispetta l'ambiente. Non stampare questa mail se non ¨¨ necessario.</b></span><span style="font-size:9pt"> <br>
</span></font></font><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:12pt"> <br>
</span></font><font size="1"><font face="Verdana, Helvetica, Arial"><span style="font-size:7pt">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. <br>
<i>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.</i></span><span style="font-size:9pt"> </span><span style="font-size:7pt"><b>Rispetta l'ambiente. Non stampare questa mail se non ¨¨ necessario.</b></span><span style="font-size:9pt"> <br>
</span></font></font><font size="2"><font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt"><br>
</span></font></font><BR></blockquote></div> 		 	   		  </div></body>
</html>
--_9dea068e-fc81-4966-b73d-20faca6c3bed_--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 02 Aug 2011 21:37:26 +0000
Message-ID: <[e-mail]>
Date: Tue, 02 Aug 2011 17:36:58 -0400
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Deacon <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Subject: Re: Last call on extensions document?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Deacon wrote:
> Aside from picking up the 64-bit int type my crystal ball is saying
> there will be increasing need for Combo-IP like data type to convey
> either IPv4 or IPv6 address information in one attribute.

  Oh, that scares me.

> As IPv6 is deployed following the current scheme of keeping address
> families separated into separate attributes wherever addresses are used
> will become problematic as cases where the address family is not known
> in advance creep up.

  My $0.02 is that it would be better to use TLVs.  But I welcome an
inspired discussion on the topic. :)

> Vendors are using it in their VSA spaces so why not just add a few
> paragraphs.  I'll volunteer.  This way future attributes with an IP data
> type have the option if makes sense for them.

  So far as I know, it's only WiMAX that does this.

> Thought about suggesting it in the IPv6 draft but perhaps better for
> everyone to get that one done ASAP.

  If everyone else here thinks it's a good idea, fine.  But I'm not sure
that's going to happen.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 02 Aug 2011 21:12:29 +0000
Date: Tue, 2 Aug 2011 14:11:18 -0700 (Pacific Daylight Time)
From: Peter Deacon <[e-mail]>
To: Alan DeKok <[e-mail]>
cc: 'radext mailing list' <[e-mail]>
Subject: Re: Last call on extensions document?
Message-ID: <alpine.WNT.2.00.1108021337010.2140@littlesmurf>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 26 Jul 2011, Alan DeKok wrote:

>  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.

Aside from picking up the 64-bit int type my crystal ball is saying there 
will be increasing need for Combo-IP like data type to convey either IPv4 
or IPv6 address information in one attribute.

As IPv6 is deployed following the current scheme of keeping address 
families separated into separate attributes wherever addresses are used 
will become problematic as cases where the address family is not known in 
advance creep up.

Vendors are using it in their VSA spaces so why not just add a few 
paragraphs.  I'll volunteer.  This way future attributes with an IP data 
type have the option if makes sense for them.

Thought about suggesting it in the IPv6 draft but perhaps better for 
everyone to get that one done ASAP.

regards,
Peter

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 01 Aug 2011 10:54:09 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=[e-mail]; l=38132; q=dns/txt; s=iport; t=1312195722; x=1313405322; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=7CaiawwhHKH+K+M1mMA0aBPIrRHQFrHlpBwE3kRjctc=; b=cKUqffV5Ec0Do1wI128ZTtCoSi39VtB8lE4rQwoLMVWUHlVFehxPGMEO YC5nC0iVdk8Xb5QZJugP142QA9Cc/x0Y9jkZCCWgXQbv+CYLXAOc0cWPa sotjbSaxhCZT1NtSMP42qHl9ksjgrVJzLv6aTMVHdkYWorIBUxYFsvat0 Q=;
User-Agent: Microsoft-Entourage/12.29.0.110113
Date: Mon, 01 Aug 2011 12:47:38 -0400
Subject: Re: =?Big5?B?tarOYA==?=: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext session
From: Wojciech Dec <[e-mail]>
To: Leaf yeh <[e-mail]>, Maglione Roberta <[e-mail]>, "'Jacni Qin'" <[e-mail]>
CC:  "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Qiujin <[e-mail]>, Wangshuxiang <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: =?Big5?B?tarOYA==?=: 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+qL/9rzAow==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3395047664_3043101"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3395047664_3043101
Content-type: text/plain;
	charset="GB2312"
Content-transfer-encoding: quoted-printable

Hi All,

Allow me to share some comments:

* There is precedent of multiple =A1=B0specific=A1=B1 named pools; Framed-Pool,
Framed-IPv6-Pool, and the uncontested Delegated-IPv6-Prefix-Pool. There is
also a special code in the Framed-IPX-Network attribute that conveys it poo=
l
like characteristics.
* There is little that disallows a vendor from implementing just one named
pool for all protocols and all methods of assignment ( the Framed-Pool
appears to have been envisaged for that ) and then using some implementatio=
n
specific logic (eg parsing for a name) to figure out/how it=A1=AFs to be used.
* The problem with relying on implementation specific features riding on
standard Attributes, as opposed to say VSAs, is that nothing indicates to
the server/client if the recipient actually supports such special features
and assures correct interpretation. Eg if we used the Framed-Pool as the ON=
E
named pool attribute, with a carried string =A1=B0IPv4=A1=B1, =A1=B0IPv6=A1=B1 or =A1=B0DHCPv6-=
PD=A1=B1,
etc, parsed/whatever to indicate the role, it would be all doable, but a
likely mess should anything go wrong (eg a device not supporting some mode)=
,
without clear indication of error.

Since the Radius specification is NOT about specifying implementation the
only reliable/unambiguous manner in which different pools/methods can be
utilized would appear to be using different attributes as proposed in the
current draft. Time (precedent) also appears to have proved this as a
desirable protocol characteristic.
Are there any other options/solutions available that do not call on implici=
t
features being there?

Regards,
Wojciech.


On 26/07/2011 22:51, "Leaf yeh" <[e-mail]> wrote:

> [RM] NAS can have many pools configured locally: how does the NAS know wh=
ich
> pool is for SLAAC and which pool is for DHCPv6?
>=20
> =20
>=20
> I supposed the local configuration on the NAS will answer this question.
>=20
> =20
>=20
> Best Regards,
>=20
> Leaf
>=20
> =20
>=20
> =20
>=20
>=20
> =B7=A2=BC=FE=C8=CB: Maglione Roberta [[e-mail]]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 3:54
> =B5=BD: Leaf yeh; 'Jacni Qin'
> Cc: [e-mail]; [e-mail];
> [e-mail]; Qiujin; Wangshuxiang
> =D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rade=
xt
> session
>=20
> =20
> =20
>=20
>=20
> From: Leaf yeh [mailto:[e-mail]]
> Sent: marted=A8=AC 26 luglio 2011 21.50
> To: Maglione Roberta; 'Jacni Qin'
> Cc: [e-mail]; [e-mail];
> [e-mail]; Qiujin; Wangshuxiang
> Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext
> session
> =20
>=20
> [RM] All the configured pools are the same for the NAS, in this case an e=
xtra
> logic would be needed to instruct the NAS about which pool is for SLAAC a=
nd
> which one is for DHCPv6
>=20
> =20
>=20
> The pools configured on the NAS are not necessary to be the same. AAA ser=
ver
> doesn't really need to instruct the NAS the specified type of pools, whic=
h is
> already configured on the NAS. Right?
>=20
> =20
>=20
> [RM] NAS can have many pools configured locally: how does the NAS know wh=
ich
> pool is for SLAAC and which pool is for DHCPv6?
>=20
> =20
>=20
> Roberta
>=20
> =20
>=20
> Best Regards,
>=20
> Leaf
>=20
> =20
>=20
> =20
>=20
> =20
>=20
>=20
> =B7=A2=BC=FE=C8=CB: Maglione Roberta [[e-mail]]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:27
> =B5=BD: Leaf yeh; 'Jacni Qin'
> Cc: [e-mail]; [e-mail];
> [e-mail]; Qiujin; Wangshuxiang
> =D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rade=
xt
> session
>=20
> Please see inline.
> =20
> Best regards,
> Roberta
> =20
>=20
>=20
> From: Leaf yeh [mailto:[e-mail]]
> Sent: marted=A8=AC 26 luglio 2011 20.22
> To: Maglione Roberta; 'Jacni Qin'
> Cc: [e-mail]; [e-mail];
> [e-mail]; Qiujin; Wangshuxiang
> Subject: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext
> session
> =20
>=20
> Roberta - If you use the same attribute for both scenarios how does the N=
AS
> know if that pool is for SLAAC or for Stateful DHCPv6?
>=20
> NAS already has those pool names in its configuration, right?
>=20
> [RM] yes pools are already configured in the NAS
>=20
> =20
>=20
> NAS does know which one is for SLAAC prefix pool, which one is for DHCPv6
> address pool.=20
>=20
> =20
>=20
> [RM] All the configured pools are the same for the NAS, in this case an e=
xtra
> logic would be needed to instruct the NAS about which pool is for SLAAC a=
nd
> which one is for DHCPv6
>=20
> =20
>=20
> =20
>=20
> =20
>=20
> That=A1=AFs why in my opinion the Stateful-IPv6-Address-Pool is required.
>=20
> =20
>=20
> =20
>=20
> Best Regards,
>=20
> Leaf
>=20
> =20
>=20
> =20
>=20
>=20
> =B7=A2=BC=FE=C8=CB: Maglione Roberta [[e-mail]]
> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C227=C8=D5 2:13
> =B5=BD: 'Jacni Qin'
> Cc: Leaf yeh; [e-mail];
> [e-mail]; [e-mail]; Qiujin; Wangshuxiang
> =D6=F7=CC=E2: RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rade=
xt
> session
>=20
> 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?
>=20
> Thanks,
> Regards,
> Roberta
>=20
>=20
>=20
>=20
>=20
> ________________________________________
> From: Jacni Qin [mailto:[e-mail]]
> Sent: marted=A8=AC 26 luglio 2011 20.03
> To: Maglione Roberta
> Cc: Leaf yeh; [e-mail];
> [e-mail]; [e-mail]; Qiujin; Wangshuxiang
> Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 r=
adext
> session
>=20
> Hi Roberta,
>=20
> I agree with you about the semantical logic, while
> "Stateful-IPv6-Address-Pool" is not necessary, IMHO.
>=20
>=20
> Cheers,
> Jacni
> On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta
> <[e-mail]> 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,
>=20
> 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;
>=20
> 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 li=
sted
> above, you would also need to define a standard format/syntax for the poo=
l
> 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 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 e=
xtra
> 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.
>=20
>=20
> Thanks,
> Regards,
> Roberta
>=20
>=20
>=20
>=20
>=20
> ________________________________________
> From: [e-mail] [mailto:[e-mail]] =
On
> Behalf Of Leaf yeh
> Sent: luned=A8=AC 25 luglio 2011 18.23
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; Qiujin; Wangshuxiang
> Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radex=
t
> session
>=20
> Question for clarification:
>=20
> We already have the following Radius Attributes for the address/prefix po=
ols:
>=20
> Framed-Pool (88, section 5.18 of RFC2869),
> Framed-IPv6-Pool (100, section 2.6 of RFC3162).
>=20
> http://www.iana.org/assignments/radius-types/radius-types.xml
>=20
> The foramt are the same as follows:
>=20
> 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...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for
> address/prefix pools:
>=20
> Delegated-IPv6-Prefix-Pool,
> Stateful-IPv6-Address-Pool,
>=20
> the fomat of these 2 attributes are the same as the above one.
>=20
>=20
> Supposed the above attributes could be explained as follows:
>=20
> 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;
>=20
> All above attributes are only used to provide the name of the address/pre=
fix
> 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 ambiguit=
y. I
> guess 1 attribute for the name of the address/prefix pools might be enoug=
h. In
> fact, the NAS take the role to interpret the meaning of the pook name, ri=
ght?
>=20
> 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?
>=20
>=20
> Best Regards,
> Leaf
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> 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 =A8=A8 necessario.
>=20
>=20
> 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.
>=20
> 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.
>=20
> 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 =A8=A8 necessario.
> =20
> 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 =A8=A8 necessario.
>=20


--B_3395047664_3043101
Content-type: text/html;
	charset="GB2312"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: =B4=F0=B8=B4: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext session</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Hi All,<BR>
<BR>
Allow me to share some comments:<BR>
<BR>
</SPAN></FONT><UL><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=
 STYLE=3D'font-size:11pt'>There is precedent of multiple &#8220;specific&#8221=
; named pools; Framed-Pool, Framed-IPv6-Pool, and the uncontested Delegated-=
IPv6-Prefix-Pool. There is also a special code in the Framed-IPX-Network att=
ribute that conveys it pool like characteristics.=20
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>There is little that disallows a vendor from implementin=
g just one named pool for all protocols and all methods of assignment ( the =
Framed-Pool appears to have been envisaged for that ) and then using some im=
plementation specific logic (eg parsing for a name) to figure out/how it&#82=
17;s to be used.=20
</SPAN></FONT><LI><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:11pt'>The problem with relying on implementation specific feat=
ures riding on standard Attributes, as opposed to say VSAs, is that nothing =
indicates to the server/client if the recipient actually supports such speci=
al features and assures correct interpretation. Eg if we used the Framed-Poo=
l as the ONE named pool attribute, with a carried string &#8220;IPv4&#8221;,=
 &#8220;IPv6&#8221; or &#8220;DHCPv6-PD&#8221;, etc, parsed/whatever to indi=
cate the role, it would be all doable, but a likely mess should anything go =
wrong (eg a device not supporting some mode), without clear indication of er=
ror.<BR>
</SPAN></FONT></UL><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN ST=
YLE=3D'font-size:11pt'><BR>
Since the Radius specification is NOT about specifying implementation the o=
nly reliable/unambiguous manner in which different pools/methods can be util=
ized would appear to be using different attributes as proposed in the curren=
t draft. Time (precedent) also appears to have proved this as a desirable pr=
otocol characteristic. <BR>
Are there any other options/solutions available that do not call on implici=
t features being there?<BR>
<BR>
Regards,<BR>
Wojciech.<BR>
<BR>
<BR>
On 26/07/2011 22:51, &quot;Leaf yeh&quot; &lt;<a href=3D"[e-mail]=
m">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><FONT FACE=3D"=
Arial"><SPAN STYLE=3D'font-size:10pt'>[RM] NAS can have many pools configured =
locally: how does the NAS know which pool is for SLAAC and which pool is for=
 DHCPv6?<BR>
</SPAN></FONT></FONT></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><FO=
NT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
I supposed the local configuration on the NAS will answer this question.<BR=
>
<BR>
&nbsp;<BR>
<BR>
Best Regards,<BR>
<BR>
Leaf<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"100%"></FONT></SPAN></FONT><FONT FACE=3D"Tah=
oma, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt'><B>=B7=A2=BC=FE=C8=CB:</B><=
/SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> Maglione Roberta [<a href=
=3D"[e-mail]">[e-mail]</a>]<=
BR>
<B>=B7=A2=CB=CD=CA=B1=BC=E4:</B> 2011=C4=EA7=D4=C227=C8=D5 3:54<BR>
<B>=B5=BD:</B> Leaf yeh; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[e-mail]">draft-iet=
[e-mail]</a>; <a href=3D"[e-mail]">ra=
[e-mail]</a>; <a href=3D"[e-mail]">[e-mail]</a=
>; Qiujin; Wangshuxiang<BR>
<B>=D6=F7=CC=E2:</B> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81=
 radext session<BR>
<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:12pt'> <BR>
&nbsp;<BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'>
</SPAN></FONT></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12pt=
'><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT>
<P>
<FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:10pt'><B>From:</B> Leaf yeh [<a href=3D"mailto:[e-mail]=
">mailto:[e-mail]</a>] <BR>
<B>Sent:</B> marted&igrave; 26 luglio 2011 21.50<BR>
<B>To:</B> Maglione Roberta; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[e-mail]">draft-iet=
[e-mail]</a>; <a href=3D"[e-mail]">ra=
[e-mail]</a>; <a href=3D"[e-mail]">[e-mail]</a=
>; Qiujin; Wangshuxiang<BR>
<B>Subject:</B> </SPAN></FONT><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Cali=
bri, Verdana, Helvetica, Arial">=B4=F0=B8=B4</FONT><FONT FACE=3D"Tahoma, Verdana, Helv=
etica, Arial">: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 r=
adext session<BR>
</FONT></SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:12pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:10pt'><FONT COLOR=3D"#000080"><FONT FACE=
=3D"Arial">[RM] All the configured pools are the same for the NAS, in this cas=
e an extra logic would be needed to instruct the NAS about which pool is for=
 SLAAC and which one is for DHCPv6<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">The pools configured on the=
 NAS are not necessary to be the same. AAA server doesn't really need to ins=
truct the NAS the specified type of pools, which is already configured on th=
e NAS. Right?<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">[RM] NAS can have many pool=
s configured locally: how does the NAS know which pool is for SLAAC and whic=
h pool is for DHCPv6?<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">Roberta<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">Best Regards,<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">Leaf<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>

</FONT></SPAN></FONT>
<P ALIGN=3DCENTER>
<FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Tahoma, Verdana, He=
lvetica, Arial"><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></FONT></SPAN></FONT>
<P>
<FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Calibri, Verdana, H=
elvetica, Arial"><B>=B7=A2=BC=FE=C8=CB</B></FONT><B><FONT FACE=3D"Tahoma, Verdana, Helveti=
ca, Arial">:</FONT></B><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"> Magli=
one Roberta [<a href=3D"[e-mail]">roberta.maglione@te=
lecomitalia.it</a>]<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><B>=B7=A2=CB=CD=CA=B1=BC=E4</B></FON=
T><B><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">:</FONT></B><FONT FACE=3D"=
Tahoma, Verdana, Helvetica, Arial"> 2011</FONT><FONT FACE=3D"Calibri, Verdana,=
 Helvetica, Arial">=C4=EA</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">7=
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=D4=C2</FONT><FONT FACE=3D"=
Tahoma, Verdana, Helvetica, Arial">27</FONT><FONT FACE=3D"Calibri, Verdana, He=
lvetica, Arial">=C8=D5</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"> 2:2=
7<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><B>=B5=BD</B></FONT><B><=
FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">:</FONT></B><FONT FACE=3D"Tahoma=
, Verdana, Helvetica, Arial"> Leaf yeh; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[e-mail]">draft-iet=
[e-mail]</a>; <a href=3D"[e-mail]">ra=
[e-mail]</a>; <a href=3D"[e-mail]">[e-mail]</a=
>; Qiujin; Wangshuxiang<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><B>=D6=F7=CC=E2</B></FONT><B=
><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">:</FONT></B><FONT FACE=3D"Taho=
ma, Verdana, Helvetica, Arial"> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-a=
ccess after IETF81 radext session<BR>
<BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">Please see inline.<BR>
</FONT></FONT></SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:12pt'> <BR>
</SPAN></FONT><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><FONT FACE=3D"Arial"><SPAN=
 STYLE=3D'font-size:10pt'>Best regards,<BR>
Roberta<BR>
</SPAN></FONT></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:12pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'>
</SPAN></FONT></FONT>
<P ALIGN=3DCENTER>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12pt=
'><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></SPAN></FONT>
<P>
<FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:10pt'><B>From:</B> Leaf yeh [<a href=3D"mailto:[e-mail]=
">mailto:[e-mail]</a>] <BR>
<B>Sent:</B> marted&igrave; 26 luglio 2011 20.22<BR>
<B>To:</B> Maglione Roberta; 'Jacni Qin'<BR>
<B>Cc:</B> <a href=3D"[e-mail]">draft-iet=
[e-mail]</a>; <a href=3D"[e-mail]">ra=
[e-mail]</a>; <a href=3D"[e-mail]">[e-mail]</a=
>; Qiujin; Wangshuxiang<BR>
<B>Subject:</B> </SPAN></FONT><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Cali=
bri, Verdana, Helvetica, Arial">=B4=F0=B8=B4</FONT><FONT FACE=3D"Tahoma, Verdana, Helv=
etica, Arial">: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 r=
adext session<BR>
</FONT></SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:12pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><BR>
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?<BR>
<BR>
NAS already has those pool names in its configuration, right?<BR>
<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:10pt'><FONT COLOR=3D"#000080"><FONT FACE=
=3D"Arial">[RM] yes pools are already configured in the NAS<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
NAS does know which one is for SLAAC prefix pool, which one is for DHCPv6 a=
ddress pool. <BR>
<BR>
&nbsp;<BR>
<BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">[RM] All the configured poo=
ls are the same for the NAS, in this case an extra logic would be needed to =
instruct the NAS about which pool is for SLAAC and which one is for DHCPv6<B=
R>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">That&#8217;s why in my opin=
ion the Stateful-IPv6-Address-Pool is required.<BR>
</FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>
<BR>
Best Regards,<BR>
<BR>
Leaf<BR>
<BR>
&nbsp;<BR>
<BR>
&nbsp;<BR>

</FONT></SPAN></FONT>
<P ALIGN=3DCENTER>
<FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Tahoma, Verdana, He=
lvetica, Arial"><HR ALIGN=3DCENTER SIZE=3D"2" WIDTH=3D"100%"></FONT></SPAN></FONT>
<P>
<FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Calibri, Verdana, H=
elvetica, Arial"><B>=B7=A2=BC=FE=C8=CB</B></FONT><B><FONT FACE=3D"Tahoma, Verdana, Helveti=
ca, Arial">:</FONT></B><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"> Magli=
one Roberta [<a href=3D"[e-mail]">roberta.maglione@te=
lecomitalia.it</a>]<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><B>=B7=A2=CB=CD=CA=B1=BC=E4</B></FON=
T><B><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">:</FONT></B><FONT FACE=3D"=
Tahoma, Verdana, Helvetica, Arial"> 2011</FONT><FONT FACE=3D"Calibri, Verdana,=
 Helvetica, Arial">=C4=EA</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">7=
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=D4=C2</FONT><FONT FACE=3D"=
Tahoma, Verdana, Helvetica, Arial">27</FONT><FONT FACE=3D"Calibri, Verdana, He=
lvetica, Arial">=C8=D5</FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"> 2:1=
3<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><B>=B5=BD</B></FONT><B><=
FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">:</FONT></B><FONT FACE=3D"Tahoma=
, Verdana, Helvetica, Arial"> 'Jacni Qin'<BR>
<B>Cc:</B> Leaf yeh; <a href=3D"[e-mail]"=
>[e-mail]</a>; <a href=3D"[e-mail]=
tf.org">[e-mail]</a>; <a href=3D"[e-mail]">fine_sz@hua=
wei.com</a>; Qiujin; Wangshuxiang<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><B>=D6=F7=CC=E2</B></FONT><B=
><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial">:</FONT></B><FONT FACE=3D"Taho=
ma, Verdana, Helvetica, Arial"> RE: Q on Ver.-05 of draft-ietf-radext-ipv6-a=
ccess after IETF81 radext session<BR>
<BR>
Hi Jacni,<BR>
&nbsp;&nbsp;&nbsp;If you use the same attribute for both scenarios how does=
 the NAS know if that pool is for SLAAC or for Stateful DHCPv6?<BR>
<BR>
Thanks,<BR>
Regards,<BR>
Roberta<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
________________________________________<BR>
From: Jacni Qin [<a href=3D"mailto:[e-mail]">mailto:[e-mail]<=
/a>]<BR>
Sent: marted&igrave; 26 luglio 2011 20.03<BR>
To: Maglione Roberta<BR>
Cc: Leaf yeh; <a href=3D"[e-mail]">draft-=
[e-mail]</a>; <a href=3D"[e-mail]"=
>[e-mail]</a>; <a href=3D"[e-mail]">[e-mail]=
</a>; Qiujin; Wangshuxiang<BR>
Subject: Re: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 rad=
ext session<BR>
<BR>
Hi Roberta,<BR>
<BR>
I agree with you about the semantical logic, while &quot;Stateful-IPv6-Addr=
ess-Pool&quot; is not necessary, IMHO.<BR>
<BR>
<BR>
Cheers,<BR>
Jacni<BR>
On Wed, Jul 27, 2011 at 1:55 AM, Maglione Roberta &lt;<a href=3D"roberta.magl=
[e-mail]">[e-mail]</a>&gt; wrote:<BR>
Hello Leaf,<BR>
&nbsp;&nbsp;&nbsp;&nbsp;The different attributes proposed in this draft for=
 the pools name have all the same format (a string), but semantically they a=
re different, as they coved different scenarios.<BR>
As you also summarized in your email below,<BR>
<BR>
Framed-Pool was designed for the IPv4 address pool;<BR>
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;<BR>
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;<BR>
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;<BR>
<BR>
So each attribute covers a different use-case/scenario and they can appear =
in the same RADIUS packet at the same time.<BR>
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 poo=
l name that allows the NAS to be able to disambiguate among the different sc=
enarios 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.<BR>
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 str=
ing, no limitation or special syntax is forced for the pool name.<BR>
<BR>
<BR>
Thanks,<BR>
Regards,<BR>
Roberta<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
________________________________________<BR>
From: <a href=3D"[e-mail]">[e-mail]</=
a> [<a href=3D"mailto:[e-mail]">mailto:owner-radiusext@ops=
.ietf.org</a>] On Behalf Of Leaf yeh<BR>
Sent: luned&igrave; 25 luglio 2011 18.23<BR>
To: <a href=3D"[e-mail]">draft-ietf-radex=
[e-mail]</a>; <a href=3D"[e-mail]">radiusext=
@ops.ietf.org</a><BR>
Cc: <a href=3D"[e-mail]">[e-mail]</a>; Qiujin; Wangshuxia=
ng<BR>
Subject: Q on Ver.-05 of draft-ietf-radext-ipv6-access after IETF81 radext =
session<BR>
<BR>
Question for clarification:<BR>
<BR>
We already have the following Radius Attributes for the address/prefix pool=
s:<BR>
<BR>
Framed-Pool (88, section 5.18 of RFC2869),<BR>
Framed-IPv6-Pool (100, section 2.6 of RFC3162).<BR>
<BR>
<a href=3D"http://www.iana.org/assignments/radius-types/radius-types.xml">htt=
p://www.iana.org/assignments/radius-types/radius-types.xml</a><BR>
<BR>
The foramt are the same as follows:<BR>
<BR>
0 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2<BR>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3<BR>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>
| &nbsp;&nbsp;&nbsp;&nbsp;Type &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;=
&nbsp;Length &nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;&nbsp;&nbsp;String...<BR>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>
<BR>
draft-ietf-radext-ipv6-access-05 is proposing 2 new attributes for address/=
prefix pools:<BR>
<BR>
Delegated-IPv6-Prefix-Pool,<BR>
Stateful-IPv6-Address-Pool,<BR>
<BR>
the fomat of these 2 attributes are the same as the above one.<BR>
<BR>
<BR>
Supposed the above attributes could be explained as follows:<BR>
<BR>
Framed-Pool was designed for the IPv4 address pool;<BR>
Framed-IPv6-Pool was designed for the IPv6 SLAAC prefix pool;<BR>
Delegated-IPv6-Prefix-Pool is designed for DHCPv6-PD prefix pool;<BR>
Stateful-IPv6-Address-Pool is designed for DHCPv6 address pool;<BR>
<BR>
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 'stri=
ng' attributes for the different address/prefix pools to prevent the ambigui=
ty. I guess 1 attribute for the name of the address/prefix pools might be en=
ough. In fact, the NAS take the role to interpret the meaning of the pook na=
me, right?<BR>
<BR>
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=
?<BR>
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 pre=
fix/address pool per the same logic. Am I right?<BR>
<BR>
<BR>
Best Regards,<BR>
Leaf<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
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 rigorosamente vietate. Qualora abbia=
te ricevuto questo documento per errore siete cortesemente pregati di darne =
immediata comunicazione al mittente e di provvedere alla sua distruzione, Gr=
azie.<BR>
This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, prin=
ting or use by anybody else is unauthorised. If you are not the intended rec=
ipient, please delete this message and any attachments and advise the sender=
 by return e-mail, Thanks.<BR>
Rispetta l'ambiente. Non stampare questa mail se non &egrave; necessario.<B=
R>
<BR>
<BR>
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 rigorosamente vietate. Qualora abbia=
te ricevuto questo documento per errore siete cortesemente pregati di darne =
immediata comunicazione al mittente e di provvedere alla sua distruzione, Gr=
azie.<BR>
<BR>
This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, prin=
ting or use by anybody else is unauthorised. If you are not the intended rec=
ipient, please delete this message and any attachments and advise the sender=
 by return e-mail, Thanks.<BR>
<BR>
</FONT></SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:7pt'>Questo messaggio e i suoi allegati sono indirizz=
ati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi a=
ltra azione derivante dalla conoscenza di queste informazioni sono rigorosam=
ente vietate. Qualora abbiate ricevuto questo documento per errore siete cor=
tesemente pregati di darne immediata comunicazione al mittente e di provvede=
re alla sua distruzione, Grazie. <BR>
<I>This e-mail and any attachments is confidential and may contain privileg=
ed information intended for the addressee(s) only. Dissemination, copying, p=
rinting or use by anybody else is unauthorised. If you are not the intended =
recipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.</I></SPAN><SPAN STYLE=3D'font-size:9pt'> </SPAN>=
<SPAN STYLE=3D'font-size:7pt'><B>Rispetta l'ambiente. Non stampare questa mail=
 se non &egrave; necessario.</B></SPAN><SPAN STYLE=3D'font-size:9pt'> <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:12pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN S=
TYLE=3D'font-size:7pt'>Questo messaggio e i suoi allegati sono indirizzati esc=
lusivamente alle persone indicate. La diffusione, copia o qualsiasi altra az=
ione derivante dalla conoscenza di queste informazioni sono rigorosamente vi=
etate. Qualora abbiate ricevuto questo documento per errore siete cortesemen=
te pregati di darne immediata comunicazione al mittente e di provvedere alla=
 sua distruzione, Grazie. <BR>
<I>This e-mail and any attachments is confidential and may contain privileg=
ed information intended for the addressee(s) only. Dissemination, copying, p=
rinting or use by anybody else is unauthorised. If you are not the intended =
recipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.</I></SPAN><SPAN STYLE=3D'font-size:9pt'> </SPAN>=
<SPAN STYLE=3D'font-size:7pt'><B>Rispetta l'ambiente. Non stampare questa mail=
 se non &egrave; necessario.</B></SPAN><SPAN STYLE=3D'font-size:9pt'> <BR>
</SPAN></FONT></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica,=
 Arial"><SPAN STYLE=3D'font-size:10pt'><BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3395047664_3043101--


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>