Re: Request for NAS-Port-Type Allocation

[Alan DeKok <[e-mail]>]

Bernard Aboba wrote:
> Are there any objections to granting the allocation as requested below?

  It looks fine to me.

  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: Wed, 30 Jul 2008 13:19:03 +0000
Date: Wed, 30 Jul 2008 06:17:37 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: Request for Minutes, Slides
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

If you took minutes at the RADEXT WG meeting at IETF 72, please send them 
to me ([e-mail]) and/or Dave Nelson. 

Also, if you presented and did not send slides, please do so. 

--
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, 30 Jul 2008 11:32:23 +0000
Message-ID: <[e-mail]>
Date: Wed, 30 Jul 2008 13:30:41 +0200
From: [e-mail]
To: [e-mail]
Subject: RadSec slides
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_43n2rxr3njeo"
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)

This message is in MIME format.

--=_43n2rxr3njeo
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Hi,

we had some problems shipping the slides, so they are now attached to  
this mail.

Have fun,

Stefan

--=_43n2rxr3njeo
Content-Type: application/pdf;
	name="ietf-72-radext-radsec.pdf"
Content-Disposition: attachment;
	filename="ietf-72-radext-radsec.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nIVSS2scMQy++1foHBiv5LdhMDT7KA30kGYgh9BTk7Qsuy3dS/5+P3lm
twmUZow/yxrp08tshV7Mb2IaGGJ2ijEonp7o/op+GiFdp+/GJ4bd0SgesGGGEy6vJD1nuwP9MM9X
nVoX/K8nkzlZT8k6mh5ptQMxpOeRpU17s53MrWFbiG2s+OD15SMIxAa9veB+g72nbFMSV+mzkYBE
Qw7IqovRRSBS4Wjr5XYH3v/TVERF6RE8s2u/zJ5vM0IdoIpFlViVbUb5WdNwHvjtaFafjoE2v0iD
opFc1d+nklw/OZelG9GpWxHg0g6v7XgY2bVBRvYc2pBGjm3wI6c2xJFzl0vH2tzIH7rpNa9505Xb
jrv2dbqZO/pOEr4P+59ZVKUWbn4UWQKqwqksvmOYdVxmiwXjm+iv5u+YMXsXig3nYKH0YJKaltEG
lLRGXZI770YVUriKl16u/lvMdm0IanGJdXmpMWVypWCaQUKXDqSS7vmd/pXmv2eP5dXe0h8om6TM
CmVuZHN0cmVhbQplbmRvYmoKCjMgMCBvYmoKMzg1CmVuZG9iagoKNCAwIG9iago8PC9UeXBlL1hP
YmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAyNDAgL0hlaWdodCAxMzYgL0JpdHNQZXJDb21wb25l
bnQgOCAvQ29sb3JTcGFjZS9EZXZpY2VSR0IvRmlsdGVyL0RDVERlY29kZS9MZW5ndGggODIwMj4+
CnN0cmVhbQr/2P/gABBKRklGAAEBAAABAAEAAP/bAEMAAwICAwICAwMDAwQDAwQFCAUFBAQFCgcH
BggMCgwMCwoLCw0OEhANDhEOCwsQFhARExQVFRUMDxcYFhQYEhQVFP/bAEMBAwQEBQQFCQUFCRQN
Cw0UFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFP/CABEI
AIgA8AMBIgACEQEDEQH/xAAcAAACAwEBAQEAAAAAAAAAAAADBAIFBgABBwj/xAAZAQADAQEBAAAA
AAAAAAAAAAAAAQIDBAX/2gAMAwEAAhADEAAAAfikpeeh4/E8ecQTOyKvg0NUpM0SoRIIIwlCaH4c
o0IWxRUcrBdUKLJAQ8sggnNiCYCSkC7MjA5xWtuWMYOkxiczhUFhEKry0gVVxtJp1MrCYVblgAXi
oFyowiCNmArkVPLgbaRnZLIaXnOoQ58k3de2L23DST1pUsiTYup4Xvock/m/u1paijTvLJmXNKhK
LVTFHQIRQrUHThOkfYRTmVaYjFSiF4JCVQw+qIWp0uaPrw7i9xOvyvQ6OH1Dm9Khessnl2lqRCqM
r8k+vW+3F+cF3xdfn1IbJNaJgdhOlfzYloqCwCqT8ZDNcI0Rh73yaLd5+yqNLYis9vPlpqzSyvsW
sym14Pfz9ynTzposS1rGfIkt7jax+VUH1nE9nj5BfbY3SKyGwxs7Snoc0mEGux5fi+ryc6Q90NIC
UWQzQ3VHB6Z6oPv595cUFu8fqv3X8i/ZuL1/qibUsPRzdFsviLzjsUn9eJf4v9SoNOej+a6bNb8/
0D5a2yaGoNmy8/Pl2irY6foPyqz8m/oPzd6bilBYoLSDabidm+1Lfh9sUzvLTEpLGUZxOWXTX7bK
lc72nzbJLSyVdebNIUFzTBfRW7z+egKyrhQWjrVDIdyIBHC9ZaCnWlM7KNrmxy1xryaBqnsa5xes
pA4WvgDIowBhqp8T0NPEwqpdmtNZzS8m3K5uTdZ6RONjQCQfns105CAObcPVtJzse68nLfu05rJr
urCsB3DmDuVLS7i5z7iV63unRfzuW3jHcgiXc5VH3TtL3uTgv3Jjb7pv/8QAKxAAAQQCAgIBAwQC
AwAAAAAAAQACAwQREgUTBiEQFCIxIyQyNCBBBxUz/9oACAEBAAEFAvloLj/5hwQjTnLC0WoC9fBR
wtP8WjKcF+Pn+a/CLcrCrj9xj0mtyfUTfyhHqHgldayvyiiFhapoKZDl/Ts5lJwEzAm6Bb6nf3nK
/TXU0rqc1EbCP0Xs0NX+wW4WuUGiNMDd2x6DUvJaGhrR29ZWi611rqXUtUK5kREQbFK6QviJd0MC
6o1qCeslSRELXCEhaq+kjpISxznlxr/2dEI+tv8AIsZoA0vOMLRaLqRiXUVphFuVHEXHRkakeSnv
bs6VxQU3o/6b7DfREz1sx6MBCgOCHnPU2RRxfrxRJzNzHWwutzj1YQhXSutdRQiTwiwktgUjhEx1
lH2iij6J9oLZA/GclshYmazBw0TpFSm2suLCoIA5CsJGClq1vHbJnFl6HCko8IVLxEjFLXMaEOTJ
QEEU1n28lxKPwVj0PwfnK/C2TJy0MmwWxtcK7cWozhRSMEdXBMbd1DXVPj32jDwcLB/1dbFnhhiP
i4oR5F5RTiimsvnTwuoYc0ZLQiwJzML/AGxo7HM+7Hz+f8GvLTD90zB1iN2DFNquOl2NGv8AWTRR
NhY97Y22vKuPruPIc5ySm8YsSwVeBntO8j5Ph+Dpx/xewJ8aIRCwizKI9key1ELCCcP8Krj3ZyYT
iOFhLaT9D4yzaGWF0iPA0nuhgjrtnsxVWWfMqofc5fkrUlfwaDk4+S4z6C0QYwU9uUfXxlGPcyM1
KIRCwiPXzVP62kDZBHVAoXoq0cXKw48UtNs0FNJbUlDkrRj8RobwVoareUhoR3eU8gnsxt4Sw4Sw
MeJfHZ+o+k3x2zM2Ruro/Grj62yt+O2qjNlN43yMV7fKq8Jcu8ePaI+af9poOThRKH8eH8m2nf8A
iWz1KS9yD1cr8m6DjuLEzhRjZHa5Z1YdEjFa8nru49jg5VfL4ePgdmxY+sMfBiL1znlNTmKwzit/
yDNV5eJuVW80PGNldG6y/wCagP1LJnFRuUbtTA/44Dy5rogQ4K7fr8dDy3Oyc/YoubCySz6mlZIb
MTVeqgot1MmCowFAWqejHILNXDzAV9PldRah7XSCpY8EtWqqH9zGPtYmJjlC7ZTRh4r3L/HqXyTm
yP17k1HWJptgCa65OtOKdcIEz+xSRKVqZJgtlTbZzYm3d2hNkCGpDoQtFI3KezCKrH9ya5DWsWmE
PSik1QlytkfwHhqFnCFkgl2zXFSPRl1T5MqROYgS1duFvlH2iE2UtQnXcFuiiAoIx9QyfYRuCaAu
sPRaWISIPXanPQk97+4rGpkOwkynIyYXYs5Thhrh8bfBHxthbrtXYq5/csdhsOxjjk2QcWu/mnNI
QdhB/wBz/YaDrlbYUcxaiewSBPX4XZhb7Is3MkZYXLK2+Ho/NU/uWn7Y3fayTCjlwmS4Thu1zCPj
b052q7EJMrZbJ5ynrK/Ca722VH7k5iI+OzVbZTmot+Kn9r//xAAkEQACAQMEAgIDAAAAAAAAAAAA
ARECAxIQICExE0EEUSIyQv/aAAgBAwEBPwEbJgnZJmkTJJJK0kkmCSTIzMjKRUikg5Rl9nTFUiTk
hmFQ5QhKSlRtgxaOGMofotWsuWY0odK7SLtp3PymCYExMkT2NDFH2Wv0WnI0v6LtGD4IaIfsdLRD
XZDWxrT4t1NYvSpwTJdqzUDrdShjuPGDys8mXY7kjuemJ6OqRicC+RUjzN9mcmT0RjIqR0fRDKXB
kVUbY0RAuDvWCCoqWyNKdGhCIE9P/8QAIBEAAgICAgIDAAAAAAAAAAAAAAECERAgEiEwMQNBcf/a
AAgBAgEBPwHeiisUVitaKK2rDWLRyRzQmn4LLzJEpHZZCSj1rWixKyXvP4Rnfsuzossvb5I/eFiH
Qkl6FFJlJHGhRoUR6NHBHA40JZssvLQn5bLELZ+D/8QAPBAAAQMBBQQHBgQFBQAAAAAAAQACAxEE
EBIhMRMgQVEiMFJhcoGRBSMyQnGhFCSx4TNAYoLRNEOTosH/2gAIAQEABj8C3KDW6pWWm5+y1+y+
UrMUWWfVd91RdF4hud91Xel2ay3ua7Kp91iOfcuytCVkwLNrfRfA1Ztp9F0X+RWird3KLxC/XNHH
0sjpz4Kp1u5lNx5trn1GWTRqSqCjiiHVpyCOjfqVnIPILKT7L41kQfosxdktKORIVCo/ELqnW7Ef
K6g9eoyWfSPJe8OED5f2XRHmV8S793X1WYwlVGYXJZrkVEeIcFiN2I3UHndnvVOQ5rsD7o4RTv47
ld/VcjcCowe0FRtfO4moFPl5r63G/RZi7G/XlyXR15r67p6iizzCNCovEFSqw1OOoWei53UY3o8X
FdMl59FTZ08yiYsz2XLbW6KzRRjg8YijZ7FZ2Z/Pgp6Krzc7Ec+F2m4MXw8UaadTGa/MFXjwuoqF
NjGnHuCDGCjQi5xDWjUlYI5Da5exZxiVLLYm2GM/7loPS9P2T5J7W60WnUDh9EDDZYGjjLOyo+6N
ndZrNaLYW4dmyJuvM8v5KHxAXOFBqDXii+hLW6nkgaZKSX+1fxnx+CixSxm0O5zvL/1WGKNsbeTB
RY5pGRN5vNFs7HHJbpeUYyRhlcLB/SK1/wAoyC2DvIjOvmpYWvErWGmMcU8UGYpvNpxVOpZ4gmgT
OLOLsGn3Q/Mv/wCL90WOi2meq/0wUlBhpJp5C73MEf1lkp+gK957RbZ2dmzRf+lbSfa2yTtWiQlY
YYmRN5MbRG0WycaACEarYWFn4aDSo+I/4UbfdY5G4msMrQ4+Sqo5dpZ42yDE0SztYSPMohQuxWaP
bjExstoY1zuGhKLTqDRfiBJY9jWmM2uOgPLVUVZpLLEcGPA+0sD6a6VustkdZ8MtqFYanou87rRb
oYMVmg+N1d2LxBZgoEODq8BwvNneaMnFAT2uF9BHJIeTWqkHs6n9U8rR+lU+a3e0WWSBozZZG5n+
4ovNTXi7MrRNoyrRHs8qYh3go6071DYrRZ7SWsZgdspQ0O/6ruVkYYLU7YgDC2cYHerVJJhw43F2
HkprBsjWSds2OvIEXNinstqq1gwhs4wBwFAaYbtu6z7exdAizSGuBzWBuJp4HL73WGGzez4DZrO3
C4SVLn1+PPvUjoWmOEuJaxxrhHLci8QRq6t1Lu9Mg9ou2UmjZzo/68lUGoPEXGW0ytiYOLk1sbTH
ZGHIHV3eVTS7NGiJ3KOCqzI7ud2l8XiCO7RflbVLGOTXZeip+OeB3ALaWmV8z+1I6qyWt2ea1uru
ao116mLxBfCR5dTkVqsQ0/ko/EEN+m53Krd7v6uLxBBGT5AcNbiOOlx3C/5QaHcJpoKm/VZXBo1R
ByI6mLxjcpdktFosz1Nesh8YX//EACYQAQACAgIBBAMAAwEAAAAAAAEAESExQVFhEHGBoZGx8MHR
4fH/2gAIAQEAAT8hDiBXpSAjWwhFzMOkjuMIE8QbueF8sfI+IU6TZ4+mC1I5beDxElehmWIo1LgL
l04xP47gr8wD+Y9Nf9WZyXnr0WomgbzKh8w6hnMwzhGmBUR2g9BvGE4qnTKarja4zNQsOBcDlrvy
/U7T8tQOG+9szhkDi8EzaR+Ue+QW24dktgZN1A9niMClLUQ/1ZnauZKNy1AOVLMSIo+B/aoWLxwT
yDFFV2S+hoU7PSv/ABGnNPmX6h2gNBcM8EzB9giWGF5qWHCacEu+rwTif3GUO2eH/JUrfk0wVHmo
JdkcLY6ZZ2aIKdF3XU7E/UCDWf8ANLLO4nEzYw6XPCWHazB+XtLJnUehUXtnggntA64fpnGx4mOp
tnx9fL/qMlet0giy3/NTDXxwYKiHBAa9y3K5bRE7IZNjqFdeQI40eKWdNqlyK4N6IeFsvzDMOCNd
WOpXpxwdxuqu+oo7O0YyktuLGiorMuSEFBM4ioe/ufaAL9nagFP2T5hVmXqoEzC0Nbi2dMrnkjXU
HmLVJKb4rj4Szsp6nwjmVUc7qYKdj7w8xzwil6JlSoC3bqVLVvDojBQMcTXAovPMKtRYg1OapD6Q
fMYirXjuAqej17v9R8sBp8e3Udq32YqjSXLRT+aC34zMok1CW1LTV1TGSIWwsjVBrm94iTdUxxNM
D2Ezf+JR2PdB8l5Z3amPI40CAe/5pKKP4vMc3938wijrb94yp+LnYniKn6TeXo4Jc4zMuwDE7s38
XOCv0JmrImWyBXhKqkTSNhzCNsOLjKelUiRKgM3Broh3zJ9yyWXCh5i0vrfvKeFjaWV+RgeSUBMh
NF0EQ8SX786+5/YSDp+UNvT9iL/5LNyP0Na/glLLoyqfD5rf7gHLdRFy3JmcFS2LHU3TD67ZNem5
TCZokLJthM//AGR19GiXjTkzBLwPWfog2ZBXhOv0yxtlEKjyoX4t/ZNGDof5DAZ9/wAW0PxPDxqP
qeKk0fcsk+kn5Vf4GFyEFMAdWl/pF7laVfYTCsmNEMRtxLrI4/EGJT6YLRYWZQtqEXtGI+SX69df
FRPRnxv9y5JbKvw2glszAjt73oxKhBrWv9RmNMI9BWPeL6WPyTqgGq/nWF974/VTxkAD6lmsomVe
DL9R7i2Hg+IX7RChTFJuILFTxl+KF0EskzTWMkC7BGoqEuZSYOClTeZojTAQWJ1fE/1YlEVGdgpz
2nErUVmJQUpeNfc4guEWxxcV3RtoRa0SoxM7ElT+F3MELNZJhZjbZ8XH6itnxysm2gB/lafj0WiE
vIr/AG0fcYs34afDUuIifPAZB4iNXLUs93mUYyDcwB1pOFXhr2bnuA14Qexiy1dor9xJTC0MSCMY
pbyIg9DAJooHZuo2CANRhK+Yge6hxIpvktfi/SNBscTkPzP5cU7j4C2Lb6IHvGqJep2Qtwnmu4Ld
xvv05HX+aAWBvL/dxMS2teNwShxcLQpackNkHG1fZ51DZjWJY+nIV434Dl8Es3U3j+MQjsgDqvYY
pKZxCFB6AaY1MAYXUWUE8kOaCExydwGp2bnEITDaI8bmwgY0mLv/AN43uNQtRVKghVzU6GIycjf+
Smcs6b+QgC7uD+4qtLljDnFnD5gmho7jucPAVeZkX9Qi4a1iVMzAMHyHHiWCDZmXNxZUSYhSe8I+
gzGU/wAWZZkl7YxweRBpHit48wFSiHEylzCxRg8tw7jLcpz3LtQVl+J8OUZfqOW8Sy+5izklIYcT
FXMcxRDpjGMltr/2matruNc5udSV4z2EccYiOYYQg5jHixYm49lvcgO+HgjHLFXps4QOzlFpeWXX
pW/QyRojhPckz5l/82Y3fq5hXBVtKKfpnAzzGxo2zcSqxTDWZTzuJ8mLJFMMBOluv0wLuLW4rY46
lPULjrIftJ0owKt4nlBdFFvUU5aaPeE1YpJ1gyEGYLWNIt7l+Y/9u49cynwfMTRiJVNNYYSILNCs
5ibtFfCDUB8Sh7x8oeDCjNcfJDG6ZkxruXT6SjbUzZiB6TGJk0ywziBi3MoiVP5Pc//aAAwDAQAC
AAMAAAAQoNmzct7SBNqhDDjNESvhv7iZzHA3PHmtwuXhtrN0qpyEjp4ITwfEUZc1HkMU2Ngn5a2E
4i1K9z8H/wB3Eh4YqLDPk4maAvfxvSC0jzlMLINKPCGUo/B/AvUutg/PHfHXQwX3PPYoP//EAB4R
AQEBAQEBAQEBAQEAAAAAAAEAESExQWFREJGx/9oACAEDAQE/ENsOHsDt9gPW2IyQWDrGWhaHcj82
0v2NGk5n0Z/6jMXiXm7a8SJDxto7sicgPBdRPIDkvdtfYf5fjD2JPyT3B4iLJNu7Y55AGfyG9gWH
/BZ8wtfR/wCXVYH5HhafZSA/4jtuW8vJL+CIdcROVw8Lr8tDrSVUcuFTIIEZYbl8CPQSpikMvJp4
38Tf4A6z7by7L5AvUlhfLQB+WSPqx4sqQST+QdWGXzBZPqSxyYN3ZCYz8ojjadVj7JAPpZeSIx32
yD/GOxG/MvqMmZHXIN+YEUkOwdsZIXFkDcuF4sZs18v/xAAeEQEBAQACAwEBAQAAAAAAAAABABEh
MRBBUSBxYf/aAAgBAgEBPxCC7s+WTxNyttwcsOpmiD1MC7sk38DMlnO7d9WjcOrhJEuLCQ8PSSh3
bkuz5G4WWVPCHNhaoXS3CjVs0kssmZJ4Xq0kuMu277uIWZcgOjanBgPUB6bD1GPUkQ7PJOOPA2y5
duc9pQls/sdZCtIR0gjf2DItZZser7QsGcT9PBn+rSTZfwZ4cY4m37PMuW7PE+Qv22G7m3nJL3f/
xAAmEAEAAgICAgEEAwEBAAAAAAABABEhMUFRYXGBkaGxwdHw8eEQ/9oACAEBAAE/EKzDPcTpD1cN
TF+RMxIpb5glpHh5l4dXXMQoS9BNywbAuv1EmRvs+x/MrMB8v5Zw83Y/7KNCL4BfqCXg7J9H+Zgs
PMyfG4mcRb/2A3qBpCQq4gRklhVfP/gFclHPM2vBz4/1AaNDZKG0fKeYK6qMj6vrKC0ECmzNv4+s
BdQFYsUFbu8QOQq7gDMFwstq4OI02165lBpv7/cxS7vuFRUS8GZiNV8RbcZlB6msiWaZUX8MQqXs
FML5gGyS5xrmZQ6m745e2MrVug/a48TObh+YsKyzbVeFwyrT2m/8yuq8Cn6xwgGskwhf7EGIKcJz
crwHlfxClBvf68QFVMBsb2XCsLbQQZeCwtD33AYVq3IlvQ16J34DtQtUX4YKYHhg9RuIu2m3IPGJ
fkDz2fG4i0i10rPrM8R0WH8SnKk7NfWKhoRTkqvEXDXM9wGt7lxBnIJQ+u3XiYKAFBL6PW4iMi1l
fTcsCp1+ilk6dmVQAbU0LAOcxjSZmHdv2i1ujrqDzqW8p/yOlG0LC49Eag39HMBqAMUYUV6w6+MA
K+kKo6FEfYLAVlFr+WYE7y6P0SlJY/0dEEXCnJv1FFq4W5WMyrWrYiqX7TMpAXwTH0ZegNSb+pBT
Q3vp6hRvrDi4gVX4Wm8UZfX1Qv0Vn2DXzVxcujZ+Bg+bldQoCRS8GLJmARp78S5miWJOaXM7SiJ3
BMiQyRxZBPcNXj0sXlWR3+kJ4YTbTKJA2HXiotXsDuEqizHOMNeQB3HKwagEbXYbTLVKgEo9lp5e
jxBLD0H5Y1c6FB1G5SK0E7CvMQGTzWZR89oZ+ZgTHEPirQZpwOa+kEiNji/Jjfmjq5afjQG/Zw+K
+YmVnedvuJPQ8cxkyQ5j1ejx4g0S8trz1CFNhwwG5B4lz8ICzM5XiNQUfEClpq5iNB7VukdLY8HB
AWXkWaYYGlboSu4mtjOAr42wBgGVeoOiNxqtkBVFZtNm4wZQnagzrm/sxAuxS539sfeHMxJXsFHn
N8GH0mEDKBrKZ84mP5BwVMoFax/eoxK+BDIsIBaupWP3TXi7u8c7vkjyjoEsHTQP1xqKTWQlt/7E
WHDNbHHzGmjnuEDeGn7/AF9IIKzg/f6gVco7g8JcU87uG+KdVLhtb7jw34Cf256yL2n8wl1VC0L0
eZQAy6JWMU8nCCsOVvFXXm3qM7QABbC9exxPcThhuwW8HzFUosCG/wCk0NDbJv8AtyiZpg/FfLzR
Hjq76EM/eFuhwjJ9YEiWbA9Q1XyfMA/DQj11cYCclEIicGoG8AGyZd700zZb6LOA4l+ZbSX3D4Rv
OPDL7CHSILeXMUXoeZsnsyQanZiUInRuKBNGtLSO2rhYlQeCl4vzUIc/7K+MQK1ELfWIK+YHa4zI
1BRVbKUMY8U8qqM1XFUxWs0kQhbw+Y63lf18Q0vIv7i6Wl4P8Dyk/YWcT2vcNfdBP2rgJygavrGS
9EkAI6bF+mGtzFpS1DtCvPFA1iPhaWEG6fJ6L5Ieg5FYlQORBfYrGAJsrJitr4dxaLasjiV2qJsq
WsfeWYwmcPgj2a3TGs1d017/APAIXvqCcCFRn1KA8Mt7fmDLUDxSg3VwOSu5qHAHUVV0uCBOAs05
8UAlnU3FF4XB3TFcLXOLKU+LPqSmTwaAF8/YgqLcUtnldfkT4iM2sDnr1UAn+M/LAREd4b76tBcC
3yL/AJstZ8LzA/lYSGmspzXw4ilGoAoKWl3usyz6VGB1vI2Jbkcu5VAJ2lbq4dL6U5lW1Q7zwtRU
HjFwxKYNNfMq6W5dCtRpYzouyxTD8QoVIxb+I402c6i1iPWazFmEhJepaVoTmAd0gI+P8wNxVvBn
Bd9xuUANvuY/vuXh/JpgBYj04vljlMHhLeaMYOtwAsUHHyfEWhavwS55Ux3eT45ofiZdiwjnDVmu
ggsNhanyUPpGeVfbewEwjldobUbl4oG4pIbgFCqNBvWfPEzvOuDIHIHjh6g4a3G6gwBdpg0qVY8c
RVwkSxK6TD7IH1dnUgYgMZStxK4QkKNIIolmxqYEW1l41FBb04cYjmpFBs7FF08nmAXTG7FWGgQC
tgZl1zJ4zHkYgxOxmCWN2LCy3KbE19PUUBvumE2C4gQiowFYbqpVv8RHAfSApoRBPhK/aRYr3CVY
QisULgLQOSUmbsBCjZcvgpRvDuXmKhSbTxTyF/8AAIt0F4LYkCSxwf4nmDA7Tqo3L1hjmMmh4RGt
CtrLv/5mM2hl28yk9cqzeJhQOUrhdTOgY+rR2+wJbFvrfEowNFHOKN1rhCVUKu0L7lqr9Pd2+1Eg
ChW4Ek+SwKA4urrRqcb8JbGK1at3xqM9NP2YzdTFtCTMq7bdTs14gYOQorQ7LGikQ20GC06smCC9
Zt9BMAMbACW6WG4mpLBDAurqAuQ6q5xMA3tZYbo3+sLUxa5tyDb7QVi8tfP9qYIdAer5INoFLfPc
SxGsRE8jwzNJg6Y59O1l2OE5EBAHSJs/8LwzorC+V4hXqXNlzWnUNGNZVnLeGW0FNF31eql4a1SB
az9pj9bl11HpF3kPG46Baq+vMGjAqEgTcu6ZVXOt0wXwjkPrAKoGL3i4qyqChnUdQCaxCqwHpMXS
PEKoOFdzRh25goXBi4Z0ntljaPuUWOqn1g99lT7wfKjRwX/kZHbZ9o/RSHNFjC9xo0dL16ghtxS/
a1b5qJkdpfgFk+s06ZgW7oU0eCodwAXiAaTJ7ChxEtQeX4lhoas2/E2BDvHzbvYMQnVW5hVKdPUA
JT3EaArWGNRQNpy/ylGgs0jhO4hlh8x9KPWYDwz4li6YSI6ch1EDg1317i6oN+iW4su5s9esMktl
wHBslCEtvZMIZI1WOckULVHFGLhGDt8I+zz8y3VZ9TEght4jJUOEcw2bMLwy7ByDp8Rb6dnqXUWA
yRAUHnuZYgWwEA1zzNiNgKKP4iYC3t6MwVP8Bhh2AckfFcO9kWy/ZgzaprmPc3UtlKHc58b7j66x
cesuSWGzcRAppLg0az7I35QhQdTAKZzBrR9wrlxmbvFGajsSmy5kbwP8y2EO+/EwcaK7jxEHJqWW
Z9sfIafzGuL9ItZg6N3GdMuDmjuCeZKL+sC7/cRxQ+YGbUstGCwJrzAyqL3AFm/UUa+8IO4jOMkb
7DfGL+XsGn+kRTV0wgq7yNdcR1TtSi+At+0RsFCAWNOTCeoxGaLfUsKlLW1z/wBgW7tHcIW7dHdy
oOXiuZhU7EwUH2fS4m8/GrgZPR8dSwopnpBaBseg2T4HzAtWDOHcsILu400H0OZRgy6WPMkVfcrL
MV7T/wBJaSTepGmHOF+5jbT3mG7xOnMapVdaZyFS5Y+dxo4UDSW6O8Z2ENF+3+SOLZbVck5r5/MU
FD05lrqiQRzwmH3GCmn6SzhFhCb4P9+0xky2Lf5hvyNkIoKwcvpBSvlxHF4xTB7MQbBz+Yu7iVtj
nWyXA4nNccyxWFaSZPwpq4l2QLqI5Lb+Y8RL3mX5Ny4RrcLuDplFVTpl3kXsmWHMa9lMsQ3/AEMZ
/9kKZW5kc3RyZWFtCmVuZG9iagoKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyL0ZsYXRl
RGVjb2RlPj4Kc3RyZWFtCnicpVRLa9wwEL77V+gcWGdmZMkSGMHuZl0a6CHtQg+lp7ZpCUlLc8nf
7zzkx4aSB1ljSdbOjL7vmxlBi+6h+evAbYCXPckYOhnvf7jPZ+53g06e+5+Nj8B2d42Mt/yyGc/s
slrJbHa37ldzfaah5WH/3bHpIbbk5D1+d+cjB+bV9QCpHG+aw7G5aqBNDtqQ+cdeH99xAGw7+Xrg
70t+b1zfxoiU3YcGOwba9R2j0mWgwCNDgdDm+esTx306TOZTmXrgOOaqH+Z5ioh5cKiQZJOfDG3P
9HuBQZ7Hb3fN+fu7zl38cXIoCwlZ/H1MkXSGPlU1KEAbGX7PZ1U9fGQ9vgxAhQaIZRMH3Javx0sT
R+I9AsNhfGI9vUdGolHIYWQKoivOuj4DJQaJQT2Hr0jIkOCubPyA+7LpBhjhomwY2FbHzDNPuoVJ
DND+3pXZZvFgmwNkHDGrfVc2OBAULzZqFQfYn1J9Di/lNHGe8QIHDgOhhqeCAnM0oAKLvJ5eUVC3
ojNC5oRk0D2KArgX7ryl6KqrEtWA1CvnbN7MRY40b/+inFGUunlbzij6pZsmDfYrWsJ6Tp+wMqA1
L2P9K85ZsuxZBLM5zM7/scFxXQB6AKINJxKQR9+LDBCSEMLUeVyIeEeeZilCG1UKeqkU3Ibcs1y+
8bEU24UIpSXnlBWuEdzXch5Xkj1dKDXptdBl75VsMce2eyNfzDSVz9Ku1ofaXQs8S7ml+iT9lTlG
6cOgTK1zlCmC+O6mge180Yzr1rpEMl1I28FKpmpbpmsjzqfZEXaxsOrEJqa2GVSwVk967qj3hORg
6kI6vFbvKIq9Ue8Ql4u66k2jXjfd0hp7RamADapusHbJrEwXS1AVxIOaTFKmk4ozjSWCx7ku1/Vo
9otSkr56ZflVE165f2/LrnsKZW5kc3RyZWFtCmVuZG9iagoKNyAwIG9iago2ODUKZW5kb2JqCgo5
IDAgb2JqCjw8L0xlbmd0aCAxMCAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicpVZL
bxMxEL7vr/AZKVt7/FpLq5WatIuoxKEQiQPiBBRUtSB66d9nXt5HUmirNKrj3bHH33zzzTi2deax
+WOs2VicZqAxBhofvptPb8yvxhn6PPxofLK47r6h8Q7/cRl+45bFjL5l3Z352dy8Ydf0wf3bfZNt
ar1JLZj9N3M2omOc3fTODvvb5nLfXDe27YxtY8E/3PXhLTpwbaCnR3y+wv9bk9uUHBTzvnEBgYYc
EBVPI0QcEYqNbZmePqLf/7speCqGHtGPbOUH2blGhHGgq9jRS/wU22YMPxMM8Dh+vW/O3t0Hc/Hb
0KFIpC2036cuAX/b3CkbLhRkAuG3qfLhcXbzubcXwwZ6u6PR+WETe3s+QA/BbukVdPhgy1CNbhw2
vrdb2PHSi+HL/kroJAQH8PFg3+G53jvEzueCcQmDxkxYN2XiGfApkg/I6F6xg2IPCoKwj0Po7WgL
wqeA9CWixq8wIObRoRUCR+V5TREH4IaN6wEGR69Gjh+jl2VJPLvC+wK9kAWjh3Xw4J3PRICNHYXi
uuDdHII3UFKlH2mINEca4KU0oABQLQVmSSsN3g8CDfpl8JUKsXirGSZWmCeOkPMuU4skCTGyQEJm
m+uGTeh9UMdkDMxZmKhnci9YIjtavGBxp0KacqX0j2y2I548+RITXL5IVxDLybqCGKuPiVB3ToAI
a9LEs4Ik+5DFICVzpKiZLhknIbI+y1JHC8ZJnK9VEwRsHCeqiZvwQVEBAlVUu6qmysMqfwur6mYR
MYZadTBpkDTAFq3VZfp1b5HjQcgalb1u9lQlqHyqrMiTD8NMN7asFZ3PMeGKO2biKPyl6iETKA1p
LesCZUGEEJArIeJDbZfsgwnQAq3Wl+ifLod4ov5dnGQ063/LTX53mOUq+VnEk7KXMWhCuWR4ijnO
mt1R+xT12ZoqadpTC+OewWldFAg1kdSvmhJqoPY58ST04tjJTpGNQlhlSLDlV1acw2vXn1hxzpVD
shNdTsLvtl5WKuuimSgwchD1UgK9zf5Fp0a+7Kh+cStKOdW+W5Qlv8iTnFezV3n2ka/Ip4wqBj9I
Abyu+LrSHrKyusXn5qvQp8bh5yBfl0usnHxiKrFwwlO9U/teZas2MZH4UWNAOlmrlDVWAscmP8cy
J3+Zs3TUbbjzrVvH/Hvu8lgK6UkpVKVp4xVdJQliIvba/AUu/YE6CmVuZHN0cmVhbQplbmRvYmoK
CjEwIDAgb2JqCjg5OQplbmRvYmoKCjEyIDAgb2JqCjw8L0xlbmd0aCAxMyAwIFIvRmlsdGVyL0Zs
YXRlRGVjb2RlPj4Kc3RyZWFtCnicpVRNj9MwEL3nV/i8UrPjGduxpShSv4JYicNCJQ6IE1DQagti
L/v3eWO7SVsQu7CNMvHHzJs3z55Sa81j89OQWRCGHav1Tu3DF/P+ynxvrNHn4WsjgeB3aNTe44Ub
vgg5Gem3+N2bb83+KkPrg/jVrukotGz03X021yOAMdr3vBx2d81219w21EZDrU/4IertKwDY1uns
EfMbvHema0OwnMybxjoQdZ0Dqzz07GFBhXybptk74P4dJiErSvfAKaF5UiLPGaEOQPmoi3gStR3K
75QGC+ynQ3P9+uDM5ofRpBCSksZLiIHzl7pY1WBOyAL6bTjqIRjtP/TMw8L21tGKZVhwb8fh4+6m
KKSgF4yAhUCJAXAZiI0NqALSkp2kfYJNECDwTIULFVoO3NNGWVBQy6NyYzcsQt1cn5NjsdIpQfJR
k9noxE5JoJF4nMVE1GtKEOXnEo0RmovrLoiyHRa+t6KMlpPZKM0iIo2U/kRea6K8nN04r8A1zju0
HRZO11w+jXWZSQCALUelae1II/ylOpRQG7PzSnOV3ZK9JJNOSVPK+5VmzW9T/irJynes6TNiHbt/
1R56x5dqb+3xok3qWxSCwlMlpWoW5VT0XLVUWSVX7+biss6zQBqasmbl0l1qE/ozxKr1fKJP4uGY
NkXHaT+zqScSn9Fq3EVtrxe0GqPr0+UNPlalZ1041su4PCnpWIYkTGWpsstK1vnyBwBI2ffZyuDU
4Bou1UG8Dlcao+1ie9lioUTIiODiG8roGTo4Punk/9JB4hFh0sHR4Grn0rGl5t7U8z/9U1rNXdyV
vvztSlByVmt2xNqytfSTg741vwCTf33mCmVuZHN0cmVhbQplbmRvYmoKCjEzIDAgb2JqCjYzMgpl
bmRvYmoKCjE1IDAgb2JqCjw8L0xlbmd0aCAxNiAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3Ry
ZWFtCnicfVDBSgMxEL3nK+Zc2HSSTJINhBxKXbHgobrgoXhSq5RWsZf+vi8btIroDpl5s8y8NzOs
DZ3UOzF1DBht9V6qPz7R3YxelaFqx2flAqPuoKrf46EMES3fUI2tbk8vajubqKuhfzGqyEE7CtrS
+EjzAcRA2yy2jDt1Maq1Yt0Ta5/woevmEgRGS81OyFd4O4o6BGMTXSsjGFSiYKoJeuvhMQp7nb6y
W/D+T5OgitU9eFrrlLTOnxNhD1D5vv6EJdYR68c6hnXwDwc1vzoILd9o3ZbXYlL4DO0Mtp80bDof
wjEOscksxWWzLJ3JvCidZOsqdsLJRisVG1dCFlfux1U72d8q9SQm2F8qIhMJTzpm4KF0LluuWdNo
qmZw/VlmTR8ZSHNoCmVuZHN0cmVhbQplbmRvYmoKCjE2IDAgb2JqCjI5MwplbmRvYmoKCjE4IDAg
b2JqCjw8L0xlbmd0aCAxOSAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMTE4OD4+CnN0
cmVhbQp4nOVTS2sTURT+5pmmViUS8LEoE7DYgsSkNmohiOBCCiaFBiOu6mQyeUBmEmYm0iBYg/6E
uNBVcaUQ3HRR3JWSRUG3rl3qHyhiaqzfxGlSJP/AM8yd7zuve+45dzynaWIazyFBMyy9ERUEEUAX
EM4ZTzytAF+EXS5yudYq7aXC38h75E7F1Ivb3sEcIN4iv1Gh4sXgYYi8QX65YnkbX5CNkHfIZ2p1
Q88gRihucZmy9I3Gadzz+Tsumq1b5n0v+4B8n3t8bNRdL4pnR9z6pW/3C+Hjywyh6nMR/70UIKIN
SG21xCmy+9cjschcLBJrSxhsivgNtfTzTVspsXdddJSsskQ/3KRXV37bkbcOHzMDJ6A6ymdawmwr
o6/EznMRpuXbh3sFRe31+z3hqpwu7vd/+dP35yBcfL3+Pby9fjZ9gFNTw2J2i5Gdk8WpDqvirHE8
KMaF8oPNEy7CP+eRZKCtXkI3tORXhSivzPLQS+JN/ZtHxPFduDOKO4MPo1yzo7wCY2YDLLI78wH2
c10LsEy8HGCFd+tugFXqV+kpyOwJ0ngUYIE1vQqwyH3fB1iififAMvGnACu4gK8BVqn/MW8saIuJ
RErLNW0tUzWcuttyPdNytRXbiK82TDvXsgr12ppZbtZ0Z6wYo7zpuNW6rSXjycRYy+MZWOCvsogE
nxRRDk3Y/GZQpc1BHS5afD2YsPjVsEK7gTiP2qDOZkSLlgI9a1ijpswMNeiMneQxSZenxmHuKpm/
d5LZk6xnku9wFkM5esreTJA/xc6ZXAplbmRzdHJlYW0KZW5kb2JqCgoxOSAwIG9iago1ODcKZW5k
b2JqCgoyMCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0NBQUFBQStPcGVu
U3ltYm9sCi9GbGFncyA0Ci9Gb250QkJveFstMTc5IC0zMTIgMTA4MiA5MTZdL0l0YWxpY0FuZ2xl
IDAKL0FzY2VudCA3OTkKL0Rlc2NlbnQgLTIwMAovQ2FwSGVpZ2h0IDkxNgovU3RlbVYgODAKL0Zv
bnRGaWxlMiAxOCAwIFI+PgplbmRvYmoKCjIxIDAgb2JqCjw8L0xlbmd0aCAyMzAvRmlsdGVyL0Zs
YXRlRGVjb2RlPj4Kc3RyZWFtCnicXZDBTsMwDIbveQofx2FK2wO7VJHQ2KQegInCA6SJWyKtSeSm
h749TjZA4pDIv/x/1m/LY/fceZfkhYLpMcHovCVcwkoGYcDJeVE3YJ1Jd1V+M+soJLP9tiScOz+G
thXynXtLog12TzYM+CDkG1kk5yfYfR571v0a4xVn9AkqoRRYHHnOi46vekZZqH1nue3Stmfkz/Cx
RYSm6PoWxQSLS9QGSfsJRVtVCtrzWQn09l+vuRHDaL40sbPOzurxpLhuSn2oC3d35Al5xZ9kYFYi
TlXuUOLkIM7j76liiJkq7xs0rHADCmVuZHN0cmVhbQplbmRvYmoKCjIyIDAgb2JqCjw8L1R5cGUv
Rm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0NBQUFBQStPcGVuU3ltYm9sCi9GaXJzdENo
YXIgMAovTGFzdENoYXIgMgovV2lkdGhzWzUwMCA3NjIgOTAwIF0KL0ZvbnREZXNjcmlwdG9yIDIw
IDAgUgovVG9Vbmljb2RlIDIxIDAgUgo+PgplbmRvYmoKCjIzIDAgb2JqCjw8L0xlbmd0aCAyNCAw
IFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMzQ4MDA+PgpzdHJlYW0KeJzsvQt8VMX1OD5n
5j727uPu3Vc2yZJkk0AILpBIICGCza08ClIUKVKihiSQhIRXAgQUkQYFREAKIgERq/wsUl+FRRGD
jxotDx9VqFpaaxXq2yqVr6W+IJv/mbm7m/Cy/X2/n9/38/n+P9/d3LtzZ86cOXNm5sw5M2dumufO
ryVOsoQwYk6dVd00ctrEywghvyMEvFMXNIcbf3C7D8PHCFG/qWuaNmvBz355CyHan/C5c9rMhXXf
9fW+RogHn697qr62uubqaYZKyOwNiKO4HiM2xG7hz4iP9Kyf1XxDdY8f2/D5BOL0z2ycWt329p1P
EtIkYfrts6pvaNov3yjj8zp8Ds+unlX71I1FNfgcJcR3W1PjvOaN5KJOQpYN5ulNc2ubPr5obyY+
TyKEtWIc4Jd/nBhU+DNlkqyoNs3ucLp0t+Hx+vyBlGBqWnqoR0ZmVjg7J7dnr7ze+X0uivTt17+g
8OIBRQMHFZcMLr1kyNBLf1Bm/vCyYcPJ/+SPfIik4X0pv5/7kbxWfOfHXXf+idXzMOYlsd3/VQps
8Uv6ryJaScYTo/P6zh2dJ8g2UkVsndd1bu38Bg7SUkxNQ4rtnV+RfGmeNI9UdW4lv8XYNvIg+TW5
l/Ba7MDr/yCWvfjLn39FVgi895N78H4PuRvvPOZhvO6+EBGw/YzHL/Abw98/nAf0HvF9A787yCKo
J9eQxm6pd5HFZCa7DkNZnX/F+8TOh0X8YjIN4VqRktVYyzmda8n99HKymOVijjX/Gbb97+d/P//7
+d/P/37+//GJPUjWkuXkE3I5WUpqSS0MgkFqVPkEY0vEdxz/mpeNHz3qB5cOHXJJ6eCS4kEDiwZc
XFjQv1/fyEV98nvn9eqZm5MdzsrM6BFKT0sNpgT8Pq/HcOsup8Ou2VRFlhgF0hdSo6nDJo2YHk0b
VhV15g7PNcJR5xUnxhZEiTeUnesJFxWU94tDReVIlPjGRP3jJu0i5uDyqBI5G+SKKOtlfJmNmceG
wiOiUi/8y728uiaaP35Sdq5xJJRML8c80fRhk7KzQ1HaC/9GYxL+XV4droka4zA+O2TFjI6ScZP4
1db53mCMJIOzy/E+flI0M/FYXn4+IlEL6Gw/i8wrYJWxy5k2bHiU+HcR53tREuBgJwaTKBkazY8g
IQaGBDZSEAX/l1HwRSEwFkk+swie7djg8/BgRM303BE1DcjRmqounp6wOJodXhVeNX6SpwiDgugx
0RevmrTLYR+WO6zWnowgu+wOjHGECEYRRNK0C5w/ABGgzhGX7KLE5kIGejnBI/g1PWqursJA7nDk
HKb4ulLaOttv755EMFsi5LNCVqlRZVhUtcgIN0TN6ihZHd7Vt33V7W0GmVIVcdbk1lRfNynKqhFg
F2G9RtRPiPYYM+4ajMKi8KqqD/MGHy5uvPnCI+rDq/CZw1bhPXc4b/Yz4mvqa6t4R4Gq3OGYpg2b
tCK7PRT14u+IqCcS/RGC/ejGD0IYW16eipStGpGLyBB2xPTLOM8Lku0iutvoGsF9c3V1OLpkynSr
c1Xfnujg2auMqPOrbGQ/NgDmFBnjnKqpms4pml7NazFienjV6lpRk9sF5dghwyOmD+cXz4jdm1yN
ua+ZNKI+d0RXgVgvDLBeZ+fNzo6mRXjGVatGcBKra5B6i2RM6KKfd/pQBJCeYVFzgvghEwSLsUSz
enh5PCoOcA3PxlOqhpeXZ1vNiqBRtdcKuX9ueBXHqPaK+iNG9j5Ma+/Xd8z4SSOGh0Tto3TYpEuP
p4aOY3jMuGQ0pCLMqoLjIYtHY36SO+Yqq5HrE7eqCdYIpcmGRdA4vMD6amroVQyPzB1ZtWrVyNzw
yFVVq6rbOpdMyQ0buat2OZ2rmkZUhcXQBox/anUoOvL28qhRVQ+XYCPz7jRy/Jio76prefOMDNdX
W9KgLDd7cCjbU56AGXeh5PhAwg6N3doaSKuMz5E6JwqdUHgklyBtOPBDUWMwH4lIy9WTsKNPFZ1S
3HAA/ATRh/hQYOW9RjT8JM6iUHaiy3DRdlU8FpFkZ/NBsrrNJFPwIbrkqknWc5hMCT1GzIIItl4V
T2lPpASu5ilLEinJ7FW52FqpY37yL3p19x69ypPrDZcWiBYQErUm2j4B6/jN4KhtcLzBfcMmsRCN
h2iI8ZA9ghJqaDQYERk5T1AQrjJyw4dzo0YkKg+b1B4aWh42PCjBINkd4hghaqZzoXk49yXgopL4
jSgMjUIKTyIoOoUEZ8HBmJjMGx6xqire17pXMS7va+rPX0+EMXKxqiEL3uPN5bX9nZBfccHcayQf
WaFsC+Ly8qjOxW9U/1zcsH6hYZPCKGpw7F4lAuER4Xre8NFw1XAhFMpD3aPbOo9VDecyDknmIKF4
J8d7+b8uNc0qNvXfHwZLcBjcfHt5/SVns3nMhGRo/KTFoRvL+xFC+UKIjF/CiEpSTbsKMvPKTJNI
wX7j3f2kbH/B/osLsz3Znl54A7TPT4dZ+2lTJqdIWGrnaykHEc378lo034vMHtJm2UZvoLdR5qVU
ZUBWS6YKmh1W64URWGzsT099bexxUlBWVDm54shxRJ3rUXIHhUuK6Pu7f/Y3yLhpqbRx8YOvId7n
EflCeSlSdp/ZRBFVC5gEwlAIJkgeJsnQUlNoylAoQ1gGQwYiQ+kJGaIybJWhSYYqGcbJYIoEjG9P
JFmRRiJ+pwzrzoRHdBXxz5z4Z278M1nERgCpT081RE1EHYpgYVsbEot0byNEeguDDjLKzNHWK4pd
Xk+Zfb0JqmpnzE5cPtmOdXHCDBp2ASLjmDrax+DsuSS93HjNU1qAf6Qg/XjZcW9pAWcS8j4Qv6S3
Tr0iZZ/exAKnP2OL5aX3xEbeE3NguREsdw+Wq9L5ZieR15sKY0ym5IYhtIWZbgYOZtMY8myhBg0a
jNagVIOIBmkaaBp8/a0Gn2rwkgZ7NVipwSKRjAkY/5aIf1rEY+ZykXlIIudXInWzBqsTeK34g5+K
nK9osEckrxTJmLmPBiENFJH6kEhamIhPE+VhxrdF0kaRBenopwE4NNh0SoPPBCWPiOKQyBkaTBDE
YE0Q4pRI3Wa+JBLHiJSeIvoVkbJF5GvRgFZqcKUGhRq4NZh2VINDGkQ1WKuBlYCxJzSw4ndqcJ8G
TSLJ1CBLgy9EEkY2isgyEUk0KMGEwxqs02CJSBunQYFIOCywrBNFW/GIKKyBoUGnBsc0eE6DrQKg
SiSViVQkQp1cUXF2ZzyrN54nRSRUnpE2t+szOZF0/sSzcZ5bXlf/j5DUgrJ07L0XF0K2J9eTPShb
2hML7I2lSaulj0+lSR/fkxgT87FvaqTMzMDhQFVYb9qYypiiOXygtKgoenA4OM4/HHCUpceHAljD
AEuS5p/+mNHTsTb2e+njmOeejm3W+LsM2mg9nYJyw/0EbKY4yAuM14iVd1A2re/4M82DtocRsh7F
XgwzKaTeHIQCBtZQ5qeUaaSc0A8JMMI2mzID6jVQUNJCSm38CVHayE1UlRfRSAQ83tLUgqIByJA5
pKwdeXG8tLJiDmpOkRWL911cyLXQJz5lMIkCzKkoB8jlVLBYxx2/oXUdF7ON0jenbNLRbZzy8UjP
aflekkKi5siARKU1PrS5fIEG32YftftA90kBzbnFoW3RJRrYDN6tPljgA+bL9RX5pvokH5N8lCgr
Pamm0xmgQYoEgqeoKLUg3Xh37PF93tLSSt6EpOx4aVnHkeNIeik+r9CRVjlB7F7i6jxh9vSlFl+j
TldvVF9WpToZFANuNTYaXxlMNgIGVYfbT9opVGDuOWRORaS8DwwqJmhB5uXmqL2LiwagsYhtnM1O
n574HVy+ZWvLzt8W/f79Vzru3xPbRg/e+TfI++zG5tvq1s754LHlsdP3xw7y+q/GmeQZKUIMUmHm
K60DneB0am7SCqzVbdhxMBBMKiTMxojXYVuumR6tlsb7yz7jCNYtbT/vj/G6FVQct6pk2tN0eEl/
S/9UZ1AxpxxUJFNRAtiLigLFSC19pqh/XklN9Y5tYxZcOUairT2mvwYdUcn7H1saCSXjOj+U/EhX
JrmIfGtWZbVKkhLetFN/Tqe6nu9NaXUHsgIFAWZnAW9rmkHyWxUfLEVaM3Qpa3mG2TejngbCKaa3
x6iUXkh2RKuj7X1ha19Y1xeW9IWmvlDVF8b1hUIRmRx5VtWOL34zkp72arye+9uNI4OPYwsWYC2x
xvGKeksXF6QmquvZmwNSyB/qGWKqP2ykjbKjEmL6dc8om2F3jYqosCf3QC7dlg7pPCGg2ket9Gz2
PORhmqPBsRDnidUMRONGsLNURCIRDJZn5+blDVJyc/IGDSwuLikRba1gY4vW9vh7D9JZwJ9SNKBY
8j9jBPe+e+eTs95+6PPm9SMP/ahowj9qDx/ccWz1suF14+qOpF2XuWPzbTNbJzjc2evnXpq/fEDZ
M8/HLv/lkYMu94CJ5mVXVWNHIOM7P2Qfy4eITnqQL8xxRquzp3OgkxKn4aQ9WiN0CKVumkWpU6JO
vNldxNdqN9JaJR94nW5YTlKWqmYmqacZah1dlwlNmZCVCZ2ZcCwT2jPBknCROI+NjvZ2UlaGM24Z
HxUFBXygHK+oMBI87f+2DR4LfhmkzwY6AnQMhTEhGO6F4Q5o1pZplOKMonm19zT2gvK6QpW2zk/M
nsH0UYvk1TJ1yeCSM+TjMkMdy0CNj0X8gFquP+pnnA6CsoOzek5C9JbLuZzT1DPQWzQg6ClinjzO
bIu9xezjHXPaX/z7yT2vz9ixI7d14u2bt64uWXAtvflu1I1sn0HuXXToqSp49kdVrzz1zBuDai1e
SlnYg/lOztvmFa5NaWaKkbYprTCl1WaQTWFvoRc1NqOV+twyqLKX+JY6zZCzgaa5lspmulxHD4eg
PQRbQ7AuBEtC0BSCqhCMC0FhCOac2V879sd5eiRtP3KRpPKOWoGcjRARHWdo34bUh1L3pr6UKgX0
Wp26/Bl+ykjQCIaDzOkOAHGDvprPneM0qrZ1fma6g6Md6rUqdRNmMBqU+Bw0mbNtMv8jfEor74Vc
I4MGkqIBJBDITkF2lTDBOlXKeueNzth7oL33CtDTp217t//2mbtd9868fmvq5IWQ13kS+sU+/bTg
6QNzYFPLxjuWcXmUhfL4qOQlDomaFTab5nDYUUvGCUKWJQUUSsHhIHZmt9lUWVYkTQKVqCsU8CsK
aCgNVkiaX5I0m+ygErFrquKWcJbxojaMAIoEGgEbsxvEkJ7qPEEUFLudqD07JEXrYwe7HfL49mQe
OUI+IpKDuFRFQcUcXsKMUprURxotlUuyS7rVBQtcUOeCiS4Y6YJiF+S5IMUFigu+/sgFB1yw3QW3
CojhLhjogp4u8LtAcsFJF3zggjddsM8Fu12wzQUbXLBMoKsR6IYLdD0FOoT/ygWI8HUXtLvgsX8D
/uBXooAjooA9IsNGQcqF6P3I7BTgFs0WrAWliMiNieLquhWXJ8raZBF3QBS0PQFkJX/UjcoJ56vV
hYisSRSfpHDaRwkCz6LuLRds/l62JQvYfiYXkixAJCVfmXMEsAWGqaUuyHEBGC4gor2OueCw4D+2
11YXrHPBEhc0u6BK1MwU7Ru+QPsiPLUyNLlgnCuONKFgVp6j9cVVv8qzFcN/pYyeoz+eq1ueJ/uF
0JyHonNBC7giUlRUUGQcQFk6YEDBnCJPsHQwfoTCgxpPe3s7v7zB0rhqtqJ/qqWhGaptqG3ouXeh
uTkoSDYgc+bg9Md1Nyjif+zoM7G3Y+88AzfHNj8PEtgei22D+2OTaQb8M3Y7NMfcKD0yOj+kpXIB
8ZNZZm+75lZauTKzye9FKetyuf0nEMbpXq5qRDGUsGIqkorTRrtp96eOUpSUwJIUqOCTO06+7a92
tL+Jyg1XNQnXbsraO9qNVxPaDQurxiiJ3yIQETIwb5And1CRB7+BXI8fpSAtrb5kxaKWlh0vvji9
f4mSfdf9tGYtZMTeX9ux7VE/UlKCs+03qHvmkBNmmHi3jPNV+Zb4mM+nZIS2kHSws/T01C0Zkm2L
ZmqczH6aVqxpji2KrzwAEtaS6iTs84X0wMqwvpL1NEkIUljIZjMNb7GtIAKpxgFuNXBN9E2htXiK
JgtddEBBfGbgwS6VpjSuPEuZ/kzao63zGzPblzrqxhSY6K/z03J3g5tOdNW5qANnrG3Zu7P3ZbNs
rs5kop4zMasua0EWuyUNltphpDRRqpPYSDqR1lFmmfYRPulagXJIQW2V5Ob0LuHTK9drcgeFz1Bl
Vfrp4vWxv7713aGiZ353+9NPP94P5t697OFHB+4/dOTrY8zWu/3mJ2Onb153/S9vWrHmrrcabkDF
9rVft/8UZ96qzg8kL/LVQYLkZ2aqd4smObcwn3slMdPQiAisVMxUZVFciz0e/yFcEYm37tCRwe3B
PUFWnDIy5UgKu8R/uf9h/5/9ErvSAFMHYh9nr7IzYhtnq7Ixt1QpNUrMTStpI2WqXNltcJeDQXuj
TmGgTuGFAV6PQXPFo+Q9/vnfP/v8+OfHY73Xrl9599q16+grsWWxVoBZsBAaYHps4+kxoMAPoC8E
Ykdjx2Lvxt4ltPOO2AS4AjU0F0mDQ2anXydCOVOdbsXWynp4SFAmyx2m2/Gc45CDeVl6yLG8pjCp
Q5SFoCAEX4TgaAjCITiUUC+s+KwQuEPw+rEQoOqxVugaZgg6Q9AYgspE8okQHEtkuzIE2OW2Iprn
QrBToPlCZEa9JSryXCkiraKeE0gxQ+MXiRLKBHrMeZ94bEyUWSjyHBVYkkVZRGL+SzvjdTBNjjfa
TUOyaOwUeZNkWdk7BeEWcUngC9nk5zfzJ3eP6QbWlXlyVzbx3GW279tn7ENBcqBsckVZUozQfM1b
LFRqNOhkv5IcEaiA8lEQ1/1hyOLVl0/KvqxfWb8dk/qWlfW96AeXXvfrX+auCJRXSU3wLI/4wUX9
fsA1qBVch0cNykOeMX/kbqXc/KBU8tjc4OKKurHcY/o89VRbbjO9tlp62AftPoj64IS4d/rgmA+S
kWjuNvm6uCRq1G3YdLQLs6jdgzIzMXqKDQdIDr+DGg4lpEQUpoTR2nHpl+pj9QodRworY1eySia5
5Sy5QGZeSeYAEOEjp7KCRFC15LLfMnxQoHIVvAQZ8vGOXz65tW3H/Jpf/HzHHY8+/Sg90DFtwa0P
08+w1muw6kNwXDCyyLyaYsRyMCUZsO+fkOGYDEcTi5H3ybBELD1myeAWi5FHu61TrpPhShk6RZbD
Ij4JfKGekpAfyVXJITt2cActRiaiBRBCORQkuaQAFPOHihOVS9CJ86It3CgpTGXu1FQlc4tX6oky
HWem0Epu1lJPoPdKlr0S1XEvc/dbqZkXs5tooSbWPkRhb3KRbRx/czK3QkuF6EL5jU9icSHeDoua
++/r/2Z/Vt63oS8tz2/Ip815+/LezGMT8+ry6MScupwFOUdypIVhWNgDFqTDqpS7Ux5OYcv9rf4H
/Ez2BXxU9gQ8dLnRajxgsFWuu10Pu5hdTVepXU6XqTrRD2n2PnaaZutjoylSnkRTaJ6Q+JLFLXKO
YhGX/FJuTk/s1iV5vHMLca/0sqYBYXH5uoWZ7ZY7Yl+++YfYl+uWVC54b1/7J82x1+puWz5j+tJ1
lT97JLrwxl3bmC3ym5ZnY52/WfRs/x7bpt3zxu/vrb+/3/V1VfObq+vnd/T75c+at22fe8t9ODds
I0S+X16K8jNAfm+OpwA3E5efEJdLoet1XQqsVxgBGYiBHUolq11bXHSh6yXXWy420DXBheaS6xif
/6hL8i62BwNSi2ymyDPokiA0BSEc5BVPDA3jyHFr+YdPBagkDR5ACg63WwvMHqETLTbiK0DmoGku
WOR7xUdf8UCFf5afVhizDLrIB5oTvnPASsdDDrpIgy81WKZt0LZpTNFSNEoSbLX4zRUmsU43QEKO
qr2ykY9GdrZ8/0exUGx5Gy09DaG2uzra4PqH9sbWxTbRso7n5aV/PNh6qPfNK1tQowCyCPvsO9hn
82AJ1zhabskKl4ZsDtvNGSF/RkaIOnIcaAeaPPqhDJiUcVsGVTLyMoozDmR8lSGroYxA7noHsIGO
CY5mByMO07HVwWySw2awvLDbW5y3IUzYejNX8m4I+wLrTcMXykgNO2wuhYR1bzFx52XlFeSxAMtL
bXGZLk6D4UsrduX7vEoLCRthqoZ5Rz+y33it22DYLxYFS/mFxm/62I4j6WnHMSB+I8QTX4arrIiv
v1VECD6v0Punjo2s0Bfvi8SboTItG55JAfY0hcf9QG/xr/ff72fpvot8l/hYAHrBIGAvheBUGiyw
fWT7ysb+oAJgvUZJ2f7sZdkbsrdly9dmzch6JIs1B2FisC5IHXpIp6rk9Dup08mVJTuCc9FHXYwT
EeEmtaUWxRuykv/NKYfEAoScSfmQCfcukSxlKa93fzpoYM+iAVJQmnLVP2Zu27cEyMNvbIy1fRr7
XUcJkC8f+fP0X9z2q1fXQc9vrgfvHGnepeMWTh4+fUT/n/zipkOfLL93+brm0dWX5PUbv/nGRw6P
HSFWQnHeeEmK4LjYbHrlTUQBB1O4UmF4NhmmwVsi3W4vNgy91efzyI6lxAzKDTSF1NEs7PbJVZ0D
51Mv4+xNLfWv9NNieiulB9xH3HS7c4+TznMC8uVPZopDH/WQfa+d3oSWeD4+pHkhhUuSSJw3FeU+
gxQNCKrJhZmSIF98GA/5f3nqwaI77tnwmxfWt24r3vH8x7Gj1A4UsqbcXv6n3U/+qW7lPOiHo391
rF7KxjrqJET+bl5ptNqH2MFtz7JTN3dSNghf1CJ2YktrdV1GDV+rzecIpSyVieFY7jQzsLo9nLU0
mgFlGbAuA5oyICsDOjPgWAa0Z0Bi2o8kBEC7cVwscH1wPLG+ZXRf3xo3RoMxnkUeOjwEwwGkAOwO
nAzQp4OnsNeosFoFl5qhLlaPq9JuZZ/ypsKWMaD8z8vmsveYpDpSQ6mRVObwh/wRP4O2zk8eC6Ti
TBpf36oQ61tzLLmLctYb4Ppnb74G6/GkJDTvHAVKl/xmz8l/Pv3cwh078jeNW3nP3atH3snuvCv2
zmexU7FXN3R8IT8bOxgbNnra688+9UoFicvRKpSjNtQz5pvpnvWEaettrsWS6ZMaqdbCdYsZNOxL
bC4k1eyCLjW7YLsMTncPd1/3o27J6ejh6Ot41CHZ2LXKIwqVlIEKvZYuovgZQKdQ5hCrT3x4cBMG
+0J2mHgMkp1dkj2AB3Kzt8GX8GP4Wezm2NMxWxsM/RZcsf/4OrZPXhr7eeyx2G9jN94DGWADDTKw
BnaswRV87w5DX5tX2CjG25mkSaqmDNb4/unNRMWZQdUkzSbdLCt+WVYwrcS+3ixksIStY5Qwk1GV
7/lpKp83UOPAXiTJclvnCbOPJmtk1qWqomlhh1O7rKYw6oRxTjjhhHYnrHNClRMKnVDghIRmEYHB
nqIiccc/klogLOginC/4VsfcdOQizhoosmw4cfCQCES4PS0PRRN6qDCgzfTVGgQ0YIYKigoehwKp
hIGbQposWCgEDl+8w/mCZbNcKPJhDa7Y/0LHgfbf0sujq99/H/4ay5KXnv6ORjr+gLLBhk2+XH6H
BGCEud/ualWJYRhUNdC2BtbqB6fN5hA7BdRBVMdytw5BppuGMyXoXJ5WeF8Q1gahJQiNQagMwpVB
KAtCQRBQbLiD0BmEL4JwNAiHgvBcEJLAFqQFZgFg6k6RVCYyDnlOAJ2LK4miKgiFYlK28mNmUwC7
g0mWd9fmuunu51n5iIDRnp76GjIQR/abkxNLAwVibWByRTvfj+Psf7ynF7xczntt7lG+cFom3jAk
8RBEIhESSeyGBAJ8qSCXLxsINYgu73N18aWFH3ywY8eO2+64St6zIm3qzGlrTy9mS9e2PLHJ2q1h
n6Ny6SG/Ni9TW51OTW7VDezJGiwnpo/UU7FH49X+s2p9R3tynLaXJbbCrS0qo/PY496UUWIi6Kk6
RhW7R7ppT9SJalzNLilbuUqpVuYoUhb2NJbFqMF4nxXqUAT7mUfY9kLyCIWPfb5T6PE7tu3Zupfe
df2yhzuC8qGO6KNPP4L1vLfTgHvJO6illZia0/G4EjWJz8lL9qjeYifDCu9ipu5muwYUxgkuLTAO
RMTcf/wkmldyl2qp9i6GtEHDh108ePxbvReFlMsLikZea+6bPWoollSDs96DOCP0hAHm3FTVrq5I
T/Wnp6duSIfr02GLHX5qn2ZfYWep6f5su4oVbiW0NdvwtHr9rW5fanpKpl11yqRnCs4PbicKkDxn
A/V65OWZJsnEx16ZddTIA9SnTuTBsTxoz4Mq1K3yoCwPMD7e27rbiUfS9nc9vJm2v5tew3tafA+R
X7ztxEainthINCe2BeBz/bROB2eBOwuoC9Q3wu+H6Z4waGHYq4Oi5+l0I9vOaGmPhh50dAikLH9W
z6zhWZLDFXJFXGNcku1HjhWOTQ72kh389uH2CXbG9czJXXpmXGFBDcWaiIPBFMtW5cYrX8bp3Z9Z
3A+yy+7bdMOSqytWHbzj/efff3bgrl0gzXx83fQJvf/08tUvj2OllZdfVnBpqPfgtbPverRh5eQt
Q8dfnB/50aSS235VcjFK6UWomlwh7Do3WWBeaZdQEhnczYW6UT1fbrrA8HArr9MDxzxw1APtHoh6
4D4PLPFAkweyPEA8cKJb0lYPrPPAlSLpfNZcqrEP9cd9OLArLUudG3VnGuM7kka45O1mfAOp6vxQ
XoHac4B8bg7/xAYf6yBvCLuVLIUqtvUmYx5Uf4XoZIa+3vT5lLDLW6zIHoP/Gp4gcYBTcSwmZgqZ
Sbk1Ee/dXHV4dz8n7sj+SFzD5X0kruTyQNLuu/bDADzlhOMAmwHG+Bf56WrvFu/TXjbCgGfd8JAb
Vru3uKnPlesqcj3ukvxaT20gmhS7tX2a8hzXO7aodIQCq6Ut0tMS201hI4XRdCH9NLGS1/UhCbUs
O4xqWXYOn4iLwqiW4eRcBZtgDAz7+4S3Y7GvYn+EXt+B/dPxp2J7Yg/Hmukz8CPY8ts72mLPxjrw
++Iza1+Cn8c1C+mvOC/biY8sM/s51hs2sNk0H9cwvJOkeom6W4hUJVEfkwIOrcVu+u2oaQQA/yrm
JG2vd7naWUEsIZZUQPNmGIsMWqM36/QVA/Zh88hQx0BhX+E8Xu5p8NByV4OLAu/icxK1E+aUlIuW
lS/bUpmyt9Hx74Ae+/ajWH1bGyzf8tCjd8UWyUs/feLJjo5D9NU7lzavIwl5jdLlLHnt/p8krwMX
lNeS904uruN7nblYT77iutdcPSIFrk6pTXkihV3jn+5/ys9UX9BHVU/QQ68xphtPGWyEDlfrtfoT
OkMbscmxxNHuOOyQ3WqLulY9pB5VZbfcIq+VD8lHZZlAEyyBdjgMsip7W4nhbFV87qXMTGMNNLBU
M1O1Oro1DdalwZI0aEqDqjQYlwaFaXA0LTnCz7vYG9cnsaXncD0ZBhCxKM13M7svQdAhfwU19u1f
34t9C+p7P9/+f+7c8H+2S5HYm19/HXsTIt98CxednvDBA4/98cjj29/n5xw7P6alKAUYudz0ch+X
dywfF0YkCj6KuuEeYjAiAy0oMtoHDB7MnVjaz3BfMZ0qTIOD8DF8jbWGyRXlGuQCLY1NugMelO/9
brT8ZMLHZxCOFZlkmwZl0nrwElVqAVOBGYn1beM1XtuLC/sAzr3Z0qDTjW30LXnpqTQCnSdjE9kJ
yYsq61RzjtutO50uh+GocoPbDXbZ6aCDHYaxglBUg6lbdxv6CpfT73I5tzl3Oz9wssVOmIHaqxPG
OCHdeZHzEidjDic4UNV08twlussgburQ3E6vqrWaUg/qcCsKRhJDd7m4ktzpdrnJtEudbnfY43Wj
jnyrF2q8MNELI72AmlSKFxQvfP2BF4544YAXtnthoxcQqC4BVOyFvATcV174KAG5pxvwgnPgk8BJ
yCRYd5iDFtC+BNCy8wH9O4iSMNvPpN7sTBK/6aQXjnnhdS+84IXdXtjqhfVeuMULzV6o8sJ4L1zm
hYFeCKN+6QXqBYT/oBv8tm7wNd3ge/578BO7wacI+GlWhiPdMmz83gzd4SEqarBB8KxJ1GCCl7tv
FIoa+L2Ac+cJZMAqrPObgsX/To6SJHQSNAmXBDovDB2XwES80O6FdV5Y4gWMLPCCISLV7gZA5Xn2
Sr93n7Tyv7izem6GC8FN/h6E50UmLMqEWekpSi1AK5NwHeJAGRqXpXyTNmK5dsR3pFecYWTq3MgU
lmNi51aIqJzH3OBioEos1WUUb3Y/5KYbnaA5+zhXOtkq+912VBcEPiIW27gjnpLc4Cjhu7rsROya
sbsfuKqyV8WAnywtjE15HC4F1KlO/eX5P/ZZnXn77ZJ+ej8bEp9JFT7DhNn9j9s2hUJCdrg8o7yt
wRB+/Wlya4bRmmYE3OD0c0ck33K/6fQ7SO2QEF+7yc5xopZYkQOlORDJgbQc0HLgu1M58FYOvJID
e3PgkRzYnAMrc6A8B0bnwBABh0AI86kAeykHnhYwq3NgYQ405MC13SC/zYHPEtieTYBZMFhknxwI
CWwvnxJwL4kirfIsoLHd4JK4uhe5OAdghgAdIwrMyjE7QRKQWORzObBTgLXknAUFjhy4u1PAHRXo
EG7LmaBXikr0FKBnga0VYDUCXVkCo7sb2CMC1aIcaBRIrPKmW0Q93Y0oq5iQ4OcXInMSYEOigIgA
wDqdzIG3E6gtKgeKJCy49JRIw5xbc8wreN7mc6p7KsGVbYIyKzUk0B7OAdrO88K6HKgSNBXmQEEO
kBywJQdW5ble6GeMu/OOuPN5Wpw7xM8zeCvPB3mm5LggwoRzvJjqByS1X64PcoXw8HHLtc44Hkks
Oz75ZuYHmSczWSZfo9BU56g30t9Pp8IrMV1zjjri/shN97rhDxLslWCzDteoT6k0K+G0SNKNdLRe
uMrId/Ekg+93VwqfMKGeRvjuflx9VNQU7u95hiYZFNqkkrtj6pQfrCmlOyoqVt+yY8fKx98Yvfa5
ex6kdy3+2RUjPBd1DOGhuIq5Y0fbDiI2ZISuotCYOZDKMFhWZElZQQCVE5AlWZFWMOpnjGJaCVEk
5kYFS0GVFAwFFRzGhMiQmYzqBlBZDqs2GfWNZTa41gbDbRCycbeTr9+2wT4bbLGBlTBGJDhsgPGv
iPjVZ8Z32uBNkWWrDTaIXFU2mCAwhm3gF0gPHjsHyIKwkq2k7vEWLWeRkozfdCFakvHnpYITYb50
AVotkGnnkuL/XlKS8WdRUnIuiWVnkfKvmHYuAB1ngwIboD1IbPHJ+jweVOcZQmcnnX+S/ZfZLjDz
nj0Uu9ZwcVxYy7hFYoo9/9qtmEszZsjACpRGhYa5aeumjZSqBMAlAWQo1tyM5tkcUmn5s1uTZ9XW
WFViyvy75LXmSkpK0SooktegBe0iN5g/Ul1O188V1a8oqs2JBoIzrHuKg04gqrO3k6pgU3CcaK7N
oMpBGQcGc6qMeVUnGqmrnZOk2yRKJMmlFBQVFVRWDO0Y+qq3FM1qvirNn0orK8QOp7WhJmoorBjI
FUcTAPWNbA9IRW/s7lhDN9z5Rmxh7FIoib0EJdtZ9PQ4urpjPqe5Hi3IXsIPvxf5ozlMIvABOYnx
WsYW7ns6jq1jksaY5vZsIV7DS+3M6/VvcUvBLZrPY7q9ozzpK5VcstJp9lZuonnO5F55x37j+L6I
MPi6PJ3EvnnFnDjzr97eE25M+XMK1ezl9gY7+9T2rY3aDKcxymEL2agk+aUJUo30gXRSUtTcXnf2
oizgC+QG7gxIG9yQp9+qb9TZHjsMVIerE1Q2UB4uT5CTSyVkcnz7qhyKxR6Mn+Za6yTxnSyIm5rc
l9sL2YVtdXs7vnzry04COR1P3VO6Zt3DbXDxrXdsXtbz8uFDht7LnGPKY98dejf2CcyEa2EO3Fy9
dmLH6Zui97Q+npJfPMF4NHZC2OSxCexj1JhSSR6MMfWgO6/V6Ux1ukelt6akcFk4F8POFGeKntHq
N3Jb3TroPnlToWIq4xTGhDuRy5Ph4XuX6cHlqWZ+aj1V5PBSj9nbU0fNfAjnw6F8iObDOhEm+TDu
aD6058OV+bA1H5bkQ0E+uPPhRD4cFgExwcaHzOT4GEps4qbtT+6acQ/muANzhfBswAksImawsniL
Ve/OhqezwO6Gv7lB9sGHPhjtgtG9YGQPGBngFoicA1fn1ObMz/lnjiRnwtWZtZnzM/+ZKS3yrfZR
1R1000Xu1W6qGbpnVJMaValE0UQ/YBwxqANCQMV0FrG2z+ILQSJUcYaXTjeP8UHneIx//pd3Xyv4
3ePL75zT/spnJ/e81tjdczzrhVfmrGm45YZ77ob+YOcO5Is7srr5j6PGG9tN64WnV5EZhLBKcKQS
t2PpAgl6SyskelgCqQCpOm4caS8agCPS4s1jk+wAFXyHgfuZlQQVir2K1o9+4/nn3xjdumZV7P2C
D2EbyCDBtg8LXo7VfHUyNpVr2MOxvGxR3jAzrIQJSWN9WCljNoblKq4qFVTdvnQhW8kocxtHeLkV
WLDwJ4yX/UQfGfoAFl9R7kvhzm5q72LvoIG095p46Wta5UMfxq6LnY6dil2HpcMvvvsK7nkZS+fv
QnoYZ3enNMSc0M4Os2OMhRhoaF+A0+GMT/PU7rDfZs3ykmbTbmMSBiVZtakrFGwXRb7WAYqDTzgM
p4iA7AhrzmIbvzGuwPSwG8URBsKZnamKXXMSt83hkGQKXkWoB8QA2ungPuaI9oQNltjW2bbamM3G
gRkjqhJW2hV6WDmh0EoFxhF4joCbZJGjhKmMmClpo3Qyn7qUZjpRR9EAkg7ffaXDBzoc0eGADtt1
2KDDMh0W6DBSh4ECKEUHhPlIAGzTYaMOC3Wo02GCgCnWIU2HkwJgnw57dK6V3apDs4Ap1aGnDn6+
sg8vf5vAskdgaeiWXxNJe0VOzDZR5Iwkclr07TM7Rdb7BZEIOFeHGgE7XJCakwDfjOS+rsMLOuwW
VbLqUyMovqxbrbD2X+rwng5vJuq2PgHcvXo9E8DJSj6WYMStCcjhAtIqvuGrbkitqi5L8KM7RiWB
cY9AZ9WpIVGh4u41FzDbdXM2rBTVhipRak9B1uCTorB9AssSUdIYHQoTnD8lkraKAhYJNljsCulw
QhTwiuCT1e6YWqYDNXQguhCIZ58LPEffqDw7/XtNiu9dELiww/i/0HHOY3Xg/Mo99rh3wRwPagNp
BQOKhFJQUVQkvImLigYPJqlc8ykyhCM4Birm8B1QrjDMEQf2LG0h7hd+5g+Ibf6EflRs52dSX5Le
kj6V2AF6hH5E2RAZBgLk83NTc+daMyzkMrGf7cM/+eHYKxtjsdbYK7t//8WDJ37PlSQ28vRTqCj9
hfXkF/cIQb0jW5x4CoFkjjVa7XY+RybdQWThDkJdJK3V8gdxpiyVhSeILnxC/i1/kMTE1uUqeMah
p27GmTlES01LpeWpDalU86f5abm/wU//LEO6Ck+p8IEKshpQ56vLVSmdwQcMZBZg89lyJqnC/cPs
FUgd1RJ8LkibAtEAdWvg9nCP2UMqLFHWKbSdL0eDo6uNLa9L0YhiguvuJxL4v/UTWSgf6sjochMB
UscWQZZYnw6aDlgiMbklKAGRUJE8TsrSX0U1keWyQUWQldvYe6/0YOwN6Pc23wPqPAF3Sr3EfsKg
vUTpbDd7oI6nRInh5MqeM+r1MfdOUwukpgV21hRae/OWN2oE/xBvtw07X/fNu9CAkSMHFA0fXhT/
lXqNGDBgxAgMnm7DyOHDMWStrON0spQ4WdDsdOB0cYvd4bfbHZokSzfbNQxqDirz6cnO3FKWVCAx
VVIdQFuw40AZgSsJaPIS1XTzaVs9oVIns6t2MuNSJtntYbcdHMyl29EARflic+jQacmYp4WQmCEE
zMCEaFktRM6QhCBB6EOPiOSwkD9EiLnDAjQqZJQlDS0RZgpIQwiyTZY82ifQWAIL4cYJgVWYkHaI
65igBWHWcVzmH6Gpm1izCk2WeFZxybKmJQvqXkqyCAv/sm54LaQWRqvGFjqEL+kuRJsTiBwJRE8n
EI1JIDqVqKclsGmTKN8UshfpzxJMS673Vn6/lfh9Kz3/3iKtBZXQfrtOjE+2jnVbFqMw8qx1HByJ
xnE0HQsOT64Q0rOoqP3sMzRCXIwMUOhFB9GrKRskXy3TT+yw1/6Snf7Yfp2drrWD3VTtowJarUZ7
aVDMJrI6diuT3kINx3CgeVOIqXs00FByPO5wj9K4G56BcddKqyX6EiqYhuoQ7mSRCP/jJ48j8Qrx
RR40RPm6DkC2orTFxm2MDX8wBm3wKI7we09NkbaeqpKXnmqU7ojvhH6DctYBD5hVqF5RCszOHA7u
pbeCOFC5c9g07TY7w5HFhgvRZqMO1sLWMr5xpinErrlRdHjfoiDTVvoAZfYq0kQoc1CmtXMvvrV2
6sGxBYTwLc9b3d5iQkwUJiRMqEZcNrZcNokMduaUa2mZC7Jc0OmCoy445ILnXLDTBZUusOJbuoXd
Lii1zn9tFQe5qkSeZJi44IQ4I5YEMF1QePZJrzNafvIZHaeb70dHuzhLFT9AzgVzkXFgQKVw1yrj
rmBlYmINFom5c2xESiwlrLAt3metzCd2f22d7Y+PvWqUjbMiN9J/lORodlBDMzFOM/HZQSHVBWOB
pklgBFKLId7/+LljInaAwfLW4Uevvnk1tnLRjh3w9IuxBirNj82RD52eD6/FqrmXO9+D/BwlpY62
exbZavYjWevD7kI3WgluNWW9jQXXq1xDpi6ZqL4WpzO0mGWnBFtUM6wmNin5fv3x0gI09bjtV2C5
s1cmzyOZl87IWJSxJYPNSFuURhs8Cz30iOsjF/2tLg4a9HQsc2xwbHMoipQi3SptlCQ0foopvcgP
xY6JDmHLJdoh4X+eHXeSFj7SA/nLPuI7+2z3hm2xI7/r2EH7fAzSyo5+cN2aJ2NtsQdh2v0HXn4o
to3GQk/e+sIH8tK9v5q2pfeCqQdOPbF28Q23Y0fLYm/QNfJWtKBCZIp5iUFTbFGqE/o4MUMuSTdV
7JHiJlMq73IYRppDT9sV9hX6TN9Wn+TzZfTYmQH3ccXBOo514DX8MSzXJu710Z7+6tgPjHYD2cVf
/qAEUpITW4l8xhNds2jQ8MsGDB7/VmwvhoYNGHzVW/KkoVcpowuLRl77w9/OHtUtzFcLQuz3dKV8
r6D9WtOV7kxzPK6TqOlXpHTsQ49ztyvel3pw+onm1HaxdI+ue5hnVzB4Jt3HBdUHjOMH+Ek6i25s
4ZPt73Ciz/DL6nXGE5XilPZeFFufdNiStp+X6FFDxarRCfYlUp1KepJ3zXqPpmq3uD1+t9vzlRs+
c4PmVj0e1a1JTkrWp6amrKeSM40rEGnRLK/mhm0qGKqpLlHb1cOqrHpQxDh9LYVykxyVj8mS7CYo
LlB7QQvU4eyxM8fslZcj1A3L5QzVNw9fFZtcwV8HEOQOWaSsI/IaX2o67sGIAvyc46OV/rQdFqAY
preo61W6Owh9AnDEBnkobrkNqumeUbIUkCjf9rdOqBNuUCObhFe/oqi5P6AlxfE3P3RXdOpf3/cX
SB25cmoNvYeVTRrZMODXP7+nHeYWjRzJNRu535x3d4z7xbyfrJrVuKXqkkkzSubdUXe6NKn1MHJN
Zz/Jr1xGskk+KYAhZnlGQf/M/s6c/N6u3hhY4+rtd7l6r8yEGZkwMnNiJvVn9syky7ioK3SZrnGu
JpfskHpn5mQ4C1z9+2g9csXZRdMmzi3mSrlbFCalbUk3eZ8yf4LR6ek9Uvw9tgR9dZ4FHtpAFpKV
hPV39XVm9iY5fqXAGWQZOTl982x9V3vS8lYTc5xnnYe6PWs9z3kYV9HDpIpIGrvY00gLyUy+6ie8
OkQDYR/cx3skWh7v4NXlN4dqYvurnqKkl3r78VeN9qTTOm+5xCk+0XYSbztVHyp1Odk+4fZl+Sj3
5TCd2J8sp7RlITRFCG+1ct/A4pJBRYGUoJrXG1Vo/iZHRQ3kDsrrXZIS9PRnskdRAv6gTzRj78nv
HJzx5/svXfzCzx6KXP3hCzM+aS848PjuSdUlsO2Gnx28e+6KBUul3K0vGdu3+5s3zwzGinpPunjq
LU987n/qKccN997goJ6h+de13AwPO5quWXVpRy//7VXjZ/flqzrcy/nH3E+bucxS1aYqtluspRRV
UW3KzbLkl2WpDV4E2gdKgbZJL0q0j1QqUZBUlcmKjTDmleNrIyq0mJIk24giZ4mXOFURMEmUUC7f
D5Gj5Asiq8xOrqeavICW2rkT9alP7VCOxpsdXrLDQ3bYbIeJ4hHTvrXDSpGaZgfFDi/j80cCbq+I
QogDIs9CAYQm4KciCTP3Qf0ZcWGGIwLoMTtss8NGO9xih2Y71IlCLrPDQDv0tIPXDpIdTgrsb9ph
nx322GG7HdbbYRmORTtMscMEO4wUZSB8ioD/0g5wzA6HRYao3fwMttphgx2a7FBjBzOB3I8ahx0a
EPsHCeDdgpp1dlgiqKmywzg7DLdDWEBbpBxLkBIVwBsEZI2gA1EXCtREQO4TqJYJgAkCT88EnlIL
yzaR3JTIb9FlFYM0tQuCLBRWqpX5A5H3aZEd89IqUWwBV6XgXK34AksE37fYcJYOXPmvnB+66UXn
RMSXjOPDew5fcuCLDqkF/OU/3INKnDQvLSgqEqMWdeUz9lni65P1MkxD+3cOmrlcc+XbKPKPO55q
63jmVXgD/iovPX1Xx4c0xOo7IvQP4iTxh/Jb8ZPET5iZ3juI5LxD8bkXc+ezRhpYzJ3PZtIlaRBO
g4qzjzp0O1FcsccPG4MgpfhTKD+tQTf7UAUPGXSzB+0bv061BS5UVuoctzrYw7x1Btp329kDfC9t
iI3epsJtMjikIRJ9GAcmHUh3o97LCBTCOGB6fAu265MI83Vg65CEuIN1TkJsPrAsKINFsSWxA7F9
scVwPYz6HJyx//j089gJtFvvjc2K7Ym9EJsC98IP4Eew8bv3YRA4QIVLMMO3sW9iLwov7Q/lPihb
PGSVOcCjMucdzGe08NOls6kN9TuvKk6AJD0YlwgnxiofjPNB2Nf1vrdz2RZ3pTf7uF2VrhbXWlcn
Ko+OccJTUHJY9naLJHGpG6ZNOKlL8YMNWGE/r23i2Cg/SCv3ib0W+zx2PPZa25t7n33nUWr7JvYH
yP+atZxe0/b7N/eyRuEJ1yC1xD7DOdB4AvgLrCSDn9cteNV6hZXUcmq+tDrWcEvc606+XLxt7g0z
+yxb5uakLXOLZcuIbefh/mBxDYM9llFTyRqFUaPYNcZNGj/tSek2CvdR4MYMmjBh7kVYRajKuN3S
IptOuZuqzM/08xcucOOgQrwCiy+vJSyD+DbjBW0DM6BpaVqpxvyXwOWwChhzAwTEHiO3NM7Q/OXL
P+p4dHdbGz14tGMNPbit4x15aUcV3dqxJ8GHXMGHCrOErbfZZIfCQLZDCzFdZDZVpTjlYWEdRRMG
UpMwnMaJt2ac1QkS/qwd7dyhtT3+Kr5cT7agKBsbM3fv6S/b2pi+l97TUYPU7KY/JnHP6404UtPg
CnPeReQSQgO+IKHB9aY7tSC1LLUxVVJZaqrPhcLNK9nDulFs3+AIO0zVVuxwrbdJvvWmeBOPXw4G
jYCD+2M77AGsCTFz81FvT80sFlaMh4WwasZi/ooeHPninTzhUNexz+NCQiUP6u6Pv61M7GmhrCrr
OIBaRpp4jRvfHo6nYYqX6yaJ9U59ewDe80Cep9hThzo270OVqGYcd0Mfd6m7wc3cBj5+rsD7ElxO
riFPkZeJ9JAGznzdO2qQ9wkvDXh7eQd5H8Dgh15lkA4BvZc+SH9C/1CXezngCQ0GqcvVVvUBVRrE
lrNW1uXaHRHbXfFDd+W9lPg5q7iDdwCDA0r4S+fkjZ/GdsXuj1l+3peenPCXWOep2F9gMKR8cFts
MR26cANsgR/CZZafd9u3sX/EXp0AZffE3/OjzuLra9JPzdF8hyeultgpozc77H4cTXyH55auHZ6b
rR2eRxwQcgxx0Ee4qwHKxgcYPMD2sz+wD5nE+PpFhs01ijCI7+8wmyPiAJcDzt7lsbZ4um3smGSJ
pcjgqNPJ69StVCr3KYeUowqaAeJlIczDXMrv6U/FJkOJDkEdVB2+/VqHgzo8qcMKHa7XYZoOPxXJ
vQXEH3XYJOInJvYmrHhFB8z4cSLvrxJ5S8TeiYX6pY9FfoRo0+FBHe7S4QaxgTFJh8E65IuNHYT7
RIe3dHhRwGzWYZUO9QJmtECXqoNNlPSiKOY23eyEUSK3lbL5YAL5bd0y5id2jRD5n8Tq21M6PKzD
3WJx7kYdputwjQ6Xi32kiwSwHZmhw98EMS8Lmh8S9KxMkG3BX6JDHx3SdXBicR06fK7DOzr8Todn
dXhEh3tEATeJRdDrxJLeULFR1UMs+J3W4TMd/iIIeiYBT9bo0KLDLB0qdRgrFvkKdMjQwa0DFvCF
KOCQKGCnDr/QzfWwVofFIse1IscQHfqJDRsXcvaUDsd1eFuHV8XS4q912KLDGrG3Y2UYk9g8SxM0
fStoekfQZNXhF6IOi0UdKgT8pTrwDFk60E4djurwnA73CaorkztBlpbUzR/sfErS97iUns9l9ftz
XFCxuyAB5136PDs5sZYkJuXue0PWzlC3jaGKiq6toYjYYLdWti60KZQ4R4zKO0q7h2ToI8EmCe6i
sB1gHwNSAXMswoSbjOUpg3/qrNjsaOye2Ipo7OZ9kAX1T0Id9JOXfrdYuvtUnbz01AZpJr9QMo3s
/FDiK//pZKWZT1JwHtlCqS19c5DZtxAHaDjRu7bYfGnGStnsId9EyeoUMwXN2d12d3GKveDAmdrM
PpLwOxFrWh0HPKWJRa3sx5wwQalRmhXG3UuaJaYaTvco8YIFvq1D+eJhBCrih3els16Yk6P25q/l
hMunTPkQfLHP3v/2UNGzL695um1ddfldLKOjhU3M+OfLr4h35Dy6cvnW7Ay6Y1tib0XsyXjoIrNT
YlQxxd6K04v6C5UXS6ZkZmYWS5K20216fe6dNYUNPjjgg5U+GO2DYh/k+eAtH7zkg+3iZZh9fJDm
A8UHf/zWB0cEnAWxR6Rhwl4faD6460sffOCDN32wzwcI+p4PXhfh3T643wfrfbDMB3N9MMUHE3ww
3AcDfJDjA78PJB98KeCtvI/5YJsPNiTgaxLwA33QMwE/7aQo9iEfbBYULRTEX+qDfj7I8oFbHLH5
wme+Am/74BUfPO2DR3zwCx+s8cFiHzT6oNIHY3wwxAcRH4RQXfdBhw+O++AdH7yagN/ig9UCfoYP
rvXBWFGCxQ+ELznlg8/OzJAkpkFksApAkjJ8wEEtWp7zwU4f3OeDRQJxkgQkmh4SyZi21gctQps2
ExXqtth8hgipnDv3gmP4fPLg/D6v3wM7OenVc+YZ2rnJs5ndVsysFTJr5++sg3Utveb3+W1NYmNu
UMdg+iJcceqa5AIVt8hiv5ffFn5iOeSUOexW10eur1wszdXHNdq10CVlrFclj3s9f9Fjk3+JX0Id
3BVcT3yuxfx/aqUvtoexe/e0N9JcCZW3nhDuCRVdry7gr2st4AZI6Ts4YjsOlHUdqpu3JwfC2YXZ
tCCrLIs+lQlP9YCCUFmIhtMK0+ieVHg4ALc6Nzo/crLrNfiVDUbaFtgO2L6ySb9SYKSyQDmgfKVI
T8iwnR1hHzE2mr5E6fasI1mUv3aFOlJCKZEUpg7SR+j0U+e3TrpM4X40wpQjZ7eBeFtl0rDzEzXx
KoQ81t3E66UkbDsw4abYt+9V/mrCuPS5V0Sfr/sc9NiJvwljL5Sw8WIzY0+ejt30wzuNtRk3Q4Ew
+BQYkjT4+Mamddn/0bu00j30nyRkE//55P73M15I/BcU/oYqdZbC/1edGv+fbyKP+oPYFWRY8p+l
ADnzM0LBKGke4f8z7Hl5ItkmvU8ieG2jD5PLML4er/H8/4nh82oMj+PP4iIkC+MzMFzC/78YHOy8
A39XwEGyBn8nygfJNsS3COE4/Or4sx3z2Pgz/t6LaTUIvwjTqkTZ80QZojz83SaRzpMKL5cf7p9H
SpP0YBxewzFfGs8DK0gd5tmGsJgHy5oo6M/CKxTPcw0vWynFcg5iufM6T3IYThOPU9eQLIQZKXDg
M/Ilm4wlD5EPaRFtoD+jB9hI/K6Xxkr/kH+u/tom2aJapr3A/rD9pOM3zitcY1zP6lP037rLjQzj
DuOAZ6PnuHet95++Bt8Jfy//iJS7U7ekF6avChX18PUY02NV5oGs+Vl3ZL2efWPOtJzPcy/PfaDn
2F7FeX/oXdP75d7H8mvyH+5zS+RQ37J+9/avEC02gr8KWLQXJQYpID9BC/AVaSrG8dQgpCfb9fFk
G/M1yMfjYYp94tl4mOEMuy8elhDm3XhYJk7ySTysEI2cjIdVMpV08JIkDZHWQVU8DMRPD8TDlOj0
z/EwIwPpJ/GwRPysRzwsk1RWGA8rxMtGxcMqOcCuiYdtZIAUjoc1MlgaHw/byTfSqnjYQYrlW+Jh
J2mS2+Jhl3Okkh8P64R4Zw9vmNbQ3HBjbU24prq5Ojy1sWnh3IZp9c3hh8IDCgsLwz+cVlcdHts4
u7F5YVNteFjj3KbGudXNDY2z+4d/OHNmWMDOC8+tnVc7d0FtDY+cUj174cPhhnnh6nDz3Oqa2lnV
c2eEG+sujClcPbsmPKt6YXhKLSKa1jCvuXYu0tMwOzy1dm5zNf5Onz+3YV5Nw1QOPa+/VUT4h2Mn
jK+dNn9m9dwzMfcLdwF0hSbWzp3Hy7q4f2GhFZtM/n9KLBlOGsg0vJrxupHUkhoSxqsan6sxNJU0
kiaykMwVUPUYG8YRFSYDsC/zb5j8EOPrBOxYhJ2NVzPCNyGmMEqsRszZJO7VogQO0V/kmonfcDe8
88RTLf7W4u8CQUkCcgrmnk0WogEdRngOyctrFlhrEHIW/s4lMzCuEWn5z9AUFiXwunNcC/F3ioDm
FE0TZTYLuiz+NIgcU0UM55P1PJ3MF/WZhzANmJrAPQ/r0a0Wgr6xZAIZL3DPxxRO/ffR3O9MPiQx
nC9uoqBqXrJeF2PpvKW6w56T+380Z/9vKfq+HMMF5PWi3Gn4fCVC1okya7+HX/NE7DwRqhWU1gku
Wlh5WVMFdh6ahakzBR9qRG/n/X92vPbNSEuCP7Pw3ixwTcVcM+N5+HichVit2kzBWA57vRi/9aJ9
eA4Ov4P0FbjmizHLRzHPMavbKK8TfOE0TxX8rxW8rhH1ahK9cqHgMB+dzRhzCc5ZBVgW//bH1Gnx
+pzJw/5xGv9zuQpEvllYesFZ/JmbjKkUrcPDN8Sp4/AunF+uwPaaQEaTkXgNQ17w8JUYy9txJN5/
LOJHYMxP8M659SMchSPwO1bETsA4lzj5YcdwfbyFz23HRHy9eGpC2hoFxFwB+18ZK/nxsdmn27hp
iEvH+aJ38TblZSzEHPOTtHDuLeg2jubHOTS3G53WOJsl4C0KOW0z4717dhw7byGrN8wSsc1CCpfH
S6vH9AUCrhHpSIzQRO+9MMfmiRKbsQ9UC+xhvBrilM2N9zoez8e21dPrBFdnJeVaON5b+RiZJsZG
Im9X7z+3lJq4hJkrRst8wYOaJA8bBe0JbiT41MWRqYIPXfyyKOl/3l5ybtld8mGBGJHz8Z4YsdWY
Nk/U4lzcV2PJM0W587q1cxfnrVY5U2ZaksOSRU2Cjw1xufXvtHBYxFSLcELyJcrl80BNXD/g/Ko+
Z97um4Se262XdvH0+/kzMy6Vmkl3GdiFZbZ4akqm8FpZfMgng8Q4uV70jBminbuPpYR866KtEWFn
ixE7X7QEp6A+WWOrzO69PTFjWWO3SxtK9MXz9a7vq3P3njNa8Ofc1k3M5nMwvlZgT8x1Vvmz47Pj
7LNaai45W5tK4OZ1bBR6Rg2x5t0FCFeLVJ2vz1+4jyTwWeO0Nt4ONWeMwAS+c1vb4phVg2YhF5q7
je1EW1WfxeXzj8vvk1QJ/n6f9J0quJyYac+kyaoR70eXdMN2Nc4YP8TnwWQgKUF9rAT1qsH4W4jP
lh4cFiN3DN4H4jcf4/ogTAkpwiuMVzH21lJxdWHl18h4zc+uXXdpnZgJ5gtNY1pcfzpzBDYJmVEd
z71A9MCGuHyZH5eTtVjjcDy+NllLTsV/Zn5OpBWcRfuZczK/fhzXOmbjfYrgsNV354t7bXyMW3W8
QoyjG+Np8+K9rT5OcV1y7ud5fiL6Ma/HfNFT5scpmBufGX4qajwvPtfU/rfUdVyS301C5s8TcqK3
oNvq5bO6SalzR3V1fLTNjM88NWIeTOgAHNN8kduSXt3lXe0Z+S4sPyztnvd1DjEznqOv6DW1GNcQ
j7sxmWOekB7N8TiLV3Pj4/y/k7PVgvKE7lEb1wvDZ/GWz33/iFseFlenilw1cSnSGNdRPhXwDYLC
ed3Su2b/BpFvYbdcNfHeNVXI1K5c84XE63vGyKsVvEq0wlwxe81LzqTheB+uFfPpT+Njk8f99/Cy
Ni51uiRgjRilVm9pOKu3NIveUi3whpN6R0JvaxDpDcn+eS4vquP8aBC1tTh+Jk8au0koy97pHR/r
Vgk34rfx/zlvWHwdtjfZeL7/Um3uqjzWeIwePZYS7PHmH/C26KaU0KKb0sI3bL2B/v51jFhwPd5m
NeFtZiPeZsxOCV05u3J24+yW2dKSGdEZ7TPYjNktc9Ob5/sDPaZNx1tdA95q6/2hrNqW+rX199Uf
qj9arxTWV9Y31T9X314vP1cXbWhvYLX1y+ekp81LuXFYWvZCvCh97Xcs8nw7i7QvZxFzn2orXfsh
7PzwuQ/puheg6b2d79F3nmORvZ3t7MvH7PbSNvbZY60s0sb+Jn462x+PpmaUclfSlJ0YiO6kkZ3L
U7M2b1EiW1rlyIY7eFKG3j93/R1y5I475cidrUpkUyuNNLa2tK5tZTtbgeP+Dwv3383Cv0oR8y++
lNLnnqWR3+C181lo33V4F92FWHcuh8jPlyuRNXitXK1EVuMvJ2FJJCJI6L8kK1y6pIVGbrmZRm5u
USKL8WpBoNvwWoHXMryW4jVuOaxbLgr+1HzEZisNlQRSiwOBQQHvwIC7KOAcENAuDij/X1vXrtMw
DEXtpEALSVwCEYUopWpQqeoKEEggoSuBUjplSUuHmEo8JHaGsMOClIXHH/QXbrYwsbLxCXwCnwA2
dOBl6fr6nHuPLd3Vrw1HX3fImtNYtZqrrMWtNmd131rxWXXZqi0zVp41StMzhrrUrxcmDEI1ddqB
35MR0dQT+xf6SH/RJ/bYCbtiI/bEXtkbe2fFEmO06FLPrEwtmU55wbQL82YbWtCEBqxAHWpQBRcq
4IANDEowCToQiLYo2iEJBwHOUekPA9ziYa7X+rjJQ5yKhnFG6Z2QLGppTskAC2muSWd3joZxThdV
+MZ9JJQSDE9vbkWmkQBpiv5hrNx+L8ZampfJIM40GgghcCeMYpUluIfn6svZa0/gpho8eIKEuNtD
1w/4f+04OU6S5DuTNRtdbHXPsN09PfiRS5PLP/rLLy35HaJcTvvJdWJXKOMcK+jLgkjRWDVe+LNP
spIqUNQPQiz2pUVDXPIleJZgWwLDV5slH75TIDAKZW5kc3RyZWFtCmVuZG9iagoKMjQgMCBvYmoK
MTkxOTMKZW5kb2JqCgoyNSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0JB
QUFBQStBbGJhbnlBTVQKL0ZsYWdzIDQKL0ZvbnRCQm94Wy0yMjIgLTMwNiAxMDcyIDEwMzddL0l0
YWxpY0FuZ2xlIDAKL0FzY2VudCA5MDUKL0Rlc2NlbnQgLTIxMQovQ2FwSGVpZ2h0IDEwMzcKL1N0
ZW1WIDgwCi9Gb250RmlsZTIgMjMgMCBSPj4KZW5kb2JqCgoyNiAwIG9iago8PC9MZW5ndGggNTE1
L0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nF2Uy46bQBBF93wFy8liBP0APJKF5LHHkhd5
KJ58AIa2B2kMCOOF/z5961YSKQtbh6b69qHpItsedoehX7If89gew5Ke+6Gbw228z21IT+HSD4mx
ade3i17Jf3ttpiSLc4+P2xKuh+E8rtdJ9jPeuy3zI33adOMpfEmy73MX5n64pE+/tsd4fbxP02e4
hmFJ86Su0y6cY87XZvrWXEMms54PXbzdL4/nOOVfwftjCqmVa0OVduzCbWraMDfDJSTrPK/T9X5f
J2Ho/rtXrjjldG4/mjmWmlia587Uka2wfwE7cgH2woUHFxwvwaWw3YEr5lTgFdmCX1iTgzfClYy/
Cpey7pYs+TuyrPvG+hV4T0aNyZnvwOqPfEP/cgOmf4UcQ/9yC6a/Q6ahfwEfQ/9CMulfCtO/knz6
e3Ggv4e/UX/siVF/yae/lXXVH5mW/iX22dLfyzj9C6xl6V++gdV/D6a/Faa/R76lfyWZ6o/3YtUf
bpb+Dv6W/k7G1R/vztLfwt+qv2SqP2qc+mPfHP2tjNPfYf+dnh84OPV/Bev5kbnwt7mBv6vIUq/n
B8/o9PzA2dG/gI/T/Zca+hd4147+hYzT38u69Pd4Lk9/D2dP/0JY/ZHj6W/xfr2efyMNpZ2D1kLv
/2nZtL3Pc2xX+UBIn6JD+yH8/YZM44RZ8vsNeOQKfAplbmRzdHJlYW0KZW5kb2JqCgoyNyAwIG9i
ago8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9CYXNlRm9udC9CQUFBQUErQWxiYW55QU1U
Ci9GaXJzdENoYXIgMAovTGFzdENoYXIgNjgKL1dpZHRoc1s3NTAgNTU2IDI3NyA2NjYgNjEwIDYx
MCAzMzMgNTU2IDU1NiAyNzcgMzMzIDU1NiA1NTYgNTU2IDUwMCAyNzcKNTU2IDU1NiAyMjIgNTU2
IDIyMiA1NTYgNzIyIDY2NiA1MDAgNTU2IDcyMiA2NjYgMjc3IDU1NiAyNzcgNTAwCjIyMiA3MjIg
NjY2IDU1NiA1NTYgMjc3IDU1NiA1MDAgODMzIDUwMCA1NTYgNTU2IDU1NiAzMzMgMzMzIDcyMgo1
NTYgMTkwIDI3NyA4MzMgNTAwIDY2NiAzMzMgMzMzIDU1NiA1NTYgNjY2IDc3NyA3MjIgNTU2IDY2
NiA3MjIKNzc3IDk0MyA1NTYgMjc3IDc3NyBdCi9Gb250RGVzY3JpcHRvciAyNSAwIFIKL1RvVW5p
Y29kZSAyNiAwIFIKPj4KZW5kb2JqCgoyOCAwIG9iago8PC9GMSAyNyAwIFIvRjIgMjIgMCBSCj4+
CmVuZG9iagoKMjkgMCBvYmoKPDwvRm9udCAyOCAwIFIKL1hPYmplY3Q8PC9JbTQgNCAwIFI+Pgov
UHJvY1NldFsvUERGL1RleHQvSW1hZ2VDL0ltYWdlSS9JbWFnZUJdCj4+CmVuZG9iagoKMSAwIG9i
ago8PC9UeXBlL1BhZ2UvUGFyZW50IDE3IDAgUi9SZXNvdXJjZXMgMjkgMCBSL01lZGlhQm94WzAg
MCA3MjAgNTQwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9D
b250ZW50cyAyIDAgUj4+CmVuZG9iagoKNSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDE3IDAg
Ui9SZXNvdXJjZXMgMjkgMCBSL01lZGlhQm94WzAgMCA3MjAgNTQwXS9Hcm91cDw8L1MvVHJhbnNw
YXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyA2IDAgUj4+CmVuZG9iagoKOCAw
IG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDE3IDAgUi9SZXNvdXJjZXMgMjkgMCBSL01lZGlhQm94
WzAgMCA3MjAgNTQwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+
Pi9Db250ZW50cyA5IDAgUj4+CmVuZG9iagoKMTEgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAx
NyAwIFIvUmVzb3VyY2VzIDI5IDAgUi9NZWRpYUJveFswIDAgNzIwIDU0MF0vR3JvdXA8PC9TL1Ry
YW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMTIgMCBSPj4KZW5kb2Jq
CgoxNCAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDE3IDAgUi9SZXNvdXJjZXMgMjkgMCBSL01l
ZGlhQm94WzAgMCA3MjAgNTQwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9J
IHRydWU+Pi9Db250ZW50cyAxNSAwIFI+PgplbmRvYmoKCjMwIDAgb2JqCjw8L0NvdW50IDUvRmly
c3QgMzEgMCBSL0xhc3QgMzUgMCBSCj4+CmVuZG9iagoKMzEgMCBvYmoKPDwvQ291bnQgMC9UaXRs
ZTxGRUZGMDA2NTAwNjQwMDc1MDA3MjAwNkYwMDYxMDA2RDAwMjAwMDUzMDA3NDAwNjEwMDcyMDA3
NDAwNzMwMDY1MDA2OTAwNzQwMDY1PgovRGVzdFsxIDAgUi9YWVogMCA1NDAgMF0vUGFyZW50IDMw
IDAgUi9OZXh0IDMyIDAgUj4+CmVuZG9iagoKMzIgMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZG
MDA1NzAwNjkwMDZDMDA2QzAwNkIwMDZGMDA2RDAwNkQwMDY1MDA2RT4KL0Rlc3RbNSAwIFIvWFla
IDAgNTQwIDBdL1BhcmVudCAzMCAwIFIvUHJldiAzMSAwIFIvTmV4dCAzMyAwIFI+PgplbmRvYmoK
CjMzIDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTQwMDY1MDA2OTAwNkMwMDZFMDA2NTAw
NjgwMDZEMDA2NTAwNzI+Ci9EZXN0WzggMCBSL1hZWiAwIDU0MCAwXS9QYXJlbnQgMzAgMCBSL1By
ZXYgMzIgMCBSL05leHQgMzQgMCBSPj4KZW5kb2JqCgozNCAwIG9iago8PC9Db3VudCAwL1RpdGxl
PEZFRkYwMDQyMDA2NTAwNzIwMDY1MDA2MzAwNjgwMDc0MDA2OTAwNjcwMDc0MDA2NTAwMjAwMDQ5
MDA2RTAwNzMwMDc0MDA2OTAwNzQwMDc1MDA3NDAwNjkwMDZGMDA2RTAwNjUwMDZFPgovRGVzdFsx
MSAwIFIvWFlaIDAgNTQwIDBdL1BhcmVudCAzMCAwIFIvUHJldiAzMyAwIFIvTmV4dCAzNSAwIFI+
PgplbmRvYmoKCjM1IDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNDUwMDZFMDA2NDAwNjU+
Ci9EZXN0WzE0IDAgUi9YWVogMCA1NDAgMF0vUGFyZW50IDMwIDAgUi9QcmV2IDM0IDAgUj4+CmVu
ZG9iagoKMTcgMCBvYmoKPDwvVHlwZS9QYWdlcwovUmVzb3VyY2VzIDI5IDAgUgovTWVkaWFCb3hb
IDAgMCA1OTUgODQyIF0KL0tpZHNbIDEgMCBSIDUgMCBSIDggMCBSIDExIDAgUiAxNCAwIFIgXQov
Q291bnQgNT4+CmVuZG9iagoKMzYgMCBvYmoKPDwvVHlwZS9DYXRhbG9nL1BhZ2VzIDE3IDAgUgov
T3BlbkFjdGlvblsxIDAgUiAvWFlaIG51bGwgbnVsbCAwXQovT3V0bGluZXMgMzAgMCBSCj4+CmVu
ZG9iagoKMzcgMCBvYmoKPDwvQ3JlYXRvcjxGRUZGMDA0OTAwNkQwMDcwMDA3MjAwNjUwMDczMDA3
Mz4KL1Byb2R1Y2VyPEZFRkYwMDRGMDA3MDAwNjUwMDZFMDA0RjAwNjYwMDY2MDA2OTAwNjMwMDY1
MDAyRTAwNkYwMDcyMDA2NzAwMjAwMDMyMDAyRTAwMzQ+Ci9DcmVhdGlvbkRhdGUoRDoyMDA4MDcz
MDEzMjkyMCswMicwMCcpPj4KZW5kb2JqCgp4cmVmCjAgMzgKMDAwMDAwMDAwMCA2NTUzNSBmIAow
MDAwMDMzNzM4IDAwMDAwIG4gCjAwMDAwMDAwMTkgMDAwMDAgbiAKMDAwMDAwMDQ3NSAwMDAwMCBu
IAowMDAwMDAwNDk1IDAwMDAwIG4gCjAwMDAwMzM4ODIgMDAwMDAgbiAKMDAwMDAwODg1NiAwMDAw
MCBuIAowMDAwMDA5NjEyIDAwMDAwIG4gCjAwMDAwMzQwMjYgMDAwMDAgbiAKMDAwMDAwOTYzMiAw
MDAwMCBuIAowMDAwMDEwNjAzIDAwMDAwIG4gCjAwMDAwMzQxNzAgMDAwMDAgbiAKMDAwMDAxMDYy
NCAwMDAwMCBuIAowMDAwMDExMzI5IDAwMDAwIG4gCjAwMDAwMzQzMTYgMDAwMDAgbiAKMDAwMDAx
MTM1MCAwMDAwMCBuIAowMDAwMDExNzE2IDAwMDAwIG4gCjAwMDAwMzUyODkgMDAwMDAgbiAKMDAw
MDAxMTczNyAwMDAwMCBuIAowMDAwMDEyNDEwIDAwMDAwIG4gCjAwMDAwMTI0MzEgMDAwMDAgbiAK
MDAwMDAxMjYyMiAwMDAwMCBuIAowMDAwMDEyOTIyIDAwMDAwIG4gCjAwMDAwMTMwODcgMDAwMDAg
biAKMDAwMDAzMjM2NyAwMDAwMCBuIAowMDAwMDMyMzkwIDAwMDAwIG4gCjAwMDAwMzI1ODIgMDAw
MDAgbiAKMDAwMDAzMzE2NyAwMDAwMCBuIAowMDAwMDMzNTk2IDAwMDAwIG4gCjAwMDAwMzM2Mzkg
MDAwMDAgbiAKMDAwMDAzNDQ2MiAwMDAwMCBuIAowMDAwMDM0NTE4IDAwMDAwIG4gCjAwMDAwMzQ2
ODMgMDAwMDAgbiAKMDAwMDAzNDgyOCAwMDAwMCBuIAowMDAwMDM0OTczIDAwMDAwIG4gCjAwMDAw
MzUxNzkgMDAwMDAgbiAKMDAwMDAzNTQxNSAwMDAwMCBuIAowMDAwMDM1NTE3IDAwMDAwIG4gCnRy
YWlsZXIKPDwvU2l6ZSAzOC9Sb290IDM2IDAgUgovSW5mbyAzNyAwIFIKL0lEIFsgPDQ1ODI4NkRC
NDczQUNDNjQ0RkQyRjEwMTZFOURBRjkwPgo8NDU4Mjg2REI0NzNBQ0M2NDRGRDJGMTAxNkU5REFG
OTA+IF0KL0RvY0NoZWNrc3VtIC9CNDQ5N0YzMzU3NTUzNzQzNzUyQjBFMDFBQTYyMDExMQo+Pgpz
dGFydHhyZWYKMzU3MDgKJSVFT0YK

--=_43n2rxr3njeo--


--
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, 30 Jul 2008 11:32:16 +0000
Message-ID: <[e-mail]>
Date: Wed, 30 Jul 2008 13:30:43 +0200
From: [e-mail]
To: [e-mail]
Subject: RadSec slides
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_4ee9yxyk2800"
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)

This message is in MIME format.

--=_4ee9yxyk2800
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Hi,

we had some problems shipping the slides, so they are now attached to  
this mail.

Have fun,

Stefan

--=_4ee9yxyk2800
Content-Type: application/pdf;
	name="ietf-72-radext-radsec.pdf"
Content-Disposition: attachment;
	filename="ietf-72-radext-radsec.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nIVSS2scMQy++1foHBiv5LdhMDT7KA30kGYgh9BTk7Qsuy3dS/5+P3lm
twmUZow/yxrp08tshV7Mb2IaGGJ2ijEonp7o/op+GiFdp+/GJ4bd0SgesGGGEy6vJD1nuwP9MM9X
nVoX/K8nkzlZT8k6mh5ptQMxpOeRpU17s53MrWFbiG2s+OD15SMIxAa9veB+g72nbFMSV+mzkYBE
Qw7IqovRRSBS4Wjr5XYH3v/TVERF6RE8s2u/zJ5vM0IdoIpFlViVbUb5WdNwHvjtaFafjoE2v0iD
opFc1d+nklw/OZelG9GpWxHg0g6v7XgY2bVBRvYc2pBGjm3wI6c2xJFzl0vH2tzIH7rpNa9505Xb
jrv2dbqZO/pOEr4P+59ZVKUWbn4UWQKqwqksvmOYdVxmiwXjm+iv5u+YMXsXig3nYKH0YJKaltEG
lLRGXZI770YVUriKl16u/lvMdm0IanGJdXmpMWVypWCaQUKXDqSS7vmd/pXmv2eP5dXe0h8om6TM
CmVuZHN0cmVhbQplbmRvYmoKCjMgMCBvYmoKMzg1CmVuZG9iagoKNCAwIG9iago8PC9UeXBlL1hP
YmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAyNDAgL0hlaWdodCAxMzYgL0JpdHNQZXJDb21wb25l
bnQgOCAvQ29sb3JTcGFjZS9EZXZpY2VSR0IvRmlsdGVyL0RDVERlY29kZS9MZW5ndGggODIwMj4+
CnN0cmVhbQr/2P/gABBKRklGAAEBAAABAAEAAP/bAEMAAwICAwICAwMDAwQDAwQFCAUFBAQFCgcH
BggMCgwMCwoLCw0OEhANDhEOCwsQFhARExQVFRUMDxcYFhQYEhQVFP/bAEMBAwQEBQQFCQUFCRQN
Cw0UFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFP/CABEI
AIgA8AMBIgACEQEDEQH/xAAcAAACAwEBAQEAAAAAAAAAAAADBAIFBgABBwj/xAAZAQADAQEBAAAA
AAAAAAAAAAAAAQIDBAX/2gAMAwEAAhADEAAAAfikpeeh4/E8ecQTOyKvg0NUpM0SoRIIIwlCaH4c
o0IWxRUcrBdUKLJAQ8sggnNiCYCSkC7MjA5xWtuWMYOkxiczhUFhEKry0gVVxtJp1MrCYVblgAXi
oFyowiCNmArkVPLgbaRnZLIaXnOoQ58k3de2L23DST1pUsiTYup4Xvock/m/u1paijTvLJmXNKhK
LVTFHQIRQrUHThOkfYRTmVaYjFSiF4JCVQw+qIWp0uaPrw7i9xOvyvQ6OH1Dm9Khessnl2lqRCqM
r8k+vW+3F+cF3xdfn1IbJNaJgdhOlfzYloqCwCqT8ZDNcI0Rh73yaLd5+yqNLYis9vPlpqzSyvsW
sym14Pfz9ynTzposS1rGfIkt7jax+VUH1nE9nj5BfbY3SKyGwxs7Snoc0mEGux5fi+ryc6Q90NIC
UWQzQ3VHB6Z6oPv595cUFu8fqv3X8i/ZuL1/qibUsPRzdFsviLzjsUn9eJf4v9SoNOej+a6bNb8/
0D5a2yaGoNmy8/Pl2irY6foPyqz8m/oPzd6bilBYoLSDabidm+1Lfh9sUzvLTEpLGUZxOWXTX7bK
lc72nzbJLSyVdebNIUFzTBfRW7z+egKyrhQWjrVDIdyIBHC9ZaCnWlM7KNrmxy1xryaBqnsa5xes
pA4WvgDIowBhqp8T0NPEwqpdmtNZzS8m3K5uTdZ6RONjQCQfns105CAObcPVtJzse68nLfu05rJr
urCsB3DmDuVLS7i5z7iV63unRfzuW3jHcgiXc5VH3TtL3uTgv3Jjb7pv/8QAKxAAAQQCAgIBAwQC
AwAAAAAAAQACAwQREgUTBiEQFCIxIyQyNCBBBxUz/9oACAEBAAEFAvloLj/5hwQjTnLC0WoC9fBR
wtP8WjKcF+Pn+a/CLcrCrj9xj0mtyfUTfyhHqHgldayvyiiFhapoKZDl/Ts5lJwEzAm6Bb6nf3nK
/TXU0rqc1EbCP0Xs0NX+wW4WuUGiNMDd2x6DUvJaGhrR29ZWi611rqXUtUK5kREQbFK6QviJd0MC
6o1qCeslSRELXCEhaq+kjpISxznlxr/2dEI+tv8AIsZoA0vOMLRaLqRiXUVphFuVHEXHRkakeSnv
bs6VxQU3o/6b7DfREz1sx6MBCgOCHnPU2RRxfrxRJzNzHWwutzj1YQhXSutdRQiTwiwktgUjhEx1
lH2iij6J9oLZA/GclshYmazBw0TpFSm2suLCoIA5CsJGClq1vHbJnFl6HCko8IVLxEjFLXMaEOTJ
QEEU1n28lxKPwVj0PwfnK/C2TJy0MmwWxtcK7cWozhRSMEdXBMbd1DXVPj32jDwcLB/1dbFnhhiP
i4oR5F5RTiimsvnTwuoYc0ZLQiwJzML/AGxo7HM+7Hz+f8GvLTD90zB1iN2DFNquOl2NGv8AWTRR
NhY97Y22vKuPruPIc5ySm8YsSwVeBntO8j5Ph+Dpx/xewJ8aIRCwizKI9key1ELCCcP8Krj3ZyYT
iOFhLaT9D4yzaGWF0iPA0nuhgjrtnsxVWWfMqofc5fkrUlfwaDk4+S4z6C0QYwU9uUfXxlGPcyM1
KIRCwiPXzVP62kDZBHVAoXoq0cXKw48UtNs0FNJbUlDkrRj8RobwVoareUhoR3eU8gnsxt4Sw4Sw
MeJfHZ+o+k3x2zM2Ruro/Grj62yt+O2qjNlN43yMV7fKq8Jcu8ePaI+af9poOThRKH8eH8m2nf8A
iWz1KS9yD1cr8m6DjuLEzhRjZHa5Z1YdEjFa8nru49jg5VfL4ePgdmxY+sMfBiL1znlNTmKwzit/
yDNV5eJuVW80PGNldG6y/wCagP1LJnFRuUbtTA/44Dy5rogQ4K7fr8dDy3Oyc/YoubCySz6mlZIb
MTVeqgot1MmCowFAWqejHILNXDzAV9PldRah7XSCpY8EtWqqH9zGPtYmJjlC7ZTRh4r3L/HqXyTm
yP17k1HWJptgCa65OtOKdcIEz+xSRKVqZJgtlTbZzYm3d2hNkCGpDoQtFI3KezCKrH9ya5DWsWmE
PSik1QlytkfwHhqFnCFkgl2zXFSPRl1T5MqROYgS1duFvlH2iE2UtQnXcFuiiAoIx9QyfYRuCaAu
sPRaWISIPXanPQk97+4rGpkOwkynIyYXYs5Thhrh8bfBHxthbrtXYq5/csdhsOxjjk2QcWu/mnNI
QdhB/wBz/YaDrlbYUcxaiewSBPX4XZhb7Is3MkZYXLK2+Ho/NU/uWn7Y3fayTCjlwmS4Thu1zCPj
b052q7EJMrZbJ5ynrK/Ca722VH7k5iI+OzVbZTmot+Kn9r//xAAkEQACAQMEAgIDAAAAAAAAAAAA
ARECAxIQICExE0EEUSIyQv/aAAgBAwEBPwEbJgnZJmkTJJJK0kkmCSTIzMjKRUikg5Rl9nTFUiTk
hmFQ5QhKSlRtgxaOGMofotWsuWY0odK7SLtp3PymCYExMkT2NDFH2Wv0WnI0v6LtGD4IaIfsdLRD
XZDWxrT4t1NYvSpwTJdqzUDrdShjuPGDys8mXY7kjuemJ6OqRicC+RUjzN9mcmT0RjIqR0fRDKXB
kVUbY0RAuDvWCCoqWyNKdGhCIE9P/8QAIBEAAgICAgIDAAAAAAAAAAAAAAECERAgEiEwMQNBcf/a
AAgBAgEBPwHeiisUVitaKK2rDWLRyRzQmn4LLzJEpHZZCSj1rWixKyXvP4Rnfsuzossvb5I/eFiH
Qkl6FFJlJHGhRoUR6NHBHA40JZssvLQn5bLELZ+D/8QAPBAAAQMBBQQHBgQFBQAAAAAAAQACAxEE
EBIhMRMgQVEiMFJhcoGRBSMyQnGhFCSx4TNAYoLRNEOTosH/2gAIAQEABj8C3KDW6pWWm5+y1+y+
UrMUWWfVd91RdF4hud91Xel2ay3ua7Kp91iOfcuytCVkwLNrfRfA1Ztp9F0X+RWird3KLxC/XNHH
0sjpz4Kp1u5lNx5trn1GWTRqSqCjiiHVpyCOjfqVnIPILKT7L41kQfosxdktKORIVCo/ELqnW7Ef
K6g9eoyWfSPJe8OED5f2XRHmV8S793X1WYwlVGYXJZrkVEeIcFiN2I3UHndnvVOQ5rsD7o4RTv47
ld/VcjcCowe0FRtfO4moFPl5r63G/RZi7G/XlyXR15r67p6iizzCNCovEFSqw1OOoWei53UY3o8X
FdMl59FTZ08yiYsz2XLbW6KzRRjg8YijZ7FZ2Z/Pgp6Krzc7Ec+F2m4MXw8UaadTGa/MFXjwuoqF
NjGnHuCDGCjQi5xDWjUlYI5Da5exZxiVLLYm2GM/7loPS9P2T5J7W60WnUDh9EDDZYGjjLOyo+6N
ndZrNaLYW4dmyJuvM8v5KHxAXOFBqDXii+hLW6nkgaZKSX+1fxnx+CixSxm0O5zvL/1WGKNsbeTB
RY5pGRN5vNFs7HHJbpeUYyRhlcLB/SK1/wAoyC2DvIjOvmpYWvErWGmMcU8UGYpvNpxVOpZ4gmgT
OLOLsGn3Q/Mv/wCL90WOi2meq/0wUlBhpJp5C73MEf1lkp+gK957RbZ2dmzRf+lbSfa2yTtWiQlY
YYmRN5MbRG0WycaACEarYWFn4aDSo+I/4UbfdY5G4msMrQ4+Sqo5dpZ42yDE0SztYSPMohQuxWaP
bjExstoY1zuGhKLTqDRfiBJY9jWmM2uOgPLVUVZpLLEcGPA+0sD6a6VustkdZ8MtqFYanou87rRb
oYMVmg+N1d2LxBZgoEODq8BwvNneaMnFAT2uF9BHJIeTWqkHs6n9U8rR+lU+a3e0WWSBozZZG5n+
4ovNTXi7MrRNoyrRHs8qYh3go6071DYrRZ7SWsZgdspQ0O/6ruVkYYLU7YgDC2cYHerVJJhw43F2
HkprBsjWSds2OvIEXNinstqq1gwhs4wBwFAaYbtu6z7exdAizSGuBzWBuJp4HL73WGGzez4DZrO3
C4SVLn1+PPvUjoWmOEuJaxxrhHLci8QRq6t1Lu9Mg9ou2UmjZzo/68lUGoPEXGW0ytiYOLk1sbTH
ZGHIHV3eVTS7NGiJ3KOCqzI7ud2l8XiCO7RflbVLGOTXZeip+OeB3ALaWmV8z+1I6qyWt2ea1uru
ao116mLxBfCR5dTkVqsQ0/ko/EEN+m53Krd7v6uLxBBGT5AcNbiOOlx3C/5QaHcJpoKm/VZXBo1R
ByI6mLxjcpdktFosz1Nesh8YX//EACYQAQACAgIBBAMAAwEAAAAAAAEAESExQVFhEHGBoZGx8MHR
4fH/2gAIAQEAAT8hDiBXpSAjWwhFzMOkjuMIE8QbueF8sfI+IU6TZ4+mC1I5beDxElehmWIo1LgL
l04xP47gr8wD+Y9Nf9WZyXnr0WomgbzKh8w6hnMwzhGmBUR2g9BvGE4qnTKarja4zNQsOBcDlrvy
/U7T8tQOG+9szhkDi8EzaR+Ue+QW24dktgZN1A9niMClLUQ/1ZnauZKNy1AOVLMSIo+B/aoWLxwT
yDFFV2S+hoU7PSv/ABGnNPmX6h2gNBcM8EzB9giWGF5qWHCacEu+rwTif3GUO2eH/JUrfk0wVHmo
JdkcLY6ZZ2aIKdF3XU7E/UCDWf8ANLLO4nEzYw6XPCWHazB+XtLJnUehUXtnggntA64fpnGx4mOp
tnx9fL/qMlet0giy3/NTDXxwYKiHBAa9y3K5bRE7IZNjqFdeQI40eKWdNqlyK4N6IeFsvzDMOCNd
WOpXpxwdxuqu+oo7O0YyktuLGiorMuSEFBM4ioe/ufaAL9nagFP2T5hVmXqoEzC0Nbi2dMrnkjXU
HmLVJKb4rj4Szsp6nwjmVUc7qYKdj7w8xzwil6JlSoC3bqVLVvDojBQMcTXAovPMKtRYg1OapD6Q
fMYirXjuAqej17v9R8sBp8e3Udq32YqjSXLRT+aC34zMok1CW1LTV1TGSIWwsjVBrm94iTdUxxNM
D2Ezf+JR2PdB8l5Z3amPI40CAe/5pKKP4vMc3938wijrb94yp+LnYniKn6TeXo4Jc4zMuwDE7s38
XOCv0JmrImWyBXhKqkTSNhzCNsOLjKelUiRKgM3Broh3zJ9yyWXCh5i0vrfvKeFjaWV+RgeSUBMh
NF0EQ8SX786+5/YSDp+UNvT9iL/5LNyP0Na/glLLoyqfD5rf7gHLdRFy3JmcFS2LHU3TD67ZNem5
TCZokLJthM//AGR19GiXjTkzBLwPWfog2ZBXhOv0yxtlEKjyoX4t/ZNGDof5DAZ9/wAW0PxPDxqP
qeKk0fcsk+kn5Vf4GFyEFMAdWl/pF7laVfYTCsmNEMRtxLrI4/EGJT6YLRYWZQtqEXtGI+SX69df
FRPRnxv9y5JbKvw2glszAjt73oxKhBrWv9RmNMI9BWPeL6WPyTqgGq/nWF974/VTxkAD6lmsomVe
DL9R7i2Hg+IX7RChTFJuILFTxl+KF0EskzTWMkC7BGoqEuZSYOClTeZojTAQWJ1fE/1YlEVGdgpz
2nErUVmJQUpeNfc4guEWxxcV3RtoRa0SoxM7ElT+F3MELNZJhZjbZ8XH6itnxysm2gB/lafj0WiE
vIr/AG0fcYs34afDUuIifPAZB4iNXLUs93mUYyDcwB1pOFXhr2bnuA14Qexiy1dor9xJTC0MSCMY
pbyIg9DAJooHZuo2CANRhK+Yge6hxIpvktfi/SNBscTkPzP5cU7j4C2Lb6IHvGqJep2Qtwnmu4Ld
xvv05HX+aAWBvL/dxMS2teNwShxcLQpackNkHG1fZ51DZjWJY+nIV434Dl8Es3U3j+MQjsgDqvYY
pKZxCFB6AaY1MAYXUWUE8kOaCExydwGp2bnEITDaI8bmwgY0mLv/AN43uNQtRVKghVzU6GIycjf+
Smcs6b+QgC7uD+4qtLljDnFnD5gmho7jucPAVeZkX9Qi4a1iVMzAMHyHHiWCDZmXNxZUSYhSe8I+
gzGU/wAWZZkl7YxweRBpHit48wFSiHEylzCxRg8tw7jLcpz3LtQVl+J8OUZfqOW8Sy+5izklIYcT
FXMcxRDpjGMltr/2matruNc5udSV4z2EccYiOYYQg5jHixYm49lvcgO+HgjHLFXps4QOzlFpeWXX
pW/QyRojhPckz5l/82Y3fq5hXBVtKKfpnAzzGxo2zcSqxTDWZTzuJ8mLJFMMBOluv0wLuLW4rY46
lPULjrIftJ0owKt4nlBdFFvUU5aaPeE1YpJ1gyEGYLWNIt7l+Y/9u49cynwfMTRiJVNNYYSILNCs
5ibtFfCDUB8Sh7x8oeDCjNcfJDG6ZkxruXT6SjbUzZiB6TGJk0ywziBi3MoiVP5Pc//aAAwDAQAC
AAMAAAAQoNmzct7SBNqhDDjNESvhv7iZzHA3PHmtwuXhtrN0qpyEjp4ITwfEUZc1HkMU2Ngn5a2E
4i1K9z8H/wB3Eh4YqLDPk4maAvfxvSC0jzlMLINKPCGUo/B/AvUutg/PHfHXQwX3PPYoP//EAB4R
AQEBAQEBAQEBAQEAAAAAAAEAESExQWFREJGx/9oACAEDAQE/ENsOHsDt9gPW2IyQWDrGWhaHcj82
0v2NGk5n0Z/6jMXiXm7a8SJDxto7sicgPBdRPIDkvdtfYf5fjD2JPyT3B4iLJNu7Y55AGfyG9gWH
/BZ8wtfR/wCXVYH5HhafZSA/4jtuW8vJL+CIdcROVw8Lr8tDrSVUcuFTIIEZYbl8CPQSpikMvJp4
38Tf4A6z7by7L5AvUlhfLQB+WSPqx4sqQST+QdWGXzBZPqSxyYN3ZCYz8ojjadVj7JAPpZeSIx32
yD/GOxG/MvqMmZHXIN+YEUkOwdsZIXFkDcuF4sZs18v/xAAeEQEBAQACAwEBAQAAAAAAAAABABEh
MRBBUSBxYf/aAAgBAgEBPxCC7s+WTxNyttwcsOpmiD1MC7sk38DMlnO7d9WjcOrhJEuLCQ8PSSh3
bkuz5G4WWVPCHNhaoXS3CjVs0kssmZJ4Xq0kuMu277uIWZcgOjanBgPUB6bD1GPUkQ7PJOOPA2y5
duc9pQls/sdZCtIR0gjf2DItZZser7QsGcT9PBn+rSTZfwZ4cY4m37PMuW7PE+Qv22G7m3nJL3f/
xAAmEAEAAgICAgEEAwEBAAAAAAABABEhMUFRYXGBkaGxwdHw8eEQ/9oACAEBAAE/EKzDPcTpD1cN
TF+RMxIpb5glpHh5l4dXXMQoS9BNywbAuv1EmRvs+x/MrMB8v5Zw83Y/7KNCL4BfqCXg7J9H+Zgs
PMyfG4mcRb/2A3qBpCQq4gRklhVfP/gFclHPM2vBz4/1AaNDZKG0fKeYK6qMj6vrKC0ECmzNv4+s
BdQFYsUFbu8QOQq7gDMFwstq4OI02165lBpv7/cxS7vuFRUS8GZiNV8RbcZlB6msiWaZUX8MQqXs
FML5gGyS5xrmZQ6m745e2MrVug/a48TObh+YsKyzbVeFwyrT2m/8yuq8Cn6xwgGskwhf7EGIKcJz
crwHlfxClBvf68QFVMBsb2XCsLbQQZeCwtD33AYVq3IlvQ16J34DtQtUX4YKYHhg9RuIu2m3IPGJ
fkDz2fG4i0i10rPrM8R0WH8SnKk7NfWKhoRTkqvEXDXM9wGt7lxBnIJQ+u3XiYKAFBL6PW4iMi1l
fTcsCp1+ilk6dmVQAbU0LAOcxjSZmHdv2i1ujrqDzqW8p/yOlG0LC49Eag39HMBqAMUYUV6w6+MA
K+kKo6FEfYLAVlFr+WYE7y6P0SlJY/0dEEXCnJv1FFq4W5WMyrWrYiqX7TMpAXwTH0ZegNSb+pBT
Q3vp6hRvrDi4gVX4Wm8UZfX1Qv0Vn2DXzVxcujZ+Bg+bldQoCRS8GLJmARp78S5miWJOaXM7SiJ3
BMiQyRxZBPcNXj0sXlWR3+kJ4YTbTKJA2HXiotXsDuEqizHOMNeQB3HKwagEbXYbTLVKgEo9lp5e
jxBLD0H5Y1c6FB1G5SK0E7CvMQGTzWZR89oZ+ZgTHEPirQZpwOa+kEiNji/Jjfmjq5afjQG/Zw+K
+YmVnedvuJPQ8cxkyQ5j1ejx4g0S8trz1CFNhwwG5B4lz8ICzM5XiNQUfEClpq5iNB7VukdLY8HB
AWXkWaYYGlboSu4mtjOAr42wBgGVeoOiNxqtkBVFZtNm4wZQnagzrm/sxAuxS539sfeHMxJXsFHn
N8GH0mEDKBrKZ84mP5BwVMoFax/eoxK+BDIsIBaupWP3TXi7u8c7vkjyjoEsHTQP1xqKTWQlt/7E
WHDNbHHzGmjnuEDeGn7/AF9IIKzg/f6gVco7g8JcU87uG+KdVLhtb7jw34Cf256yL2n8wl1VC0L0
eZQAy6JWMU8nCCsOVvFXXm3qM7QABbC9exxPcThhuwW8HzFUosCG/wCk0NDbJv8AtyiZpg/FfLzR
Hjq76EM/eFuhwjJ9YEiWbA9Q1XyfMA/DQj11cYCclEIicGoG8AGyZd700zZb6LOA4l+ZbSX3D4Rv
OPDL7CHSILeXMUXoeZsnsyQanZiUInRuKBNGtLSO2rhYlQeCl4vzUIc/7K+MQK1ELfWIK+YHa4zI
1BRVbKUMY8U8qqM1XFUxWs0kQhbw+Y63lf18Q0vIv7i6Wl4P8Dyk/YWcT2vcNfdBP2rgJygavrGS
9EkAI6bF+mGtzFpS1DtCvPFA1iPhaWEG6fJ6L5Ieg5FYlQORBfYrGAJsrJitr4dxaLasjiV2qJsq
WsfeWYwmcPgj2a3TGs1d017/APAIXvqCcCFRn1KA8Mt7fmDLUDxSg3VwOSu5qHAHUVV0uCBOAs05
8UAlnU3FF4XB3TFcLXOLKU+LPqSmTwaAF8/YgqLcUtnldfkT4iM2sDnr1UAn+M/LAREd4b76tBcC
3yL/AJstZ8LzA/lYSGmspzXw4ilGoAoKWl3usyz6VGB1vI2Jbkcu5VAJ2lbq4dL6U5lW1Q7zwtRU
HjFwxKYNNfMq6W5dCtRpYzouyxTD8QoVIxb+I402c6i1iPWazFmEhJepaVoTmAd0gI+P8wNxVvBn
Bd9xuUANvuY/vuXh/JpgBYj04vljlMHhLeaMYOtwAsUHHyfEWhavwS55Ux3eT45ofiZdiwjnDVmu
ggsNhanyUPpGeVfbewEwjldobUbl4oG4pIbgFCqNBvWfPEzvOuDIHIHjh6g4a3G6gwBdpg0qVY8c
RVwkSxK6TD7IH1dnUgYgMZStxK4QkKNIIolmxqYEW1l41FBb04cYjmpFBs7FF08nmAXTG7FWGgQC
tgZl1zJ4zHkYgxOxmCWN2LCy3KbE19PUUBvumE2C4gQiowFYbqpVv8RHAfSApoRBPhK/aRYr3CVY
QisULgLQOSUmbsBCjZcvgpRvDuXmKhSbTxTyF/8AAIt0F4LYkCSxwf4nmDA7Tqo3L1hjmMmh4RGt
CtrLv/5mM2hl28yk9cqzeJhQOUrhdTOgY+rR2+wJbFvrfEowNFHOKN1rhCVUKu0L7lqr9Pd2+1Eg
ChW4Ek+SwKA4urrRqcb8JbGK1at3xqM9NP2YzdTFtCTMq7bdTs14gYOQorQ7LGikQ20GC06smCC9
Zt9BMAMbACW6WG4mpLBDAurqAuQ6q5xMA3tZYbo3+sLUxa5tyDb7QVi8tfP9qYIdAer5INoFLfPc
SxGsRE8jwzNJg6Y59O1l2OE5EBAHSJs/8LwzorC+V4hXqXNlzWnUNGNZVnLeGW0FNF31eql4a1SB
az9pj9bl11HpF3kPG46Baq+vMGjAqEgTcu6ZVXOt0wXwjkPrAKoGL3i4qyqChnUdQCaxCqwHpMXS
PEKoOFdzRh25goXBi4Z0ntljaPuUWOqn1g99lT7wfKjRwX/kZHbZ9o/RSHNFjC9xo0dL16ghtxS/
a1b5qJkdpfgFk+s06ZgW7oU0eCodwAXiAaTJ7ChxEtQeX4lhoas2/E2BDvHzbvYMQnVW5hVKdPUA
JT3EaArWGNRQNpy/ylGgs0jhO4hlh8x9KPWYDwz4li6YSI6ch1EDg1317i6oN+iW4su5s9esMktl
wHBslCEtvZMIZI1WOckULVHFGLhGDt8I+zz8y3VZ9TEght4jJUOEcw2bMLwy7ByDp8Rb6dnqXUWA
yRAUHnuZYgWwEA1zzNiNgKKP4iYC3t6MwVP8Bhh2AckfFcO9kWy/ZgzaprmPc3UtlKHc58b7j66x
cesuSWGzcRAppLg0az7I35QhQdTAKZzBrR9wrlxmbvFGajsSmy5kbwP8y2EO+/EwcaK7jxEHJqWW
Z9sfIafzGuL9ItZg6N3GdMuDmjuCeZKL+sC7/cRxQ+YGbUstGCwJrzAyqL3AFm/UUa+8IO4jOMkb
7DfGL+XsGn+kRTV0wgq7yNdcR1TtSi+At+0RsFCAWNOTCeoxGaLfUsKlLW1z/wBgW7tHcIW7dHdy
oOXiuZhU7EwUH2fS4m8/GrgZPR8dSwopnpBaBseg2T4HzAtWDOHcsILu400H0OZRgy6WPMkVfcrL
MV7T/wBJaSTepGmHOF+5jbT3mG7xOnMapVdaZyFS5Y+dxo4UDSW6O8Z2ENF+3+SOLZbVck5r5/MU
FD05lrqiQRzwmH3GCmn6SzhFhCb4P9+0xky2Lf5hvyNkIoKwcvpBSvlxHF4xTB7MQbBz+Yu7iVtj
nWyXA4nNccyxWFaSZPwpq4l2QLqI5Lb+Y8RL3mX5Ny4RrcLuDplFVTpl3kXsmWHMa9lMsQ3/AEMZ
/9kKZW5kc3RyZWFtCmVuZG9iagoKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyL0ZsYXRl
RGVjb2RlPj4Kc3RyZWFtCnicpVRLa9wwEL77V+gcWGdmZMkSGMHuZl0a6CHtQg+lp7ZpCUlLc8nf
7zzkx4aSB1ljSdbOjL7vmxlBi+6h+evAbYCXPckYOhnvf7jPZ+53g06e+5+Nj8B2d42Mt/yyGc/s
slrJbHa37ldzfaah5WH/3bHpIbbk5D1+d+cjB+bV9QCpHG+aw7G5aqBNDtqQ+cdeH99xAGw7+Xrg
70t+b1zfxoiU3YcGOwba9R2j0mWgwCNDgdDm+esTx306TOZTmXrgOOaqH+Z5ioh5cKiQZJOfDG3P
9HuBQZ7Hb3fN+fu7zl38cXIoCwlZ/H1MkXSGPlU1KEAbGX7PZ1U9fGQ9vgxAhQaIZRMH3Javx0sT
R+I9AsNhfGI9vUdGolHIYWQKoivOuj4DJQaJQT2Hr0jIkOCubPyA+7LpBhjhomwY2FbHzDNPuoVJ
DND+3pXZZvFgmwNkHDGrfVc2OBAULzZqFQfYn1J9Di/lNHGe8QIHDgOhhqeCAnM0oAKLvJ5eUVC3
ojNC5oRk0D2KArgX7ryl6KqrEtWA1CvnbN7MRY40b/+inFGUunlbzij6pZsmDfYrWsJ6Tp+wMqA1
L2P9K85ZsuxZBLM5zM7/scFxXQB6AKINJxKQR9+LDBCSEMLUeVyIeEeeZilCG1UKeqkU3Ibcs1y+
8bEU24UIpSXnlBWuEdzXch5Xkj1dKDXptdBl75VsMce2eyNfzDSVz9Ku1ofaXQs8S7ml+iT9lTlG
6cOgTK1zlCmC+O6mge180Yzr1rpEMl1I28FKpmpbpmsjzqfZEXaxsOrEJqa2GVSwVk967qj3hORg
6kI6vFbvKIq9Ue8Ql4u66k2jXjfd0hp7RamADapusHbJrEwXS1AVxIOaTFKmk4ozjSWCx7ku1/Vo
9otSkr56ZflVE165f2/LrnsKZW5kc3RyZWFtCmVuZG9iagoKNyAwIG9iago2ODUKZW5kb2JqCgo5
IDAgb2JqCjw8L0xlbmd0aCAxMCAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicpVZL
bxMxEL7vr/AZKVt7/FpLq5WatIuoxKEQiQPiBBRUtSB66d9nXt5HUmirNKrj3bHH33zzzTi2deax
+WOs2VicZqAxBhofvptPb8yvxhn6PPxofLK47r6h8Q7/cRl+45bFjL5l3Z352dy8Ydf0wf3bfZNt
ar1JLZj9N3M2omOc3fTODvvb5nLfXDe27YxtY8E/3PXhLTpwbaCnR3y+wv9bk9uUHBTzvnEBgYYc
EBVPI0QcEYqNbZmePqLf/7speCqGHtGPbOUH2blGhHGgq9jRS/wU22YMPxMM8Dh+vW/O3t0Hc/Hb
0KFIpC2036cuAX/b3CkbLhRkAuG3qfLhcXbzubcXwwZ6u6PR+WETe3s+QA/BbukVdPhgy1CNbhw2
vrdb2PHSi+HL/kroJAQH8PFg3+G53jvEzueCcQmDxkxYN2XiGfApkg/I6F6xg2IPCoKwj0Po7WgL
wqeA9CWixq8wIObRoRUCR+V5TREH4IaN6wEGR69Gjh+jl2VJPLvC+wK9kAWjh3Xw4J3PRICNHYXi
uuDdHII3UFKlH2mINEca4KU0oABQLQVmSSsN3g8CDfpl8JUKsXirGSZWmCeOkPMuU4skCTGyQEJm
m+uGTeh9UMdkDMxZmKhnci9YIjtavGBxp0KacqX0j2y2I548+RITXL5IVxDLybqCGKuPiVB3ToAI
a9LEs4Ik+5DFICVzpKiZLhknIbI+y1JHC8ZJnK9VEwRsHCeqiZvwQVEBAlVUu6qmysMqfwur6mYR
MYZadTBpkDTAFq3VZfp1b5HjQcgalb1u9lQlqHyqrMiTD8NMN7asFZ3PMeGKO2biKPyl6iETKA1p
LesCZUGEEJArIeJDbZfsgwnQAq3Wl+ifLod4ov5dnGQ063/LTX53mOUq+VnEk7KXMWhCuWR4ijnO
mt1R+xT12ZoqadpTC+OewWldFAg1kdSvmhJqoPY58ST04tjJTpGNQlhlSLDlV1acw2vXn1hxzpVD
shNdTsLvtl5WKuuimSgwchD1UgK9zf5Fp0a+7Kh+cStKOdW+W5Qlv8iTnFezV3n2ka/Ip4wqBj9I
Abyu+LrSHrKyusXn5qvQp8bh5yBfl0usnHxiKrFwwlO9U/teZas2MZH4UWNAOlmrlDVWAscmP8cy
J3+Zs3TUbbjzrVvH/Hvu8lgK6UkpVKVp4xVdJQliIvba/AUu/YE6CmVuZHN0cmVhbQplbmRvYmoK
CjEwIDAgb2JqCjg5OQplbmRvYmoKCjEyIDAgb2JqCjw8L0xlbmd0aCAxMyAwIFIvRmlsdGVyL0Zs
YXRlRGVjb2RlPj4Kc3RyZWFtCnicpVRNj9MwEL3nV/i8UrPjGduxpShSv4JYicNCJQ6IE1DQagti
L/v3eWO7SVsQu7CNMvHHzJs3z55Sa81j89OQWRCGHav1Tu3DF/P+ynxvrNHn4WsjgeB3aNTe44Ub
vgg5Gem3+N2bb83+KkPrg/jVrukotGz03X021yOAMdr3vBx2d81219w21EZDrU/4IertKwDY1uns
EfMbvHema0OwnMybxjoQdZ0Dqzz07GFBhXybptk74P4dJiErSvfAKaF5UiLPGaEOQPmoi3gStR3K
75QGC+ynQ3P9+uDM5ofRpBCSksZLiIHzl7pY1WBOyAL6bTjqIRjtP/TMw8L21tGKZVhwb8fh4+6m
KKSgF4yAhUCJAXAZiI0NqALSkp2kfYJNECDwTIULFVoO3NNGWVBQy6NyYzcsQt1cn5NjsdIpQfJR
k9noxE5JoJF4nMVE1GtKEOXnEo0RmovrLoiyHRa+t6KMlpPZKM0iIo2U/kRea6K8nN04r8A1zju0
HRZO11w+jXWZSQCALUelae1II/ylOpRQG7PzSnOV3ZK9JJNOSVPK+5VmzW9T/irJynes6TNiHbt/
1R56x5dqb+3xok3qWxSCwlMlpWoW5VT0XLVUWSVX7+biss6zQBqasmbl0l1qE/ozxKr1fKJP4uGY
NkXHaT+zqScSn9Fq3EVtrxe0GqPr0+UNPlalZ1041su4PCnpWIYkTGWpsstK1vnyBwBI2ffZyuDU
4Bou1UG8Dlcao+1ie9lioUTIiODiG8roGTo4Punk/9JB4hFh0sHR4Grn0rGl5t7U8z/9U1rNXdyV
vvztSlByVmt2xNqytfSTg741vwCTf33mCmVuZHN0cmVhbQplbmRvYmoKCjEzIDAgb2JqCjYzMgpl
bmRvYmoKCjE1IDAgb2JqCjw8L0xlbmd0aCAxNiAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3Ry
ZWFtCnicfVDBSgMxEL3nK+Zc2HSSTJINhBxKXbHgobrgoXhSq5RWsZf+vi8btIroDpl5s8y8NzOs
DZ3UOzF1DBht9V6qPz7R3YxelaFqx2flAqPuoKrf46EMES3fUI2tbk8vajubqKuhfzGqyEE7CtrS
+EjzAcRA2yy2jDt1Maq1Yt0Ta5/woevmEgRGS81OyFd4O4o6BGMTXSsjGFSiYKoJeuvhMQp7nb6y
W/D+T5OgitU9eFrrlLTOnxNhD1D5vv6EJdYR68c6hnXwDwc1vzoILd9o3ZbXYlL4DO0Mtp80bDof
wjEOscksxWWzLJ3JvCidZOsqdsLJRisVG1dCFlfux1U72d8q9SQm2F8qIhMJTzpm4KF0LluuWdNo
qmZw/VlmTR8ZSHNoCmVuZHN0cmVhbQplbmRvYmoKCjE2IDAgb2JqCjI5MwplbmRvYmoKCjE4IDAg
b2JqCjw8L0xlbmd0aCAxOSAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMTE4OD4+CnN0
cmVhbQp4nOVTS2sTURT+5pmmViUS8LEoE7DYgsSkNmohiOBCCiaFBiOu6mQyeUBmEmYm0iBYg/6E
uNBVcaUQ3HRR3JWSRUG3rl3qHyhiaqzfxGlSJP/AM8yd7zuve+45dzynaWIazyFBMyy9ERUEEUAX
EM4ZTzytAF+EXS5yudYq7aXC38h75E7F1Ivb3sEcIN4iv1Gh4sXgYYi8QX65YnkbX5CNkHfIZ2p1
Q88gRihucZmy9I3Gadzz+Tsumq1b5n0v+4B8n3t8bNRdL4pnR9z6pW/3C+Hjywyh6nMR/70UIKIN
SG21xCmy+9cjschcLBJrSxhsivgNtfTzTVspsXdddJSsskQ/3KRXV37bkbcOHzMDJ6A6ymdawmwr
o6/EznMRpuXbh3sFRe31+z3hqpwu7vd/+dP35yBcfL3+Pby9fjZ9gFNTw2J2i5Gdk8WpDqvirHE8
KMaF8oPNEy7CP+eRZKCtXkI3tORXhSivzPLQS+JN/ZtHxPFduDOKO4MPo1yzo7wCY2YDLLI78wH2
c10LsEy8HGCFd+tugFXqV+kpyOwJ0ngUYIE1vQqwyH3fB1iififAMvGnACu4gK8BVqn/MW8saIuJ
RErLNW0tUzWcuttyPdNytRXbiK82TDvXsgr12ppZbtZ0Z6wYo7zpuNW6rSXjycRYy+MZWOCvsogE
nxRRDk3Y/GZQpc1BHS5afD2YsPjVsEK7gTiP2qDOZkSLlgI9a1ijpswMNeiMneQxSZenxmHuKpm/
d5LZk6xnku9wFkM5esreTJA/xc6ZXAplbmRzdHJlYW0KZW5kb2JqCgoxOSAwIG9iago1ODcKZW5k
b2JqCgoyMCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0NBQUFBQStPcGVu
U3ltYm9sCi9GbGFncyA0Ci9Gb250QkJveFstMTc5IC0zMTIgMTA4MiA5MTZdL0l0YWxpY0FuZ2xl
IDAKL0FzY2VudCA3OTkKL0Rlc2NlbnQgLTIwMAovQ2FwSGVpZ2h0IDkxNgovU3RlbVYgODAKL0Zv
bnRGaWxlMiAxOCAwIFI+PgplbmRvYmoKCjIxIDAgb2JqCjw8L0xlbmd0aCAyMzAvRmlsdGVyL0Zs
YXRlRGVjb2RlPj4Kc3RyZWFtCnicXZDBTsMwDIbveQofx2FK2wO7VJHQ2KQegInCA6SJWyKtSeSm
h749TjZA4pDIv/x/1m/LY/fceZfkhYLpMcHovCVcwkoGYcDJeVE3YJ1Jd1V+M+soJLP9tiScOz+G
thXynXtLog12TzYM+CDkG1kk5yfYfR571v0a4xVn9AkqoRRYHHnOi46vekZZqH1nue3Stmfkz/Cx
RYSm6PoWxQSLS9QGSfsJRVtVCtrzWQn09l+vuRHDaL40sbPOzurxpLhuSn2oC3d35Al5xZ9kYFYi
TlXuUOLkIM7j76liiJkq7xs0rHADCmVuZHN0cmVhbQplbmRvYmoKCjIyIDAgb2JqCjw8L1R5cGUv
Rm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0NBQUFBQStPcGVuU3ltYm9sCi9GaXJzdENo
YXIgMAovTGFzdENoYXIgMgovV2lkdGhzWzUwMCA3NjIgOTAwIF0KL0ZvbnREZXNjcmlwdG9yIDIw
IDAgUgovVG9Vbmljb2RlIDIxIDAgUgo+PgplbmRvYmoKCjIzIDAgb2JqCjw8L0xlbmd0aCAyNCAw
IFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMzQ4MDA+PgpzdHJlYW0KeJzsvQt8VMX1OD5n
5j727uPu3Vc2yZJkk0AILpBIICGCza08ClIUKVKihiSQhIRXAgQUkQYFREAKIgERq/wsUl+FRRGD
jxotDx9VqFpaaxXq2yqVr6W+IJv/mbm7m/Cy/X2/n9/38/n+P9/d3LtzZ86cOXNm5sw5M2dumufO
ryVOsoQwYk6dVd00ctrEywghvyMEvFMXNIcbf3C7D8PHCFG/qWuaNmvBz355CyHan/C5c9rMhXXf
9fW+RogHn697qr62uubqaYZKyOwNiKO4HiM2xG7hz4iP9Kyf1XxDdY8f2/D5BOL0z2ycWt329p1P
EtIkYfrts6pvaNov3yjj8zp8Ds+unlX71I1FNfgcJcR3W1PjvOaN5KJOQpYN5ulNc2ubPr5obyY+
TyKEtWIc4Jd/nBhU+DNlkqyoNs3ucLp0t+Hx+vyBlGBqWnqoR0ZmVjg7J7dnr7ze+X0uivTt17+g
8OIBRQMHFZcMLr1kyNBLf1Bm/vCyYcPJ/+SPfIik4X0pv5/7kbxWfOfHXXf+idXzMOYlsd3/VQps
8Uv6ryJaScYTo/P6zh2dJ8g2UkVsndd1bu38Bg7SUkxNQ4rtnV+RfGmeNI9UdW4lv8XYNvIg+TW5
l/Ba7MDr/yCWvfjLn39FVgi895N78H4PuRvvPOZhvO6+EBGw/YzHL/Abw98/nAf0HvF9A787yCKo
J9eQxm6pd5HFZCa7DkNZnX/F+8TOh0X8YjIN4VqRktVYyzmda8n99HKymOVijjX/Gbb97+d/P//7
+d/P/37+//GJPUjWkuXkE3I5WUpqSS0MgkFqVPkEY0vEdxz/mpeNHz3qB5cOHXJJ6eCS4kEDiwZc
XFjQv1/fyEV98nvn9eqZm5MdzsrM6BFKT0sNpgT8Pq/HcOsup8Ou2VRFlhgF0hdSo6nDJo2YHk0b
VhV15g7PNcJR5xUnxhZEiTeUnesJFxWU94tDReVIlPjGRP3jJu0i5uDyqBI5G+SKKOtlfJmNmceG
wiOiUi/8y728uiaaP35Sdq5xJJRML8c80fRhk7KzQ1HaC/9GYxL+XV4droka4zA+O2TFjI6ScZP4
1db53mCMJIOzy/E+flI0M/FYXn4+IlEL6Gw/i8wrYJWxy5k2bHiU+HcR53tREuBgJwaTKBkazY8g
IQaGBDZSEAX/l1HwRSEwFkk+swie7djg8/BgRM303BE1DcjRmqounp6wOJodXhVeNX6SpwiDgugx
0RevmrTLYR+WO6zWnowgu+wOjHGECEYRRNK0C5w/ABGgzhGX7KLE5kIGejnBI/g1PWqursJA7nDk
HKb4ulLaOttv755EMFsi5LNCVqlRZVhUtcgIN0TN6ihZHd7Vt33V7W0GmVIVcdbk1lRfNynKqhFg
F2G9RtRPiPYYM+4ajMKi8KqqD/MGHy5uvPnCI+rDq/CZw1bhPXc4b/Yz4mvqa6t4R4Gq3OGYpg2b
tCK7PRT14u+IqCcS/RGC/ejGD0IYW16eipStGpGLyBB2xPTLOM8Lku0iutvoGsF9c3V1OLpkynSr
c1Xfnujg2auMqPOrbGQ/NgDmFBnjnKqpms4pml7NazFienjV6lpRk9sF5dghwyOmD+cXz4jdm1yN
ua+ZNKI+d0RXgVgvDLBeZ+fNzo6mRXjGVatGcBKra5B6i2RM6KKfd/pQBJCeYVFzgvghEwSLsUSz
enh5PCoOcA3PxlOqhpeXZ1vNiqBRtdcKuX9ueBXHqPaK+iNG9j5Ma+/Xd8z4SSOGh0Tto3TYpEuP
p4aOY3jMuGQ0pCLMqoLjIYtHY36SO+Yqq5HrE7eqCdYIpcmGRdA4vMD6amroVQyPzB1ZtWrVyNzw
yFVVq6rbOpdMyQ0buat2OZ2rmkZUhcXQBox/anUoOvL28qhRVQ+XYCPz7jRy/Jio76prefOMDNdX
W9KgLDd7cCjbU56AGXeh5PhAwg6N3doaSKuMz5E6JwqdUHgklyBtOPBDUWMwH4lIy9WTsKNPFZ1S
3HAA/ATRh/hQYOW9RjT8JM6iUHaiy3DRdlU8FpFkZ/NBsrrNJFPwIbrkqknWc5hMCT1GzIIItl4V
T2lPpASu5ilLEinJ7FW52FqpY37yL3p19x69ypPrDZcWiBYQErUm2j4B6/jN4KhtcLzBfcMmsRCN
h2iI8ZA9ghJqaDQYERk5T1AQrjJyw4dzo0YkKg+b1B4aWh42PCjBINkd4hghaqZzoXk49yXgopL4
jSgMjUIKTyIoOoUEZ8HBmJjMGx6xqire17pXMS7va+rPX0+EMXKxqiEL3uPN5bX9nZBfccHcayQf
WaFsC+Ly8qjOxW9U/1zcsH6hYZPCKGpw7F4lAuER4Xre8NFw1XAhFMpD3aPbOo9VDecyDknmIKF4
J8d7+b8uNc0qNvXfHwZLcBjcfHt5/SVns3nMhGRo/KTFoRvL+xFC+UKIjF/CiEpSTbsKMvPKTJNI
wX7j3f2kbH/B/osLsz3Znl54A7TPT4dZ+2lTJqdIWGrnaykHEc378lo034vMHtJm2UZvoLdR5qVU
ZUBWS6YKmh1W64URWGzsT099bexxUlBWVDm54shxRJ3rUXIHhUuK6Pu7f/Y3yLhpqbRx8YOvId7n
EflCeSlSdp/ZRBFVC5gEwlAIJkgeJsnQUlNoylAoQ1gGQwYiQ+kJGaIybJWhSYYqGcbJYIoEjG9P
JFmRRiJ+pwzrzoRHdBXxz5z4Z278M1nERgCpT081RE1EHYpgYVsbEot0byNEeguDDjLKzNHWK4pd
Xk+Zfb0JqmpnzE5cPtmOdXHCDBp2ASLjmDrax+DsuSS93HjNU1qAf6Qg/XjZcW9pAWcS8j4Qv6S3
Tr0iZZ/exAKnP2OL5aX3xEbeE3NguREsdw+Wq9L5ZieR15sKY0ym5IYhtIWZbgYOZtMY8myhBg0a
jNagVIOIBmkaaBp8/a0Gn2rwkgZ7NVipwSKRjAkY/5aIf1rEY+ZykXlIIudXInWzBqsTeK34g5+K
nK9osEckrxTJmLmPBiENFJH6kEhamIhPE+VhxrdF0kaRBenopwE4NNh0SoPPBCWPiOKQyBkaTBDE
YE0Q4pRI3Wa+JBLHiJSeIvoVkbJF5GvRgFZqcKUGhRq4NZh2VINDGkQ1WKuBlYCxJzSw4ndqcJ8G
TSLJ1CBLgy9EEkY2isgyEUk0KMGEwxqs02CJSBunQYFIOCywrBNFW/GIKKyBoUGnBsc0eE6DrQKg
SiSViVQkQp1cUXF2ZzyrN54nRSRUnpE2t+szOZF0/sSzcZ5bXlf/j5DUgrJ07L0XF0K2J9eTPShb
2hML7I2lSaulj0+lSR/fkxgT87FvaqTMzMDhQFVYb9qYypiiOXygtKgoenA4OM4/HHCUpceHAljD
AEuS5p/+mNHTsTb2e+njmOeejm3W+LsM2mg9nYJyw/0EbKY4yAuM14iVd1A2re/4M82DtocRsh7F
XgwzKaTeHIQCBtZQ5qeUaaSc0A8JMMI2mzID6jVQUNJCSm38CVHayE1UlRfRSAQ83tLUgqIByJA5
pKwdeXG8tLJiDmpOkRWL911cyLXQJz5lMIkCzKkoB8jlVLBYxx2/oXUdF7ON0jenbNLRbZzy8UjP
aflekkKi5siARKU1PrS5fIEG32YftftA90kBzbnFoW3RJRrYDN6tPljgA+bL9RX5pvokH5N8lCgr
Pamm0xmgQYoEgqeoKLUg3Xh37PF93tLSSt6EpOx4aVnHkeNIeik+r9CRVjlB7F7i6jxh9vSlFl+j
TldvVF9WpToZFANuNTYaXxlMNgIGVYfbT9opVGDuOWRORaS8DwwqJmhB5uXmqL2LiwagsYhtnM1O
n574HVy+ZWvLzt8W/f79Vzru3xPbRg/e+TfI++zG5tvq1s754LHlsdP3xw7y+q/GmeQZKUIMUmHm
K60DneB0am7SCqzVbdhxMBBMKiTMxojXYVuumR6tlsb7yz7jCNYtbT/vj/G6FVQct6pk2tN0eEl/
S/9UZ1AxpxxUJFNRAtiLigLFSC19pqh/XklN9Y5tYxZcOUairT2mvwYdUcn7H1saCSXjOj+U/EhX
JrmIfGtWZbVKkhLetFN/Tqe6nu9NaXUHsgIFAWZnAW9rmkHyWxUfLEVaM3Qpa3mG2TejngbCKaa3
x6iUXkh2RKuj7X1ha19Y1xeW9IWmvlDVF8b1hUIRmRx5VtWOL34zkp72arye+9uNI4OPYwsWYC2x
xvGKeksXF6QmquvZmwNSyB/qGWKqP2ykjbKjEmL6dc8om2F3jYqosCf3QC7dlg7pPCGg2ket9Gz2
PORhmqPBsRDnidUMRONGsLNURCIRDJZn5+blDVJyc/IGDSwuLikRba1gY4vW9vh7D9JZwJ9SNKBY
8j9jBPe+e+eTs95+6PPm9SMP/ahowj9qDx/ccWz1suF14+qOpF2XuWPzbTNbJzjc2evnXpq/fEDZ
M8/HLv/lkYMu94CJ5mVXVWNHIOM7P2Qfy4eITnqQL8xxRquzp3OgkxKn4aQ9WiN0CKVumkWpU6JO
vNldxNdqN9JaJR94nW5YTlKWqmYmqacZah1dlwlNmZCVCZ2ZcCwT2jPBknCROI+NjvZ2UlaGM24Z
HxUFBXygHK+oMBI87f+2DR4LfhmkzwY6AnQMhTEhGO6F4Q5o1pZplOKMonm19zT2gvK6QpW2zk/M
nsH0UYvk1TJ1yeCSM+TjMkMdy0CNj0X8gFquP+pnnA6CsoOzek5C9JbLuZzT1DPQWzQg6ClinjzO
bIu9xezjHXPaX/z7yT2vz9ixI7d14u2bt64uWXAtvflu1I1sn0HuXXToqSp49kdVrzz1zBuDai1e
SlnYg/lOztvmFa5NaWaKkbYprTCl1WaQTWFvoRc1NqOV+twyqLKX+JY6zZCzgaa5lspmulxHD4eg
PQRbQ7AuBEtC0BSCqhCMC0FhCOac2V879sd5eiRtP3KRpPKOWoGcjRARHWdo34bUh1L3pr6UKgX0
Wp26/Bl+ykjQCIaDzOkOAHGDvprPneM0qrZ1fma6g6Md6rUqdRNmMBqU+Bw0mbNtMv8jfEor74Vc
I4MGkqIBJBDITkF2lTDBOlXKeueNzth7oL33CtDTp217t//2mbtd9868fmvq5IWQ13kS+sU+/bTg
6QNzYFPLxjuWcXmUhfL4qOQlDomaFTab5nDYUUvGCUKWJQUUSsHhIHZmt9lUWVYkTQKVqCsU8CsK
aCgNVkiaX5I0m+ygErFrquKWcJbxojaMAIoEGgEbsxvEkJ7qPEEUFLudqD07JEXrYwe7HfL49mQe
OUI+IpKDuFRFQcUcXsKMUprURxotlUuyS7rVBQtcUOeCiS4Y6YJiF+S5IMUFigu+/sgFB1yw3QW3
CojhLhjogp4u8LtAcsFJF3zggjddsM8Fu12wzQUbXLBMoKsR6IYLdD0FOoT/ygWI8HUXtLvgsX8D
/uBXooAjooA9IsNGQcqF6P3I7BTgFs0WrAWliMiNieLquhWXJ8raZBF3QBS0PQFkJX/UjcoJ56vV
hYisSRSfpHDaRwkCz6LuLRds/l62JQvYfiYXkixAJCVfmXMEsAWGqaUuyHEBGC4gor2OueCw4D+2
11YXrHPBEhc0u6BK1MwU7Ru+QPsiPLUyNLlgnCuONKFgVp6j9cVVv8qzFcN/pYyeoz+eq1ueJ/uF
0JyHonNBC7giUlRUUGQcQFk6YEDBnCJPsHQwfoTCgxpPe3s7v7zB0rhqtqJ/qqWhGaptqG3ouXeh
uTkoSDYgc+bg9Md1Nyjif+zoM7G3Y+88AzfHNj8PEtgei22D+2OTaQb8M3Y7NMfcKD0yOj+kpXIB
8ZNZZm+75lZauTKzye9FKetyuf0nEMbpXq5qRDGUsGIqkorTRrtp96eOUpSUwJIUqOCTO06+7a92
tL+Jyg1XNQnXbsraO9qNVxPaDQurxiiJ3yIQETIwb5And1CRB7+BXI8fpSAtrb5kxaKWlh0vvji9
f4mSfdf9tGYtZMTeX9ux7VE/UlKCs+03qHvmkBNmmHi3jPNV+Zb4mM+nZIS2kHSws/T01C0Zkm2L
ZmqczH6aVqxpji2KrzwAEtaS6iTs84X0wMqwvpL1NEkIUljIZjMNb7GtIAKpxgFuNXBN9E2htXiK
JgtddEBBfGbgwS6VpjSuPEuZ/kzao63zGzPblzrqxhSY6K/z03J3g5tOdNW5qANnrG3Zu7P3ZbNs
rs5kop4zMasua0EWuyUNltphpDRRqpPYSDqR1lFmmfYRPulagXJIQW2V5Ob0LuHTK9drcgeFz1Bl
Vfrp4vWxv7713aGiZ353+9NPP94P5t697OFHB+4/dOTrY8zWu/3mJ2Onb153/S9vWrHmrrcabkDF
9rVft/8UZ96qzg8kL/LVQYLkZ2aqd4smObcwn3slMdPQiAisVMxUZVFciz0e/yFcEYm37tCRwe3B
PUFWnDIy5UgKu8R/uf9h/5/9ErvSAFMHYh9nr7IzYhtnq7Ixt1QpNUrMTStpI2WqXNltcJeDQXuj
TmGgTuGFAV6PQXPFo+Q9/vnfP/v8+OfHY73Xrl9599q16+grsWWxVoBZsBAaYHps4+kxoMAPoC8E
Ykdjx2Lvxt4ltPOO2AS4AjU0F0mDQ2anXydCOVOdbsXWynp4SFAmyx2m2/Gc45CDeVl6yLG8pjCp
Q5SFoCAEX4TgaAjCITiUUC+s+KwQuEPw+rEQoOqxVugaZgg6Q9AYgspE8okQHEtkuzIE2OW2Iprn
QrBToPlCZEa9JSryXCkiraKeE0gxQ+MXiRLKBHrMeZ94bEyUWSjyHBVYkkVZRGL+SzvjdTBNjjfa
TUOyaOwUeZNkWdk7BeEWcUngC9nk5zfzJ3eP6QbWlXlyVzbx3GW279tn7ENBcqBsckVZUozQfM1b
LFRqNOhkv5IcEaiA8lEQ1/1hyOLVl0/KvqxfWb8dk/qWlfW96AeXXvfrX+auCJRXSU3wLI/4wUX9
fsA1qBVch0cNykOeMX/kbqXc/KBU8tjc4OKKurHcY/o89VRbbjO9tlp62AftPoj64IS4d/rgmA+S
kWjuNvm6uCRq1G3YdLQLs6jdgzIzMXqKDQdIDr+DGg4lpEQUpoTR2nHpl+pj9QodRworY1eySia5
5Sy5QGZeSeYAEOEjp7KCRFC15LLfMnxQoHIVvAQZ8vGOXz65tW3H/Jpf/HzHHY8+/Sg90DFtwa0P
08+w1muw6kNwXDCyyLyaYsRyMCUZsO+fkOGYDEcTi5H3ybBELD1myeAWi5FHu61TrpPhShk6RZbD
Ij4JfKGekpAfyVXJITt2cActRiaiBRBCORQkuaQAFPOHihOVS9CJ86It3CgpTGXu1FQlc4tX6oky
HWem0Epu1lJPoPdKlr0S1XEvc/dbqZkXs5tooSbWPkRhb3KRbRx/czK3QkuF6EL5jU9icSHeDoua
++/r/2Z/Vt63oS8tz2/Ip815+/LezGMT8+ry6MScupwFOUdypIVhWNgDFqTDqpS7Ux5OYcv9rf4H
/Ez2BXxU9gQ8dLnRajxgsFWuu10Pu5hdTVepXU6XqTrRD2n2PnaaZutjoylSnkRTaJ6Q+JLFLXKO
YhGX/FJuTk/s1iV5vHMLca/0sqYBYXH5uoWZ7ZY7Yl+++YfYl+uWVC54b1/7J82x1+puWz5j+tJ1
lT97JLrwxl3bmC3ym5ZnY52/WfRs/x7bpt3zxu/vrb+/3/V1VfObq+vnd/T75c+at22fe8t9ODds
I0S+X16K8jNAfm+OpwA3E5efEJdLoet1XQqsVxgBGYiBHUolq11bXHSh6yXXWy420DXBheaS6xif
/6hL8i62BwNSi2ymyDPokiA0BSEc5BVPDA3jyHFr+YdPBagkDR5ACg63WwvMHqETLTbiK0DmoGku
WOR7xUdf8UCFf5afVhizDLrIB5oTvnPASsdDDrpIgy81WKZt0LZpTNFSNEoSbLX4zRUmsU43QEKO
qr2ykY9GdrZ8/0exUGx5Gy09DaG2uzra4PqH9sbWxTbRso7n5aV/PNh6qPfNK1tQowCyCPvsO9hn
82AJ1zhabskKl4ZsDtvNGSF/RkaIOnIcaAeaPPqhDJiUcVsGVTLyMoozDmR8lSGroYxA7noHsIGO
CY5mByMO07HVwWySw2awvLDbW5y3IUzYejNX8m4I+wLrTcMXykgNO2wuhYR1bzFx52XlFeSxAMtL
bXGZLk6D4UsrduX7vEoLCRthqoZ5Rz+y33it22DYLxYFS/mFxm/62I4j6WnHMSB+I8QTX4arrIiv
v1VECD6v0Punjo2s0Bfvi8SboTItG55JAfY0hcf9QG/xr/ff72fpvot8l/hYAHrBIGAvheBUGiyw
fWT7ysb+oAJgvUZJ2f7sZdkbsrdly9dmzch6JIs1B2FisC5IHXpIp6rk9Dup08mVJTuCc9FHXYwT
EeEmtaUWxRuykv/NKYfEAoScSfmQCfcukSxlKa93fzpoYM+iAVJQmnLVP2Zu27cEyMNvbIy1fRr7
XUcJkC8f+fP0X9z2q1fXQc9vrgfvHGnepeMWTh4+fUT/n/zipkOfLL93+brm0dWX5PUbv/nGRw6P
HSFWQnHeeEmK4LjYbHrlTUQBB1O4UmF4NhmmwVsi3W4vNgy91efzyI6lxAzKDTSF1NEs7PbJVZ0D
51Mv4+xNLfWv9NNieiulB9xH3HS7c4+TznMC8uVPZopDH/WQfa+d3oSWeD4+pHkhhUuSSJw3FeU+
gxQNCKrJhZmSIF98GA/5f3nqwaI77tnwmxfWt24r3vH8x7Gj1A4UsqbcXv6n3U/+qW7lPOiHo391
rF7KxjrqJET+bl5ptNqH2MFtz7JTN3dSNghf1CJ2YktrdV1GDV+rzecIpSyVieFY7jQzsLo9nLU0
mgFlGbAuA5oyICsDOjPgWAa0Z0Bi2o8kBEC7cVwscH1wPLG+ZXRf3xo3RoMxnkUeOjwEwwGkAOwO
nAzQp4OnsNeosFoFl5qhLlaPq9JuZZ/ypsKWMaD8z8vmsveYpDpSQ6mRVObwh/wRP4O2zk8eC6Ti
TBpf36oQ61tzLLmLctYb4Ppnb74G6/GkJDTvHAVKl/xmz8l/Pv3cwh078jeNW3nP3atH3snuvCv2
zmexU7FXN3R8IT8bOxgbNnra688+9UoFicvRKpSjNtQz5pvpnvWEaettrsWS6ZMaqdbCdYsZNOxL
bC4k1eyCLjW7YLsMTncPd1/3o27J6ejh6Ot41CHZ2LXKIwqVlIEKvZYuovgZQKdQ5hCrT3x4cBMG
+0J2mHgMkp1dkj2AB3Kzt8GX8GP4Wezm2NMxWxsM/RZcsf/4OrZPXhr7eeyx2G9jN94DGWADDTKw
BnaswRV87w5DX5tX2CjG25mkSaqmDNb4/unNRMWZQdUkzSbdLCt+WVYwrcS+3ixksIStY5Qwk1GV
7/lpKp83UOPAXiTJclvnCbOPJmtk1qWqomlhh1O7rKYw6oRxTjjhhHYnrHNClRMKnVDghIRmEYHB
nqIiccc/klogLOginC/4VsfcdOQizhoosmw4cfCQCES4PS0PRRN6qDCgzfTVGgQ0YIYKigoehwKp
hIGbQposWCgEDl+8w/mCZbNcKPJhDa7Y/0LHgfbf0sujq99/H/4ay5KXnv6ORjr+gLLBhk2+XH6H
BGCEud/ualWJYRhUNdC2BtbqB6fN5hA7BdRBVMdytw5BppuGMyXoXJ5WeF8Q1gahJQiNQagMwpVB
KAtCQRBQbLiD0BmEL4JwNAiHgvBcEJLAFqQFZgFg6k6RVCYyDnlOAJ2LK4miKgiFYlK28mNmUwC7
g0mWd9fmuunu51n5iIDRnp76GjIQR/abkxNLAwVibWByRTvfj+Psf7ynF7xczntt7lG+cFom3jAk
8RBEIhESSeyGBAJ8qSCXLxsINYgu73N18aWFH3ywY8eO2+64St6zIm3qzGlrTy9mS9e2PLHJ2q1h
n6Ny6SG/Ni9TW51OTW7VDezJGiwnpo/UU7FH49X+s2p9R3tynLaXJbbCrS0qo/PY496UUWIi6Kk6
RhW7R7ppT9SJalzNLilbuUqpVuYoUhb2NJbFqMF4nxXqUAT7mUfY9kLyCIWPfb5T6PE7tu3Zupfe
df2yhzuC8qGO6KNPP4L1vLfTgHvJO6illZia0/G4EjWJz8lL9qjeYifDCu9ipu5muwYUxgkuLTAO
RMTcf/wkmldyl2qp9i6GtEHDh108ePxbvReFlMsLikZea+6bPWoollSDs96DOCP0hAHm3FTVrq5I
T/Wnp6duSIfr02GLHX5qn2ZfYWep6f5su4oVbiW0NdvwtHr9rW5fanpKpl11yqRnCs4PbicKkDxn
A/V65OWZJsnEx16ZddTIA9SnTuTBsTxoz4Mq1K3yoCwPMD7e27rbiUfS9nc9vJm2v5tew3tafA+R
X7ztxEainthINCe2BeBz/bROB2eBOwuoC9Q3wu+H6Z4waGHYq4Oi5+l0I9vOaGmPhh50dAikLH9W
z6zhWZLDFXJFXGNcku1HjhWOTQ72kh389uH2CXbG9czJXXpmXGFBDcWaiIPBFMtW5cYrX8bp3Z9Z
3A+yy+7bdMOSqytWHbzj/efff3bgrl0gzXx83fQJvf/08tUvj2OllZdfVnBpqPfgtbPverRh5eQt
Q8dfnB/50aSS235VcjFK6UWomlwh7Do3WWBeaZdQEhnczYW6UT1fbrrA8HArr9MDxzxw1APtHoh6
4D4PLPFAkweyPEA8cKJb0lYPrPPAlSLpfNZcqrEP9cd9OLArLUudG3VnGuM7kka45O1mfAOp6vxQ
XoHac4B8bg7/xAYf6yBvCLuVLIUqtvUmYx5Uf4XoZIa+3vT5lLDLW6zIHoP/Gp4gcYBTcSwmZgqZ
Sbk1Ee/dXHV4dz8n7sj+SFzD5X0kruTyQNLuu/bDADzlhOMAmwHG+Bf56WrvFu/TXjbCgGfd8JAb
Vru3uKnPlesqcj3ukvxaT20gmhS7tX2a8hzXO7aodIQCq6Ut0tMS201hI4XRdCH9NLGS1/UhCbUs
O4xqWXYOn4iLwqiW4eRcBZtgDAz7+4S3Y7GvYn+EXt+B/dPxp2J7Yg/Hmukz8CPY8ts72mLPxjrw
++Iza1+Cn8c1C+mvOC/biY8sM/s51hs2sNk0H9cwvJOkeom6W4hUJVEfkwIOrcVu+u2oaQQA/yrm
JG2vd7naWUEsIZZUQPNmGIsMWqM36/QVA/Zh88hQx0BhX+E8Xu5p8NByV4OLAu/icxK1E+aUlIuW
lS/bUpmyt9Hx74Ae+/ajWH1bGyzf8tCjd8UWyUs/feLJjo5D9NU7lzavIwl5jdLlLHnt/p8krwMX
lNeS904uruN7nblYT77iutdcPSIFrk6pTXkihV3jn+5/ys9UX9BHVU/QQ68xphtPGWyEDlfrtfoT
OkMbscmxxNHuOOyQ3WqLulY9pB5VZbfcIq+VD8lHZZlAEyyBdjgMsip7W4nhbFV87qXMTGMNNLBU
M1O1Oro1DdalwZI0aEqDqjQYlwaFaXA0LTnCz7vYG9cnsaXncD0ZBhCxKM13M7svQdAhfwU19u1f
34t9C+p7P9/+f+7c8H+2S5HYm19/HXsTIt98CxednvDBA4/98cjj29/n5xw7P6alKAUYudz0ch+X
dywfF0YkCj6KuuEeYjAiAy0oMtoHDB7MnVjaz3BfMZ0qTIOD8DF8jbWGyRXlGuQCLY1NugMelO/9
brT8ZMLHZxCOFZlkmwZl0nrwElVqAVOBGYn1beM1XtuLC/sAzr3Z0qDTjW30LXnpqTQCnSdjE9kJ
yYsq61RzjtutO50uh+GocoPbDXbZ6aCDHYaxglBUg6lbdxv6CpfT73I5tzl3Oz9wssVOmIHaqxPG
OCHdeZHzEidjDic4UNV08twlussgburQ3E6vqrWaUg/qcCsKRhJDd7m4ktzpdrnJtEudbnfY43Wj
jnyrF2q8MNELI72AmlSKFxQvfP2BF4544YAXtnthoxcQqC4BVOyFvATcV174KAG5pxvwgnPgk8BJ
yCRYd5iDFtC+BNCy8wH9O4iSMNvPpN7sTBK/6aQXjnnhdS+84IXdXtjqhfVeuMULzV6o8sJ4L1zm
hYFeCKN+6QXqBYT/oBv8tm7wNd3ge/578BO7wacI+GlWhiPdMmz83gzd4SEqarBB8KxJ1GCCl7tv
FIoa+L2Ac+cJZMAqrPObgsX/To6SJHQSNAmXBDovDB2XwES80O6FdV5Y4gWMLPCCISLV7gZA5Xn2
Sr93n7Tyv7izem6GC8FN/h6E50UmLMqEWekpSi1AK5NwHeJAGRqXpXyTNmK5dsR3pFecYWTq3MgU
lmNi51aIqJzH3OBioEos1WUUb3Y/5KYbnaA5+zhXOtkq+912VBcEPiIW27gjnpLc4Cjhu7rsROya
sbsfuKqyV8WAnywtjE15HC4F1KlO/eX5P/ZZnXn77ZJ+ej8bEp9JFT7DhNn9j9s2hUJCdrg8o7yt
wRB+/Wlya4bRmmYE3OD0c0ck33K/6fQ7SO2QEF+7yc5xopZYkQOlORDJgbQc0HLgu1M58FYOvJID
e3PgkRzYnAMrc6A8B0bnwBABh0AI86kAeykHnhYwq3NgYQ405MC13SC/zYHPEtieTYBZMFhknxwI
CWwvnxJwL4kirfIsoLHd4JK4uhe5OAdghgAdIwrMyjE7QRKQWORzObBTgLXknAUFjhy4u1PAHRXo
EG7LmaBXikr0FKBnga0VYDUCXVkCo7sb2CMC1aIcaBRIrPKmW0Q93Y0oq5iQ4OcXInMSYEOigIgA
wDqdzIG3E6gtKgeKJCy49JRIw5xbc8wreN7mc6p7KsGVbYIyKzUk0B7OAdrO88K6HKgSNBXmQEEO
kBywJQdW5ble6GeMu/OOuPN5Wpw7xM8zeCvPB3mm5LggwoRzvJjqByS1X64PcoXw8HHLtc44Hkks
Oz75ZuYHmSczWSZfo9BU56g30t9Pp8IrMV1zjjri/shN97rhDxLslWCzDteoT6k0K+G0SNKNdLRe
uMrId/Ekg+93VwqfMKGeRvjuflx9VNQU7u95hiYZFNqkkrtj6pQfrCmlOyoqVt+yY8fKx98Yvfa5
ex6kdy3+2RUjPBd1DOGhuIq5Y0fbDiI2ZISuotCYOZDKMFhWZElZQQCVE5AlWZFWMOpnjGJaCVEk
5kYFS0GVFAwFFRzGhMiQmYzqBlBZDqs2GfWNZTa41gbDbRCycbeTr9+2wT4bbLGBlTBGJDhsgPGv
iPjVZ8Z32uBNkWWrDTaIXFU2mCAwhm3gF0gPHjsHyIKwkq2k7vEWLWeRkozfdCFakvHnpYITYb50
AVotkGnnkuL/XlKS8WdRUnIuiWVnkfKvmHYuAB1ngwIboD1IbPHJ+jweVOcZQmcnnX+S/ZfZLjDz
nj0Uu9ZwcVxYy7hFYoo9/9qtmEszZsjACpRGhYa5aeumjZSqBMAlAWQo1tyM5tkcUmn5s1uTZ9XW
WFViyvy75LXmSkpK0SooktegBe0iN5g/Ul1O188V1a8oqs2JBoIzrHuKg04gqrO3k6pgU3CcaK7N
oMpBGQcGc6qMeVUnGqmrnZOk2yRKJMmlFBQVFVRWDO0Y+qq3FM1qvirNn0orK8QOp7WhJmoorBjI
FUcTAPWNbA9IRW/s7lhDN9z5Rmxh7FIoib0EJdtZ9PQ4urpjPqe5Hi3IXsIPvxf5ozlMIvABOYnx
WsYW7ns6jq1jksaY5vZsIV7DS+3M6/VvcUvBLZrPY7q9ozzpK5VcstJp9lZuonnO5F55x37j+L6I
MPi6PJ3EvnnFnDjzr97eE25M+XMK1ezl9gY7+9T2rY3aDKcxymEL2agk+aUJUo30gXRSUtTcXnf2
oizgC+QG7gxIG9yQp9+qb9TZHjsMVIerE1Q2UB4uT5CTSyVkcnz7qhyKxR6Mn+Za6yTxnSyIm5rc
l9sL2YVtdXs7vnzry04COR1P3VO6Zt3DbXDxrXdsXtbz8uFDht7LnGPKY98dejf2CcyEa2EO3Fy9
dmLH6Zui97Q+npJfPMF4NHZC2OSxCexj1JhSSR6MMfWgO6/V6Ux1ukelt6akcFk4F8POFGeKntHq
N3Jb3TroPnlToWIq4xTGhDuRy5Ph4XuX6cHlqWZ+aj1V5PBSj9nbU0fNfAjnw6F8iObDOhEm+TDu
aD6058OV+bA1H5bkQ0E+uPPhRD4cFgExwcaHzOT4GEps4qbtT+6acQ/muANzhfBswAksImawsniL
Ve/OhqezwO6Gv7lB9sGHPhjtgtG9YGQPGBngFoicA1fn1ObMz/lnjiRnwtWZtZnzM/+ZKS3yrfZR
1R1000Xu1W6qGbpnVJMaValE0UQ/YBwxqANCQMV0FrG2z+ILQSJUcYaXTjeP8UHneIx//pd3Xyv4
3ePL75zT/spnJ/e81tjdczzrhVfmrGm45YZ77ob+YOcO5Is7srr5j6PGG9tN64WnV5EZhLBKcKQS
t2PpAgl6SyskelgCqQCpOm4caS8agCPS4s1jk+wAFXyHgfuZlQQVir2K1o9+4/nn3xjdumZV7P2C
D2EbyCDBtg8LXo7VfHUyNpVr2MOxvGxR3jAzrIQJSWN9WCljNoblKq4qFVTdvnQhW8kocxtHeLkV
WLDwJ4yX/UQfGfoAFl9R7kvhzm5q72LvoIG095p46Wta5UMfxq6LnY6dil2HpcMvvvsK7nkZS+fv
QnoYZ3enNMSc0M4Os2OMhRhoaF+A0+GMT/PU7rDfZs3ykmbTbmMSBiVZtakrFGwXRb7WAYqDTzgM
p4iA7AhrzmIbvzGuwPSwG8URBsKZnamKXXMSt83hkGQKXkWoB8QA2ungPuaI9oQNltjW2bbamM3G
gRkjqhJW2hV6WDmh0EoFxhF4joCbZJGjhKmMmClpo3Qyn7qUZjpRR9EAkg7ffaXDBzoc0eGADtt1
2KDDMh0W6DBSh4ECKEUHhPlIAGzTYaMOC3Wo02GCgCnWIU2HkwJgnw57dK6V3apDs4Ap1aGnDn6+
sg8vf5vAskdgaeiWXxNJe0VOzDZR5Iwkclr07TM7Rdb7BZEIOFeHGgE7XJCakwDfjOS+rsMLOuwW
VbLqUyMovqxbrbD2X+rwng5vJuq2PgHcvXo9E8DJSj6WYMStCcjhAtIqvuGrbkitqi5L8KM7RiWB
cY9AZ9WpIVGh4u41FzDbdXM2rBTVhipRak9B1uCTorB9AssSUdIYHQoTnD8lkraKAhYJNljsCulw
QhTwiuCT1e6YWqYDNXQguhCIZ58LPEffqDw7/XtNiu9dELiww/i/0HHOY3Xg/Mo99rh3wRwPagNp
BQOKhFJQUVQkvImLigYPJqlc8ykyhCM4Birm8B1QrjDMEQf2LG0h7hd+5g+Ibf6EflRs52dSX5Le
kj6V2AF6hH5E2RAZBgLk83NTc+daMyzkMrGf7cM/+eHYKxtjsdbYK7t//8WDJ37PlSQ28vRTqCj9
hfXkF/cIQb0jW5x4CoFkjjVa7XY+RybdQWThDkJdJK3V8gdxpiyVhSeILnxC/i1/kMTE1uUqeMah
p27GmTlES01LpeWpDalU86f5abm/wU//LEO6Ck+p8IEKshpQ56vLVSmdwQcMZBZg89lyJqnC/cPs
FUgd1RJ8LkibAtEAdWvg9nCP2UMqLFHWKbSdL0eDo6uNLa9L0YhiguvuJxL4v/UTWSgf6sjochMB
UscWQZZYnw6aDlgiMbklKAGRUJE8TsrSX0U1keWyQUWQldvYe6/0YOwN6Pc23wPqPAF3Sr3EfsKg
vUTpbDd7oI6nRInh5MqeM+r1MfdOUwukpgV21hRae/OWN2oE/xBvtw07X/fNu9CAkSMHFA0fXhT/
lXqNGDBgxAgMnm7DyOHDMWStrON0spQ4WdDsdOB0cYvd4bfbHZokSzfbNQxqDirz6cnO3FKWVCAx
VVIdQFuw40AZgSsJaPIS1XTzaVs9oVIns6t2MuNSJtntYbcdHMyl29EARflic+jQacmYp4WQmCEE
zMCEaFktRM6QhCBB6EOPiOSwkD9EiLnDAjQqZJQlDS0RZgpIQwiyTZY82ifQWAIL4cYJgVWYkHaI
65igBWHWcVzmH6Gpm1izCk2WeFZxybKmJQvqXkqyCAv/sm54LaQWRqvGFjqEL+kuRJsTiBwJRE8n
EI1JIDqVqKclsGmTKN8UshfpzxJMS673Vn6/lfh9Kz3/3iKtBZXQfrtOjE+2jnVbFqMw8qx1HByJ
xnE0HQsOT64Q0rOoqP3sMzRCXIwMUOhFB9GrKRskXy3TT+yw1/6Snf7Yfp2drrWD3VTtowJarUZ7
aVDMJrI6diuT3kINx3CgeVOIqXs00FByPO5wj9K4G56BcddKqyX6EiqYhuoQ7mSRCP/jJ48j8Qrx
RR40RPm6DkC2orTFxm2MDX8wBm3wKI7we09NkbaeqpKXnmqU7ojvhH6DctYBD5hVqF5RCszOHA7u
pbeCOFC5c9g07TY7w5HFhgvRZqMO1sLWMr5xpinErrlRdHjfoiDTVvoAZfYq0kQoc1CmtXMvvrV2
6sGxBYTwLc9b3d5iQkwUJiRMqEZcNrZcNokMduaUa2mZC7Jc0OmCoy445ILnXLDTBZUusOJbuoXd
Lii1zn9tFQe5qkSeZJi44IQ4I5YEMF1QePZJrzNafvIZHaeb70dHuzhLFT9AzgVzkXFgQKVw1yrj
rmBlYmINFom5c2xESiwlrLAt3metzCd2f22d7Y+PvWqUjbMiN9J/lORodlBDMzFOM/HZQSHVBWOB
pklgBFKLId7/+LljInaAwfLW4Uevvnk1tnLRjh3w9IuxBirNj82RD52eD6/FqrmXO9+D/BwlpY62
exbZavYjWevD7kI3WgluNWW9jQXXq1xDpi6ZqL4WpzO0mGWnBFtUM6wmNin5fv3x0gI09bjtV2C5
s1cmzyOZl87IWJSxJYPNSFuURhs8Cz30iOsjF/2tLg4a9HQsc2xwbHMoipQi3SptlCQ0foopvcgP
xY6JDmHLJdoh4X+eHXeSFj7SA/nLPuI7+2z3hm2xI7/r2EH7fAzSyo5+cN2aJ2NtsQdh2v0HXn4o
to3GQk/e+sIH8tK9v5q2pfeCqQdOPbF28Q23Y0fLYm/QNfJWtKBCZIp5iUFTbFGqE/o4MUMuSTdV
7JHiJlMq73IYRppDT9sV9hX6TN9Wn+TzZfTYmQH3ccXBOo514DX8MSzXJu710Z7+6tgPjHYD2cVf
/qAEUpITW4l8xhNds2jQ8MsGDB7/VmwvhoYNGHzVW/KkoVcpowuLRl77w9/OHtUtzFcLQuz3dKV8
r6D9WtOV7kxzPK6TqOlXpHTsQ49ztyvel3pw+onm1HaxdI+ue5hnVzB4Jt3HBdUHjOMH+Ek6i25s
4ZPt73Ciz/DL6nXGE5XilPZeFFufdNiStp+X6FFDxarRCfYlUp1KepJ3zXqPpmq3uD1+t9vzlRs+
c4PmVj0e1a1JTkrWp6amrKeSM40rEGnRLK/mhm0qGKqpLlHb1cOqrHpQxDh9LYVykxyVj8mS7CYo
LlB7QQvU4eyxM8fslZcj1A3L5QzVNw9fFZtcwV8HEOQOWaSsI/IaX2o67sGIAvyc46OV/rQdFqAY
preo61W6Owh9AnDEBnkobrkNqumeUbIUkCjf9rdOqBNuUCObhFe/oqi5P6AlxfE3P3RXdOpf3/cX
SB25cmoNvYeVTRrZMODXP7+nHeYWjRzJNRu535x3d4z7xbyfrJrVuKXqkkkzSubdUXe6NKn1MHJN
Zz/Jr1xGskk+KYAhZnlGQf/M/s6c/N6u3hhY4+rtd7l6r8yEGZkwMnNiJvVn9syky7ioK3SZrnGu
JpfskHpn5mQ4C1z9+2g9csXZRdMmzi3mSrlbFCalbUk3eZ8yf4LR6ek9Uvw9tgR9dZ4FHtpAFpKV
hPV39XVm9iY5fqXAGWQZOTl982x9V3vS8lYTc5xnnYe6PWs9z3kYV9HDpIpIGrvY00gLyUy+6ie8
OkQDYR/cx3skWh7v4NXlN4dqYvurnqKkl3r78VeN9qTTOm+5xCk+0XYSbztVHyp1Odk+4fZl+Sj3
5TCd2J8sp7RlITRFCG+1ct/A4pJBRYGUoJrXG1Vo/iZHRQ3kDsrrXZIS9PRnskdRAv6gTzRj78nv
HJzx5/svXfzCzx6KXP3hCzM+aS848PjuSdUlsO2Gnx28e+6KBUul3K0vGdu3+5s3zwzGinpPunjq
LU987n/qKccN997goJ6h+de13AwPO5quWXVpRy//7VXjZ/flqzrcy/nH3E+bucxS1aYqtluspRRV
UW3KzbLkl2WpDV4E2gdKgbZJL0q0j1QqUZBUlcmKjTDmleNrIyq0mJIk24giZ4mXOFURMEmUUC7f
D5Gj5Asiq8xOrqeavICW2rkT9alP7VCOxpsdXrLDQ3bYbIeJ4hHTvrXDSpGaZgfFDi/j80cCbq+I
QogDIs9CAYQm4KciCTP3Qf0ZcWGGIwLoMTtss8NGO9xih2Y71IlCLrPDQDv0tIPXDpIdTgrsb9ph
nx322GG7HdbbYRmORTtMscMEO4wUZSB8ioD/0g5wzA6HRYao3fwMttphgx2a7FBjBzOB3I8ahx0a
EPsHCeDdgpp1dlgiqKmywzg7DLdDWEBbpBxLkBIVwBsEZI2gA1EXCtREQO4TqJYJgAkCT88EnlIL
yzaR3JTIb9FlFYM0tQuCLBRWqpX5A5H3aZEd89IqUWwBV6XgXK34AksE37fYcJYOXPmvnB+66UXn
RMSXjOPDew5fcuCLDqkF/OU/3INKnDQvLSgqEqMWdeUz9lni65P1MkxD+3cOmrlcc+XbKPKPO55q
63jmVXgD/iovPX1Xx4c0xOo7IvQP4iTxh/Jb8ZPET5iZ3juI5LxD8bkXc+ezRhpYzJ3PZtIlaRBO
g4qzjzp0O1FcsccPG4MgpfhTKD+tQTf7UAUPGXSzB+0bv061BS5UVuoctzrYw7x1Btp329kDfC9t
iI3epsJtMjikIRJ9GAcmHUh3o97LCBTCOGB6fAu265MI83Vg65CEuIN1TkJsPrAsKINFsSWxA7F9
scVwPYz6HJyx//j089gJtFvvjc2K7Ym9EJsC98IP4Eew8bv3YRA4QIVLMMO3sW9iLwov7Q/lPihb
PGSVOcCjMucdzGe08NOls6kN9TuvKk6AJD0YlwgnxiofjPNB2Nf1vrdz2RZ3pTf7uF2VrhbXWlcn
Ko+OccJTUHJY9naLJHGpG6ZNOKlL8YMNWGE/r23i2Cg/SCv3ib0W+zx2PPZa25t7n33nUWr7JvYH
yP+atZxe0/b7N/eyRuEJ1yC1xD7DOdB4AvgLrCSDn9cteNV6hZXUcmq+tDrWcEvc606+XLxt7g0z
+yxb5uakLXOLZcuIbefh/mBxDYM9llFTyRqFUaPYNcZNGj/tSek2CvdR4MYMmjBh7kVYRajKuN3S
IptOuZuqzM/08xcucOOgQrwCiy+vJSyD+DbjBW0DM6BpaVqpxvyXwOWwChhzAwTEHiO3NM7Q/OXL
P+p4dHdbGz14tGMNPbit4x15aUcV3dqxJ8GHXMGHCrOErbfZZIfCQLZDCzFdZDZVpTjlYWEdRRMG
UpMwnMaJt2ac1QkS/qwd7dyhtT3+Kr5cT7agKBsbM3fv6S/b2pi+l97TUYPU7KY/JnHP6404UtPg
CnPeReQSQgO+IKHB9aY7tSC1LLUxVVJZaqrPhcLNK9nDulFs3+AIO0zVVuxwrbdJvvWmeBOPXw4G
jYCD+2M77AGsCTFz81FvT80sFlaMh4WwasZi/ooeHPninTzhUNexz+NCQiUP6u6Pv61M7GmhrCrr
OIBaRpp4jRvfHo6nYYqX6yaJ9U59ewDe80Cep9hThzo270OVqGYcd0Mfd6m7wc3cBj5+rsD7ElxO
riFPkZeJ9JAGznzdO2qQ9wkvDXh7eQd5H8Dgh15lkA4BvZc+SH9C/1CXezngCQ0GqcvVVvUBVRrE
lrNW1uXaHRHbXfFDd+W9lPg5q7iDdwCDA0r4S+fkjZ/GdsXuj1l+3peenPCXWOep2F9gMKR8cFts
MR26cANsgR/CZZafd9u3sX/EXp0AZffE3/OjzuLra9JPzdF8hyeultgpozc77H4cTXyH55auHZ6b
rR2eRxwQcgxx0Ee4qwHKxgcYPMD2sz+wD5nE+PpFhs01ijCI7+8wmyPiAJcDzt7lsbZ4um3smGSJ
pcjgqNPJ69StVCr3KYeUowqaAeJlIczDXMrv6U/FJkOJDkEdVB2+/VqHgzo8qcMKHa7XYZoOPxXJ
vQXEH3XYJOInJvYmrHhFB8z4cSLvrxJ5S8TeiYX6pY9FfoRo0+FBHe7S4QaxgTFJh8E65IuNHYT7
RIe3dHhRwGzWYZUO9QJmtECXqoNNlPSiKOY23eyEUSK3lbL5YAL5bd0y5id2jRD5n8Tq21M6PKzD
3WJx7kYdputwjQ6Xi32kiwSwHZmhw98EMS8Lmh8S9KxMkG3BX6JDHx3SdXBicR06fK7DOzr8Todn
dXhEh3tEATeJRdDrxJLeULFR1UMs+J3W4TMd/iIIeiYBT9bo0KLDLB0qdRgrFvkKdMjQwa0DFvCF
KOCQKGCnDr/QzfWwVofFIse1IscQHfqJDRsXcvaUDsd1eFuHV8XS4q912KLDGrG3Y2UYk9g8SxM0
fStoekfQZNXhF6IOi0UdKgT8pTrwDFk60E4djurwnA73CaorkztBlpbUzR/sfErS97iUns9l9ftz
XFCxuyAB5136PDs5sZYkJuXue0PWzlC3jaGKiq6toYjYYLdWti60KZQ4R4zKO0q7h2ToI8EmCe6i
sB1gHwNSAXMswoSbjOUpg3/qrNjsaOye2Ipo7OZ9kAX1T0Id9JOXfrdYuvtUnbz01AZpJr9QMo3s
/FDiK//pZKWZT1JwHtlCqS19c5DZtxAHaDjRu7bYfGnGStnsId9EyeoUMwXN2d12d3GKveDAmdrM
PpLwOxFrWh0HPKWJRa3sx5wwQalRmhXG3UuaJaYaTvco8YIFvq1D+eJhBCrih3els16Yk6P25q/l
hMunTPkQfLHP3v/2UNGzL695um1ddfldLKOjhU3M+OfLr4h35Dy6cvnW7Ay6Y1tib0XsyXjoIrNT
YlQxxd6K04v6C5UXS6ZkZmYWS5K20216fe6dNYUNPjjgg5U+GO2DYh/k+eAtH7zkg+3iZZh9fJDm
A8UHf/zWB0cEnAWxR6Rhwl4faD6460sffOCDN32wzwcI+p4PXhfh3T643wfrfbDMB3N9MMUHE3ww
3AcDfJDjA78PJB98KeCtvI/5YJsPNiTgaxLwA33QMwE/7aQo9iEfbBYULRTEX+qDfj7I8oFbHLH5
wme+Am/74BUfPO2DR3zwCx+s8cFiHzT6oNIHY3wwxAcRH4RQXfdBhw+O++AdH7yagN/ig9UCfoYP
rvXBWFGCxQ+ELznlg8/OzJAkpkFksApAkjJ8wEEtWp7zwU4f3OeDRQJxkgQkmh4SyZi21gctQps2
ExXqtth8hgipnDv3gmP4fPLg/D6v3wM7OenVc+YZ2rnJs5ndVsysFTJr5++sg3Utveb3+W1NYmNu
UMdg+iJcceqa5AIVt8hiv5ffFn5iOeSUOexW10eur1wszdXHNdq10CVlrFclj3s9f9Fjk3+JX0Id
3BVcT3yuxfx/aqUvtoexe/e0N9JcCZW3nhDuCRVdry7gr2st4AZI6Ts4YjsOlHUdqpu3JwfC2YXZ
tCCrLIs+lQlP9YCCUFmIhtMK0+ieVHg4ALc6Nzo/crLrNfiVDUbaFtgO2L6ySb9SYKSyQDmgfKVI
T8iwnR1hHzE2mr5E6fasI1mUv3aFOlJCKZEUpg7SR+j0U+e3TrpM4X40wpQjZ7eBeFtl0rDzEzXx
KoQ81t3E66UkbDsw4abYt+9V/mrCuPS5V0Sfr/sc9NiJvwljL5Sw8WIzY0+ejt30wzuNtRk3Q4Ew
+BQYkjT4+Mamddn/0bu00j30nyRkE//55P73M15I/BcU/oYqdZbC/1edGv+fbyKP+oPYFWRY8p+l
ADnzM0LBKGke4f8z7Hl5ItkmvU8ieG2jD5PLML4er/H8/4nh82oMj+PP4iIkC+MzMFzC/78YHOy8
A39XwEGyBn8nygfJNsS3COE4/Or4sx3z2Pgz/t6LaTUIvwjTqkTZ80QZojz83SaRzpMKL5cf7p9H
SpP0YBxewzFfGs8DK0gd5tmGsJgHy5oo6M/CKxTPcw0vWynFcg5iufM6T3IYThOPU9eQLIQZKXDg
M/Ilm4wlD5EPaRFtoD+jB9hI/K6Xxkr/kH+u/tom2aJapr3A/rD9pOM3zitcY1zP6lP037rLjQzj
DuOAZ6PnuHet95++Bt8Jfy//iJS7U7ekF6avChX18PUY02NV5oGs+Vl3ZL2efWPOtJzPcy/PfaDn
2F7FeX/oXdP75d7H8mvyH+5zS+RQ37J+9/avEC02gr8KWLQXJQYpID9BC/AVaSrG8dQgpCfb9fFk
G/M1yMfjYYp94tl4mOEMuy8elhDm3XhYJk7ySTysEI2cjIdVMpV08JIkDZHWQVU8DMRPD8TDlOj0
z/EwIwPpJ/GwRPysRzwsk1RWGA8rxMtGxcMqOcCuiYdtZIAUjoc1MlgaHw/byTfSqnjYQYrlW+Jh
J2mS2+Jhl3Okkh8P64R4Zw9vmNbQ3HBjbU24prq5Ojy1sWnh3IZp9c3hh8IDCgsLwz+cVlcdHts4
u7F5YVNteFjj3KbGudXNDY2z+4d/OHNmWMDOC8+tnVc7d0FtDY+cUj174cPhhnnh6nDz3Oqa2lnV
c2eEG+sujClcPbsmPKt6YXhKLSKa1jCvuXYu0tMwOzy1dm5zNf5Onz+3YV5Nw1QOPa+/VUT4h2Mn
jK+dNn9m9dwzMfcLdwF0hSbWzp3Hy7q4f2GhFZtM/n9KLBlOGsg0vJrxupHUkhoSxqsan6sxNJU0
kiaykMwVUPUYG8YRFSYDsC/zb5j8EOPrBOxYhJ2NVzPCNyGmMEqsRszZJO7VogQO0V/kmonfcDe8
88RTLf7W4u8CQUkCcgrmnk0WogEdRngOyctrFlhrEHIW/s4lMzCuEWn5z9AUFiXwunNcC/F3ioDm
FE0TZTYLuiz+NIgcU0UM55P1PJ3MF/WZhzANmJrAPQ/r0a0Wgr6xZAIZL3DPxxRO/ffR3O9MPiQx
nC9uoqBqXrJeF2PpvKW6w56T+380Z/9vKfq+HMMF5PWi3Gn4fCVC1okya7+HX/NE7DwRqhWU1gku
Wlh5WVMFdh6ahakzBR9qRG/n/X92vPbNSEuCP7Pw3ixwTcVcM+N5+HichVit2kzBWA57vRi/9aJ9
eA4Ov4P0FbjmizHLRzHPMavbKK8TfOE0TxX8rxW8rhH1ahK9cqHgMB+dzRhzCc5ZBVgW//bH1Gnx
+pzJw/5xGv9zuQpEvllYesFZ/JmbjKkUrcPDN8Sp4/AunF+uwPaaQEaTkXgNQ17w8JUYy9txJN5/
LOJHYMxP8M659SMchSPwO1bETsA4lzj5YcdwfbyFz23HRHy9eGpC2hoFxFwB+18ZK/nxsdmn27hp
iEvH+aJ38TblZSzEHPOTtHDuLeg2jubHOTS3G53WOJsl4C0KOW0z4717dhw7byGrN8wSsc1CCpfH
S6vH9AUCrhHpSIzQRO+9MMfmiRKbsQ9UC+xhvBrilM2N9zoez8e21dPrBFdnJeVaON5b+RiZJsZG
Im9X7z+3lJq4hJkrRst8wYOaJA8bBe0JbiT41MWRqYIPXfyyKOl/3l5ybtld8mGBGJHz8Z4YsdWY
Nk/U4lzcV2PJM0W587q1cxfnrVY5U2ZaksOSRU2Cjw1xufXvtHBYxFSLcELyJcrl80BNXD/g/Ko+
Z97um4Se262XdvH0+/kzMy6Vmkl3GdiFZbZ4akqm8FpZfMgng8Q4uV70jBminbuPpYR866KtEWFn
ixE7X7QEp6A+WWOrzO69PTFjWWO3SxtK9MXz9a7vq3P3njNa8Ofc1k3M5nMwvlZgT8x1Vvmz47Pj
7LNaai45W5tK4OZ1bBR6Rg2x5t0FCFeLVJ2vz1+4jyTwWeO0Nt4ONWeMwAS+c1vb4phVg2YhF5q7
je1EW1WfxeXzj8vvk1QJ/n6f9J0quJyYac+kyaoR70eXdMN2Nc4YP8TnwWQgKUF9rAT1qsH4W4jP
lh4cFiN3DN4H4jcf4/ogTAkpwiuMVzH21lJxdWHl18h4zc+uXXdpnZgJ5gtNY1pcfzpzBDYJmVEd
z71A9MCGuHyZH5eTtVjjcDy+NllLTsV/Zn5OpBWcRfuZczK/fhzXOmbjfYrgsNV354t7bXyMW3W8
QoyjG+Np8+K9rT5OcV1y7ud5fiL6Ma/HfNFT5scpmBufGX4qajwvPtfU/rfUdVyS301C5s8TcqK3
oNvq5bO6SalzR3V1fLTNjM88NWIeTOgAHNN8kduSXt3lXe0Z+S4sPyztnvd1DjEznqOv6DW1GNcQ
j7sxmWOekB7N8TiLV3Pj4/y/k7PVgvKE7lEb1wvDZ/GWz33/iFseFlenilw1cSnSGNdRPhXwDYLC
ed3Su2b/BpFvYbdcNfHeNVXI1K5c84XE63vGyKsVvEq0wlwxe81LzqTheB+uFfPpT+Njk8f99/Cy
Ni51uiRgjRilVm9pOKu3NIveUi3whpN6R0JvaxDpDcn+eS4vquP8aBC1tTh+Jk8au0koy97pHR/r
Vgk34rfx/zlvWHwdtjfZeL7/Um3uqjzWeIwePZYS7PHmH/C26KaU0KKb0sI3bL2B/v51jFhwPd5m
NeFtZiPeZsxOCV05u3J24+yW2dKSGdEZ7TPYjNktc9Ob5/sDPaZNx1tdA95q6/2hrNqW+rX199Uf
qj9arxTWV9Y31T9X314vP1cXbWhvYLX1y+ekp81LuXFYWvZCvCh97Xcs8nw7i7QvZxFzn2orXfsh
7PzwuQ/puheg6b2d79F3nmORvZ3t7MvH7PbSNvbZY60s0sb+Jn462x+PpmaUclfSlJ0YiO6kkZ3L
U7M2b1EiW1rlyIY7eFKG3j93/R1y5I475cidrUpkUyuNNLa2tK5tZTtbgeP+Dwv3383Cv0oR8y++
lNLnnqWR3+C181lo33V4F92FWHcuh8jPlyuRNXitXK1EVuMvJ2FJJCJI6L8kK1y6pIVGbrmZRm5u
USKL8WpBoNvwWoHXMryW4jVuOaxbLgr+1HzEZisNlQRSiwOBQQHvwIC7KOAcENAuDij/X1vXrtMw
DEXtpEALSVwCEYUopWpQqeoKEEggoSuBUjplSUuHmEo8JHaGsMOClIXHH/QXbrYwsbLxCXwCnwA2
dOBl6fr6nHuPLd3Vrw1HX3fImtNYtZqrrMWtNmd131rxWXXZqi0zVp41StMzhrrUrxcmDEI1ddqB
35MR0dQT+xf6SH/RJ/bYCbtiI/bEXtkbe2fFEmO06FLPrEwtmU55wbQL82YbWtCEBqxAHWpQBRcq
4IANDEowCToQiLYo2iEJBwHOUekPA9ziYa7X+rjJQ5yKhnFG6Z2QLGppTskAC2muSWd3joZxThdV
+MZ9JJQSDE9vbkWmkQBpiv5hrNx+L8ZampfJIM40GgghcCeMYpUluIfn6svZa0/gpho8eIKEuNtD
1w/4f+04OU6S5DuTNRtdbHXPsN09PfiRS5PLP/rLLy35HaJcTvvJdWJXKOMcK+jLgkjRWDVe+LNP
spIqUNQPQiz2pUVDXPIleJZgWwLDV5slH75TIDAKZW5kc3RyZWFtCmVuZG9iagoKMjQgMCBvYmoK
MTkxOTMKZW5kb2JqCgoyNSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0JB
QUFBQStBbGJhbnlBTVQKL0ZsYWdzIDQKL0ZvbnRCQm94Wy0yMjIgLTMwNiAxMDcyIDEwMzddL0l0
YWxpY0FuZ2xlIDAKL0FzY2VudCA5MDUKL0Rlc2NlbnQgLTIxMQovQ2FwSGVpZ2h0IDEwMzcKL1N0
ZW1WIDgwCi9Gb250RmlsZTIgMjMgMCBSPj4KZW5kb2JqCgoyNiAwIG9iago8PC9MZW5ndGggNTE1
L0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nF2Uy46bQBBF93wFy8liBP0APJKF5LHHkhd5
KJ58AIa2B2kMCOOF/z5961YSKQtbh6b69qHpItsedoehX7If89gew5Ke+6Gbw228z21IT+HSD4mx
ade3i17Jf3ttpiSLc4+P2xKuh+E8rtdJ9jPeuy3zI33adOMpfEmy73MX5n64pE+/tsd4fbxP02e4
hmFJ86Su0y6cY87XZvrWXEMms54PXbzdL4/nOOVfwftjCqmVa0OVduzCbWraMDfDJSTrPK/T9X5f
J2Ho/rtXrjjldG4/mjmWmlia587Uka2wfwE7cgH2woUHFxwvwaWw3YEr5lTgFdmCX1iTgzfClYy/
Cpey7pYs+TuyrPvG+hV4T0aNyZnvwOqPfEP/cgOmf4UcQ/9yC6a/Q6ahfwEfQ/9CMulfCtO/knz6
e3Ggv4e/UX/siVF/yae/lXXVH5mW/iX22dLfyzj9C6xl6V++gdV/D6a/Faa/R76lfyWZ6o/3YtUf
bpb+Dv6W/k7G1R/vztLfwt+qv2SqP2qc+mPfHP2tjNPfYf+dnh84OPV/Bev5kbnwt7mBv6vIUq/n
B8/o9PzA2dG/gI/T/Zca+hd4147+hYzT38u69Pd4Lk9/D2dP/0JY/ZHj6W/xfr2efyMNpZ2D1kLv
/2nZtL3Pc2xX+UBIn6JD+yH8/YZM44RZ8vsNeOQKfAplbmRzdHJlYW0KZW5kb2JqCgoyNyAwIG9i
ago8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9CYXNlRm9udC9CQUFBQUErQWxiYW55QU1U
Ci9GaXJzdENoYXIgMAovTGFzdENoYXIgNjgKL1dpZHRoc1s3NTAgNTU2IDI3NyA2NjYgNjEwIDYx
MCAzMzMgNTU2IDU1NiAyNzcgMzMzIDU1NiA1NTYgNTU2IDUwMCAyNzcKNTU2IDU1NiAyMjIgNTU2
IDIyMiA1NTYgNzIyIDY2NiA1MDAgNTU2IDcyMiA2NjYgMjc3IDU1NiAyNzcgNTAwCjIyMiA3MjIg
NjY2IDU1NiA1NTYgMjc3IDU1NiA1MDAgODMzIDUwMCA1NTYgNTU2IDU1NiAzMzMgMzMzIDcyMgo1
NTYgMTkwIDI3NyA4MzMgNTAwIDY2NiAzMzMgMzMzIDU1NiA1NTYgNjY2IDc3NyA3MjIgNTU2IDY2
NiA3MjIKNzc3IDk0MyA1NTYgMjc3IDc3NyBdCi9Gb250RGVzY3JpcHRvciAyNSAwIFIKL1RvVW5p
Y29kZSAyNiAwIFIKPj4KZW5kb2JqCgoyOCAwIG9iago8PC9GMSAyNyAwIFIvRjIgMjIgMCBSCj4+
CmVuZG9iagoKMjkgMCBvYmoKPDwvRm9udCAyOCAwIFIKL1hPYmplY3Q8PC9JbTQgNCAwIFI+Pgov
UHJvY1NldFsvUERGL1RleHQvSW1hZ2VDL0ltYWdlSS9JbWFnZUJdCj4+CmVuZG9iagoKMSAwIG9i
ago8PC9UeXBlL1BhZ2UvUGFyZW50IDE3IDAgUi9SZXNvdXJjZXMgMjkgMCBSL01lZGlhQm94WzAg
MCA3MjAgNTQwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9D
b250ZW50cyAyIDAgUj4+CmVuZG9iagoKNSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDE3IDAg
Ui9SZXNvdXJjZXMgMjkgMCBSL01lZGlhQm94WzAgMCA3MjAgNTQwXS9Hcm91cDw8L1MvVHJhbnNw
YXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyA2IDAgUj4+CmVuZG9iagoKOCAw
IG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDE3IDAgUi9SZXNvdXJjZXMgMjkgMCBSL01lZGlhQm94
WzAgMCA3MjAgNTQwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+
Pi9Db250ZW50cyA5IDAgUj4+CmVuZG9iagoKMTEgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAx
NyAwIFIvUmVzb3VyY2VzIDI5IDAgUi9NZWRpYUJveFswIDAgNzIwIDU0MF0vR3JvdXA8PC9TL1Ry
YW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMTIgMCBSPj4KZW5kb2Jq
CgoxNCAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDE3IDAgUi9SZXNvdXJjZXMgMjkgMCBSL01l
ZGlhQm94WzAgMCA3MjAgNTQwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9J
IHRydWU+Pi9Db250ZW50cyAxNSAwIFI+PgplbmRvYmoKCjMwIDAgb2JqCjw8L0NvdW50IDUvRmly
c3QgMzEgMCBSL0xhc3QgMzUgMCBSCj4+CmVuZG9iagoKMzEgMCBvYmoKPDwvQ291bnQgMC9UaXRs
ZTxGRUZGMDA2NTAwNjQwMDc1MDA3MjAwNkYwMDYxMDA2RDAwMjAwMDUzMDA3NDAwNjEwMDcyMDA3
NDAwNzMwMDY1MDA2OTAwNzQwMDY1PgovRGVzdFsxIDAgUi9YWVogMCA1NDAgMF0vUGFyZW50IDMw
IDAgUi9OZXh0IDMyIDAgUj4+CmVuZG9iagoKMzIgMCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZG
MDA1NzAwNjkwMDZDMDA2QzAwNkIwMDZGMDA2RDAwNkQwMDY1MDA2RT4KL0Rlc3RbNSAwIFIvWFla
IDAgNTQwIDBdL1BhcmVudCAzMCAwIFIvUHJldiAzMSAwIFIvTmV4dCAzMyAwIFI+PgplbmRvYmoK
CjMzIDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTQwMDY1MDA2OTAwNkMwMDZFMDA2NTAw
NjgwMDZEMDA2NTAwNzI+Ci9EZXN0WzggMCBSL1hZWiAwIDU0MCAwXS9QYXJlbnQgMzAgMCBSL1By
ZXYgMzIgMCBSL05leHQgMzQgMCBSPj4KZW5kb2JqCgozNCAwIG9iago8PC9Db3VudCAwL1RpdGxl
PEZFRkYwMDQyMDA2NTAwNzIwMDY1MDA2MzAwNjgwMDc0MDA2OTAwNjcwMDc0MDA2NTAwMjAwMDQ5
MDA2RTAwNzMwMDc0MDA2OTAwNzQwMDc1MDA3NDAwNjkwMDZGMDA2RTAwNjUwMDZFPgovRGVzdFsx
MSAwIFIvWFlaIDAgNTQwIDBdL1BhcmVudCAzMCAwIFIvUHJldiAzMyAwIFIvTmV4dCAzNSAwIFI+
PgplbmRvYmoKCjM1IDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNDUwMDZFMDA2NDAwNjU+
Ci9EZXN0WzE0IDAgUi9YWVogMCA1NDAgMF0vUGFyZW50IDMwIDAgUi9QcmV2IDM0IDAgUj4+CmVu
ZG9iagoKMTcgMCBvYmoKPDwvVHlwZS9QYWdlcwovUmVzb3VyY2VzIDI5IDAgUgovTWVkaWFCb3hb
IDAgMCA1OTUgODQyIF0KL0tpZHNbIDEgMCBSIDUgMCBSIDggMCBSIDExIDAgUiAxNCAwIFIgXQov
Q291bnQgNT4+CmVuZG9iagoKMzYgMCBvYmoKPDwvVHlwZS9DYXRhbG9nL1BhZ2VzIDE3IDAgUgov
T3BlbkFjdGlvblsxIDAgUiAvWFlaIG51bGwgbnVsbCAwXQovT3V0bGluZXMgMzAgMCBSCj4+CmVu
ZG9iagoKMzcgMCBvYmoKPDwvQ3JlYXRvcjxGRUZGMDA0OTAwNkQwMDcwMDA3MjAwNjUwMDczMDA3
Mz4KL1Byb2R1Y2VyPEZFRkYwMDRGMDA3MDAwNjUwMDZFMDA0RjAwNjYwMDY2MDA2OTAwNjMwMDY1
MDAyRTAwNkYwMDcyMDA2NzAwMjAwMDMyMDAyRTAwMzQ+Ci9DcmVhdGlvbkRhdGUoRDoyMDA4MDcz
MDEzMjkyMCswMicwMCcpPj4KZW5kb2JqCgp4cmVmCjAgMzgKMDAwMDAwMDAwMCA2NTUzNSBmIAow
MDAwMDMzNzM4IDAwMDAwIG4gCjAwMDAwMDAwMTkgMDAwMDAgbiAKMDAwMDAwMDQ3NSAwMDAwMCBu
IAowMDAwMDAwNDk1IDAwMDAwIG4gCjAwMDAwMzM4ODIgMDAwMDAgbiAKMDAwMDAwODg1NiAwMDAw
MCBuIAowMDAwMDA5NjEyIDAwMDAwIG4gCjAwMDAwMzQwMjYgMDAwMDAgbiAKMDAwMDAwOTYzMiAw
MDAwMCBuIAowMDAwMDEwNjAzIDAwMDAwIG4gCjAwMDAwMzQxNzAgMDAwMDAgbiAKMDAwMDAxMDYy
NCAwMDAwMCBuIAowMDAwMDExMzI5IDAwMDAwIG4gCjAwMDAwMzQzMTYgMDAwMDAgbiAKMDAwMDAx
MTM1MCAwMDAwMCBuIAowMDAwMDExNzE2IDAwMDAwIG4gCjAwMDAwMzUyODkgMDAwMDAgbiAKMDAw
MDAxMTczNyAwMDAwMCBuIAowMDAwMDEyNDEwIDAwMDAwIG4gCjAwMDAwMTI0MzEgMDAwMDAgbiAK
MDAwMDAxMjYyMiAwMDAwMCBuIAowMDAwMDEyOTIyIDAwMDAwIG4gCjAwMDAwMTMwODcgMDAwMDAg
biAKMDAwMDAzMjM2NyAwMDAwMCBuIAowMDAwMDMyMzkwIDAwMDAwIG4gCjAwMDAwMzI1ODIgMDAw
MDAgbiAKMDAwMDAzMzE2NyAwMDAwMCBuIAowMDAwMDMzNTk2IDAwMDAwIG4gCjAwMDAwMzM2Mzkg
MDAwMDAgbiAKMDAwMDAzNDQ2MiAwMDAwMCBuIAowMDAwMDM0NTE4IDAwMDAwIG4gCjAwMDAwMzQ2
ODMgMDAwMDAgbiAKMDAwMDAzNDgyOCAwMDAwMCBuIAowMDAwMDM0OTczIDAwMDAwIG4gCjAwMDAw
MzUxNzkgMDAwMDAgbiAKMDAwMDAzNTQxNSAwMDAwMCBuIAowMDAwMDM1NTE3IDAwMDAwIG4gCnRy
YWlsZXIKPDwvU2l6ZSAzOC9Sb290IDM2IDAgUgovSW5mbyAzNyAwIFIKL0lEIFsgPDQ1ODI4NkRC
NDczQUNDNjQ0RkQyRjEwMTZFOURBRjkwPgo8NDU4Mjg2REI0NzNBQ0M2NDRGRDJGMTAxNkU5REFG
OTA+IF0KL0RvY0NoZWNrc3VtIC9CNDQ5N0YzMzU3NTUzNzQzNzUyQjBFMDFBQTYyMDExMQo+Pgpz
dGFydHhyZWYKMzU3MDgKJSVFT0YK

--=_4ee9yxyk2800--


--
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, 28 Jul 2008 15:47:37 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Bernard Aboba'" <[e-mail]>
Subject: RE: IETF 72: Request for Slides
Date: Mon, 28 Jul 2008 11:46:42 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <1F16E99510C441E8920124D8713C1392@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjwyKFHLmwRXFyMRlyMS1nE1RgYLwAACvaw

> If you have slides to present at IETF 72, please send them to me
> ([e-mail]> ASAP, so we can get them loaded on the 
> server.

Please copy the slides to Dave Nelson, ([e-mail]) as well.
Thanks!

Regards,

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, 28 Jul 2008 15:40:56 +0000
Date: Mon, 28 Jul 2008 08:40:04 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: IETF 72: Request for Slides
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

If you have slides to present at IETF 72, please send them to me 
([e-mail]> ASAP, so we can get them loaded on the server. 

--
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, 28 Jul 2008 15:37:15 +0000
Date: Mon, 28 Jul 2008 08:36:18 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This is a reminder of the RADEXT WG Last Call on "Extended 
RADIUS Attributes", prior to requesting that the IESG publish it as a Proposed Standard. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt
 
WG Last Call was originally to have completed on July 24, 2008.   
However, due to lack of response to the RADEXT WG last call, 
we will be extending the WG last call to August 10, 2008.  Please 
review the document and post your comments to the RADEXT WG mailing list 
([e-mail]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

--
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, 28 Jul 2008 15:33:47 +0000
Date: Mon, 28 Jul 2008 08:32:49 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This is a reminder of the ongoing RADEXT WG Last Call on "Crypto-Agility 
Requirements for RADIUS" prior to requesting that the IESG publish it as 
an Informational RFC. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt
 
WG Last Call will last until August 10, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([e-mail]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

--
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, 28 Jul 2008 15:33:07 +0000
Date: Mon, 28 Jul 2008 08:31:35 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: Take Three: RADEXT WG Agenda at IETF 72
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

9:00 - 9:10  Preliminaries
 Blue Sheets
 Note Takers
 Jabber Scribe
 Agenda bashing
 Document Status

Completed WG Last Call (20 minutes)

Extended RADIUS Attributes, Glen Zorn, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt

RADIUS Design Guidelines, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-04.txt

Transport Documents (40 minutes)

TCP Transport, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-dekok-radext-tcp-transport-00.txt

Status Server, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-00.txt

RADIUS over DTLS, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-01.txt

RADSEC, Stefan Winter, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-00.txt

RADIUS Cryptoagility (20 minutes)

RADIUS Cryptoagility requirements, David Nelson, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt

RADIUS Confidentiality, Glen Zorn, 10 minutes
http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-11.txt

Additional Documents (30 minutes)

RADIUS Attributes for IEEE 802 Networks, Bernard Aboba, 10 minutes
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-08.txt

Problem Statement and Requirements for Diameter/Radius Prefix 
Authorization Application, B. Sarikaya, 10 minutes
http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt

IPv6 Attributes for DHCP Networks, B. Lourdelet, 10 minutes
http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-00.txt

--
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, 21 Jul 2008 02:49:55 +0000
Date: Sun, 20 Jul 2008 19:48:39 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: Take Two: RADEXT WG Agenda at IETF 72
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

9:00 - 9:10  Preliminaries
 Blue Sheets
 Note Takers
 Jabber Scribe
 Agenda bashing
 Document Status

Completed WG Last Call (20 minutes)

Extended RADIUS Attributes, Glen Zorn, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt

RADIUS Design Guidelines, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-04.txt

Transport Documents (40 minutes)

TCP Transport, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-dekok-radext-tcp-transport-00.txt

Status Server, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-00.txt

RADIUS over DTLS, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-01.txt

RADSEC, Stefan Winter, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-00.txt

RADIUS Cryptoagility (20 minutes)

RADIUS Cryptoagility requirements, David Nelson, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt

RADIUS Confidentiality, Glen Zorn, 10 minutes
http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-11.txt

Additional Documents (20 minutes)

RADIUS Attributes for IEEE 802 Networks, Bernard Aboba, 10 minutes
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-08.txt

IPv6 Attributes for DHCP Networks, B. Lourdelet, 10 minutes
http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-00.txt

--
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: Sun, 20 Jul 2008 19:36:35 +0000
Date: Sun, 20 Jul 2008 12:35:44 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This is a reminder of the ongoing RADEXT WG Last Call on "Crypto-Agility 
Requirements for RADIUS" prior to requesting that the IESG publish it as 
an Informational RFC. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt
 
WG Last Call will last until August 10, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([e-mail]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 



--
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: Sun, 20 Jul 2008 19:35:25 +0000
Date: Sun, 20 Jul 2008 12:34:28 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes" 
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This is a reminder of the ongoing RADEXT WG Last Call on "Extended RADIUS 
Attributes" prior to requesting that the IESG publish it as a Proposed 
Standard. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt
 
WG Last Call will last until July 24, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([e-mail]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 



--
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: Sun, 20 Jul 2008 19:33:41 +0000
Date: Sun, 20 Jul 2008 12:32:11 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: Issue 271:  IETF Last Call Comments on RADIUS GEOPRIV Document
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

In order to make forward progress on resolving the RADIUS GEOPRIV IETF 
Last Call comments, I am reposting Glen's original review to the RADEXT WG 
list. 

Suggested text changes to resolve these comments are welcome.  

=======================================================================
Issue 271: Review
Submitter name: Glen Zorn
Submitter email address: [e-mail]
Date first submitted: April 27, 2008
Reference: http://www.ietf.org/mail-archive/web/ietf/current/msg51649.html
Document: LOCATION-09
Comment type:  Technical
Priority: S
Section:  Various
Rationale/Explanation of issue:

In the description of the Operator-Name Attribute (section 3.1), the
discussion of the encoding of a name in the "REALM" namespace is
incomplete, at best. First, there is no discussion of the steps (if
any) to be taken if the toASCII conversion fails in the case of a realm
name containing non-ASCII characters. In any case, however, it is not
possible to encapsulate a maximum-length FQDN in a RADIUS attribute
because the maximum length of a RADIUS Attribute data payload is 253
octets, while the maximum length of an ASCII FQDN is 255 octets.
Furthermore, due to the addition of the ACE prefix(es) as a result of
the toASCII conversion process, the actual length of a converted realm
name may be considerably less than 253 octets. The conventional way to
deal with type of problem in RADIUS would be to split the offending
string up into multiple attributes; however, the formatting of the
Operator-Name attribute into distinct sub-fields would seem to preclude
the use of that technique. I suggest that (in order of preference)
a) the Operator-Name Attribute be split into separate
Operator-Namespace and Operator-Name Attributes with instructions
included on handling too-long FQDNs
b) the attribute be redefined in terms of the new Extended
RADIUS Attributes
(http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribut
es-03.txt)
or at the least
c) text be added noting the actual restrictions on realm name
length

Section 3.3, paragraph 2 doesn't make a lot of sense to me: suggest
rewriting it in less florid if more precise language. For example,
something like this: "In order to enable the on-demand mid-session
location delivery method, the RADIUS server MUST return an instance of
the Requested-Location-Info Attribute with the 'FUTURE_REQUESTS' flag
set and instances of the Basic-Location-Policy-Rules and
Extended-Location-Policy-Rules Attributes in the Access-Accept message
for the session. Upon receipt of a CoA-Request message containing a
Service-Type Attribute with value "Authorize Only" for the same session,
the NAS MUST include location information and echo the previously
received Basic-Location-Policy-Rules and Extended-Location-Policy-Rules
Attributes in the subsequent Access-Request message."

Section 4.2 says:

Length:

>= 21

String:

This field is at least two octets in length, and the format
is shown below. The data type of this field is string.

Suggestion: change "at least two" to "at least 19". Later in the same
section, it says:

Method (variable):

Describes the way that the location information was
determined. The values are registered with the 'method' Tokens
registry by RFC 4119. The data type of this
field is a string.

Does "registered with the 'method' tokens" mean "along with the token
values in the same registry" or something else? I _think_ that what the
authors are trying to say is "This field MUST contain the value of
exactly one IANA-registered 'method' token [RFC4119]." If so, maybe
they should.

Section 4.2.1 says "The location format is based on the encoding format
defined in Section 3.1 of [RFC4776] whereby the first 3 octets (i.e.,
the code for this DHCP option, the length of the DHCP option, and the
'what' element are not included) are not put into the Location field of
the above-described RADIUS Location-Data Attribute." I don't really
understand: does this mean that 'the location format is identical to
that defined in RFC 4776 with the exception that the first three octets
are omitted'? In any case, RFC 4776 say in the last paragraph of
section 1:

The DHCPv4 long-options mechanism described in RFC 3396 [8] MUST be
used if the civic address option exceeds the maximum DHCPv4 option
size of 255 octets.

My comments on are similar to those on the Operator-Name Attribute
above; this case is a little more complicated, due to the use of the
Index field to associate this attribute with the corresponding
Location-Information attribute (there seems to be an implicit assumption
that these always come in pairs).

Section 4.3 says: "Implementations SHOULD treat this attribute as
undistinguished octets." In context, this statement doesn't make sense
in at least two ways. First, I have no idea how any implementation can
treat an entire attribute as undistinguished octets, since at least the
Type and Length fields have to be distinguished. Maybe the authors mean
that the String field of the attribute should be treated in this way,
but that doesn't seem reasonable, either, because that field is itself
formatted into two distinct fields.

Section 4.4 says "The Basic-Location-Policy-Rules Attribute MAY be sent
in an Access-Request, Access-Accept, an Access-Challenge, an
Access-Reject, a Change-of-Authorization and in an Accounting-Request
message." but RFC 2865 says (section 2, paragraph 7) "If any condition
is not met, the RADIUS server sends an "Access-Reject" response
indicating that this user request is invalid. If desired, the server
MAY include a text message in the Access-Reject which MAY be displayed
by the client to the user. No other Attributes (except Proxy-State) are
permitted in an Access-Reject." This being the case, it seems like
there should be an "Updates: 2865" in the first page header of the
draft.

The Location-Capable (section 4.6) attribute can take only a "True"
value (presumably the lack of client ability would be signified by the
absence of the Location-Capable Attribute in the Access-Request). This
puzzles me a bit: isn't it possible that a NAS might be capable of
discovering (& therefore, communicating) one or a few type of location
data and not others? For example, it seems rather likely that a dial-up
NAS might be capable of conveying its own civic location but not the
geospatial location of the remote node. I guess what I'm asking is if
there isn't a need for a little greater granularity here.

The discussion of the Requested-Location-Info Attribute in section 4.7
is remarkably soft and fluffy, attributing such things as "wants" and
"desires" to servers and clients. To the best of my knowledge, software
does not (yet) display needs, let alone desires. This would just be a
little annoying except that the warm fuzziness spills over into the
actual specification of what are presumably requirements. For example:

If the RADIUS server wants to dynamically decide on a per-request
basis to ask for location information from the RADIUS client then the
following cases need to be differentiated. If the RADIUS client and
the RADIUS server have agreed out-of-band to mandate the transfer of
location information for every network access authentication request
then the processing listed below is not applicable.

o If the RADIUS server requires location information for computing
the authorization decision and the RADIUS client does not provide
it with the Access-Request message then the Requested-Location-
Info Attribute is attached to the Access-Challenge with a hint
about what is required. Two cases can be differentiated:

1. If the RADIUS client sends the requested information then the
RADIUS server can process the location-based attributes.

2. If the RADIUS server does not receive the requested
information in response to the Access-Challenge (including the
Requested-Location-Info Attribute) then the RADIUS server may
respond with an Access-Reject message with an Error-Cause
Attribute (including the "Location-Info-Required" value).

In the case of #1, "the RADIUS server can process the location-based
attributes". This seems fairly obvious, but just because it _can_
doesn't mean that it _will_; it might not (presumably based upon its
"desires" ;-). Must the server process the location information? If
so, the document should say so. Similarly in case #2, "the RADIUS
server may respond with an Access-Reject message with an Error-Cause
Attribute (including the "Location-Info-Required" value)." If it "may"
then it may also not; just guessing (since there are supposedly only two
cases and the information is stated to be required in order to process
the authorization request) it seems to me that the authors really mean
"MUST" in both cases but that is not clear at all.

o If the RADIUS server would like location information in the
Accounting-Request message but does not require it for computing
an authorization decision then the Access-Accept message MUST
include a Required-Info Attribute. This is typically the case
when location information is used only for billing. The RADIUS
client SHOULD attach location information, if available, to the
Accounting-Request (unless authorization policies dictate
something different).

Once again the server exhibits desire, but this paragraph begs another
question: if the data referred to by the Requested-Location-Info
Attribute is actually required and the Required-Info Attribute signifies
data that is optional, why are they named the way they are?

Change "8.3. New Registry: Location Capable Attribute" to "8.3. New
Registry: Location-Capable Attribute".

Many references are out of date or incorrect.
Given that Bernard is a co-author, it may be a bit excessive to mention
him (thrice!) in the Acknowledgements section _and_ in the Contributors
section as well ;-).

In section A.1, paragraph 1 change "This section discusses the privacy
implication for making location information available to other
entities." to "This section discusses the privacy implications of making
location information available to other entities."

Last but not least, this draft fairly universally violates several of
the guidelines given in
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt, in
particular those regarding the use of tags to associate different
attributes (called "Index" in this document) and the creation of
"complex" attributes. I realize that the RADIUS design guidelines
document is just an Internet-Draft, but it is a radext WG document & has
been under construction for some period of time. More important than
the standardization status of the document is the question of whether
the guidelines make sense; if so, then it may not be such a good idea to
so completely ignore them; if not, then maybe radext should rethink this
work item (especially since a co-chair of that WG is also a co-author of
the document under review).

[BA] Can you provide specific instances in which this
document violates "Design Guidelines" (applying the tests in
Appendix A?.

OK. As you noted above, the Design Guidelines say

If the RADIUS Server simply passes the contents of an attribute to
some non-RADIUS portion of the network, then the data is opaque, and
SHOULD be defined to be of type String. A concrete way of judging
this requirement is whether or not the attribute definition in the
RADIUS document contains delineated fields for sub-parts of the data.
If those fields need to be delineated in RADIUS, then the data is not
opaque, and it SHOULD be separated into individual RADIUS attributes.

But section 4.7 of the draft under review says

o If the RADIUS server requires location information for computing
the authorization decision and the RADIUS client does not provide
it with the Access-Request message then the Requested-Location-
Info Attribute is attached to the Access-Challenge with a hint
about what is required. Two cases can be differentiated:

1. If the RADIUS client sends the requested information then the
RADIUS server can process the location-based attributes.

2. If the RADIUS server does not receive the requested
information in response to the Access-Challenge (including the
Requested-Location-Info Attribute) then the RADIUS server may
respond with an Access-Reject message with an Error-Cause
Attribute (including the "Location-Info-Required" value).

The RADIUS server "requires location information for computing the
authorization decision". How can it make a decision based upon data
that it cannot understand? It doesn't have to because "[i]f the RADIUS
client sends the requested information then the RADIUS server can
process the location-based attributes". Of course, "process" can mean
many things and if these attributes are opaque then "process" might mean
just writing the data to a file or forwarding it over some unspecified
interface to another entity. So maybe the RADIUS server is making the
decision based just upon the fact that it received a
Location-Information/Location-Data pair in the new Access-Request (along
with the echoed Attributes). The problem is that the RADIUS server
didn't request just any old location data; it requested a very specific
set of data (in the example later in section 4.7 it is the civic
location of the user). AFAICT, the only way that the RADIUS server can
tell if it has actually received the information it requested is to
examine the Code and Entity sub-fields of the returned
Location-Information Attribute and check that there is an associated
instance of the Location-Data Attribute by matching the Index fields of
the Attributes. Remember that this check for the requested information
takes place before the RADIUS server processes the data; this suggests
to me that these fields "need to be delineated in RADIUS" and therefore
"the data is not opaque, and it SHOULD be separated into individual
RADIUS attributes". Further, section A.2.2 of the Design Guidelines
asks the (how I wish it was a musical ;-) question:

Does the attribute define a complex data type for purposes other than
authentication or security? If so, this data type SHOULD be replaced
with simpler types, as discussed above in Section A.2.1.

Neither the Location-Information nor the Location-Data Attributes seem
to be used for authentication (authorization != authentication) or
security. Section A.1.3 of the same document says (WRT Attributes
encapsulating complex data types):

Does the attribute encapsulate an existing data structure defined
outside of the RADIUS specifications? Can the attribute be treated
as opaque data by RADIUS servers (including proxies?) If both
questions can be answered affirmatively, a complex structure MAY be
used in a RADIUS specification.

The specification of the attribute SHOULD define the encapsulating
attribute to be of type String. The specification SHOULD refer to an
external document defining the structure. The specification SHOULD
NOT define or describe the structure[...]

However, section 4.2 of draft-ietf-geopriv-radius-lo describes the
structure of the Location-Information Attribute in detail; the question
of opacity was dealt with above.

WRT the Index fields of the Location-Information and Location-Data
Attributes, the fact that they are both mandatory and large avoids many
of the drawbacks mentioned WRT tags in the Design Guidelines document,
nevertheless that document does state 'new attributes SHOULD use the
grouping method described in
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-03.txt'.

Additional discussion is available here:
http://www.ietf.org/mail-archive/web/ietf/current/msg51657.html
http://www.ietf.org/mail-archive/web/ietf/current/msg51686.html
http://www.ietf.org/mail-archive/web/ietf/current/msg51691.html

--
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, 14 Jul 2008 15:18:55 +0000
Date: Mon, 14 Jul 2008 08:17:54 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: PROTO WRITEUP: RADIUS Authorization for NAS Management
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Title:  RADIUS Authorization for NAS Management
I-D:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-05.txt
 
Status: Proposed Standard
 
Response to template:
 
1) Have the chairs personally reviewed this version of the ID and do
   they believe this ID is sufficiently baked to forward to the IESG
   for publication?
 
Yes.
 
2) Has the document had adequate review from both key WG members and
   key non-WG members? Do you have any concerns about the depth or
   breadth of the reviews that have been performed?
 
Yes. The ID has had 2 working group last calls.
 
3) Do you have concerns that the document needs more review from a
   particular (broader) perspective (e.g., security, operational
   complexity, someone familiar with AAA, etc.)?
 
No concerns.  The document has been reviewed both by the ISMS WG
as well as by RADEXT WG. 
 
4) Do you have any specific concerns/issues with this document that
   you believe the ADs and/or IESG should be aware of? For example,
   perhaps you are uncomfortable with certain parts of the document,
   or whether there really is a need for it, etc., but at the same
   time these issues have been discussed in the WG and the WG has
   indicated it wishes to advance the document anyway.
 
No.
 
5) How solid is the WG consensus behind this document?  Does it
   represent the strong concurrence of a few individuals, with others
   being silent, or does the WG as a whole understand and agree with
   it?
 
There is solid consensus behind this document.  7 people other 
than the author have commented on various aspects of the 
document. The issues raised, available for inspection at
http://www.drizzle.com/~aboba/RADEXT/, were resolved in the -04
version of the document.
 
6) Has anyone threatened an appeal or otherwise indicated extreme
   discontent?  If so, please summarize what are they upset about.
 
No.
 
7) Have the chairs verified that the document adheres to _all_ of the
   ID nits?  (see http://www.ietf.org/ID-nits.html).
 
Yes. An output of the run on this revision of the ID by the online nits
checker:
 
idnits 2.08.10 
 
tmp/draft-ietf-radext-management-authorization-05.txt:
 
  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
----------------------------------------------------------------------------
     No issues found here.
  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
----------------------------------------------------------------------------
     No issues found here.
  Checking nits according to http://www.ietf.org/ID-Checklist.html:
----------------------------------------------------------------------------
     No issues found here.
  Miscellaneous warnings:
----------------------------------------------------------------------------
     No issues found here.
  Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
     (See RFCs 3967 and 4897 for information about using normative 
references
     to lower-maturity documents in RFCs)
 
     No issues found here.
     No nits found.
--------------------------------------------------------------------------------
 
8) Does the document a) split references into normative/informative,
   and b) are there normative references to IDs, where the IDs are not
   also ready for advancement or are otherwise in an unclear state?
   (Note: the RFC editor will not publish an RFC with normative
   references to IDs, it will delay publication until all such IDs are
   also ready for publication as RFCs.)
 
The document splits references into normative and informative ones.
There are no normative references to IDs.
 
9) For Standards Track and BCP documents, the IESG approval
   announcement includes a writeup section with the following
   sections:
 
   - Technical Summary
 
   This document specifies RADIUS attributes for authorization and
   service provisioning of Network Access Server (NAS) management.
   Both local and remote management are supported, with granular access 
   rights and management privileges.  Specific provisions are made for 
   remote management via framed management protocols, and for 
   specification of a protected transport protocol.  
 
    - Working Group Summary
 
    There have been 2 WGLCs on the document.  Much of the discussion on
    the document has centered around the model for provisioning of 
    protected transports, as well as the different remote administration
    mechanisms (secure and insecure) to be supported.  There has also
    been discussion of the relationship between Framed Management 
    (introduced in this draft) and the pseudo-TTY management model 
    supported in RFC 2865.

--
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, 14 Jul 2008 14:46:59 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-management-authorization-05.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 14 Jul 2008 07:45:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.


	Title           : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management
	Author(s)       : D. Nelson, G. Weber
	Filename        : draft-ietf-radext-management-authorization-05.txt
	Pages           : 24
	Date            : 2008-07-14

This document specifies Remote Authentication Dial-In User Service
(RADIUS) attributes for authorizing management access to a Network
Access Server (NAS).  Both local and remote management are supported,
with granular access rights and management privileges.  Specific
provisions are made for remote management via framed management
protocols, and for management access over a secure transport
protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-management-authorization-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--

--
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: Sun, 13 Jul 2008 21:37:44 +0000
Date: Sun, 13 Jul 2008 14:36:09 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: Comment on draft-ietf-radext-design-04.txt, Appendix A
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

There are a few cases where the text in Appendix A is not backed by 
discussion in the rest of the document, and vice versa.  

A.4

      * Extending the RADIUS packet length limitation past 4096 octets.
        A multi-packet sequence of Access-Request / Access-Challenge
        SHOULD be used instead.  If that is not possible, then a method
        other than RADIUS SHOULD be used to transport the data.

[BA] Generally, the Design Guidelines in Appendix A are supported by text 
elsewhere in the document.  This one has no corresponding discussion, and 
it seems to me that there are enough issues so  that adding a section for 
such a discussion could be beneficial.  For example:

* Discussion of the length restriction.  As far as I can tell, the length 
restriction is mentioned only in RFC 2865 Section 3.  However, there 
is no normative language or even discussion on how receivers behave 
on encountering larger packets.  Based on this, one thing we can say is 
that a sender cannot by default assume that a receiver will be able to 
handle a RADIUS packet longer than 4096 octets.  So my suggestion 
would be to rephrase the first sentence to state that attribute designers 
SHOULD NOT assume that receivers can handle packets larger than 4096 
octets.  In the discussion section, you can then talk about potential 
alternatives for designers. 

* Support for Access-Challenge.  In looking back at the WG discussion on 
attribute length, the most frequently discussed cases where large 
attributes (and hence large packets) might be required are filter rules 
(e.g. NAS-Filter-Rule).  Unfortunately, Section 3 of RFC 4849 does not 
permit this attribute to be placed in an Access-Challenge.  There are 
quite a few other attributes that also do not permit this usage (although 
most are not large enough to be an issue).   Even if this were to be 
fixed, using a multi-packet sequence would imply that RADIUS attributes in 
a subsequent packet would be concatenated to those in a new packet, as 
opposed to replacing them.  So it seems to me that the attribute would 
need to be specially designed for fragmentation across multi-packet 
sequences.  I don't think we can see that even the Extended Attributes are 
designed for such a use. 

Also, as we discussed in the RADIUS location work, not all NASes are going 
to be "Challenge capable" for a access mechanism.  Does this imply wider 
use of the Challenge-Capable Attribute than what is implied in the RADIUS 
location draft? 

Given all of this, it is not clear to me that the suggestion in the rest 
of the paragraph will be workable in all situations.  

My suggestion is to change A.4 to the following:

A.4. Changes to the RADIUS Protocol

   Does the attribute specification change the RADIUS operational model?
   If so, then another mmethod of achieving the design objectives SHOULD 
   be used.  Potential problems include: 

      * Defining new commands in RADIUS using attributes.  
        The addition of new commands to RADIUS should be handled 
        via allocation of a new command Code, not by use of an attribute.  
        This includes new commands created by overloading attributes such 
        as the Service-Type attribute to define new values that modify
        the functionality of Access-Request packets.
      * Using RADIUS as a transport protocol for data unrelated to
        authentication, authorization or accounting.  Using RADIUS
        to transport authentication methods such as EAP is explicitly
        permited, even if those methods require the transport of 
        relatively large amounts of data.  Transport of opaque
        data relating to AAA is also permitted, as discussed in
        Section 2.1.3.  However, if the specification does not
        relate to AAA, then RADIUS SHOULD NOT be used.  
      * Assuming support for packet lengths greater than 4096 octets.
        Attribute designers cannot assume that RADIUS implementations 
        can successfully handle packets larger than 4096 octets.  
        If a specification could lead to a RADIUS packet larger than
        4096 octets, then alternatives described in Section 3.3 
        SHOULD be considered. 
      * Stateless operation.  The RADIUS protocol is stateless, and 
        documents which require stateful protocol behavior without use of  
        the State Attribute need to be redesigned. 
      * Provisioning of service in an Access-Reject.  This is not 
        permitted.  If limited access needs to be provided, then an
        Access-Accept with appropriate authorizations can be used instead.
      * Lack of user authentication or authorization restrictions.  
        In an authorization check, where there is no demonstration of a 
        live user, confidential data cannot be returned.  Where there 
        is a link to a previous user authentication, the State attribute 
        needs to be present. 
      * Lack of per-packet integrity and authentication. 
        It is expected that documents will support per-packet
        integrity and authentication. 
      * Modification of RADIUS packet sequences.  In RADIUS,
        each request is encapsulated in its own packet, and
        elicits a single response, sent to the requester.  Since
        changes to this paradigm are likely to require major modifications
        to RADIUS client and server implementations, they SHOULD be
        avoided if possible. 

For further details, see Section 3.3. 

Also, change Section 3.3 to the following:

3.3.  RADIUS Operational Model

   The RADIUS operational model includes several assumptions:

      * The RADIUS protocol is stateless; 
      * Provisioning of services is not possible within an Access-Reject; 
      * Distinction between authorization checks and user authentication; 
      * Authentication and integrity protection of RADIUS packets; 
      * RADIUS is a Client/Server protocol;
      * Packet length restriction. 

   While RADIUS server implementations may keep state, the RADIUS
   protocol is stateless, although information may be passed from one
   protocol transaction to another via the State Attribute.  As a
   result, documents which require stateful protocol behavior without
   use of the State Attribute are inherently incompatible with RADIUS as
   defined in [RFC2865], and need to be redesigned.  See [RFC5080]
   Section 2.1.1 for a more in-depth discussion of the use of the State
   Attribute.

   As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is
   to deny access to the requested service.  As a result, RADIUS does
   not allow the provisioning of services within an Access-Reject.
   Documents which include provisioning of services within an Access-
   Reject are inherently incompatible with RADIUS, and need to be
   redesigned.

   As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not
   contain user authentication attributes or a State Attribute linking
   the Access-Request to an earlier user authentication.  Such an
   Access-Request, known as an authorization check, provides no
   assurance that it corresponds to a live user.  RADIUS specifications
   defining attributes containing confidential information (such as
   Tunnel-Password) should be careful to prohibit such attributes from
   being returned in response to an authorization check.  Also,
   [RFC5080] Section 2.1.1 notes that authentication mechanisms need to
   tie a sequence of Access-Request/Access-Challenge packets together
   into one authentication session.  A similar need exists when 
   dynamic authorization is used in as noted in [RFC5176] Section 3.3. 
   The State Attribute is RECOMMENDED for this purpose.  

   While [RFC2865] did not require authentication and integrity
   protection of RADIUS Access-Request packets, subsequent
   authentication mechanism specifications such as RADIUS/EAP [RFC3579]
   and Digest Authentication [RFC5090] have mandated authentication and
   integrity protection for certain RADIUS packets.  [RFC5080] Section
   2.1.1 makes this behavior RECOMMENDED for all Access-Request packets,
   including Access-Request packets performing authorization checks.  It
   is expected that specifications for new RADIUS authentication
   mechanisms will continue this practice.

   The RADIUS protocol as defined in [RFC2865] is a request-response
   protocol spoken between RADIUS clients and servers.  A single RADIUS
   Access-Request packet will solicit in response at most a single
   Access-Accept, Access-Reject or Access-Challenge packet, sent to the
   IP address and port of the RADIUS Client that originated the Access-
   Request.  Similarly, a single Change-of-Authorization (CoA)-Request
   packet [RFC5176] will solicit in response at most a single CoA-ACK or
   CoA-NAK packet, sent to the IP address and port of the Dynamic
   Authorization Client (DAC) that originated the CoA-Request.  A single
   Disconnect-Request packet will solicit in response at most a single
   Disconnect-ACK or Disconnect-NAK packet, sent to the IP address and
   port of the Dynamic Authorization Client (DAC) that originated the
   CoA-Request.  Changes to this model are likely to require major
   revisions to existing implementations and so this is NOT RECOMMENDED.

   The Length field in the RADIUS packet header is defined in [RFC2865]
   Section 3.  It is noted there that the maximum length of a RADIUS
   packet is 4096 octets.  As a result, attribute designers SHOULD NOT
   assume that a RADIUS implementation can successfully process 
   RADIUS packets larger than 4096 octets.  If a situation is envisaged
   where it may be necessary to carry authentication, authorization or
   accounting data in a packet larger than 4096 octets, then one of 
   the following approaches is RECOMMENDED: 

     1. Utilization of a sequence of packets.  In the case of RADIUS
        accounting, this would include a sequence of Accounting-Request
        packets.  This is non-trivial since RADIUS accounting clients 
        would need to be modified to split the attribute stream across 
        multiple Accounting-Requests, and billing servers would need to be 
        modified to re-assemble and interpret the attribute stream. 
        For RADIUS authentication, a sequence of Access-Request/
        Access-Challenge packets would be used; for this to be feasible,
        attribute designers need to enable inclusion of
        attributes that can consume considerable space within 
        Access-Challenge packets.  To maintain compatibility with 
        existing NASes,  either the use of Access-Challenge 
        packets needs to be permissible (as with RADIUS/EAP, defined in 
        [RFC3579]), or support for receipt of an Access-Challenge needs to 
        be indicated by the NAS (as in RADIUS Location [RADIUSLOC]). Also, 
        the specification needs to clearly describe how attribute 
        splitting is signalled and how attributes included within
        the sequence are to be interpretted, without requiring
        stateful operation.  Unfortunately, previous specifications
        have not always exhibited the required foresight.  For example, 
        even though very large filter rules are conceivable, the NAS-Filter-Rule
        Attribute defined in [RFC4849] is not permitted in an 
        Access-Challenge packet, nor is a mechanism specified to
        allow a set of NAS-Filter-Rule attributes to be split across
        an Access-Request/Access-Challenge sequence. 

     2. Utilization of names rather than values.  Where an attribute
        relates to a policy that could conceivably be pre-provisioned
        on the NAS, then the name of the pre-provisioned policy can be 
        transmitted in an attribute, rather than the policy itself, 
        which could be quite large.  An example of this is the Filter-Id 
        Attribute defined in [RFC2865] Section 5.11, which enables a set 
        of pre-provisioned filter rules to be referenced by name. 

     3. Utilization of Packetization Layer Path MTU Discovery
        techniques, as specified in [RFC4821].  As a last resort, where
        the above techniques cannot be made to work, it may be possible
        to apply the techniques described in [RFC4821] to discovery of
        of the maximum supported RADIUS packet size on the path between
        a RADIUS client and a home server.  While such an approach 
        can avoid the complexity of utilization of a sequence of 
        packets, dynamic discovery is likely to be time consuming
        and cannot be guaranteed to work with existing RADIUS 
        implementations.  As a result, this technique is not 
        generally applicable. 

--
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: Sat, 12 Jul 2008 03:17:56 +0000
Date: Fri, 11 Jul 2008 20:16:14 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: "David B. Nelson" <[e-mail]>
cc: [e-mail], 'Bernard Aboba' <[e-mail]>
Subject: RE: Question on draft-ietf-radext-management-authorization-04.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> OK, I don't know what typical NAS implementations use for NAS-Port and/or
> NAS-Port-Id for remote connections, e.g. when the NAS-Port-Type is Virtual.
> 
> I could imagine that they might use a number of things.  Remote IP address
> and Remote TCP Port are one possibility.  The file descriptor value for use
> with the open socket might be another.  By definition, the values are
> transient, or if the value is not transient, the status of the particular
> virtual port instance they describe certainly would be.  I suppose that what
> would be important is that the NAS *has* some unique and meaningful values
> for those attributes, valid for the duration of the remote management
> session.

Right.  The issue isn't so much how they fill in the values, but that they 
need to include *some* kind of port and session identification if dynamic 
authorization is to work well.  This might not be obvious to readers.


--
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, 11 Jul 2008 20:08:12 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Bernard Aboba'" <[e-mail]>
Subject: RE: Question on draft-ietf-radext-management-authorization-04.txt
Date: Fri, 11 Jul 2008 16:06:53 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <22AA312D3F1E49A480194DE1B7F910C8@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjjXiqH5jfTd/GPQK+GcWoGUGg+tQAMh87g

> Typically, the way that this kind of problem is solved is via 
> addition of session identification attributes, such as the
> Acct-Session-Id, NAS-Port or NAS-Port-Id.  Is a NAS-Port/
> NAS-Port-Id Attribute likely to be available in the case of 
> a management session (local or remote)?

OK, I don't know what typical NAS implementations use for NAS-Port and/or
NAS-Port-Id for remote connections, e.g. when the NAS-Port-Type is Virtual.

I could imagine that they might use a number of things.  Remote IP address
and Remote TCP Port are one possibility.  The file descriptor value for use
with the open socket might be another.  By definition, the values are
transient, or if the value is not transient, the status of the particular
virtual port instance they describe certainly would be.  I suppose that what
would be important is that the NAS *has* some unique and meaningful values
for those attributes, valid for the duration of the remote management
session.

> If an Acct-Session-Id exists, this is probably the
> cleanest way to solve the problem.

Yes.



--
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, 11 Jul 2008 19:49:30 +0000
From: "David B. Nelson" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Question on draft-ietf-radext-management-authorization-04.txt
Date: Fri, 11 Jul 2008 15:48:16 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <D472E56937E944008468EF97E5FE2893@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjjjMr07xnyqXAOQOyMsTBQ/R+IOwAAMyqw

> So I think we're talking about trying to dis-ambiguate a situation
> where there is a valid User-Name attribute, but perhaps multiple
> sessions associated with that.  It might be worth quoting some
> text from RFC 5176 regarding the recommended NAS and session 
> identification attributes, since it might not necessarily be 
> obvious that an Access-Request for a management session should
> necessarily have a NAS-Port/NAS-Port-Id + Acct-Session-Id 
> associated with it.

I can remove the Framed-Management-Protocol and
Management-Transport-Protection Attributes from usage as "session
identifiers" for Dynamic Authorization and quote chapter and verse from RFC
5176 as to what SHOULD be used as "session identifiers".

I think that will cover the "80% problem" without introducing too many
opportunities for odd behaviors and wild-card usages.

The only reason that I could see for a NAS to not include the appropriate
session identifier attributes in an Access-Request message would be if the
NAS implementation didn't assign identifiers until it processed the
Access-Accept message, i.e. didn't want to assign IDs to sessions that may
never materialize, or the NAS implementation didn't support RADIUS
accounting, and thus had no notion of session identifiers.

Do we need to add some wiggle room to cover those corner cases?



--
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, 11 Jul 2008 19:29:43 +0000
Date: Fri, 11 Jul 2008 12:27:54 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: "David B. Nelson" <[e-mail]>
cc: [e-mail], 'Bernard Aboba' <[e-mail]>
Subject: RE: Question on draft-ietf-radext-management-authorization-04.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> I think RFC 5176 already says that.  But then it goes on to provide for
> additional forms of session identifying attributes, for the cases when the
> "SHOULD" doesn't apply.
>
> One of the use cases that motivate some of this behavior is the "privacy
> NAI", i.e. anonymous (external) authentication, in which the RADIUS entities
> don't have the actual user identity.  I think that makes sense for certain
> forms of network access.  I can't imagine a valid use for anonymous
> authentication for the purpose of NAS management, however.  :-)

Right.  So I think we're talking about trying to dis-ambiguate a situation 
where there is a valid User-Name attribute, but perhaps multiple sessions 
associated with that.  It might be worth quoting some text from RFC 5176 
regarding the recommended NAS and session identification attributes, since 
it might not necessarily be obvious that an Access-Request for a 
management session should necessarily have a NAS-Port/NAS-Port-Id + 
Acct-Session-Id associated with it. 

> As an "overlay" to the "SHOULD" in RFC 5176?

Quoting from RFC 5176 would be sufficient. 

> > Assuming we do this, then the remaining use of
> > Framed-Management-Protocol and Management-Transport-Protection in 
> > a CoA-Request would be as a wildcard.  As you say, this kind of
> > use will probably not be mainstream - which raises the question
> > of whether putting it in is worth the interoperability issues it
> > might end up raising.
> 
> Right.

--
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, 11 Jul 2008 16:20:39 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Bernard Aboba'" <[e-mail]>
Subject: RE: Question on draft-ietf-radext-management-authorization-04.txt
Date: Fri, 11 Jul 2008 12:18:33 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <75F159F3CDB946CA91F48C99323A0FF1@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjjXiqH5jfTd/GPQK+GcWoGUGg+tQAEga4g

> Another way to solve the problem is to specify that one or more
> of the above session identification attributes SHOULD be present
> in a management Access-Request.

I think RFC 5176 already says that.  But then it goes on to provide for
additional forms of session identifying attributes, for the cases when the
"SHOULD" doesn't apply.

> That way those attributes are likely to be available for session
> identification in the event that dynamic authorization is needed.

Indeed.  We *could* say that if your implementation doesn't follow the
"SHOULD" in RFC 5176 regarding the inclusion of session IDs, and the Dynamic
Authorization Client doesn't have the appropriate session ID attribute(s)
available, you're simply out of luck.

One of the use cases that motivate some of this behavior is the "privacy
NAI", i.e. anonymous (external) authentication, in which the RADIUS entities
don't have the actual user identity.  I think that makes sense for certain
forms of network access.  I can't imagine a valid use for anonymous
authentication for the purpose of NAS management, however.  :-)

> I think it might be worthwhile to add a section on dynamic 
> authorization, clarifying what session identification attributes 
> SHOULD be included in an Access-Request.

As an "overlay" to the "SHOULD" in RFC 5176?

> Assuming we do this, then the remaining use of
> Framed-Management-Protocol and Management-Transport-Protection in 
> a CoA-Request would be as a wildcard.  As you say, this kind of
> use will probably not be mainstream - which raises the question
> of whether putting it in is worth the interoperability issues it
> might end up raising.

Right.



--
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, 11 Jul 2008 14:20:57 +0000
Message-ID: <[e-mail]>
Date: Fri, 11 Jul 2008 16:19:41 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "David B. Nelson" <[e-mail]>, [e-mail]
Subject: Re: REMINDER: RADEXT WG Last Call on Design Guidelines Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Ugh.  I wonder how the RADSEC proxy would function when receiving packets 
> from an implementation like that.

  If both IP's are listed as clients, then all the packets get processed.

> RFC 5080 does suggest that NAS-Identifier be used to avoid 
> multi-homing confusion, at least within the RADIUS packet itself.  
> Using different source addresses does seem "novel" - and quite 
> likely to confuse.  One can imagine quite bizarre scenarios for an interop 
> torture test - like having a NAS sending RADIUS/EAP packets within the 
> same session from different IP addresses.  The RFC 5080 algorithm in 
> Section 2.1.2 references "source IP", so it would be confused by this, 
> wouldn't it? 

  Yes.  Luckily so far, devices do this only for accounting packets.

  Anyone crazy enough to do this for EAP will quickly discover that it
Just Doesn't Work.  They'll then fix their implementation.

  For accounting packets, it's harder to claim that this behavior
violates the spec.

  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, 11 Jul 2008 14:02:40 +0000
Date: Fri, 11 Jul 2008 07:01:44 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: "David B. Nelson" <[e-mail]>
cc: [e-mail], 'Alan DeKok' <[e-mail]>
Subject: RE: REMINDER: RADEXT WG Last Call on Design Guidelines Document
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> >   e.g. I just ran into devices with multiple interfaces that send
> > Accounting-Requests from IP (1) for Start/Stop, and from IP (2) for
> > Interim-Updates.
> > 
> >   Since this isn't forbidden by the specs, they have no interest in
> > fixing it.  It's everyone *else* that has to butcher their systems in
> > order to deal with such nonsense.

Ugh.  I wonder how the RADSEC proxy would function when receiving packets 
from an implementation like that.

RFC 5080 does suggest that NAS-Identifier be used to avoid 
multi-homing confusion, at least within the RADIUS packet itself.  
Using different source addresses does seem "novel" - and quite 
likely to confuse.  One can imagine quite bizarre scenarios for an interop 
torture test - like having a NAS sending RADIUS/EAP packets within the 
same session from different IP addresses.  The RFC 5080 algorithm in 
Section 2.1.2 references "source IP", so it would be confused by this, 
wouldn't it? 

--
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, 11 Jul 2008 13:54:19 +0000
Date: Fri, 11 Jul 2008 06:52:54 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: "David B. Nelson" <[e-mail]>
cc: [e-mail], 'Bernard Aboba' <[e-mail]>
Subject: RE: Question on draft-ietf-radext-management-authorization-04.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> For example suppose there are three sessions with a User-Name of "dave", one
> with a Service-Type of "NAS-Prompt", and two with a Service-Type of
> "Framed-Management".  Of the latter two, one has a
> Framed-Management-Protocol of "Web-based" and the other has a
> Framed-Management-Protocol of "SNMP".  If you want to affect the web
> session, you need to "address" the session either by an available session ID
> attribute, which is preferable in my opinion, or by the value of
> Framed-Management-Protocol, if the session ID information is not available.

Typically, the way that this kind of problem is solved is via addition of 
session identification attributes, such as the Acct-Session-Id, NAS-Port 
or NAS-Port-Id.  Is a NAS-Port/NAS-Port-Id Attribute likely to be 
available in the case of a management session (local or remote)?  This is 
not clear to me. If an Acct-Session-Id exists, this is probably the 
cleanest way to solve the problem.  

> >    In this case, if it is desired to identify a single session,
> >    session identification MAY be performed by using one or more of the
> >    Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called-
> >    Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id attributes.
> 
> It is in the sprit of this last paragraph that I proposed that some of the
> management provisioning attributes, specifically Framed-Management-Protocol
> and Management-Transport-Protection *could* be used to further identify one
> session from another.  Unfortunately, that usage also allows any of these
> "provisioning" attributes to be use alone (or in combination with others) to
> form all sorts of interesting (maybe not useful) wild-card matches.

Another way to solve the problem is to specify that one or more of the 
above session identification attributes SHOULD be present in a management 
Access-Request.  That way those attributes are likely to be available for 
session identification in the event that dynamic authorization is needed. 

> We can eliminate Framed-Management-Protocol and
> Management-Transport-Protection from such usage in this document.  We can't
> go back and clarify the "murkiness" that exists in RFC 5176 about using this
> sort of wild-card matching when selecting one or more sessions for action.

I think it might be worthwhile to add a section on dynamic authorization, 
clarifying what session identification attributes SHOULD be included in an 
Access-Request.  Assuming we do this, then the remaining use of 
Framed-Management-Protocol and Management-Transport-Protection in a 
CoA-Request would be as a wildcard.  As you say, this kind of use will 
probably not be mainstream - which raises the question of whether putting 
it in is worth the interoperability issues it might end up raising. 

--
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, 11 Jul 2008 12:37:09 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Alan DeKok'" <[e-mail]>
Subject: RE: REMINDER: RADEXT WG Last Call on Design Guidelines Document
Date: Fri, 11 Jul 2008 08:36:37 -0400
Message-ID: <01e201c8e352$c33df4a0$6401a8c0@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjjOT07EPspkJfYT/+SqsH4378cdAAGNk2Q

>   Leaving it open ended might not be catastrophic.  The rest of RADIUS
> is open ended.

It might not be catastrophic.  OTOH, just because there are so many "issues"
that arise because RADIUS is so open-ended, the engineer in me wants to
"fix" some of that, at least in any new features we introduce.

>   e.g. I just ran into devices with multiple interfaces that send
> Accounting-Requests from IP (1) for Start/Stop, and from IP (2) for
> Interim-Updates.
> 
>   Since this isn't forbidden by the specs, they have no interest in
> fixing it.  It's everyone *else* that has to butcher their systems in
> order to deal with such nonsense.

Yeah, well that's the kind of thing that motivates me to craft tighter
specifications for new features we're adding to RADIUS.  We can't fix the
past, but we don't need to add fuel to the fire, either.


--
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, 11 Jul 2008 12:29:47 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Bernard Aboba'" <[e-mail]>
Subject: RE: Question on draft-ietf-radext-management-authorization-04.txt
Date: Fri, 11 Jul 2008 08:28:34 -0400
Message-ID: <01d801c8e351$a301a7f0$6401a8c0@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjjIXlij6BNrX8KS+6Zf5IZglX3NwAK3Kag

> [BA] Using the Framed-Management-Protocol and
> Management-Transport-Protection attributes for session identification
> would seem to imply the need to change the Management-Policy-Id and
> Management-Privilege-Level attributes based on values of those
> attributes, affecting multiple sessions.  The text does not talk about
> when this might be used, so wanted to make sure we understand what the
> potential uses are.

I did send the proposed table of attributes text in an e-mail to the list,
soliciting WG feedback, *before* I submitted -04.  However...   We're
getting that feedback now.

> Some possibilities that come to mind:
> 
> 1. Change the Management-Policy-Id of all sessions with
> Framed-Management-Protocol equal to a particular value.
> 
> A potential example might involve configuration of a new Management policy
> for web-based management; a CoA-Request might be used to cause this to be
> activated for all web-based management sessions currently active on a
> particular NAS.

I suppose.

The whole issue of using RADIUS attributes, other than the User-Name or one
of the session ID attributes, to identify one or more sessions seems pretty
murky to me.  I can see some scenarios where adding some "provisioning"
attributes into a request as further specification makes sense, however.
For example suppose there are three sessions with a User-Name of "dave", one
with a Service-Type of "NAS-Prompt", and two with a Service-Type of
"Framed-Management".  Of the latter two, one has a
Framed-Management-Protocol of "Web-based" and the other has a
Framed-Management-Protocol of "SNMP".  If you want to affect the web
session, you need to "address" the session either by an available session ID
attribute, which is preferable in my opinion, or by the value of
Framed-Management-Protocol, if the session ID information is not available.

> 2. Change the Mangement-Privilege-Level of all sessions with
> Management-Transport-Protection equal to a particular value.
> 
> A potential example might involve discovery of a vulnerability in a
> particular Management transport (e.g. the GNU TLS vulnerability discovered
> recently).  To avoid the potential for compromise, dynamic authorization
> might be used to lower the privileges of all sessions using that
> protection mechanism, at least until a patch becomes available.
> 
> Do people think that these examples make sense?

I think they make sense.  Whether they are within the bounds of "the 80%
problem" is another matter.

> Typically, dynamic authorization has been used to affect particular
> sessions, but the changes in [RFC5176] now make it possible to affect
> several sessions at once, using identification attributes, so discussions
> like this are likely to become more common.

Yes.  I've already indicated, above, that I think this extra flexibility can
be "murky" in its potential applications.

> Here is what RFC 5176 Section 3 says about NAS and session
> identificaiton attributes:
> 
>    In Disconnect-Request and CoA-Request packets, certain attributes are
>    used to uniquely identify the NAS as well as user session(s) on the
>    NAS.  The combination of NAS and session identification attributes
>    included in a CoA-Request or Disconnect-Request packet MUST match at
>    least one session in order for a Request to be successful; otherwise
>    a Disconnect-NAK or CoA-NAK MUST be sent.  If all NAS identification
>    attributes match, and more than one session matches all of the
>    session identification attributes, then a CoA-Request or Disconnect-
>    Request MUST apply to all matching sessions.
> 
>    . . .
> 
>    To address security concerns described in Section 6.1, either the
>    User-Name or Chargeable-User-Identity attribute SHOULD be present in
>    Disconnect-Request and CoA-Request packets.
> 
>    . . .
> 
>    A NAS implementing this specification SHOULD send an Acct-Session-Id
>    or Acct-Multi-Session-Id Attribute within an Access-Request.  Where
>    an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not included
>    within an Access-Request, the Dynamic Authorization Client will not
>    know the Acct-Session-Id or Acct-Multi-Session-Id of the session it
>    is attempting to target, unless it also has access to the accounting
>    data for that session.
> 
>    Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
>    present in a CoA-Request or Disconnect-Request, it is possible that
>    the User-Name or Chargeable-User-Identity attributes will not be
>    sufficient to uniquely identify a single session (e.g., if the same
>    user has multiple sessions on the NAS, or if the privacy NAI is
>    used).  In this case, if it is desired to identify a single session,
>    session identification MAY be performed by using one or more of the
>    Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called-
>    Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id attributes.

It is in the sprit of this last paragraph that I proposed that some of the
management provisioning attributes, specifically Framed-Management-Protocol
and Management-Transport-Protection *could* be used to further identify one
session from another.  Unfortunately, that usage also allows any of these
"provisioning" attributes to be use alone (or in combination with others) to
form all sorts of interesting (maybe not useful) wild-card matches.

We can eliminate Framed-Management-Protocol and
Management-Transport-Protection from such usage in this document.  We can't
go back and clarify the "murkiness" that exists in RFC 5176 about using this
sort of wild-card matching when selecting one or more sessions for action.



--
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, 11 Jul 2008 09:30:34 +0000
Message-ID: <[e-mail]>
Date: Fri, 11 Jul 2008 11:28:29 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: "David B. Nelson" <[e-mail]>
CC: [e-mail]
Subject: Re: REMINDER: RADEXT WG Last Call on Design Guidelines Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
> OK, so that's not a viable simplification.  I'm still fishing for a
> definition of "security functionality", as used in this context, that's less
> open-ended than the plain meaning as found in the dictionary.

  Leaving it open ended might not be catastrophic.  The rest of RADIUS
is open ended.

  e.g. I just ran into devices with multiple interfaces that send
Accounting-Requests from IP (1) for Start/Stop, and from IP (2) for
Interim-Updates.

  Since this isn't forbidden by the specs, they have no interest in
fixing it.  It's everyone *else* that has to butcher their systems in
order to deal with such nonsense.

>>   If SDOs need functionality that is useful to *everyone*, they can
>> request standard space allocation.  If SDOs are defining their own
>> specifications, they do not need standard space allocation.
> 
> How, exactly, do we define "everyone"?

  "The wider Internet community".

>> I'm not sure many SDOs would agree to cede change control over
>> their allocations to IANA.  I'm not sure that IANA wants that work,
>> either.
> 
> Isn't IANA funded to allocate code points to anyone who presents a valid
> request, even individuals?

  Yes.. but change control?  I don't think any SDO forum would be
willing to go through IANA for SDO specific attribute allocation.

> To some extent, I think this is a matter of nomenclature.  If we say that
> the RADIUS code space is divided between "standard" space and "Vendor
> Specific" space, we effectively lump SDO uses, would could be very broadly
> adopted, with proprietary vendor uses, which could have minimal, if any,
> deployment.

  Yes.  That's the reality, unfortunately.

>  That's why I've been touting the term SDO Specific Attribute.
> True, it uses the Vendor Specific Attribute format (and top-level ID), but
> it allows for a distinction between proprietary vendor uses and standardized
> uses.  The distinction between "IETF standard" space and "other SDO
> standard" space then becomes merely a matter of which registry is used, and
> not a matter of "standard" vs. "non-standard".

  The document already refers to SSA's.  I think that's good enough.

  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, 11 Jul 2008 06:39:32 +0000
Date: Thu, 10 Jul 2008 23:38:09 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: Question on draft-ietf-radext-management-authorization-04.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

8. Table of Attributes

   Change-of-Authorization Messages
   Request  ACK   NAK   #     Attribute
   --------------------------------------------------------------------
   0-1     0     0   TBA-2   Framed-Management-Protocol (Note 1)
   0-1     0     0   TBA-3   Management-Transport-Protection (Note 1)
   0-1     0     0   TBA-4   Management-Policy-Id (Note 2)
   0-1     0     0   TBA-5   Management-Privilege-Level (Note 2)


  Disconnect Messages
  Request  ACK   NAK   #     Attribute
  ----------------------------------------------------------------------
  0-1      0     0   TBA-2   Framed-Management-Protocol (Note 1)
  0-1      0     0   TBA-3   Management-Transport-Protection (Note 1)
  0        0     0   TBA-4   Management-Policy-Id
  0        0     0   TBA-5   Management-Privilege-Level
 
    (Note 1) Where NAS or session identification attributes are included
    in Disconnect-Request or CoA-Request packets, they are used for
    identification purposes only.  These attributes MUST NOT be used for
    purposes other than identification (e.g., within CoA-Request packets
    to request authorization changes).

[BA] Using the Framed-Management-Protocol and 
Management-Transport-Protection attributes for session identification 
would seem to imply the need to change the Management-Policy-Id and 
Management-Privilege-Level attributes based on values of those 
attributes, affecting multiple sessions.  The text does not talk about 
when this might be used, so wanted to make sure we understand what the 
potential uses are. 

Some possibilities that come to mind: 

1. Change the Management-Policy-Id of all sessions with 
Framed-Management-Protocol equal to a particular value. 

A potential example might involve configuration of a new Management policy 
for web-based management; a CoA-Request might be used to cause this to be 
activated for all web-based management sessions currently active on a 
particular NAS. 

2. Change the Mangement-Privilege-Level of all sessions with 
Management-Transport-Protection equal to a particular value. 

A potential example might involve discovery of a vulnerability in a 
particular Management transport (e.g. the GNU TLS vulnerability discovered 
recently).  To avoid the potential for compromise, dynamic authorization 
might be used to lower the privileges of all sessions using that 
protection mechanism, at least until a patch becomes available. 

Do people think that these examples make sense? 

Typically, dynamic authorization has been used to affect particular 
sessions, but the changes in [RFC5176] now make it possible to affect 
several sessions at once, using identification attributes, so discussions 
like this are likely to become more common. 

Here is what RFC 5176 Section 3 says about NAS and session 
identificaiton attributes:

   In Disconnect-Request and CoA-Request packets, certain attributes are
   used to uniquely identify the NAS as well as user session(s) on the
   NAS.  The combination of NAS and session identification attributes
   included in a CoA-Request or Disconnect-Request packet MUST match at
   least one session in order for a Request to be successful; otherwise
   a Disconnect-NAK or CoA-NAK MUST be sent.  If all NAS identification
   attributes match, and more than one session matches all of the
   session identification attributes, then a CoA-Request or Disconnect-
   Request MUST apply to all matching sessions.

   . . .

   To address security concerns described in Section 6.1, either the
   User-Name or Chargeable-User-Identity attribute SHOULD be present in
   Disconnect-Request and CoA-Request packets.

   . . .

   A NAS implementing this specification SHOULD send an Acct-Session-Id
   or Acct-Multi-Session-Id Attribute within an Access-Request.  Where
   an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not included
   within an Access-Request, the Dynamic Authorization Client will not
   know the Acct-Session-Id or Acct-Multi-Session-Id of the session it
   is attempting to target, unless it also has access to the accounting
   data for that session.

   Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
   present in a CoA-Request or Disconnect-Request, it is possible that
   the User-Name or Chargeable-User-Identity attributes will not be
   sufficient to uniquely identify a single session (e.g., if the same
   user has multiple sessions on the NAS, or if the privacy NAI is
   used).  In this case, if it is desired to identify a single session,
   session identification MAY be performed by using one or more of the
   Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called-
   Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id attributes.






--
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, 11 Jul 2008 05:28:21 +0000
Date: Thu, 10 Jul 2008 22:26:30 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: Conclusion of RADEXT WG last call on "RADIUS Design Guidelines"
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

The RADEXT WG last call on "RADIUS Design Guidelines" has 
completed.  Comments were received, corresponding to Issues 260-269 in 
the Issues Tracker.  Of the issues, 5 were technical, and 5 were 
editorial.

To view the discussion relating to these issues, click on the following 
link:
http://ops.ietf.org/lists/radiusext/2008/threads.html

--
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, 11 Jul 2008 03:17:26 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-management-authorization-04.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu, 10 Jul 2008 20:15:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.


	Title           : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management
	Author(s)       : D. Nelson, G. Weber
	Filename        : draft-ietf-radext-management-authorization-04.txt
	Pages           : 23
	Date            : 2008-07-10

This document specifies Remote Authentication Dial-In User Service
(RADIUS) attributes for authorizing management access to a Network
Access Server (NAS).  Both local and remote management are supported,
with granular access rights and management privileges.  Specific
provisions are made for remote management via framed management
protocols, and for management access over a secure transport
protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-management-authorization-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--

--
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, 10 Jul 2008 19:46:42 +0000
Date: Thu, 10 Jul 2008 12:45:44 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS"
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This is an announcement of RADEXT WG Last Call on "Crypto-Agility 
Requirements for RADIUS" prior to requesting that the IESG publish it as 
an Informational RFC. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt
 
WG Last Call will last until August 10, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([e-mail]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 



--
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, 10 Jul 2008 19:25:18 +0000
Date: Thu, 10 Jul 2008 12:24:27 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: RADEXT WG Last Call on Extended RADIUS Attributes
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This is an announcement of RADEXT WG Last Call on "Extended RADIUS 
Attributes" prior to requesting that the IESG publish it as a Proposed 
Standard. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt
 
WG Last Call will last until July 24, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([e-mail]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 



--
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, 10 Jul 2008 19:21:16 +0000
Date: Thu, 10 Jul 2008 12:19:20 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: Take one: RADEXT WG Agenda at IETF 72
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

9:00 - 9:10  Preliminaries
 Blue Sheets
 Note Takers
 Jabber Scribe
 Agenda bashing
 Document Status

Completed WG Last Call (30 minutes)

NAS Management Authorization, David Nelson, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-04.txt

Extended RADIUS Attributes, Glen Zorn, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt

RADIUS Design Guidelines, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-05.txt

Transport Documents (40 minutes)

TCP Transport, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-dekok-radext-tcp-transport-00.txt

Status Server, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-00.txt

RADIUS over DTLS, Alan DeKok, 10 minutes
http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-01.txt

RADSEC, Stefan Winter, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-00.txt

RADIUS Cryptoagility (30 minutes)

RADIUS Cryptoagility requirements, David Nelson, 10 minutes
http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt

RADIUS Cryptoagility, Glen Zorn, 10 minutes
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt

RADIUS Confidentiality, Glen Zorn, 10 minutes
http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-10.txt

Additional Documents (20 minutes)

RADIUS Attributes for IEEE 802 Networks, Bernard Aboba, 10 minutes
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-08.txt

IPv6 Attributes for DHCP Networks, B. Lourdelet, 10 minutes
http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-00.txt

--
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, 10 Jul 2008 12:46:46 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Additional comments on draft-ietf-radext-management-authorization-03.txt
Date: Thu, 10 Jul 2008 08:45:38 -0400
Message-ID: <015201c8e28a$db2b2060$041716ac@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcjWDNpFBM9lW8yqTripxrKpZlc0EgKUz0eAAGXOpmAAJHlq4A==

More follow up:

I could also envision permitting Framed-Management-Protocol and
Management-Transport-Protection as session identification attributes is a
CoA-Request, similar to their usage in a Disconnect-Request message.

> Add the following text to Section 12 (as currently numbered):
> 
> Change-of-Authorization Messages
> 
>    Request   ACK   NAK    #     Attribute
> 
>       0       0     0   TBA-2   Framed-Management-Protocol
>       0       0     0   TBA-3   Management-Transport-Protection
>       0-1     0     0   TBA-4   Management-Policy-Id (Note 2)
>       0-1     0     0   TBA-5   Management-Privilege-Level (Note 2)

    Request   ACK   NAK    #     Attribute
 
       0-1     0     0   TBA-2   Framed-Management-Protocol (Note 1)
       0-1     0     0   TBA-3   Management-Transport-Protection (Note 1)
       0-1     0     0   TBA-4   Management-Policy-Id (Note 2)
       0-1     0     0   TBA-5   Management-Privilege-Level (Note 2)

I don't think it makes any sense to allow re-provisioning of the session
transport parameters, as that would almost certainly require a disconnect
and re-establishment of the session.

> Disconnect Messages
> 
>    Request   ACK   NAK   #   Attribute
> 
>       0-1     0     0   TBA-2   Framed-Management-Protocol (Note 1)
>       0-1     0     0   TBA-3   Management-Transport-Protection (Note 1)
>       0       0     0   TBA-4   Management-Policy-Id
>       0       0     0   TBA-5   Management-Privilege-Level
> 
> 
> 
> (Note 1) Where NAS or session identification attributes are included
>    in Disconnect-Request or CoA-Request packets, they are used for
>    identification purposes only.  These attributes MUST NOT be used for
>    purposes other than identification (e.g., within CoA-Request packets
>    to request authorization changes).
> 
> (Note 2) When included within a CoA-Request, these attributes
>    represent an authorization change request.  When one of these
>    attributes is omitted from a CoA-Request, the NAS assumes that the
>    attribute value is to remain unchanged.  Attributes included in a
>    CoA-Request replace all existing values of the same attribute(s).

Similar logic applies to the Disconnect-Request case.  Those attributes
which might aid in distinguishing one of a user's concurrent sessions from
among others may be useful.  The primary indicator here is likely to be the
Service-Type, but that is already permitted by RFC 5176.  We only need to
discuss the newly introduced attributes, in this document.

I'm planning to crate a -04 version of the draft today, to submit prior to
the upcoming "blackout" period on ID submissions.  Now would be a good time
to submit comments on this issue (or any other open issue against -03).  :-)



--
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, 09 Jul 2008 21:37:08 +0000
Date: Wed, 9 Jul 2008 14:35:42 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: REMINDER:  Call for Agenda Items for IETF 72
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Currently the RADEXT WG is scheduled to meet at IETF 72 in Dublin, Ireland 
on Wednesday morning from 9 AM - 11:30 AM on July 30, 2008 in the Conservatory Room. 

This is a call for agenda items for that meeting. If you have an item 
you'd like to put on the agenda, please contact myself 
([e-mail]) or 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: Wed, 09 Jul 2008 19:54:11 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Additional comments on draft-ietf-radext-management-authorization-03.txt
Date: Wed, 9 Jul 2008 15:52:55 -0400
Message-ID: <00c801c8e1fd$61fd60f0$041716ac@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcjWDNpFBM9lW8yqTripxrKpZlc0EgKUz0eAAGXOpmA=

Following up on an open issue:

> > Section 12
> >
> > Within the document, the CoA-Request is mentioned, but the table
> > does not describe which attributes can be included in CoA or
> > Disconnect Request, ACK or NAK packets.  Is it accurate to assume
> > that none of the attributes defined in this document can be
> > contained in a CoA or Disconnect packet?
> 
> Good question.  I need to think about this for a bit.

I've taken the time to re-read RFC 5176.  It's not entirely clear to me if
and how Dynamic Authorization ought to apply to NAS management.  There's a
clear and straightforward application for Disconnect-Request, to terminate a
management session for administrative reasons.

I'm a little less clear that there is an application for
Change-of-Authorization for management sessions.  One could well imagine
possible, hypothetical use cases, of course.  The question remains whether
there is an actual user requirement to be met.  OTOH, I see no reason to
explicitly prohibit the usage of Dynamic Authorization with NAS Management
Authorization, especially if such usage is entirely optional.

RCF 5176 Section 2.3 (page 9, second to last paragraph) requests that future
documents defining RADIUS attributes specify the nature of their usage in
CoA or Disconnect messages, and whether each attribute can be used as a
session identifier, for session provisioning, or for both.

I will take a stab at that, and hereby solicit WG feedback on the proposal.

Add the following text to Section 12 (as currently numbered):

Change-of-Authorization Messages

   Request   ACK   NAK    #     Attribute

      0       0     0   TBA-2   Framed-Management-Protocol
      0       0     0   TBA-3   Management-Transport-Protection
      0-1     0     0   TBA-4   Management-Policy-Id (Note 2)
      0-1     0     0   TBA-5   Management-Privilege-Level (Note 2)


Disconnect Messages

   Request   ACK   NAK   #   Attribute

      0-1     0     0   TBA-2   Framed-Management-Protocol (Note 1)
      0-1     0     0   TBA-3   Management-Transport-Protection (Note 1)
      0       0     0   TBA-4   Management-Policy-Id
      0       0     0   TBA-5   Management-Privilege-Level



(Note 1) Where NAS or session identification attributes are included
   in Disconnect-Request or CoA-Request packets, they are used for
   identification purposes only.  These attributes MUST NOT be used for
   purposes other than identification (e.g., within CoA-Request packets
   to request authorization changes).

(Note 2) When included within a CoA-Request, these attributes
   represent an authorization change request.  When one of these
   attributes is omitted from a CoA-Request, the NAS assumes that the
   attribute value is to remain unchanged.  Attributes included in a
   CoA-Request replace all existing values of the same attribute(s).


--
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, 09 Jul 2008 00:14:54 +0000
From: IESG Secretary <[e-mail]>
To: IETF Announcement list <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: WG Action: RECHARTER: RADIUS Extensions Working Group (radext) 
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue,  8 Jul 2008 17:13:12 -0700 (PDT)

The charter of the RADIUS Extensions Working Group (radext) working group
in the Operations and Management Area of the IETF has been updated.  For 
additional information, please contact the Area Directors or the working 
group Chairs.

RADIUS Extensions Working Group (radext)
----------------------------------------
Last Modified: 2008-05-29

Chair(s):
* Bernard Aboba <[e-mail]>
* David Nelson <[e-mail]>

Operations and Management Area Director(s):
* Dan Romascanu <[e-mail]>
* Ronald Bonica <[e-mail]>

Operations and Management Area Advisor:
* Dan Romascanu <[e-mail]>

Technical Advisor(s):
* Paul Congdon <[e-mail]>

Mailing Lists:
General Discussion: [e-mail]
To Subscribe: [e-mail]
In Body: In Body: subscribe
Archive: https://ops.ietf.org/lists/radiusext

Description of Working Group:

The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to define extensions to the standard
attribute space as well as to address cryptographic algorithm
agility and use over new transports. In addition, RADEXT will
work on RADIUS Design Guidelines and define new attributes for
particular applications of authentication, authorization and
accounting such as NAS management and local area network (LAN) usage.

In order to enable interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items MUST contain a Diameter
compatibility section, outlining how interoperability with
Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the
RADEXT WG:

- All documents produced MUST specify means of interoperation with
legacy RADIUS and, if possible, be backward
compatible with existing RADIUS RFCs, including RFCs 2865-2869,
3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176.
Transport profiles should, if possible, be compatible with RFC 3539.

- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.


Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.

- RADIUS Management authorization. This document will define the
use of RADIUS for NAS management over IP.

-RADIUS attribute space extension. The standard RADIUS attribute
space is currently being depleted. This document will provide
additional standard attribute space, while maintaining backward
compatibility with existing attributes.

-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally
relied on MD5 for both per-packet integrity and authentication as well
as attribute confidentiality. Given the increasingly successful
attacks being mounted against MD5, the ability to support
alternative algorithms is required. This work item will
include documentation of RADIUS crypto-agility requirements,
as well as development of one or more Experimental RFCs providing
support for negotiation of alternative cryptographic algorithms
to protect RADIUS.

- IEEE 802 attributes. New attributes have been proposed to
support IEEE 802 standards for wired and wireless LANs. This
work item will support authentication, authorization and
accounting attributes needed by IEEE 802 groups including
IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. A reliable transport profile for
RADIUS will be developed, as well as specifications for
Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS.

- Documentation of Status-Server usage. A document
describing usage of the Status-Server facility will be
developed.

Goals and Milestones:

Jun 2008 RADIUS Design Guidelines submitted as a Best Current Practice
RFC
Jun 2008 RADIUS Management Authorization I-D submitted as a Proposed
Standard RFC
Sep 2008 RADIUS Crypto-agility Requirements submitted as an
Informational RFC
Sep 2008 Extended Attributes I-D submitted as a Proposed Standard RFC
Dec 2008 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Jan 2009 Reliable Transport Profile for RADIUS I-D submitted as a
Proposed Standard RFC
Mar 2009 Status-Server I-D submitted as a Proposed Standard RFC
Mar 2009 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental
RFC
June 2009 RADIUS over DTLS I-D submitted as an Experimental RFC
June 2009 RADIUS Cryptographic Algorithm Agility I-D submitted as an
Experimental RFC

--
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, 08 Jul 2008 18:12:14 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Alan DeKok'" <[e-mail]>
Subject: RE: REMINDER: RADEXT WG Last Call on Design Guidelines Document
Date: Tue, 8 Jul 2008 14:11:05 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <A55B370B1CBA4B85A66CD99B56068DC2@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Acjg/Xvknd8pR5PZQRGDH2+MWm/VMgAIekeg

Alan DeKok writes...

> > (3) Undefined term.
> ...
> > Add a definition of what constitutes "security functionality". 
> > Given that I'm having difficulty in suggesting specific text to 
> > accomplish this, I'm thinking it's not all that obvious.  Do we
> > need to reference "security functionality" at all, or is an 
> > exception for "authentication credentials" sufficient?
> 
>   The Message-Authenticator attribute provides authentication of 
> RADIUS packets that is independent of any user authentication 
> credentials.

OK, so that's not a viable simplification.  I'm still fishing for a
definition of "security functionality", as used in this context, that's less
open-ended than the plain meaning as found in the dictionary.

>   SDOs don't have a problem referencing RADIUS specifications from other
> SDOs.  That's not the issue.  The issue is whether or not everyone
> *else* finds the specifications useful.

>   If SDOs need functionality that is useful to *everyone*, they can
> request standard space allocation.  If SDOs are defining their own
> specifications, they do not need standard space allocation.

How, exactly, do we define "everyone"?

> I'm not sure many SDOs would agree to cede change control over
> their allocations to IANA.  I'm not sure that IANA wants that work,
> either.

Isn't IANA funded to allocate code points to anyone who presents a valid
request, even individuals?

To some extent, I think this is a matter of nomenclature.  If we say that
the RADIUS code space is divided between "standard" space and "Vendor
Specific" space, we effectively lump SDO uses, would could be very broadly
adopted, with proprietary vendor uses, which could have minimal, if any,
deployment.  That's why I've been touting the term SDO Specific Attribute.
True, it uses the Vendor Specific Attribute format (and top-level ID), but
it allows for a distinction between proprietary vendor uses and standardized
uses.  The distinction between "IETF standard" space and "other SDO
standard" space then becomes merely a matter of which registry is used, and
not a matter of "standard" vs. "non-standard".

I'm an engineer but I recognize that sometimes marketing considerations are
important.  :-)

>   How about adding 2.1.6:
> 
>   The extended RADIUS attribute document [EXTEN] defines a number of
>   extensions to RADIUS.  The standard attribute space is extended by
>   permitting standard allocations from within a specific subset of the
>   VSA space; the format of extended attributes is defined; and
>   extended data types are defined within that format.
> 
>   New specifications seeking to extend the standard RADIUS data model
>   SHOULD examine [EXTEN] to see if their needs fit within the extended
>   RADIUS data model.

Yes, I think that would be helpful.

>   We could add the following sentence after the existing bullet points
> that discuss "SDOs or groups of SDOs".
> 
>   Any new RADIUS attributes or values intended for interoperable use
>   across a broad spectrum of the Internet Community SHOULD follow the
>   normal IETF process, and SHOULD result in allocations from the RADIUS
>   standard space.

I think that would also helpful, although the interpretation of "broad"
remains subjective.  I'm not sure ewe can do much better, though.

>   As noted in my response, there are many uses of attributes *outside*
> of SDOs and groups of SDOs.  The text here can be clarified a bit, but I
>  think it's relatively good.
> 
>   How about this text:
> 
>   When attributes are used primarily within a group of SDOs, and are
>   not applicable to the wider Internet community, we expect that one SDO
>   will be responsible for allocation from their own private space.

I guess this OK.   See my discussion, above.



--
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, 08 Jul 2008 17:23:40 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Bernard Aboba'" <[e-mail]>
Subject: RE: Additional comments on draft-ietf-radext-management-authorization-03.txt
Date: Tue, 8 Jul 2008 13:22:22 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <EA1BE2E7564C4ADF8889E0D31F689739@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Acjgdi5xjTxGUhOtQj235JAgVzoOrgAqGQhg

Bernard Aboba writes...

> > > "MAY use these hint attributes" -> "may use these attributes
> > > as a hint"=20
> > OK, but why "MAY" --> "may"?
>=A0
> Hints are inherently optional.

Well, quoting RFC 2119:

   MAY   This word, or the adjective "OPTIONAL", mean that an
   item is truly optional.

Since MAY means "truly optional", which I can't distinguish from =
"inherently
optional", I'm proposing to leave the text as is.  :-)



--
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, 08 Jul 2008 13:22:52 +0000
Message-ID: <[e-mail]>
Date: Tue, 08 Jul 2008 15:20:55 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: "David B. Nelson" <[e-mail]>
CC: [e-mail]
Subject: Re: REMINDER: RADEXT WG Last Call on Design Guidelines Document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
> My review comments on the -04 version as are follows:
> 
> (1) Short-lived reference.
...
> The RADEXT WG mailing list is a relatively short-lived entity.  We hope the
> WG completes its charter and closes one of these days.  :-)  This text
> provides no guidance to the reader as to how to determine what constitutes
> an "equivalent" IETF mailing list.

  The introduction references the AAA doctors list.  A similar reference
should be added here.

> Requested change:
> 
> * Reviews of specifications are posted to the RADEXT WG mailing list or
> another IETF mailing list suggested by the Operations & Management Area
> Directors of the IETF;

  I think that referencing the AAA doctors list would be useful, too.

> (2) Misplaced modifier.
...
> Requested change:

  OK.

> (3) Undefined term.
...
> Add a definition of what constitutes "security functionality".  Given that
> I'm having difficulty in suggesting specific text to accomplish this, I'm
> thinking it's not all that obvious.  Do we need to reference "security
> functionality" at all, or is an exception for "authentication credentials"
> sufficient?

  The Message-Authenticator attribute provides authentication of RADIUS
packets that is independent of any user authentication credentials.

> (4) Needlessly IETF-centric viewpoint.
..
> This leads me to believe that the authors think that other (non-IETF) SDOs
> (or worse yet, groups of SDOs) are unlikely to define attributes that are
> useful to the broad Internet Community.

  SDOs don't have a problem referencing RADIUS specifications from other
SDOs.  That's not the issue.  The issue is whether or not everyone
*else* finds the specifications useful.

  e.g. 3GPP2 defines a number of RADIUS attributes.  I haven't seen them
implemented in a Wifi hotspot or in a low-end Wifi home router... and I
don't expect to see them there.  As such, the 3GPP2 specifications
belong in the SDO space, and not in the IETF space.

>  That may or may not be true.  I'm
> guessing that what this really means is that only the IETF ought to be
> consuming standard RADIUS attribute IDs, based on IANA allocation, and all
> other bodies need to host attributes in a private code-point space (i.e. the
> assigned VSA block).  Does this document intend to Update RFC 3575?

  Yes (to the first sentence), and no (to the second).  Pointing out
that IETF and IANA are responsible for standard-space allocations isn't
an update to IETF processes.  It's a re-iteration that vendors and SDOs
SHOULD NOT stomp on the IETF space for vendor-specific, or SDO-specific
allocations.

> I think the conditional phrase "for attributes matching any of the following
> criteria" will almost always evaluate to TRUE because of the second and
> third bullet items, so the whole paragraph makes little sense to me.

  If SDOs need functionality that is useful to *everyone*, they can
request standard space allocation.  If SDOs are defining their own
specifications, they do not need standard space allocation.

> If the issue is standard attribute scarcity, isn't this addressed by the
> RADIUS Extended Attribute format [EXTEN]?

  No.  While the guidelines document was started when [EXTEN] had 8-bit
attributes, the issue isn't attribute scarcity.  The issue as I see it
is requesting "standard" space allocation for SDO-specific
functionality.  I'm not sure many SDOs would agree to cede change
control over their allocations to IANA.  I'm not sure that IANA wants
that work, either.

> I think that this document should provide better guidance as to when an IANA
> allocation from the standard RADIUS Attribute code-point space is
> appropriate.  Does the need for interoperability between multiple SDOs meet
> that threshold? 

  I don't think so.  WiMAX is referencing 3GPP attributes.  There's no
need to re-host the 3GPP attributes in the IETF standard space just
because another SDO decides to reference them.

> Or must the usage be of general applicability to the
> Internet Community?

  Yes.  And it should be *new* functionality.

>  How does the existence of the Extended RADIUS Attribute
> (a VSA with a code-point block assigned to the IETF) change the distinction
> between "standard" and "VSA" allocations?

  How about adding 2.1.6:

  The extended RADIUS attribute document [EXTEN] defines a number of
  extensions to RADIUS.  The standard attribute space is extended by
  permitting standard allocations from within a specific subset of the
  VSA space; the format of extended attributes is defined; and
  extended data types are defined within that format.

  New specifications seeking to extend the standard RADIUS data model
  SHOULD examine [EXTEN] to see if their needs fit within the extended
  RADIUS data model.

> Requested change:

  We could add the following sentence after the existing bullet points
that discuss "SDOs or groups of SDOs".

  Any new RADIUS attributes or values intended for interoperable use
  across a broad spectrum of the Internet Community SHOULD follow the
  normal IETF process, and SHOULD result in allocations from the RADIUS
  standard space.

> (5) Format issues.

  Fixed.

> (6) Bad reference.

  Fixed.

> (7) Missing definition/reference.
...
> Where do we normatively define the term "extended data types"?

  I would suggest in a new section, 2.1.6, as shown above.

> (8) Duplicate section title.
...
> Both of these sections are entitled "Complex data types".  One of them is
> permissive and the other prohibitive.

  The first talks about Opaque data types being OK.  I've changed the
title to "Opaque data types".  The second is about Complex data types in
RADIUS being NOT RECOMMENDED.

> (9) Confusion over allocation policy.
...
> As discussed in comment (4), above, attributes intended for interoperable
> use across multiple SDOs *could* qualify for allocation from the standard
> RADIUS attribute space, or from the Extended RADIUS Attribute (IETF/SDO)
> space.

  As noted in my response, there are many uses of attributes *outside*
of SDOs and groups of SDOs.  The text here can be clarified a bit, but I
 think it's relatively good.

  How about this text:

  When attributes are used primarily withing a group of SDOs, and are
  not applicable to the wider Internet community, we expect that one SDO
  will be responsible for allocation from their own private space.

  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: Mon, 07 Jul 2008 21:46:35 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-radext-extended-attributes-04.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  7 Jul 2008 14:45:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title		: Extended Remote Authentication Dial In User Service (RADIUS) Attributes
	Author(s)	: Y. Li, A. Lior, G. Zorn
	Filename	: draft-ietf-radext-extended-attributes-04.txt
	Pages		: 13
	Date		: 2008-7-7
	
For the Remote Authentication Dial In User Service (RADIUS) protocol
   to continue to support new applications the RADIUS attribute type
   space must be extended beyond the current limit of 255 possible
   attribute types while maintaining backwards compatibility with the
   existing protocol.  This document defines a mechanism to accomplish
   that task, along with standard methods to group together related
attributes and to encode values that don't fit into 253 octets.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-extended-attributes-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--NextPart--


--
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, 07 Jul 2008 19:13:35 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Bernard Aboba'" <[e-mail]>
Subject: RE: Additional comments on draft-ietf-radext-management-authorization-03.txt
Date: Mon, 7 Jul 2008 15:12:33 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <69C61DEE097F4E5AB1582222AB04AFBC@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjWDNpFBM9lW8yqTripxrKpZlc0EgKUz0eA

Bernard Aboba writes...

> Section 8.1
> 
> "Service-Type of Framed-Management" -> "Service-Type Attribute
> with the value Framed-Management"

OK.
 
> "in Access-Request packet" -> "in an Access-Request packet"

OK.

> "MAY use these hint attributes" -> "may use these attributes as a hint"

OK, but why "MAY" --> "may"?

> "MUST treat the response" -> "MUST treat the Access-Accept"

OK.

Reference issues have been previously discussed.

> Section 8.2
> 
>    The Management-Transport-Protection Attribute specifies whether a
>    secure transport protocol (e.g.  SSH, TLS, DTLS, etc.) is required
>    for use with the associated framed or non-framed management access
>    session.  The value of this attribute specifies the minimum level of
>    protection that is required from the protected transport.  The
>    protected transport MAY provide a greater level of protection than is
>    called for by the value of Management-Transport-Protection.
> 
> [BA] The second sentence is more on target.  How about this?
> 
>    The Management-Transport-Protection Attribute specifies the minimum
>    level of protection that is required for a protected transport used
>    with the framed or non-framed management access session.  The protected
>    transport used by the NAS MAY provide a greater level of protection,
>    but MUST NOT provide a lower level of protection.

OK.
 
> "in Access-Request packet" -> "in an Access-Request packet"
> "RADIUS Client" -> "RADIUS client"
> "RADIUS Server" -> "RADIUS server"
> "MAY use this hint attribute" -> "may use this attribute as a hint"

OK, but same question on "MAY"...

> Section 8.3
> 
> "application to SMNP services" -> "SNMP"
> "NAS behavior in such cases is not predictable." -> "The behavior of the
> NAS in this case is undefined."
> "a single service provisioning message, such as" -> "an Access-Accept or
> CoA-Request".

All OK.

> ", within a flat namespace of significance to the NAS"
> 
> [BA] Are you saying that "." can't be used?  Can this be deleted?

Eh?  By "flat", I mean a monolithic name that can be searched by a
non-structured text comparison (e.g. strcasecmp()).  This is effectively a
prohibition on sub-fields within the name text that a client or server would
need to take special heed of.  You can include ".", but it has no more
significance than any other character.

> "Overloading or subdividing this flat name with" ->
> "Overloading or subdividing this attribute with"

Hmm.  Module the resolution of the "flatness" issue, above, this might be
OK.

> "If a simple flat policy name" -> "If a simple policy name"
> "sufficient to the anticipated use case" -> "sufficient"

Ditto.
 
> Section 12
> 
> Within the document, the CoA-Request is mentioned, but the table
> does not describe which attributes can be included in CoA or
> Disconnect Request, ACK or NAK packets.  Is it accurate to assume
> that none of the attributes defined in this document can be 
> contained in a CoA or Disconnect packet?

Good question.  I need to think about this for a bit.

> Section 14
> 
>    Any of the attributes described in this memo, with the exception of
>    Service-Type, may not be understood by the NAS which receives it.  A
>    legacy NAS not compliant with this specification may silently discard
>    these attributes while permitting the user to access the management
>    interface(s) of the NAS.  This can lead to users improperly receiving
>    unauthorized management access to the NAS, or access with greater
>    levels of access rights than were intended.  RADIUS servers SHOULD
>    attempt to ascertain whether or not the NAS supports these attributes
>    before sending them in an Access-Accept.
> 
> [BA] This paragraph could be more clear.  There are really two cases.
> When a Service-Type value of Framed-Management is used, I'd assume 
> that a NAS implementing this specification would be required to behave
> as specified (e.g. treat the Access-Accept as an Access-Reject if the
> attribute or value wasn't supported).

Right.  Service-Type is the one implicitly "mandatory" (as in the Diameter
Mandatory bit) attribute in RADIUS.

Can we assume that if the NAS supports a value of Framed-Management for the
Service-Type attribute that it also at least *recognizes* all the other
Framed Management related attributes in this document, even though it may
not support those services?  Or is that expecting too much?

> I think that an issue could occur when a legacy Service-Type value
> is used though, since then the NAS might ignore the new attributes 
> instead of treating the Access-Accept like an Access-Reject.

Um, yeah.

> I don't think you need to talk about the potential behavior of an
> implementation that claims to conform to the spec, but doesn't do 
> what it says.

:-)

How about:

  A legacy NAS may not recognize the attributes in this document
  that supplement the provisioning of CLI management access.  If
  the value of the Service Type Attribute is NAS-Prompt or 
  Administrative, the legacy NAS may silently discard such 
  attributes, while permitting the user to access the CLI
  management interface(s) of the NAS.  This can lead to users
  improperly receiving unauthorized management access to the NAS,
  or access with greater levels of access rights than were intended.
  RADIUS servers SHOULD attempt to ascertain whether or not the
  NAS supports these attributes before sending them in an 
  Access-Accept provisioning CLI access.



--
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, 07 Jul 2008 18:31:15 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'Bernard Aboba'" <[e-mail]>
Subject: RE: Editorial review of draft-ietf-radext-management-authorization-03.txt
Date: Mon, 7 Jul 2008 14:30:14 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <72F93F8B338146A396310828430D7D83@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjWB/omJanCHyJNRY+ezPx3//Rx9wKVS2yw

Bernard Aboba writes...
 
> Abstract
> 
>    This document describes Remote Authentication Dial-In User Service
>    (RADIUS) attributes for the authorization and service provisioning of
>    Network Access Servers (NASes).  Both local and remote management are
>    supported, with granular access rights and management privileges.
>    Specific provisions are made for remote management via framed
>    management protocols, and for specification of a protected transport
>    protocol.
> 
> [BA] This document is about NAS management authorization, not
> authorization of NASes.  Suggest the following:
> 
>    This document specifies Remote Authentication Dial-In User Service
>    (RADIUS) attributes for Network Access Server (NAS) management.
>    Both local and remote management are
>    supported, with granular access rights and management privileges.
>    Specific provisions are made for remote management via framed
>    management protocols, which may run over a secure transport
>    protocol.

Yeah, something went awry in the editing.  How about:

  This document specifies Remote Authentication Dial-In User Service
  (RADIUS) attributes for authorizing management access to a Network 
  Access Server (NAS).  Both local and remote management are supported,
  with granular access rights and management privileges.  Specific
  provisions are made for remote management via framed management
  protocols, which may run over a secure transport protocol.
 
> 2. Introduction and Rationale
> 
> [BA] How about combining Sections 2, part of 3 and 6 into a Section 1 that
> reads as follows?  The Terminology section can then be Section 1.1.
> 
> 1. Introduction
> 
>    RFC 2865 [RFC 2865] defines the NAS-Prompt and Administrative values of
>    the Service-Type Attribute.   Both of these values provide access to
>    the interactive, text-based Command Line Interface (CLI) of the NAS,
>    and were originally developed to control access to the physical
>    console port of the NAS, most often a serial port.
> 
>    Remote access to the CLI of the NAS has been available in NAS
>    implementations for many years, using protocols such as Telnet,
>    Rlogin and the remote terminal service of SSH.  In order to distinguish
>    local, physical, console access from remote access, the NAS-Port-Type
>    Attribute is generally included in Access-Request and Access-Accept
>    messages, along with the Service-Type Attribute, to indicate the form
>    of access.  A NAS-Port-Type of Async (0) is used to signify a local
>    serial port connection, while a value of Virtual (5) is used to
>    signify a remote connection, via a remote terminal protocol.  This
>    usage provides no selectivity among the various available remote
>    terminal protocols (e.g.  Telnet, Rlogin, SSH, etc.).

OK with me.

>    Today, it is common for network devices to support more than two
>    privilege levels for management access than just NAS-Prompt
>    (non-privileged) and Administrative (privileged).  Also, other
>    management mechanisms may be used, such as Web-based management,
>    Simple Network Management Protocol (SNMP) and NETCONF.
>    To provide support for these additional features, this specification
>    defines attributes for framed management protocols, management protocol
>    security, and management access privilege levels.

Looks OK to me, with minor grammatical tweaking.  How about:

  Today, it is common for network devices to support more than the two
  privilege levels for management access provided by NAS-Prompt
  (non-privileged) and Administrative (privileged).

>    Remote management via the command line is carried over protocols
>    such as Telnet, Rlogin and the remote terminal service of SSH.  Since
>    these protocols are primarily for the delivery of terminal or
>    pseudo-TTY services,  the term "Framed Management" is used to describe
>    management protocols supporting techniques other than the command-line.
>    Typically these mechanisms format management information in a binary or
>    textual encoding such as HTML, XML or ASN.1/BER.  Examples include
>    web-based management (HTML over HTTP or HTTPS), NETCONF (XML over
>    SSH/BEEP/SOAP) and SNMP (SMI over ASN.1/BER).  Command line
>    interface, menu interface or other text-based (e.g. ASCII or UTF-8)
>    terminal emulation services are not considered to be Framed Management
>    protocols.

OK with me.

> [BA] How about combining part of Section 3, as well as 4, 5 and 6 into
> a Section 2 that reads as follows?
> 
> 2. Overview
> 
>    To support the authorization and provisioning of Framed Management
>    access to managed entities, this document introduces a new value for
>    the Service-Type Attribute [RFC2865], and one new attribute.  The new
>    value for the Service-Type Attribute is Framed-Management, used for
>    remote device management via a Framed Management Protocol.  The new
>    attribute is Framed-Management-Protocol, the value of which specifies a
>    particular protocol for use in the remote management session.
> 
>    Two new attributes are introduced in this document in support of
>    granular management access rights or command privilege levels.
>    The Management-Policy-Id Attribute provides a text string
>    specifying  a policy name of local scope, that is assumed to have
>    been pre-provisioned on the NAS.  This use of an attribute to
>    specify use of a pre-provisioned policy is similar to
>    the Filter-Id Attribute defined in [RFC2865] Section 5.11.
> 
>    The local application of the Management-Policy-Id within the managed
>    entity may take the form of (a) one of an enumeration of command
>    privilege levels, (b) a mapping into an SNMP Access Control Model,
>    such as the View Based Access Control Model (VACM) [RFC3415], or (c)
>    some other set of management access policy rules that is mutually
>    understood by the managed entity and the remote management
>    application.  Examples are given in Section X.
> 
>    The Management-Privilege-Level Attribute contains an
>    integer-valued management privilege level indication.  This attribute
>    serves to modify or augment the management permissions provided by
>    the NAS-Prompt value of the Service-Type Attribute, and thus applies to
>    CLI management.
> 
>    To enable management security requirements to be specified, the
>    Management-Transport-Protection Attribute is introduced.  The value
>    of this attribute indicates the minimum level of secure transport
>    protocol protection required for the provisioning of NAS-Prompt,
>    Administrative or Framed-Management service.

This looks, OK, too.

Obviously we need to see the edited version, in context, but I don't see any
loss of information in this condensed version.


--
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, 07 Jul 2008 18:01:18 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: REMINDER: RADEXT WG Last Call on Design Guidelines Document
Date: Mon, 7 Jul 2008 13:59:30 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <6A2BB8CCBEB94217B36A3D8B3F015564@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Acje0nghTRj4aUmRTkOTstmvS+hHqwBcbLAg

My review comments on the -04 version as are follows:

(1) Short-lived reference.

Submitter name: Dave Nelson
Submitter email address: [e-mail]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: 1.1
Rationale/Explanation of issue:

* Reviews of specifications are posted to the RADEXT WG or
equivalent IETF mailing list;

The RADEXT WG mailing list is a relatively short-lived entity.  We hope the
WG completes its charter and closes one of these days.  :-)  This text
provides no guidance to the reader as to how to determine what constitutes
an "equivalent" IETF mailing list.

Requested change:

* Reviews of specifications are posted to the RADEXT WG mailing list or
another IETF mailing list suggested by the Operations & Management Area
Directors of the IETF;


(2) Misplaced modifier.

Submitter name: Dave Nelson
Submitter email address: [e-mail]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: 1.1
Rationale/Explanation of issue:

   RADIUS protocol changes, or specification of attributes that
   can be used to, in effect, provide new RADIUS commands (such as
   Service-Type) require greater expertise and deeper review, as
   do changes to the RADIUS operational model, as described in
   Section 3.3.

Service-Type is an attribute, not a command.

Requested change:

   RADIUS protocol changes, or specification of attributes (such
   as Service-Type) that can be used to, in effect, provide new
   RADIUS commands, require greater expertise and deeper review,
   As do changes to the RADIUS operational model, as described in
   Section 3.3.


(3) Undefined term.

Submitter name: Dave Nelson
Submitter email address: [e-mail]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: 2.1.3
Rationale/Explanation of issue:

   As a result, the introduction of new complex data types
   within RADIUS attribute specifications SHOULD be avoided,
   except in the case of complex attributes involving authentication
   or security functionality.

"Security functionality" is a term that could be assigned a fairly broad
range of possible meanings.  Well intentioned RADIUS Attribute designers
might think this applies to any attribute that they wish to remain "secure"
or which has security implications for their product, e.g. important service
provisioning parameters.  While the term is defined by various examples in
Appendix B, I think a better "normative" definition is required here.

Requested change:

Add a definition of what constitutes "security functionality".  Given that
I'm having difficulty in suggesting specific text to accomplish this, I'm
thinking it's not all that obvious.  Do we need to reference "security
functionality" at all, or is an exception for "authentication credentials"
sufficient?


(4) Needlessly IETF-centric viewpoint.

Submitter name: Dave Nelson
Submitter email address: [e-mail]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: 3.1.3
Rationale/Explanation of issue:

  SDO RADIUS Attribute specifications SHOULD allocate attributes from
  the vendor space, rather than requesting an allocation from the
  RADIUS standard attribute space, for attributes matching any of the
  following criteria:

   * attributes relying on data types not defined within RADIUS
   * attributes intended primarily for use within an SDO
   * attributes intended primarily for use within a group of SDOs.

This leads me to believe that the authors think that other (non-IETF) SDOs
(or worse yet, groups of SDOs) are unlikely to define attributes that are
useful to the broad Internet Community.  That may or may not be true.  I'm
guessing that what this really means is that only the IETF ought to be
consuming standard RADIUS attribute IDs, based on IANA allocation, and all
other bodies need to host attributes in a private code-point space (i.e. the
assigned VSA block).  Does this document intend to Update RFC 3575?

I think the conditional phrase "for attributes matching any of the following
criteria" will almost always evaluate to TRUE because of the second and
third bullet items, so the whole paragraph makes little sense to me.

If the issue is standard attribute scarcity, isn't this addressed by the
RADIUS Extended Attribute format [EXTEN]?

I think that this document should provide better guidance as to when an IANA
allocation from the standard RADIUS Attribute code-point space is
appropriate.  Does the need for interoperability between multiple SDOs meet
that threshold?  Or must the usage be of general applicability to the
Internet Community?  How does the existence of the Extended RADIUS Attribute
(a VSA with a code-point block assigned to the IETF) change the distinction
between "standard" and "VSA" allocations?

Requested change:

  SDO RADIUS Attribute specifications SHOULD allocate attributes from
  the vendor space, rather than requesting an allocation from the
  RADIUS standard attribute space, unless the attributes match any of the
  following criteria:

   * attributes intended for interoperable use across multiple SDOs.
   * attributes intended for interoperable use across a broad spectrum 
     of the Internet Community.


(5) Format issues.

Submitter name: Dave Nelson
Submitter email address: [e-mail]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: 3.3
Rationale/Explanation of issue:

      * The RADIUS protocol is stateless; * Provisioning of services is
      not possible within an Access-Reject; * Distinction between
      authorization checks and user authentication; * Authentication and
      integrity protection of RADIUS packets; * The RADIUS protocol is a
      Request/Response protocol.

Bulleted list not well formatted.

Requested change:

  * The RADIUS protocol is stateless;
  * Provisioning of services is not possible within an Access-Reject;
  * Distinction between authorization checks and user authentication;
  * Authentication and integrity protection of RADIUS packets;
  * The RADIUS protocol is a Request/Response protocol.


(6) Bad reference.

Submitter name: Dave Nelson
Submitter email address: [e-mail]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: A.1.2
Rationale/Explanation of issue:

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.2 SHOULD
   be used.  The extended data types SHOULD be used only where there is
   no clear method of expressing the data using existing types.

Requested change:

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.1 SHOULD
   be used.  The extended data types SHOULD be used only where there is
   no clear method of expressing the data using existing types.

A.1.2 --> A.1.1


(7) Missing definition/reference.

Submitter name: Dave Nelson
Submitter email address: [e-mail]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: A.1.2
Rationale/Explanation of issue:

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.2 SHOULD
   be used.  The extended data types SHOULD be used only where there is
   no clear method of expressing the data using existing types.

Where do we normatively define the term "extended data types"?

Requested change:

Add a definition, or a reference to a definition.  Does this, in fact, mean
the RADIUS Attribute format defined in [EXTEN]?

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.2 SHOULD
   be used.  The extended data types [EXTEN] SHOULD be used only where 
   there is no clear method of expressing the data using existing types.


(8) Duplicate section title.

Submitter name: Dave Nelson
Submitter email address: [e-mail]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: A.1.3, A.2.2
Rationale/Explanation of issue:

Both of these sections are entitled "Complex data types".  One of them is
permissive and the other prohibitive.

Requested change:

Clarify the subject of each of these sections in its title.


(9) Confusion over allocation policy.

Submitter name: Dave Nelson
Submitter email address: [e-mail]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: A.5
Rationale/Explanation of issue:

A.5. Allocation of attributes

   Does the attribute have a limited scope of applicability, as outlined
   below?  If so, then the attributes SHOULD be allocated from the
   Vendor-Specific space.

      * attributes intended for a vendor to support their own systems,
      and not suitable for general usage
      * attributes relying on data types not defined within RADIUS
      * attributes intended primarily for use within an SDO
      * attributes intended primarily for use within a group of SDOs.

As discussed in comment (4), above, attributes intended for interoperable
use across multiple SDOs *could* qualify for allocation from the standard
RADIUS attribute space, or from the Extended RADIUS Attribute (IETF/SDO)
space.

Requested change:

A.5. Allocation of attributes

   Does the attribute have a limited scope of applicability, as outlined
   below?  If so, then the attributes SHOULD be allocated from the
   Vendor-Specific space.

      * attributes intended for a vendor to support their own systems,
      and not suitable for general usage
      * attributes relying on data types not defined within RADIUS
      * attributes intended for use within an single SDO
     


--
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, 07 Jul 2008 12:46:31 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-design-04.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  7 Jul 2008 05:45:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.


	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, et al.
	Filename        : draft-ietf-radext-design-04.txt
	Pages           : 34
	Date            : 2008-07-07

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--

--
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, 07 Jul 2008 12:35:14 +0000
Message-ID: <[e-mail]>
Date: Mon, 07 Jul 2008 14:32:52 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: [e-mail]
Subject: Re: Review of draft-ietf-radext-design-03.txt
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
...

  I've just submitted -04, which incorporates this review.

  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: Sat, 05 Jul 2008 19:01:42 +0000
Date: Sat, 5 Jul 2008 11:59:25 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: REMINDER: RADEXT WG Last Call on Design Guidelines Document
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This is a reminder of the ongoing RADEXT WG Last Call on "RADIUS Design 
Guidelines" prior to requesting that the IESG publish it as a Best
Current Practice RFC. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-03.txt
 
WG Last Call will last until July 10, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([e-mail]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

--
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, 03 Jul 2008 12:21:01 +0000
Message-ID: <[e-mail]>
Date: Thu, 03 Jul 2008 14:19:58 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: Stefan Winter <[e-mail]>
CC: [e-mail]
Subject: Re: TCP transport draft
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Stefan Winter wrote:
> some small glitches:

  Fixed, thanks.

> Should there be some more TCP usage profile guidelines in it, like
> recommending TCP PSH when a RADIUS message is complete,

  There's no socket API to do that, so far as I know.  The closest thing
is that the kernel *usually* will send the data if it's written by
write() or send(), as one call.

> or should it
> remain at the sentence "We RECOMMEND that implementors of this
> ~   specification familiarize themselves with TCP application programming
> ~   concepts." IMHO, a little more handholding wouldn't hurt.

  I think that this document isn't the place to get into programming
guidelines.  If people want to know about TCP application programming,
there are books && lots of source available.  This document should
concentrate on RADIUS && TCP interaction issues.

  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, 03 Jul 2008 12:14:18 +0000
Message-ID: <[e-mail]>
Date: Thu, 03 Jul 2008 14:13:02 +0200
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (X11/20071114)
MIME-Version: 1.0
To: Alan DeKok <[e-mail]>, [e-mail]
Subject: Re: TCP transport draft
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

some small glitches:

2.2.  TCP Ports

~   IANA has already assigned TCP ports for RADIUS transport, as outlined
~   below:

~      * radius          1812/udp
~      * radius-acct     1813/tcp
~      * radius-dynauth  3799/tcp

1812/tcp.

2.6.3

~      * Packet from an unknown client (using the key as defined above)
~      * Packet with an invalid code field
~      * Packet that is less than the minimim RADIUS packet length
~      * Packet that is more than the minimim RADIUS packet length

more than the maximum.

Should there be some more TCP usage profile guidelines in it, like
recommending TCP PSH when a RADIUS message is complete, or should it
remain at the sentence "We RECOMMEND that implementors of this
~   specification familiarize themselves with TCP application programming
~   concepts." IMHO, a little more handholding wouldn't hurt.

Greetings,

Stefan Winter

- --
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkhswk4ACgkQ+jm90f8eFWY7bgCeI497U6BcTdsGT/iOy9CSIbbQ
TTwAoIXYaIVDfXQJpfOR/OjmH4d2sLHU
=M56L
-----END PGP SIGNATURE-----

--
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, 03 Jul 2008 10:36:39 +0000
Message-ID: <[e-mail]>
Date: Thu, 03 Jul 2008 12:34:46 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>
Subject: TCP transport draft
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  I've just submitted a draft describing TCP as a transport for RADIUS.
 Much of the text re-iterates existing specifications, and says that
nothing has changed.

  A few TCP-specific issues are noted.

http://www.ietf.org/internet-drafts/draft-dekok-radext-tcp-transport-00.txt

  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, 01 Jul 2008 14:18:57 +0000
Date: Tue, 1 Jul 2008 07:17:29 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: Review of draft-ietf-radext-design-03.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Section 1.1

Suggest chasnging:

"  The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.  RADIUS protocol
   changes, or specification of attributes that can be used to, in
   effect, provide new RADIUS commands (such as Service-Type) are out of
   scope.  Since protocol changes require greater expertise and deeper
   review, such changes should not be undertaken outside the IETF and
   when handled within the IETF require "IETF Consensus" for adoption,
   as noted in [RFC3575] Section 2.1.

   As with protocol changes, this document does not provide guidance to
   document authors seeking to change the RADIUS operational model.
   While RADIUS server implementations may keep state, the RADIUS
   protocol is stateless, although information may be passed from one
   protocol transaction to another via the State Attribute.  As a
   result, documents which require stateful protocol behavior without
   use of the State Attribute are inherently incompatible with RADIUS as
   defined in [RFC2865], and need to be redesigned.

   See [RFC5080] Section 2.1.1 for a more in-depth discussion of the use
   of the State Attribute."

To:

"  The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.  RADIUS protocol
   changes, or specification of attributes that can be used to, in
   effect, provide new RADIUS commands (such as Service-Type) require
   greater expertise and deeper review, as do changes to the RADIUS
   operational model, as described in Section 3.3. Such changes should 
   not be undertaken outside the IETF and when handled within the IETF 
   require "IETF Consensus" for adoption, as noted in "IANA Considerations 
   for RADIUS" [RFC3575] Section 2.1."

Add Section 3.3: 

"  3.3 RADIUS Operational Model

   The RADIUS operational model includes several assumptions:

     * The RADIUS protocol is stateless; 
     * Provisioning of services is not possible within an Access-Reject; 
     * Distinction between authorization checks and user authentication; 
     * Authentication and integrity protection of RADIUS packets; 
     * The RADIUS protocol is a Request/Response protocol; 

   While RADIUS server implementations may keep state, the RADIUS  
   protocol is stateless, although information may be passed from one
   protocol transaction to another via the State Attribute.  As a
   result, documents which require stateful protocol behavior without
   use of the State Attribute are inherently incompatible with RADIUS as
   defined in [RFC2865], and need to be redesigned.  See "Common
   RADIUS Implementation Issues and Suggested Fixes" [RFC5080] 
   Section 2.1.1 for a more in-depth discussion of the use
   of the State Attribute.

   As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is
   to deny access to the requested service.  As a result, RADIUS does
   not allow the provisioning of services within an Access-Reject. 
   As a result, documents which include provisioning of services
   within an Access-Reject are inherently incompatible with RADIUS
   and need to be redesigned.

   As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request
   may not contain user authentication attributes or a State
   Attribute linking the Access-Request to an earlier user
   authentication.  Such an Access-Request, known as an 
   authorization check, provides no assurance that it 
   corresponds to a live user.  RADIUS specifications
   defining attributes containing confidential information
   (such as Tunnel-Password) should be careful to prohibit
   such attributes from being returned in response to an
   authorization check.  Also, [RFC5080] Section 2.1.1 notes that 
   authentication mechanisms need to tie a sequence of 
   Access-Request/Access-Challenge packets together into one 
   authentication session.  The State Attribute is RECOMMENDED
   for this purpose. 

   While [RFC2865] did not require authentication and integrity
   protection of RADIUS Access-Request packets, subsequent
   authentication mechanism specifications such as RADIUS/EAP
   [RFC3579] and Digest Authentication [RFC5090] have mandated
   authentication and integrity protection for all
   RADIUS packets.  It is expected that specifications for new
   RADIUS authentication mechanisms will continue this practice.
   As noted in [RFC5080] Section 2.1.1, integrity protection 
   should also be extended to Access-Request packets performing
   authorization checks.

   The RADIUS protocol as defined in [RFC2865] is a request-response
   protocol spoken between RADIUS clients and servers.  A single 
   RADIUS Access-Request packet will solicit in response at most a single 
   Access-Accept, Access-Reject or Access-Challenge packet, sent to the IP 
   address of the RADIUS Client that sent the original Access-Request.  
   Similarly, a single Change-of-Authorization (CoA)-Request packet
   will solicit in response at most a single CoA-ACK or CoA-NAK packet,
   sent to the IP address of the Dynamic Authorization Client (DAC)
   that sent the original CoA-Request. A single Disconnect-Request packet
   will solicit in response at most a single Disconnect-ACK or 
   Disconnect-NAK packet, sent to the IP address of the Dynamic 
   Authorization Client (DAC) that sent the original CoA-Request."

NITs:

Section 1

"such an "Expert Review"" -> "such as an "Expert Review""

Section 1.1

"In order enable" -> "In order to enable"

Prior to the first recommendation, insert:

"Encouraging SDOs to request review of RADIUS attribute specifications by 
sending email to the AAA Doctors or equivalent mailing list;"

"Development of a program to encourage SDOs to make" -> "SDOs to make"

"proposed in this document;" -> "proposed in this document, with reviews
posted to the RADEXT WG or equivalent IETF mailing list;" 

Section 2.1.1

"most significant octet first" -> "in network byte order"

"this usage is NOT RECOMMENDED" -> "this usage is NOT 
RECOMMENDED."

Section 2.1.3

"complex structures" -> "complex structures;"
"well-known types" -> "well-known types;"

"implement a new attribute, as the" -> "implement a new attribute. The"

"to send a new attribute" -> "to send a new static attribute"
"dictionary and policy management" -> "dictionary" 

"required in the RADIUS server's" -> "required in the policy management 
code and in the RADIUS server's"

"error prone implmentations, and interoperability problems." ->
"error prone implementations, interoperability problems, and even
security vulnerabilities."

"most of the complex attributes" -> "most of the existing complex 
attributes"

Section 2.1.4

"does not originate from, or is checked" -> "originates from the user
and is not validated" 
"on an unauthenticated host." -> "on the user."

Section 2.1.5

"RADIUS also SHOULD NOT be extended to new commands via attributes." ->
"New attributes or new values of existing attributes SHOULD NOT be used 
to define new RADIUS commands." 

"Specifications SHOULD NOT" -> "Specifications also SHOULD NOT"

Section 3.1.1

"attribute ID" -> "attribute" 

Section 3.1.3

"via IETF process" -> "via the IETF process"
"SDO specificiations" -> "SDO specifications."



--
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, 01 Jul 2008 12:17:13 +0000
Date: Tue, 1 Jul 2008 05:15:32 -0700 (PDT)
From: Bernard Aboba <[e-mail]>
To: [e-mail]
Subject: Completion of RADEXT WG last call on "RADIUS Authorization for NAS Management"
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

The RADEXT WG last call on "RADIUS Authorization for NAS Management" has 
completed.  Comments were received, corresponding to Issues 257 and 258 in 
the Issues Tracker.  

To view the discussion relating to these issues, click on the following 
link:
http://ops.ietf.org/lists/radiusext/2008/threads.html

--
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, 01 Jul 2008 09:31:11 +0000
Message-ID: <[e-mail]>
Date: Tue, 01 Jul 2008 11:29:34 +0200
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: [e-mail]
CC: Milan Sova <[e-mail]>
Subject: Re: I-D Action:draft-ietf-radext-radsec-00.txt
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

| Apart from that, the title, abstract, some sections in the main body
| were updated to reflect the splitting. No real content changes in it.

It has been brought to my attention that the feature of Trusted CA
Indication (which I thought is not there before TLS 1.2) is already
present in TLS 1.1 - at least RFC-wise, I didn't check any
implementations. Anyway, the section dealing with this should be
corrected, I suggest the following text:

~   The list of Certification Authorities that a node which acts as a
~   client is willing to accept SHOULD be signaled within the TLS
~   Extension "Trusted CA Indication" during the TLS handshake, as
~   described in [8], section 3.4 (or equivalent extensions in future TLS
~   versions).  Omitting this indication makes it impossible to
~   deterministically select the right certificate if a RadSec node which
~   is acting as a server for multiple roaming consortia (in possession
~   of multiple certificates from different CAs) is contacted by a
~   client.

( [8] being RFC4266)

Greetings,

Stefan Winter

- --
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIafj++jm90f8eFWYRAmoCAKCG0yrTwTvHfhMfj/hHvy7Z+rtr0ACcDN8j
PCkQZToKFPvXcJFrJnMhxME=
=gmRO
-----END PGP SIGNATURE-----

--
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, 01 Jul 2008 06:48:46 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>
Cc: "'David B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt
Date: Tue, 1 Jul 2008 13:47:02 +0700
Message-ID: <002d01c8db46$4e5f4800$eb1dd800$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjbQ+C/o5AkRFYUTrWdWx2hNMdJRwAAT3dQ
Content-Language: en-us

Alan DeKok [mailto:[e-mail]] writes:
> Glen Zorn wrote:
> > Uh-huh...what's your point?  Everything that is copyrighted is also
> subject
> > to "fair use", at least in the US, & this would certainly constitute
> fair
> > use.
> 
>  "cut and paste" of the pages is fair use only if *quotes* are
> included.
>  Including the pages verbatim would likely not fall under fair use
> guidelines.

First, man pages are portions of a larger document (the manual) and as such
reproducing one is by definition a quotation from the full document.  Be
that as it may, however, see
http://www.freebsd.org/copyright/freebsd-doc-license.html &
http://www.freebsd.org/copyright/freebsd-license.html for the ability to
reproduce BSD man pages (the most likely candidate for rcp, anyway).  

> 
>   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, 01 Jul 2008 06:30:58 +0000
Message-ID: <[e-mail]>
Date: Tue, 01 Jul 2008 08:29:41 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: "'David B. Nelson'" <[e-mail]>,  [e-mail]
Subject: Re: Additional comments ondraft-ietf-radext-management-authorization-03.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> Uh-huh...what's your point?  Everything that is copyrighted is also subject
> to "fair use", at least in the US, & this would certainly constitute fair
> use.

 "cut and paste" of the pages is fair use only if *quotes* are included.
 Including the pages verbatim would likely not fall under fair use
guidelines.

  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, 01 Jul 2008 06:02:05 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>, "'David B. Nelson'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt
Date: Tue, 1 Jul 2008 13:00:00 +0700
Message-ID: <002c01c8db3f$c1f2da40$45d88ec0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjbPMKilZXLKDrySwe2xdAeQuCwVgAAbn3w
Content-Language: en-us

Alan DeKok [[e-mail]] writes:

> David B. Nelson wrote:
> > Well, yes.  I suppose there is no copyright issue with cut and paste
> of UNIX
> > "man" pages into an RFC.
> 
>   s/copyright/license/
> 
>   Everything is copyrighted by someone, unless explicitly place in the
> public domain.

Uh-huh...what's your point?  Everything that is copyrighted is also subject
to "fair use", at least in the US, & this would certainly constitute fair
use.

> 
> > Does anyone else on the list think that including "man" pages in
> appendices
> > is the best way to go?
> 
>   No.
> 
>   I would suggest referring to a specific version of the "man" page as
> a
> stable reference.  e.g.:
> 
>     "foo", as described in MyOS Release 1.2 "man" page.  Other systems
>     may have similar definitions.

OK, the problem is that while the reference may be stable, it may not
necessarily be readily available after some period of time: i.e., stable but
useless.

> 
>   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: Tue, 01 Jul 2008 05:36:31 +0000
Message-ID: <[e-mail]>
Date: Tue, 01 Jul 2008 07:35:22 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.14 (X11/20080502)
MIME-Version: 1.0
To: "David B. Nelson" <[e-mail]>
CC: [e-mail]
Subject: Re: Additional comments ondraft-ietf-radext-management-authorization-03.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
> Well, yes.  I suppose there is no copyright issue with cut and paste of UNIX
> "man" pages into an RFC.

  s/copyright/license/

  Everything is copyrighted by someone, unless explicitly place in the
public domain.

> Does anyone else on the list think that including "man" pages in appendices
> is the best way to go?

  No.

  I would suggest referring to a specific version of the "man" page as a
stable reference.  e.g.:

    "foo", as described in MyOS Release 1.2 "man" page.  Other systems
    may have similar definitions.

  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, 01 Jul 2008 05:09:45 +0000
From: "Glen Zorn" <[e-mail]>
To: "'David B. Nelson'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Additional comments ondraft-ietf-radext-management-authorization-03.txt
Date: Tue, 1 Jul 2008 12:07:24 +0700
Message-ID: <002301c8db38$63d40530$2b7c0f90$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcjWqBjcX9Y3RWDZQwe1oKjYZIXyNgBKopewALHr3XAAEX7N4AAVzF1A
Content-Language: en-us

David B. Nelson [[e-mail]] writes:

...

> Does anyone else on the list think that including "man" pages in
> appendices is the best way to go?

Slight clarification: I don't think that it's necessarily the _best_ way,
but it is _a_ way & in the absence of another...BTW, if you're going to
include rsh at all, you should mention Kerberos.  Unfortunately, Kerberos is
not transport security, so it kind of messes up your structure.

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