Forwarded mail.... (fwd)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Forwarded mail.... (fwd)
Forwarded message:
>From mac4bww Tue Jan 31 21:22:59 1995
Subject: Forwarded mail.... (fwd)
To: mac4msi (Melanie S. Irvin)
Date: Tue, 31 Jan 95 21:22:58 EST
From: Brian W. Whitson <mac4bww>
X-Mailer: ELM-MIME [version 1.0 PL0]
Forwarded message:
>From ted4adp Tue Jan 31 16:43:42 1995
Subject: Forwarded mail.... (fwd)
To: mac4bww (Brian W. Whitson)
Date: Tue, 31 Jan 95 16:43:39 EST
From: Amy D. Petersek <ted4adp>
X-Mailer: ELM-MIME [version 1.0 PL0]
Forwarded message:
>From eng4dgb at hibbs.vcu.edu Thu Jan 26 13:57:24 1995
Message-Id: <9501261857.AA28794 at hibbs.vcu.edu>
Subject: Forwarded mail.... (fwd)
To: ted4adp
Date: Thu, 26 Jan 95 13:57:22 EST
From: Donna G. Bryant <eng4dgb at hibbs.vcu.edu>
X-Mailer: ELM-MIME [version 1.0 PL0]
Forwarded message:
>From rarust at hamlet.uncg.edu Thu Jan 26 12:40:24 1995
Date: Thu, 26 Jan 1995 12:40:16 -0500 (EST)
From: "Rachel A. Rust" <rarust at hamlet.uncg.edu>
X-Sender: rarust at hamlet
To: Donna Bryant <eng4dgb>
Cc: larson at turing.uncg.edu
Subject: Forwarded mail.... (fwd)
Message-Id: <Pine.SOL.3.91.950126123929.21801F-100000 at hamlet>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
---------- Forwarded message ----------
Date: Wed, 25 Jan 1995 13:27:07 -0500 (EST)
From: JAMES D. SPROUSE <jdsprous at hamlet.uncg.edu>
To: "Rachel A. Rust" <rarust at hamlet.uncg.edu>
Subject: Forwarded mail.... (fwd)
---------- Forwarded message ----------
Date: Mon, 23 Jan 1995 13:28:30 -0500 (EST)
From: Heather A. Worthington <haworthi at hamlet.uncg.edu>
To: jdsprous at hamlet.uncg.edu
Subject: Forwarded mail.... (fwd)
---------- Forwarded message ----------
Date: Mon, 23 Jan 1995 00:07:40 -0500 (EST)
From: Jill Renee Snyder <jrs12 at acpub.duke.edu>
To: heather worthington <haworthi at hamlet.uncg.edu>
Subject: Forwarded mail.... (fwd)
---------- Forwarded message ----------
Date: Sun, 22 Jan 1995 21:32:40 -0500 (EST)
From: Sonal Dinesh Thekdi <sdt1 at acpub.duke.edu>
To: Michael Adam Bolch <mab8 at acpub.duke.edu>
Cc: Jill Renee Snyder <jrs12 at acpub.duke.edu>
Subject: Forwarded mail.... (fwd)
---------- Forwarded message ----------
Date: Sun, 22 Jan 1995 00:23:30 -0500 (EST)
From: Lindsay Brooke Renner <lbr1 at acpub.duke.edu>
To: Sonal Dinesh Thekdi <sdt1 at acpub.duke.edu>
Subject: Forwarded mail.... (fwd)
HA HA HA! Now you have it! I HATE chain letters, don't you. However,
this one is easier than most because you only have to forward it instead
of making copies and sending them through the mail. Sorry anyways!
---------- Forwarded message ----------
Date: Thu, 19 Jan 95 11:32:39 EST
From: Jennifer Lea Rhawn <jlr7y at curry.edschool.virginia.edu>
To: lbr1 at acpub.duke.edu
Cc: dancap at aol.com
Subject: Forwarded mail.... (fwd)
Hi! I'm out to plague your life now. I haven't sent a chain
mail letter in ages, but I thought you might enjoy this!
Jenn Rhawn
According to Kristen Marie Anonick:
> From kma3x Sun Nov 13 15:28:19 1994
> From: Kristen Marie Anonick <kma3x>
> Message-Id: <199411132028.PAA45766 at curry.edschool.Virginia.EDU>
> Subject: Forwarded mail.... (fwd)
> To: jmm3u at Virginia.EDU (Julia MacMillan)
> Date: Sun, 13 Nov 94 15:28:18 EST
> Cc: jlr7y (Jennifer Rhawn)
> X-Mailer: ELM [version 2.3.1 PL11]
>
> According to Teresa Lynn Divers:
> >From daemon Mon Nov 7 15:12:49 1994
> From: Teresa Lynn Divers <tld6h at fermi.clas.Virginia.EDU>
> Message-Id: <199411072012.PAA114431 at fermi.clas.Virginia.EDU>
> Subject: Forwarded mail.... (fwd)
> To: tdd2n at curry.edschool.Virginia.EDU (Todd Douglas Divers)
> Date: Mon, 7 Nov 94 15:12:47 EST
> Cc: kma3x at curry.edschool.Virginia.EDU (Kristen Marie Anonick),
> bem2b at uva.pcmail.virginia.edu (Brooke McMinn),
> mjallard at mail.vt.edu (Jonathan Mallard)
> X-Mailer: PENELM [version 2.3.1 PL11]
>
> According to Theodora Lippitt Gongaware:
> >From daemon Mon Nov 7 13:31:14 1994
> Resent-From: "Leslie D. Edwards" <lpe8y at uva.pcmail.virginia.edu>
> Resent-Date: Mon, 7 Nov 94 12:53:06 EST
> X-Mailer: UVa PCMail 1.7.1
> Resent-To: tld6h at fermi.clas.virginia.edu
> Resent-Date: Sat, 5 Nov 1994 15:38:25 -0500
> Resent-From: djm5a at uva.pcmail.virginia.edu
> Resent-Message-Id: <199411052038.PAA02014 at uva.pcmail.Virginia.EDU>
> X-Mailer: Mail User's Shell (7.2.3 5/22/91)
> Resent-To: lpe8y at uva.pcmail.virginia.edu
> Date: Thu, 3 Nov 1994 17:23:41 -0500 (EST)
> From: Theodora Lippitt Gongaware <theodora at phoenix.princeton.edu>
> To: djm5a at virginia.edu
> Subject: Forwarded mail.... (fwd)
> Message-Id: <Pine.SUN.3.90.941103172316.17870U-100000 at phoenix.Princeton.EDU>
> Mime-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>
>
> ---------- Forwarded message ----------
> Date: Sun, 30 Oct 1994 00:00:18 -0400 (EDT)
> From: Allyson Chari Goldstein <allysong at phoenix>
> To: theodora at princeton.edu
> Subject: Forwarded mail....
>
>
>
> ---------- Forwarded message ----------
> Date: Thu, 27 Oct 1994 18:08:11 -0500
> From: Elissa M. Blum <emblum at afar.med.cornell.edu>
> To: allysong at Princeton.EDU
>
> >>> >
> >>> >>
> >>> >> \\\|||/// \\\|||/// \\\|||///
> >>> >> . ======= . ======= . =======
> >>> >> / \| O O | / \| O O | / \| O O |
> >>> >> \ / \v_'/ \ / \v_'/ \ / \v_'/
> >>> >> # _| |_ # _| |_ # _| |_
> >>> >> (#) ( ) (#) ( ) (#) ( )
> >>> >> #\//|* *|\\ #\//|* *|\\ #\//|* *|\\
> >>> >> #\/( * )/ #\/( * )/ #\/( * )/
> >>> >> # ===== # ===== # =====
> >>> >> # (\ /) # (\ /) # (\ /)
> >>> >> # || || # || || # || ||
> >>> >> .#---'| |----. .#---'| |----. .#---'| |----.
> >>> >> #----' -----' #----' -----' #----' -----'
> >>> >>
> >>> >> This message has been sent to you for good luck. The original
> >>> >> is in New England. It has been sent around the world nine times. The
> >>> >> luck has now been sent to you.You will receive good luck within four
> >>> >> days of receiving this message - Provided you, in turn send it on.
> >>> >> This is no joke. You will receive good luck in the mail. But no
> >>> >> money.
> >>> >> Send copies to people you think need good luck. Don't send money as
> >>> >> fate has no price.Do not keep this message. This message must leave
> >>> >> your hands in 96 hours.
> >>> >> A United States Air Force Officer received 470,000 Dollars.
> >>> >> Another Man received 40,000 Dollars and lost it because he broke the
> >>> >> chain.
> >>> >> Whereas in the Philippines, Gene Welch lost his wife 51 days after
> >>> >> receiving the message. He failed to circulate the message. However,
> >>> >> before his death, he received 7,555,000 dollars.
> >>> >> Please send twenty copies and see what happen in four days.
> >>> >> The chain comes from Venezuela and has written by Saul De Groda,
> >>> >> A Missionary from South America. Since the copy must tour
> >>> >> the world, you must make twenty copies and send them to friends and
> >>> >> associates - After a few days you will get a surprise
> >>> >> This is true, even if you are not superstitious.
> >>> >> Do not the following: Constantine Dias received this chain in 1958.
> >>> >> He asked his secretary to make twenty copies and send them out. A few
> >>> >> days later he won a lottery of two million dollars. Carlos Daditt, an
> >>> >> office employee, received the message and forgot that it had to leave his
> >>> >> hands in 96 hours.He lost his job.
> >>> >> Later, after finding that message again, He mailed twentycopies. A
> >>> >> few days later he got a better job. Dalan Fairchild recege
> >>> >> and, not believing - Threw the message away. Nine days later he died.
> >>> >> In 1987, The message received by a young woman in California
> >>> >> was very faded and barely readable. She promised herself that she
> >>> >> would retype the message and send it on, But she t leave her hands within
> >>>96
> >>> >>hours. She finally typed
> >>> >> the letter as promised and got a new car.
> >>> >> Good Luck but please remember: 20 copies of this message must leave
> >>> >> your hands in 96 hours... You must not sign on this message...
>
>
>
>
>
>
>
>
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13581;
1 Feb 95 21:04 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13577;
1 Feb 95 21:04 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21063;
1 Feb 95 21:04 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <UAA25324 at pad-thai.cam.ov.com>; Wed, 1 Feb 1995 20:36:47 -0500
Received: from YAZ-PISTACHIO.MIT.EDU by MIT.EDU with SMTP
id AA02522; Wed, 1 Feb 95 20:33:41 EST
Received: by yaz-pistachio.MIT.EDU (5.57/4.7) id AA20362; Wed, 1 Feb 95 20:33:39 -0500
Message-Id: <9502020133.AA20362 at yaz-pistachio.MIT.EDU>
To: "John Wray, Digital DPE, (508) 486-5210 01-Feb-1995 1843" <wray at tuxedo.enet.dec.com>
Cc: danisch at ira.uka.de, cat-ietf at mit.edu
Subject: Re: Anonymity by mechanism ?
In-Reply-To: Your message of "Wed, 01 Feb 1995 18:51:55 EST."
<9502012351.AA11778 at us1rmc.bb.dec.com>
Date: Wed, 01 Feb 1995 20:33:37 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at mit.edu>
>> Or it could ignore out-of-sequence major-status codes completely (I
>> believe they're supposed to be informational, so that the other output
>> parameters from GSSAPI functions should still be valid). If RFC-1509
>> doesn't explicitly state this, I think that the new version should.
>> Does anyone have any problem with this?
They are currently not informational. I've been saying for months
that they should be (and I think you were disagreeing with me, but if
you're changing your mind, I'm not going to hold you to your old
opinion :-), and that rfc1508 should be updated to say so.
I'd change the sequencing indicators to be supplementary info bits in
the C bindings.
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22322;
2 Feb 95 0:18 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22318;
2 Feb 95 0:18 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24079;
2 Feb 95 0:18 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <XAA28910 at pad-thai.cam.ov.com>; Wed, 1 Feb 1995 23:54:28 -0500
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA13213; Wed, 1 Feb 95 23:50:00 EST
Received: by dcl.MIT.EDU (5.0/4.7) id AA28398; Wed, 1 Feb 1995 23:50:01 +0500
Date: Wed, 1 Feb 1995 23:50:01 +0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9502020450.AA28398 at dcl.MIT.EDU>
To: danisch at ira.uka.de
Cc: danisch at ira.uka.de, wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
In-Reply-To: Hadmut Danisch's message of Wed, 1 Feb 1995 21:38:10 --100,
<9502012038.AA02126 at elysion.iaks.ira.uka.de>
Subject: Re: Anonymity by mechanism ?
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Content-Length: 810
Date: Wed, 1 Feb 1995 21:38:10 --100
From: danisch at ira.uka.de (Hadmut Danisch)
> GSSAPI would certainly support this, but it would all be hidden from the
> application programmer, and it would all be localized in the GSSAPI
> mechanism implementation. If a mechanism wants to constantly be
> negotiating new subkeys to protect messages sent via gss_seal(), that's
> certainly the mechanism's perogatative.
I do not agree with that (at least at the moment :-)
This model forces the application using GSSAPI to use a linear logical
structure.
Well, that just means that you have sequencing, which is a GSSAPI
provided service. You're right that if you want to be able to accept
messages out of order, constantly changing subkeys would tend to defeat
this goal.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00642;
2 Feb 95 5:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00636;
2 Feb 95 5:00 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01804;
2 Feb 95 5:00 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00605;
2 Feb 95 5:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00538;
2 Feb 95 4:45 EST
Received: from nova.unix.portal.com by CNRI.Reston.VA.US id aa01567;
2 Feb 95 4:45 EST
Received: from jobe.shell.portal.com (dwm at jobe.shell.portal.com [156.151.3.4]) by nova.unix.portal.com (8.6.9/8.6.5) with ESMTP id BAA24252; Thu, 2 Feb 1995 01:44:45 -0800
Received: (dwm at localhost) by jobe.shell.portal.com (8.6.9/8.6.5) id BAA25384; Thu, 2 Feb 1995 01:44:44 -0800
Date: Thu, 2 Feb 1995 01:44:43 -0800 (PST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: David - Morris <dwm at shell.portal.com>
To: Jerry Peek <jerry at ora.com>
cc: ietf at CNRI.Reston.VA.US
Subject: Re: URLs for RFCs and more (sigh!) on HTML RFCs
In-Reply-To: <199502011914.LAA02124 at ruby.ora.com>
Message-ID: <Pine.SUN.3.90.950202014234.24465B-100000 at jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 1 Feb 1995, Jerry Peek wrote:
> One easy thing to do, for a start, is to make that URL a *navigation*
> document that points to *instances of* the RFC. Also, if an RFC needed
> to be updated, the navigation document could be modified to point to
...
> This would make life a lot easier for casual RFC users, like me,
> who don't know what the latest versions are.
A great idea ... I second third forth etc the suggestion.
David Morris
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01299;
2 Feb 95 7:11 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01291;
2 Feb 95 7:11 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03492;
2 Feb 95 7:11 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01268;
2 Feb 95 7:11 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01188;
2 Feb 95 7:08 EST
Received: from mail02.mail.aol.com by CNRI.Reston.VA.US id aa03428;
2 Feb 95 7:08 EST
Received: by mail02.mail.aol.com
(1.38.193.5/16.2) id AA01085; Thu, 2 Feb 1995 07:08:42 -0500
Date: Thu, 2 Feb 1995 07:08:42 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Telford001 at aol.com
Message-Id: <950202070838_10813016 at aol.com>
To: snmpv2 at tis.com, snmp at psi.com, egypt-net at cs.sunysb.edu, iab at isi.edu,
ietf at CNRI.Reston.VA.US, anf-announce at netcom.com, anf-disc at netcom.com,
ipng at sunroof.eng.sun.com, rolc at maelstrom.acton.timeplex.com,
cisco at spot.colorado.edu
Cc: Telford001 at aol.com, Joseph_S._Ayoub at gmlaw.com
Subject: Severance of Relationships
As of January 26, 1995,
Telford Tools, Inc.,
formerly known as
Tudor Technology, Inc.
a Massachusetts corporation in good standing,
which was founded in 1993
by
Joachim Martillo
and
which sells
services related to software development and network debugging
as well as
communications equipment
has severed all relationships with
Penril Datability Networks,
Penril Datacomm Networks, Inc
and
Penril Datacomm, Inc.
All inquiries should be directed to:
E-Mail: Telford001 at aol.com
Voice: 617-298-1617
FAX: 617-298-1745
US-MAIL: 17 Pleasant Hill Avenue
Dorchester, MA 02126-2813
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01309;
2 Feb 95 7:11 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01296;
2 Feb 95 7:11 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03494;
2 Feb 95 7:11 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01269;
2 Feb 95 7:11 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01190;
2 Feb 95 7:08 EST
Received: from mail04.mail.aol.com by CNRI.Reston.VA.US id aa03433;
2 Feb 95 7:08 EST
Received: by mail04.mail.aol.com
(1.37.109.11/16.2) id AA057306621; Thu, 2 Feb 1995 07:03:41 -0500
Date: Thu, 2 Feb 1995 07:03:41 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Telford001 at aol.com
Message-Id: <950202070339_10812899 at aol.com>
To: snmpv2 at tis.com, snmp at psi.com, egypt-net at cs.sunysb.edu, iab at isi.edu,
ietf at CNRI.Reston.VA.US, anf-announce at netcom.com, anf-disc at netcom.com,
ipng at sunroof.eng.sun.com, rolc at maelstrom.acton.timeplex.com,
cisco at spot.colorado.edu, jcurran at nic.near.net, nomcom at nic.near.net
Cc: Telford001 at aol.com, Joseph_S._Ayoub at gmlaw.com
Subject: Announcement
As of January 26, 1995,
Joachim Martillo
(Joachim Carlo Santos Martillo Ajami)
formerly
Manager of Internetworking Research
at
Penril Datability Networks
190 North Main Street
Natick, MA 01760
Corporate Headquarters
1300 Quince Orchard Boulevard
Gaithersburg, Maryland 20878-4106
no longer works for
Penril Datability Networks.
Joachim Martillo may be reached as follows:
Voice: 617-298-4107
E-MAIL: martillo at delphi.com
US-MAIL: 15 Pleasant Hill Ave
Dorchester, MA 02126-2813
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03209;
2 Feb 95 10:16 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03205;
2 Feb 95 10:16 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07137;
2 Feb 95 10:16 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <JAA07796 at pad-thai.cam.ov.com>; Thu, 2 Feb 1995 09:37:41 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA24679; Thu, 2 Feb 95 09:27:47 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <JAA07566 at pad-thai.cam.ov.com>; Thu, 2 Feb 1995 09:30:38 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA18079; Thu, 2 Feb 95 09:30:25 EST
Message-Id: <9502021430.AA18079 at winkl.cam.ov.com>
To: Dan Nessett <Danny.Nessett at eng.sun.com>
Cc: jim at bilbo.suite.com, kerberos at mit.edu, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
In-Reply-To: Your message of "Wed, 01 Feb 1995 14:00:46 PST."
<199502012200.OAA05923 at elrond.ss-eng.eng.sun.com>
Date: Thu, 02 Feb 1995 09:30:24 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Dan writes:
>Unfortunately, it is very hard to guess whether this sort of replay detection
>would be appropriate for all apps. Consequently, I am currently of the
>opinion that both GSSAPI and Kerberos should provide a way for an application
>to provide a sequence number on a seal/mk_priv and sign/mk_safe call, as
>well as return a sequence number on a unseal/rd_priv and verify/rd_safe
>call and to set up the security context so the underlying mechanism doesn't
>perform sequencing checks. This would allow the application to do its own
>replay detection and sequencing in case the underlying mechanism's method
>is inappropriate.
A desirous application is completely free to set up and manage whatever
sequencing and/or replay detection scheme it seems appropriate and
represent the corresponding sequence numbers, timestamps, or other
data elements within its tokens. Such application-managed data would
be uninterpreted by GSS-API or Kerberos; it would just be a part of
the token and doesn't need to be visible as a distinguished item at
the interface. The only conflict potential I can see would arise
if the application were layered atop a mechanism which performed its
own sequencing and/or replay detection (in a conflicting fashion)
even when the caller requested that these optional services not
be enabled for the context. RFC-1508 strongly recommends that
mechanisms honor a caller's request to disable the message stream
integrity services on a per-context basis; if mechanisms honor
this recommendation, I think a pure application-level approach,
wholly independent of GSS-API and Kerberos, should "just work" today.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04021;
2 Feb 95 11:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04009;
2 Feb 95 11:00 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08166;
2 Feb 95 11:00 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <KAA08490 at pad-thai.cam.ov.com>; Thu, 2 Feb 1995 10:03:37 -0500
Received: from inet-gw-1.pa.dec.com by MIT.EDU with SMTP
id AA28146; Thu, 2 Feb 95 10:00:32 EST
Received: from us1rmc.bb.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94)
id AA00313; Thu, 2 Feb 95 06:50:33 -0800
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA11994; Thu, 2 Feb 95 09:50:57 -0500
Message-Id: <9502021450.AA11994 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Thu, 2 Feb 95 09:50:57 EST
Date: Thu, 2 Feb 95 09:50:57 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 02-Feb-1995 0913" <wray at tuxedo.enet.dec.com>
To: marc at mit.edu
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, marc at mit.edu
Subject: Re: Anonymity by mechanism ?
>>> Or it could ignore out-of-sequence major-status codes completely (I
>>> believe they're supposed to be informational, so that the other output
>>> parameters from GSSAPI functions should still be valid). If RFC-1509
>>> doesn't explicitly state this, I think that the new version should.
>>> Does anyone have any problem with this?
>
>They are currently not informational. I've been saying for months
>that they should be (and I think you were disagreeing with me, but if
>you're changing your mind, I'm not going to hold you to your old
>opinion :-), and that rfc1508 should be updated to say so.
Oh yes - I remember why I may have said that (I think) :-)
It was precisely because you can't decrypt out-of-order packets if the
underlying mechanism uses cipher-chaining between packets, rather than
re-syncing at the start of each packet. Such mechanisms wouldn't be able to
provide any integrity or confidentiality services on out-of-order packets.
So it looks like we have a choice:
i) Continue to treat out-of-order packet receipt as an error (which means
that out-of-order gss_seal/wrap packets won't be decoded for the
recipient).
ii) Treat out-of-order notifications as informational only, and require that
gss_unseal/unwrap correctly return the packet content to the user
(assuming that the integrity check passed) for out-of-sequence
packets. This would mean that GSSAPI couldn't support mechanisms that
use inter-packet crypto-chaining for integrity and/or confidentiality,
or at least for these mechanisms, out-of-sequence notification would
always be accompanied by an GSS_S_BAD_SIG error status (and
gss_unseal/unwrap would never return content data for out-of-sequence
packets).
Option (i) has the advantage that all mechanisms behave the same at the GSSAPI
level. Option (ii) has the advantage that mechanisms that re-sync on every
packet will allow the application to choose whether to use out-of-sequence
data, but not all mechanisms will allow this.
I guess I'm leaning towards option (ii) at the moment. Maybe desired treatment
of out-of-sequence packets should be an extra input into the mechanism
negotiation process, so that if the application really wants this behavior,
then it can request a mechanism that provides it.
One other question is, is it worth changing? What sort of application would
request out-of-order notification, and still want to deal with out-of-order
packets? I don't think that the examples discussed recently (apps using a main
data-channel and a seldom-used control channel for out-of-band signalling) are
really appropriate here, since GSSAPI doesn't constrain the behavior of the
mechanism's sequencing detection after receipt of an out-of-sequence packet.
For example, let's say I'm the receiver part of such an application. My
data-channel has five packets sitting in it, waiting for me to process. I get
a priority message on my control channel, so I process that ahead of the
data-channel messages, and get an out-of-sequence notification from GSSAPI
(which is OK, as I know the packet's out of sequence). However, when I go back
to my first data-channel message and pass that to gss_unseal/unwrap, I may or
may not (GSSAPI doesn't specify) get an out-of-sequence error on that packet,
and on the remaining four. I think the only model than makes sense for this
sort of application is to use two contexts, with independent sequencing. So,
is there a class of application that would want GSSAPI to determine whether a
gss_wrap packet is out-of-sequence (along with GSSAPI's undefined recovery
behavior), but might still want to use the data in the packet?
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06779;
2 Feb 95 11:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06775;
2 Feb 95 11:47 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09264;
2 Feb 95 11:47 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <LAA10047 at pad-thai.cam.ov.com>; Thu, 2 Feb 1995 11:01:21 -0500
Received: from inet-gw-3.pa.dec.com by MIT.EDU with SMTP
id AA05769; Thu, 2 Feb 95 10:57:38 EST
Received: from us1rmc.bb.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94)
id AA05926; Thu, 2 Feb 95 07:07:50 -0800
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA12823; Thu, 2 Feb 95 10:07:29 -0500
Message-Id: <9502021507.AA12823 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Thu, 2 Feb 95 10:07:29 EST
Date: Thu, 2 Feb 95 10:07:29 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 02-Feb-1995 0953" <wray at tuxedo.enet.dec.com>
To: danisch at ira.uka.de
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, danisch at ira.uka.de
Subject: Re: Anonymity by mechanism ?
>> An application that wanted to do this could use two different GSSAPI security
>> contexts.
>
>So you want to use two different contexts for programs like rsh and rlogin ?
>Uuugh. :-(
The service you seem to be asking for is independent packet-sequencing on two
separate channels. The GSSAPI way to do that is to use two separate security
contexts. Now, some mechanisms might be able to create one context from
another (e.g. by spinning off a derived key from the session key) via a method
that's less expensive than re-authenticating. There was some talk of adding
such a service (creation of a new context from an existing context) to the base
GSSAPI. If such a service were to allow the possibility of token-exchange, it
could be implemented above any mechanism (reverting to re-authenticating if the
mechanism doesn't support derived keys). Maybe we should consider specifying
such a service for GSSAPI-V2?
In general, though, I'd have thought that if your application creates two
logical channels over a single transport connection, then you can avoid the use
of two security contexts, provided you make your calls to gss_wrap after you've
multiplexed your two logical channels down to the single transport-stream (and
gss_unwrap before you de-multiplex). It's really only if you're using two
independent transport connections that you're forced into using two security
contexts.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07268;
2 Feb 95 12:34 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07264;
2 Feb 95 12:34 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10314;
2 Feb 95 12:34 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <LAA11124 at pad-thai.cam.ov.com>; Thu, 2 Feb 1995 11:46:17 -0500
Received: from Sun.COM by MIT.EDU with SMTP
id AA10906; Thu, 2 Feb 95 11:36:18 EST
Received: from Eng.Sun.COM ([129.145.1.18]) by Sun.COM (sun-barr.Sun.COM)
id AA00360; Thu, 2 Feb 95 08:36:12 PST
Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1)
id AA10689; Thu, 2 Feb 95 08:35:55 PST
Received: from elrond.ss-eng.eng.sun.com by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id IAA18287; Thu, 2 Feb 1995 08:35:50 -0800
Received: by elrond.ss-eng.eng.sun.com (SMI-8.6.9/SMI-SVR4)
id IAA06372; Thu, 2 Feb 1995 08:35:45 -0800
Date: Thu, 2 Feb 1995 08:35:45 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <199502021635.IAA06372 at elrond.ss-eng.eng.sun.com>
To: linn at cam.ov.com
Subject: Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
Cc: jim at bilbo.suite.com, kerberos at mit.edu, cat-ietf at mit.edu
X-Sun-Charset: US-ASCII
John writes:
>
> A desirous application is completely free to set up and manage whatever
> sequencing and/or replay detection scheme it seems appropriate and
> represent the corresponding sequence numbers, timestamps, or other
> data elements within its tokens. Such application-managed data would
> be uninterpreted by GSS-API or Kerberos; it would just be a part of
> the token and doesn't need to be visible as a distinguished item at
> the interface. The only conflict potential I can see would arise
> if the application were layered atop a mechanism which performed its
> own sequencing and/or replay detection (in a conflicting fashion)
> even when the caller requested that these optional services not
> be enabled for the context. RFC-1508 strongly recommends that
> mechanisms honor a caller's request to disable the message stream
> integrity services on a per-context basis; if mechanisms honor
> this recommendation, I think a pure application-level approach,
> wholly independent of GSS-API and Kerberos, should "just work" today.
John,
Your suggestion that applications could place sequence number data within
their own messages is a valid workaround, given the existing interface.
In fact, while exploring the gssapi code in the MIT Kerberos distribution
it appears to me that sequence number checking is not carried out by either
verify() or unseal(), so the application is going to have to do this for
the existing implementation anyway.
[ the bit of code I am looking at is in k5unseal.c and it is the comment :
/* XXX this is where the seq_num check would go */
NB: both verify and unseal call the routines in k5unseal.c]
However, I think someone else has said during the discussion of this issue that
sequencing is a security service and is naturally part of the services that
would be offered by GSSAPI. While I would not suggest changing the existing
definitions, I think it is appropriate to consider adding a way to get
consistent and useful sequence number / timestamp checking using the interfaces
being developed for GSSAPIv2.
This is why I suggested adding something to the seal/unseal/sign/verify
[or whatever their new names will be] that allows the application to pass
in sequence number or timestamp data that will be included in the associated
tokens. The advantage is it relieves the application programmer from defining
a field in the application protocol messages to carry what might be considered
"lower layer" data. For example, if the sign/seal routines allowed the
application to pass in an opaque 64-bit quantity and verify/unseal returned
this quantity, then the application could use it for sequencing (whether
it carried sequence number or timestamp data).
I am not ready to draw swords on this suggestion, I merely mention it as a
possibility. As someone who will be using GSSAPI, I always can use the
workaround you described. However, the GSSAPI interface MUST then have a
way for the application programmer to specify that NO sequence number or
timestamp checking should be carried out. Otherwise, the mechanism will
report errors when none exist (e.g., in the multi-threading cases I have
mentioned in previous messages).
Dan
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07377;
2 Feb 95 12:38 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07373;
2 Feb 95 12:38 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10414;
2 Feb 95 12:38 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA11672 at pad-thai.cam.ov.com>; Thu, 2 Feb 1995 12:08:15 -0500
Received: from Sun.COM by MIT.EDU with SMTP
id AA15246; Thu, 2 Feb 95 12:05:19 EST
Received: from Eng.Sun.COM ([129.145.1.18]) by Sun.COM (sun-barr.Sun.COM)
id AA07184; Thu, 2 Feb 95 09:05:14 PST
Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1)
id AA10795; Thu, 2 Feb 95 09:04:56 PST
Received: from elrond.ss-eng.eng.sun.com by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id JAA20096; Thu, 2 Feb 1995 09:04:59 -0800
Received: by elrond.ss-eng.eng.sun.com (SMI-8.6.9/SMI-SVR4)
id JAA06392; Thu, 2 Feb 1995 09:04:56 -0800
Date: Thu, 2 Feb 1995 09:04:56 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <199502021704.JAA06392 at elrond.ss-eng.eng.sun.com>
To: Jim_Miller at suite.com
Subject: Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
Cc: kerberos at mit.edu, cat-ietf at mit.edu
X-Sun-Charset: US-ASCII
> From jim at bilbo.suite.com Wed Feb 1 15:21:59 1995
> To: Danny.Nessett at Eng
> Subject: Re: Interoperability questions regarding the Kerberos GSS-API Mechanism
> Cc: kerberos at ATHENA.MIT.EDU, cat-ietf at MIT.EDU
[text deleted]
>
> I can see how your window mechanism would work.
>
> Just for grins, here's an expanded description on the idea in my previous
> post.
>
> Each ticket would describe a range of sequence numbers using an initial
> random number and a message count. In this way a ticket would be "good
> for" a certain number of messages, in addition to being valid a certain
> length of time.
>
> Client Side:
>
> Each time a client sends a message, it would get the "next number" from
> the ticket (credential, actually) and use it as the message sequence
> number. If the "next number" > (initial number + message count), then the
> client would have to get a new ticket.
>
>
> Server Side:
>
> Server receives the message, decodes/decrypts it and examines the endtime
> of the appropriate ticket. If the ticket has expired, then the message is
> rejected (i.e. Messages secured using these kinds of sequence numbers
> would expire when the ticket used to secure them expires.). Assuming the
> ticket has not expired, and the other checks pass, the server examines the
> sequence number. The sequence number must fall within the range of
> numbers described in the ticket used to secure the message (duh).
>
> To cut down on the amount of replay information that would have to be
> searched, the server maintains a number (N) indicating the lowest number
> in the range below which all numbers have already been received.
>
> Hmm, that doesn't sound very clear. Assume that all sequence numbers from
> "initial number " through N have arrived. Now, if a message comes in with
> a sequence number < N you don't have to search through the replay cache to
> know its a replay.
>
> So, instead of simply searching the replay cache, you first compare the
> message's sequence number with N. If the sequence number <= N you know
> its a replay. If the sequence number is > N, you search the replay cache.
> If a replay record exists that contains a matching client, server, and
> sequence number, then the message is a replay. The replay cache search
> will also tell you when it is time to increment N.
>
> My N is kind of like your sliding window, but it only tracks the lower-end
> of the window.
>
> Finally, the replay cache expunge code could be modified to remove records
> with sequence numbers < N. Of course, this implies the various Ns
> associated with the tickets are somehow stored in the replay file. I have
> an idea on how to do this, but I don't feel like going into details in
> this post.
>
Jim,
I think both schemes are similar. Let me try to analyze them from a strengths
and weaknesses point of view :
Fixed Sequence Number Range Scheme
----------------------------------
Strength : Packets will never be discarded erroneously because they arrive
very late. This is a weakness of the Sliding Window scheme, although the
probability of this happening can be made small by an appropriate choice
of window size.
Weakness : The application will have to guess the rate at which packets will
be generated during the ticket validity period. However, using sufficiently
large validity periods should mitigate the performace hit of resynchronizing by
resending a ticket.
For sufficiently large sequence number spans, the amount of space
allocated by the server to handle the book keeping associated with keeping track
of which packets have arrived and which haven't could be large. Since the
span length is under the client's control, the server would loose control
of its resources. Of course, the server could impose a maximum limit to
the span size, but then for certain client packet rates, this might
induce an unacceptible performance hit on the application.
Sliding Window
--------------
Stength : No need to estimate the rate of packet traffic and optimize by
computing a sufficiently large sequence number span.
Weakness : Packets could be dropped, requiring a resynch by the application,
if they arrive too late.
If the window value becomes large, the amount of server memory
required to handle the book keeping could become large. The server could
limit the window values as it could with a window span, but again this might
not be appropriate for certain clients. Since the window slides both at
the bottom and the top in this approach (as opposed to just the bottom
in the fixed range approach), the amount of resources should be somewhat
less for a given packet generation rate and delay distribution.
===
The above analysis doesn't demonstrate one approach is significantly better
than the other. The only additional argument I will make for the sliding
window approach is it follows accepted practice in sequencing for reliable
transport and link-level protocols.
Dan
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07472;
2 Feb 95 12:44 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10510;
2 Feb 95 12:44 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07437;
2 Feb 95 12:44 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07183;
2 Feb 95 12:33 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-levinson-multipart-related-00.txt
Date: Thu, 02 Feb 95 12:33:02 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502021233.aa07183 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The MIME Multipart/Related Content-type
Author(s) : E. Levinson, H. Alvestrand
Filename : draft-levinson-multipart-related-00.txt
Pages : 6
Date : 01/31/1995
The Multipart/Related content-type provides a common mechanism for
representing objects that are aggregates of related MIME body parts. This
document defines the Multipart/Related content-type and provides examples
of its use.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-levinson-multipart-related-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-levinson-multipart-related-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-levinson-multipart-related-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950131135000.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-levinson-multipart-related-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-levinson-multipart-related-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950131135000.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07964;
2 Feb 95 13:31 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11287;
2 Feb 95 13:31 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07949;
2 Feb 95 13:30 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07202;
2 Feb 95 12:33 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-levinson-cid-00.txt
Date: Thu, 02 Feb 95 12:33:06 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502021233.aa07202 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : CID: The Content-ID Uniform Resource Locator
Author(s) : E. Levinson
Filename : draft-levinson-cid-00.txt
Pages : 3
Date : 01/31/1995
The Uniform Resource Locator (URL) scheme, "cid", allows compound or
aggregate objects in a multipart mail message to refer to one another by
their body part labels.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-levinson-cid-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-levinson-cid-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-levinson-cid-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950131134725.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-levinson-cid-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-levinson-cid-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950131134725.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09921;
2 Feb 95 15:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09917;
2 Feb 95 15:25 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13648;
2 Feb 95 15:25 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <OAA15245 at pad-thai.cam.ov.com>; Thu, 2 Feb 1995 14:47:55 -0500
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA08101; Thu, 2 Feb 95 14:44:58 EST
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4 + 8.6.9, dpg hack 5dec94) with UUCP id LAA19480; Thu, 2 Feb 1995 11:44:32 -0800
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA19359; Thu, 2 Feb 95 11:44:31 -0800
Date: Thu, 2 Feb 95 11:44:31 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9502021944.AA19359 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: John Linn <linn at cam.ov.com>
Subject: A difference in the use of channel bindings
Cc: cat-ietf at mit.edu
Reply-To: dpg at ocsg.com
John:
I discovered that channel bindings are used in the MIT
GSS-API code in a way not covered in
draft-ietf-cat-kerb5gss-01.txt. If the code is doing
the right thing then the draft needs to reflect the code's
behavior.
The difference is associated with the GSS-API function
gss_accept_sec_context(). The GSS channel bindings
passed to gss_accept_sec_context() are passed through
to the function krb5_gss_accept_sec_context().
There, if the bindings are not NULL, the binding's
initiator address is used to verify the AP-REQ token's
sender address.
The draft specifies the channel binding's role in the GSS
authenticator but not in address verification. Also,
since krb5_gss_accept_sec_context() is using the
initiator address to verify the token's sender address,
the contents and byte ordering of channel bindings need
to be specified.
-dpg
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10235;
2 Feb 95 15:33 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13835;
2 Feb 95 15:33 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10189;
2 Feb 95 15:33 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10035;
2 Feb 95 15:29 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-rekhter-IPv6-address-format-01.txt
Date: Thu, 02 Feb 95 15:29:39 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502021529.aa10035 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : An IPv6 Global Unicast Address Format
Author(s) : Y. Rekhter, P. Lothberg
Filename : draft-rekhter-IPv6-address-format-01.txt
Pages : 10
Date : 01/31/1995
This document defines an IPv6 global unicast address format for use in the
Internet. The address format defined in this document is consistent with
the IPv6 address allocation architecture [1], and is intended to facilitate
scalable Internet routing.
The format defined in this document doesn't preclude the use
of other address formats.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rekhter-IPv6-address-format-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rekhter-IPv6-address-format-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rekhter-IPv6-address-format-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950131173543.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-rekhter-IPv6-address-format-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rekhter-IPv6-address-format-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950131173543.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10236;
2 Feb 95 15:33 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13836;
2 Feb 95 15:33 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10188;
2 Feb 95 15:33 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10008;
2 Feb 95 15:29 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-lang-tag-02.txt
Date: Thu, 02 Feb 95 15:29:11 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502021529.aa10008 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Tags for the identification of languages
Author(s) : H. Alvestrand
Filename : draft-ietf-mailext-lang-tag-02.txt
Pages : 12
Date : 02/01/1995
This document describes a language tag for use in cases where it is
desired to indicate the language used in an information object.
It also defines a Content-language: header, for use in the case where
one desires to indicate the language of something that has RFC-822-like
headers, like MIME body parts or Web documents, and a new parameter
to the Multipart/Alternative type, to aid in the usage of the
Content-Language: header.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mailext-lang-tag-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mailext-lang-tag-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mailext-lang-tag-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950201152113.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-lang-tag-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-lang-tag-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950201152113.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10287;
2 Feb 95 15:34 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13867;
2 Feb 95 15:34 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10270;
2 Feb 95 15:34 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10116;
2 Feb 95 15:31 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: host-conf at sol.cs.bucknell.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-dhc-dhcpv6-00.txt
Date: Thu, 02 Feb 95 15:31:23 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502021531.aa10116 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : Dynamic Host Configuration Protocol for IPv6
Author(s) : J. Bound, Y. Rekhter, S. Thomson
Filename : draft-ietf-dhc-dhcpv6-00.txt
Pages : 15
Date : 02/01/1995
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6): provides a
mechanism to autoconfigure inter-link Host IPv6 addresseses [IPv6-ADDR],
provides parameters to autoregister [DYN-DNS-UPD] and receive Domain Name
System (DNS) [RFC-1034&1035] Host names, and provides a mechanism to
specify additional configuration options in the protocol.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-dhcpv6-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcpv6-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-dhcpv6-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950202153042.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-dhcpv6-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-dhcpv6-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950202153042.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10492;
2 Feb 95 15:41 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14071;
2 Feb 95 15:41 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10461;
2 Feb 95 15:41 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10453;
2 Feb 95 15:40 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14049;
2 Feb 95 15:40 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10448;
2 Feb 95 15:40 EST
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call2: Tags for the identification of languages to Proposed
Standard
Date: Thu, 02 Feb 95 15:40:41 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9502021540.aa10448 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Mail Extensions Working Group
to consider "Tags for the identification of languages"
<draft-ietf-mailext-lang-tag-02.txt> for the status of Proposed
Standard.
This is the second last call for the Language Tag document as there
were substantive changes made during the previous last call period.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by
February 16, 1995.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11936;
2 Feb 95 16:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11930;
2 Feb 95 16:55 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16191;
2 Feb 95 16:55 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11904;
2 Feb 95 16:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11868;
2 Feb 95 16:53 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa16139; 2 Feb 95 16:53 EST
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-20.dialip.mich.net [141.211.7.188]) by merit.edu (8.6.9/merit-2.0) with SMTP id QAA24814; Thu, 2 Feb 1995 16:52:37 -0500
Date: Thu, 2 Feb 95 21:05:06 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Message-ID: <3859.bill.simpson at um.cc.umich.edu>
To: ipng at sunroof.eng.sun.com
Cc: ietf at CNRI.Reston.VA.US
Reply-to: bsimpson at morningstar.com
Subject: Re: Severance of Relationships
> From: Brad Wilson <wilson at cps201.cps.cmich.edu>
> Come on ... what it REALLY necessary to make some people who PAY for email
> to read that you had quit? Twice?
>
8 times here! Now we know which mailing lists haven't thrown him off, yet.
> From: another user who apologized for accidentally sending it to the list
> Like, why do I care, you worthless little vandal?
My feelings, exactly.
Seems more like a commercial advertisement. Against our Acceptable Use
Policy. Let's all ask for his Delphi account to be closed.
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18009;
2 Feb 95 22:41 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18005;
2 Feb 95 22:41 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22366;
2 Feb 95 22:41 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <VAA23590 at pad-thai.cam.ov.com>; Thu, 2 Feb 1995 21:28:29 -0500
Received: from Sun.COM by MIT.EDU with SMTP
id AA26376; Thu, 2 Feb 95 21:25:28 EST
Received: from Eng.Sun.COM ([129.145.1.18]) by Sun.COM (sun-barr.Sun.COM)
id AA03147; Thu, 2 Feb 95 18:25:16 PST
Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1)
id AA14978; Thu, 2 Feb 95 18:25:01 PST
Received: from icenine.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id SAA00820; Thu, 2 Feb 1995 18:25:08 -0800
Received: by icenine.Eng.Sun.COM (5.0/SMI-SVR4)
id AA05001; Thu, 2 Feb 1995 18:27:54 +0800
Date: Thu, 2 Feb 1995 18:27:54 +0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Don Stephenson <Don.Stephenson at eng.sun.com>
Message-Id: <9502030227.AA05001 at icenine.Eng.Sun.COM>
To: cat-ietf at mit.edu
Subject: SNP - session oriented overlay for GSS-API
Content-Type: X-sun-attachment
----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 10
Attached is the USENIX paper on the SNP work done at the Univ.
of Texas, Austin. This is a possible alternate interface to
provide a session oriented overlay for GSS-API, similar in
some respects to Ted Ts'o's CATS proposal and P. Rajaram e-mail
proposal. These are attempts to provide a simpler interface to
GSS-API that might have greater potential for widespread use.
- Don
----------
X-Sun-Data-Type: compress
X-Sun-Data-Description: compress
X-Sun-Data-Name: snp.ps.Z
X-Sun-Encoding-Info: uuencode
X-Sun-Content-Lines: 2173
X-Sun-Content-Length: 134529
begin 600 snp.ps.Z
M'YV0)4) F=(B")DW8LJTD.$"AH(2)8;(*1.&SALY.D"0L9,&SAP0-5S4D!$#
MQ) W</+(27,T0,7+ at L,$"9HX<,T!("4,FS9 at P;$ 4R5,&Q)0W9NC<"3/Q
M80DJ:>BP*9.QSIPR;M+@<;$QC5.)%.FD>>.&2$6J(*B at J0,B"!PY($#<@&E#
M!PT8=FO8S$'#*90P9\K,R1BC+\2_ at 9_((5,&8]LY8["2<2KD31TW/=V<J8PG
M(PP0GVW$D"$WAPRG1-Z,J=,&*QTC9.D,3INF]9P64MZT">.&MNT62>@ ]>E;
M<(O*;,B8M+RRL=,BF$^V:>U&]D,B5I(,E+X;,Y,T;M!V]0BBA1805K%J+?_F
M>O:!1^O(B9PQ;1DL("S3 at 5/G94R^#='0T TZQ&####E05L89X$$AAVI3E$%'
M1G24@<<8+KS5W at M4W$>$3R_)4,-G/8WQ$F-FV(?%AR:"D!"#O;W at Q!XH]H$B
M""\(L8<8X"E7HQ,X3K&'A6. at T8<3"KR Q1Y3 at .!$'T+ at 2(44>] A!V]SL''6
MD3BFD>5'9 at !UE9,XVC%'&GH4%4-)-Y#61AU! ?D"&F>F"0(.(LEUVIMQXJ at E
M9G"P854.,.P1)AM7V5A&BB\ L1*,>WB)Z!Y;?/8G&8$.6FA)+<30QQZ=PM2'
M FF840:B17VF:A=CD/43'7V4JJ=. at KTAJ%AD:92&';-:(46MMX[56T^\AG<&
M") !50:I7^YQ::9S$+J'K\#V)^RLQ()@)II%\0D:"$0:N<>O<]AJ;:XMM*FK
M'0K0R2T(WL(0JZFHIB7%O+26&VRNU.I[;F_;VIDN:=F6Q)-R?"HP);P5K80'
M"*O),5%UNUFY'AEUP*%1QB#0 $)@+SUXF7(>APL"?R=RC+'&>H&L@,B8 at 03N
MA6B<W!^R$E;L,)>-7IHL'&7L\8*D'UE91U%/1MEH=W4 96H99.RAP!S"T6%5
MB2^]P+3394 - at M%%H0PECD"T"D<:@@D] at MEH?X3%V"\8T41%6Y2D:GEV*P!#
M%W(:(800E7Z[JIQN]/:9G$D4\:V<)L)U.(YDF-&"<&FP(73A=^K:(I"%*_ B
M>#C"5AT5>0 -0DY]QS:WQ0^;49T<#Z=>W=]O/.QWE$!2O9)F.(H1QIA8*,#4
ME7G at *$14<Y.'7XYU5$[&$&@PM0?T3 G1?'*-\0Q=JYD=FSB9DFT,A]!FO-'>
M57247UT?I T?1O%FPV]'[""P\09/WV*.,HZ-+[X%W)$3VAQ25!(YN<Y*>%"
MW"I"ILA-+ at R5 Z 9YD"C7>%H@"!8W at %AMP4,W at V#QA(<WS0B.<JQ 6Y%D!H<
M4 ("S*U,(XL"SZ)B at [/TQ09N16K!'=) !CJ at 80\Y)$-%PB"^^F'E##Z4V1SJ
M((:/26A42LLA&LK $I< $0TM$*)PBC at 5S2318TML(LAPB$4\(,4,>Q at -#B"&
M12T2<64*Z"(2:Y:3,#KQ)6$D8POR<,8K9G&(7#QB$DEC1Y#!1 9SR:,0DA1$
M//C1C8'T8LU*4L at G1A&+M0%,T(((R!?2H73+>H'NP(-$4+9PDU:Z(_]2V3^#
MD4$Y3RH5W'BX.!S)X0ZU?,%\<GD&..B-3"\8 at \8>]X(CY-*#P*2>'*SGO,;L
M80YAL$-1<E*2![$A*$UZX0M\-R9#GJ9'%E)EDW*$O#"0QY!-,F0PVPA(_*Q0
M8\%,Y>,:^:T<FM$,9E! #OF(3S:V8(I5Q",3_7G/%.5PASVLV<'\R<\4H>\G
M18):&3 at 2&7UB$:%)E"(56_(2L-5-<'@KCPM*8L\S(FN at ^S3I2$%PL"X,;3(Y
MS&1@@'E+?V*T9G-9Z!IY:,%1\DY.NR1F+W,IS,5)+:BGW,,N*3E078XA at R"X
MY:>.,*]3)4JF9=C-'-805<%89")P.\(>(J6<H;KL!6;5F"MA6<08K+$-;U!.
MD]P* I[R*E!&4:6%RC"&/M@/)7#CB1V J+&%!M.7;[OD&92*RZ+2<J@> ^?#
M0 :>"LG!#D"QF5BJTQC,!N6%0S7L4(,G6+AA1FA%?5Q-+105N"'JAS4M*FGB
MI\H7?J8,<=C#.T5%HXPI0$1ZP:UN62 at B&GSJA2]<*'!9&K.Y,E<Y%ZDJJJ0[
MIOVYT at Y0M.4<8-M8C<T6)<4SI&W!E=O=JO&X'%NN<,V+2/1ZMZ[$4L!<9;!&
MWD!7#M0M0WXU"Q.6;@2';) #8R'V7LDBRV*:40#**MO9S)96:>@;<%'-4#E$
MR;-C=<5,."G+V<MF=L$=]JSP_JLT"E]3=S!9HT^/]9F2Q. &>_AN2D"PW/V]
MLP_E at XN< K6%/0BVOT4ZPZA\O!$ at H^%8F/G46MDHY#3Z5SE!;B$9/O7CUU*Y
MR*^5\I5Y)8?M?FK$7-ZNEIV\T-(*;9?X23*97UE#)3\98@'>,HV9+.?31%G-
MNTUR%U:VHQZ=#+ Y!DJ?7D $U#X5/YXTI2 at 17$K3A6</75 OC"WS=\5Q9!C
M>&K_]D?IX]$A>1]!)\12V20,EN31R/6M')/(U":^D#0&3J>$D)6B;(E-5ON+
M)UQ:^>:DX2@)4LMT?Q=*!+B) 25[2,]B0-0[E/S3?%Q= at QO>< <W[,C9:( V
MOEXPA20 at *YI( X&C6 *>7WX&KM*T"(ZLP##604P^$Z.#SB[&L9*(EV/>,MEG
M[JVQA"W4!3>I'QV$% at 4K?.H%4C!XJ:Q:%/OA[T:[O;&<RH#L;G>5:A<IRG:I
M#0=-*D#96,,1Q>'P[#=$>]K5'A*VM2U+.0&!:DP9.,B9O>B8EWP-"I VM:T-
M<SG0X>;XVNT+^F4N7/5F>>0J^K7P$P,8.'U=.,).$G9SK."]X'LBL at %+)?8^
M,K68QC6HP1Z^Y]P5%_$S.3'P_L9 at A]Z(+<<*L$$-;H"#&+C at !EK/U at L"5A3\
MR)WN=L<[U.=4I[[S;'P;OP//I+"ZC]XM5 [9FYR$D)H0V> S9@<JG,))3#EL
MOGC$'*PN/P_5T4_E8? at QN-*LH( ]P"WA!Z[(U9C]N1AI"&,MNL,4)S)<C=V^
M#BUZX:IQZL0]?.8&"N"P93TK/A1\: Z!>E\*<#NS(GW+8\IO,!M0X(3[4&'Z
M<<@/?GL/@D,EBE3T2I2AQ*3?A==+,F,] S2E:2^1<FJE"W,QLGXRE:AN_F&>
M-Q5YH #F5Q2,5Q%[0'EO "M8I55<=083 at 7%@]2E[('_ at 5G\ML%(96!(+$X#A
MY($#F"S]IW\%J!.KDX"5%RM4EU6_\X 1^%7ZM5]*4W 5.'_+8B58DF-M$%66
M$3,F S/*83)1<25N,$ 7L8/H)B%OX'^G]RURP 8RI&X. 8*G="Q/&(5+Z($/
M$T*?<87AH6XF%A00Z%49%UA[D(06 4"G(AR_)"<FU%OPQ!ALL$7XT85H^ 9P
MTP1,<C(P-(=$M% F9&Q[J#&!J !1!"H>TP0 !"HYH8A*$S0+ 0*.B"-H%"J3
MB%;&)XEP\T,E<8EI$&.:J#1J(#6-"#=KL >)"#=WD(ER<(>NI5OEX3&*IS1M
M (LMD!.SB"/6IC&1F(LO\ :ZI0"AXHOEU5^^*&#OY8L4I#&X"#<#IS&R"#>.
M]!E-THIOD&YXJ#1Y0(IS9DU!45C&] at 84Q&VE=H&^]@(41T%34(UD"%91(AG/
M at 1D. B$2HB P,H]C$"$3\C46XA$9\B *XR&TMR"@HTMH1&&8H3XIHS'#-VQL
M%G*UYV0&%C=)0 2G1&.DHF$/\P)5D!5Q<#05>9'V12.+\BD1!UCNERB!=DT?
M96"A$5+>J ![]52W13,R$RK>" )$MR^]D70\"77>PH6 at X5)-("$K,09S(),V
M>2,029"]L3UQ14I#LI0<\TFF,S2<%1 at ^9TJ/=I)J=5)BH #C-16]]RG_DY+Z
MM0>B\VD-LQ[[-FO94I06 at Y3?(EX65"/HQW X=A&")HE&Z1,?\0)R>90?$3'Q
M%G+A at R); &L:^6X2XQI8(Y,Q at R(RI)"G Y.V$A2[L08S5!T7)"&6Z7!DP"KS
M T-FH"CY] )/( 90^)%E, 5_,G O=":]T22M\A'98BQP YN\\1JQ at 8H9QA@/
MXRT'@YI)4 at 1X4"&8L99[D!,XF9GP B?59R0W at G!E )6,P9PO@)VD-)VF:9SP
M"!'000;XJ(_VV" /DH\2DA'0QU=I !3_V!X=LB(#"2-!PB(A\G0A!R13@)\N
MXI1D,P5 ,P;OR09$L"AA ">R(31T @*B01I(LG<?<0.F 4S9EDMVL(3$1"=/
M54!E AG])2>\P6+)Q 3:D4NWE 81 at A4$R'XTA08JVC6]48)R,A5T8%FN1S at +
M�\$P8TD*-^LB! D:-0DB0OQW]E<!E1 1-/YW(<JBQ[<*3*HJ0G8D&$=VAP
M P1F at J11*H))FA5T()96NJ49E*7NDB8,ZC8X,@0F"@4AFJ5\)S1F4GIL>J(%
ME*5C (7CDR1UZJ80:J9G%&%SLH2)1389BD^"FJ%EJC1 ,*)D^0(CNJADDZ)2
MTW2#EZ*EEZ(KVAM at XR19*@<PFD8D8J6 at F@:9"J.;^C6>AS1%VC-LX$ at O<$VH
MEZ77M(VQR@;%4ZB-(A^PRJN2NJMR8*ORD:MP0W5>J@"=>B/ATRASHYYT4 7C
M,W,MHC7*H7,I)ZU9TP9E-6M6&4I8TZWDE6Q7L6PM4GOPHAP-::D+I:T,@P<-
M&1A"PZ[L"D<-*0.?L5 A1ULU(BOAPZ[F&JL2 at J,\,VT5 J0 >P9#.BIR$E=5
M@@<K-"9V R]T\# HDJ!S.&\4BX-%J(-Y-41N\ (=!U7A<0<=YT/ZI*<E6S.[
M(0>GJ+%&V(J1XK(<ZXJ?(K-'&+-$^+(["(5?B(>2M at =:%XDY:;.MZ*#E01I#
MF[,<&[1("YU$6XND\K1&V[375%=2JW54&Q1#F(-'.+4\6+41 at XU]0($G*XYE
MD+)CF[(K&10CF[(0TX,WJAM,P57N4SR_ X,X<@9/A0>1\V<:TR((\DO6]1EF
MH ??,D%S9 at 0OP =?T+B.>Q+R at 39P<4 9)DT^9P9:LEA_45E"H"5CL ;S<B1)
M,K$/&S1P@ <?D1(?X:4G\Q8L)9I^^V<"-FV8VQ'+R$)-$D)-LC#FA3=3 at Z3X
M@@>UJS%Y,+S/17ZYNR!YE7\XT(4+>!;]%2JL"P>NFQ,N0[UP86^S%D)V%$+8
M.V>&]+UO^1+<.U A-"7!:[S%JZ<*0+#'NUO)>RR[*P6QZU;.6S5A4[VJ]+W:
M2[[*V[W*ZQ#H*ROKVQ$@(+QZVD(+^+ZNV[]5V+J.HTKG>R^RM >TJZ<4-"4*
MQD*[A4CW"[V<0DG *RL(;, %7%BGQ;L<S$*$PH/X"Q/"*,+* L&7&;X-+,'_
M:[[*^[VD8<,1;$CEVT3&HC 4G"(E3+S&Z[XCJ<*^Q\(?7"$T;+VSQK\X? 93
MH\,D.L I<L('G,0+O,3TZY4T= at -/G+]PT<-3_!:_!,0Y+,0!O+Q%O%]>* at 9Y
MD ,VH%NN"Q3WHQR[Y3'/6;4'\UM01TU?&Q3*!74R5CP+ W!YQS&LJ[L//+^A
MRSB^1'Z[E7 at =-U-PL(,O6(9 (AFAVW*Z>(1BPJ4^^2]Z(J:\LI.HK"ZY^;](
MRC#RQZ521W5%Y*7X at GD2 H'OH[ XXA%)H8X..G=U=W=Y9T%/(B<]1P<=@@=&
MP!)" \PD, 7 at 1@93\,(V2";8J@"[X:Z"5#--:9]: QBL6X(W,FVM6,HS;)BN
ML4*592])(LW#>C(#)!N_/$ DX*O ;,\ at B\^U2L_!?,]F0 *R"M#\+,W%L\])
MV<\#_3 *[9CQYLZ>R= D, :Y*M 5C7H8/0<.C<\=/="\JF#^_*I@"74[AL]S
MD-#XK-(@':P 3="X6M+9 B32S-$OG=*_.\/2/ 8?30(V;6LC_3!VM-,L[=/%
M ]0M73QVI,&BE&TDJTD&VQB6ELD\RCC at 1=4&RXRF*6[-JH_0RC,'D:<=H4)!
M_=+_+,^P\]+SS,[5(=$O@;6%?$I/_45O.V,><QHY>8=&^\?85#]8F%<\JX2
M_==Y:K9N*]8:T[85 at 0;<?(U*R#.2T<S/O%CA(\W4+$W6_,*=#%8N5WOM2:!#
MVI\ at XCD RFT#6J"7K7'F^#'9C,Z[ at 2BQS-;[\0;OK,% (*#N"10'&B8*6IAP
MBR.J\=O+0P:M<ADO4=S5 at 34P][F>ZG+H\]D%VGI]VE_"I=A)=#=ZW:!=&-A2
MJ"T?X86"W:!""=X64;97<=AZBB\7JJ at +PZ'>_52L&ZD/HMD[M*F,9:J^*JM7
M[&H65*KV7:KHX=+_;$?$XEYR',L%'4+_/,$_Z]\RJE0P&N#%,^ #E2VSB> D
MK> Q/<&AG'[+,MVD4=UE,-<U4]#_K-?Y'=/<O82^.L\K7C\D/:QQ1-CV<]Z+
M#6<=L6V8#-60?24V#J\\$S]8S276S= at \ P22 =U#BMPO$=ScE.1% PT!,
MKMS"P=S$_=MA)#6 at +.5A\3&;712X#=ILD-H7A[>@['(HHN26(]KEZI2^W"BF
M0 at 9L/B1)IC10Z"Q8"#=/J%0KSN=CH%1A^]A*XP9[RFW at AA^R[=9! FY9 %5
M0DD2$M at _D=@CCK;*/'"Z8W)BGNCRY>CPXMAI:$"58R at 59A2)CNK2].BN.''7
M9+M! at XZ8X:A]ER3+3.NEIQ+XLSQX<"7*L3PVB+'MYC 0[1K"#B0+T^L\H0"Z
MKARL>S>4)!P^A^N2@>M, =_@)NSH at [%<$IXE,)[E68_SZ9_F>A<B@@,T, ,E
M,1(P<!.%H75-]W0S(.].IP H\ +R! at =?T ;5L7>B)&AYL'<T at .^Z43YX8)U7
M<>UHP)%7D15XP!=3\ +IX?!<P1$IH O)^U98P1$% ,S, -UHQ<O!A-S$0-U
M4_(YP*0P(?(B7S<I'Q,V,<8*8*DC;_(T__(OWV(H3_(Q#_,XL)@YH>XTEA.(
M1&,NEB R0$U /\9 at =SHNMI@M/QHPL9ASD?1#S_0B,O56;P-U<QH at #_-@C_,]
MG_)?3QHT4 ,]U@<C<CHW(!).]_924AO&$1S#,08OPRA&T$0>__,R0!I]3V-^
M3QHF__>$'_BGLYBD ?)_/_B"C_ at SC_BG@_:+3P.0S_B ?_EWD?9T-0-M/R)O
M_QDO +G-(0=W'SI/Y3'H3D(\4! at P, 1!0!(T$ .N#_LS, 2%40.S7Q at Y4 2%
M at 0-%4 1" --Q_OS+ at .O[_$P0 /'/^]UI^X.\?HTD ,W\/M", -&</W ?Q<P
M< -[#P.O7P1!(/Q.=_SV*B)!\/I.)_N]#P,(<OW-:_U&(/RV3P0W8 0Y8/M&
MX -RIP!$P ,ST+PQX/H- ?;7O-C? !1^'P\'!(&S)P068 UH at #2 !N" &G#^
M(N $K( 2< C4/]=W]H( ^,-^PH\D:, BD .$P&CP 0K at !N2$_O?_A-_U,P)%
M $$XG=IG -L= 6R!,* ("+\:$/]BP-SQ?C(@^GF\^!<$9D 1&( Q0 <*/QWH
M\0;@$=Q^S4L!',$DZ'2 WPLD@/*/ +(^VW<7P)\, ']8< &V0#*V!'T at #%"
M)*$&-!T)B/R, !' 2#0X]DK!3 "PQ\-C %$ ].OQ)HKWP #B -_0_XP0 C
M8/N W[S[>-G/Z<! (5 ']02M(/CSUXY'=$P[Y2?)-0;W&_> <'Z!P:M'PRP
M 4- "- 0@@*FV .K'XP$ &R/T$X"(4?#2!CA6'>D3][A?X^(0*\/,>O+R!!
M"4@ XQ_[JX)!8 @,0!L _G" ]:L[=:<([$';EP-\ at +=1''	-P)CQ$Y5I^Z
M:W[_;_G5 at .8G$V;>_QL"8+#IV+[R-QH^(1C<@&"P>3VHIC,:#B$<K#M& .
MO^F' _* at #=!_-8#_\0#P%P"=8/B[/-YO!E! !U at !*>!H((3>+P?20R( XB
M#U"!(" 0!H$ 2 C!X.4Q at L'/?KV^%C@ 9X#>4(7$,/RY/S X ,>A6UF ,Q !
MOC\X. #)X)I0B$6@'OI /W@:)"+[,P(T@"2V/G[H="PA\ at N!L@\,(D0PV H]
MGEM!?G4G""+ X1<,88"] G]"(!Y60;VA#&-B'I0!SE HA XU 1)(A!E8?20A
M*<;#T7 2)Z(,N'YGL"'>@#?H!'U ].-_6C%N$)#^4 at T_(/9#?_$/D;Q!-7@/
M/X-% at H9&X%A0D^2G^I3?]'M]Q/ PID%<>!J0X5$4 MR/O at #!(>#[PM\!K %$
M #-BQM>W&8- at $!B(?6]-O$(2V/?NX<?3AQZO]GD\'1 at ._6$8) +G,/V1!-YW
M%I-B$BR'A_$UML8<&/YR( *D at 47@M\P=$F@"9X /:#J $"R.Q=F(&SMA\PH"
ML#'\R3[>6 5_H^TS at M1Q.CI'[Q<=,:%LO(VU,0>*B#U8'+,B8*0C3&J-U$61
M&/_"X7/\ at I#0^\4^>V4#".("5 44!0B1-OW8DA at %7R(*W ?LD<CT +MURZ\
M/)UP_*D[&M 1U2$6'(,(D3K: $Q8_\JAZUN0:5'X-;^F\__0(A7T at 6MB#PJ_
M&T 3(R)85(WV:O8-1'7'^7BCNB,4X$\!S("DYR*U7SM,BIPP"(@& "@#OU\P
MC 'A#_R51*?#'T5DTSF.VP\N D935?+6A.H;#9?G( +!T0 +24) ' VTD"0H
M1?1W%R#C&YQW0L 'U( $T?\* SM,=ZZ0C.7"L4 at #&*$ at W'O(S_B1A$J(_*[C
M&01^')(+JK\9B0"[(&04 at %*0$<H_'RG^0J!3;%X&,462Q5"8$Z,B0 at 220++^
MN3N'*'=,9">\BTY'3;)(':@ %N!N])1V\#GFQ/!'!A= at .01_'= N(D'A%P3V
M8 Y8$P!2'[9 ^!</<2 9A($M$0#>A7GW(6F@&"04TQ$*[L#T%_MXWRLTAN]/
M )["*'AY=.7_BXWR\>T1/[IS_&K 7?"!S8L-?KPAT/X>I2^$E*V2!+Y*A_@'
M]2&>C'^^3PA<GC<(_%9B..R)&])0UD<,:2 at SH6NT?D, %.I';ED ZU_S GYZ
MXU'RRN4G&[/D_P.(&O$+!C]-"/[(8$ at 4AD$Q"!C#'J@&PZ6[(Y%)0$ &0 4
M .W5#"B"&7 #FLJG2#"GGPF4";Q1]B4]CU<L!>7GPX,:D!"VP]]7!(=B$?1]
M#L'CD;&&N?V )(ML$^!/!\Y(\!<E^6.DM'^OD at 8@R;D at $<F8$01_VU #_K\<
MP! +I S8?:-! =R_C8 at LMY^"1'Y*$!;. at +NP_-0?+PR:1/)@9LKON/UBHA%X
M,<>QZ2C)T*$&'%0..'EWPN71F,54$K[>7'B%>#/L,3W!*3=]X"&9>H0SY5U-
ME0?VZD:+$7M2K^:]O)WW8F1DUT.<?H_H5;VY(!"Q7M4C>B4AZPV^T+DY3P?1
M\XA%SW!*O:+'.D.GYFQZ6:_H<;V;-_;&WLR#G+A3Y;T\TJ X+V?D]'MD[^>Y
MGAO@,3B?V_M\20(J_(;<T!VB"M[C*A[O;D9.O?#U%&??=#&?008X3J.W-RNG
MS:MZ1P\F4+[4J3U%)]5S4#= \U'/SO?Y0)_R- [(83+( ;P7%%)CR.-YE,])
M>KR5USU+WAJA+R"@=[Z\-6+S8L#,BWHBCX VR<5TUQI?$,R;^U/Q^;V[YC%L
M0/IT/5;OX[F C\=!3P.'D'NW(7XZS]"Q at P#GXIP)]U-UIE"]0$"QY\H[H/S3
M<%H] MKR:&@,;3'41.3E4)B0$_C>TR,)O\7%$%!X]_+J!M8*G:$3WOW/OLDW
M$><2K9U 5':NT!C*\JBH%56A?Y/KN1YK26-RP$BQ 6#4!N" Y E"<8/<Z at WS
M,W3T!N2WF%I,&]5Z;M1>T9CL24?GZ&^)HW54CNK1.CKX\J at ?G:. =(_"T9D'
M ]ZH(.VC at ?2/RE'%AT<3Z2"5?"T&D9;/1BI(,Y_K.7NF<X-RT!FYIIB#Y"I]
M<6,)>3RN-^^XI]6S>4IT;Y*$J]<Y5^?EM'I U.;]3Z+71--G*35Y-,#O+:99
M>CH^ at ^1;(S^OE +0T< W at Z@I1:+=TXU:J at B8]DII[',!812,KI$/^AM$Z/Q,
M$D;@*ZV]:I at H>V;2>YLR0 /BQNKW&>VB5,R#&G (E,"9^!;_8N@(/VRTY at 7.
MDD=/>5[-JZ?WU)XBGWS*3_&I/]6G )6?XDVTYSU+WCP-J/^TG_(\[:E0[^G,
MPZ=XDZ$FU'KJ-WE>16VH^]2 at -M2(>E#'9MJS 8K3BQJ(,#I-1=\G3:-Q(WM]
M/,@7._5"^52@,6_Q[5+8N49BG_BD,6/4YMTU AI1':C?^Y\BS^3- *WS\7#J
MZ2"J9,^-#M7'5U09:N\LI45UJ![5J2=5UP34 at YTN-:MV3[.G1?O 7<"/,* A
MM,^X5TUMA7) J4;@(PB^O/,5U:4:F9*$0B^B01C@ QR"302.[#%ECL2:61%;
MY5V4 4* !W+ AOE7P1_\ X<3<:\.PO9H!P<@(6TZ>W!-U(#CJ!?<:=SP#T.U
M\N'-ET=-E%X__2T>X^6UO"(Z\D2K/15Y]71$;($6VC'0'@;MFS- DW90,OH;
MZ!X4>BIHE2U8JFWX)$D"#"R"]HMHMC[>>!>Z8%/$A96QN/+&R^-8#6MP3:QO
MSP1NOW at 8__*?!#219!%')D69D%U_Y%E$EY#U#5979P at 6 R#1-*#_$B7Z0P<Y
M&I"@)%Q^KO&Y_D)Y20%YHKW"DKQQ X9 M"A=ZQ_''*\9DRS^UK"X7(<K^4M_
M+?!= L7?ZG1XY+4<JB%P /K(;,D;XTY:Y(>^$ ;T5^HZ",FK>YR2'K,<JD%[
M=15C EE<$Z%Q-,2^]IH$ at P (C)$:4CX*126X8>% at A\V87G"X&E:IZ 65('X%
MKGWOMS(_WFBOC.LD?'[J+ISRQN;E#W>D7HVND)7#YC\<2RK3JULQKO/.O49)
M39 at HA\!O52 7U@,F/]XX#*^D4A2N_G#(8E at H.UUM[)0%B\:U_O5 [%@,'0+9
MA(\--CO*1J=X8!VA3TR1G['UA4C[IPC)JX!UKNF5N0;$&'D-7>2W?(J&-<'J
M2.UX7*_DV"RP_C LEE_"6#+JY!%KYB6S([94;IH42(3#(W\L A$24G(,D-M
M]R.:FI LZL ::P0"IGD,';R"95[5EHI5>ZWYY+4M53 at VO<&G58%ML3VV<F'7
MNE1E"W:$K;'UM5J5V&H]9,MKI6W2 at WK"UI)Z5;WP3*.I&.VDD:LQC-"X at 4MV
MJWK\BN50R.I8'6D+?:2YJ[ =T?OM/I1(,B\/8S2LZ[85$DF=21IAY74MDXI2
M!(Z&*0AH?ZNRU!L3D?,1 =, *P.L;T6SMY WQC^QR2ME (+LC6IR3FY9]RK\
M7FWXNX3U-?S5':!(9)UB?DV%!S'^7<<]2!)B@(<5B6G6:_+,;)AD$2RO](BL
M$>921Z^9&C?DAAR'JW;.NA6T^2S9[<Y,K =P6MJ_EFMH/>*6U8&$TD 82BWY
M"2UD.;2-(?"^6MP(*W$%(%'$A37 at 4CI!G5EK&:[+I;+V]N0B04D; 64CV4RR
MHY!G^L,NN'.W;,8=N%/2Z1)7W^ at %*:VFW;><K]^>70&Y_5SC$""9D#7K%MA(
MV&6_+$/TASKPX at [ ^_KQS*QQO3PDDSZFS'R;85>NX#6T9]:O*I#K& ]1I?BK
MLS>79/9$E:AG at 6 WI;KUD>I"S7+8!0O#'E1W!O3E#L),*W/1WU'<NN3OZ-:^
M>;=C+^X at Y)$Y5]TQULM#=X2D_/.&K:\("M>A6P1_H5!,NF37[(+>08AO$^V8
M-;V2U^2FQH X\T(O\W61&I8Z$DA#B0 I[\75 at 0\VO<8^V8 at =/:_V30)2,'0\
MC+K31$="W2"@_Q, <\_(">^.Z#'EGO.N_*88S'F (^<3I2NK=)424U@:.J^J
M,!VCG?/K>0RA&D>I9_8$JL,V?4;.%N,QSE[:LZG=-IJ.46HZ]X3#;1VW1J!X
M at -04*DL/G^&4@ ?U at 1;4 ,I#8<+34Z at 6EP>75B&,3UT,:HVA^Y1ZUHT?S$2%
MWN"[:RWF?S8^"$Q!>VD at W<!+&+32F W\/[-G [U\#U0$3U3$.88K9\ICK?]S
M"?O at CE%(78\-*)ZQ=9-R4A9\&Y at G;X#!>F#F89AJ:"%]I#!TKT4 at .OI+ZIAT
M_6IZ#<3N51CJ1""8$+TD#I"N/L C6E8C$ 0Z1OK,I4;O_^9-";ST,J at F!IP0
M&)DFX CL8M;J327%!YB3KLY2?#A1<6%(,<8T%"] at #8PXL3!413M%5)BZ5*+'
M4S.H0X"J5<\#TX6;>HNO7M:[P$;UEFKBLG=(C"DJ?L;(%!H?3IJW@;-GW=C
MV%A&WLWA^3?MCK>=IN^S#I]1&!PE1ND62'=6N*DZ!%C*.8->T$,[.6'MC;RB
M^CU-IQ76H^V8Z9W&4GHW+\_>O OV&!T+U;_Y-W/"^*2EG&_JH6/MB8YMZ2]&
M.Q Y'4?D8LQ(6^L)CL=>]";<!(A(AX^#606EA)"'CD_#UU3]GLC;P)"3V1YC
M>'?7KK&S/<E at V*4Z4+V0/H?I.7YZ4A6 'F-?.E-MZ82,JA&9[VG5\5EL?6?)
M,WN4S_4 at B*XH5I%G1[:MQ &M6J220 W1K:^L <]2T/I#E9L OR$9!(.(^%+N
M7#I('3TA6"8"B-4K=\C6AU=UX'4L@ ?0^XU8'[ at 6[5A,B,1S,VXH#G,\$J at J
MUHJC+5FJ2M4: .^V0%5]HT)U0CY056R8&Y\J!GD F2&[T;X\/CU&^NS+7$^.
M;L.T-P?;1%.&>QW9#J/1%.'MP)TU>0-6#"(( :>DCWP+1# "84$^H 45<,J,
M3B^% 9C"*XR[^E1NXI$UDQ"NN00 at !K3@8O3P9S at V:N4&H-;Z @)@( J8 DX
M"NB %$!7Q *" )N( 68 120!#J,&4 at !;P %A('(D +. K(,2D #3QGOB*;
MM3/WD1!WX.*%YXNP!LHS"IA'O&PZD!+J# M7'FDH'FX0!7"!&4B=94(772,
M>@B@ +4 at M^8 =3X-UCD+I( 6H!>LLPL8 BZ .GL,ZWP%)G2%1@'F at P50YYQ@
MG7="2Y /X%D\MP'[?#PP TMP ]%D*HCH[3P%H@>UP0H7SSQ/@3J0GL4S9G#/
M4Z VD 7[/ 4RM'IF F% at 18])ZDF804 ><#YG*^90!SK at GI%"CY8.**,Q:&=[
M-P4(%%:(# ZZ678,P_FDU4(9L,\=:5<TAC/Q27JTE=[.WX="NP at 4<*;#,Q[X
M'2/:<XAG*KV= at T"*M at J;)06(T<_P"G/"D_;3X1E0 at P<1K9[C](>NTRC at 3CMH
MCZ>GZ4YD[!1N!0>D at !FY1@Z$7 at #00N ZBP'=,9ZI]"V:"VTBY0'H(/"<H[-]
MUA IFB,P! at =MGL- >K9W,*HEM("I$*M3]*F8/N)Y5.,@$R$L>C1ZWLY7(6*<
M:35 IS'#Y'@#+6!"<[X42*&<=+,F RE at C5CG+W0'Z#.P;A7304F]"F$Q!S*T
MX;3.P2$%S 7KO$2HUT60#?;YV/B0\FSO= =%6-%IP$=CZU-])Q;GDW8C^9DZ
M:QUVS8*J V!* ?EZA\QK,H "DG7D:M.,#06<@:9!A"J$8.C17(!.NX SX )$
M=+YV(])Z+N NF.M+P*YR<X#6SSWAREBL E4FVX#*(!1VSN0K9X93(J&0%$A
M#P!K^X*P40#-1@&MP at UP@:S#& SV</@D7" %9.A3K34!Z)-.UPS;2_3L6?VB
MH89[M at CV.0)E%=9TIM6S#SG3YGDULZQ3 :EU-K)6#9P)7B<?%,! at YN=X[MH-
M^PV$[ !*LI^T#ZD(*6 --&SVO!+:M'G^"=E9/2<$^TP1S at 2NHM<H8")8B3<P
MM GSC;+:98!M5P>Y;9XA-1[P$IOE#/3H<O&Y),3<1HYC]$EKB/SLH".WPD8#
M]IDL'&[SW ; PT6PSW"E)S1N&S"NR4*Y%MAZ&CI# >I<$JRSU#;/8N!/5PXJ
M';F'-+^&K @:!5 at $.."FO[-Y/@+KJ"! @23 J)7W6G#0^00%;*;]7+/Y=.(^
M%14A#?3J\'PJ=+9Y7B'3CFO;Y_'\(.: @V;:*'8N_.M2D:)-1;Q9WRO;-?B$
M\#VDMW-K*!*\P4NT 0?-K(.V#MK/D1MK1VSH31 ^]XN1W]=Y>AOI5KV[S3.,
MFM7V^6O;9\9 at 0F@UB';>*("!2^\D at +@S=AG8V!V[9X^!B5"TQ8*8^-Q]#X+S
M[.T<M"M$BDY.#EH]=P=-,J63ML>V=QH\<H/K-Y$5:G=V1M9,1$L0!3D PV^
M#"? at *. .G HVX)[Q=+X.XO9NA9<.B\#+X ",&@/V.8PH<2UMGLW @UC1YEF#
MJV=S$BCV=[2&WS,2 at AL=ZGR<4<#HOA+384UGZ%6*KJFTU+/.8H)R-^M*MT2T
M1(7(X?6:;^=L8-WPV+3X#L]VP%=_;LX'P<&##N+?;D!$,VP?8A5Z]%N U)&\
M/33KS+V^,PT/<0U P4TS<?/,8 PV64CE#+LGW(;/G4LGY),N;$MD(J0 9DW'
MUG=VKM74Z[9B<O=\QY/TTD[(/A"D,KOF'*IC0 H8DW.Z.UN)%!U7@,\</]Y@
M]#\W9U9MIGGWG+;<@4(</7(4$,KI-.*&0'([/-^!>;V=K;1ZYM;>6HB3A?!
MK&/U(E?/T2.'-^P772K>^+1^,5+O2>_OZG"X(S= at X&7C>T];;68=Q.WX at ^#:
M:/R#;VY%_K)10(9^J'.Z"8 at C/U['+3?FWL_'&^_\9Q0 SUG6JWX0^;EU:P:$
M;>\ZCJ]C"0-\?1\$.$"E:W4&]SQ4HP5P$ZL-S/VY_PSH#OU^%(D4L,GE=L1V
MV'W;; MHC<VQ/;;RQNFDG&&7]/I\OL=SVIX#(IJA0W60_L]GPDC/-E1C#B3M
M/:ZM%S2,FM0?^G>3=+F]G>V'9B#CXIDQ?*2S(*)Q#IUF<X>;81]K[3T<?+I-
M<)*W?"QT\NU<$:[<&KC=(D)/=V?& #5$]"NVSJ?;/1=NG;W&,XU@<-!77&Z/
M 9(.G^FS/N?9\-LN6VM;#<E3- 31$CP""D%LB9ZORX47_^BOPFIOYZF>P<T'
MHLCJ0'R* .M%4;_?]=66V_SZOI:$)PU7C%L*V.R%W:KK\R4RU&LU(F_8*X1Q
M9YV5'KEI^W;N.)T;7N?KUVV>YT!6^,[A67*$[#LJ&JSU?M[L%<8G1 7W;,E)
MV1POXV>\9UOWIQX&P+N SCI at W"NP;>S=L)D(S#':M6INM]SA_KUQ#]38XZ3!
M.G\?F"VWLZ9UYNWAG:^(A81>OGLTD]/2V_EK7X4>G=P_%U;G\.ZY5>P>US#>
M28(_?M)(?9&O:\EMQN^6YS$1[;EF>_#P(%'(@+G.A]89.V?K.5T;T+=PJ Z2
M?2I,Z9YMI8.[E;36S!UUVW16[ at 9:O.ZPYNV9 .UW$*^>@W8*< /DW%=G!1)/
MV(7UE2#6_?L\OV[UC-3/--,NC9_A2;-Q83['9WMG-^GJN9CK9\V0H>^:\[/6
MW9FH?^_( .2M& H@"DSAPS-K66XQ at G>BKA#8FF&G-*J153QXBO?;*""?9VV^
M0D4H/+861 at DYZ9UX\:RAY_08PMOFF3&D<O-LI6OUXW;E;F"/;V at 48 2H.1,O
M#'K:<B?I0%$&LCJGE^JL(2&L<HE>J^N 7P^"ELINLVRQ8,130()@UWF T<?T
M?&W"4;A37P*^6 at [H>G$$K,VX;K#/32 )?!_U'/)2=!<0T3H:"F"!$D\#-KVU
M7]',&C8. at 9Y]\KQ]%?_1YGD)!"N:_@:60%;@*-4^ON?K)" $FH![W@(YH LD
M[5L=Z4E[EB?? EX-IGD4D!!PM*6RSE3[#(0';%VK?W3-;@.T?DH?^+QM[X+
M',HV=: E&/LYK>'A]J*O$#&=%V5Z:\DY_^"<X15W;>[T!2)B!/2 @";0A&\;
M?NKF_*3)!468#ZA;T6<,'R_;)7?/=NDUG>&;;^XS!?RTGT\"3L (/($I< 1[
M=IJ.U6MZD3-LGZ_P!+P-R'I/&C_C\3QMG4>&EJ[RL>'+>^]I,\&; !%(T4X?
M!1 *&M "7F4+T(#)SP;H>9[-K-T^W$?<<[_NSX!?#T8]QI,> G<!!^0 <*^O
MV7O at MN,QQSWW<O/L!#!Y*E?/71IMN 'R+.5AP\ at 8YMN9EP'Y=_X&,C3E'P)2
MX->3,<,O]WMBN1<0QGX;QIW.N:I]MMS.U[ :DI_R=\_AY7K3L.%D7ND,:;T^
MYI5WZ=C?5-S/T_;NKA!B?Z>>@-8Z8BQR&NXJ&D,1JNO6NVSK^25BW^WW^B;X
MNT$-O&[J/QV&=*B_$BGZ#OB.SR6B<P!O58&?FJ0GZ0H/LQW[L6?;5!J]>_">
M8-]G]VJ80[6=?6:SA6>\#/"7_45TE05;YZ,1?&N>&^?\R070G]TF+&1HI91U
MIM'I<N<:=.>>^'\ 3PI0_^URV5^*IK--!K:??4:P$&XWG(_W_?UM4P%OT+/Q
M;.X?,$7[T6F_0Q[PK+4 Z<&6)KE9%F$">9;&10])'^#6HPUNV]E$P!-4#DI=
M>H"MY6O@ ;#6XTT%T5H,R#&E/L2=_K;2/7R<WL>&N:T$AAX*T!]8;8I>9^$3
MG'#\V9S6ZLUGKQZ$9L[9:;.>C"8 $F\?G'+2HPD'G(F#%@,&4&/3:">PS6E!
MVYG &%P)ZEOVEJ3!+:G;=[:=07ABGL\Q!RJ C9L,P)E(>XT!MS"TM0DOX"^W
M!D9JF%L4*/O)!*S??N8D07Q;8!K0!7Z!V%KD-JY0%&0 at S&.=K69^H&# at V*F!
M&MQVUK;U@&!;4&?/,084WY1W!W)(K-\)B/N]:V$ UR:S\75KP'Z6X>EVW9W"
MUMR=9_$=J1<>X&]?6\LVS$F!30<5V+ E>R at ?L(:U$78$R^Y1Q<EW9,'DL!+8
M<["<\M:"F&MOS\RS]UAKW9S>-A'P>5+!TL<?L"9>PA11"G)G'<87TJ.1 5="
M4A#&_7A"Q&)PJQD!>$ (AQ5$ at F#<+IBI66L1 at O37IO%QZ]EE,0;:9VY!&U?L
M,6P.PI4'HD$ at X)F]DZ2! at -)<8T +:F?;W%(GPCV -Y*U% at 1,;P/?8X<"K%;N
M7JUV3=1I] at Y'<!;P=VI<4 ?1N6?E0FN0_@&!>US*EN?M3]99#T@'.'7R&NI&
M#=(7R=L4(.ZE '\/( ?OH0#RWA97[]U[+L&(1CP=$A 1@'8'H #.G)ET&J at 1
M"%I)&#U0>!Q>@$$1D %*W1.85;@&/!VG1PTF0$C>:T/%_7']W:CFN9%Z()P(
MMQ(F >::#,1#63T#B!'P%<H &IH$1A?6?DA .A?% at 7+1GD;HU&EP#)M?.+WU
M:&U;BA:M:4V\U=X#P8V$45OIUK")!=?$;V?4H0#V0_JWJT&&Y%ORI[P)<H.;
MG_<6E&K(G[$V_AE_9P/_80*^>?79+ICNR'#!W/XVQT5L<IY*Q[&-:-$<O+;9
M:0A Q.WG>6 ZME$\)&D 1&(XR<65 QG&C4H 4%P9E^7 1 :@[R>]2;)F6?=
M(147GN4!32 !:)]9AB1<]A:T108TW8>WG>D>/H%2V!EB91"<$. at 2_@30X3XG
M\:4!'""0MRSX;%L@;3BD16[G'@@8"_)U3:#7UH)4:2"<K48-;D,0G)RWQWUH
MZ9I+*+5M9^7<<) +8FW=G?3AM0&![AE[>/'(>.X97*'+D7G- Z*'$AX(G^'K
MEO*4?1M>S7;$78/*WN:&%"@%3,&9EKW=;99 at $VB>Z7($()S %*QOP6&Q=]T]
M")K at $#43,#L2&QYG'%Z(T9R&T=A19VD='*C6M7*X8 9'(MIT7MOQIQNZAX+&
MV2?1[8(JD-;QI)F(,R+#YR-R>FA?N%;$ at 7Y!G470*K !(IJ4=\(U=7F;\G8J
M?"&:W'FV']AG,&%XUOYUAG2'FFC'96C,F at S0!:"#]<Z51>!U:##;F3;R6&<)
M 13"&IIS(R+>9KJ1B"BB>4;C=8DHHD&7G>EWP2"I!N9E9PBBC- at 9*GX$7IG7
MH]%VD5MQN)_]@'A;Q"8$XG.[7^0&5U -S9N7F!UVAGS!PL?!G78.&D18ZH5P
MT=M?2/#1A[Q:$2 at A0!!9P4IW#)I\\U_/5KC5 at E;:+G at 3. 1/6 at YX*8IG'MRO
MF/1Y=%0# A>LJ8I&ASZ'GHF*O*$.*.<UB7,40$;<D1*FWW4VJ=5Q+F#%I\><
M 3K;!_ at #UH+HGSJ'N,V";UL 2-AY<O--<$/%16[-'I]X!]HK+0R 9@<H;\)$
M"N!+<$ at NE0W4@Y$&N99>\!6"!RA#QC;P:0R4V+VC,39G%R,=D#&J%4G6'=7"
ML!O[TU>H'Y2, EH*@"6Z""4A>M:H#0%0P, G"^IS.R*.MIWQ?TUB$&4OWG>$
MV?_GO8&(7N!5X-3I'HU!X7;2H692XG[&L%D%MV(6B*M5$5I:>+8:4GA4W,3H
M5JAJZ^*P-L=A at 1%C"A?\97<?GI]'!9 at H Q\KQ]^="?]A at !@/[G:_ at ^2B$9IK
MQM!=\V+T!5XA"C #T'%/1]\3 3EI)>%0N.KY$&I=Q]$<2H8 at H!0'K,ERJX'[
M)BPB;A'?C<BS77P9'RI'+_8]?(&U-L>UB>X<!8>QH0 :HP)1$#:$*!J6![=U
M'TI!/'>?,7%8'M9HVLUYFAO*R*KY<-\?KZBK\6JEG2CWJVD,$^/8%#SY/=H"
MDR+\##V"!\U7!X"%=!P$]O^4A3$853CO603V7D Q?= at [4AOIE_3-@[=5%B&W
M@ ?FVHK7S6&!.2!?N!XVBY<A$UBZV3O4P>B82\EQPH+59B,2BCF MX? at S6G6
M at Q_7N^%_F"%_=P+Z>7G*SQ< FF>Z!ZA'IR4G7%X(:"/R@ GC=B;I"6XRBO,'
M6EE0YAW&)^3!A38>XA at Z13\[GQ$P/2*&[!!0]0DQCMFCGQ:YO8-<GD?H<_ at $
MO-K^F"(8 70 T*8;P '_"#5G)]H*Y=HC.+B%9TS<?):BS8_9(\QQR"F(7R+;
MYD&^A=5!&# Z6DN*8KL((;Z/!(&SF*^A9P,BM$>^08+MFWNV0Y2&^5H@)_G5
M@@9?AU at Y!(-3 :1H0(U'AE]S-CT>CBDDV!$!\GSX8)]H%%9O8AMG(H P<FB;
MA.#!G860'-AF[Q2-CU_#=R-:!*3 at ^O;9]6CAW^LFS[D!H^/7EP_9;5S at GT;*
M;6=&H23Y&O9L"^([820F=5?DSP at %7!V[V_;!*'9\'Y]E(/)M=GTDV;;T<6Y7
MW0-H<;UAT9\+R"*Z:XK at PJB>A7(R)-H Z2V+&L(/>=N] at ?;94K#_"095&[;F
MOU&+JUL4%Q6@;OH=%0 THI*VY.IGWK&*VEN/D*%I#".'7Z!)9 1^CR#3N[$0
M_!HF1?.Q:JFBVEBLE77H66O'M]6"UEU+A])EC2L=KICT68[X7!HIR?%K[I^U
MQAB0C2C!QC<VY6ZNVKBHUD$AG E/&$C":^K9;3 at WDG!,(#=YMR5]ZYW=R.%E
M9YA>R8-)"73>6<*8LEV45^,M>+$!<Q8A)N?!C6=@&JT&Q ERRY\.V0;X=3%!
M_$?$"8?DVAY'HJ$ C6'ZMREJ:5A>GI at !KG>1&_]7OZUI[EF"^#;6DA&E<[B@
MF2@"8'9VYBV.Q)T+>!YN?_R<WIA,O at ^#00I0/&%B -H<</.]&%"A =5$I(RZ
M6Z=GG>5^Y-PI1ZLU9P4A4J<1GFFF2LI(VS%L0YRXALE==$6/=78&@FA,7+EW
M.KQ*UIJL]T2*:!#A>L>PL96RVL5V- X11-ZCT 3*)"I;-$CL+7(?X,<&60J6
M$1"!-P!&B8L<7LBS:9;" >(6M,UN+5R!LLB9 at F(@F 8"AGG+VQ7)6;Y*4&)#
M9Q4T#53<#1E73G.RXT=85[*3/YINZ;,-$1QA>/81YA,IXRDX!F)VMJ#NUR5&
M;KV<8&DMQ8H/I8/&L'%W3R5 at V*-U<[+A.^ at EU(+*I6MYOCT()J4SJ?01::Z:
M=$E8JGFZG-YV+%8.D!OX^/@UA.\="@#[55#56E at Y5MX 927/B%:Z:F4=8^E6
M;I2(FV1P TH&WYIN<%,6>VN<ES>>16N"9:IF.A9KA!V5-B)V;1YADCC,16[$
MX\%'I^&)/1O5: 0N=]7ENV=>3I1>Y83DQ*&-/:):2=\5(2H at A_E34G%EI(.Y
M*MYN<X='A'?$D8:A?2FH&0AR07Y9$EZ X.5IPP$&>!] at N<<Q^6NW7MR6W;EG
M4H[65AT\DFE<SJ("MG4S)N$&*- V0)Z4US;:>K::8#FRH8W6Y.YVW;UKP",#
M":-$BPM at OI96'H);9F6A T:9 at H%K\-D]?N8$A*EUF 9H8THYQZUX8QP3QZSI
M;VT:Q,C4I7 * +-FJ[&6ET6T-];M at 0K>63?R at 8+IXN8WQPF6TD_R%CXZD3Y>
M;_(]-G[,VH9XGLD'7YM3"<YI"3($MK8_ZF at 27K%FGL567B4AI9PQA*Z:1LG*
M/9$:GZH)HEF4*$&P^+S!C]JE>9:NV9I9'+SA&AQNQ]MH$/\U at 0F<;K=%'B%7
MI$V7KT$A8L"5$*QX at !8=2$BEW7\\ 4H KPV,85RVF*]Q$SZ!>]8Y5G'O&S+W
M8ER23F8M:6CZ$*XDZH:L_917 A7'K#V#!B,-)V@,DOXDPN?G*9*]'RX(/,Z'
M7QSJ=KSU/?&?H.$8W@'ZW&0'2N8L40&Y]FDJE>VFA*#361JYH)QWNVU at B(2B
MV,UM9[[#G^ #2G3'X._6TID3<-VF^;H1@ %<FF!>XFGJ6?EP32R<MYO>EN>-
M4=:9!G>\S4B*(KX9J<&!R9K1,36^B9]<PY/T]8L at VOAF[XB!D%I\YC[J:*Z:
MG&:A[7B1IM16*Y*7SN7%!L<)'FJ>-V>=38>?BW7X(. ><UQ1!P*FE1ADCE$+
MRB$< 74G7T*-[R6B at !E*E<A<+6>M&7):6AAX8YIK?0&ZEIV5=?0EA6DX5F^6
M8^6&VO$E-IPS^ U.FYB;GI<ZGIL=I? at T:SYITF'S,!%,:7>FKLD8$"AG at NV6
M3-:"A*2'";?M! at .EG]<$7HL;'#,I\5V1Q]M($/^EE5)GMCDNYGFLYJIHG]$
MPV#AV5RVE0.E0=>SY6I81(=9SOUJL9Q at L,)U!-?</S=WQ']OF at 2YMTF$KF5$
MV?U5C?= at +X?Y19TXGNPI%'*3@>>0II[5 (3GF\@@H(4V'?QF22)Y1B9^-\RM
M>,NB! at =U5G [H$CXMIEK:F">M^)UGY8 at 3?!Y;G!>0N:8;I8\%E3\UR&N!)8!
M9I?%V6ZGW)5 at 1>J3'-Y*4",:?;(@KFD%:FXT&O:IIYEK V2>%]*!?>N9[<FL
MW0!#9TF9=0*2/J%^-[M-;-5A.[=(ZG9QGDA(RFQ^9AXRY\2Q?E::W&2=,0<"
MH 0:11H=YMKV2<?-:?BG?88#A)\6W at [98E:@N]O:AK4=;W\0Z]<3GFDO)/CF
M(B)KV&"C=^-5B51G!UI?+G[/XMK9?UH%'MR".!6X;YXG$[H5/FDMH!PP\56"
MN6!/\ Y:D=F;SSAJ6 at VZ' -)GQUS58]3I,WY#2@ 8 at C-66=/P/!91+:5(XZ&
MIJ<MB[!GI@<EL9!R0!\Z4CQS=9R?AA=& <U#V&F>/3/>H7W&!$ ;)9Z](K^5
MA M>TAFYC9_%HSD')J( 8&=])@N^#M6<[5F\?6<)VY?(I;EJ,A[CIWL.D1+;
MZ7E>&GE-&AH*;>QG92255D;">*.>ZM at NZ)"E)S,(&&">>]R*-]G(9I/:JN?,
M57RY(&)XYLT[BN+&D?Y-FM_;9S/AE:(5WA6GVV5X8F(J1\-IBJ-?X^?GG8*1
MX?4)?W(/9*"=-W>HA/R=$ B\U8*%&Q+($\HHDZ%N1UFBG?&GVS9RXG(5GK1X
M%<R4 MY= ,%Q;=:E]>9 NG/U6G7)=\YI:H'4MN)I;6T :\(;D&<HXFRW@'R#
M:!]X0* 4;9$!'@I:S:,]WV(#5,9L?6)&&<7A::?HN7DTNB>=IR68L5T%<%L0
M*N4=CF4<=NE^)FY29,*W_4R8K]Q4\&CN>W_GG+9'0I(;W16IA"*#0-N^B0*"
MHX^?XD8M7FT Q:X7)K1N4,B1Z$L$=RS?Z>#R at 8PR QS)4LB1/F;.=T=FCQ4I
M%"=J'I"CX5&R-RJAJXHC&<:5F(0=HG ::@B-Y<YFV6F.7MM>VC#>B?_G;W%^
M at I2O9:EIGP6:'ER#& *2?PLFG0BC2#5 G\X65!)\8X 9D,+533 at D4!J?*7JJ
M08I62QX+V:.$@"%X?;CDD]93JG. at 7-C(DB(?[%J)28UNEU!E&:G+)7#E:(#W
MMR&@?V#1I\"YB8B;RZ("FF>!IH"G38*4%"28EJ'= at 1]E27B0]B8'VQ89WTEY
M7QMUZ% ^F6B?<=,8('WRH?46;PJ+UNFMF30&E*+;![F#2IP98(N9KTV'-EQ1
M2;]%>/$&!5A_9F= 9LX)E<J<J:$Z1TK,:(\A2OA12I.E89M8/F2.1)X;4- =
MDH_?3\I_R)T,:*VV(G)VV^ at JBE[N;A3:!8HX9D]%3YDVXD&%_&(=JKQU:RGB
M5?K.-9TAWKZ)_<%HK<'A9O<8 1>C=P<'F(PZ8\V0,L* O%7'R4*VJ(;.RL at Q
MCC'P#M&C (2,(,!7V.&A 3#JRI at R-J/^)8[ZHN:,R.%9R:I).9[+Q<;0Z7;+
M HM:<=(!12IIRJHMJ \ at S[E-@I)0*2VY%P:DM" %V'=R9WY<RJ;6G0E<Z9'(
MY-EG9L!EL"H>;2/@)RD%<CYJ(LMXI1:I-R2K)B0ZI!8F 2G$&8%+I*)IG^65
M<^(<-R!*!F[-<LI;V9U/F_=F5,*G_%V"2)JVJ ]ED>I+I(S56[;A4U)XN"-+
MNC\VF[GB OA^:IED0-+X"BF*;LUQIT,^)M '64#G+(*\7QFI82JJJ.'[8"82
MFF:;O:. >H.=8G9V![J>>J!6AR7$F+GJ$M>C\:K8)J3H$#!?>%YVUE?&=3T!
MKHJUU947XQ3P! P!T![,.+(Y*$,IS= at 7?(53P)0 _OA[6JHZJJ=JJ]RJCHIW
MZ 70*LTH,CH?1X 4$ 3X>YLJJW8H=FHHJ9[JHA:IU9ES.O2]:S at AB HO;J/J
M63&(&7AP5MK:AJCBE&'>54 ODC$07'= ['653X65FE:J%6=C"A2N\D_DJKEZ
MKPIJ_B5PJ6JNJZZ:6C$BD 84JT[R0GV%1$"].K+ZCMEFV+: R)N7( 1I\86
M=Z!R!L$]IRT;P^J\Y794Q*X7 at 0PHWZCH>9<^F;NI=BH'<*?QVM)W,.QG4F#S
M\K-2=#H;42BQ46R]2=> V'UH8PZ J'XBF2RI#Z2GN8 W9+::LM(%!\*=\+$:
M3B&K%'"NDH0I8]"6-$Y /6>K:?Y->81=_B8-(GHZ)45*(FJM7D+U9JLAD/.<
MWLI-=FMP at GDYN-V!A(*B2'IRBP:JSA:YT6_=&WOWW+&49XN+*+ at I=0LBEZ@_
MVG%=PZYWDZ:?A)G5)@6Z?XJB]?F82FX19T5P$21M.\#.]J,5<$,:EB>(7 at 6'
MVP=X8>J IYS!UJ9=E]_9E/HF@@>Q*[T8[U21V.6N")R2AQ[)T9#7S6P20F.@
MTBUTYR7JR>0I)UWB=5>Z%JCDV2X( Q!F4**MEJ\%;?1<FS?EZ7 \ 1EH]>1X
MKT3$691ZG7N;0TC9/9^HH(-VC'Z9*&'3$?^!;*NH#4< DI(?8%$)6>J*9 %J
MJ;_1J0.?$.<"CIMP&VV8T)T%YF68YP)2 at SY0":FV[FYJ!?L35(4=+BO<^IR)
MK/X>5U&W)JZV)\AYOZ(/I!QURH**9] at +2K 2G 55&LF!$MHK\9\5N372)A2H
M J&DZJ at QW"$QOH:P\RKZX&T6J3+J[[BWY:2*JWM& SR:!H*>5 at 2X;PLLV;JO
M'A(@K)I'G_9N*"L'FQZ)/,"% B"O!JDCK-PZLO:I.F3AT,3^;;KD\^H%:AC>
MH?EP#^)IABKU1TE>/+O at O!/_I:_%FCA:JK9K/IYHJ,')DQ;KP29][FP#8;:Z
MK7:K)(\\IL<2L61LN6K&^GMY;!9;$J*O36SDQAHNG:>BT6<J:HO9F>Y*'9(%
M0Y[I-DU&E4;#'WB[V2\YU<>CJC5G7V$-0)VA.P240%1"<G.ZG6](&-URE@:<
M*DGZL*HCQRIXL#X>PQ at +L\JL_AX:NVFRJ6MDJ.JLSCP24)YJI;JH.NKVXU'.
M!"&L++*G73E$*I/Z6TYYIRBX1NM5"(=;]N9SQF=5GJ!1N[)RDNH;<%*N==OF
M?2A5/6FAY_ )XIUM3.L!ZK0B?8"CX&HI[I2[ ;,Y:EJ:@J>5)HZ*FESJA(C-
M"G3ZW#:XS8YGJ-L:]\O!E6Q;:EEHEH2_:1N;5OIYC"J720?TLY&FI9C@/;01
M!;:V"QX(BF+P*A:T:4,CF$JYGFG'*$EINED&R4&\%L'ZK<0>!:LP9H&DZTKJ
MJ.948E3\I^/)@A9MG2JUW9L?Z7:F! at !JW^"].?\Q?D3E^LKI63$$87_'2[J(
MZ6J> D%$=-TBHC at #VFIZ&]+G$XR2P!J*F at I:7!F5'%4XZGURD,Y#^S6.EN#-
M:B9V:XO!AR?1LG=%[;?F JH!]L[CBBA&@&]LDL8C3&P%Z.&&!0JB8FOJN at 1^
MDA6?7.M4(GTZ&S>3;<I1?B?]:EG$=(>L>(H2&D/Q7^AXGI(%@:(N"3[FM7 at E
M AK6$7G?V1IG F:+:1QJ)B%X at _/A*4L-X@" K:U6G>UMWENI1]&N<'-E:OG"
MI:LD)?4G,2 $B">&&0+V>I:E>E=HGHG$8AXH[-&3\Y]\2I%BF[EI[\J2SCPC
MY3 at *HC6'P]S3Z:_FJ,G9\Q at 3Y('B*AD[I!:IU" GR$+ZJ:&LAVDK#)_)X at !Y
M)TX%Q)JUZ'RR<0_"6_">))Y9' M7Q7IP&9O]L*#J;!,C^\/ZV1>_R*N7LEV>
M.PJN,O#%G.-?O3:PSI#V;4X(W<QN5EN^9M92 at $)A/-N%H3M0XL;1N/Z at F")=
M"<]";H#J' B5JK2K)4EK#X*2 at ER_.(ON;NJ9 at 6E+LDS66JLZHD(-S.4)"%V:
MN*%K7ON*LG3';50Z$ZYR%.WD2.:=:30KDNI7NGHW+HC[I!F6M)YCQR_J>7((
MI(:P&("[P=*W% !Y&9X".*3V;%'!_%C1,JN$'11WN/ILI\+HF/08:I? at EOO/
MSFF_*EP')+)W:EL[E_X]?BQN1;?'U7%/ '=K='2 '^ GR-,NJ%J:%-CW&$/F
MG6BH</J4YB74..;>M5<E*R?D?I)W;<36T<J9!AUSZ=91H.2B+<E!F7<8Y6>G
MOK6V]MF6"]L2K3U:Y4D=%GTKG$0!X#6T at AP@Z]N1JA[N;_'_P+E];L"8;2*/
M-6I8^O\PC[E6^ at -V0$32(PH at RZ:0PM%:>JBY;ZR!UAC438[M'$U7K(5GCR01
M"5Y":D'@14 DUFLK1'86GG4/O]WFF,:!$D>DFU:_>8E&8(H&KRFZAZF/=EF6
M+!M?O)-$]64 VO3(UFI(-$;AQT(>:CU;0O"X.967+<&WUT&.^MSOUISED/KM
MYM<1I'(HXY.6H>5K 22PIGMRB=K at [8<"<"9GR\5SN0JC+!XI4S;6J,>IT?<#
M;IJ2HY9F*N:"$T&+YYA:JF_GV E\J(L6@<;;'5BN?F(K<KN!DRB!.!D89 1!
MCXPT9R!GY4%")O*X?]E3\WB\V4)SAO^J%_ *"T$\9C T9W$ "C "B*2"PD )
M1%EG/("+Z at *@ 3X [Z9U6(,N0-DK]OI at E=QWQK"9C V;H?,%=+S,6 at ^P_1DZ
M&9N+]060<%6O$U $I !Q at +U#!=AZNML7(,F"/WPO"M $,'Z!+Q0 at !3P!WT?5
M^P1\ 6]?U5L$M'I5;Q!0!12^3 5,/!5O74C"L #Z'DP0-UH[^P!4&&3!B(A
M>6YO<_@@,'&<+PH@ A2^WEWANZ06O at -?OM88K+[VF0X@ M"N9:59^4!&!1E;
M#,#[K at E*%.O7!YR]) $$]P*H +-LE1B[0B&%;YH @JXYFCC)^4!#7#=P;#K
M/7DF at CX7K45N2RVPN,8UIME9YQ2;PHUEI9ZF KP R._:(_&:O<0O3 at 7G+K]Z
M7G?V_(IO5:_TRZQ1O[DE"F " &O8+Q,7L9FU_^"+!U&&NLB:4V,)9HK41H^V
M_IZ]Z at X$Q_]^ 3!:X=L:9&A]+TG'O%6]+D!V5O7J.Y%<U9O*;876F=P[+F9L
M )R at B0*H TL7S=SC at $W:>&+)A2^% ??:^^8 2APX0O]5KTX6M5+!U# A>]'
MR -OOCEC[1K_"D0+WP1< 5>]%W#AFZ-FP!VP[/L%4'$\<'9& J, )O"*ISMT
M$3EPU;L#-VN%[P_L :MH-# 1; 1'L;LNDF<E"!-Y0(!;^*H&MIH7_ 4XP7&P
M]D8&5KU/L$4W!NL[A:]G4?C6=5D<.BH&U\&M at 1E\]L8^K&KI2 at $+P1K;'HP!
M:\"%[Q> 6>C QI[OFP7/:2AP]* "L\ ZHZ^H<,+ #9L,K ?0P');U8L#A\(\
M,.M+SIUI5:\< 1GP(QP&4 $#[] 9 at 349RK"*"H-' 5_P(]P'CP%L\(D726L
MIUW"[)J5P 6CPG2:*BQ-%+ZN\!@<"QO"Q*\"( '!N;H#&YRQ;<!TFI96];["
M9# /O LOBDXP-BP)!\$ at IMYV"C8&K[!'N*(-P2G &:QU6$MH(_VV]K:]^DYA
M%P2#<55O-PO[^L+ ,!R V_F_2G 0[!-6O8R?"1 +\+K,)W6^7Z^#%OHJS.:
M9Z1OUH$?N7PH7NI[^[YNK>_K6_7&OA_P'"P"WRCW<.&K#W.^.J/M.]SN>KHO
M[\LQM8FL!98*%M+"6H=H$/\=O_'O&Q8/?V>W[4WJ]EIY># P;"+8P$L=1VS'
M><1T&C9LZQ4>2,%-.LU5O<!'&+RTK@':+U$,'A#!(AJ"D ^)42.=4FP /\7:
MKWO&";MG&9M!K CS!(4O/TC[QJA,:N3V^9IG#C'B%A$W:=Q/_.>B?@&J+T:\
MU&G$;:\47/CRQ!!JU?L3M[X#WZ!Y$GN\*$!*W ZK:R-M2QS\PL1RP77UI-'$
M0";=,=+1;SGQ4N<&Y'IY )7& Q-P]H[<J^BYO7= WU8&(\/\L.QKZXD!=8 9
M(*)!EZGQ%U!XG,6UK^<+^ at Y\:]M;//:2:?0P77P1J\(9&UXL%//!56]HC/_Z
MB;0ODRH8X[[9FV%L!*^0#][EYA(+OX=Q_$O+6FN0\=A;=UAK92\&.B$E3>8=
M3ES6Z<3Z3F$#^P+#,3 >#!P7Q6<Q",@0HP!M,41<^F['CG%N7!?SQJ[O/JP7
M^\6IX49,'AO'R3!R7!COOM'Q)Q3K.<>+<70,9')7U/'9>R9AQV:O6O$J84_^
M&.NQ]'Y]-L':0Y9B98*/QZ,7K).L'DO0GK6),<!TE at %2,T^DJ_IFVCM#@"#L
MGHE]'Z%Z9 at 1<"6? D*?R-4D!);L!ED8_&(F&[#% O:<4L'>6&@%5[]6[^66]
M9QI$V/4:.E]OV!O_4DFL7W8L]D)?::^>Q_;.Q7 O%CSW+JEV+][+?>R]5>_?
M>W9&9X*OR%KX'KZ(6^*[^#:^*,#C&_FB )-OX6OY8KZ:K\Y($MMGZW%[C +8
MQMZ03541ZSOS<7'L&^_!&5MZ;!+CON:9<BS9$<@O\6&L#O:H9R at *4!V+3T/I
MDT;_;F?VKPOW!>N_J"$<W/_.<#WMKM<5KVW<[P'\_:( X6^@"I-"H%<J<_D
M+\EM%Y3H)+/*C3+]&[E5RJIE]+NL9<ICHOSG$R)K1D/WR^%A;_6: FS3V at _H
M[ K,_B[)(X($K"DOPA;P'0P)<\![\# at L E-QQ-,P7 9:9YGPD<BL?<6>\ M<
M'K-MHS /7 J?9]^R-KP*,\/I<#>L$,O)1;"";"TEP<OR$FP']\+8\#>L[U#!
M8'"U7 )?RW'I,>R at I<)],##<# O$93"[[ X?4%UA7&H-HX9O\$^@ Q/%\G(3
M;!X7OO8R4>P'$\0<'_Z*#D?,LK#!K"#;6]VQE)P;V\,B,#X<Z07*&W%IG '[
MPR"@"1 0B\ #,4MJGHG%&_,S_!#+Q at UQYXLG&PA+XUS<)V?$]G%'' 2#Q"6S
M2(PR>[/],7=G[QC*BM\WARA#Q^XP79 P/\HOQ at HIT'G'>AIX_ 7P"&,P&7 T
M_\9OKVG<,I_#KG 0C*U5O?P at XX<4G\+_\M*I# O,7T =_$HPP[.PSKB=?;Z1
M6UNLGMG&)$_ at LB?KQH,QT)PRW\<,7Q.(-A_-L?%N#*P9RBK6@ S\)LI1\P,W
MTE'-ZE#(7!G/Q5#(OTP<X\$H<[VF,MMQMEX-,/ Q;&LQ>_S at WLGO<8JQE/W-
M/_-='#2W=$1QYAP& \-"&^LX)]>X at W&A#"#7KDUS<_PX0\U/LENA+CS&"C*A
ML&QZQYBP93SBN,;1,@W,O,6]5W+<;-EAPR[QQ3,X=\3]L*VG%5MS7/$KL>M]
MQ0P;S>P*'PS,L(AF0?4%XVWR9@)$Q5T$;*PS,FMULLZ<.L<$P[-\K# at +SGFQ
M B TE\PF<\?K R/.)7'2C!+OSMD:2_PTP\1WU!!+/,>_'I.FB3QCR[DQR"#[
M L/F,@\! FK-9PNX9^^8 &*-:\ -V\QT\FQ\,_/-GFBL:!$'SJ[S]0P[%[X2
M] =,0:O"/ 0 #0(JSI&;H9R0^<[/,0)M)<W$R.\Z>#4WOQ!TQG899Z29,0T,
MQ7G&N;$1>#8KSX7O'3 'Z\]Y,?8L-O-RJ?%JS/"UQJ\Q21P;Q\\C]'L<1'$_
MJ"^??#^GT%'T4,P,4P1EL0Q]'%\$!+34Y3CGT 8RUE)D)<@,=-(#P;W*0&8,
MYUEBS1#T7"P>Z\?%\1B\/ ?-9C0/C UOT<":WHPZ2\0TDA-Z0N.^^#/8O!?G
MQWM;<9PX#\;;&>,L(./0!7+4_.9"<(^R';WPX=%8RZYD.>.<0?%.3$EO>*VO
MYNSV.L_I,?PL0MMG>'(0E)"QSF-T;TQ(G\=_="4-&+_/ K1[IDE/2)PTY(S\
MOD(+7R at ](L"Y3K*#["05%PF"C;SRJ4$5<M(+\^5D7Y_'P"$_H[I<FR at #B,A@
M:QMXIFUV)_)ZYIH >$1:9]&.WHY8XW')ZL'(,C*XT/,>!N,DAM$7%$\N G$!
M1F$888 "8/3$!-LAO'-E]4SPSO at J(IQ!6]A=L$PG/C,!A7(^MU934^P#1F at \
MD at U+X$_?DOST>5(6J :L at 6N0$70?=P"%(7\$$SLD66!G9 at A)20GP$#1G>%P9
M,#<\ at B %+#1=6DK 4T74Y]F at E%#4!/D&.C!F'"ZL=3SWTLM;L56#D$)L!RD
M!(^"2P " &TI at $TP$[ (QM4O? at 1"BP 84G' -6M at 7U0)$P;]@/ N!P\K8CG
M!+A2>WQ!05)MSVAME\6!]Q"LU/;>SG%3(P1"WF#P$"0 1,#1\#4L(:BQ_)%A
MI 4YR_%)T]4$7QL(< (,! 7!09 0M G0%WQ$>@&40&B5WZ<<7Y-> ##Q U-
M at .52DR[51'53?2.LU/H(>J QG 3V UQ@)K@ ($#G8M6U /9%"W %P"@5@@*0
M %#6#D)ET9V!UA<!LE"%:BLTQYUHLJT@(("UX@:XU at G R9=5A!S!A+%9'>C6
M/H?2(F[YUN*':;)2=R1#G&OP-9QUD751 (9<!)&!BV "X!*Y G)],NP.EL5*
M'1? UN#U;&TKU-;FS** 3;74_DE-J3F<"(L""# UW-;$]6X<<C#7[HO08%\S
M&Y9*R($B -?[];1"A 0&$05S\TPL;WV 9I% at EPHKM9G65? $@<U>G?0T!!J!
M.^O=G0 A U^!FF4%=L(*=P)\!+]#"\$&?-CY06]0$4X%5 !0@'.\R/.??X+O
M8'P#-E\Q13 W 7;6$&,7V _(%',SR"0G,7%]8\_87(5:PE[3''FUJF)7BPW\
MA0(Q9$\K178)LC]P,W.+?&U4'P59]4# ,!0),L1WLQ:>#'?+=%T4H'XU0;G0
M6W<-A,@447YD)M1&=Y(3!#9% at VM;:H8 ^H1QG3[ ETH$H_% at DP&!S4?T$;5/
MZ6 "&7/(+2R+?%UCVQ(CBHS-5YBP2W;6D._\V(?V_K)CL]BM at 8M=9!L2>X!\
M_5HKT1&VU) O-;RAYUM,OS7FS9:86(4!9^V>AUJPPC"R;< :B< FO:F?0:,
MVG=V[ )<)P OA*5"?4PEK45=D2+,VK5V3G!KM\0+]JZ]:2< G?;N<"R8#*AV
M.&$R/-G#-EIA8"3;#\.2L5EOV at GV7^%+;-J[!7!=;'<G^\:S+2&T;<Q'IP)<
M)]B at =K"-334!5D 1( 5T&T\ D*!IRPV6];4 at 6;?:H=DXAI!$#C0$7>&E6";H
M at T("7,<[SF.H at XT U^]T4!T&P-3Q=JYP$ @&"LQ+4#%8'P^+;.!7_\ :0E<=
M EP\F_8+T0, UXD'LN#44#7CMJ[M6I/;\?6YS01LJT$ $P "O-N)]G\"([C6
M)$+)G0"$#R/W5N-:HQ5FA]QP<KL^3,#-_6K3V3HWRMUS<]H&1M#-<]_<%\$9
M(+R(6T9WRHUTRP&]1'K2G#4!.[?3_5HGW;A.TSUT)[BOMG0X=5?=6W>R%\MH
MW3<WZC)V4]U"]\V]-; !3X-R0':_UBDOJ+)1*-5O-\B"<J8H"<77G793UD3
MMEH%- %% at !- !:S<EG;=$CHT 0K)1U!J"]LOP-J $K0-W at FH#6F7 >2.4P)S
M7R0OQ#.1,_ &N&7;;6Z_UFMWVQUYF]IV=W,(4' 4HW<^ 7??W3=%ZGUSB]TS
MS.)==K,NLG<"(-O(+.(6VZ': 3=0]](-%]3>L at UD,!% at !1"#';![<]T:PE-1
M>W/=U,Y2$E]SW68<]5%[T]P) ,G->%,UV4S=G70+.W6WSU#I% 5D-V4M!!0!
M1P#4!P4$ 4> XE!IN]:3=^5MG]S<V/<%DLV VK$5-KOM1 6- 132NH4IK[7W
MC7)Z)Y^!9 UJ^]^FP_J]:;<P\PWT4I-8'R&$RX)WRMK4-G!MR0 6P#5:XEJ;
MW3,,[-U_'"M7-]0M[ @[H+8%0G_4W)LU91UX$P'G=_J]<KO68X at $4A2XUO$W
M_1'FN-;4]XX3&)#@)3=E+?4)WK"1$0#UJ=^6=OO-F_W6"<"];9FXUK\"=O*"
M)P E at 8%A,KC6E$EX<(0G ')#XGV95!/0"0S>']#@,0,.OFOKX$D $\ $- DL
M=XL]A+O6AO<+$(9X%HJW\ZUZ4]_6MWP-AHOA*S at 5WG+7'JYU^5%AL.%7>%R#
M,G#ARH$7+H?+#4[ $\!XI-Q)@!9 ?MNK4 2D 0, 62XI5WDP-P4=EAU;H at Z
M[0$37D,$-C?%Y8T^4#KFQ.7]0;RV<X 8 at %Q[XKL,\6!I)]A<LX] >IL!M@/:
M?72_UF8 @":+6]UJN(QZBV_=9@ NT7V3-+^X+0YVW]R^2MT]SX3?<L/X77[K
MO0.!$4!X ^*6M at G>C'\;],>TW=1P')K$RAV'L]]-0"%^B)LHBKC,VH at _XDV"
M:[T%J.'% at QJ^D9@!-8,:CDM(/"X-/+Z1_#.W"A[0!:S<BW>"O;98VK!X^5$\
M..#0BVN= at +?613@ND>((-16.!<&.2S at PCE*3D/,*K(MKG> H+PN.\ at *00S$U
M=RON7)O at 3@!L-(V_VX#W-#Z#V^%F^)OS?E??+H*?\5\+X28YZ&#K;-Z7,=?@
M-6C:L8?5, <0UZ%WUZ <="I_.$K^7X\S#P,H0EO,(? at XS1!L^RVLN$JN7FL-
MH(-0#EY\#"_!5%(D'.4W1DH^F2SE(FG-L >H"WR"]1W/:!(] 77PC"< <??I
MK53;$:GB,$:4/^%D.>O-0R01:/FHII:_!/:%:QW-W-UF;>J=8)<ENC;#X87#
MWW=WX1%RA-_H0]R=EQO at I7?6YW+RU]00LS%MQ]V"^1F^>C>'>;G$XP8PU]/V
M:\T$!"SB%IZ at %V3E/AB%#9I3-6$YBQ)J;^8#[Q1 at %\H%T-1.L?E-$F$5D#F:
M at ^5R#Q'^6J?8K EMHQRL":+Y:T[R].80-VU.'0#7+\!F3 at 9H);_Y9P":\^;*
MN6].FM?FQ/EFCK $!9YYAF%]% ; ><WPG _GH?8U<Q9,:2!!G@":5^>S>6!0
MFMOFVPD>P)Z)!?1'YV.=P^;9.9=MGD/GH781%)J#5.\Y72">.^?"N6G^6B]
M=X(+$(0MY]Y8RE.>0PWT^7]. ZCF?4G;\PKEYTV'"P#]'>CG.7$N"C$I(T76
MLYP+"$45A9Z at YP@TV1<%H<?F&CI_/I]SY_"(3[Z40^;O at J;-HB_F+3EZCII;
M%BNWC6)9X" 3#F>.7SC7I[F.SJ!7+<Z"CHZC&Q$#[QQ at %WKEH39N;C_0$FE$
M#( 'O!A#^IKPI-\ 2+IF#C4 at YT'Z<=X8#.E3 at 9:^HZ_:Q;F0$A0$Z=,YERZF
M5^G<!OX"GA_8W[EK,*0KD5 DK,"CO];(R7JNIA7E=GJZH8K/)-:"-(&FV^<^
MQ at PPI(<!,\"?[C'X H&Y<S.DOP +THX_I/HJB;J0+&FCZA;XC).JJN!BP
MJ(/I at =7*+0;4 $/ZIXZF7P;,=;)QF:,<;@"2_J(CZ,$'QV"8SW^]-:J^<K_J
MK<%>;IG[UL$VPW%' .(WM]SPK; 050Z(L-Q 3V_&M*U$SAXQ^H&!$@ -04 at 7
M;GO#+5:.51=2^.H at PO(VJ[,0H,R9#1?\Y>-,3,X&K.IU^*H>SI0;/?K 6Z/K
MZ&CZC-X8/.KG>I%^I#/J2KINOG)+Z2]&NGZEBUM9NE9BKT_GY_ITCJ9[YRB?
M=,VF!^SK Z->IZ\&['E1,)7DZ?H%HPZH$^J&^LKMHQCJ[#JB/JE?$Y7ZH:ZI
M5^IZP8Y0 XSJI[I;;:KCZCRZN.Z8N^IX.:Q>JM/J#;O00*JCZKEZO> RS-R8
M at 6N-<5 O7 at .W/JL)NE%:<UAXU.''^DU.<Q3FFH1+EZ1]!+ZU! Y<Q]VM=UD^
M=[\$7P?'734 at ZR\!'KYI:][[0='.%!SM"?;-SJQ#X#3[9$!MB]PJ>FH2[+0E
M0;EKO7VC[<4.Q<"VOQ,9N5*>FH0YPHZFO;:[&]L.VAZW7^6I"1GP@;/M/WEN
M%A?$!>H"B0""(R at *"@C^M/C3 at _L+D6_8)'&!XRZ=+!1QP1P0!_@<&WGT'7X(
M[F[%W:$79 OJ47_3 at _@(',-M$7Z0'YZ"KITY> N"^Z=]ERSET(1F,(*HVH<[
M;W.Q .Y2B\G at L6SD'P+[%G&. =P)[[ %) D=\ )2G13O=,#Q3K H[\;[\XV\
M,^_)N_.^O"_ES[OTWKPS"M4[]CZ]:^_7.XZ0O7OOVSOQOKV#[]W["_"]F^_C
M._I>OI_OV;OXOKZG[^P[_"Z_O^_7N_L>O7/O]SOYGK^K[_L[]/&VB1P7 at I:P
M at [P '\F.0@:P)DG"$*WKX8TQPD%P33 %OTQC _B"+/>FF9?X @%_"%'2O0?
M=O?$,!4D!5_YQ&!64_",G@/*58 L at D)@,L01$7-"Z<"R1? $J'(@2F@)8L8+
MD"8\",!->#"Z=&LX@@\Q?%,BS $E<J>+$NN!*#%1$-_H2$"AB\ at 0_,-Y'2,<
MI#Z!$Y\DC*&!"6Z!6^8MA*JX1< ?#>EBK@"I9 V56(ZPID0=. )@A",8$R\
M$O!KX A* (ZP!"0)*K=@@B/("4\ CN"FO !1 (Y OW ;4 at *.4 6L&SC"%8 C
M+ ^/S at MP'FP37U[:]L%G#>O?84?#,S:(O%7WEZ#>D IDD :H=_,!:X C=(>0
M0<:!Q5\ at D$KOP#] #B(')9*WX B0O*GR M1-+\ )'Q1H#;H(<//+8/"VQ 71
MPV_R90*.\(YO).FXX1+)1P:+?._ %"0)U>;;-L)7\ at 1*Q(D]Z._5B4$ at N3"3
M at 4D08&RO*9%!3_# E_'CV1>8)# at !I"%C@",\ 3U!U7 at F!"950# at ?@7@)%'PV
M#\5 *KP,_0&I$"B9?!N N803D(HY#\TG">';,@^I3//!1#5?8;#P% '"7A2@
M(^W\0.^>Q//S_$:"H(OS7D*2\)X(]%U"0=\EP/.K at 3S?A+P4S_PXKXMT\P.]
M4/<% C<%?9*@&E"'%7U"#]S8\QK]+\+1;_+J_$ ?\ET)[OS,B]"?'DE"'8#2
MH_,O at !!Q!B#G_'MU,L$O&OEW=V+$KXJ] YQ at HX3P@,&5X,7E+=:K?<&:!"83
M 8-0PGL-)#52K<3C.[X."Q)HO_/:?$Z?T>/TY[L'],UG";]#.QZ_T^_[>_O^
M A %,<)9G];/[V\]6O^37P210U:!O$K6":[?_CO\?TQ\3_]\AP$=/5E?P[LF
M73QFL',D"42" '\05!M^ FJ&_+DO?CVC at +F8;&T]7/^33VP51E:Q@ 3S:,7U
M(.0M(,?\%&>[@/7I>Q @T3?J''V2\ 2L]*H)-.3.BARS3 at T_7)?U&'P=8,"S
M)IQ]! at \UL"9F=9* at V^?VMKUE<=6[]=5)'G#3!R99P'&?)+1X1'UQ_9AL?NDX
M9H\H;/"<O73/PP885SV%08F\\CJ]5G+ LP'Q3"085\"#U&=MOZ-<]SN=>8_H
ML2;I/<BRI8-\L?MDT*A3]*R!2;^=T/<6/3T?!+3T9?QQ7\:?]DE 2Y\D) 'X
MO7V?!/CW5\=I_P3P]ZI)@7_1G^]/0$C/D3#X58"#3\]7 :?]02 57':JO(6_
MD;#VN\$*1Q80\Q.!.Z_A<ZX3#3_OSU_S<\)E at +!X'FV EG S_")G at $E]PO\$
M#\)O?8__Y$GXYA=7*.R6] at LAD7\S0?X0;FEKVDUX8T*16"22M01>(UC:K+97
M$K./"37W/GYYW]K;B8_?/41$#WW?YA,$[\?"DR\KN-:R3<@!C>_MKGAJPLOD
M ;&;=;VJ\.C;1.M==XL!'L$IIW?/XMM$SKV+(]UN (] at SVC?^(2?_Q'4W9=;
M8U)WHX>&_I[_6L?BP_AK+8SOW43[P-L;T.1Q_EM>,[C>"4#O4.=[\YA^[V!V
MU-XYO*"O:L?7P$V at 7^:.^JKW8TU]Q.YG0/]!@"OL+4QQHKI+X&L]II_IOP /
M0^U]ZQ?ZJ7:T_680#!8$G=\*1B=! =MAJJS:. *BGVH7#TL&L,\K"/MVOK=@
M[,_I+H+9H>R'$V) Z^TM\/KAQ$Z1+2P4,WNFSR8<, ;&6Q%7E#2"/HR2%#P7
M^<.RL&FOW+](GW_JE]BBOD.2YHL*P#6\?T:(^OO^J2]MQ]?R0KYO at 4?@F_9S
M$^N:YMIX#8%[DSZ9?K]OSSC\B[6\;\_ at *Q:$W( ^K/D^-_'0YI<?+DJY;96G
M^4G"FA\>N&]UN,6?BK\/++C&_^,WW'4XIZWR>_/)BJF= "3=OG?Q+=0$+,HU
MPS_S0]V:N_B!L,CN14'2G7S;_#6$\"VCA-P,-DJND8/::7P5H#C4W4W?X%UW
M"P%20!)P!" !4K^B'_J<UUW&G>]TRPVQ=75 at 7H?6EK9=?G,C 4X_JG]S1_UJ
M_VM-]5O]6'_;;U0;WDC!UD$\? 1(@%U]P5,S+X%GP<5KZUXVSF"TMXL at P!:
M]BL.;__53P5$&J\U;=WUQP7F>. PN'\&(, ]/K@;U1KIYY*'2_YQ >5O^<<%
M1C5]2) 7_I9XB]$0?/X@@%'-PFW^814R=_H/[JD_F'/T9_J5 C1E^N\-L#_F
M+RBX^Z2_VP,3O/Z7/\20!_ &K+^$3DT _Z"_+(/*%?] IMV!^P?_T?5$XZ1-
M<=1&'K[CJ]>P/^3O]I/?4)\0H.TU 2OA$/ $G-STBP&> 'C_5 #X#P6(_^0_
MDIXC</]. /JO_K/_AOA38?[+_^'_^%__N__*>/?__:^$4P*G'_VO_ ?EP_]!
M 0* 1Q#]'_V"_P?_,P B > ]K\"X/_O "@%$ J )\*[K\EP% at N >#X:\-9
M'_ at -P+7Q!8[@\.>=<,%!^1P8.8*JG^*O! B#R/>! $B IKO2F at HP[A<#K,L-
MV]((%#:VGQWAXD<\&!7< $F ;+_$7]P/?4 G,,5Q_1)L+L"!7]FN5]<$X %V
M'<Q_W(8 at P.#-9.#\*P$.%$R +D 8('E!! at CW&[S5 &MV-\ JH [P"GCRRP/X
M *]V0$ I(!=P!4 at $+,4AUY" [[Z^'*H at Y+;T,[7Y ,U^V[]EG %P + at !- #*
MK+( #$ ]X 00 M@'G #^ ?L*<+[^7_QO O@ 5 6 M-_ , *X"(N"/#H" 3Z
M_R"!%$ +(/DO @A<<P!* @^!( #WG\F/#K#F6[DY <V 'S\XGP;0_ >W&]N5
MV_(2<\ 7@&MC.& GT+1)+8 0W at E<H!!B<:?TD]LE"<@ LT H1"T0"G<+'-WE
M HV!0H@>@M+B"('FV\BQ 8*!+3I+&XD at =V>3F/;!&K(%;@+IQ)(A&2BU: 4F
MY?AV20(UG@'N&2CR>A=\XF0(G;A>(#C0D >TFW3($"H=S4"FWQI.3.#UZ[DI
M"<9R\T!$ at 7=B9I=HN$JL&, 5N 6[' &EAE"RL"RDZHY\(K_+C at ]PX/<-!/D-
M'<9R(CA2&U+ at U-&":P&J QV"[C9+VZ:#,Q$/7,HU 59N10Z!VV,C%?B34[_]
M.4B"2SF+!!!!/B"V0 FF)NIX0(0:1Y3&A] 0A//U!L)O*K?U&PC at M=8;J+U-
MXA( T, T at 6M-K^%:$WRT$*YUB8URH)W@) AWN ANY!X=!CB5&YE/)IBRZ BJ
MWG!])0%"'VG at T)<5U/KE ;:"6C]?1STP24 ?+V%.-QP9;>SH/6!Z9<'* DL
MWYYTF#ZX8%OP O>?,: D / _YG3P%UPN*,7]! at \.JR"9,&RX*4-?^ 35 JZ
M^]9Z:D%P!ND-+XCI"PH>!MN"F#ZL8&/PTK'8N, -=ZH)^(-U!2;.,NBD(0TP
M!K^"487,X'R at O'$7S L>,.J"H4'EP+6#-/@9+ G(!3&#JL'18";N-7C X NF
M!K<.)H),'$&J*LB$TSKPY;P<%0' 8. at #(CB2BP at BX2QMB W X&M-;N#6^-DA
MX\9R5;C8@ >P9C"S8PYZM'YV^[;8@,T.-*$== K^Y/)XB#GK8&7A9U=[<\8)
M!P=O!CB]1N)!."@%<,89X 9R[KX G,(N5"##F I\WFJ"/SDJ@'O0TF8<3 0
M!1, [4&;G5,CY=>.</?A!Y=R;HKTX&8P 8!V2'QT(Z 3-X7UH'<00;@?9,'9
M((:"F#A+6X"007 at Z<!!F+8)4ECX)844PXR <C,1A" =N'$+=G83P0)B:F )4
M"(EM%T+_X()P0[B 4RB("$=R+,(D091 08 at B;!!B&#Z$-4*60H1P0# at A3$U$
M12"",<([!!*NUL(AY*3<->(:0<(PP)"P^D=LPQ&Z!),$Q at 0#7'_P)^ at 85%5@
M"1YPECC0 (7M/P@,- SN'V88E#A5 86M"D at ]B6M<.Y"#5,$;1QB"0.B"$PY6
M8K2$,<*S'>O M?839$RDVIQ];P:30=JA,0$HM".PY;J$?L)P0J%PH" H#$XH
M"J$."P6VW$5N"1>18Q!6XM:$%+8V84[B32B0*Q!B+&QVBQN.8)6P0*@<Q/6-
M!1U]I\(7@"].ZZ>+:_3A^AA]:3='WZ,/SW<'6!6Z"M$ K<)8(67-!H$04 -(
M>%*%<@-O$PNA[D:M,Q%8Z\)OBD#%%]3'FO0$@(V,Y2AKO[J_!;1.6&?8L??9
MW):#&AUZC[3PR0%&J'#(W':%X(9>X:]P_F9JPU:XW%QRKS4;G,)N&T>%Z\89
MXL!_X+A)X# at .$F=I&Q2FVD((]L)P0@,N9X%W$ at Z>X)2% at C?QG[-0T\;DF-9E
M"ZUU$S at X@#ZNMD;FFQ9VOZJ%H8)B8=Q"8T!^R-;QU+AQO$(Q at *^P11#F6,5=
M"=$*DSYIX)$O 2!8\A8 US)3L;9LVZ:-DV)' *Z]$ 1+1#E<FYQNS+=I$RRA
MY=@,(3=K&QH.9U at DO+FA&,)OF:F/ &(.Q9 E.#!,\Z9M7X>B8:O!%)A*,!DP
M'Y!L%\/@6BIAVI8C'!H\%;8 (L.[ at =80I+ U[!J"!OH>'A$.H==P;,@UY!J"
M#6%N=KG/ !H #["7*PFL#?=RI(&WX<HM)R W!$[4#?4"=4.M0]UP+E W7"/4
M#5,>;T.[G*6B;N at D(1S&#=F&\SJZ(>(PC> Q(!SB#1>'0";"(=\0<N at W9!L*
M#@&'BT.)#PB@;B at OF-?!#?=RA;J5VZ)N#_"Q6[G9 /9R5+J5&PY at +Y<#:!MV
M#IMT;4,9@ \PC1 Z9!RV#4N':833X;PN=9A&6!W.ZUJ'*S>)SU[N,Z![:!L&
MJ8P$*S?20/%P;G at \G!W*(I"'I,/FH>E0>KB5HQZN$9:'>X"4!_;04K$]+ EL
M#Y6'1 at +!(2X">OB*P1YJ#K&'QYD3PKS.1: ^!$6P)D"'[,.]W(:F?5BA:1\.
M;$X(=KEU3?M06],^G!&U#Q\^_\/>S?\PP?,_)-'\#^>'>SG-X?LP;5A^^!\V
M$.&&#T3F(>9"?AA!C!Y.$*>'%\3J809QC9!!3'E,$ 6'A(L 8 at 51ZI%!W)^4
M$#T&&43-X0<Q 7#]NPH6#>MNS(>Z&\,I55@;2!7*Y>IN=(GN&_&M[O:P& MJ
M#82&T;BBX>(M&L=\6"Y8XV:(0<-H7 TQB7AS8S[$W!AO<CDFXFN-+B%%S!%J
M/^ %'P&''L70TH;.N[R1^0P*6C8(&Q-/9;@'2 0!Y!MLX:9!)1OH1!RL_*1
MY5@(KC7AH.[A6=A%2+U%XWJ(0T37V at S14D!\RSYX&+06.X@>8AW1C\A\H"VT
M @6)Q#?A(&N"CDA\RR/"W<01=D37FER.C]@;("1F%FJ(B,1*XK<MQ)!9,"3V
MO-Z('X$ZHG!P#J!_,#O\Y# 7C,2>H!ONC at A)="3N'3J)#H5JPEIHBH"ZL+/M
M%D2 H+8>8DD at D_AF6!I&"G803L,/0W] at 8<CPXR4*!]>&8[F< &W!DA at 4^"+F
M F>)% at *S@QBC5)@KI!6F"MUN6C\VP%E)Z^?GVPUX!"X0=3=T'@[QAK3G4Q72
M,0XY8SDA7P)@C7!KJ\HY&6YM.04V at [=O5P _7"A$% at H<<L!$03[10/@Q5 0:
M (4 5P!.H";.]6 2> (T 9H [38#H-VC9_C^$P1B D&!!K at U D%1_'=03"A.
M !>*54-_X at 00L*+M$2B2!B:*!D6$XB(0$XA1_!A2%$6*"L5GX>\-+?A:"T*P
M%/N#DT(7!O2"=3$GL".J"B.#VL0 at E48@2'5.9+ at 9ZX(".<6884YQ@'.4N[EU
M$\T)V0QRH; -+I#]:RHZ%96('X$:HJ5 C+!)7#YD%J9M>\3Z 55QLV!5U%KX
M-F8,*L-@@D%!S at 9KPRIN#G>*6P!<PMV at 9B"40 /<X^QR.8ZZ F]-DA at 5\"9F
M,SJ&=$*+8$:Q 3 at !!"B.Y4H"(,6*XDA1_2<<U"@^%.U54$%+FT0QP792M"AB
M @N+?$5,($<1/6AI^R at R%D.*CD7"(D.QL3A87 FI%".#+L6UH*D-IL at OA%[
M!\^$'+R:P1#QIKA\.RI^$^D/2D5+&U/QJ4A;A"KJ%)4#ZI_,&,/-E$AZ0QG*
M-LJ*,C=< CBC\*=6_!:P%=\8;L4C'\H0G:=$HR5*$P$+<D6/0P+ M7A7+!#R
M!ZV$=<"K8/*M*^ at J3+Z!!5V%;0NI&S*N#2!LD!K _D 6Z8G$8/%M]_9?.R]N
M%[T3NK<E17MQ<"<+O'1(W=Z+#0GOHA%!DO!F,+S-%^,"X475P+? at O0ABZ"HR
M[@",]D4!(WZ1R*=?+#!J'PZ,<HVA']LA at 5 UU P0#T($31K_XE+.#<#"P3!J
M'32,J8D^W^[/PVCWZSK\Y"R,,@H2(X at QXY<9LR'>"E*%$ C/1-VMPTA#Q S
M"O%\%HW+6*J0ZL 6./2="GJ,6C\3EM8/R#B,(ZF%UM '' ."H9P-N;;P8S&^
M!%J++\;E6XSQR<A2U"5 #:B,HD75V]=AN4!OZQ'D^EB*4\0\@(Y1EJ@<\#*J
M$HR(/05OH>H-] 88T*W(_HAO9D9O @@K6T# at D/FM]7Z,_076A%TMSCAK0#-"
MY-2,Q#FN0HZ1+<!CA!> #H@"@@)#X[# SL at 6$#3*V;I#R#4&%_-!C;AJXS!>
M&8,3OK[/P* 1/5#2Z&:4-&B,:L2>'%!P#"%=,S-&+ J-; $[ at J>QD*"&HC+R
M%30+P#41X]'@)6!J_!8@&MD"J<:!PJIQH*!G=#4^%42-%L;W :W1QMA?<#0^
M]^@ F;\U0& @/*" NA:H$5F-+<90XQ8.)=<4C#& L*1]'($6 JC1)C%&L,LM
M%["-I at H4HW0-C0@K\#9>&Z43TSY98QJ1V_A$,#?J!<"-+80U'Y:1.MAN#*Z9
MIKA^3<8H'PNA<XADA&-%&C5[(@966]=.0I!L7#9*-8P.I4*-A0\Q3,"90*XA
M&2F&-S>%8];!:-B= +5M&4%80@,SHR,Q :!P]#("UU at XF$95@A.'V*=M&[[U
M!OB,_ at %J6L)@TZ9G+ J@'(TJ*\<$0)F!S3!QM"LHV+1U9#XY6[[1VOAN1#=F
M&Q6.Y$:P0TA at 5(%=H,'9)(P Y$7X!LXO!^$<R"@. AV!B#GE@'IDM! at CC"F>
M%FF*JL55(FNQRDA=E+]=(*9M#D? at S+5M:/ 1P"7 at %GN*JPL[&]//MTA6I+.9
M%8>+:460PG&11)%<M,LM%\.(9 #GHBT1NA at IF /LY;P$";9.A3*1ZX=5L+1U
M'65PUL6\(HF0H;@'O ^"Z6./#K2XI?0M/B\@&)@'6V*N(3E6T[1[,A3U"WB
M)F1N1<. at 8E1NJ.AWG/6]U at Z/JHUJG,PM[&@U&#NB\Z2*6L4[ KCMJAA<_ A,
M%66/G$2O8ETCH0%'G"*.%8^-P$5AFW 1K5A<5!L^,-2&;T566URQ[_AW+#T*
M'M\6H36L EU1WH!4O$# at %4>%=4+&(R-0$D@(U DZ%8V#3T6K8^51XQ#+J"FN
M%C./:,&GXC:AKEA]A"U^'4MN3T4(XWD1G8=+X"WF$^*/3\6L(BZ!F:A8VSW*
MVM2/;$? at H]L1_NA4'#ZN$>*.:\7CX^;PK?A4C!0H#(.'RT<>P0/R^8A<DSX^
M%5&/9PY/GOQQ<#<B; H\%9V.F,!&(/GO&?=4!#\Z%<6/V(SR8]8QRZC+<[VI
M'S&0L<4-Y'B-_DAQY!W\%[-_SK:R8PTRS(?]<RJN'W60]D<9)/_ at ]QAO"#[*
MU_*/9\4#9/'QK-A69$ Z%2MM=\<[F]YQFK=;0 (V("$&*0*IGA0RFKAWU!A8
M(9^06,B4'-YQ"MF=J$(>(4^0;[[!8_1QKGB!9#^^%HL">,42Y SN ]E/W#XZ
M_2"*9\BFH at FRJ8B"G"FJ(#&/+D at ?) SR_;AKPS_Z(&F004A#9%-1_XA[["KV
M'SV)&@,AI%BQ;3=GZS]LUI"0-0,EI-Q1 5EW;$ :,! at $&@,)I$YQS;= at 6T$(
M(3&0<<COXQS2J5 at UK!7Z$.$"X3?25#EQFUADK"N5$TN!WL>FHJH0_9AEE$0V
M$61OZL=C6_K1![E2[$4^%;\.KDA?8I? C@@7,%48$ at 1T 0=OP;' &3EK$ E\
MJV*.T\6Z at BIAI/"*(4ZP&18*S<C+!%^C at 6@^V#5D&_<'Q$0A).F##IE=U!':
M(2>!B44AY!XR^]>'M#S^(<^/@4A=Y"!2]5B(/$0"(=6./4A=I!:R_ at B0O#\*
M(A&1!4E)9 "R"#F [$<N(I.0Q,5-9!,R#YG] at T*F")B+T,1:(A42CEA;1!EJ
M(9N+7,B-9"2R(YDBX!&,(4.294 at 6POZQ!Q@7L$ Z%5&1B4<Y)*F0'>D+S!$8
M A&+8SF)(L-1PW9D%#M>% at 6+!L#"XDV2$BA0U$D>W'B2%X&'XT\2I7A1]!=V
MY R =;@<(?6M4<<$( )DW[1^*3<BP-_.W7 CR$H*.V0;P at ZX79HNYI"5K,-1
M):V27D=^9!Y.3^ at PR,-Y)=EV>;L](4.Q.U.6I,G1[?1V#,740'B at +NF6K$I6
M%[./.4+#44. at J28W2+>MVY( [38]3$G at 05$:( U\';J"?;<AP-\M\$8%,#>0
M58P#HIFIVPZ."M"#^\')2,""/C at QW!3 ,BDW"$WVW$H"*X729!BNYT8:V*!H
M)E>30J\\ at 6I2#"<- P'<'5Z3M$F] , !-]ESTSH '.8"L\F>6\F#-\DQ 0'P
M & 9H 80!E at !C &H#N8 6 98 8P!C at _T$B(4ZF/(Z39H"1S70R.OF<I#LP
M)Y63/@#BI*6"!Y!I*$^:)\^3F8;P9'!2'62<Q"? at $SX?[LGGY-M#/=D$,$TJ
M8'@ =8=<"K '&1($R:74'>B3]LG]R7$2&P4#& .X%0B48X SB,M%/.DQP$^.
M6>XK>99WRX)R/=G\$T_.!7:3%,HUPFV20IGRD$W6)V&3<A37Y'IRE9*:_%#2
M)O\>EKB<P(@R)_ 9&%$V*)^3T<GIY,@&.:F<9$[2'0"4($J] ^ at .VD,,5"6
M 9"3VLD90'021WFBU#KX/^0P2,I-"I&2-3D7.$Z^/>*3\$GWY)+RM[!&X '<
M ,H 8H!70D+ at 2GD#..!E*:^44\K%R8XR,Y4#, ,(*6\ 9$HSI1D 3$F<+*58
M*<T 8@ S0%T/GW # at %/**4T%4TK&)(7",3EU2Q:BWX(C= 4QBL= at 1%!!27V0
M!GIN.0$D@"!#"_!+"!Y\!MYX2 (# 6D at [ !4(0V$470">H,\@:(223"8Z0P%
M82Z54@ %0*220B91 SM,*O\>H4I.I=:A5+F(&@F0!E*5OP2I1Q3 WA&M 0F4
M8!A=E4D$P3OL487- E6**K4QJ\I73#0+)("J_%52<$8X3;410<H#*Y86F'FL
M$=YE.)5G960&!("H? $:*TU$791UQ_^C6>DQ@::D/*A(+ at #!DB<*)%"CBM )
M/<"5XLJA%+IR50D"R *(L8(HK3]M96R%BS*N=%7.46(K^#FLS+P2"C,7T%>*
M!$HP[<IW9;VRW!.N_,OT*S4H]$IJ9:92+Z"H_ PP*I$$3AQOI:W2!E"PO!.L
M.W at KZ(X-RKJ#8"EFVEA2+#E+ 4O60\;R7(FP1'VL._X>$<M\9<G28 at D26%GZ
M!=^5U[%U)<O27YFP[+DA"2PN^TIP%9X /R<BL%2N3 at X$_TH'A0]$8]GOREDR
M)E^6K(?_AX! L"03(UKJ*H66#+6E94SL#"*Q5%I6+(^6(4O#E-%2ZF&U9%JN
M3A262(+?D,129ME9(E?65"(@1$NRI4V%;)FUC(!PZ.250<NRI;U2;*FRS%G*
M+5V6;<NU)<=R5;FV7%D>*HV58 '?%A7'5CG,X$#8.^8&,!JM1+*R at I*0J4RB
M $X"G(7D1%/M*#+,( TX+A&7F at 0F#LEC60F0<5P&+JM8R<I5Y77,<7G-,("U
M9T "J\IYE.<R-F AH-*D&&Z5ALOG3*^,#G6F>5VV5N8"N4I_#+224&FK3'I5
M*Q65I(&')8I,P:17FN. !/8G^*%F)3XH.56[5(/$8[(>JTLY$<0J.\.&@5>5
M4BZ7O(',95,M]@&O<HHT*S<?=HQHY6 )KF&SM'?$DOY(8YI;I=:!=%EB2E]V
M#"ADCLLCP$'H*-%4NYK\3;8?T!3EI43 *M3%^>+4+Z4? at Z60P/K2WA$2$DC5
M+NV78BE\I?)R0#,B6+<% >161@ &IC.GB\(YX7[D+QV7#,S6!Z%*6""B(7DL
M)J4>CLL#A8V"@SFY!*,!1)27OP)CP0)BOR4LD&"6,-<=M*T%YOC*^S$&F XY
M<D!;BTNHI?(2.7$VN#81+D^8CLL.Y at 1$0C<7 &+:.WX%+:"K@ N3<+D-62-4
M)N4&_\(_I6\F-5#1<PTH /QID0T+P63#GR9&*0F at .S9D)2%NFJ6HCC,#F,[H
M;10#-YN6TS1H3I,Z2D0A'UXEKZP7F2/*#U7'P=*8U*9,]*LV9M0)F</T* at RQ
M:@!2:IW.4='G<\1I,D]AM4Q>4RWM335'2[#*N8&5]29 #IQ at #YL,HJ7GB21I
MI>14 at R[53IW*2L.LV6B!LSA9A!PCT2%3%V6^VMO8L))-FYZM7>(I664FDFFM
M@>P=# at N"%97G,71-R"+(PJ8[11^$44F*7R;&Y-WH:0Y'!Z=V!Y+'4Z7.82XI
MJ*H_-!W<TF)*5V5L,S%!DL( XI]&IDPIW&5G* at 3!<* Y3QK8TX>FSB.2&>GH
M;I"542R(SRV3,#/R,W=Y at 7!V3B43S@W'( @4Z'SI,B-8$ZS*P69HYU2A4/.H
M;S8[#JTV5@/(B&.N:1,5,&$T5BQ?IG4&(+69N-BH9W) [1P03NV(E at -6RI3Y
ME)@XZ)V0$IA&1.81L<Z8B) [P26>5L8&/%#F:8'-=\ U/AUH5CU3>U.\+-8P
M:_Y"$QP34>5F\X-4%&4:-%]7<2>A58XF!-1ZTI-!?F9(_Y\CT;@H09'<*O:,
MEQ80#B/[C!(($&:]Z>0P;+ "T0.'UTJG];1>"@%%-!D#0 ,- PS*UU3DVFC9
M.XI3\)UK#^KIH G'PE5P=0!0-DV>YK!G>IFMT=/\;Y*: AR0UG.F-M#,LFY9
MN4 at ^4*F'5;''_-34=!:%FO0%-R%S9DS3F at DOJAV9="!3)4WOTPTLOA/2L6DV
M= !2Q2DL3S]S3D,I,N<X> H^Y">@#5@'1]/=P4N%NL114"B9TDTII/EBJ!A%
MI7!5?R&G3D"K<F5N.AHLD/ __!V$ CRS>.016B.E=C!+V28N3,+,1*2WT471
MH8H0(:HZ$ @(H4ER at A-=-1=.&!Z)S?RRW%3EF??0E$P#<"XNCE+/?QFUD6BZ
MK\Y4;:D'#8_'N<DP<@PUEE9*?RECIMR&82-H&._0S^!<6AQZ3_^RW*37P61*
MG"1:NB:UCL&1?CFJDB E<HH0<)O at %@$IN.,4 6^Z@&Y;MJY>T at +HJJ2>N4FQ
M^5H#<PG$#7:I!I3'F4N<SL*;%H%%SZ]G^Y'<S"K4>49:T<V8@)Y&P(3!,<\T
M at A"<XHC;6E0)JBD9^-+<,BE!Z,T2#Y;$6M,#JAQ$!?*:+B&'4VO'O[/2^A>X
MJJA&V1F]S3E+![31U$%5#21.P9T7PT at G*:8S:A-A.(5K,1T'E8FKW]3:1.VT
MD?I$)B2? at S>H380Y D.YFL)#."@C3]\#2F0B"C79..E$A,R?5'D(T:>Y,>C@
MM!Q 9QY$PDA'?55,"FIJE#!((B!9E8KK3=3) QJ at MK1!DB;9T-UMG160\BI8
M;8([,Y*1CA(-J93.L at 3U@104P!J at 1XKFA].'VALDE;!+*J*UT[2H<K!QVL(H
MT,PZ1;(ZSF at 33F7>/!!)="(V/RG$)C-3<U6>V6VQ+M>9Z9F2$&AG6A,$L615
MM7A;LB/!)8F+KY.XC-,9J5 at UC"(TE9X'>>7"62)M-3U"-<SFP0V3FV30 MI,
M!'X]O,M_S7\+^P-7 %,D);%2AJ31D.R!: 3"J>%8;KY-ZBA?IZS+4O;A 4M9
M2\I7MRO85:WS8A.%\CG5^&J=Q9K^9GC(V;G.%.N at Q1!<$:[OS7AF.D3XV67M
M<\I.2YU>9ZQ+<&GNK-[0;]P\+26F0,#(WD$!RD#Y<3XT(JZ:%L@);D.PN!(%
M=^0.K!]B9G\*'!6J&@:Y,G]2I1IE9G?GJZ!)"!;9L018/Z>5TE1HWHD5"&EZ
M,% at _U$YNU*:I;0/0+'>I9]A#/ZT BH030-.(8@@<CM8> \V$TDY)%P6YK!!(
M+L57WLO:3UHI-$3,B?RXC]8VMAKU#"/S9@/7T1!L#.% O4[F@" +5)3&B at RH
MH1I:VBW&0-+(?S728>"!@ B9;J$I#9TH==0OHFB)-?4W%R%F4$=(1=-T\M8H
MA'*>/:/7S: G%#0*<A&9 at FYK4!R^B?\(*J0&6A_ME%H\/B%UCK>&L.,]N^R\
M-"5$G:'3%^6IT.9X&EI5EL::8<]1D8-&;^/*Q'K9]-Y9QX8%!*F&>K&?TB"5
M0P at \RH8>35>-HVF[TC4%P(I0TDLCSBHK^Y16P at *)F at 29N2 \S2Y(1$#@:6.]
M,P^=TDS.E?L&&!4"JA5]K]8X7\YBS]4)J'DGLGSR2KY4VQT4#7PG6Z3W9%DX
MJW at H6!EKS6J&/[3AT=M8:3Y>+B5%)L9 at Z!GJ43UE<O9!B\XNG7N&D_<=6NGH
MLCPB3QHKS8KG)^78.E25U,(#>,PW51HG17.?:JFE?[PUK)QTU]KF!"0MF at ZE
M:% at X<R?_5/(S_+D8T-(P/A5 _2'L$O>39R/ET6;.:3!052+&#AF@>O-FXEM]
M;PPYXYSAT^%F0L3^V"9Q.*6:5!KBU9HS=2-9*GDBB-R?Q<_Z3.9*/:-,XAQ9
M/XL^Z)G+U"XH[ #GXMG at A0*>U2<35SYJ==/2 08% at A)!0LT'E"ZJ_(G<0GP&
MI:A!F!>BU(T([UGV9%GH<VY278,>31!J.S,#@&+!IB"=+:^,PRMH3J-[&B,]
MC'9-$]#.D-QAI%-M0ALT;FX .IM!C_&)"Y3L)'\JIG93&)\[)KQ&0A510M%P
MDD"@41SZS+[JH9+S_"09KY95Z\P(D@:'ORF>\5"YNO"?G*3B3RS(WC$ =='8
MM[I:"A1\E^HH]G3\M%^P?H( 5!I46M')-5"]P4&]08F?<5 X3\$G#(4&&+X1
M<P930"2*YMGJN$/1DBO)CC9;7)0G3>13-C#-,2XQ;Q9+H2K>IZU@(,2J(2G]
M;;)XS"5;C7!I%:H[,.TP;X0X6[K$%NV&AL782!EE#(8TWB)W)W.GI12GN at NM
M>GBA. C*IV:@=L7=W.6XCJ)&KJEG [#(?],?4&9Z.7N:/U!B42I4>=/'<NAH
MA&2AR1\%0BVTB13KRFN6D3J=5:W-9W8&KQ0,Y0#9<+Y9,,X5$#:4B<,9ZL(H
M0X$/S% X ;"FJR8: @_0.0F9AZLDU_=*;/3YC-B\":P&J9QOJ _T=%2C&E_!
MN=X"YU!C$J1)'9KB:FG]KH W?2-WT6W( #IU&A=QES)E,()/D]-3+& /'18M
M42J at #*U)C\7 at IY0+RH>>HC*?R*6"4(>'_7E2* at F5N01 EZZ,UGS)5:/H\H'
MN39=U8%89X13OE4/53\9 at -94, CSTI]*QJ4Z$G>RAP8^$R./2?3'OX5.(_/,
M+MLS*R\R%W]'"70B^B3UK<"AJ\R<D++A!* 1L@/5J$0$O*Z\%BKM6H7:?-5\
MKQ2;%ZJAQZ/SX]0ITPQ]/GN at 8,\-DST)'>KX(?((/Y51><],:&^H1F7+&NU
MNVP#'"H]#64(&_KF]#V=KQ1,JAO0%51'MN/US'U. at V0_2A&Y6&?!_UD2JGM-
M 1Y-#!NW@,^3&73M86?Q=[Z>?RL*T\RF/^#KPOX$ :8 3B"WZ/_D[)%PTDM!
MF00#X:XSP0U4#K7>#-]8BUA=2Z[9Y]ZJH53IPH;F at II $Z- at YP+H+#H1+=9H
MLN0SD1H SEN' K134 at M8!1P[99TFT'6I_ZF5PBX!I+ VBJZP ^LG3D70&OZ\
MJMY0;DT0T&W4/:/XW&D-;N(\^:W\F^4JD0/RRA at XN5@]4*Z)T>6!]4/E<@.U
MB11+)$WQU_-J,-H<*F?5KV0SNB:>S3TJU14!U?+H0UL%CXF?&+QK'.I&V.FH
M-=='(ZTFIW*4UZG0?&']#C at W^RW]D4?(;X>\(M4DK>Q9$Z.2EY= at B>!8<H#B
MHO@(4Z&?5)L3IG7(*CGQ=^)N?Z.543B)GO;SDAGD0[ at M^31H1&OE1\:J0=)0
M#>*CMRU=*$6+ ,;\ at 3X9DE)&:IT_*(I+#G61 P_EF>8VY"D[#ING6,.P*4[I
M=PA-;8-RU\ H//5BBE7I-\VDU*H(Q%7 at =@._^4]%-Z4ZXB;\U1B(\:/PM!PQ
M/"E'.ZY[$/T3.(7IW(PN0.U2[JC/39BT.:2#6'K";9A#&!Z/D&=4?84Q:&;N
MIM18MJ<:URPGN$-5,@?1 at [8+4QJ3E-*2A12J>7FVB0X45D_S%PK at 5S =&D3%
MZ5ZC.ZL#!8$B6C,2D(;Q5E \.$ZC%S6M]N,XFM-TCKI&)-&R%3&M/V7AS#ID
MHN9-21_] at #Y4@0?7619I24.:41)K#3/*/2,$P#BYJBR=)9]6EQ7OU85YLD75
M at B97$YU>C0+ at BU2,8H[^>>8V<@<"S[FI^,1YRBFYF!J;9QI46A=TG D&-3=]
MH0!3KZMF8U&J%O0NROYL>)@V_1G*T[;T\E3-5#1-A39/7 at *)TSTJ/Q7%F<Y8
M9FA;RYRTRGZIO^2D4AUIP4 ^-:V?ICTG19.,,C!A;<1&"";$E?0R1:,DVM.H
MN"0Y8J9MI9KG5F729&4R<?(U=2[G4&ZGC;4 at $D[Y=HA3FTZ\J"KH.L,&T#/=
M";Y5PI[O5/9)@V.L at C'=NERF!:3-47_36+H-O=8<F#*:B4U[AX@&TW1+ZT_Q
M<DX%:(/(YC$3!D73X6N>N817."^IC7XG,YHBH at A4BUYM E%,$]#49.K\%( %
M:ZR;XZ$BUYRT)J4#2FQ.MD9:?Z77C=:J0%KK(7/-0U$ :1H\0(J)D%(UY925
MF;!)L2?'S@ ID+6^>5"=+:8(K8%ZDR\GTH4,\ at B1H4 ;EZ:"VMJTU\DX92"=
MLGZ:+24IU92GJ"1F3-+X!"XZ;Q@"RO9C#_45XB^!5 8C0-.2$+QT6)8U!4=A
MAJ at T2J8UP3QKRL.P272^@&)8^BT:5 at +G-+33<=.@:%A+A2RD1(%*!]0 \IFN
M"19:G\UWTIQ&^.2KH3&-<B).W$Z'5(**<F,Y72+XA%1;S!]E#>R&C;.?$2RU
M0UI7\)D,TOE&ECF;ZBZI!OR>C4ZCR"=*8CJ@(2OQ<4I"::4V$0STC#1WNH"V
M<&::S2>KTKD4]Q-S&&L-/26B'<\4$P^% at R0!*O;@?D"A5)R(#7:)"/K^-'Y2
M3,TZ4AO1TLPI_</?.8_*;7*GL8^%E(FKTW3J$L^(^/"EDZKS3-4(S'7X#(RV
M>>HU<,\Z#TN&@8H"F)TJFK!L/Z6>39+'\>,_]7!*?LPWA% >%A8)66D^58/(
M<>0V+#&6ID? I>G2,C=E/V6:?AXM9U>3RPD @Z!.3>$=A!E%T6 at I588H?4P=
MH$*?W2TRU?S)JT07<(PU9\1*]5/^TOTT992NV>SL3]&<'*T:$(Q+SV/ET5U%
M>T!>Z*)-$F?'KZF* at F'IF;!;!IKR%%D3+Z1QFJ,^AQY0P=(;CYXF%"7FPJ&B
MA49$A2LQTIG&?$H\@>"@/DUDM"BSJ*]JT8EG*A<!'R):"# [CCA".,IFR at DM
M&YVG% KDPY1+<FH*^HIZJ)9%0<\KU2>TG=8&N$)99Y 'L[IC(4S46;L.421
M-A=&YE-T1\4*>?7:, 'E>IJEJ2T(5;ZIZ=FYTN?41V-:<IL?E^;SY[.&"J8"
M,!%3Q1OR**VJ5I/KI!8E2T=^IP+#9V0'"56[8O;TH5I at 9%,=CNLFL$1$>= ]
M:3(VYJ+#C3E,S'CE(/8\N.A'40E[J,3)S9/A,HNZL0X"SR!4E_GT)F#+26-I
MA 11IC(=T9-I241+/6UJM%PU#-7\#*&3D^. at 25<*EG"E>2/U$T%'9P-/&L^8
M.&^<^:3OS>)F=G.CP!<-3ELN(YW9:0:HN)$QA6S:3FM<? *=%K@)3 at -5BMB\
M/E=1C!Z>@ S5Z$$A>])4O#8[EB,(EJ8(+70, O5$I-!?LZE3)R!G&28VE
M:/P_FI^]D;BRY1+B8FL./<LZOZF 'BBU_%E43?JH=C9\NYUU)OIGT-3]\>U0
MEC9-6E)LS52UO&.W:?!\:.JHHB=%D%*5A//3)-T<C"8W0)I,JL9)NK4*:OZ(
M*W$O2!ZW$GA4,KJA(NP\J,($3!Q?4<9!6W3#^>BL=$!33Z8'*BVUHJJ8&:H0
M>.Y<D1L4$WYTLEJ] at 3>%?((^V240D-4)%56)6@,X2!$6=SW-C32LE ;8$:7R
M!QB9L$UN9A"DGGE&G9BN4?^8":7LT_YT/K3W-/J\0RTXU2N4SD&H *5E.JB.
MLMP H=*3JK5DI!/=M'U%D1B=AZH>43.T"%6$2$"IE( UJ2/; #0A,#!#NV.M
M5L$.(TWN at 2=HI+5%3;YQ^. at \I2_&)K;)4G2FJF?%38L$9 at M+T(I "D H,A"X
M>V9D_:X at S+!+D,$K<*EL07]DTR,UJM_#WP6 at Z?G4F=)JV!J&ERSS0]-B4FT]
MDP9>!)_FDY6GD(3J20&(E<BFEZF!T8-*K3-M(.8T]="?IAI29\FK%6=2E0D@
M20<0XA-[!6W+'^._NGUP49ZG"JG0B<6%OF :H)X0"H at G0Q6]@++2#.+R6694
MU*P8 13HCS9-HT;%[*A5!SYJ(PZ1VAS B&<E)26BU-9J1K7)FU -+B!3HQK0
MU)!/;[6NVNE IP;X2P^ "),(4M:C)%R J+92.PE8]5!O3#6G&DT at JJ;XJ:K!
M *IJO1N6)ZRN0[!5.Z]YU4X"8#5]::IGK%:U,*MIV<YA-AXH*PB at K<;8FT=
M=.1J)0"ZFEU-W9!7BRKV!J@ ?;6:VE$H\#=8RR(9UA0"B35T'F/M<:,<./=4
MUR9K\+:L3ZY , D#T*R5W*9LLP:.@>//NT%:,ZU]+E!KSIK5&OZ-"1CVHP.,
M_6IK0$[B6 at 62MY:T*_C1UW)K2T9\8\XO5N=6JZW]UXQJT#4%DW0-X?5IO:[-
M!XH"8H#M6HD-^EA;:WB%UXQJXS6P7WG-#;!J3:^E)EAR_H& DG^MY)9KI3D,
MVO!K"PS]6H^-OS:J"#[(_ 9MNH1"&XZ-:0A=1+(QV(QJ#C9,&Q,/=#!A(Q%8
MV-P &+:N0JO@/]1ADP.0V$)L!BH26Z[ at Q%8&2+&Q 59L+;<7VVSHK3-OA;<R
MVI@;X8L=F\55W at ID6[F!6XMZQP*>W# QR?9QW2:$?#A^]8(GV\J"J\!9TPT4
M!:QL(3X8Q<@O9=AE"ZR!V9 %2PB.5YFM*("?2K/Q#M9L6;:[&LA at ]P!G^RW2
MV?0"9 at =]JPZOWL%G0Y[XV7P.@#:6Z\:5XMIQ+;DNVCBNC;:,ZTM R5:28^2=
M7"EMT3BEJ\*..+=MXQWH^D1M=+:S*[2M[<=JF[7]W/H/2C2P':VMWA #E!D6
M%8=MO;8MH-W5].AJ^_1Q&YUP- at EFVZGMV69@^/<)VU!R.D-L6^\11FAGZ[8U
M)OB/XC97H!U0Y$99,TRRV]QMW+B$6V] at WD:<"\>849HG1KA\FXH!2<%OXPY6
M!_YM3P> FY)PTU9P:PU,6;4%HM9A at 86-Y?=PT\YM=(1OR">Z&$[MXN8RY!AL
MW I^3 at V/&S;N!C>V2_IMXRAK8+>2WQW.\L8AG+;!X:Z%.#<[6]WM[0I^T_JM
M7;5OO3?[3:I0Z"=>U/IAW8!^VU>>G]?MT,>Z(/257[5^.3FO 0_Q[F:6>PFL
M7YM#<KYRHMP@,CF9%+R-Y=)PT<$I4R3QM>9X.QLPW,J#R]>7&X=0 )=DS-MY
MZSQO9+MN7>=-)Q<9=-HI\99O3#M+7V10 T=JJS)BX/H/P#>=X[ UOI at UH/EI
M7S.PQT:C'_&- \M[B[H)&)=OW]=67P66!0E]\[I-WYQU[$*[6V# at *NDJO-L1
M.[IO]H6?0?6UR)B,@_^EX(!P[+< ++I0!BL82$L6!>AO$CJMP_W-LJ!_BPK<
MW%Y] #C,FZD-"FO^0\"-'[\%)H-]X>01BJ$RK+Y)X*1\%3@/QP6.=4&!12T>
M!FVPZX':G87P B&(.[=%,55PFK8.Y!(N!@>')!6&[32"'S?IXO&U--ENXTQ.
MOGYPT$$A+!$N].J90,)=)[1\2[ at D7ZJ-+1>%ZTQL7=N%5CA"1DY""\=_>[Z6
MX(*39+@@;-?U7$B$2\/E Z>#/#I+; XN.*E\W<1:[?1PUP0^G"06.M&3$\5^
MX0AQ[T)$7#B.$>>(HQ<:X'Z"8<(PX>I5TB$50 =:^E!QO5AZ3BA.;/@M: ,:
M 4-KP-A28*FP'U=WJ\6E"A=RS5A;H:ZPH!&,2Q46XX:,+ at UD7!- $5 at $^,A9
MVJ:24,QI7 PR79B'G2D0%*=ML-AO7").7EB++<<E ,YQSEAU'"6B'=>+V^3%
MXWP5MXITG*SB'B>54PR>)K1U?0G76C_.&1M3%,B-'P6R!KFT1D&#P*&0JQFX
M.&(:#%F(7"Q#(I?AH,AM."QRI46,'$,1BMF1Z\:Z"$M^(;F/[$CNXVJN R2
M9 $4+SGJXP&6 4N3"]KAY#AO,KF=W)NO)^>5 \HE#_V/,<-P 54.NMB.9,I-
M^A(94+FBW%1.=5>5Z\F"YK9RV4#UX4]N.T=\,\ Y8%%O<;F/ )!I+6>3@,&Y
MY?)N4=FYW'/!+I>84T/!ZO)Q2,$I'S^1Z6>R:Q$0YB0$++MG85G6/]"8<[<*
MV]:RG%C '&4.5G>KD]5EYL)TYCKRG&^..9>?8\K*Z'QTJ[FVQ[=E.1>;TSIX
MZ+ASMSDVDKR.+[N<:WLTYX)S)SK_7)C.2Y><@]!5 0^SDEGI7&9!+WN=$Q \
M9K5S_3GT', N3A>>^\SYYCBSH-G(+'KN8->G*PJXYPBS\3F_+''./L>;P\\M
MYRB6IEG(+((.,=NH0WT(Z RS>]D"75\V-#N;7= %9L.5<P'8[(3.1+>;E<Q>
MZ")TRB8('8=N4*B;K="%VCIU;0_9W%Z61)>;3<TV9XEP*;J:++C.11>8XQ:,
MZ_ZRYKH at W<#+3#?PLM>EYE9SZMD;G2K.1K>F>=>!Z>)U3#IZW0T at 2N>DJ]<Q
MZHQS6+HNG5;"3.>EV]=E%LAT0 $SG;^.43>:7=/!Z:8T;SHUG6L 3<>:3=CA
MZ1!V:IHA'9\N8?>GRPD$Z at 9UH4,P'8 .4:>HH]C!9R-UJC at ?Q<5.*6MGM-1I
MZD)UF[H6;<?N4Q>J*QV"Z5YV(CL<;;5!55>>A=$M)+AL<]FLVLHN95>K at _?I
M: ^":(E=7=B."1 at M?%L8-Z)US W#JT9P:B>T2]9Y[;P&U+= at W<-06A<Q; (T
M:2N&20; '[=N[3:>M<KZ[,RSDCDK77J6/ONELS.JZ^0 %3LV[8H638>?50XT
MZ:9T]CK*;+XN>_"?%=/UZX "_SH)K6=B8!>GH]"JYS"T](>%':*V82>B]=!"
M[!QVA[J)':2V8J>BM<^V:#5V,=HU(XC.4V>C932&[!A[(SN87<FN1\NJ^]&F
M98>T0=J675UVYR"65=*FZ*ZT@;@E8$X/.'IP[-DIYL:N4L-E)W&-:!<8,-H-
M<(BMU0:E';;M*IM$>,HJU:)V!3\J[7E6 L>KC=+@<4J/L%JP78H.)6=\W<BQ
M)=<#=CL/'-L.+/FV^R16#>^2[H9L;8P,+KEYDTM6#?5Z[ at 8U;$[O; #[*]QI
M!&IW% at OJ(U=R<0?[D]P%!4P&D3M\P^2.S5"YN]S!UU(3/3_.'9Y at U@2Z at SK@
M L<+[4060NI.5O!6D$ZT[I82KSNS':XC8H&N)794+!)WN+ME8-%"=_?CX=UU
M^7YW8+["G_T.>D>RM=[%]4ZV)=O4!''/9)NR9>:Q;%^V*EO+'LS698N_:]E&
M]D:V,]O('LUV9ZNSO=GV;%>V-=OGF_\NNX:.". E:=1[NSWPGBSPF-IE>-%
M#C(3$#SWWK-UHE'!ZS)<\+9XY[T-WD#/I8,56.2%\+ "Q[R[121HJ_#+2.$U
M\:8#+#PT@ L/B=<<&@O(\ 1[[;@;WA(BWA=*J!WU\#JA70,@GGQ B.?..Q-L
M)*X"TH08P=-NB8?7TZT]\>QZAMLIWF5'Y##7>>5]>FAT6SROPK7 at BX<C".,I
M#88 9+SM1.C at C#<"7..] -IX+X W7G$.1_ 1E!%\\^QX.((\'L(A2-#'XT@
M\EX @KQ[X N at D'?(*^9E=SA[C3RX+8E/DF<QH.3M]2YY^+U-'ARKDS<1^.2Y
M\UAX381@ BD/'6'*0RN at \AQZ. )6GBL/1S# BQ',;>$)X0== at BT/WX'+VSNT
M($V%M3X;7N_ at RT.V6?=5&D at ?O[Q(D._6DJ?,\^;U;)UY#+UH'C]O"+#BTQ)@
M\P1ZVSS6'CCOJT?.0_"% 1A\23U0GD=UID?/.P+%;_%YK#VF at %#/LF/-L]^B
M(QA\"P*8GD'/PR=R4.X-#1A\+ $)[D2/I%??N^CQ%.*W&[UF G"#P==.DR:(
M]"BXOP at $WPI3G]<T at .A)/$Y[,KV2'DU/XH'@Z^YI\<YW/[T2'L_B6##4L\V8
M7&="88H.7 at !WJ8=6^+!^]Z!Z!(FIG at PO?G#,PT$P!E:N%#S\K5</A/N^A88\
M >"V/%N at +<TV2<#6R^+*;(.V8-PM;E[/5*#2Z>O1];0*?#V\WOD.L ?<P.)&
M;@M[B[W?6M%6JZ6M<*O%*AQ[_ ?(WOENLK<[\.+6[SI[F3VXPH;/?"O=^^SU
M;I5JZ(A71YTO,!'6.^U!0IL)JCW]K6O/H!?;:\?-] at 9[P;VD+7#OMH?=XRCX
M]C*YFUSA'B5/B[O60_ E]_BWRSVUS^26K6'1R%M<#ZY[U;U7[@;OF*?=4\-Q
M]PXZC8'O7G at OAD?> SEB;35XLKOVGF[ON]?>:PYY5N-[28(@ JW"(#"W>^Y
M<(L "+XB (!/P'=U0.$>^/BWOP8%'X/O"8#"A?!)^*H %#X4+H9/@YO3V^QQ
M^/@''-S\WH=/A#O.$/')<:M-1[RG[97CIZ?B0]"Q^-8"F@&F &M QM>!K?&%
M!VY\3($17PN1+'B(A4>E$SD&0S[^(A3.R(<'5,32\WQP3+XE'*OMR?>%76$\
M().T53Z^1-7BRG>ZR_*)5WD'O;OC$[$G9"OF$[:5^9 at -9SZ&XIIOXQ?SNPIF
M^R2P<[Y-WPY65^CEZ4YHWR1^ at S[OJZGOSZ?UX_;=&'%QU[Z?[M9-J/MZ\R%&
M^ at R"=;C>0>NMT[=-D.G&!4!]>3Y/&TLQU'?J>R*.UR!^;3]57_B!U>?JR\%^
MWU9NL;Y7PMV5U5;KT_7A"+Z,O<AW'Z[/P.#K.V1D"Z!]WCQX([)OK6= at 8/;]
M^J .<-UN@<_QV"?SJ_;9V8*Z+@)MGW3"IYLYL#F"^^H1[[YQ'V'7W.?LX#66
MN=1]=+F8 at 7PPWR<T( O4^RR[\SXIK:> LON+V.DNUCR[UL(;0<#OW:<$/ ,:
M_$R.>3B"(@LKYY>'P^JZ=G&ZQ;J*7Q.P#)CQ>Q]L_+RMPL&$(,D/)'<*3/G9
M=E=^^36RZ\O/S6=76[5Y8'-OI8G5+M-1YY=TZ_FE8/L/W%<!XX2QZ'?PL\W=
M!Z^$KS42(-1/#3CUFP%F_5R%'<"QH+95ML9MY?J5_=JNV=VTWQ-Q[:<&7.^Z
M_;R[<K\28_&@[E>WP/OI_9H+# 2_'\.-IQ98LW'H63\"AK^TGQ!P\7=S"^]J
M_[8 G+]O0>4O]\<^M.JP_F!_GC\&K^B/]U?[2[TB_V)_JS_:7^NOY''A-:J1
M&HEPO3\6:X>7?7 at T*/[)8T:\% at WBGX;7^/?[>_XE_U80423F'[P#Q:MLE?XA
M&HEEUC_G6E/QYF98G/]!'26 F, !H"6PL[C^<SS>_YZ.F\ AKR=0$VB(>P2J
M_T2035XE[SNR^PCD??)R'QV/&< -8'@WZ A'V+2) )M^B at .3 19PTX8"'/"R
M !>/F;X7H'IW"VCF_0**[:YV8D UX ZP#'@&9+6E 0=O9EYC[!L0RM>2%,-*
M7J^"HT!<))0O"C at %M$E4 <6\5T"\119PS4M]:/-N 6V <-X<H)R7#$ at *[ '.
MVO8 =]XUX!"0%'>,C2[P>?>)=$!?H!<V 8 ';"A> GV\(\ at C[V&1$BCE#?(:
M>:N\*Z%#8*O7RLOD%0R>_]Z1?\!08"(PLDCK30!N IV\D< [)&(1 PCG"_2J
MXK!VI$CL;NAV ] at *7 )Z82UPLD SH2U08\O)0 ;:)'2!-HFMQ<:"&<A0+!.F
M,X2!N%IE(->B:('MM3Z4>VL&;SEJKW"0'/CMC09>WL2]V]Z-;34PVW at -M" D
M9:V%W$!JK]]"."@.M+2Q>U\;YD!WX,CB%\M0/ ]HVLZ!PMAK6XZ0%K>'HP>&
MW_ #!KA/[#X0L=L/'.C] TT) 4%6VT#PJ&O] at 0-6((@'(S^_HVN-(? at Q9#?@
M"2\0%(<PA.P/,/DQS B""A\$HL*JX4?0 at D$93"*X(CZ&)L$]Q\=0)3CH2$-\
M#&&"N\'%QL)7%NA#S D>(7F"DT$2!Y_0,'@B%&P4!?L+D[X\ at YF0*7@1$ [&
M(Q, 4D';6YS09-$S7/1Q%W6%C$&N8*H0-#ACQ!^$WP2#B,'((&-P^089? NZ
M!5F*KT&ZH)/&+O at 9U O*!?N"[4J/84]6"H#V%0L6!MN]0D%'GWJ1Z;?V92DZ
M!E]O;]^TKF30)UCS96SL!>>^MT'-((KP[GL:[ Q&?F6#<E_08&OP\IL;S/RZ
M!B^#G%_6(.B7\BL67 WJ!K>^CE\ at TV_P;!$6$ YB;K6$Q<$8(?UB*M at 1*!6*
M!Z=,[X+GH $N_VK/(#=RXYJ#YD#2:W>PW]8=K!J"!Z-QMU_9P+N@/*CWK4E2
M%IN^ZH85X<>P/3B6 at P]>WN9M]$$S['6W)ZL?1!*"&Z"_2X at EH8"02BB'%0XF
M""UMJU<?(=$CKC$EO .8?U^$_<'_((VP0WB9^!"V?Q6/30&&HHE01M at C]$Z4
M]:B$5<./[,G7A,O_54*(?U.$-HG_K_L7^ZA7[">.Y=*_]-\G84XB2GC_93S"
M?Y.$,T(FH8]0 @R=H "'"(F$Y5^&8I:0/Q at CY!*:"6.*N= at Q8880"M<EK!2F
M@&]_,H.<P*9PES 5-&S("2L,^%]^8D_V3D@"_OX&U[(=>,D^H:/P80 HC!3:
M)/*%1&"H at Z&P* at L4-!,F"I/ =$9&X1%X"#QG^/:Q&22%&5E*X4364J at FA %K
M"J$3G,($ +BV+2DUA/FZ^T+ 0U^B+JI0AI at JK";BXO :N"UWJP0%^>*K+OA
M"H&%3<!PH<;P5T at L/! at ."[5^$L-C83DQ65CU"Q at V"X&PV,(FK9:6%2JMD](R
M 86%VT+/1+?0U? MM/CI at 8^>U+ at C;+EP7'&>#2*68]>%U\)T++QP'2N.:\?6
M"ZG ^$)4,$9V"ZL#KDG^"PO!S,*!8</PR=&EA00C!9%R8MIGW9.66LBE[0I^
M:7<+%D.&8;LP8X@)OCY6#36'!KC/@%V.9*AU,!ENVE"&<=<N+,MPH-![A49H
M'7*RSK&QKLUPH,!&'-LE7KO!0]^?83DQB3 at T3"44#>V/(D-*0OVDI'% at *T;6
M#)Z&(]>H(8J!:O at Q) Y at #45Q94.RH3[X;$B,U0?G at _/!_&"' *M-;0 at YW!PN
M# at ^'\,.Z8>-P<? at XW,OI#1>'D\.]7.60=6 at 0GAT.#B&';D/((4(X<5 at 1GM<M
MA&^''>'<84AXY$$XG A?#D/"FD/.8=OP<S at WE!_NY7"'NL.MG$28=>@Z;!NF
M[M((LD/Q8=MP=. at #:1O&A/VSO<.V(?"P G$0S$1L#ZF'X$/X8?'0+O<\? E3
M#[4.V,.Y /;P>@@]U!Z2#XF'Y$/O(?DP*2P^I!Z6#Z&'YT/H8?K0>/@^O,F6
MA9L3\4/185HX>G at 6OA_.#O6'$N&UL/_0=;@6_ at 0-$.O"!L2=\%I8 at 8@_' B/
M$"N(I($,8DX@@XA"I!]6$+4.&<2YP :Q at NA![ N+*D:()8$28F"X at #A"+ PG
M$&<4?>&!;KHP* !#S"S($'.ZKL(:XIP/-*PKS"%F$W>(6K\>8OCM5SLTO->N
M$IN(F04CXK<0B8BXN+DM$6O#KS4G(O0UBH@;#B84)G##5L2GPZ]6BSB6ZR)R
M")V)= FQ*P2NC'A&9#?Z&M>(/$-JHT:WF?A&C$22>AF*<T3$7!W1E8A'? TG
M +** at \2JHO9!KOAG""7V$<7#?T3_XR$1DBA*9"@N$K7#C43O,,BBE>@=GB3N
M%QN1XV%,(GOX/,Q5' ]#(F%P^^'>P"BQE)B0M.6F$O>O\V%0K#6ND!A+W$)J
M)%.2PX3:@JE-EU@>O at \O%'R)-<1 at XC<B'ESU!27>AX^)0;E3\#(1/<Q\<";^
M(#*2S\4FAG5XZ.L&WKI)8_%\V$1784YQSN>&I,'J"L6)6C^48? at MMXA.-,"I
M$]F)ISMWHEOP=!=/A#S:%>J);(9[(CUQGRB6A2PZ%-5_ $6!(F!Q*9E97 F5
M%'NR/=Y8[[ W)YGPXRPJ%)W$I]Z5T&31H] at EQBP2>:_$-4DO\47QL[A\"RWZ
M8]>P!.!Z)/EQAF%^U#KR(M_$_;<F N>11^Q3!#T"%9L(0L4F E'1]+A^I#Z^
M(3/!U\+98FW1J6@;CBKN(&Z/_$>LHNTQ]LA_1.=!(J-Q"TG7 at !%2CWA65 X@
M((V+G,CDHP.R%)F-FS[:%:V/B4<&\.)QK_ at D7@GY%0UP4^*"(E!R @@F)O+F
M>B.*9>)9\6.1\<CK%1.C_\9RED59,5-R5UPU5!-C MG$548W<>2QZI at %EBG:
M(^G$*TA_; NRM5 at C-L(FBA?%M,5&\6VQ\XA.#$+Z'BF1F^+O<*<X(IF G$C:
M'2^2)\D',>^ at *B=]G"Y6BQ&/8UXTL++WO<A#3"^F"@.,&2OY:])Q!>=>M!>;
M#$BP-TCTHFH at \5LS !@')'41"<9?8WJB))!?M!<W),H,7(>CQL$87SQ at 7!AK
M%F:/X#W8'\5XP<A?;#!:"W*/$$:*\811TO Q##:V&">.*T99((T191PQWLBI
M&U6,+>,3XX<79JR*8_I!(%J,<[X7X_2UU9 at JI#&&$XF-.$0Q(Y%15UAH]#$F
M&NMN0D97X=#XZ&9D3$J*'>MPL at TF(VO7Y1=MY#I&&:N,4\;(X+8QK7MQ[- at 1
MYS2.8,9@@M"XOP!R?#GZ&64:=L9"H[W!Y!ARE#-^[M*,E&!-[:TQS[C[:QOW
M&>>,<&-&G:!Q;%QH5.E,_Q*-?N,;;6^-$ at EIY/I)&C,+E$:9GZ6QAQ!RC%AL
M&G.- at N(P $*NB;!M?#4"&V?&C>-O :JQTR at Y+FEDC:6-_#>@8,MQV$@&R#3^
MC7&-G./),8GW.7PYOC!FCHV-\8:"X_P2DS,S>#5"&UG'T\9T)*OMV[C7U39>
M&LF-LT/><;$OVRAN]$P C]V-Q+[B6[AQ=#SQ+3?NCL^-P^-PH[RQ>>P#?"@(
M6Y>[=KE;XL#1:N!O-!P#'($"=KGML>R8V8C)23 at 2(1:.1TG68Y(QXG at ^GCAZ
MB[O&\#ZP,0L2N-9QM#%^'+T&+\>18\SQPVLW3CF6!&*.+<?^,<P13 at !<FSDJ
M!VJ.M at 8.,</O]C8UYCDFCZ=]0$?GL-"1PE;@,#I:'Y".P@;E[L:BZ5B'=/6F
M>J-QD,<0'+.8%>PLGA.G%@&1U&)#<5*1$(D<Y/H]'+7%>V*TXPX2SI<IK at Z$
MBX>/GN(EY-S1N"@JCD*")-7%QP)W(N!QY39$ID 2'N>*[F(5,JHX7HQ=K$DV
M'G^]4<?,@0C9!RPG-L.B\E#(5<;-XTZ13_QY%+:%'@'%HT=!<>F19E at H/A6[
M'_F1+>2>9.M16PQ[S"E&BFN/WP(W,HGXDOA5Y#U:AR>11E=+9'!Q7/PI-CZ:
MBY6/#TCF(Q'9^9B&I+:N!$R1260S<AV6B6R'!4'V>JF\\L at +8?BQ67QUO$?:
MB?.1.,A]I";8(9G]DT0B)(^&!V/8GQ"2$5DIKB/_'WV0->1*Y":9(@G[,T"2
MBT'%YF)/9" 9%+F7DT &'@O)NU:/0QM2B0PO5O3*).N$-,EUX)+7U]ODS45F
M_^:1L+\J\N41'PF,/$CRDE./JV1/\C\2E&R0%$A^DBN.H63ZHDE2IYB(1"43
M(37%#4E6\N#.E=Q'9D(B%YV0346+9/_QAYPBUO4*(=7)'TD4<1?2G7R%1!EN
MD]G)\^0O)!\2EWQ$+A7ODA7)&<CBK3QR%=E4="0'>^&1G, 2I"09#4E"KB1#
MB['(QDAG,D Y!JF(Q$%>DVV0V63(7_YQ4KQ_G"/K'B_%"LEOL at TYG#Q*ADB6
MDW?(R$=Q<ES ?DQ,&"((E>2O8SHX at WNG]Q^7"3[DE61,TE6Y,>P#EQ.A$7>
M(GV(M,B]FRVRR"CHE42Z(IO)^DA,\GE1&!E1UD6Z at W6\3D5D9+F%';R,'"*&
M(Y^15Y.4AS12&_F,I!"1'(=M301JY$N &^DQ\$:J!MD,X4CG!!:N:C'9JZU-
M^]"1.,>GXCI2IXPEQO7B)(W)L#]D\N!.F6Q)9L'>B:'*^LAW,339YJ9^O"CS
M(*O).,B!Y SY!GE>W"83)*G)(65P,4D9$YDY."F'BE7*A#<?LCQ9)(E9C at MX
M)#&2/ $RY+J8(TE;M">#EO..*,G1LL8 IHP*E"DO"VC*A^)4I!Z2H)S],RA#
M 6[%BL65VTY2??R -!9K%FW+>$C7FE&RX>A"]DD*BZO$4 T\3KP! >5U+1)
M)9UU9TD;,9[O+9FN!=S%UZC+Q YNK;M!+.F=\SGP)?]S?DEK,:@M$_PIS/1A
ME]<#<4DR<-60+EF53.J.@;4"PD&]9!G at N]P6""_WDE?%5T)2*V$2W:9NN[PJ
M)G68>\IO0>ADZD9_!;P)WBR3];;F"1^6!_>'U7M])GF3H\F[ 872-MD5M$^V
M)E64)LIJI8?2/NDQV%!FF/$CMLF4QWK2-PG 7$\.)]>354H:Y7*R.8D# at %%*
M)ZF34\KK)) 232FDC 'P*+^398 IY7 at 2/<EC+D_JF$L".TKW9)3R/3F?%$^2
M!O"3A0'%T5&D">6?G%!^F 64OY#+ at X'2&&(+25#^)QF4QDD*"X0R+2*AU#'#
M.RR4(6;QI(82./ED[E#J!4:4GP$1Y8>91%EA!E$Z)AL"&&8+,XN2./E V5%"
M)U_,,\KDY(KY1DEGUE'>F'V4,^;MI)/9PFRD3%(:FHTC=.8FY9!9/NETB$^&
M*:N45\HLY0&O#,"E]%*2 =B4(\KKI!D at 37FFY#2O*7/,;<K/P)LR3CFG7%/:
M*>MZ>4JI1X"Y1;F-]<%*,3<?NLO2T0QJ </W75A:*X.7C<I? J12:T*HD<?8
M*X*6*)8\0?'C:NET$-"M$8( O.;62HOAU_QB'0WD"5X,'\MW&,$2@()L;F&<
M/9;-895F,T. VV(\D2Y-FX_-L4K2P*SR.;/("I--LK:7BI\-"N<$;3G I."8
MF^=6EAB7YZH2?SG _ RD/,;-@:\GP $0,>D$F ((OHH 40"GGQ, '/+VV<+D
M!-H$#(%O%>D23*9OI at +PF_W-@3?4S_8RES)2 at %>)48B8RLLLP $P$).LO)H$
M"!P4%V>%\XSK"]!P?C at +OJQ^>J^",V$&FE)!"3GC+L/-((!Q,Q1 Y:P&@::@
M:E;.+A_'Y<RY)N#Z2%8RYUA6O+F<L[UCYVP2" +4!/H3]4L5B,02C&)W6,KH
MG(D /&>C<T2$>C.YI%H:O3S.3N>A,]2YZ%P30,MTG:G.'8.ARMWA9.E%R3H[
M'YX 4F<B !' 3Q-VIEB"T8RH&Y24Q],YZMS!M&4U!":5IH&XL_+2ZSQUKCN'
M'>[.(('FA=XYA(EV]COC";R7A!D\ at =E9[6QT;JH)1 [/D\J5L]D9Z1SY at #S;
M*CET<F=[1]\M[;QVKCHKGON5+X;!L]:9[ER_!#*-25R>F6?G ]C9Q!-X;OVE
MGC?/'4R2 at !?E>91X%CT['];.L>>80$/@8DFQG#P7G&7/N^?+L^A9,$.RF3MH
M'2JIM&98)4<6!2?%%$] at !HJL4YHK)K@ ,_!C]:>50UA6Y9UMFH<, U3'H0&8
M,2-"^2L]SSRBO$3'B7UP3&9 Z)GZE/5&U,0? *M)C7HVHTT'Z5[G)]K=>0(I
MMWQ=_4X]S6W4"?"(6H-X,0%;=8,N@,C3 at T,6M2&!:,Z at +=38Z($(AJKL@>+P
MK]0S7J1DF&:H_%P2P G$?Z8]<:/GC+B']S4?,F[-;C*:ZYTPUQ (;@,W_2(Y
M2,59;)[1E0LT^6% ,;%::^!22X03I_IF_!4\JA,M((X_*QU\IFVGGZFG>9%=
M>_!".*C*30HH$A2M\3\S*9Q;@YR^J7EFOJKGN2"YB2B;*U(K'EU'Q?6=DNI\
MI&C0S)[QB$='?6.$K at 81CD)=#*1:$..JIL5A2 at -P)AJA!@)#36TUC<JA*EFI
MCB at U[!J,:0S4;]I#9:$2DPJH.<U=SX\SV5.$9D&77_8G=ALKU*:FK*-2+>M
MM&JG2BM(JFC(=?6E:6E"0%<Z4I[NYBVT=-"'MJE 29*;[;373GYGH'5CVGX*
M455;ZIGU9KD)@;0]RD3[+[O0+))M$O,R0\.P&0H-D"RA0!LY&\$GZXG*$3I)
M4GLT_2$-#BJZ;06 at *0@-E/0VG:3O47()(,04T#7MH7-$5::Q at +W3!7#"<>K
M1G"C#!O'B0#:_PS- NJ at 9]RH_\V_!!AGI8G@)&&:9QR8]=7#47A& -V3BGVF
M- J<],LN=+EGI/.EV1Y91QL_^1JWCRQK.]/UB GA0/T\VM6*IQ9H!OO1>A%Q
M4D U/B9_S$#3-15^AD/?CJ at YY&<T$=@'?XJU(EGY;AA6I,TP="V3,?"!MMJL
M;2([0R):[4\,U;7DL=X0JF W/SXV0,KS@<-NRO,HHE\U=S?*40?Z5^8]K07I
M2(G1 J$?T$<:'QV2# at P)KO V*YY(ZB[H#Y)PTJ$&@W84AU%[E+KS4&I3A6_Z
M'/A36:Y5)J<L=E,JD%J)N\ZE(RH^JN5S9)/#Z@<]5?$[ME199UEGMPJ<TG 9
M\+!2#J2 at 9[WF)UTA<(."L^!9NZ%\YTH@"TI J;'J at 8:G+IAH$DWHYV3]*495
M%CP/?R#*47=G3E +$DJ;D2:D'>FI (/@.D3#\O-D/O&BWJ)&F7?TPS,N6K)2
MJ:)2EJ#V4<@KG8&K\B>-2\4SKDU>369'']IA&DQG$FPX!:X'2KAH7.&J$F at 5
M=PPV^22/4">KP[,&.'YZHE at _L]-6JIQ4Q86W:>>8I=M\UM.%&[ ,+;V*RE,\
M/D.=5:VB38&BE/1\FD";C433;27R#*RG8LJS ;\5A%JAXIG^#W['EP,42/8H
MO%)&/KRP &+']Y4A&FFI=8 "2X%DSZMFE"H*8C.A9\Q&C3*P5L.&+)VD('AQ
M3]^C&0/O37<SSL.[U>=T'&:?%:Y.:+PI*#2G*0(,GX15H%&PX6B'/N6=%MI,
M=_!O!1W25=.6T9..:GCDI?N<@](2M-L,7',KVZ&6M at 91;JZ$F>?!VF7II-]@
M-GE"[&D4#8IH;2.%#O!XKQ;4RHE^M/IYL:.3$]%L=LQ%HJZD!Y1HOF,K6NDT
MF-A%"M.MU=:.LT"YHH%6M: )IH(V3?*H*U02:GN6M9):2:Y8*$=(=J0YRE?)
MGN >01#"4!X)W-23VJ#JIS0#5C3+$;-F$LI"%1)]C89'6:8,C_7*F*G=(DV+
MC6Q)KY"13O at YK(5UJ at F=<AQ72Y]$ZKMTO0H68YI*JL:9-H!G$ :)81J?^1&]
ML*P2M:'HZ-_#;@-*:$ at MB\)++TTK#7RJZ-/+61CI=V1%:-#(E/K*;F5+FCN,
M=/A89 $163K(XI(*74./2-K09Z6"T.ZF4H2B)O&L>$28:IIK4Q)KJ3-S;H%Q
M ? at D!)^XCX,:KF,%];"6JC>J%. at QAKO32I"U\GW]IA0W.8O]F[GI@,6V >&$
MH#>ALZ*DUA.Z*D7IJ9"2;RX]ZAFB0#^:Y^5+()*B!6)B<0>9 =&+LP3&3!DM
MIM^:UIF9<P[*(A052%"?2#MJ4)P%$73HD/2=,>A\+CJLZAP!K<\T3#HMW< (
MF>BGG^JM%T6+%<31Z4^7515!D1M4M>4B#%H:10&,WX@ KFI8M7G&+%!:6G*!
MN>A'(B+ 4HA*9S-511N=@/0VPP-G-:?(9$JEWO-4>EB;$FB\* #%.E,$H&1F
M@)I//ZFV36N@)T##$E=2*&;4/SX'S6;'>45%4$P%0F\)Q>@JC=N4']1K0CV1
MEL( =1X9"2_:4VT_Y6)5M2($Y[1JGHM)8-T8H.P4K/L30B,!#:R:4I;:FME
MEAQ4XR!PU$KIZ*0M]9G.1Z(_'^NXJDI:4$4_8FJM<7!V;BI4F8XT3TK7"VX>
MJTN at S)^DZ.!T'<T.(A%=KC+0'=:,=-O:4BJQ#O5D#,:D'>I<J)7:WB'%"2$-
M*B^J1&LUJM&Z(,2PMFW5,1-81)LJUGKGJH1<4F*A94YGKVI[18^F<9TT54$Y
M2#O3Y6F7] =U0C(FJ2*MN# at +&@;S$ at Q)8^W3(J,.:EA(:-1\M5F)HL6Y7O&$
MA#1".!N_3<&:") $P%Q/K9T/0P1;CSS,A H?<A'QM<Y+U5"8:;,:5$4YBC"5
M4H at [9FLW4=K:PL7:.D"AKN734$]/T=Y&;FVRY#'%KHO6_B7&-63I":H8.-GT
M:! U7J">YO1G=_T$@/OXKC77"^O at -9FK78WK+%Y;;<1,J:GSDK3)8\VZ;GC"
MGYE:#!OW*L('@?4]98VN:'Q/"2MX=12'FW3AFDYCF at #1V^N\-%ZT+["1 at 5W;
M5A?7P.O2$A8(5;I9H!.AKW.?BQRO0,HH8Z-VU@@% 3I?F>M2JWEFM8:C4<^
M;,RGR0\9CL2 =?WA\3WY>5;7S&LV5F0:1378LNU9!1+4'!SKE0R!-HT[G9 T
M':ZI!*0S9Y%+=*6Z7E[_22?8ZJ#KF'Z)#;U&+0A!+C'5]*D/S0=;?0VQX8AF
M;%P?[VL5]G7&_(DIM477;+XSYM.5B;2T?:4X-6LRM0:>(VBE@/KT=<7$]K#J
M<<BH<A#PYQOZK8ITHG!ZH:9/]QMY3D8*/'!=S6RY-]^F:*&=4\(,48W82=FL
MCSXTGQS.4U]:-\ UNZZ*)79/C:7TYG*'-; ;H"GE4N!<*P&7D[IFNFF?Z66:
M9V@ *1KZDQ2+DLE^*I&ZI U6#!]JCN"4?-.8\N"8AX(U9)M<4*/:MYG&\F37
MS_X[?IP0*59 at A9F?-G')-;M;B9SDJ5TKBK-F>A-I53\W]LKPIR&HR$71&T,E
M3?T\J)U<] at ^5P'2J(O5PJ/^F?: ?3S\Z* at 3I]&Y:JJ,_E&Q"]NF(C9E,9617
M-\G/SR$X5O#HY(33)&L)LFE*7Y^1CJ2Z' JTNEBQH?91R5+#I[=)XG2W[MED
ML[6?ZD^:)C+'@C(9ZS $G<*=X2$US at $*5A7N(G=)BVXV[M)I5=[TU;/JX9N*
M:. W"&=K37<(5-W%TE&!L'2<@H_U;ZY%FS7XFEEQ1.V=T^RD$-UJ at [4R(LR@
M5OX>QJPTV;ZYW88;]24H9V[:I('R%KD*Y<QQ#NF T6H_/)NBREF)IKTQHL<X
M<4H"0FV=ML.9I[TRRG.2/,!H.6VJ3\ YXLQQKESW04U<Z(.J6)M(@Z/4+DZ?
MJ9E0JY0G3? at YES+AQ#KQGN)"#=;[#-39/N/Z8/SPKNW:[>OP3.-Y.U/"QO+X
M:> W(YO6YX\FZS'0) ),<&:GHJ(=A9>H-EW2]B7P0E(,6.V;RE>HY$S5UAB
M408HD6T15K?A")!RAH>:K+R;#)<;53"+#6,36*5$M2G;_>:5$>FHM W5%I\H
M +Y"$6<I@,:9"L!QKD]=LG at #)R#!S<T*6#.XD2<=G9(^.J=_CO0C5I0MRO#(
M/<@Z_JR=D77F)_" XB(UMJ5AS0N;0&9[7A6SLE>AJWRBRQVKZI$HPQKME-J<
M>4PN)9O]&^!*P".I))4JNYXY;:)'-A"JUK2\E#^19\*<IDY631 @M7G*VFK*
M4K=7[NV^J3L*6<E)JG3B-LE$G:S!#9[ST=D3(#^;/O&JQ5+"C#WK?$7#FY.*
MR.X_M$[5DAY at F&,H6G5BLC*E=QWA at !C@UV/+ at A)ESM 4YI T<]FX:>73F-A
ML7^C2<R^J<$TT4,()0W%5OM$LU-.J;MS5G-\&MS@,^]3_FW^CF/JF7V,TFII
MCA:F"Z=FE8O)3^/CW"'9*-Y$F;,0*_*AU$F#2J;.ISG1<"BI%BE*]'0C<DR9
MLI5=BM1PM6FGI699<%69M3X[I\R5C[MSRM',O%PEJ.Y3:+:QYP[AL9H7>FA[
MGI at U+2\[ER 'WK3A28 MG.A.2V[UJ.EHQ"-;'9!::S0ZP")@=([;/2/ -N<P
M:_K9!YOL#3-KZ"F"7I-NOQY*7I]QZ(7G:15SR!=E;/(\]Y^EU.^*<OW5[ME,
MN?_3<$[P4I[TRPV23E65>$I><()HJO/IDS.[$9PFN!%#**,?EG>A:?;Q%&.!
MK$I"&1J8S21(!M 22MFH5 =(A6YZTD=*DQ53=1&5D4I#+JRU$V2).5657NY2
M.MNCN,TA5VO'LLF_XFM-LR0# YS>44E(DZ.G>@?9 ;+=KTXF%>3J?V7:9.C,
MN;-2P*O7 at 7!HVZ7,WN,,D)P EET!E\)*<X,%2 at *H)I*FNZ2IYW^*Z',H9= at 8
MJ9T[8L8B08Z/N$HINW>+.], S&BW44!J0TV\F=EDK:G<[DQGZ at *B$1HF5:FN
M>,Q('BD#4' +GPHL*N,,N@>>?.K5$<&"C82/NN$DC?J38.MO-G,I(= U^DF!
M;*I,SNZ84XY[="92E0^<BNP=8FQD:(VJ=(3B 8A>=EQ5,QQ/M=/!2 4'H!ZA
ML?9688+* at 6SFSZ78(5#/::96MNA35*L/(1 1]3 I<$G>7:H(2,14UGV$IIXL
MCG+:MZ\.*_B-55.KGB11#CI9[J<,$W-HAF7#.00-QMXY3-O4#8!ZC8 @6(^>
M=I;>&B3G)2,*R^W,@7GB at ^Y?$VZ*Z+-RO13&''0_0?]4"*\03X/[ZJG+.:3&
MA?8Z[5!23E)5VRGAWL_T0QT484WZU*JG 8H4'6=W1W4[5R4-T9#L-XU<4E)I
MJK;=P&FN]^ H-&!3R6FWXC15+^T'$$ at ES?/=8MYTL#HGLV](UE<HR8T5*%*M
MJ#[;ERIZF(Y*H68W^0SDM,];3*HFEP8) ,)""L^$!.P.SAQ,S%*;'H;>PECF
MEZC?3*KZ%$<T\GVQ*2/=B#K?A4\0T#&;![6I&6D%!R8UP]*. [V(SV2MX7(C
ME9 at UP6YD)XBZ!(4;RI["G(!98BJ7F-!(U+FSBG]#KJ[?B^XCT?T'T8V4Z$'-
M:88 <K;XZ%@;*D4V1>)<M497':+='^+F/-T9.I2(MK=2^JC'#G8[]7V=:?6H
M%9)?3 KZ at JV[?,B=T7M]'VA6C!\,Z=%*5D7S. at VEK/-!GAN^Y]03"B)0FDV7
M<4RGUJW_44BK225*G7W>0"/@7#QK9C&T983N0F/%M;51ZIPJ]]S;!^.TJ7V*
M>:S4TB2WDZ=T*C"=Z6!QD)ZG-)F<3/.HZ7 %5QS-&0 RQ:Z1(Y:D+T S6H,<
M$J0>-!\LS\;*![-/(XL(/JQIAY.XU=RJJ7U=&8-_P3\#O()OE2\NFSE/(M)8
M">XU[JH*Q1A\!-Z\$'QXP6E&GY"C#"X)$2X&M[ at 4LWPPA!%E4_N@.:,&3UDM
MRN =/4N5!UE*ZG',LF[KJ,8F!!1'^!U\"SZ4<O]FCV!''JK&=< F.2,(%X73
MC KAAX1%.)/B"GX(&8%;LW at H%= R>"3\:C+U,@*HP1=9.BJW B:<L&2I !DI
M8.3@,RN13"VK FKVP(.C3W2*V2-X][?7/G/IAF\J:Z+6I4M ^,8HP(S\R F\
MPKV7W? 05B*\FRD.%X./38+:D'#TV<>C%_X+;U=QK+!9J1$7RB9<>4BO\H3#
MC.K at YW!!!AC\3B 5QB-)PXNIXL[N3$?3;I;!#N"N:%CA8Z%S> @+%LXR08=S
MP4L>8Q/+C!:\V)5ZC7TP9U)&&VVRCYZJS-G[1(&;,V4;#M+\YA3*ZKW[RX6N
MB"RG_JEORY.FY\I!K8('4 3A?)&?*5R#5W 3$'S PP09>2"*N$T<1X8(7YP8
M15,>-)^JUQJ\&F037\HH3GY4<?#[S)FL?2W,$JTL96A&]/ >G.4K\_4)AX?#
MPS 2.?'T"#0<9K/;B->.LG,\D])W]#Q"([HQ:JBM/'CBD.V2QU6<W5 37WFX
M?!#AX/!MB$/<*2)::1,(#ZA>HVVB^,I#7: XV8+3PQ5?C"^F.-JK+NX0/PU\
MA: 58 I !( B 7-H<LXQ'$1AJ]#,!. at *HY%'4N=#G9D0LO7=G,&9@,%L I0
MDPQ?(6GW3! @+![F&8L'-=4*#;4#REL\+>X61X>WQ0T$AA.X^%HE-AX"?WE<
M'C9D"@2A^-I*+RYUT0OTQ7,M?_&E>#"\6M,;#V$9QE>E10#+Z][+6U6 D:%<
MQDGAU\/-^*JT-=5E,'&-QM&BUM&A,P151V46AXWK!5[A8G"9F,OJ-9XZ%8>#
MPU.GMG"?^('@(E[UT at X QJD @G')2HMA/<Z#V81#QLM,K:.]1P'FNI+XP(S/
MT7QQ,)M_^.5G00,TXHY?P<OCK ?A&5ASC< 6%X0S*V7C=('5.'+$-JXN"(IS
M9Z [W&FN#I('L/0KH]OP2'C50 4'&4\0LX\RHK_QZ7C G+74(B<@^6L/)!+
MR$<V *C5.'F<T;5B??DXCW0>\ZA^6LI($K7B ==4LM57NBV-U6[\BKAN at HAC
M)(!4R/#K]HSJ1^/]% at %5:0*J$>U<ENS'?@'!F=UDHK! V>E:$$=\%LHA,NV4
MQ+6EA1QHYU04<2,KLGW9/TM1R@(@CP9T)XV2(I!3J+:9AJB!IG;["5$;G3XT
MMG'A"91Y5%2[NCVR2E=YJ65*/W+!4V0GH at 0E1X3:!")E(: L-&$F$R633H*Z
M3S6B=BQ at M@?'CTUE>I ^J%;DED_658X+ at LJ?WH%G@*SD3=,L^=4(4I[&DI1C
MIMI81"#GJ"UI$E*RB4 at SLUO8CRD]%0;<1\U.&D1-;(8\OR0ON6G3 at G,J S at Q
M?X#;2%30Z/A*452S!E;=R44C?YDF35:;A$6W8M6,>8!90_&SA]]C6)[-(F/Q
MR?%5N&[[3#?GH%GG# at \5RQ-=H%$NN&C;/2X<YUAU3JPD6H><-J;<[>8L1W)9
MJ<CE at ?'\>+D'B;)"RFGCQ]-5$8C>1E1):;K6F88717M12QV$=S.Z-&T-E\VT
MP##EI!ZG$GY\LVI,RD ?K5I-8T\)*/[9Q62FV?!D11^=+::=Z;9T at M5%R(!B
MNEA=S!]E]M''K9W)UO.XKBQ<D&Y%UW(!.97?=DT_LBQ&V.^!S[JF)*2XL7EK
M/"=4])JJ5E(3SR;)\8A+N^O?\-"+D9Q)^:VUZN8\07?FO)KD419KRH.QYG-I
M&&XXUJ$85Y H'U2,TG#S:OP\B*A,:J@,&A6B @_8CQZ=9^_1U2Y;FVFA*II?
M;Q at _EP&&TIG&[8:IRNZ<OCE5E2 E*$2UX(,92)J#1L\>G:#2S93T"BWJI(9G
M'=A,-&Y)Z^M&9YI]PJ7"H%S4<9L"]O-3;@J3S at 6Q1\< 4Z3D1VUIGYKB.EL'
M"I8^DBZ%:MK&B8I[I?<XE6K5B6T+D]H[FI3/7((#%U at _::5\#=(\%02E]G-K
MJ)8U^&_PE at \&A+5U>82+L#I>:"Q?;7#5;\HW&NH8L@>A!VAOD,<;VJT;[7>-
M0\6C'3(4U)M(EA4=6A2T,E7=#U4:%Z[&OL!F0 at B$S<U+%*<U%Y<*U14CW67%
MSI=4)Z-L.;7:YX460-6D0(P61"]^S='+0J;TXF/.FM[ at 9 REE]6#MT+SV3[0
MRFB!TR ]S1! *A7U8E+$,;$\<J:=*36KLYD\ U7O at .!4./ \ ']*SH3I!"5
MM5BH6_((:KNL?Z[[4$7SA-Q>K3AUS?TG4$;9.J!W=]Q>&32>T.Q2<]X5V\ZH
M "9 at VJ\'NN at \3OH+NQ'QOBCH,4SD5!C'[<7[+G^UB3CH#@'?39\G-Q9"#V -
M@:PZ736PV&&L?[[HLJ!_T.MA-PI*9N "@F9 ES,=T=]>+#->V5;LG3/_<8UY
MQ91 at 3ZT"&/=L %9%Y^^H YB5-().CLFCKE]N&(WL5!I4RRK>3UHR).OV9^?
M&"8T&12A!X &@ [D$:#OQ%!829] V02)3 Y"CZ+'I;;H[:82^ at KL()9"1V5Y
M<L9BWK,6NA"]=B6,R*#$SV7H3W3.5==T*<-$[Z [T7GH?O10&<&'EB1(_Z(C
MTM-FAO06%#J,?68T$J-[1'(IPYWFS/:A=CW=PO+D_.C:_'.K1Z&&A41']^,,
MP$%C?9LSS1]JJ=-$WZ%3R?SH*3 '&&I,-69(G^V@'0D^+_3Y.5!'SH2L<7LI
MT33H!71+NB^]C\Z?"J9';%0 PW05.GWTF-[?'*+/SQ6AS/3<F(-:@YXU8QU)
MTY,^O_1JNB9,F%Y%*Z:3=-".]DX6*N:"G(%,]Z9C9#Q++-2YF+<;FEY)K^-<
MTM/I(9YU^C4]F^Y.[_-Y'N/IWIMYNOP!8V-/=U#(T0_HS71]AX,::Z.-B:;[
MTZ?I^HX>NF3S2*2>P::WT[=7V_2#^MR)3W,#RUQ\>#X>\*I'^A_])[94ZJ1;
M!,QG%W5;NF345@ K3Z8?G(69,O2(^A? VVVI"I at WJ*GI 76.NKW#HTY,!ZD;
MTT7J>W1.DDF]*M8Y(9Z at C33I+77OF0Y(!7#N0:A[Q<X][;-N>NVJ?UX 82&5
MT?'H[R0]#1)S6P1+?Z-SU?%=E/ #NAT]/"831&^7TWOIZ/0^^B(=CMY#:6K^
MT]U>VX7^0!R7&GY /^H U7WH^)P&F(6SH<X74$,; ;8/50 7=YNFK.-&ESM%
MO;0F/.^T>@!=?XI75T),TF_HYO28^ at P]H^Y'9Z"CAHYX(*:U33C=VV36JMX$
MTTWHWB;/@E6]VK7A>_S8U FGO*Y\NML+9! LZ#M4D?JFW4H.G\*JJXK*P-8
MT;,WGO2:F4]HL%Z[<J9A3V9-TK22QRV\I at 0'SZ9MR'OAK)I>)A:H!O!]WGFV
MMPV80!K4U3 T^;1/03 at UO_G> CJODM%:]8U+PI+H4&SD(JS7-Y,*C@,3+0D%
M 9("6AJ(4.2;A&DPW=GT/7_<?)VE3VR(X3.ZRW at Q@(:B%"IDCD#D*!IGJJ-_
M:+A&*QULE?";&5$X&;!7R[]"ZO7P^9%J4^/(UNT$K*Q4_*_649L (I[\/'Y+
MU8W@/YKCC2D-9MX5LVSG0U at ?WG#)]F>=/G6<$74^J!;GU&OZ=[?"T47^,G<!
MLR+L=K.>D9S*D[W_)(>2!3(T>IMN#J<;NE&+"W4C;K1?/^_ %&_;Q'5L&!G@
MH58>)Y[FC/-[I+!!$:^["+[G.JKR.F'&^ VR<G$5J; Y*M,%NS1L/KZMC&HC
MOV7F;FBU#EFT'!W&.6T4V<,SX*%YC?$(,_0_A;-3:9JCVO/NYA?I<R-&2=[L
M$+8+%YO'ID.KMYV SFF-Q&%.GR3HYR'=3,0I^TD1P"2HWYF03M4T=(6Z)A7U
M1476GV_VJIXFC+XU;WSKJ0A@&H,->]]L+A#5?BMA2:&H"NV,RMJ4)7ZEUMQ\
M:'00%,WD671S*^U*/5Y%/WF:<HN<EFY*N$D^=A$QH:JFO1P%^]-J#+!LI(4:
ML&O03&@I.I1G(N "&/@<;P at %M&]?^$I=IKZMZ:+3TJ!"-H'5V;2]1T/ZPL30
MS]!&=8 OP"6=AHX5J%V-2?0T]*\.^F9.DD"<=K07MXUE7J5I.5WAEK-._ZI8
M9U0 ;B_/0NUJ.Y-NK^/P12.> W("6+7FWL[^FI;/':!$QZ\.NJ%CJY[I:7>
MTFI7 at J-'>N/H.Q.$T:$?5*DYG DX-8AG':5.V[-?IC at IT^_/)\N 9UDUTWWW
MUDM?GH.24)<KX+7M4G(#/M1:GZ2,U<7("5 %$,.%N^/I8J2"DX6GE]7C!JM;
M.K/G3^G[50<-R&/DP<\]:<;0V)IP9E>:>-VY,BBUB9X 4\V=J2[4Q-W$\HAF
MN-E(]2"#)ZGS1;+G/M/4-O-:"<TF* at LHJEJB"G![H3IY2J=D&*-ZZ;. at XG ;
MW24W].[Q^H*=2;&+4>9$M6GKI:L8&I-J58T$A=LPP-(_CR;*5NU;PS[$TO2D
M/,SL2?0BP9<]TQ/[B&,6A-X$P**9><IHO]X$LJ.*<C at =NNP9@H<*?>6KL3U5
M;F .K(D4S1J=$NH$ at D59RF-02^YR#]IH_%T.W311;5 at X3_;QB#1KRFYW0&6;
MGZ??U"RU BY)]FYRKZ$OWJL>",_U5CE[3:"G>9Q7IJ'@#*?;J0<'T>4V=6 at 1
MV>]7/ZEN1FV -7!D[YD:I]R=?&JKC?JYD1=$=Q^A?<K8 at J?*DU?A=G-0ZN/P
MRR0]EJ[ Z,@K%,Z!(H!_=EQ*&';,3>\[^8WZKG'=<(K7R*1-SE'RSB0WAS\E
M-:>>B(3_U9%3Z*'@H6[EA at A=PM*G=W3UR&7-+'W/W74?NQ/D>I?=]\ZD4F;E
M0L,X'?>0=;9I+L2!BFX.SUU1D.D"E8-TOUZ WC7Q?H;@>7$RR&#H.]YE;VDG
MLTI"KJ):UN1I704,WQ at QO70F+'C--K/\X7/)\KFG>E!"<X<$ <L3RTW'/(#[
MX.E7:72L.ZB4Q'/2&ME$3'%9NG0MF(9MX[GX=A_UMXGG(1[3U at $,$?I0N:4-
MWF_?J)6$3$[[PJW_UAF9O_C?2R LNUI! B+X4(&0VE7LDO0R?+@;XKX U_XL
M50 YW;2_5L5JHV/8JN.LV>_1<2E ^/<=BWV[26\QN@ T4W:&0/0[P?.%9X,_
M3AA=46TR?/5[C$(QBK9'UZ%<4=(CSK%\I#)'F1FUX)GE5"U63>>[LRII0A#Y
MMR<]8?*$E^F<]5%;@DIY%93P(.X($BR5NGKBCFVQ<WA:?]%B]3>HYXZAOG%Y
M-E? at AE#-3? []WY(V%;*GAT"9O;IF1Q^51TY<D&U(N)"N^R<T.<3,1V at 7AKY
M:9 XV<WIZJ7TQ&W0\8U6E$H$><V%47?'Y^V^F:X>HQ(4;JZFV7-+ 9V4>O#<
MWY.:W-5\#8*]RWG(WG*JBV"CAO9B3?)(VQY!?V:%1J-50+37%7/[5O;\/):/
M349(0ZP$.74;F75S#YH_X+<A%)2$O(I=$L^D"L5C00E<-2K>*)*GWW37<54U
M= !9FB+S4D,T3IID]V2IIOVF[,PK*$"*^Q4Y!WGBO9DUT4UNTWU=GX-T7[*_
M at !ZC<:%!>WPSZBFYA=$(OH4CXU DN^9(]%W%*0V-X_5"Y[2DSXC[E1[/IN+]
MUZ=2D1IRM8>KW^7N%,HSET:KGVXMSQ[G_@/O5FX7VLF:!6W<CS-^9;V^ 6Y+
MR2GQP7<)D$]HL]-^TFXMJ&I7-J*<ZJ&4G<7I;$'-3XX0<.V:#JO+N*TX=V5G
MD]R=H'))%;&:Q*UONB9\DV02\S3A3#T-F%*<7->@DQ(RZB0I.Q$^O&Y3P;W+
MSGEF2]+]B3%<A!6'_[T?$AQIMF_2MHKEP<YTI^D K/I.M^T%&-R&+.JY5NKL
MK1Y8=_*?=OG%=L[29I9+VH7OKQL%.[N*D14BZ9N-P&OSY^9T5>>; H0A\N-<
MO)7QS"4R_#OZUWGQ,/+ N0A[\)H'BE0H%X2"KEY!/;,*[!V_O)\''[_N%LE_
MKX([";->UZ9&TED1B"@L/E]7)C4RN79=;([S*F5^<NPYQ%5^S8S$L"[K'K-W
M"%/L)/ SN\Y(^3UC[:5 at C[Y"FIH%R7W^"?^<(<</$ 2BXZ+J_/&]7( 9\B"E
M29DVG(_D)HGHQOTHO7U^35=:=2I)S]64LOF5C^T<2KE!T.H0_(0TG32H)A"A
MW1F><:%YO$,^]RXC@<SCM%7L>/=(D->,_CYAK[BS>DA-NX=$IV-G6+K>22?5
MS^S/-=*<T"O^4QJ+WZ'/XNG3UJFP.\?=?D7&QGCB<.8VT>QXYS,("^1 >F:+
MTN4 G:\9#LC<1%_HT221224ZAJKD*-W4/&,NG9CW!<[9KW-^6<U<#06L 8+#
M;;[3NZ%MU*FJGU0WAT(1KG7N?<X1-+JT1,^:!\3'J92<P4W6NV!3FG2+'V1=
MVK-->2"_$HY>2\.OZ9#?<H[P3U#Q^VE+A]VD!P_LRI4W"&DT:"UH!VH)R at DY
MAAX%8T]"-A6'7Q/2SF:Z:@9-!?9^-+,F":#VVHA_KY at 1Y_:0MH?=+):NDI"Z
MZK4T)G;+S(N>,R]5]VGCYV3U*O;V6:U>ET.J/VJO=2A)-'<Q'.-G#WHN]9R6
MAN#8)JB_N?930D78 9ZRO>D_V29^C>)G#]6("@F\/'/H!7'ZU?=A^_!*!RA)
MW'?DI:&43>KH)\5JCX)W.:W6I:6BZ0 AN&E\IYROZ<_<]"36 &<3O*T*U=)L
M=T XQW1N*D1TUVYT4N7\1B,#K&M=D_E'PI7=W"C= at SH%<N_/C=>$Q'GW9K8[
M<,HEB'@L=VPE^BUW)\9CYI^G#O$BEF3 (O![+[^P5>?N !DH26N;!#Y19]QD
MOR7OK!H'-?S]8F107R*EJY9%/QNW!HH+:M3+V3D1WV'FPW0[.7;:!0Z5&LE;
MY7E"ZWE=4S2^<FJE A&5A'3G76Z\Z,YITW,GA7(+GE;N$*P<*$\'016OV6W+
MI@'A*^[+$7%I["-BEV1VOA$[\RD>^$#>X at DG&BX)!P(V<"9,@4>+\2/3=L K
M<-#PM)PH>]->;J.R$I]$R(+U.!K8E,J=J068U@ 1*#!<(227D-'<5WJU!E"Y
MAO;K!7N.UN9G>W3G1.8H?$HVKQZ 9S,),Z2=AV&MO5.D>57I^78KRAW_AF!Q
MZ-$'T.Q-3]]]2S/-NLPO/K;L)G<CEFD^+5:D/A4LG!Y-"1A/^8KG84%*79N3
MQ(/@WN]]S4);DNE^[Z7>H)PWLG*3>K.\T_VA- at 5EBQ1-2T^SQ;[< =^R?YO#
M.C\WI7K)O+>>,M^Q!V]AM^S5N_IY%4_]C..9MU\L?(CQ*?L"R&^>C#6^UPT
MK(S6[*3'#<;G .;0PF';3D78-/MC^MC[TNFVM]4PH=Q?C1\M& SB.H\ \AP-
M@;"C3E7X%#''H^6;(IXZK:U407NB^:JGFX-*.]H_VY\.6JRD^ZKG:#]M^F:$
MOS_4YYOO%5-U?R6M1W$E@&;:Q_9OUJ at 3Y>'^DI7'=WP)E1+F.FF^?;:_?YC7
M<\!1\5$FD-J+OSZO\;X?@,JB+:;$-K*^YLX$B+W#/6#F"G7KDEG(BO.Z at B9\
M3Y/9T"GEJ7-G7]YLZMITN_D*=H!SC_4^6T_J3'Z0F2SLX5$?GW%H6-VP/DMO
MGBCWN:#;$&(+<9\G<B^Q?H/Q IYV![ at ]W,6-R at D!I ;:GB=%3]+>))5B^:YO
M[P]'E?E&/&:^CY_35J+!OF$#+"FE=B,^ E+U:+F8W(5C%8*W>86;JL7U_FD#
M/IPDI7;)0)'J6U4:2:4C\E?0*??6?6C>1];)-[E[NSWS20][$2AJBK#AF5E+
MI2CU6'-7.0G^*I#&MP39:SY"*TVY_7 at P*VVFL4X-2R56 A[!4%4I:-6 DH%2
ML0 \">H ^*X':E2=DF;FO\V?^ZR8 YV4\;XZ6^1[89[BT"PREH,:B86WEU%Q
MO04BI;2GN(K]E%^1YXA2RJLX\:M,9K6'(O#KD8"@C6B7DYJ*YE)G3Y3"67$.
M=3I=>% [#;,._V9><B.<SER9ZBG>-*='E*-&,G*BWL$.VG:,M"!?)X.5.;R_
MK*(XN71N_I+\9"7*7QFQX1'Z#GT1EB$_^<T1W<HGMS- /OGVC/L(+*6.[]^O
M.B/W$FMI$<(^8NZK66SY3_D[>ZL%D6RC_YZZ47D?Y at ^>^E7+>'_5>#X)-R&A
M #0UA \"*QZ)52__#N$'-ZFDX*X-4-8A+K1I2M8S 4SK/OB&%-"=[:XB0Q&=
M>4I><?B-#[-[[QT20&7[O<WHMB=#UUB]E[44XC%-V04$B_ at DU0->ZO*9_QAM
MP;59>?7DW<X!8)5#E\S;ZBOZ*BMX^ -E#"\3G,3?*PGT%?-(IU)JT!W YLB#
MM>?DC)R"C3\;>O]I:N8_Q3PWT5'P)MQB.R7-YT]9;O#OJ*=*5TMG+%_4?X"2
MU;<[I$WN)GR=B7,'.H1TW9WD\&_#_DQSC;_4_Q#9K9U/$X$4=\]&4 at \'Z at FD
M\3N at -*P[E2(T080ECVMZNR0\BW9GU@/H%<)CZM:+!"!1>IK$^D>U5SVGR0U\
MC"\VPZK]YRJ_SE3M(>PS[U7E?IZ]3G>@(R#*! \5?X#5B.BV$ZA+ at W,'NHA
MB5)@I9JQK3_;T!5 !;!+=E+U/ZT4R,@C8Q\2>'['V]7Z'GNV/O?C#<^RMZS+
MX:5 % JYV&7>@U4:R,&+[)<W<GB8_5GZ#P\U0MUG;[Q-HO<A#;8+Q(,FSTSS
M2Z%<'6E7Z<W&U[/\_D\-/9=*8ZI3F13'*!_J&A%)[TU!VO5-M$.+;#YU:A-=
MXY6I41PR-C#[BJ7XT6"-MN'F>AM)S\"SA1WS:D6! at 7"@('P]U51 FI#\>=IO
M[0"<K6NWPB+U+!] ^4_A\7&;;2*._&D'Z[W&"50-0H7D%9R2$/6T-=0XI0JL
MC.P8RG7""$Z at ZM$\ O,33LG\67'IAW)=#.\\JL84/2SD0_'QE7(=D: U0:][
M#Z7:#^= at ^+<*.<+?UV9)Q6ON)W!(64Z%_8'FQXP'' #DTW'4?3>^__7D!VAG
M;FA=J2?;'96F+"X()_2'L.(J1^ at W/)B?21$_9XN+P2?V</%JS.7A+ at XDRXO+
M^6?A]F8[/QD+M=W3]L'L^9E>"7)M5FQ[MLUQ7L,CU!(O<X:L>*4$T;\]V![M
M;$I#AV[_CA6/Q$," MF at QBO]G?Y#.?R<R[[I?XD\PM7\Z7"=!"$E$M[NT*;A
MQ>/\\Z at C=FA%U3_9WFFGMM_A^Y1J/VE^L]W9MO6W4 @C_?$M.) )T1^D63T=
MNUU#882K0%+^XO%8*BT=^S-DA!&:$:;?V3\>OX+K3,;C8G"=B2T\$DXE^9'I
MQKU8_JLF2='C-[Z&Z?9/M;_]46R%?Y\_D at 5P%C@3G(??M_Y_?[J?5[#KEXY#
M!W(,Y!E%][!?J2F,-\'_K+GC at O!_O[X?'*[R#Z!84,HOS/!G.$V\$9X+;_,[
MX at W^IOYLOQN-X>\D<?CG^<']-_^H=B'.X6P$D-"8^X58J!.9/QM\*\Y]6&$6
MV0LX9:)=3YC'V2FYK-PX+*A#2Y\4]CY(;E.-II'!N4Y #)N)0(2;AD4==:$6
M:^[],'_\_+Y?*\H6[X)KP=/\C7"I2JC_D&!Q(?4?_*M9V?[2B(<\UW+G9_7K
M^8\R09A8/QE+_"=X*P)@ 0+];2VZ?[J\!_,5<C at #WC#^H?"W?U\ at UQ(=1SJN
M9T!>5'^/>3^".A1&O0XQN5(,K?"ERLK?$"[W=_D?9;:58W[T.MS#*&+M1RL%
M+#Q!%<UC.<6(A_**T<QOP>=5?G^84<"!];^^AUE-OJ;BVQZ:N6! 7Y[0UMJ4
M5+V?G:&ARA>ZNWE=4GG[UR],;-*++0#H5_[HIW/:0O<[U9N\-2C3'8W#] V]
M8IXT'59D#3_'OD7(S%OO;9+6)M5X1\[D]<,0>OVO=*3SLG\YRKO#=H[[]_;W
MM*O1)!A9. E\UK]Q?ONLJIF?W6]M;LT?*U"P'D\:\WY8(/H!-3[J(B ;FVD3
M4C4NDWM;'!L?>AOZ"*0<$R*I*<=R!'[)'/1_JW[V?T LHA.$&61P*G;D?AQG
M(VNW;>D!S"7Q?B-_2$_] 0J R'] +1!L(!NW+3IYFQO-)!0 at 91WK(V4=97KV
M4<8M?WA['>UH6QSZ>%I0O&B-'Z8 at XW^:&SQ/'VIB>L4:4AXZ at *P;WE34(DQ]
MG7IQ3;)H:"(0;(\>;'>?3I=IR0G_48$N5B1$(<=RPTH '?AY]7\/?_=_! at +#
M+)D0I'G\?[1M;Q]H(D-K$WWE;VI]&ROJ(*D3> ?X>=HLN7^T?_ .=H F=R.
M;Q]>;8 ;<"GW4;@M51Q6?DQ^1Q'4,-DB-GJ>?QD:YW8%> P>4"$=;4T>V#5@
M;2-_! K4'>$A;@2():@CWVQ3:3U5&("M%%X=)G=Y at .9U*09?'[U_SQD5?UQM
M;Q^V;<DE<FC\4[YM9BJ"*QE4PU(K=]XB0!V#&X8N?7I_*D$;2RW0;A8OIRRV
M+],DX'(Y%78,>RA,;5UO- at $4,CEMI(#>=3$!IX!1;6N '&<W>Z1]%5$!':"
M'2-9$\R '8 ?<+$3(1#C?D1M;Q]$<YMJGQ I52P;>AX**K)HX5,/&UB 0!X(
M'W8:YR(I(-8IQB/=*79\[&W%*68C0!VX=A4#R!^&+<-2$P-:+BM,[E"<'FX>
M""MI+$YZ_6BJ4A%.3U#.*WXM2Q0]529Z)&^Z;$H=+"RW(L]MW0\\50YQ>(#<
M at %!VUA/+ at %UV0W]) $5_K2,I(W1.?RKT(4,=65% '0-Y4U#V*;Y[GDR93R10
M%08V>?H=! O"4"@NJ2/D3O" 4'E7?]<F:B8X&BIS)WOK'79YC5*^'#1];"R&
M>9 FPW<#))52&R:73AXAU%4(@65W>GK)(ZU5J'OD(4)457R)+'EQ<%%##YA\
M77:D at !$0IQ-?@21PA'^T;8=_^7$' ID39(':+(Y_>R\W>]]L+G,0 at ?!N-AR,
M3TTD$FU,(S8 C')Y at ?8LWFQ6) 8=NASF;CL]O!IK+^,1Y S8'] B+E&@%:U5
MY'W34W<+<F\$(P-307HO+#J!/R<;'/(! at E&8+DMW#6R*+851$R/S<J)MJ740
M+]ERZ5$S>(A\]7V4>8QX>'TW?^,1.7C:+/,Q='VA?,8E\!Z"?% at 96 O+)R9W
M,7HK 3-Z6%&@46EY#W at $?IQJ&X!?(;"!%7E/>V-YG%#8(D]\5GON44Q\+VF\
M :,C)2\!(=@:@G=6*L6!HB\I(_5Z.$RV+_=WG2M@:=X;QVHL)7 +S"7H&;X$
M0U**>452*0\) F<825)%+_U*U30V<HUZQG at .=3D!/#(&&3D!-!]Z&V!]<QQH
M=*!W'VY#'L4/ 3< &LP:7VR\#P,?-S3-&?L>LRR]&PH$S!K3&=M*UAG%438<
M91W3!E---R0:+L8>]!B[+,T9ZADD',4/T"S2+ 2"CTM% +QN9GB2=PJ"42'-
M&>89%S? at -_D:]%7J F<E#H*#:*%\"H)B);4K*1M6,%45+7Q& !V"XWF"#X1O
M1@ B at N 035 F at C2"JU("&S,BS1DR at A""O':U6EDH%8(A?PF"P3 X 1X1[C4
M&NH9]%4! at G8T+"1"@D4 3RPF at OXE+H(D;8$1* 7-\ at E^1KS40 9,8*%,4)[
M-8(H #>"<QHY at JQ5+"0] at LH9IQ.J5%*"=$Y2 '!YP3#H#EX8GGQ8 at CZ"\B]<
M at DL=X!"B,T6"9R5H at KA1[P[^)4N"91T2 at O%2<QI- at %*"]1D? at IP:A((% at C8
M!X(G at M<9N%$I at F2"%S=N-V*"$()* at FR"5"UE'-\9*"-N at G""VQKJ&ELA'P][
M*'6"%0J7@@ :^1IZ at G1.?R=T!RUZL8)'@H0"00].&WF"/1KU&>$'9(*:&Z(=
M!WET at ALOQAZZ@C,2<4S;&0,:0V\H(Y$;SAS0?@(1/":I48N">B at =0M@CYAGT
M;GYHL(+)@O49"7^F$] at C6Q^"@@<3F((C at C< FX)7=L\,1X+5 at 2N"="L* at K,F
M:X(/@MH:*H+G&:F"4H(D'#:"@AJ;=JZ"Q1,5(QR"W!D:= PUTBRV at O89>X(F
M(-D:)!O"? H$ at 8*^@F(I!X-O at L*"?"_X at L:"Y1T( G%,"2O+ at G1O3G@ &L^"
M;P]&*M."RX+=&)Y\V()T''\/Z(( &MV"%&C:&-%V'(/C at D]+ !JM:'0<@@<K
M at Z6"(AHH(V4<1BH8 at O$;+X/)@B0<R'(2 at RPD"(.S';P;V"S"? .#]%4G%A*#
M$5,M at ^T0N!@P at \J" 8)B@>F"X! X .R"B8($ at U-.9R7Q@BV"1X(P at J6"]H+^
M)3R#JH+!,-P/9TOS4X&".%;2,. at 8+(,2&^H:I$KN5 .#]1G]<R,"TBSZ at 4=X
M91UC?1L>'X*$&89U0H)2 - QFQJ<@B0<GX)? at U*"68*2=S*"Q5!F at _N"%E84
M at SB"B#&32 at Q4 X,D',03OA1O@ B#WVBX at MD:=7^$&6N#1X(3$)6#AG4M at X%M
MJ$NB at Y6"WDN7!W%,@H,E at H6#1H+T5?""98+R@@2#:H)C at T)[CX/N at B@;T!^4
M$!%3=8(54*V#18.2 at W&"ZAKH&)00R8(O at O@YPX.%(2V#= >=&H!H=8,Z* at \R
M#G4,<NZ!F&^/$^QS_57D*VF VF?*<WTB=0%](AT)?R!>32L=91W7<=51>RNF
M<;U/6!G4&O\9%S44"FT7,4R:'OE)114C 98D]FH<$N,1 at R6(! =A!K2#\X/
ME at H^5EI,%C4M2T$F[0-$5APU4QI(5B$U+ %+5I,]=P!/5BHU458M-:]7559T
M %=6-C7S"%I61#4[-;4U7E8_-6%6,#5D5D8U9E8J 4H\:58Q 4\U;%93-6]6
M5C5R5EDU=%9H %PUJ!G% WA6Z!M[)7Q6934!!7]6HU&!5A2$ at U:R.H96<34Z
M ',U=376-7 at U(1^.5GPU6 (3-X U9C:55H4U" &85OU'FU:.-9Y6$38&%)0U
MFE>8-8-)-C>H5B\!JE;F7:,UI36>"VL L%:I*K)6!#GD->1=JU;E5M,*N60S
M!;U6P36_5G&$P5:A-0L_P%J] <96ZC7(5F)\X#G,5A$VSE;9-=%6W#6] =XU
MUE;. =A6AS>U5K=6DPL=/TLY'U?N->-6NS9PA%D#YU:R.ODUZ CK5BT"_36.
M.>]6G80V-EA7!C8W.PDV]E;Y!/A69C;*8?Q61#45-H(! %<9- at -7'#9% 1XV
M(#8? 0E7$3]M <$<#5<J-EQ7D38T!U=75%>--E-7!#8=5UI7 at C:BA(0VPX0&
M-B57138B5W(Z3S;.A"=73C8[-E!<+5=5-DT",5=!5]% at -5=F-C=78C8Z5X$_
M/5=K;H(1U35M-D-7C0%%5VU'_0=(5W8V8E=Z-DU7?39I*!8!UX3%A(8VS U6
M5S VI(0Y-B\!TH015Y,VLP:(.<IA]#9E5TQE>&*<-K V:E<N"7,ZK3;$-K V
MT6"+5W-7'2QZ5\ V?%<3A3T8OS;98!>%!H7[0(!7$#<[-LTV:U=K5XY at WF#F
M ]<VU6%0/AV%CE>I-I!7;SXA-QX_##:55_UE_&8 at 65V$G%=).F44F4F$6/X!
MHU?* J57- at 2G5V1>J5?"80M""0"M5RXU8E:P5TU;"C>S5^X+M5?E81(WDE:Z
M5W96O%<9-[Y7'#?!5^I"2#^J-WM8NSBE6,"$,3KO7C(WKEC1.!V%TU>P-M-7
M13?>5]E73#=LA298^6(U6% W63=OA3T_Y%=G-ZY"%U at S77@^Z5<Q8KI"QEKN
M5ZEAQ%HM8N<V!6:42?=7+6.4-58XKD3]5Y W %BF6,Q7\D%%!% at [?86?-PI8
M,5D-6.Q7 at UL06(.%$UBT-Q98GX5I70QDRUWK14L*7#<U/R!8\08B6(B$QC>F
MA=%=RC=51L]=*UC28BU8TC<L166% at #DS6.!$;X7<-]E$7EW_-]I8?DIP6$$X
M at EAW1)H$*V1J20D ]3=*6#D#^#=7"/LW3UB_A:8#^ at 926*HW5%A0/E98+PQ!
M0EI810@/.%U89T )0V= S]ZA4X:K L<.%PW6TD66U1';%AE.X,X!F;,9W!8
M.6"6-G18 67N/C4XGV!M6#HX?5B=27HO at 5B0A0)8/(4:0 at 5=*S^N-0Y=:%TU
M U X,012.#0$W#B16&1C63AD.=-&N(5S.&,X8(64-Y(YGE at -7_I +UBQ6EZ%
MIDD6ANXWY#JH6&P JE@/AE4+K5 at P6#8WE#7>.*- at LU@K(:9 at MUB-7VE"8D*7
M."A"O%B<. 1?N at S!6'P%PUA;0WI>7#_)6*HXRUAQ8,Y8S5B$A;0X+V*X.-18
MV40Q#<8X:0U.AG- at ]D ]6,LX'EDO0N!8(5G...-8USA/#>98[$*B8+)8[%CD
M.)8V\%CI./TXN3B4".\X\PSR.'X",0WU./Q88%EN1 -9_SC-8 at 99^ L(60$.
M#P,+60\YY0<.60(.$%E[AI5"$SG' A4Y(5=TAAM9[X55AB!9B88C6<6%)EF-
MAD8\*ED+6#,Y:TG*6C0'?85&-F$#N6,;.9Y&3CDS!MA at 0UFX!CQ9-4E^8YV&
MX051.3I91%FBANM 1UE<.7 "XEFA66,Y@(4E#6DY4UGS1O.%G8596;6&6UED
M76E98%E\.21?9%FD6H,YY41$.ZE::EG"AHPY[S770G!95CM=694Y1UK70FI:
M-#JH6:$YGUGR.=]9T3F 60TZK3DC.B(ZF%GH.75:U880.HY9PUFJ6=F&E%FA
M9]:&C%G,6=995CK\.M2&V#G6AK)9W3F"6B\!]7WY.=2&\X9T.H=:K5FL.=U9
M&#KRAL19]3G4!,)9MUG[.=59'SH .G@" SK!61)+WX;%6>PZ#CK)6=M9$CK_
MAOJ&.0+5&!DZ_X;8.1TZ[(8?.MA9WH84A]%9#X=+6K):95IM.6=:/EIQ6>4Z
M-#KQ65LZ\UGH.GU:[UE]"2Z'R35=!W):EEJ:6N&&=UI0.JHX^EEY6 at %:]SHV
MASDZ!5I]6OPZ"%IS"#"'"UI at .@U: CL/6FXZJCA/AP4[8#H56G<ZBEJM61I:
M_(8<6 at X[CEJ".BE:(5IV1B-:*%I=!Y):(EK&632'8X=V"S0 <UJ,.BY:F#I=
M!QL[;8<S6J ZF3J=6II:T(:A6JQ:HUHIAZ5:102G6K(ZN at 5$6JI:1UJM6C,[
M*3K00M4ZP#H.0XQ at 45K%.J!'E8966LL;7SM96HN'PSH&0[] at V#IA6E%#-5ED
M6J1:X3K(AF*%+(?X.FQ:[EF6!7%:.CILA_=9BEGY6?U9J4- at .@!:HX="AP9:
M8SJ":8!:#%KUADQ#;3I3AW9&58>)6AM::AH=6A([8(>:6F*'F5H0AR=::X<Y
MAQ8ZF%H<.YQ:(#NE.H2'>X>W6OXU*#O&AJA:=6E%6BX[GUI(6AX.KEI at 0-%:
M.CNT6 at HHMEI-6\- N5HV.;M::%E:.\]:>X3"6BB'C0%-.YJ%2CS(6N>'5#LK
MAZPVS5J^6M!:DH=> UU8TUK773\YUUII.SL_XUKN!MIEQ [>0!]#[V4#B&A8
M-S_R6NIE'T,56VE8UF5].^Q:@SON6A*(% N(.[<[\UKJ7O5:^EJN8=8'^5K]
M!OM:R@']6I at [IT1>-P);GCM0!Z$[7 ;&0 A;06(*6T<Y#5N?!>Q:KCN\ @&(
M$UNT.Q2(\5J*._I>'%MW&#\Y(5U>/L [6C[="<,[/UM?7'Y<*%LP6SA;85Q*
MB'(].5MJ/:1<58A+B#Y;5HA2B%"(0%M/B$R(-EM#6P8]1EL#/,-<"#Q+6QDI
M61^:0^5<#SQP 5);/SU56_$]2%O7/5M;/2(&*HL"05Q<6QQ&5SUB6R8\95M6
M 6=;NP&H/&M;M at ?B/6];CSPX G);.3QU6SP\^ YX6P,]Y0-[6VHX0SQ^6Y\)
M at 5LB!U<]U2(#/89;GPFM&XE; LD/^@(C5M8/&$!6CS0>9-;# 2-.L8#8SR$
M!F4\FUO%!)U;5P=L/&X\<#RD6W,\IULO '<\JEM[/.,$ at S>N6P]!L%N#/#@"
MM%OC6[Q;N%O*'8\\NUO9'6%;[%O!6Y8YJBP84@,]ISW(6Z,\.3VE/&HXISQS
M M!;JSPX M-;L#Q$7[\(LSP$/+4\H at 2W/!(/N3PW1>!;O3S#B, \=HC"/.A;
MMEOJ6XA<OUOM6P,]83T(/M(\0CWT6_9<#EPE:U)<W#SL7/M;5%SE/-A<D H
M7-&(*%P&7.<\"PWY/.Y;"ER\ _T\^H@ /1!<IST'/3)<]#P+/0F)#CT87*<]
MF#P5B1L)'UP)B2%<^CP>/>L\)5RA!",]!%P;"5$)5%PK7.Y;+5P?/2]<Y%PQ
M7!U<%@(U/35<N%QLB#A<TC5 /5X(/%QN;C$"J#% 7$ at ]_4M,/>D,F %//;8$
M25R6!50]3%Q7/4Y<6CTG/-1<"#YA/59<;EQ9B$V(J0E=7%&(5XE>B$Z(8UQV
M/9B(O#=Z/9 !< )]/6M<@3V&B&]<1 at =Q7(@]8HAQ7(T]# )Y7 L,/5M\7 4)
M7(B 7#,A at ERQ7(%<H#U7/:(]BUP\6Z8]Y%R/7- at #D5S_B)-<L#U"!+(]V at JT
M/;]<FESLB(V)WSV]/8V)H5SPB%D#I%S&/0.)IUP'7&HXJEQ>/*Q<T3VR7+([
M>HG3/;([M%RJ/*A$.3TWB;I<4EMN6[U<5#VZ/>@]E at 9(6\1<LHE26\=<=3GS
M/>E<]CW,7+J)%SW.7"^)T%P#B=)<Y%P!/E)<!#Z]B?0\UUQ47$D VEPN7-Q<
MR(D;"=Y<$EQ) N!<+EP5/M")?CP9/N9<LT_H7"B)/3SL7"$^.3XD/O%<Y5SS
M7#J)]5P-7&E;+C[Z7#$^/$T@/38^_ ,!73H^&SD]/@9=/F((70D #0D+7<DZ
M#5U48$L^%PE./B4)4#[AA?M$'D-N1'57'EU1"2!='ULC74>(&&7_6#1#)UTM
M BE=QV##79B&<#XO77DW,5W#/J-ATE?>5[!= at #YP2J<^A#YKA:Y"@%V$/F-?
M1EWJAY(^25V5/GDW3%UY74]=4UU17=,\4%V87?8,5EVE/B**.(H\.EI=WP;@
M5U1885U3!GQ70@/% V9=ID)'BH1=;5TT1WA=3EUR77U==%V-"79=;EW!/DZ*
MO6/(/C5=O . 71F*-E^#7>4^\ 46!(==H6/]!7,!BUVA#HU=303I/J4"D5W*
M 9-=[SZ57;!=]#Z978Z'! 1G0/H^H%U875):HUV9/J5='#>")-5=J5W;8_E&
M^0%XBGB*L%T4/[P"QEXH/RX_OUW>/+A=*ET at 7XM;O%VT755"C8I% <%=IS86
MBBU=P#7'7>9(#HCY1 at 2(SEUSA>!7KX5$/Z==LS_46EV%RE[:75H_;#_=75U
MJ4+A760WXUUB/^5=9#]Q1.A=8%YM/X1>NXJ.7J V<S\M8_1=$6/V744!>S_Y
M74 !?S_\768V_ETJ)84_)$ #7HP_6S]'1H,[D3^4/YT_<0&H/[H_#EX:7A!>
MV(H27JPU%%ZE/RU>V8I=!6([O3^N/RY>L3\?7L4_(E[IBKH_)5XK7B=>[HK"
M/RI>O3^,+LX_Y(HP7FP(*U[-/S1>>1PV7M0_"V +7HQET3A98D5>'V2=0$A>
MACBS7OD_4&2P7@>+^S^[7JUBF4#$9+9>PV1\0 R+%(N09)LV%XM87JI 6EXN
M9,UCX@,A0*H$NHIB7HI>9%XEBV9>)XMH7G$!6D"-7O!=;EZ77G%>@S=S7I5>
MO0R77IE>>5Z<7GM>24!^7LY>NT)E0!M O(I40!0VB%Y-!&->:5XOB^$'CE[4
M!Y!>K#8TBR4-IT!U7IA>:3]!0/!=/X:A-7! :5ZE7=A==T"YB@:+?$"J7NH_
M?T 9BQN+MUZK7ED B$!,/P:+4%X6BW9EE$"Z7FR+O6(:BZ]>"8LA2)] 6V*B
M0+-=-XO% \A>+$GM2*\UJT!0/LU>2#JC M!>74+37N->U5XC \= C8N[0.I>
MW5Z)B\1 ^E[G7CP(CXO97O!>. at OK7HF+(D.:BQP+_V+T7F"*O +W7MM F8O=
M0-Y:'T/]7A(Y+6 "7R,.!%]50P9?VT$[AO! 75^1B*E8#E_E1!!?_#@:AJ!8
M_$!5"8H&%U_3A7TO&E_]!1Q?:B@>7[I=(E]F1'Y>54,F7SU at ] <I7Q1!363K
M0"Y?96"<#L)!,U\A03=?/5DY7ST+54,\7RQ!(T$]64!?J%]#7S=!Y41&7_XT
M2%^,7TI?36" 7^X^_T%&05%?+ 1=0E1?##]50U=?65]!7UQ?:6!?7W at ^85]>
M0?^+0%W?1;I"8D%G7\]"H$%O08-?I#=M7Q98!&,\.G%?I4%S7YE?=E]\0:XU
M?D'-7^M ?%\J181!AE],7X)?:E\,C*HWAU^./A",A%\GC*8V/T&T0:5?; :K
M5Y1?=5^A7[-!ID&;7Z5?F%\3C)!!+(RB09U?CU\YC+9!-HP\C/R+J5^^054Y
MP$'\-\5BQ$%V6/U!LU]:7[5?MHO)7\Y!\E?008 at WTD'-8[]?UT'!7S^%PU^F
M5T>,'T/'7TQ P%]V LQ?YT$/8!E"TE][7R]"UE\#6/-!I43 "V0[54/=7P-@
M\8LK8 !"3$(W0HUD'T/G7^!?ES><%.M?.0D58%5#4 78#Y at \E\:8/1??HP0
M0A] at Y%_4BPY!^U\08"I"1$(!8(.,!&"K5_-?D(R+C'B,6&)EC/U?3D(/0E4+
M'F )!6>,3F23C'.,*$+S7YV,0$+^7Q5 at \F(]62-@<&+N/B9 at \(M>0MV%"CB7
M0C6&3E^T-BU at 6V O8"U>,6!N0C1 at 6E\V8$D$<T*J8OE?54,\8*^,-CM 8'))
M0F &!D5 at 5V!38,Z,2F!28-8'2U^RC$] at 56!Y8XU"THQ68,IBKC4%6<$UNXRV
MC+V,7V" #,","X at O7]B+Q8RM8.! BSXIBFQ at =F"I0G! at 8U]1AC<W/&6W0D>&
MX$+2!.)"9EF 8'Y at *"/^C$U:R$(^6+!@ D.(8(B'QD**A[M at 6UJ-A_@*E6#_
MC$Y:DF!H8XPWEF#[C'M at +0)*1:XUYD(E6>18PU>@8.A8[D+J6"Z&\T+N6$A@
M#PPFC=R%9#T$.55#KV#+0@:-4&._#;5 at VD*W8%4Y44.+8):'75J8A^ DFH?"
M8!6-% <7C1DV8U['8"%#7D2L-LQ at R6,G0RD"$8768<J%A 348%>%UF "!T4Y
MN38T0T>--T.Q6HA7)X4[0QV&RE[B8$5&Y&!!1.9 at 00'H8)<WZF#&BP,%[6#>
M"?!@<CKR8%-#,C=50_9 at 64/_8/Y at 74,!87.-=XUC0P%A#$2$0R%A&V%H80IA
M(6$-8=-#>T,A81-A8%T582!$(V$98;%#(V&*0WIACD,C80]A;4,18?,Z)F%0
MBYA#EV$A8:]#-V&R0RUAHD,O80YAJ$,S86!=-6'S.C=AHP$68;5#A0&W0SYA
MDXUM0[Y#:01#8<)#*S=88<9#V$-)8<Q#2V&L-DUA*S<B(]!#4&'00U)AT$-4
M811AVT.UC::-7F%<85"+XT-Z8>9#O0'H0W5A:V$$1/!#9V$(1+V-:V%N8?E#
M:V'\0Q1A9V$ 1#9A=6'3C1QAWHW6C41A\4,,1"5$@&$51(-A[4.68=>-&42(
M8>U#BF'[0XQA#T2)C25$D6%W825$[(UZ82E$F&$^0)IA,SRI0C%$6C\S1.%$
M.PBC8:E"IF$R8JAAW4601*MA0$0^0R&(TF*P84$!LF&,-[1A642O-;=A&HZO
M1$$!5EU&1;]A'8Y41,!A5T)71,-A0P-;1"-?&H[*8+8W8$1W-A$V9$1F1+"%
M'T#K1J]&!6318<1$ 5DIA;B*K4A:.=$XVV'R8=UA\V/?89-BX6']8>EA^F'F
M89I$2(Z%1$\YZV%+CAJ,#D'O84".\6%$C at EB^U?V84>.&&/D8;Q$_$?_81YB
M[6%50Z1$QHL%8JA$\&&J1%>.0XX4CKEAL$3( K)$H66I94%D^T828JHW%&*\
M1!=B[& 98C8):XVZ8\9$#$7(1 8X at T<S!OQ')F+77IME$&(0."QBJ4))AELW
M?H5X/C-BW$2"931$I&$X1N1$149<9 ==UF% 8F%9ZT/P1&\&\T38!<Q#]D2C
MBV)936*\8A.+46)_1;EBPV+J/\IE#D$&B\%EZT2LCLAEKXX;.0:+8V+ 8K2.
M9V*N7V9B*44#A:!%F#Z21[2,4 P.92=DS&199'IB6V0R9#]%L4>!8EA$=U=E
M9#5EB&+3-HIBV&*B9!N.CF)Q9%M%7(Z28MN.^&%)CJ9D846I9#=D?&0Z9)=E
M<$4774AD,$F,9"Q?6&)TBZ]BEC:Q8KYE*R&U8GY =V6Y98%%K8[UCJB.86)0
M )-%NH[ZCLAEO8ZZ8NH_R&**7\IB4V1Q8I1D5UC+9)=D*60392QD CG7CHQB
MV8[;8IF.WF)X9.R$T63B8G!'YXY_9$ $Z&(.8BEBI&+$5^R.*(NLC*)> F,&
M2JE"^D5U-Q1CXT7E11!&*X_J109CB&4KCQ",-H\SCQMC%F,-8ZH!I $/8]](
M,6,38PEC%6,#8Q=C(&,:8T6/'&-S!-\U/X](CP9&2H\D"U(W(V,51M-C+&,U
M8QM&*V,91D./(4;,8UB/)D8;1IAC8(\28U=!-V.!A:Y"O48P1CQC,T:71C]C
MI6,*CF-C=3=%8UY!>$9(8]98/D2\95!C>(3O&E-C: 7!"K:&3#]JCU)&/&/+
M-UMC>&+P8UU&Q$9G5YM&9$8"9&=C=4::6FIC;T8G1\1&;F/3C'%CQ#ES8P)$
M>T:6CW=C;V-_1IF/H39[8SI&?6.'1GA&@6.,1H-CL at V%8Z$UAV.N8:]&E48T
M1K5&FD9C8Y!C[0J?1K]CAUJP1ILVQ6.D8Z9CFV.J1IUCK$;&8[N/P$;,8[2/
MIV.<1L*/JF.#C\:/TT:C1JYCM4:P8ZX!XV,'1\Y&NX^W8[5COT::AM5&PF/*
M8[YCC&/'8\]C/4?18_%&)D>VAMU&Y(\/9,1CS&/CCPYD\$8F8^F/]4;68WF$
M#63:8S4$K8^_?>@&X&,"1S4$UH]Z5N9C=QCA-[MEQ66M1V9)$D=-&N]C_05<
M1E@)<(\;1_5CI6/W8V5&GH\O ?IC!&2N-FQC+T>G+P!D=6-F8S6(.(YG90=D
M31HV1U!#'6*CA1MD##_PC[UC$60UCAA&0T?K CY )@,89$I'-PJL7;9E8HL@
M9%)DZX4+CPUE#8]]9;2%?V6"CY..XUB\93!DRXZ>1XMEO44B9:IDUT(X9*]D
M?F3G9,I%(H_X9"))S4=7D!>*:DB[-:5BB633CM='*8_"9 J+4@ "1=2(4T>J
M-\..*HUP2#^0#V7(CHI?6F1G1TF0S8ZB1S4Z8F31CIIDUT)&D!:/;63<CKE'
M3I!&CGR0CDB68D^.O4<:CP)(>F3"1^:.$DE2D.F.6)""9$9D:TC212>/&DCK
MC$))>(NU7 at EEWT<+9?MD/I I2&R0#X_#2(%ESV34C at 1(.UZ%9=-DV&2(9:)D
M&V7? AUE38YT9.IAI&6Z2.2.DV4%2"9E'X^+D+)D"4012'%%CY!;D#-E+TF3
MCK)EQV2T9; _MF5NBR1(F9#?7Y-DG)!^2)Z0?F5*9=ID1) 2CZ:0W&0)2<%(
MAF6 99EDV) $B^,ULY"'D)AEY&2WD'1'Z&0526%(IV6B97..7DB89?!DYY!R
MCK$+^F3ED*9EZ6+M9/"0R63\9)"0,P6G2,&0,4DX9<!D=&5.9'"+:HO(D'I(
MFI#T2 R/G9#'CI^0367:D**0%&6,8M20CV6HD$)(HV0<9>".S >"D&!%L9 X
M2-Z0T62499I(Y6*XD$](GT at N908,K&4ECZ]EP)"BD,*0>67$D(,[K4B-CDD"
M/F5$94!E/D1#97LW167J1T=EH)"99-"0XS4'A=F0YT5/9=R0 F9!*E-E= at 25
M-D,#S$A<9=5(667)8]-(VTA>9=A(867;2*(1R6,&9%$%VDAJ97$-;67F2*8*
M<&5P!W)E0DC&D'F+<8MX91Q(!9'VD,R0SV()D<^02&4,D1&/:&329-60D&77
MD*>0#XJ^2-N0&65#2))EWY E99E(4)#F9..0ZY#FD/.0\V1"2)YE64CMD$!D
MIV1/1?*0(X_S9":1+4FF2+!E?TDW9;-E.64%91UD9(OXCL)ENF7I8P:0&0-4
M8D1>E9";D41)7&+K!\1E:F2AD<=EO(X,1<QE$T!125="4TE92=)EN#CG9<,)
M%(CU95I)VUIR-F%)/2]C2=YE[66:-M%EXF6F-N1E>$FZD=H.Y5H0B#U9[&4J
M07DXZ(QY228U]&6TD4MD#6#M2/IE4S>65_QF_V5Z2A4*6T8$9GXW!F:527<#
M"68#D/5)^X4-9L$1G!286*1)3V849G1FMDEQ9K!).0$;9K!)'69D9O9)NDDB
M9A]F)&;YD;!))V8?9BEF>F8V2BUF=V8R2M5)ZTDR9ME)-&;<25 0.&8Z9J)F
M/68]9C]F[4E"9D]*%Y).!SIF1V;Y24IF_$D1$/0% at V:P25!F"$H'2E5F"DHZ
M9 at U*6F:%$BN2(I*T215*%$H72OR1 4IC9N))9F9T9FEF\Y$G2JA);68G2F]F
M%5 K2M\"+DKM20>2U$DJ9 at 6284I^9@^2@&8,DH)F84J%9H=F2$IA2HIF&))$
M9HUF4DIT9I!F6$I:2I1FE&:69IAF:V::9IQFE&:>9F"2]DEN2G5*I&:F G1*
MIV9X2L1)WI%\2E.&YC=23"08,6>Y9H]*!$Q@"OLMKQOB$[$5%0K<#UX4 at B65
M2=4 at #G4>@783.0&A2MEFMV8@ ,)+RV9VDA(;[AO2,ZU2OG7S3AE,2TRB$2R(
MTA052XY+\ at =S .)V8 JN,7P%7P"9?Y:2XRL33-4@ P+ at *O4WEDOV#IV2GY)1
M :&28P"CDJQ+R0FEDFH0GF>IDN\R$CJLD at $'GVR #]P6(T>P2LPB30)0 %H:
M0BRN26</7A1"9R@ +0!%">X;%4]T <X_)1AC$KN2^DM2*7Y[&Q0E&,\40F=T
M&41+(53 9EP4=P%85&$5^#G?DB]6X9*A9^&264L^$"48.ACHDIT/3T+E2RT,
M&#)##Q44Q4JC2MYZ; +)#\!F%#*O4VYQ$DNK'_R2+"O[DNJ2[DH)<A0RW \N
M! at B3!)/QDK]*! at +YD@YUVV8;&/V2$AC;$$MG,Q("DQ&3<4OKDOV22QGE;6J!
M04M_2_B2:4L at %1F3E$K_DOE*)9,O5A0RA!E>% 63[TKE;3H?= &5 at RZ3#9-(
M BT,5Q.S%"48*R3"DJZ226F^=<D:LY*12U at J,TR7DON2Z!C42=62G)*1DC^3
ML9)"DS9/1),C D:32TM!#T-+W))S!TY+9P_ at DG 8&Q at C E5+6I/GDE\E]7T
M2P:3!Q3%$_%S[)*7<6.3<P;E2]V20 at _T!1*39W%C#$88Y)**$W\06Y,X%7&3
M2$MFDP<:<I-PDR&38$NQ2AX#XV;D A5MQI*Y%+IZ816"DMH814P &2,"\"JE
M([!*CI+C9JZ2ZTZ6)Y22+!RVDA-,XI(@9R]GD)*>DG%X3I.DDD63II*.9S%,
M%Q%*DZV2D9*ADT&3HY-2DZ638BG22G8'RY(U3ZU+0@'^ at 5EWV!KY57<'9 at _2
M#ZF3UR,= P\4:A E&"0;PI(,'#$UAY,K).4>GP&.2\V2EQW0DA$0;F<E&/X8
MGDO7DHB3'0.8&)5)>'/>DNF2TY)4&<J3KQ 22^:2WI-C&O"2& 9EDV</5!D/
M%.F3Y9. D^5+G _?2IP4(P$Y ?ELF$IA2]821$MD#&N3[),@%=J2 at EDI#_J3
M<4O4- &4+Y.L!^R3D1&M%?J2:Y,BD[92;TOT at 0*4BTE_#XQ\%Y-V2]0T!P)V
M2VU+%I0 &?R3?DN!D]N3YTID#!"4Y$HI#Q.4^4HAE.&2U#0_$!N3Z),IE- at L
M[),JE#5+OTKPDWV3\Y-L&%H'/9.1DN95D9*9?U\ %@&<"4(;I).WDF(IB0]8
M&:F3'Y2A$W>3*)2D$U09X9,\2TF4Y)-_DP64ME*A$P8:[)-1E#:3GC-(=-PL
MFI..9S$Q%V?M9GXT>'1<E L8Q P73%F4HY)]?4&4$TQ%#T,5# % at E*HT9@MC
ME",!7A1 at -&V49I04'!$1D"4M2VT/4A5G#SM+RDO?!WN4&Q1\2Q1+[6:O=,)G
M10_1DW>4C74.&H*4?91C$W>4<S'G+6J4'6=A%>H"EVV1E&XOG7F4E,1*;0\0
M$4%X9I06%W@"$2849V^3T6TJ$(H3%V?.:P),J92CE,=G2QE[DRAOJ)3]+JZ4
M<@%+&7]+)0&;2L(1RI)L A87=P=VD\<'$1C4DM<Q<3$".J$3PY2]E%09 4LY
M <$#K >RE,*4O)1Z @-FOTN_2I\!P0./2VD?M@)2=FP \1DX%0"4BV> !(=U
M#3#>E-*4,DPC N 0PB^PDQTG2V<>#ZF3-Q_GE,H02TR(! ("WQ9EE,N2&4Q8
M at _*42F?UE(@$=Y3XE(.#^I3!$UX4[6;_E+QNZI35&@IQ at Y)R!]Z2M"T9DZ\0
M:G$[2R24#94KDV8/$Y5DDS"3+)-.&*1*%I5LDWH8NI1XE)QK1Q6#E+=+=Y2!
ME&)G?91:DX:4SFYA9P(Z?Q,IE=:2;W0BE8^4"DRY2A:3US&B 9:49 _5&K=Q
ME6<2.NL.-P'&E#V5-Y5#+"]+S)0"2[AO0RR/9SZ5X"HN%0I+B4J_2L4%+%[6
M$@),F1-^DM]*Z0[!9P<U+97D2A1+K!,C 2(!.E9>DP$E>Y,M$$R5IDHB ;M*
M816E(PR4 A%M#S%+!$L(E<5G-A5ME4N56!DA :L4=)5OE<J499.I?+9*?1-8
MDWJ5'96J2HJ20Q49&71O= < !W1OEP> 9TJ5%5!*E1PD A%>%/I5;QB:%.>3
M1Y4V5G^5DI6*E0Z4#)11E08:$3 B 565 =D#YT[WDL]2PT!1!7T!;R3"'VA
ME?=YW$B6E4E+")6T<T64R4_S>2L%#)1G#W$85!D<E==FEA at NE864$I6>.=.2
MA!J\E0%+UI3O2KV56!E4&6L/$A#"E1V5N90.DTIGX9*$ A)+Y6W1#_9J=DN^
MDTX8TI4E&*4C+TN6"LV4TC#_#Q5+T0]\E,N5 (0E&..5LR5UDV%GM937E;"5
M77AQ2]Z5ZI6K2FN5"DL.2[]*_Q.Q9C=G-Y2V9L!+C)*Y9D@"RV<_6%-,"X16
M3%A,U&<%A$!6_BZ:'OB!84S;9R8N! )](C5/U at 19*'P?X7J7*"%O4R554]],
M6B3!-&@?&!PT:!UH28$5=U]X^!'Q<[8T1G*;</,JNH%Z=RTA)!K"?^U\'X-/
M'>%]OAH-*1!/DU),?9<NO4X_*=-XV29Q!P!,01##,[ L<A\K(R1]1!4Z?64I
MR8/)+OTC07V)'056>22<)*4:RWI0*9<!W'D>>K-.>2W,&FUY1"<B?. C%W at 5
M? at 9].QLD)L8;F1X$5J$NFQQ5EE-4QB"24MAQ>RL1=/893FCF534>*0 Y) D!
M.%()5HE,*U%7*5=]8VYS>_E\JS!!(J9W"R)7EDZ!X0*$3U*6T%6))B93ORMQ
M>RE/*9;F;7H? FEI,H(H]AR%* 9IO4Y3!YXM-TXZ;_J5&X+>:M at F<AO :!Y5
MJAW"4R9Z_B?A3NQJ_7=L45@>.FY73K9H3"!:(L5SPH'6&E,$WSK354]04".!
M>9(?S0%?4$L? at 7.B("1H9FE/(+X:6D_U)1 IPY+1@>Y.*$W;)292I'%_4W"6
MT"OE at U146',B:LF6SB+C<]9JA $M!CD3J7[I<Y!YW6I^*J^6Q1HY:2B ?5)3
M<^X9O4P1&WH?MW4H(YL=)!R<*:P:11OG/>B R" 4+6-_?AWN'[4EKQL><><:
MS1F;'?15:"SN)Q0MH2K 4;(J_GIX>U4JFQWS4?&6(2#<3<^6^RB-)E\DCR8B
M=NPF%'QS&G"6\R&(=F-_ 1Z+)4D<N9.\<^89B _>'DX=!%!M'6<!NQZ(+<=-
M\1^(>_E/]&CV"M4;20^/(G%RY6PO:N13F(#K>I(F#%4:41QIUY:7(5,E>7,]
M&NPIX"4X" $%.09+ 8L!_"E;5(%,8U#!EL]1EB""3J(<,Y<9(-T<FQTZ@,$=
M/&^B5)=T=%$%3P(@G%"U:8ER7U3[;)XGIBSS&C(J"Y>X40V72C%G"_\GEW&&
M'_8.!8)? at D,;H@&9 at DD; Q_('8&!TTQ';@Y2C6A+5'@G-5'3)*<G] at XG(?)Y
M69>A37L?4R$!?6!_(!IZ(1*7P1HU)/IKQRTS+II/.5.Q3<IF[" &>/V =7)W
M+>\G_&U&+A)T&R) '%E at 3Y>9<W!O9XA,'.IS&'S\>RI-GY?/'5P<KRW!31AI
MK9>T*MHKFDUZ)2%-80<+'[ at J=E/N;G,:)B)X(5E2!I?55254QQJMDK-CI!PR
M*L]IG ZX3>IS 0>U'_)-<6T\>^ E, HX.\XD050M;Y2!Q$N)*H(GO)<&=!HH
MTQHV,8%5)3+C3V-J_2B939-.S7.Q*L.7RWUUEKU-]H!)*#A3RBHM+:@NC7K.
ME]\;T'EB=XD;WB-A+C^482C$4\8MD(*Y(!D;XH'+!A4N at AR93Z1Z.#("4_B7
MP7N'*K)HQRAP.E%K64ZJ;E at !N1Q +J!OS7J=;C]-#5(Z&P!3]I<+/_A/.FC\
M<KEXGDS=EV8K?B40EEDH_"5D'GU2."$O++%]02G:>@J8/G9%"-27)G/I4S@:
MQVL=EI<A2($,*M%.)B*%>8@"66D9&]T<3!N*'\D;QP8U+7B7;FW)=Q4EI6PI
MF-L9*YCO4<*7'R(*('B!&9>C(6R78%+Q,4T at ^1KJEB@ %$L#'XL33RYH(% at B
ML1XW'.(T8"9T5))HC"V->*]K? &U+$=R7784><YV"1DW = at C3RK#?W,(.FZ=
M>K!L"RK:3<)H%R.=DA9]01AWF"9WM$XU;385AIB9?& <EFT)&(N8<YBTDG)X
MM7IMEVL0?G93'-PHSH&-B MX<B<_(N=NDVQ at 5/4EW9<;&&9PKW.-;QJ8E30@
M:U(-KB&63%EXU55_(-=5;RH1*)N67TT;<JASV"<'4/0KLU,S*;A7 at X!?&Q$=
M?W?J' Y3Y1=';8EK%%. at *-@F("H9(#-V5$WY:#-8)RKS'_%1! @4+2 ;&2N?
M;<F7!X&Q4%0<'G'F4S,2K4^W*6U2]AN 4'TM.)CN?49]70:=<N%Z+B'.F!<;
MW9AD#.=]L0%7*3LL<!T_&Q)24YCJEY$N at AP *2]O;5*;(>93N10+']X?>"4F
M*LDDS6RNF(L;K)C/DS-8XF_QF.)1\B67')E3DB<+'S"8;D^,+44N!25Z5EY3
MF4ZN&FL;6$WS?,X>*APH+,Y3[ Y"4,LJN)-+>*,?FU30>59&ZI=*3.=.&4TJ
M<%28"E1T&;J7;E4()30NV9A<<K.7XD[T?!X;C7AC$BT&/Q C</,J=)C[>:51
M.B/<33\:YE-?'P&9 at VZH-/PK>AN5 at 9)+W4X!@>!."2Q*&S.9(!5">%!0EB*&
M: \J"TVF&UPE:TX;'JP;"ID! at $(@TE0P;T4(?U2#(V at CXI@;'S at R@"C/((DE
MD'Z^(@H*'0$=)H)3%R9<+0ANO&QRB#.9% K)&\IY.$R&+O:89E#"<V=IVR#]
M+:.((""X(-UY"29W+,%4\3&$>'H><BA6>D!S87=K&^R8JRPK'BI5=1S>)EM2
M at E"Z'=94H1NY*A!6$"P @ R9K"A74)N9.E2O@ P;Q5$!'EE[N5-PF-8:67GD
M&]PD^BTF&RPM22=_4H,>D"7^&V:9B!WR?-]J/'#W3B$@>':Z' -5 at 52)=DMW
M()A%'PM[<E-Y4H.9UT]:@=*6V5 *5$46R1OF at YH;= at ^VE]N7WB=V,-I1 AP@
M()!W'G,B<7<I/B%*)A0C,2*M"*4D26IC :0D:"SLF#T;)4Z:3$)N>AN ;I%0
M9YAV&HY5]'@@3=F9MA?24H%-EB!G30$<1CK,)3<I>"GR)2AI]6R,3%%K!P')
M:D5L1 at ](;.B9XWC+(/HMKAZ/'$ <2AWTF9M5+25=(R-^(FG9&BLD81&L4V A
MI5:D at T$4UU33?=F90I:F(]T:+0#4F>=Y_ at +#(0-][BT\!*Z7+RQU:",G0QH5
M:S\KGU1 ;Y D,C8'FK54FQKG=HLN)YIK D:6F1[*(T.4\8'%<'@J %8HFG1/
M0P\04U"6]W*V']E3N6U6+5<F"R\@&OT!+0!( 1<GP25X)&X$@".*'?UJ$!\6
M-CPA$R[H="Y7A!M0( DI&2IV,%$DUR8W:RL:F2V$4+9R)!ZA'HU[ at W*Q<ITI
M*!H$(!$D?CXL'=DCC7;VEH*:?)H0= Q\3!P1+UQ\50_E'JI4!FN- 7XD90 4
M at 9!NXWA7+40C89ICFKX#&4V:@& JWRE:@?H=D6S?)?LHR5-"*8HB$QL[:A8;
MN5&_)U4$-%"%3'$ZF!RV3%%-'%,X&N$9_6B= MD36!D\)M,C2YI33L4%TBQ/
M&S<B3R at 8>/!-5)9;(I\=MG)- ^H;/RZIF3\BU2V6*2PIF$T>*ILF8F\Z:D0(
MP$Z +:^:*BA*4YM4$%!8'U4<,VP<<W,@(!1>4ZV9\R9&>I8 at 1B67:?8;)!Z#
M>(HKTWS =QPHJRD+3ZLP at RC8'XXILR'$&I$!PR"0;U%]P(#S&B!\ZVG#=7$;
M\ at $A?]%.LQIB 1Y/9Y8^>?1UKRN>?\Q.C5,/;Q%PARHR0?)G:6ZB',4R-5/I
MFK]SVBTV?"]2!WVU;B@>20['3\TI^&KV4RUVWFH6=B,MM2,RF at .;IB#"'QPE
M>2D,>H=N]F<8+OP=HR" ;!-H1FAA4K1/[R'6'XULN1LI? at AX.WIS&KT<W$W<
ME&*9&6E'(#9JQW;4:+</IWU%;JN9D)DG;N).]IC >!9MFH' +P\Q<)=V:D0H
M76AA4AU6>AN?+D=].CES5- E?QH^FVL<R&X=:YE/?IIE?)%L"#I7("QH"35O
M:3F9_2_TF3I\GR:Q5#4<%9;N:C::'%8Z.1L?'73K(WB;5Q-?:%A3*AW#'.Q]
MIG?/3N at ?P!MMFT<ES4PWFZ<A/1XD<V-/[RR,4BLGS)*Y:A%Q:VPP*"F;P((K
MFVI4=7TNFYE-O$WM)R J=BR4F4,B$ 1S4AM0YAFEB&$>#2M&:,<2IWU\3_P@
M/V^H+ at 0G]2'\<LD::D[;>%5WP3(T+4EW>)LC 2)4KBI-=I at !0'9I,B@:/D[J
M at +2:QI:R4>(939OB:9]W&FZ5:.L.(T=H*%EWZ6IA*E-XNB8;30EOPR"!F[8"
M=Y=4=[8GP2 at U:*UN+7VY:E\?E)J*:N<9J'LQ)_$=C9;[4)L;0Q\A>< :YIL#
M<^XE0P2C,]9K)VY&:!84,APS>3IPW!DX,>15,QV'3(AVVG.Y*S4A6AZV:#Y2
M/"&O at *%SN6JB=K<<63P$)E<E R+S+0E381X: A =QT]U!U]\13(I&Y-.]7ZQ
M5)UVQRL<)1UKFD[**AHEJ"=W(#,!<4RJ;QXL'!/X.;9_2'+;=OZ6PVBF2Q9[
M8YAH*F at =>AH4:0=JZBO++.>6TWO)<^MO\W9>(+H<J#1>%!1SN2QJ?>F;VYBT
M?Z$5= 6E=F@;<DK":->8>BK&?G0!R4^O$M>#+'M?G!0?I5%+?<D!NE%:$RIQ
M!X'4(M4;(YNL:_%1,U7W;6PNG7-?!=%/_5);4PB9*"'\+AE\+B8_&S.:02%+
M?I8B'QH8+FZ<*'SS3EEV517\+CEM26[Y<<H9V!-=G%UV-!WN<I]MXBLJ<7HJ
M)@*"4V!XA!3?%I*<C2<<*_(8GQ!HG*^!TQSL<G*<?RHZ>UT&_G7Z'0P<RTPT
MG--V7',*(5&<JWNW+;U,D1M9 at UB9 A&(G/PRK0$!')H!,DW^&TTI$24V:WF!
MIP*S*FL<>7 at Y%6> MIFL:]PDMDV^??^*L at $>?21K)FO#4EPJPU,K>G0OQH%U
M*[A0<7.K3_-]:GC)@&01_'U%+"-T:"POG+4K=U"1&YY,JW.(&_=Z3'VP4C<L
M-%3 at !%!S 2S0<]D9H294<U0<^G?J&Z0"O4VOG/Z7WYRA>>LFRV8<)#EMFG1S
M(?-]*G=/@*DF)G.8<U I,YQ)?ND at HQ00'+-3JG.J?81R>1VO(9]4_53'4"LH
MWU(B*F<N>!JB=7$MPY8(*=Y_%2*&3'LE7B4[)?J9!1J'*'YY+FQ/5*Z83D]G
M4TUZSTXI<92:X!R<?U%O!X$^G529-QL"@69L=!HN(YLI+E5**Y0E "?M'/LW
MRBLQ<8%HV!IE'1 at #\4T*(,,'[AE-6)R6/WB/3=%-RR$I:1TI\2>I:W)O#E*J
M3_<A^S1=)P]4C9N$;'>:AR2 at *AP!)"HP&UEILU-M(MD&;DZ-;IALNQ]@(C<P
M1CU^*4P.+R) )H at I87IY@25/TB(^'O%]17+F;:Y3=1R[&U\D]ATO*.$KKR([
M at JP:0R%#4SJ7]2NV:,P:EB-7)W4FOG1PFD2!DYV1@:EX3BG)4 L?."CQG.QM
MM&B?+3]XY&SK(ZL>PYP6F)@GB!M2'!XJ %4N4?"!X4_M>(E,\QV(*)<!2E"I
M)!T?4 at !# $HD!&THFB\ \PZM+I<!/)TT&I<!4Q^K<JJ7:'T;%%ENPW=U'!$(
M-9L??')3&DY5'O)NG$ZRF(=L>VO63 4N 'R<B.T;Y)NK+,^ ]THE)%\AHP$7
M*O!*EG at U5'1J2U.+<AUO1BZB(..'FR,G:I<<4TW_>E4:;E#]+?Q+RTWE)F8C
M,YC8'5 Q,U at [58 H*!H==,]H*&F?"Q5/'2E0@:%HPTU@'-<='Y<7GK8?HR/_
M 6MLT%%L3.$!A"<&F<4;PD]'3$T?@@F9$1">"9XF+J(F/74.3!!,MB2S5=8:
MYQ at SES,2>AJ5 ?,:&2 (GL>%+R!^4%(H=IQ*'214;B A3H95R4XG(%E1]I<#
M;:T;+B<<+A]]/D[# <4\\$Z/+L5,N&C13W GP577*QM0R2,SF"5HR3!3!&0Q
M 2PR+TIKT"64'5MZ)9B5E[8>EWU9+^<=ODZ4:*(NW1!M5>--FVBW"?UH:H(8
M5),: 28D<P,FCFIN(A!6P9F_ ^T98U/M:CPK&7GQ,9Z;18GA*^QL )Y.)8!,
MXY8X3-D;"0&IF8Q]BE7/G%L8S)G )X8M'QI*GN99*ARE:'*>GR8[G at N987L6
M),5H2)>ZG<4%2)@:- at 5L4GX6?OPIP',83I^>U!\*4K5J1R-L35D!VP57+"("
MS)F)@70<A%6U()Y,79Z- 5^>BRV7)]0B]2BV&^)LAWD"4CE]Q"Y!5E at +_U7)
M+N^==22W)#PF:7HO:H4;LAE#'MD;BC,5;JISP$U8'_N:L)KY&F\"]WR94 \H
MD9X)"MURR):9?W]Y3BC*(#)79P#5&]J!-R)<*A$EE at O#GE8TIBF'>>>!PQF$
M 2X&!A3Z$\<9Q 5]E"P%%S4F'ML0-0^*'^F3 at B4Z#^65M9D( BH081%2+YTE
M'P]*6!0U"I87-02?_32J&4X)T&<>-1H!Y1H> 8)6(X3B%AB$&H0O 1R$J!E;
M5F]6758^-=,D6#5)A22$#0%E5N %(SPJA#(!:U8 at *&U65#4PA#"?6C4TA'96
M-X07 3F$/"@[A%$%/807!S^$+@""5H16O0%$A(T>1H2)5DB$=S4N DN$>S60
M5DZ$DE90A$4!4H0& 52$B#56A.)M7 at -9A$P\6X2A5DR%O0'9D9LU882>-<L!
M9#]EA*Y6:(2I-6N$AT&TBK96MHJX5G:$60-RA$4!=(27A/P#?(\VARF0>X3-
M-<=6( #)5M><TS7H/(.$2P@@?]!6TE;=->9=BH2D#XR$;82UBMU6D83?5BTW
ME(2 at A):$>I\B!\J$Z%91.9R$JR\A!Y^$;ED -LJ$\5;,A$$VIH0W1_=6:0&K
MA&LA$3:MA!1D_U8!5^\@&S;O K:$+ 6XA",VNH0,5PY7$%>;6!)7%U=<!?>$
M\U;(A#PVI9\T!\:?'E< A2=7T(2GA(\VT)_' M6$6U?7A%,V+E<Q-=J$AV at S
M5]V$5 .!/^"$.5=D-N.$:#;EA)<);#9"5["7<@#KA(:010'NA-,\\(1,5_*$
M# at %/5_6$43;+GW0]S9_\A#"?+C;"A,:$65<Z-EM7TX3' F!7-S<$A617?E=I
M70F%:5=A8VM7[EWH7:XV$(5;-EU8&(6V-J<[%H55C1>@OC89H!N%&Z =A<@V
M'X7:.2&% at U>/5X57=(I0/M4V6HV*5TR-*X4M98]7'F47BC"%DU<RA85)-(7M
M-C:%L5<7"?0VGE<[A3T"E at GZ-L)?G at G$7T*%3#A$A;>,I$%'A22?HC4[H+II
MM%?E>;9781T3-U2%%C<8-QB%OU?!-5J%^(7%5ZJ*EUA?A64X8855.Y&%UT*X
MA9PV>CZN0M17,$8EBKI"G8KA5W"%;Z!TA7*%73?4!W>%,PSF5WB%1&,P66PW
M#%CO5\*>@UM^H'@W8%;R5VX?XI&'A08X^%=4C/I7C(5L _]7+$4G60)8DH69
M-P98DH9#BDD_EX5\H%A:54:RAIR%\%<26&Q?H85X8K at ^H: \.BB0\WKF2,<W
M;J"IA78FU5VEA1U84#=#/RA8HXHJ6#9%S5TN6+>%*8;6./2%V%<%B#=8OH4+
M*U]=P86N9L.%FEABH)Q8QH6ZA6=DFV2N-<N%-03[-T$]T(7]-]*%LX7M/CPZ
MUX7 -=F%"CC>"2F-WH6+5^"%8%B;-N.%9%CFA4 at *3S>]H!.(7$D\D$LX7H5O
M6.HW\H566<F at -F6+1_>%'HWYA0MF?E at ^./V%NU^"6 )90* ,A at !" X;>/ 6&
M5&",6 J&CEA!.(J at ]@RK6!M=$8:56+F at HU@99IE8)#G&H%8[&8:XBQN&N*!<
MC5^@'X9AH!>&H8<CAB6&:V4;8 at ZA&J$0H2R&8(:E8&*&,8;NB[R,NUB;.+Y8
M"07 6* XUS8^ACR+0(8<0J= 4HYP/LQ86C]%ACVA^8SU6+\X<6#_#$Z&<6#'
M.(2 at W%C>6"E=TC at ?65J&ZD()/R"-)Z'Q0BFA]$+F.. at XE CK./18:8;W6&D-
M^5ALAO8X0EG^6#J.#*%RAK.,:9"R10=9!3EXAC .JF/9 @LY#UD..?P-$EEH
M0OF)%5F#AA=9A88D9,)!RV>)AB YBX9V6)"@Z$(Y0H&A F*0AI>&+5F0A]D*
M>Z"B-]"$8UJ=8Z6&4HW]6#M9#T at ]6:2&0%E(!&&ADZ%PC;XY2%G$/J^&JEFQ
MAO*'4%G<8'(YNH9L.1%86%FDH5)9UV!LBEQ9O89N.'LY[&+-BW ^<%EG65D[
MQH:(.7!9KQB5A+>&?(?+6I,YV(<N/=N'T89X6=.&!X>3!)=9'H>\66]:$8?<
MAK!9VED(A[Q9X8;KAM<YY(8DAU8ZZ(;6H0V' 8?FACTZ[X;'H>(3L5D"AZ\U
M38>>"?>&XSG at H1>'O8>N6>"A$3K<H=B& X?W.08Z>UFX6>6&\*$*. at $Z#(?7
M.06'RJ&268XZQUD/.LI9%H?CH1B'&#HCAWM9TUGVH>V&FUK96<!9USG<60JB
M]#GA61LY)X?,ALQ7TH:QA^M9,(?M63*'IH?P66Q:[%F6!:F'=D8[A_I9_%EX
M6GU:>EH"6B^'-X>RAT:'!UJUATF'+:)+AW9&Y:%1.5*'-I!=!SBBAEH,.Q=:
M6(=[.EJ'P(=<A\*'(%H1.R1:*5K&A_4Y9X= .FF'+ 7)AY0Z;8>86C!:S8<>
M.S5:SX> A]&'N42 at AZ9:@H>$GX&'J5JV.M&'25J&AV! "(T30Q&-R3N\8 V-
M#PF/A[I:1C[16I2'"XV,AUP%.8V)AQ1#P& \C=LZLEJ=AWR'GX>^H6E:Q:$9
MHI8%I8?K.A^BJ(?*ATDZJX=V6C^'*:)!AT6'KX=^6DB'@5JZAS>B]88\HHM:
M/J);AXU:PH=&HF6'88=+HI Z3Z(8.U&BGCI)HFX_<X=7HCE:VX<\6G^BK3J^
M!UVBUX=>6=F'JUH[6 at 6*9*)B.^"'LEH[.[5:)X<N64,[ZH>]6D=^2#NH.NZ'
MJ*'%6J*AQUK]!5([;J*AA_B'P*+.6EP[RCK5E]):8$"IBMPZ HAU. V(E$B^
MD0I?"HB>0FP[XEK*D0^(\&7=7NF%%P-+.8([%XA\2AF(I at D^B!E;BXL01O9:
MW at DCB%:1_%K( OY:F3LJB.Q:G3L$6Q8$+HB7BY,)I3MZ5^8%-(C)8P];:T$1
M6[8..XB&.SV(&%L=B(N+_E\=6T.(#(I?/@Z*QP))B%:)-EL9H]0[5X@;HUN(
MX3M:B1JC':-?7%V((:-3B".C?UP>HSQ;8(@ /'1<LXEEB,Q235MIB X\C$PP
M/&Z(&!\6/#$#C8ERB+\,=(A>6QT\8%MZB"4\7@(G/- "?XAI6X*(,#QN6Q<$
M:(F(B'1;.SQS6UER>EMLB!0&?5M%/(!;2#R#6[) ?3V:B$8\G(A2/)Z(53RA
MB'^/HXALB+:;,0*GB)9;JH at 6"9I;<0.<6VD\GEN at 6Z);<3RE6W0\J%MX/'H\
MK%L< GX\KUNQ6X0\. *U6XD\DPZ/B;E;QXB_/&D;RHC)/,R(G#S/B,9; SW2
MB,I;U(C,6]:(SEO8B$F1VHBM/'X"U%NQ/-^(( NT/-I;XXC<6^6(WEOGB+P\
MAXCJB.5;C#S#/.E;B:.7/*P]]8 at #B?>(#HGYB.F)]UM=/?Z(^CP B2")' G^
M6P6)Y%P#7!V)%#P67 N)CZ,J/O5;$8DN7!%<H#P4B3.)"CT67 \]+XD97* \
M'(G-HUT""#X&&R*))%P2/B>)P:,I7 .)+(DN/0P^+SV@/#*)ZEPUB0.)-EPX
MB>D[.5Q,6$(]/HE%/4&)0EQ#B45<18E'7$B)4CU*B4M<-9]-B5D]4%Q</:TU
M4UR[HU.)8SUHB2JC/EM9B0:D'J,B/8L!9%QW/1T]BP%H7&2):ESI.VQ<OPAN
M7&>C:XES7(H]=ER;3W&)EHGI.W2)E3U:B"$_GCV:/8-<60.%7":DH3V*7"D]
MC5R"B:D]J at F27, -E%R)B99<BXF87)Q<E(F1B0$%GUP-+H^)NCW'/)>)IEP6
M7,P]/ER?B:Y<C$[4/8^)UCVS7-D]IXFW7#L]N5QEB&U;XSUP(;Y<L(D;/,)<
MF5RTB6,"MHGP/;B)RES8B?<]8J2_B>L\P8E47,.)H#S%B5T]QXG>B5<'"#[,
MB>1<"S[.B=U<Z3L1/M.)$S[6B>)<VHD;/MR)P01BI" ^[!LC/H at \Y(DG/I8=
M*3X+7!")J#SKB3 ^_%SOB?]<\8GBB0-=U at E*.)J._EY$/ON)8Z G.4 at ^_HD0
M70"*5SL475<[4CX%BAE=]2;480B*(5M$B"!;%J/?":9'$HJ/6,]7/5DK72L_
MFXJG1_%7:8].71V*TSPW7:(^(8J]I#U=;*!X/B>*/5WOC,2&*XI(790^7(J7
M/E!=,8HPB at N@>&)473R*-P(ZBJ(^[ET^BEQ=#0?3H&!=]PIB742*95U at 1F==
MMCYG76Q=UD* 0C&*3XIK1LD^=5WEI$V*PS[HI/D^68K' EN* at EU! 6:*AEUL
M!N$^9(KD/HT)C%WH/H]=:XKL/FZ*F3YPBI==<8J:77:*E5V%BCN*4EDIH'N*
MH%X$/_9&4H6S/PD_&F2GH*U="J7\/H>*#PFR7;U=C(IL/BL_CXH5BN\#(5\@
M61VELZ3>/)B*'J4L76\^QEUMA9Z*"C]38Z&*7C>RA3X_$D;)77^*J%U=H*5"
MK(JN0JZ*6C]F7G4WLHI[/G:?CX3G7<.16D!,/VP_[ETI0+"*[EW BJHXPHIW
M/R] ]UUR!<>*)7& /_U=T**$/P%>B#_>7=&*!EYCA at E>$5[!/\E&#UZ3/]Z*
MP3\37L4_%E[SBAE>YXH<7O.*ZXHK7NV*Y(HM1R9>MS_DBBE>(%ZU/_>*(U[Z
MBOTT_(HS7O.*T3]9 W]C.%Z9/@-=.UYY0/Z..9!WBZA>"XL2BXRE=HL<BV*0
M:XND-VV+5UX(BY2EEI 5BW*+EZ5TBVZ+ D5HBX]D'HM,/X.+P#5;7A)D75X<
M0NH$)$ LBP)E*8OJ!"N+- at G91TJ+C%Y,BS&+CU[5HE"+DEXUBY1>I$ at YBU:+
M:D [BSX$;D!'0)]>78M,/XJ*?HN#7FP_18M!0CM *(NVI8H#,4!-B^$'3XLX
M0-0(DUY(BW1>P:6* U>+L(I9BYY>/HM^.6,[ at 8M?B\.188L_7HZE6F*L7I&E
M1%YGB_>.1$D9B\>08XL'9;E>]*69I?4_P%X4BZ! >XLYH7^+,66!B\M>K$"?
M1,Y>AXMB6-%>LHR*B_%>C(L^"-=>UE[6!]I>FXN2B])>E(L0HY:+EHOI7O"B
M#$7_7K1 0#[O7M1 U at ?60*.+<P;> J:+$J:?BUT+"8 at ]6:N+^8FMBSN&Z4"Q
MB^U M(O#6$-?$E\/7_A O8M6C!B%X J+!L8V $'$BWL &U_'I!U?"$&1BNX;
M"T&SH3U9SXNOC/(T*E] at D!A!8SD;0>R,#D':BXU?(D$^7]V+-3HZ7SU9X8MI
M-5JF-4GEB\*,R$,#INB+14;JBSM!1%_MB[Q!)8SRBU!?MV#VBSI?34'YBV,Y
M^XNH7Z5"<$%:06-? XQA-P6,>#X'C.5$:%\*C!98(XR(7VI?*8RJ-Q*,K4$5
MC)Q!7T$8C'E?[$%]7QZ,:5TEC&E?"XR-02",:SV)IF4WG*9 03*&/8RP06\&
M+XRV03&,0(RL032,J$&GIC.,D%\ZC+%!/(RT0:1?.XRD04*,!89$C-!%1HRN
M7TF,V4=+C'!"3HQ#7U",N5]2C+M?":&^BXA=P:9V ME!0H5%H%V,/5E?C-A"
M88S4H)(W.J'Y09N,@@VBC!N,:8QIH9*%H )MC,H"VU_.7Z2,X%\:0G:,(&",
MC!LY>HP%8*1!ZE^>C$$!@(QYC.*FZJ;A7W6,?(P>0NQ?BHP+8%&F&SF.C M"
M44+8IHV,\::5C(:,EXSYIN>F/SD[0NA?_:818.VF6%@)8.^F6&(!IQE at ]:8_
M0E!"JHSXICE at PD&NC#!"/F"QC !?=@(H8..,9$*ZC'2AO(QL0I<),V!/!35@
M- at [#C#A@E) ,1<B,&Z<$8 *(?$* at IMB,SXS*8B:-BT*_2$Q at B$)48#JGW at DY
MIY!"T(S5C!Q'AH8N8..,)J<R8&! at YXS?HG))5*88I[:+<6#UC*\U,)&O-?F,
M\XR'/E.GNTAM8/F,/HW\C&B/ND+!0C.-?6 "C8- at !(TNC8= at ST*!8 J-R0UJ
MHL0Z#HT4C1"-!4.38-!77J= C:.0JC<;C2A9'8U<AA^-,C=?AE.AM%ABALR@
MJF#FA 8&W*!G 4Y)*# at %C6FG!$,QC5U!MF $BC:-E8<00[Y at =J*W8,%@>J)V
MI\5 at J6)#C6,Y+8YE1"5#T at E)C2E#BU?38$T$U6#O2Y&A&J"'5]M at 303=8%F-
MGT3 at 8%V-J01 0X at +Y6!P >= at !4GI8,@"ZV!'D2@&&F(W1VV-< 'T8$995T-R
MC72->(U?0S)J_6#*IW2->HU^87R-=4-^C8Z-:F%W0R%ADHTK-Y2-0Z8A89B-
MB8V$0XN-\SI^C?L3A$,?8?,Z at HTB89)#(V&6C;&-*&&] 2IAGD/)0Z!#+F&]
MC:&-VJ>CC=E#I8VP0^*GJ8T[8:R-\SH_8;Q#;@5"89=APT->84AAU$/,C4QA
MU$.^C0YAU$/"C7%AV$-6871AW4/)C<U#76';0[R-YHW0C=Z-THUK87EA:F%G
M8?5##J at +1*PV<&&J0W)A=6%C8<B-WHWBC;1#=6'EC7QALT,A1,9#&4238?!#
MA&$51'H!\(T51/.-<6$=1/:-4(LTJ,B-DF$C1/R-'F$51"I$F6%P/B]$6C\$
MCJY"!HY:/Z)AW$25CK at X"X[36 V.?X4/CN5$K&%!1!..T%=%1'-&LV$BCDI$
M.PA21!Z.J#[1.+QA(XYDJ(!!)XY91"F.Q6$LCLA!+X[*83*.S6$ND-N/T&%8
MC6.AU&$J0W)$/XY/6%:.;(Y8CHY$X&'\85R.2H[W85^. at Y#7-G^.54-4CH*H
M:8Z$J&N.UT):CHBH?9"*J%N.?9! at CH^H'T-DCM$.D&4&8FB."&*5J MB;HYD
MCE60B8ZX1!-BD$2[1 %BO41ZCL!$?(["1&R-'6*>J#U9 at 8XB8D\YA8XNCL]$
M<8Z+D=-$MHOYC%6GU(C=-T%E>#X82.%$5:A;-SIBY429CO>)FXX#HWQ'0V+:
MIZ".I8ZCCDEBV*AH":>.K&+^CJJ.L&*[CE]B_8ZV8EMBN&("CZV1WJA$7KF.
M!CC!8O2.R64$C_N.R64'CZ*@"8_JH-^,!Y'-D&R109 X1<J.<)#H1'*08&1T
MD-".A&)WD-6.%(^*I61'Y&&08C* at WHX,J:Z0'V6-J)AB3)#ECAZ/BI""D8R0
MKF6&1_N0[8[7D4YD\(Z"/.&HZ*A!2>2H\J577XM%K)$DJ>JH!D C^VHXJBT
M8IM%OHZPD<".;6+"CB-DQ(YJD B1 SW18EL-6T>*7P:I,C?6C at BI1Y#_J+M%
M"4G?8GED'(]/D)9E((^:9<"H)(^N9:9B7I"I8OJF9%D68_5B3X\OCT6/,8_V
M/S./^D6AB^Q%!V,XC_!%K87_6CN/2X\]CPQ&#F-$/A!C68^(911CGP$$1A]C
M48^#.SR/1X\^CV, I $.1G]$(6-%CU6/)6-7CUR/;JD)/%N/'T9=CPD\7X^"
MJ6&/(49CCXJI98].1BY&-P,[8S)&84%NCU*H0&,Y8G*/Z%=M1F-?=H]!1GB/
M0$. at D1!'MC>!G_E&?X]58S^I5V.*7Y]C54:'CSPZB8]?8XN/86.-C^6*CX]X
M8Z&/C#J3C_QC9F.WJ1.-FH]X1IR/+D<5D$)'F(]Z8\(_I8^<J7YC<V.ICW>'
MJX^/1MUCKH_?8["/3P6RCY=&R8^/8ZECN8_BC\^/H6.^CYECYP:<J;>/NT9B
M!(6/W*FQ1LB/Q$81"W-CXJG#C[Q&5V.68]"/\H^O8Y1( )"T8\]& P5GCWJH
M-%DX1^N/\8^NJ>J/*Y#FC]ZI[X_?C^E&[H_.8<%CT&/@C_*IXX_UCWV/V&/Z
M1L,$VV/ZCX\)_(_@/?Z/Z /UJ0A'MHL*1P20GY&JD:.I6#UW&.YC1ZF)CPZ0
M!X;1AA&0"02;-F5CPZD7D!>JHT)P1L.I') 8D--%'I##J0 4,4=7D0AD% at 0F
MD MD&E at 0J@&JX(\MD/1&+Y 49/1$%F0R*OMB%:7V&R1C=64>9,5D.I!FD,F,
M1:=JD29D.ZD09:* at 0*DF7:*I1*G<8D:ID&5(J1N/3I")D""1&*FL-DZIJ&7!
MJ'Q'0V2.D/>0OI!+.)*0L*55J4LY3V3[I5%D4ZHQI^X^?&7.D/RHFD?^J%^J
M760:07]BD:&D1W:0TI!QD<\Z(*IL9(]BE&(-J7!D#ZF)J.*.A) <D62J%JEF
MJCQD1S[+1VVJ161OJH=DD9 <J2B/!J=UJE->=HL*9<J0#&4XJ25D5F1U8FV1
M.Y&-98BJ'9$/D?Y(<Y$2D15EK605D:5DL) C2=YD?)&RJ at ])?Y%,J2&1Z63+
M1[1DGCJ\D)ZJ+DE-17*J+SB_9"U P62PCJ6J"(NGJB9<RY"JJL:.6*IMD&]B
M+TBQJH1EM*H1D7>1=9&UJN&J!TEVD8=ED65)J=ZJP*J59>*0F:KO9(21CY&<
M9?60 at SOLD(61\JJ#D8Z1JJBJ9?1D:$AV-5J0GZKYD)21UI$:2,ZJ)$+0JK>.
M 9&8D 21J*J;D->J:Y#[J#VI0I!ZD=*.AV(.D:60WZI*D*F0U(JKD,1#%I&O
MD"!E $ at 4J;20ZZH?D;!DPZH522.1H4 at ED6 .,67*JMD_S*J89>5?!ZL_.?>,
M>S<RD3>1-)'A-S:13&,XD3Y(.I$+D8UE/9&G/&Z109%"JU)E9XU-!$B1I at I6
M94N18V5-D5ME8F6V25&1-:K92%&K9&7UHB*06)&F"EJ1.0E<D>"/7Y%57V&1
M,ZNDJIREN&619 RK!I%6JJRJ/*G5"1*K&JOC-5NJF&4*J>"JYZKBJG2K0)'1
MD.:J>*O=D"*K?9$>D8"1*&4+2/BJ5)"(CONJAY%A2/%D3ZF&D21)8DCQJHF.
MD9%1J0*K]V4"906K'DC_D&&0:8NGD060(*JBD2JIFI'MI0*1YZB;JTYCK4>=
MJTU)KI%/23.I at $&SD?9E>X6VD55)YJ(:B"D"MY';HMU:O at 3 D70 WV7$D<J@
M/8HSI^9EL*OD6N.B*ZKK96X ]&71D>"+TY'"D7U):$F3JU6FSC79D3>@ATF)
M2?H'<))$D6!!AH4'9N61/J#C&/>@_(7KD:!)JTD19D*2[Y$E2A9F\I%M2E*K
MQ$GXD<1)^Y%ODB%F_Y&T20&2]DD#DC5*+&8N9 at B2,6;&28%F-69_9N!)XDD2
MDA.2Z$D5DD%F5I+(21F2=!5&9EEF26;[26X%_4DADCIF.0$#2E5F)I)29BB2
M6&8.2A)*$4KB%UYF_04QDF%F&4JV2?"KITDWDFAFYZLC2CR2=&8_DCJ2K$ES
M9D.2=F8Q2D:2!)(L9DF21)+>24R204I#2G1F4))1DDI*B6;ZJU62C&8&K/@$
MCV;&29%F7)*59F( 7TJ at 9IEF[4ECDFA*9@!E2C, GV932FB2;9*+ J9F:I)+
MK/V1JF;?D7U*PZ#KD1M[\"J^E,E/&2SA2BUG;I1S :%*T)6X9L>5>))( D!+
MEY1?'S9G#G6KE5\?N%GK7_*2'#H at 9VBL37ZN27:L(@%XK+]*H at $B 509GAFE
M(]!FZF8@ :\2OTGVDW$'=@<IE/N4>X"]9_U*D:R"E8ZLA*SD2MYZ]FJ3K)FL
MV9*6K(.L*93&$Q50B*Q&+Z*L@:R12IY9212]9QL8" (- 345[0ZOE;!*20\)
M9_J5JZR1#VT/8Y6PK$X2H4IS >&5QY6HK,%G_P_>>BEMLV<>@\.LEJSQAGT3
MH*S$K*ZL1Q6/K,PC;9.IK*83GI2=%<6LTZQW!Z>LNBZTK&(IQZQTE0$EPJP;
M%-"L4)48DS%,EE6ME=ZLU!/+K):LLZP2.G1OQA,0$>BLUZP0$0R4D12/DI]+
M !Y& ;5V]4LU9_>!Y)(Y :M+0Y/YK$.<M4NEE345Z at Z)E<I+.Y at D',=+D),N
MDX9+H*SK#KIG 27K)HRL:A 9&4V5/3>*DA^5;@2N,6J<334S 7<'@TK4DK at D
MCDM9G!VMGPM at G-,0OY0@ 8B50RDEK2P<4S"8&W0QTQS\<&-GMDH;>^UFGYPQ
MK50#,ZV:2^EFN"3X at W.LI$N&#D9#RW9% 1E,WP82=;-+( !+3-22O!5C$A*'
MWTM]#W<'-14D 2(!+P^Z9P\Z\Q>HE6QP(CJH=%>M/AB!DG\35JW0''N3:P)B
MK<&3 @( 3&>MR%G!DX^L?7%MDWEGTB7S#M 4;7 at Z5G2M%#(,E.LFMDJ'9TL4
M.TLZ5A(0S:R=E08"(P7MDFJMP1A-9VFMC*R=E?B3Y1U?K= <K$_(DNZAI32X
MK"249*V*$_RL;JU at K;&4F:V(DXNMG:V7K9:L[Y0P *Z2.JT\!%\ -&[RE EG
M[9,(-1A,,TREK3"MJ:WJE(N5PDS?DJVMT&WTE $8&1D8&;$YW!:PK%8/PI+D
M at _I1W0E" )1G(P)-9Y:M> +0'^Q+V1T"K4:MR4KL#P(Z)1C.9C at !WTNS)C9M
M<4NJE:9G"Y4QE)%*UZV,+A$05)6!9]FL41B/DAD:/ACU-]]*^Y)"#XY+YZVZ
M4Q(Z))0X 2QGRDONK>V433-L>(RLY)%K&.-FY",^ 5\ G DZ&U1Y#0$ZE2Y/
M'@..2_HMF 45 O^MF)KU2[2M9 \ F TCDMB3:XQEP6N,/VMLI( KO5+%&?4
M-,HC^:VZ+K$5Z@(L$ADZD0]N9T05[91?2^5+*%'@ :.26SH-KI8X9 _]E&"4
M'#YD 0NN :YW 8FL=6\VK8Y+2C#5']M+&UYL#P6NRDM at =#VN;! at XKM$/'J[)
MK$X/&WLI;8Y9U!,GKN*L2 *=,@@QM4LWK at D9<1QFE.6MXV;GK6 4(:V]%&JM
M>@'MK4TU7*Y;(5<3EC@&KOQ.8J[2DV,,SV^LDMDF.!4?2QX87Z[TK?5+(*V8
M%&6N'V=AKF^NX4HN%<H9(Z[:DTIGAA.[+G%+&4O?%BT0 CH&&8"NZQ,42]6M
MA1H59V(I816R=&U+_91#*8:NLG2)KH^NAZZ6K-9F:P]RK @U!ZV$$<80Q at QR
M 5Z3(P_(9D-,@@<6%+-G!AF>63$Q% IP9I:LX9-2%><SJ9)H2RLDV1QQ2Y:4
M*76>62Z57*VSKD,I>Y.UKJVNJJ[8D[VNQ!.IDKB5BGB62N.5BQ,49U(/VQ O
MKK"NAI6!9QPZ14R/K#!,SC_UE0BM<P>>E-P6TJX(GURMP*[)KH%GV*X= ]ZN
MQ0PEFH&3]:SX9D2MI4M&K6T!$6-BK at P!.#*:D@ 4^JUT!5JNMDGYKJ0U[JW1
MK7\/;Q@, 801>:[*E6B5 at R5V!Z4C J\'K4T:E!ROK at BOCZQ$%7*L($QHKBU+
M#J^7<6T/;:[GK0.O"J\8DXL3#:\$KZ"5VTH=KPJO3A%MK=J3VJWO,-RM[9)X
M D FE:[_$QZ4!$O0'-L0JZZX60^N(0$MK^5+:6J,K!J#X4J[E4M+B0_N'Q(Z
M\69 KP@"JZTXKTTSNDHK!<"NX9,*KW8,=P<$&0EG#ZX42].44)6=.Y42UA)]
MK48/?ZV*K;1N at 9/C+>%*\1AXK3^"L17H&)ZM6Z]QK6*O!ADB DE8KGY=KKD4
M-:_D2]64<@&(9X019 SBK$^52 +JKAT?+%,)+#,2LBRH2Z.NJ6>-E"\1 <'
M9] <"V=N"D@ U'/-2\=G-A7ZK;V5$!:7EPR4/I<+K865EY?:D]\6O947$9"O
M at 9/8E*&8UP(%3",AOI6M%9EGOH/5&M ?*A -D]"5 I;OA026SF=D !Z?IU<(
MEF0 U6=Z L-PX9;)<^T96" X -]GG&L,&^VN,![5(3,RWA G;4 at O\8$-=_LT
M0&<E ?:!/!38+!9RFG1S$.P:>'6],DXQ[C&L,C /,G1#%64=)JT,>GXQPX+G
M&4LTM2N$ NAVS"\[4Q26LU @?DIYQB=8(FTBJS+-/])R%G38KTB<0P0GK6L
MWQEH,T8PZ!C6&?0O.U.U:P,DSWP==#1NZJ_J+\<R[:_04W(FV*]**0ETM2NK
M;?FOXZ]M(G\!SUJ;&VYV: .J)@R: YFE(3""\';(,M:O!W0'L#DGH 21,V$'
MIP&0=#9H=R(@L( MSJ]U')QT4G6P<>HO*'1S,ZTP]Z\[)?JO3W=B -=SQAK-
M(+DQZG7I,2H0 K ?,QNP!K#?%M89+K!F,=LP^#(],!2#T3 /DU5/(W0=="JP
M9C&P<7,:P77C,U)U52_[=O<.#;!Z&JL)-K#XFZU1N3&8+'LQ5!I-&@1W'S.
M+4"PDE"?=&4S7C"T,\LQ91TSL&Q,3B44!IDH+FS$:KXW)2IO="D0(RWLKWN
M49PHL'&"UG;N-?=V6'0),64 ,;#BKP4:<QI:L%" NB8]=9*4B7=&,TPJE'09
ML%$LZR:Q(DRP=1QF+59T at +"#=+ at PV2)5L HR= ?L)K"M5AO;,!8TVS"!*O-.
M.ZT_,+(OFC&)&VRP<QHSL/IS7%&6,K O1Q^.F@(;=1QZL"D&49REK1,+4C%D
M $0Q5!IS$GH:.JU);G0Q83"J,$8PA&U7L(>PUAFUDY)+<1ZVL#02/;!+,A,0
M^'14&AVPIW=? !!^52]C 4XPFC/@K^!Z;K" *#6PBK WL%VP<S&R>V$P12J1
ML'JPSDK6(&:P<8)O *&2F $*L'@AXK!I,LY_$"Y.)>BP:P').V\P\1E0-+4S
M!X+KKP.P1!3S?1RP0;!K'3MU6'R1,^X?!A0H'I:P<QK9;E9T6A)1L,6>J561
M,$LT>!LB,+4K/+ ,L,RP&)9['KIL_0$F(,IJM'W ,-@:VS(%L;<3UB!A %\
MS0/5 ?95] 4[)?)^%#!Q;YZP;'T?L3M3L $$+R\LLYP<=^A_8S#>@F4=N;#W
M%3(<+[&5!3*QC"[6&>\ at O[ UL6,PU'=5+X,;4#1R %MUL!0S3 DRQG5S%/LT
MR75;L6UIVX.VE/D0L _0=;>OW&=S&CD U76N&KVO^JS>!<E/?0].$=X0*);-
M(UV!8$--E29R;2MUL2XK-%8O=]UJ7'&0)9L=ZW9S!*TCL'MYL:]PD'$& D(
M*R,@%3)6G1/L!APDL2RC 8FQ&@-_$($/P)SL!H('[IU+ )*Q 13T2DD/+'B8
ML7THFK'5+- ?A;%!)F0L- "BL1LCK&>EL:"Q. "IL<IP@ ^-L0X*]' & J^Q
MMA>*$YZQMF[E'5\A,Q*VL:(!C+$Y>%\?P+%ZL6ZQ6X(Z$]D32'%TL:5.Q+%$
M#X at $+:]WL<VQ)!OL!GNQI1'U!<X'10"X4>89O7Y @$,:O at 2$L<ZQ(2R<%%\A
MBI.P;G83,E;2L6XK9"P)9[(LD[&%#[J"E[':0T1X[+&<L0T4Z+'5&E\A&1G\
M)1TLI+'@L8ZQ\RJZ9SX0^7&KL?VQPPQD+-UF^K&PL3$<UX.X)*U3SV_](VMX
M+VL*LBXK:P_NG5^5VQ!9=L\T!+*22N>QUX/*L5$0Q[$V<G2QJ6@;?T5+7H$I
M=M2QIGUA ->QV;%0&MUHW;'X$?X8*Q/X>4(/X[$[KXJQA"4RLBXKT6V'(0 '
MJ&SML6N!'A'PL60L77VE5L N=A[[$_ZQ9"S060^R7RPFLBXK;QBO;6 A-9-
M+'DTJ6A)LKRQ"X=%L at FR5K*8;V0L$4M!$/)RU1HYLNP&%+)@(1:3= <8LJX3
M2+(SDVJR)[+N at RL3.A1RL:2+;K&@<+E^_G%XL76RT[&T;G0A*K(/GCH:+QJ#
ML3&R>;)&#\1#[#&#E#>RKA/7%>P&.[*&LM82*R.4L?628Q1"LC6R*A!??O1*
M at [+WL6 AA:VCL;L8BK+IL>Z=\*T"LE6RGK*9LF*O>A_W<#J3UX.9LH64SAP0
MLD@/@[*[?F A# &4(+IWSS2#LANRD;+,L?62"0(@LF0I(K*,+B2R.$M6FB>R
M>[+(+BNR]AE6 .M5*P%%=MZQ at K*0>(=R9"RM/X<CEFTXLFDPB[*%LMEF/K+]
M&ID3QA"V;IFREI33LO2QP[(N*YFRT&^MLDVR20_/LHRRLY,/LG]H6 O6LJ4!
M!K+A2N6Q+!.S%,^RJ[(B 0BRM[&Z+L^RL;+.9LH9:;+CLC0CPK$"LPA]5IKJ
M<'*R!K/[27:R<[%XL19Q>K&T;HD?+ 6K4DT?/1HC%L :V[&=@,VR?X+7 at V6R
MTR72K8BR6QB7G!ZS%&<D 8^RPYH/L^P&.#*Q+ 1+T8+BL at NS*K/QL6$'!J_T
MLF<0+A46<;9N'K.+E1$05+*L5=>#*[/*+BE+3++ULB*S#'+2,/&Q.Q+_2L-O
M8K(ILUT19"QB%'24I[+1DB,DEYP;LHN!';)NL8UW/!0)LW2Q[J_!L at ZS?1EZ
MLD@/()(3L^!H^1H7LP%K? 7<?]D9(W=>&&&S7;*Q+'Z2T[) EB,D;[,,LLHN
M%$L3$">S$Q1VL]HLU))+FD:R6QBU4E>R8)CU-^&RU2 WLWVS7K(;>]JR9!&E
M-':S^1#XL78'5Q.?</QQ[J\QLTJR_931#TNSBA.7LTZS[ITR ?.R:8'/-)ZS
MN+*E3NAP7;,O5BT2(;)9LYQ\,A)WLD0/VR$0LYVS(T<JLF:SRB[OG?&<@+)M
MLUL83GA0<==#RBXWKB("(;-!$-\J9+*%LKJ230=[L[VSI'9'LT.R-ZYG#Y:R
M%!3&L^6NS[/DDHVS-K/,LQ.R# at $LLP("?Q ]L]JSF+/=L[MGE;.[4=2S0+.Y
MEP(Z[+'0+$RSU+,>LS5G9"6ULB,DU+.FL[*ST[%OLNY\6[-P<'2Q]DI?LT0/
M]DIBLV ':' 4LWX:9[.YLR@ R;)M &XS36DU;3&R +3%>$.RRX7$LP^T=[-%
ME-^SO at 20LCU+Z' 5M ("FFN!LQJT3[+S*OB3F[/[L6*Q%+1^LUU]FAH?<'DT
M%+0BM(Y94K-$LQJTNK':+(N5RK.NLJ9*&[0TM%V5Y[*P<<>4NWK"L<(1+WK\
MLSH8J[.^LFZQ80>%? at VS_[-Z<MZ4PA$/.BJR\F at -M+Z:3+0'-=&R#0&$&1.T
M3+3?LNJSK2,9M$BTY++QL8J3X;+N'S$?6K1AM+^4G+)"1\@'U[)*LJ&5X+/
M!6]XI;)B%>6S:K1 at M%&R%$LNL[>Q=;2$L\YF at +-3LWNT;+)JM+9N_+.-<46T
MS2.RLSA+/7W<'- at F6&]Z&R$R7GG[2^)-!)Y@'* at TQ9)W>8B>MS(;33<B7"F9
M,^F=X7/\GO4TOQ,*&)\ at CWGO@9 5 V90+U:NS[&8<0L!'H,N*\"3_P\YLXDC
M%W$P&_N!*R,M*V5V<@'S&!VR2QE?(2DRTGLV>'B5:)SL#WT3UX."(0 9;Q at J
M;=B#_BMS!APD/#*#?BQXP)/,M"JS3A(4,BJR3 at !Q;^IZ:&Q.$F%2 at 2[7CYXG
MWK&-<1)Y,I/5&BJR.QHUL,\+6IPM*].TNK3*=9^QIQ'6M-P'<6]A=Q&?G+'6
M&MZT_UV/LA 1[+2*'PD"Y;0%>NBT+AC5+!(8$GD<$M at 3+'A++\IU8#2G :FT
M'B5)+UEQK;20,BXK]$&E%+:S%;/>!2LDK \A++J"L&T0 at !JSL9,2M9.R?2A
M #$ :P";L6$'+P\ &62RA['M#@"O1;(>*PZUY+(U#RJU_'#4!#2UR!$N!C>U
MQ+0AM>Z!U6B<?JBTR[3O<\]QS[2-+'JQ&;42>&\N99S" RVR:[-5;3%,>ZV7
ML<"S,@ DM2:U-6V-<1)XC[%@(9T[?0^$=_04G['W%"QX(QO4!!)X.+5%M8AP
MVY4L>"I6#Q5C+[$3[7-Y**NT\G,?+D:U?QF\M-0$W1#FM+NS(+4J5D0L4F%@
M(52U)[60K0 at UCK%]M;J2T;,^;4,I>[67L2,/B;4UM7,4P[01&(*U1VBA$Y&U
M:K6S?SQIQ:^2F at -F$+4Z&:UO6[$BLWJQ317J#DNU";3), RTS CT at YVU_WZ'
M(7^U5K6=LZUM6;6HDG<!7;6?M8JUF;4ZLO.LJ;5.$52SXG!ODYVU&Y8_M9BU
M/"H,LT2U-BHV,JJL$[,/GKX$]!'"M30CF;(9LW,<I[7_$X('CK':+%.UDA"2
ML? at 1D*W3M2Y_ZK$5A[>TB+7;M?M]S+7 at *NJQ0 #7M5VT\ZS;M>%+/+)ZLQTL
M$1C;M0:UX[7@>:I3W _\5=B# at %4DLA&U at %73L2LD^[5##^\8!@-,M=RQ;+,R
M$N6L7X%M*^Z=YK5.!X"UI)6M;>NUFK*&M7&OG!/$=[6U3 at ^OM86RUK4+MOJT
M59,.ME!ACBB$ @.U!A3^M?&U_K5[M4D6_1I-E0VU;I?#M4<+=&]:;_RU1!5?
M;_^UIA/:-%0AOAKW*_)+/WC1M2NVS;4>MJVRV;5D#S*V $PULO\/W[7K9H]P
MXK6BFXNR\*PRMCBUK[.V<SNU2K;WM3!L"[5NM6P/?7&;M1 at 8U1K&M4<50'$H
M $QH&+5$%5NV?3-D+$HX3K6'E=$T>"#JL3$ 0 $0RV5[8ZLG=^'F<7M!*V
M<+:UM3(28[;0'*NUY[63L?"L8[8/M at EGV+-XE5NVA%-]$V.V\GG7,:>TP;6E
M2OFU !2E2LZ4RI.O&-.Q117%%<BU&C8#)3NVC[8!%/1P] at IMMAJVX;0DE)*V
M]K0\LBZS+2N:MN*UFK;^&'NVG[8<$Q 1FK8/MI"N6K)EM9JV\;6:MNDDJA,]
M$_:UZ20X,HVV9TL.?:$"Z0Y>MM\'N2,"M>89WP=P=CXARK7 at DPY]=&ONG35^
M^;)&MMB3#GVHMFAQ6Q=D+ -;[;*SMFAQM;9H<>DDIYQ5MBJVTS##M8UT-17/
MLL"VQK)%"8">^$_&MJ)WR;:>M>*V*K,",H<AO0_A2EJRIK;WLB,/\+9;&!ZV
M01 ![*VNK4= ]VR9[6[E2EVZ230'XJV9"GJ<Q 80[4MML=+DK(A!2,"UK&I
M<Y26?Z!D,6&V#K<N*_<CZK%?E<80L[5J$*JR(P\?MWJQ#SKNG5&O/+0 MR*W
M [<.M[9NZG/R?ST3P;4L4"RV$;4QMURVUA+X@<\9D&Z95>VV3"[D'>1**782
M$/,J\J[VMNI*'7;MM#ZW>K$4,C6RLK7!M!=+^'D[M32WV(-A!R(/+[<)MU(/
M7Q\7<8NT,!M8;\1WUAG?-" @MK083;D at O[1DF8]+KWP^=2DBZ1W#FPLK)R.$
M%*]^!V>"!YMP9Q 0<7 -67%';'.W(2RC ;L3$Q(T'S ;U@,^FPP;@;'S&C C
M1+2+?[P5[IU5M6MX='ZC%!.RU;6(M_X9G!6%MY!Q- ".MVEH+@:E?^Z# 'J4
MMZ>O"U2,MTJR-@"4MQ,0.!2+?\)PHK?2?M4 at $'%K!$X<,W'I$1XEH[=RMT8/
MZU_.M/YSX!-!LI!PDQ/W"CBW3R8O$8H3,%'D9NYPKGY=&#D!OW'L24ERGW /
M%',2S;1S ;D6.5:0;1.SY)+#;ZT3M;?[-*"RLK9SE+"W(;1MM(>S!P)(%"EV
ML;()9Y2<>2#(MVRTL2SA=:AQ%C)KLJ2WU[>(<)Q\L!ZJMZI_G'S7,99*RK>S
MMS at 5*WM';%::$[.E3T=LOP7&>KMY>G[2M15HW'YE+'-P at R$[%:$3<0?SMZ,4
M614;,H:R^K(:MR&23[(^MH\H*BN+$R&2NK'_L<=]NG>FE*^U\RIBK^XJX;?7
M,>.W8)AW!_EQH;?UMPMQ,;(AN*RW at X+NMW&WWRI.FO*W2'%VMY=Q&7WWM] at H
M^;<))3:XVG:!*!6WV!J#MWT!3IHT(\RW\WG.MQ.X*5;K9 at Y]T[>&LCRTUK?*
M(Q>X5K3TLMNW-+C8MS6R,+2;MT&XG[*:LNNS;@5K#UBXZ;=>N*^W A%L G"W
MT''=&&1^+W_%+ at !,(51XM\),G \UMD-QF'ENN'M_* at _%M[NW8W80'% J"9L
MLP6XY9/)MQ]RE1(( @&V# 'TLAJW(52ZL1ZVL17TLM:W:[B$LTM+CYQ4&2,/
MA+/96>"WTZUO>$JXSF8PM":XC+BF@(0:D;@KN(UWU!JKMZ>W ;=-E;*W,[A
MMVRX))28&.:TNW$\,VZ#O!.J?Y$L.WCWMZ\0KR>;>S^XI+ at 8"::XS+?)DA.S
M';30MW\3T!^.L1ZV-:\F;<RN$Q!/N !Z$CJ/N+FX9+)W?M at Y5KAY(*BXA+/]
ME#^V7+C$E3EX,P'8N.)PWRJRLRVX9;A'MS&X:;C]2D6WN[?'2[BW<+A K98*
M/'^%LBYXO!OM#O at 1;X-L,AZU+B*XN#&W\K<?<BF4;WY@(9DUB;?(!U"W9;)3
MK4.SUK< N86R%&?ZLE*X +D&% !ZW[?)&7D at !;F>M_A*W'%K#U"WZ;<L4+9P
MWRI2MT$FHKBOMU>W3%(+&HRTZAOY&F5,/'"<:YL=Q[9 *2F0]'YEMV]TSX*(
M3)RTWR5!&W0. Q^6&<\C!E;BF+1/ORFA*%AOYADQ 'DB^IOM>N6$V%6-EQTB
M5B1Y>EE[ %.[4GP=C '3&2*"A(,W at $5[8WD;*28N5AK^;KMMZAE^LH6"0 at #K
M'MD;;3ZQ,2M\;BL$'E&TM4VV;#($''6$>J@;42C>* HBJFX@&Q"8W +IF!D;
ML(-F<Q5ZE[03:-IZYIU3N0UX!+2S:*]1OE'$*6:YNQZ7?=Z!SR:)50T;=B$;
M',1JA0?UFKQF"Q_13?.7/ANF34IVI9KG&:4:WX&^++L>0T^$FOL at D"52'HNY
MMAZ34>!H "4 ?*V=7IU9*+IIX"#C(YQ]7B8]2V #NVX]&^!H<"8NLC]X2R^J
MEP)Q%0(\ 0MT<""[EA$;D((7>"\D] at 77'EBYV+'V&3J B/9']]O]+B%*?XK
MNI>Z'0*<97SC5$4N#Y[Y&L:Y,C-$@(>='2"2>PA.UWGN&0^>R2:JESJ D1LJ
M>ML9#DQ!:Y(5!!Y/ "@:ZF>SG=F>U4S_G4 at HMFK]G>09MBGB)\YJG"R%4<%,
M!!X[N0PI]"N((>U3 at DG\,F0UO9[6&>RY!%-X3(HFIYC.;5A^M[0"&?<5;GWL
M CIXYV8T*PQW1QE*N<I\KBH%NJ]25T_!'# at OBID+NBP#:6S4-#EMUW(->2%.
MSIS<(E*=WDV_3U6=O9?6&72!<RZ '+Y1757"(@\H&;JUG2>ZB!L['14L)9V3
M'$JY.2!#+N89(Q8Z'5$MX&C,&F5ZNVD G IOL1MP E8!CR87E#P4\RQ$EAX/
M>&PC=LB86K<BN7TH&)SI'(1KW+E\>> A^7)[F+8A>FA'>-N;P2"<3>ZOX)LH
MF2 O2;IU'8UX9:[B$V^S(BQ%F22!K!KL+[%N<W>B 1XE<;J0<9UY-'J_(TB9
MC1_P&RLK[6]D&[TLAB8"<RD<PWBR<\4%*P_>2WQ]<90<?2-L6)D[4R!2TRT,
M'@*U<!H[MZTN06[= at C1LYFR*4(9Z at R#&';]S<@^E'!<>B[">)*XKL)Z3M"NY
M8+E2%R,=3&@==!B9*B5U'A-\NAWD;.FV%I at G)IJZ4AY,F#T:MYD=>:@GV!R*
M4 @!["C/:C27%)OY3YHL)YGPGI-3%AXU#ETC2"< *91J(&UU4%AL&1J95;H=
M5YWO*2I4$P,+FP(O4ARP<KFZ$%+:<KRZ('KENI>ZJ1PA'4JY*+FENEHK&1OO
ME^X9 at 2C1'L.>1"Y,F"TPP+HO30LBP9YR-V0Q%26+&YQ-S&__&L '/WZ3'XM0
M<'**>]HMOP(;?M1/N;>;<T4 at 06YK&_FZ7;KD4 5L/7K('-6PIB/[=PYI.%"-
MEA-M7)M=(\]\Z2QO=+^;>I?5*Q,ID2;?4:!M-KDX4#UR9+I7=T1Z(6Y'@3L@
M8IZ#3$ (,TV0KI68#K$E&Z JPYY9:7X:*QZMF'$BU$QV:(9/B6^D'CV[:R%B
M449V0FCP at .@?]$WU#I0GHSOB(!T!C9G@&SH;A;D;4(!-X)F6(+*7:6\): M.
M 'SY>'LKQKH2:*.>12XG4B,].BT.46:9U4T at FIB >!LY3JJ7&AR&:!"7\R82
MEVXS05(9(!EQ5INU>)Y]E@:@N8]I;DQ!% !\_+KUNO(CY9K]==L9!@(#'+)5
MY0^8EU>ZO!K,&CPIQYL<5.9,UR%?NGJ8!S!['0R X9B!>OQSI$Z9<.]4AGO"
M4 ,NE9EC'HUX^+69<.(J4;*0?+(P?KHY([Q\%G9U'+N6:1P at *B\D-">>;O:Y
MYAP#;I=5VBW)NFQV8")W<O0%NQC"#T.9LKCG9F at LU)G))/5MSB<_ at %U3URA*
MN2Y0*1M63ZQUE'-A;2"Q=9QD(Q-SIQ&><MDMU"&J:T%NH6B>NC)NOKN939Y_
MF+G,4[-]6BYD+6DKHVU:LTH1*WOS*NZXZ2K1N1U6$E2= at *PE1R$)*4JY(B96
M(]:98AXX>L :OKKCNVEW[RPY(>B[AU1=(]$'?RKY;_6:8 ?&NVEZB5+J&?.Z
M7R3UND,B06ZA'YZZ'6L2:EZ>2KL3)#6[U2<=F-,T!!YR:OY,WAL- at 3XBAR1$
MN?&;G2)/(Q:=[&V&NTJ[B+N^(L14\ FM(T>63YI5M]D32Y9H*5.Z3I8E)$\:
MZ;DJ,*6YH!]?EIX<1W[::&(DIRSIET at K)D\;+PRN6":2!#QH'!IT:@=/^6M"
M("L>,U K+.^>J1N6"_YUS!K($70?AIHD( "NZITW:?N[D1M]4M1Q at TYZ'K5J
MAVXA;R<OQ9RG;C-N=VZ,'%DE&E5[(WA107:Z'<U-[5#=<HXI=)Y>EV51/BZH
M(8&Y^4]D>E&\*W9S!,=/ 5-6NG%0_!G#L*X"*3PY:D(@67M'(P4C"VQP*CBP
MV5)EF>JV X"R'Y6<TE)V)K%V$#2$ at ^HCOGWWG1)6GIZLNEAS at BXY:@<!CIM+
M)#><++NZ:#LE% at $"M?(<"E)Z3&]R97,[)8AM;B)#5;93)R^B(9:\;BRQF9R>
M52MBNZ<A E1"=ZR\Y at 3^2ZPE3'HZ'$2:MYY&FB)P$#1SN:L>PR9G:0\+ZV^J
ME[U[.RU^;&1R#6FF'EJ[GGN :Y8 at Q2DR@9Y5N2[$KR EA at ELGB,#IDW;'4F[
MN;F,550I!)LX*Z(M;RR;GJ)L$2C**T=\8E*UFN1OS!IWG?R947G ?>!3 at 7A)
M&H$-]R!%O/4EZ%%3<EBQHAN<?=R!^;P8)!!6U'BA<)^6H1J:&J-^)1I2*-IW
MJQX=&ML'9D_)?S:Y0R9-*==1_9F5)O1X="TB4"9X1QU]<%%I,+T))IVO>RM2
M&Y4L!!X#*F11H'W[G8-1/)=]:WU06#85 K^O$2S>*/H<AAEMO.89_2.3?&:R
M;;S:(2R[+P9= +4KFQUP*>2>H%3H=\MJ&QSI>78L.YW1ND0NL9F)?>)3OB'2
MNWJO-R(Q)35JPGAO)RUS>5%F$' NW1P)&[U5,&K-<UM^\BYJ4F":L)S'*(Y/
M&!SS)J J W*R(BM0/792 .L_N!O('@UHTQF+ at !9VU+M]<"Z"AKV+)58=^FBH
M,HL)))<]&SL:K"*)',HKF:^W'&!1JU*&O9$;_Q<":"%."VO at $!AXXE-8@H:]
M]&B% 6-/,Y?O*\-WJQXU/B\<87<G+:"ZK'QL3G!/77YD<HA](FBV:5T&(C+C
M3PT>=1SCO)9SZ;QOG%4S8TY6)G2(:2I/;PU[YFZN*K(BN"LXO3]X-IZW5-^>
M3VPL*6 at BMKUC3!*Q(6D5FUN[9$U 3P^<-KNW,BE4\9IR:X^]ZQX[:750YVJ0
M4?5U.5&%3,HM1!T]>-.]\&<U:>-Y:+R'O=A_;R#%<URX(QW*!OLBOE*J;G I
M;B at 2'M$D.QSQ>&*7!)H9:$9J9FYR>2 at AF'[/+4YRRVEL+L4HD1UJO%4$8R,X
M?!P>-B8+*(A,ERW?O8-1D0'**SN[ [L1"!0 at =1RE3PQ6.'G\=U0M!2&G)O*]
MRKO:EV1-QYQR"."O%5$LNS"!XPJW= at \J!;XF B"=P'CAO/JP426Q*Z0<DR3T
M'"=OII)"4!\>;E22 =&Z4R'V>VTE(56BFJ2]0!O0NE)PAIPW+BR[ZR/]KZPM
M!"* ;#Y4AR"-5:<MD)[EF#I4U24< E E85&IO>J]Y4H6NI\$UFQ/)WM4-KW9
M&VN]KFE:48<:2!_UF9R\9QVNGB\L$+W7FSF7U'ULOCPA?&@QGCUV*!\Z;C at A
MZ;1 ;-RZY[U4&L<H%"=*3RB[ %)EF"PQ:)B')4U4()Q^(C\:BBZF?6U57GG[
M=6(!' 4):L4-M!Z++0XMAGKV>(]50;UF3A^9?")14J(NBE!,:2V7;2+=!U #
MT0,S)5T:^FD2!?Q0#'-!3=%H:P(":(B[CF_I35"7B"'C:+F>Y at Y0(A%HC0$8
M:*)5!&BT?$Z<:!E% (\F%+QF:0%0?2' )O(B>IX8')^!BE!PEF9N/)JL<_4.
M!S6/4),>\" H:9,CP!M+'XU-" &Z'G0K+[ZF,B.:RVDE(2X/[AY,3DV7"0'\
M=]4NV)G144%YI!RM'1I.IB?434.^IB!NFEY2SY;I(\EM\"[N3J]/:BH>'#JZ
M$7L=:9<<KB%?&Q<!2Q^S>"Z^&B '-R)1 at B;"?Q!0G9;&<ZP?6P W %.7Q7EV
M()*\DWO5*PUZFY9. at 34<QI[A4 at Q/ W)M&UX%)V\R4BL=BB8=OE,;0P0S=HP?
M/9GW+'HJ83]AG$!S+KR_45QJ\!K9ENB!Q!F=%=X0AQ/?EG\3W6H%(0TO! H=
M!W(G_9;\(DQRTU' +.F#GFU <PTJWQM(O_9INP-5OR\<OB=,&XM2Z0DE>4)I
M[0D'-^F[>[QY))L=%)DM<,93TDPPO52612NH+-B9%9<4>PN;0FFI<B5XIS)H
M*QXA<PAU:08 at V7=.):]/P;L'N[F8]Q_?ERQ\)1O*G'0M= [Q= ^^<KY=4O8M
M"JVG<B2[%IF$EXQWCU"7(5&9!)D?:IN^*;S!*:.7Y2Y!F("8M9>O3UB77VA-
M(&4=][[C:%EI.QHI at 0IX:IDJC>]H;U2$4J15^#<Z(*0:1I<7 4B7PGM'MM8:
MZ)ZLFYU[P">+*5DF6',1(L(:]T\&(L>:$R[N+O4N R1^&C:7T4SC'75O B5>
M H(%IAU1)-Q5(9MYO_AM!DRD>/$F"W1=NE=-5AUL>P":N[:L'R4+HB#LE[9X
MJ!M;EHHI2RY,>EVYU;P"'((>AR;\*<V^8"3B"$]VT0]P+D0F_+J4(\=KCGUF
M;LQ+<9:(= at UP7+V@(X9,T)EX;O&X$GIO(CNYU![;':^\F(! 3B67(&C+=PEP
M2ATG($!/\4QBELV7<"[N48%33W9N>.9M_2..@,X']U)T4^DI4R$F)'0HDAS;
M&26]@"5V at PD9QA##'1Q1LU/^;EA3.52)4HF=4B8',$ at G/1[ ( (B>8&9*!"8
M%0+,&Z at NZAPY:]IZ4FRG=WTBM")!'2D=72/O(LA1?!U4+(@=)[S&F?H<3U=@
M4L]K*2ZH--T!3G),(&E0TPY*P#-207"!4K27;BS9G22&\9OW*&HG95&);P E
MT6V/>B,N5U.S3$8 at ]YEUG5 A*1M4-HF<-IVA;AL>\B,T4J]1$P&*O;>\%G:K
M'@,E.'S[>F7 * %#'FQY3F[ :7$E#6FK*&8<IAV==G,E.7/K4&"7YWQ<3:4"
MT"9++WO K$X\'"0>37/]?&Q/8T\N3AI0!1RRL 4*1U W3<0>HR3()NHF9<#H
M&3QZ'0:QO%<I97_L>, C)KK;+=>/]BU 3OR;86[[%/8+.2XW4QV[#!]](YMH
M5X"0F<5KFVS+(*<RXGF4):M[^1HN#P(?6)D<)V7 4'>6(MJTYDQ<59PFWUD0
M)4>\(7R7M-T!NTQE;1T: '3S&@<GJL!*/3P$ABV^+YJ;UDW<&VV>DK30O*-H
M<1M) ::>#GL,P(L!IIX?;?\<E1=[;A8I<QJ[OX. :RYA.2U2S;J[3R:<-)?S
M;=PH3US(GN.'4E%X;ENS:"-; +(LR;Y](@LB[0FC*P%4X!\_/FQZY+E) %,
M0P 7)]*^=BA&4*:Y87G8FYYL5Q-0(DHT."]#E^A\4F@&(/U2,&HT',^\FFCF
M3Q at ?_0&8''DB(G;7;WYLNB8Y(68U17DU/GT;(&X:3Q2PHWML38%OR)TM)LP:
M2B#<3$91"Q^S4S9Z07S8FPQZ[B&\*9$@(54;'C._H)<=!CUY]'C/3 at E4@KH
M<!(G(I at ?4:HCY+]E*EXE91V8*%0#B"7R?%DN:4RX*J:_V!Q,)@<#<)FHO%(;
M6R]Q4",N$BJ6=R :=,#^)O<MZ7SO:#R6KILP?O$9YB?7;W^8TQDR=P]XBR-G
M@)P5Z'7:+%DN<B[O>Z%\K!H'+SN:9!N P> A.I2Y4"%V,B at XP3!SZ'LZ#XL3
M9G8X>44J#9=<4CQYG6EG =Q1>AHB3%HNCYL,5LAW*R78>]=O?\$L)^TI%IF6
MN7X>T;DQ=D-.*QN[F3H;R!WBFV\BR,$2&\91FAN ;4UPK<'$>4 HY)OV'W!-
M4"B+?")P#:QHG/,J^GG+>_6>(GIN+)8; ;MU&YR^72+!O1P>RGB:P!=Z+2[@
M' 67(U*<,5A210BXN?<@RR*E,CPA;B&*4DUPXGF*;D>;[2(_N\(J/!Z7+OG!
M,ZZ/'Y:\27T$"D5VSW;PP;8:TKV!<K>;R51]+FE2N"X]&C5Y_R9P&^-OE7MY
M*$UP6!L4>L%]05+\2J69F)TD'V-J7E. OCA,)% FG9I1F',*("H at $1MN3$8/
M)\+;3<%SV2]VNS at BB;XAF9. K0@('"\E/1LH3^1M\,$>'^4"B',+(GY/Z#1,
M(*(>,'T@'%9-(7AH3GQ/Y at 2'3% CX[Q23LD;U<"*)B OY4]2'HPI?'5 O_)Z
M/AZ!=YEV+B94/)XG*VEA3M^;GW5, 6LH:BKNFM9/3[[/439.P%+L;;D?;FK)
M*.D!TU5X3G2:<6[>NH%V R2Z*#M4=RV'(/]J=9ZZ+O#!D$M at O5&;.2'G)G*^
M06AB5 ";(,*@)Y9ID,'@4IQ2)\*WNO(M1BAB :]-RRV1'=-N2%6730 at JF4VI
M([!HL2753^U\<L)63W*_DH'34DMT\YWSP*@;MRV7PDB_J2<,/"675QNY*24>
MRYM('I!NRR'W)"TR6,+ *78L%W=?))XK.R ^PGLMQB at 1561[*Q]RPKT<6VE/
M(%(K\2LA5;!Y>'T%MO^S(T>(=UN4%7BW;=<$YC-DKH092IJH;("2PA'?FR4A
MIQO*4HH>+ &$'W2:60%Z(X8M(RU,:;4X7E+B+O8.85#NER\L>53J(O H5"(Y
M'H6_7EDV'%\I9I: N$F6O9K]+A4*T9ZH;(0/QREX)- at 95IUG*W^Y#AUX:H4^
MH"[/?#V8-'F?4TPCL&X*!*V6LG,0>;IJU1CH=<I#>"2[;BE/*IOREM9/T2AZ
M&K*73GE#N^$;I<)U*EK!/7"]>_]1&7$4OH8EZV^=+6X at *<*74OAW<K[B>0XL
M9G>(&QH"@EPY>8P@/4N\N5:^)U+Z3]$?$2=I @9J($[*3C8Y,QJ;5-$'EX E
M?PIZ!2G.)]F^URD/NW$=4T]A4KV;7L#<468 at F'A:O)B^52X;4*9X6'C4>Y=Y
M%A1$%.=UFW#:+'.ZGX$\)I]M*RJJ;^)R*&_)>,5K?"KPPLB;R$ZJ>11J&B0+
MP0 :.G3!L*L>891J+&"P/1N!,LU-<76<=8I3L;12FA"Q4W2]=59T'75 at =(0P
M<!N\+\PI)7J<+B,STS- ,;A3WS'F=#-/&'6Z=;P;VTJ3FFHPG\.8L/H<4K#,
M,ADP!6S#+W /7[2U'] at 9Y4_J9T.;;'JK)G1L!;_4*U9/-9P4+9E/EU%W+.5]
MB'*\)8[!X6[0F_B:\1D&:5F]37J"FPT;KX"@:/N;A7OYNIXC_6\1N^5];7)<
M:4.!_U0F-3\ D8!NPV68*4YQPT.>051()2ZY%[[.)[:63\#,+:FWB')()[.Z
M1KY"PED%]U3Y=<R[VP4[+3"^+AL'OME+\7C23DDC/BL")?\M62B_F+PK\"U.
M':\;9B?<<CMY>;_%&WLN!!_/N^HK1[H&>[2\6E1L %'!TR2-N^W##)ZO'O)\
MO<+53\O#V)M\:AX<@BCW*UV=*"Z93\J\BB)9G& Q#"*N<CX\WRGNNQY[C'QW
M N0K#9W^?5M\O"\G:4TK+54. at 0$4 C(K4Y][9P$):F_!J6O'3YIR3QK/# !-
M\5'&*]B:NVDY(6>CQ&D-)"^\?G=>!;2<<!T4<(-^5C-\G>0N3;[3O%V:OATW
M:[,B\2)EP?6]=B,C:=1RD2I](J:_AE4;?J,K&V_9'UO$);%A'%I;9R0*4NN\
M.% 7G! at LCT[M9Z4+?%7#=RD;7L37(HO#+E==)71^D!V#*VD=W+GW*, B"B%+
M<U_#KDX:4/,F3'K9??YM1QL>PM#"^R".OBM47E7,3/V]."PA+IH=*2X=:V"Z
MDF]$O:PUG7>T2X.\K!M-*=V"LV/I4-%./ '":A-^JT]+<TE,@2HK ^F\[,-:
M*TT 09IGP(M5&6D)#T ?2[O5'8:;59BI&^2PT%$HO>PFTL)8 K>=05*^(50E
MS!S7&>]J"R<"6K6=$R)>>"DCP+Q_=C at KS'Q)37U4."@LF(]3N5SG:T($$1V
M;FL 6[I1'&(!HS!)F2FQA)XT%&M3O $2?G\>Q1W,)87"7BMBNJ%N27K6:Z$R
MK&N at 3[6=#9@G+5532P11I(4]MQLK;'1J%7P>*G]I42)G =-5(FA8N5DV."MF
M :[!YB6M 2V=4W)B%")4L)PN(3!V+RRT(W2^B7X_'T,=G4Q?B4<B0+J2EX!3
M60&@*FP:&'D*%%535;D at N94B:)BY4-X;HW&5)M4>2C.&O QJ+6^"'._$*)V%
M>*\BYWJA&K\"WA^XF:XE:GZW$YUJ08(O(3$ F at 0(<(0VA[?!V)]JI[4 5H$
M[VA8 (Z9Q!*4 G"2X!A=VB".[]&:)(0"Q]3 /14DF,@('2!853I>;M4^V<C
M!< CQVLKA'@"@\#?P>Q53V\:PRW!3P!7!U4?<<5Y']8:M"U!$.T?>AHKA%6<
MT'Y6$A <BPE>Q=:_+@"&;:XJQP./"4F!96VH<)IVRVTSO at PF42-=(PPNJTP:
M MV;1 at \]=M4\(GVMERB^H7PJLNAK0P#^'E27&B&#*%@"T;\P?8\?6!I?((R>
MN;V;*LP:5BXV%;)G:"--4(DR!0)SEZ(1[1]F(%A*G at ?Z3NX9*X0A 26#OP76
MMD\:AAF8Q7,:2@ 9&F4=20#W X4#/ 6P4KD at 30 3+P9K6@)I A,<W1PD( H/
M^#='O07!LYCF*:O%-!)5)'G%AD]3';L:FTZ at Q.R 0DWR;- K6@&Q3GD>X#<J
MLADAN2.1 7:;"W74:)ZQ.T[?&7H;B3I*'H!3#0]: >X9 at 5-*4)S \YT,'D90
M>9TD@</%0!J]";%4*3);.TX=;G1I //%$)\D3A<!60%A %8TW%P6 ?"^VQE/
M+!87]E79&_\!L":4Q;VXV,4T -K%)1H5LX8N2!K'! at HH)AN" >DC8G5-'Q!,
M(C+6OX<J0\'1O*\AM at +%(%0:S!KI9WYH!S6=+1>;IAU@'.<A+0!(35.YV!I!
MNZ<=E+Y* #!9UR9/4+(L^1HUQLLI(T=9!Y;%-0 [QB@ W,5" !D:@+'C&4YR
MERE8N2X J20U*X=+40$1!>?"_VR;'8U-+ at #EQ4I0?,8CFHEZCTNE:-0FFFKF
M9S+&(QV1M,I-T+P$+J1LP1\#P3TB66E#(2V;!,:Q4 ?&W0/6):J6S!I5 !+&
M at E/;&17&<<5R!TTA#6D,&^Z^&L8]:]P9R;+"Q2PI6VH\G at P;PB\RQB\&3AW4
M#%$D=&V,3"O&5QK# 3D&*L;$Q6\D)2\MQE2$;E,QQJ(!>A^+NS<!L"9*O_V>
M-Q6P'K5_)!KH)# /D7E;Q5L - at !MQG#&]"M(&A at ?Y0+5F88OYL5! +X#/0'\
M*8+&$1O6 \,M'%2,'\UI0<79)OD:[KY)K$E^*1NC<1 F^1!-36Z6?U..*80>
MF22''D4?0$Z3Q+XO9AH8O])-TWDG';0ANTR8%(NWQII -,T9F<;G4)O&I 0R
M:Q(==AT>#_,:D1NTQ?X>;B9L/@\+:0#4=]<EG2SXM*8=I!P)QQA[SQFYO0ZP
M9+]XF1<;*",=QO1I"YF+NW('R\4-K(P?\VV5 X V1"Z02^>]Y!EVKDUP0P!6
MI&V\D1N0G294I;OK(9N;Y!O#("3&O\;O"8P?Q,8OQORX,L=Z']."[ at Y+&S /
M3"$SGB:_Z2^K( A0UAG<QAX!.$R1&X+&;\5'(.7&$QSHQDR8&6CLQJ$HYL64
M(BN\\+XZ4_/&''Z8%!\/($_J at _G&CQ_[QJ(@FB2R'0QHB;Z*O0,D L?7)J(E
M4R'^FL0>\2C4$WO #<=C;.$9M<7N&<.VB1MC3[K%G6C%&[W%.R2_Q4 :P<4Y
M at ST:30<9&U^".@"<:LO%S at ]34_D0;:_6&EUYX"BGEST;_P$, 2"QDB at C+9\<
M35 at P&JIJ<55T4T,N,2UQ3I ?U"Y^5%XEP)($'F1N/WZ(=M?&,Y>= @D"])+8
MQ3@ ;<;<Q4J!WP&% RB^_B4JLCFV""$N)JAPBQRL)E92.B G-F1-^1H%QALA
MN<4K&I at 4VZ[1*@O +,?9O;D;37>HQ\K&\JT\<.U!ZQZ;'3Q65,?+2F%V !^8
MQ6)UE+X:'8_!XAG\*4< ^2)4 $L$/0%K (P?10#Y(LFRVP=H*SPEMR]-)UHN
M+!O#()PR11H]&EH A1T(;[O'# at J'>(G'52'T'MTC^![ at -XHF$)=$GO8..H N
M;+# AQX0;4!.=1XT&4PF>1XW) ['!L8Z.1''QQVJEGH;,@ _&I$;10"Q(\?
M!<ATQ6E09P+4=X1R/1I<'X,H6,:1'KO'U!K+)ITLOL5=;C0:#6GCQXP?V#?2
MQ6$',L?$$]4;"QZ')*ENZ0&,'RPVAW,2R'\0"Q^FQZ(GJ,<,&TD/R\7#L^C'
MJ\<ZP at TOBDOF&0/(R3"9"T]VM"T$'M)H!G25'^I\)Y@&:[(9"0K1)K)+] at 7%
M:,MLC4V/3%X$)$QVQA@:4"$X)XG'G&N8%*8!$!S/M=)3 TTP::8=YB4^. ,!
M/1N=<<$;IVRGL at V"UKEAQC$Y=YI0O3VY:GY/=C(!EL7"O at 9T4@"!QN@@>AJW
MOGE''R%A4>89Y<6;Q9 at ? F_N+!)LV2:?QD)4FQT>Q$].Z!EG#[!UHQT<R$8?
M0D]'(INY-;V>'>%OTKU9&NB8UE <#YROFTT2R) 5JW?75:@CG7L8QQS&HBI]
M*,(OLK))&SH R\;+Q1H9 at 2*R4EL;9B+T,X'%R29^,US%CB*BR-BZJU(T; F!
M&QJ)Q^LC*1M1M.H9SI+;50H!'P(+F:(<<" >'R7$/@0'<9G'>AMN 6MIR\A<
MN-8:JL<V:24:A!"N*G(0= at ?>3<NQV,4>#U[%=1RCR$5\+B92 .G(U1M! !D:
M-!JYOO. UKF<,A')?AX& 4(>O &J'G,:DBBRG:\M<05(Q8$E8"Q-3=9SU"+2
M+CT! at VF7'_4:+QJR!]4AJLAV'!F>+0 ?R/[ "4XQ5$+(J1'S4RJRW $+ODJ!
M/);:+='(2L at $'R0!<KG7R.40,L<6%U;(S\44&Q1K.A04,5*RB)4,37ILUQC#
MOAC&LB<[);D!#0^Z'M<FERD!:Q,<S;Z% W3&&\D93?K'!!_/#(!VPGUK5"JR
MPJW>(?8%Y5,G&25]U+Y&*LP:?"=9L"< OP*9/4YRFQW_+^89\VTH4C<A at 2+=
M&1@"MAX#R>9L,Y at A#P[)V\4N &O)6BO7#%0$S$9MO-L9@<B4'TD*W0'KQC+(
M;L8N -HE.IA8- at QX(FM&:RJR_[]NQR :#AKCQR(R\\;9&;G(/A!A4H66:R/]
MKZTE;R+H&5N6N)I2'?$B9!X]R4I^E2U_'(G'V\?0&LO(;Q at +'Q#'<[QNQ8!3
M5!]. $D XQXWP!HAF2$1&SG'KBD^5$C)M2(\GIS(M,:.$#( HL<1<HHB9 at $/
M/-TI5 !8 %W#K!Y1R='%RL8-E=A[[E1<Q=C&!G28O:M.30 ^ >T;<$^,'XC)
M1,9G)2JR\U6::OUI$"1>6?TOG&LN at F<+KE(-#^XN02FPR0%F$B!A'MXYLPZ#
M*#ZXF<<,&TH EP%P&RN$;0_JQP;)[<=R?B8I7+AP+B</C\G6&=S%R<>&+CNY
MBP%B+E,A2P#AQID+;!PAR6<GXAZ;P8.7]@,A)] @=<?+R$>8(FU9 at 3?)]"#;
M:%"\3G+N(4U132,W(03)>21N-RK((!K(R0MUF,!](J,!MWB) [\//LE\ :AS
M&\?B'-1W+,6/'S[()%/L3[-._IP=*/S%Y[I^'K$UF 46#7G)UIJ0'PN9"<??
M(M8:LZQAR!$0(AIE'0L^IE7V!1HT++FGP&HH2\<]&W,#2AWV"F'(B"'HQPG)
M]$T ?**]D5%:Q^)ZC+1Y *$USDQ\;2E-9A7PO at 0@M+]]</<?4QU=(XXIF4[!
MG7:N[0[$<D]I' $Y/LE578-Y)%^ R,C#R4C*AFK%*P5Z>1Q.):#&Z@&BQMB4
M31[8F;G(L _L:%--U\EFRME3] 6 at QR HYVM2 1_&3AWR2Y^;# *\QML9$\K/
M(%(>*X042P(>C[L,R0$?!G0!R+J8H9;QQN&>8,?AQN/&:0!DQX@;9L<T)X8K
MGLG:QD<:LQ[>QM";],82R(HCR1OXQ at 1SP2E0*2DVU![]OLU&:,&W-9;&V1D9
M*T;*[U,(QA558K&+FR4;@YZ% 1;'BL>/2_X>F!]3RCK(!VPRO?BPKBG9P4I0
MN;T#(F$_5;_6;$C)=JZN+/0H: < 3,AV!_2<+=X^W/6!(1LU1MGQN0>JI=M
M%"#*[<8N !(:C%"!R#M3[KZE'Q1VSL>*QRUN-<H[31E-6VS9!J%LPQS'P\\'
M]<:@%?\I77K]QO<@=,4-:&3*V9SW&6@ K( ?&AH>D518N<Y:\ at 8D'E(>RR)&
MR%H:=JY"$ PA7AHP*!\>4+FU(%<?#$\\Q6].V1NA*+(>6VL4(8H:UT^KR-('
MG,@ @D?BE!\$P[)BU3-*B'+VTPCR[^\H98GRCG++@ -R/D:W,9,;V!QY,I8
M(+C)7'K\QNEK]VM9%16:/<E4+4')E<==;DC)91TB @4R.@ ( LO%(P&,'YC(
M4LGV&8O)9QZFQC.>?0\>RVK':<L'4"/+;2(ERXG*SQEPRQ,<<\L4=EDS/4O8
M)NF#9G^0:Y0 at ZF=$(FTE;!IPF7RNDG, &H'+1L&#RYG'WC2B,X8C3,EO5M@>
M71]ARZO'4B#_*4 /;<:6RQX:F,OH(.I5#![1PE,A11IQRR@ H,OZ':A2+QJ!
M(JQ]0<I#G9PR;B&KQ;0E52"NG6].B\(=>F%4_7 at TEUG+6S6!:LU]9PN^';MH
M[" !EW(? at Q_J#G9M1<M#'D\GPTNRRW =F1\>3C5LY6SY&E3+8FMG:EUH)<=6
MR^^Y[<9:RX6 /1M&Q9L%_"E<R,,GJ,=ARS;&LA_J#K-W9AT-&NX9$AJJ)('(
MZAF;RQ9XWQ_:QV@ FL47R9!IMGUD?QXAAH"U( <*2!]#'J5]:YV]34K+C)Y/
MRZXE[IO:*_8.^<N[*],?_'M9RT/%'!Y%Q5W+\7W<2]8:2 95#LE6AM='_^Z
MXCSP&GZ\1#)%P<7(<,1\5)5/4AZR'/0BY1Y5:7G'.,O;'_;).E07QO:8? *>
M?RQK%QWJ?PRM=6L0S!D at 4;[#)ZE/U%(LLAD;>\$_!R'&FB/9&XTAZ SF3JDG
M-QN>4$Z8PRJ5$H]Z\LM,'(H>*\S\4GR^*KPYQ?UK5LMA=^H9:\PE?Q%H9 $E
M?S0JT8/9Q)8 at 30"X43,I;\Q)4$Z8 at FQ'S-T=>,SFL!$="R(PS-A161^\F89R
M8!3Q'S3,;"!J+C?,E2;Q?4X<AG7A&28::P%C'Y$;+1HOR14PD!R\&OM[8E.)
M3',#)3S+=W3)6 at 3&+6"7"R('"O0B?Q 745(:\IKA(2G,1!IXS$3%C7TO+)?,
M7R16RT,NC1IT:I_,#R!BM:,=4,;7&3C,D;RW5"(M="Y.;*(GNB:E> 9K;X&(
M3.(LEL=D'I/,YKQ15$Q^R$W6&@N[!"#" @-RT $P GEW(56 at -9UIW"*=>U<?
MEVDQS)K,R51D->%0:P0!A+66P2#WO+,R+AI :Y9/9Q![*.$9-1IA #<:7,H[
M&L!I?BJO4;^ZO at Z_'VQ.5@/_4Q4F3539&R/,O\Q&>M\9"B$/=<+,-!K$S#;,
M^YU\S :\35OXS-LES<R1&DQ\VFL$S. at C_2M4P+A4 [S9S, D=!KF);?'BLQ.
MG.W,,@1GP25_4 !J6V<"4GS'=OJ;:1H > ]U]\P P\LB3P!QRMD&NP'PQ9$>
M:AW%K2Z7/LO6:5)\ at TU=L*L9:0!J %0KGDI4P,C,R3!6RP4LE9I9S95/VQF]
MO!8:H\C0 X1L(VE* at XA\01K%3E]QG<N:*+A\&W!_&]$#U"%HP/#+F'KA&5 I
M&<T^!^_+*,R"RY$AOB':=O3+4,OV'\E].L55RXL<2LK,S$+%SLSNFQ?'7<N=
MR=O,9A5F+ at M-OB$E?9(!P$TB>0\"I@)D*%T&U)>-;',:L35Z4_)\ORGB'QBQ
ME+E>S9G,/<4K#]IV5AI!=BG-DAI$+BS-7<O5'MD\<PCW*XXI]#.XRO@<;R(E
M4 Y6W2 at RQ?8A.17;$$]UP@'='V53"<P<:Z\K_![H*A_+R<<5S(RTL@']&T=,
M=29 S(]+/\<J4%I0VG:7RS<H+ L?4YJ\<\BX5#V$3AW=!W)Z* #>S3G 2H$)
M(LK&Q!-QP+S-\BEZ&CS,_;U0LX2ZS\1#'4,E;,&G+=Q-NAR/S/<M(R9O3I=L
MX,Q=;L'(1E!7+"\&87:">E8P&)<05/(AFWWNP'JY%[V_>TC!L$_%5&@B,70'
M'PNT^E0X3&%[!L[U&=*\_,6"P%O,!TJEF6[-81Y at S/&;'VK;&<6M3\HXG8W,
M8FBG+ %KCE6V)U(>"2([:1G.?,C;!:0$%@'T*83 ^ M6'XG-L\<RS']RSX!<
M* V86H'PR"RRALS9=LD;/LT;S/0KDL!1(@?%^R,D($<$.\W-3%RPE<Q0*:O-
M)LVN>2 <),9IPZMV*<;O"2+-1QK4'H/);QUQOJ at R]#-B;(1,]#.X)W,F&FDO
M4M53$W/C(C'-!2Y54R50XGA['AT!9'=*>EMZ]#.R+.89FSFO'#%I(1P3'.+&
M5P*YOO89L372+P4N,Y9"QREI_<@I -L'P[]))7K,]AE.RGLOZAE"R5R[#2E'
M 5X:+QMHKF8C55,QS4TE:4RTA',L.RMP:UC 8Q]US1 $4G^&(%S M;MC;%@>
MC,=F(VM3FVTG17H>.,@<Q]1WP%4M5495SB==SLK,,\RRS6F=4AB[4W@;:(*V
MS69N95$KA+ F19PQS>IG2+\A<1EXB6H\NI4;U2HF&ZD<*G/04\<&>LAPS4%R
M!2&;SCT;CL>YQ44(N\6.)_,E.R)(EZ' :QLZS30>EE)X>_MXTBSESK\/10"-
M.BD:C,<P>;C%W[_0!)UHL7SV&2_%]!G[&<IO2K]8G_ EI _P".9"L at ZI*MD&
2)@=[A'8.$,\L!ZF$WPY/ +46
end
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00662;
3 Feb 95 4:23 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00656;
3 Feb 95 4:23 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01281;
3 Feb 95 4:23 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00624;
3 Feb 95 4:23 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00462;
3 Feb 95 4:10 EST
Received: from unet.Net.COM by CNRI.Reston.VA.US id aa01041; 3 Feb 95 4:10 EST
Received: from mac.net.com by unet.net.com (5.0/SMI-SVR4)
id AA02149; Fri, 3 Feb 1995 01:10:19 +0800
Message-Id: <9502030910.AA02149 at unet.net.com>
Date: 3 Feb 1995 09:04:48 U
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Angus Goldfinch <angus_goldfinch at mac.net.com>
Subject: Re: Severance of Relationsh
To: bsimpson at morningstar.com, ipng at sunroof.eng.sun.com
Cc: ietf at CNRI.Reston.VA.US
content-length: 794
Reply to: RE>>Severance of Relationships
Sounds like a useful way to inform people of what is going on to me.
--------------------------------------
Date: 2/2/95 3:09 pm
To: Angus Goldfinch
From: bsimpson at morningstar.com
> From: Brad Wilson <wilson at cps201.cps.cmich.edu>
> Come on ... what it REALLY necessary to make some people who PAY for email
> to read that you had quit? Twice?
>
8 times here! Now we know which mailing lists haven't thrown him off, yet.
> From: another user who apologized for accidentally sending it to the list
> Like, why do I care, you worthless little vandal?
My feelings, exactly.
Seems more like a commercial advertisement. Against our Acceptable Use
Policy. Let's all ask for his Delphi account to be closed.
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01384;
3 Feb 95 6:32 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01378;
3 Feb 95 6:32 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02886;
3 Feb 95 6:32 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01366;
3 Feb 95 6:32 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01327;
3 Feb 95 6:28 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa02825; 3 Feb 95 6:27 EST
Received: from monet.caad.ed.ac.uk by venera.isi.edu (5.65c/5.61+local-20)
id <AA08033>; Fri, 3 Feb 1995 03:11:07 -0800
Received: (from john at localhost) by monet.caad.ed.ac.uk (8.6.9/8.6.9) id KAA23258; Fri, 3 Feb 1995 10:54:07 GMT
Date: Fri, 3 Feb 1995 10:54:07 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Lee <john at caad.ed.ac.uk>
Message-Id: <199502031054.KAA23258 at monet.caad.ed.ac.uk>
To: IE-list at cs.ucl.ac.uk, ag-exp-l%ndsuvm1.BITNET at forsythe.stanford.edu,
agosta at sumex-aim.stanford.edu, ai-ed at sun.com,
ai-medicine at medmail.stanford.edu, ai-nat at adfa.oz.au,
ai-stats at watstat.uwaterloo.ca, aisb at cogs.sussex.ac.uk,
announcements.chi at xerox.com, arl at arl1.wustl.edu,
arpanet-bboard at mc.lcs.mit.edu, atm at bbn.com, ccrc at dworkin.wustl.edu,
cellular at dfv.rwth-aachen.de, cip at bbn.com, cnom at maestro.bellcore.com,
cogsci at cogsci.ed.ac.uk, cybsys-l at bingvmb.cc.binghamton.edu,
diagrams at cs.swarthmore.edu, elsnet-list at cogsci.edinburgh.ac.uk,
end2end-interest at isi.edu, enternet-ec at bbn.com, enternet at bbn.com,
f-troup at aurora.cis.upenn.edu, fj-ai at etl.go.jp, g-troup at dworkin.wustl.edu,
globecom at signet.com.sg, hipparch at sophia.inria.fr,
icad-request at santafe.edu, ietf at isi.edu, ikbsbb at inf.rl.ac.uk,
iplpdn at CNRI.Reston.VA.US, ircpeople at cogsci.ed.ac.uk, kdd at gte.com,
met-ai at comp.vuw.ac.nz, mmws at caad.ed.ac.uk, perform at tay1.dec.com,
rem-conf at es.net, schulzrinne at fokus.gmd.de, sig11 at roses.stanford.edu,
sigmedia at bellcore.com, smds at CNRI.Reston.VA.US, sound at acm.org,
tccc at cs.umass.edu, tcplw at cray.com, tf-mm at i4serv.informatik.rwth-aachen.de,
uist.chi at xerox.com, xtp-relay at cs.concordia.ca
Subject: FINAL reminder: IMMI-1 Workshop
There is STILL TIME to submit an extended abstract to IMMI-1;
the First International Workshop on Intelligence and Multimodality
in Multimedia Interfaces, Edinburgh, July 13-14, 1995.
For details see the (recently updated) Web information at --
http://www.cogsci.ed.ac.uk/~john/IMMI_call/index.html
-- or email to the address below.
Thanks again to all those who have already indicated their intention
to submit abstracts.
John.
---------------------------------------------------------------------------
John R. Lee
EdCAAD and Human Communication Research Centre
Dept. of Architecture University of Edinburgh
University of Edinburgh 2 Buccleuch Place
20 Chambers Street Edinburgh EH8 9LW
Edinburgh EH1 1JZ Scotland, UK.
Scotland, UK.
Tel: +44 131 650 2335/7 Tel: +44 131 650 4420
Fax: +44 131 667 0141 Fax: +44 131 667 4587
Email: J.Lee at ed.ac.uk
---------------------------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02741;
3 Feb 95 9:10 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02737;
3 Feb 95 9:10 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa05118;
3 Feb 95 9:10 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <IAA01360 at pad-thai.cam.ov.com>; Fri, 3 Feb 1995 08:19:17 -0500
Received: from inet-gw-1.pa.dec.com by MIT.EDU with SMTP
id AA29424; Fri, 3 Feb 95 08:16:20 EST
Received: from us1rmc.bb.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94)
id AA16950; Fri, 3 Feb 95 05:14:27 -0800
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA07436; Fri, 3 Feb 95 08:14:52 -0500
Message-Id: <9502031314.AA07436 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Fri, 3 Feb 95 08:14:52 EST
Date: Fri, 3 Feb 95 08:14:52 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 03-Feb-1995 0809" <wray at tuxedo.enet.dec.com>
To: dpg at ocsg.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, dpg at ocsg.com
Subject: RE: A difference in the use of channel bindings
>The difference is associated with the GSS-API function
>gss_accept_sec_context(). The GSS channel bindings
>passed to gss_accept_sec_context() are passed through
>to the function krb5_gss_accept_sec_context().
>There, if the bindings are not NULL, the binding's
>initiator address is used to verify the AP-REQ token's
>sender address.
>
>
>The draft specifies the channel binding's role in the GSS
>authenticator but not in address verification. Also,
>since krb5_gss_accept_sec_context() is using the
>initiator address to verify the token's sender address,
>the contents and byte ordering of channel bindings need
>to be specified.
Content and byte-ordering are specified in RFC 1509. Addresses should be
placed in the channel bindings data structure in network byte-order (big-endian
for IP addresses). RFC 1509 also says that mechanisms are allowed to (but not
required to) verify that the channel-bindings source address field is correct
if you supply one, and that an application should either supply a correct
address (in which case the Kerberos check would succeed), or a NULL_ADDR value
(which the mechanism should ignore).
I don't think the Kerberos GSSAPI draft needs to be changed, at least not for
interoperability or portability reasons.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05320;
3 Feb 95 11:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05314;
3 Feb 95 11:49 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12714;
3 Feb 95 11:49 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05304;
3 Feb 95 11:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05209;
3 Feb 95 11:46 EST
Received: from ub-gate.UB.com by CNRI.Reston.VA.US id aa12639;
3 Feb 95 11:46 EST
Received: from garfield (garfield.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.9.1])
id AA18465; Fri, 3 Feb 95 08:46:32 PST
Received: from smtp.UB.com ([128.203.7.39]) by garfield (4.1/SMI-4.1)
id AA16165; Fri, 3 Feb 95 08:46:23 PST
Return-Path: <Doug_Corner/UB_Networks at smtp.UB.com>
Received: by smtp.UB.com (IBM OS/2 SENDMAIL VERSION 1.3.0)/1.2)
id AA2203; Fri, 03 Feb 95 08:47:39 -0800
Message-Id: <9502031647.AA2203 at smtp.UB.com>
Received: from UB with "Lotus Notes Mail Gateway for SMTP" id
D7CC3A4213B510DC85256155007F16ED; Fri, 3 Feb 95 08:47:39
To: ietf <ietf at CNRI.Reston.VA.US>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Corner/UB Networks <Doug_Corner at ub.com>
Date: 3 Feb 95 11:54:10 EDT
Subject: Local implications of CIDR
Mime-Version: 1.0
Content-Type: Text/Plain
CIDR is primarily considered 1) An address assignment policy and 2) An
enhancement to external gateway protocols and is assumed not to have any
implications to local networks. Its implementation, however, does have some
significant consequences.
I would like to solicit comments on the following hypothetical situation.
A user has a bridged network of 600 users which performs well. The future,
under ATM and with modern ethernet switches, seems to be one of mostly bridging
locally where bandwidth is inexpensive. The user decides to connect to the
internet, applies for an address and is assigned four class C addresses. He
converts his internal applications to IP in order to have only one protocol to
manage. He finds now that he must install a local router in order for users to
communicate between different class C subnets even though they are on the same
physical network or are at the most separated by bridges. Because of the
necessity to communicate through a router he must now take two hops across his
backbone in order to send a packet. In an all IP network with mostly local
traffic, the backbone traffic will be doubled !!
It should be possible to use a mask of 255.255.252.0 which, in the spirit of
CIDR, would make all four subnets appear to the hosts as a single "Classless"
network. Hosts would decide that an address in any of the four class C
networks is local and would ARP and then forward the packet. In the case that
the destination address was off the local network the packet would be forwarded
to a router as usual. The router could even be configured with four separate
network numbers and a mask of 255.255.255.0. The problem is that essentially
every host implementation I have found refuses to allow a configuration of an
IP address with a Class C prefix and with a mask such that the host portion is
to the left of the last byte, e.g. an address of 194.130.64.5 with a mask of
255.255.252.0.
If there is any other way to handle this? If not, do we need an update to
RFC's governing host requirements and subnetting to allow this? It seems to
mostly a configuration and setup issue. It is hard to imagine that most stacks
do any kind of run time checking of classes and masks.
I would appreciate any feedback on this and would be very glad to hear that I
am wrong about the host software.
Douglas Corner
UB Networks, Consulting Services Group
1595 Springhill Road Suite 210
Vienna, VA 22182
(703) 448-1117
dcorner at ub.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06145;
3 Feb 95 12:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06141;
3 Feb 95 12:57 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15475;
3 Feb 95 12:57 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA06141 at pad-thai.cam.ov.com>; Fri, 3 Feb 1995 12:29:45 -0500
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA04062; Fri, 3 Feb 95 12:26:48 EST
Received: from krypton.mcc.com (krypton.mcc.com [128.62.30.63]) by turtle.mcc.com (8.6.9/mcc.8.6.9) with SMTP id LAA28253; Fri, 3 Feb 1995 11:26:12 -0600
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA29781; Fri, 3 Feb 95 11:26:11 CST
Date: Fri, 3 Feb 95 11:26:11 CST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9502031726.AA29781 at krypton.mcc.com>
To: linn at cam.ov.com
Cc: jis at mit.edu, linn at cam.ov.com, cat-ietf at mit.edu
In-Reply-To: <9502011259.AA17454 at winkl.cam.ov.com> (message from John Linn on Wed, 01 Feb 1995 07:59:08 -0500)
Subject: Re: Draft of revised CAT WG charter statement
> My opinion is that this is a valuable work area and, along with
> authorization extensions, a natural outgrowth from where we are today;
> I'd like CAT to address both of these as foci after we stabilize GSS-V2.
> (As a particular motivator, I think the idea of being able to use
> common credentials for association-oriented and store-and-forward
> services (for mechanisms capable of so doing) is powerful in terms
> of avoiding the need for users to log in multiple times for
> different purposes.) Rather than co-opting, I'd seek to complement
> and cooperate with related activities in other groups, wonder
> if this can be reflected in a non-inflammatory way, and hereby solicit
> thoughts from other interested WG participants.
I agree, although it seems like this would require a very close
relationship with the Object/Document Security (ios) WG.
- Doug
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06345;
3 Feb 95 13:02 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06336;
3 Feb 95 13:02 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15590;
3 Feb 95 13:02 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06315;
3 Feb 95 13:02 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06184;
3 Feb 95 13:00 EST
Received: from Valinor.BARRNET.NET by CNRI.Reston.VA.US id aa15508;
3 Feb 95 13:00 EST
Received: (from vaf at localhost) by valinor.barrnet.net (8.6.8/8.6.6) id KAA24718; Fri, 3 Feb 1995 10:00:20 -0800
Date: Fri, 3 Feb 95 10:00:19 PST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vince Fuller <vaf at valinor.barrnet.net>
To: Doug Corner/UB Networks <Doug_Corner at ub.com>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Phone: (415) 528-7227
USMail: 3801 East Bayshore Rd, Palo Alto, CA, 94303
Subject: Re: Local implications of CIDR
In-Reply-To: Your message of 3 Feb 95 11:54:10 EDT
Message-ID: <CMM.0.90.2.791834419.vaf at valinor.barrnet.net>
It should be possible to use a mask of 255.255.252.0 which, in the spirit
of CIDR, would make all four subnets appear to the hosts as a single
"Classless" network. Hosts would decide that an address in any of the four
class C networks is local and would ARP and then forward the packet. In
the case that the destination address was off the local network the packet
would be forwarded to a router as usual. The router could even be
configured with four separate network numbers and a mask of 255.255.255.0.
The problem is that essentially every host implementation I have found
refuses to allow a configuration of an IP address with a Class C prefix
and with a mask such that the host portion is to the left of the last byte,
e.g. an address of 194.130.64.5 with a mask of 255.255.252.0.
This is a bug in host implementations of IP addressing and is being documented
in the new Router Requirements RFC. There needs to be a similar revision of the
Host Requirements RFC. This is a well-known problem with many implementations
that vendors should be aware of by now and should be fixing - the code fix is
rather simple, since it involves removing some code which checks for proper
"class" of an address.
If there is any other way to handle this? If not, do we need an update to
RFC's governing host requirements and subnetting to allow this? It seems
to mostly a configuration and setup issue. It is hard to imagine that most
stacks do any kind of run time checking of classes and masks.
For some implementations, particularly those based on BSD, there are simple
workarounds for this problem. First, it is usually possible to add a route
with a metric of zero on such systems, which causes the host to ARP for any
address which matches a particular prefix. Using a SunOS system in your
example scenario, you would do the following:
ifconfig le0 194.130.64.5 netmask 255.255.255.0 broadcast 255.255.255.255
route add 194.130.65.0 194.130.64.5 0
route add 194.130.66.0 194.130.64.5 0
route add 194.130.67.0 194.130.64.5 0
which says that the all three of the "class-C" networks are local. Note that
It is very important that the all-ones broadcast be used in configurations
such as this one, as some systems using 194.130.64.255 and some using
194.130.65.255 (etc.) is an invitation for trouble.
For some implementations, it is also possible to tell the host to simply ARP
for all addresses and as long as the other hosts on your network are reasonably
well-behaved and any router you have that connects to other networks responds
correctly to proxy-ARP, this is an even simpler workaround. Again, using a
SunOS system, this would be configured as follows:
ifconfig le0 194.130.64.5 netmask 255.255.255.0 broadcast 255.255.255.255
route add default 194.130.64.5 0
which says that the "default" route should be considered local, i.e. try to
ARP for anything.
--Vince
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06437;
3 Feb 95 13:04 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06431;
3 Feb 95 13:04 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15632;
3 Feb 95 13:04 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06422;
3 Feb 95 13:04 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06308;
3 Feb 95 13:02 EST
Received: from stilton.cisco.com by CNRI.Reston.VA.US id aa15585;
3 Feb 95 13:02 EST
Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id KAA23039; Fri, 3 Feb 1995 10:02:49 -0800
X-Sender: fred at stilton.cisco.com
Message-Id: <v0211011fab581cf17f7b at [198.92.24.2]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 3 Feb 1995 10:02:52 -0800
To: Doug Corner/UB Networks <Doug_Corner at ub.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Fred Baker <fred at cisco.com>
Subject: Re: Local implications of CIDR
Cc: ietf <ietf at CNRI.Reston.VA.US>
At 11:54 AM 2/3/95, Doug Corner/UB Networks wrote:
>If there is any other way to handle this? If not, do we need an update to
>RFC's governing host requirements and subnetting to allow this? It seems to
>mostly a configuration and setup issue. It is hard to imagine that most
>stacks do any kind of run time checking of classes and masks.
There is no separate RFC for the way routers implement CIDR and the way
hosts do. Interest in the community has been in changing routers and
preserving hosts because there are more hosts than routers by far, routers
are far more likely to deal with supernets than hosts, and CIDR requires
revving routing protocols. The Router Requirements RFC references it and
Host Requirements doesn't primarily because RREQ was worked on later then
HREQ. Yes, HREQ needs to be updated, but the hosts can become conformant to
the CIDR documents without that happening.
I would suggest that you talk with the relevant vendors and see if patches
for their operating system might be forthcoming.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Top Ten Reasons Santa Didn't Come in '94
...
6. The sleigh has an "Intel Inside" sticker on it. 'Nuff said.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07455;
3 Feb 95 13:42 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16459;
3 Feb 95 13:42 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07420;
3 Feb 95 13:42 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07220;
3 Feb 95 13:34 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-heffernan-tcp-md5-00.txt
Date: Fri, 03 Feb 95 13:34:28 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502031334.aa07220 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : TCP MD5 Signature Option
Author(s) : A. Heffernan
Filename : draft-heffernan-tcp-md5-00.txt
Pages : 4
Date : 02/02/1995
This memo describes a TCP extension to enhance security for selected TCP
applications. It defines a new TCP option for carrying an MD5 digest in a
TCP segment. This digest acts like a signature for that segment,
incorporating information known only to the connection end points. Using
this option in the way described in this paper significantly reduces the
danger from security attacks on critical TCP applications on the Internet.
This document specifies an experimental protocol for use in the Internet.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-heffernan-tcp-md5-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-heffernan-tcp-md5-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-heffernan-tcp-md5-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950202110243.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-heffernan-tcp-md5-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-heffernan-tcp-md5-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950202110243.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07460;
3 Feb 95 13:42 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16456;
3 Feb 95 13:42 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07422;
3 Feb 95 13:42 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07329;
3 Feb 95 13:37 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: addrconf at cisco.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-addrconf-ipv6-auto-00.txt
Date: Fri, 03 Feb 95 13:37:37 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502031337.aa07329 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Address Autoconfiguration
Working Group of the IETF.
Title : IPv6 Address Autoconfiguration
Author(s) : S. Thomson
Filename : draft-ietf-addrconf-ipv6-auto-00.txt
Pages : 15
Date : 02/02/1995
This document specifies how a host autoconfigures one or more addresses per
interface. A host can form an intra-link scope address autonomously based
on information local to the host. A host can form an inter-link scope
address in two ways: either semi-autonomously, based on knowledge of subnet
prefixes advertised by routers, or by using DHCPv6. All mechanisms rely on
a host having a token per interface that is unique at least per subnet.
This document specifies how a host forms an intra-link scope address
autonomously and an inter-link scope address semi-autonomously using IEEE
802 tokens to identify each interface. DHCPv6 is described elsewhere.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-addrconf-ipv6-auto-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-addrconf-ipv6-auto-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-addrconf-ipv6-auto-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950202151247.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-addrconf-ipv6-auto-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-addrconf-ipv6-auto-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950202151247.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08199;
3 Feb 95 14:18 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08192;
3 Feb 95 14:18 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17217;
3 Feb 95 14:18 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08183;
3 Feb 95 14:18 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08108;
3 Feb 95 14:15 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa17186;
3 Feb 95 14:15 EST
Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-20)
id <AA25486>; Fri, 3 Feb 1995 11:15:51 -0800
Date: Fri, 3 Feb 1995 11:16:13 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: braden at isi.edu
Posted-Date: Fri, 3 Feb 1995 11:16:13 -0800
Message-Id: <199502031916.AA28760 at can.isi.edu>
Received: by can.isi.edu (5.65c/4.0.3-4)
id <AA28760>; Fri, 3 Feb 1995 11:16:13 -0800
To: Doug_Corner at ub.com, vaf at valinor.barrnet.net
Subject: Re: Local implications of CIDR
Cc: ietf at CNRI.Reston.VA.US
*>
*> This is a bug in host implementations of IP addressing and is being documented
*> in the new Router Requirements RFC. There needs to be a similar revision of the
*> Host Requirements RFC. This is a well-known problem with many implementations
*> that vendors should be aware of by now and should be fixing - the code fix is
*> rather simple, since it involves removing some code which checks for proper
*> "class" of an address.
*>
*> If there is any other way to handle this? If not, do we need an update to
*> RFC's governing host requirements and subnetting to allow this? It seems
*> to mostly a configuration and setup issue. It is hard to imagine that most
*> stacks do any kind of run time checking of classes and masks.
*>
Did I hear someone say "Host Requirements RFC"? Hello. Well, on page 32
of RFC-1122, under DISCUSSION, it says:
An architectural goal for Internet hosts was to allow
IP addresses to be featureless 32-bit numbers, avoiding
algoirthms that require a knowledge of the IP address
format. Otherwise, any future change in the format of
interpretation of IP addresses will require host
software changes. However, validation of broadcast
and multicast addreses violates this goal; a few other
violations are described elsewhere in this document.
BTW, Noel Chiappa was the person who urged this point in the HR WG.
Bob Braden
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09976;
3 Feb 95 15:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09971;
3 Feb 95 15:40 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19331;
3 Feb 95 15:40 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA09887 at pad-thai.cam.ov.com>; Fri, 3 Feb 1995 15:14:10 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA12781; Fri, 3 Feb 95 15:11:08 EST
Received: from dun-dun-noodles.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA09879 at pad-thai.cam.ov.com>; Fri, 3 Feb 1995 15:13:57 -0500
Received: by dun-dun-noodles.cam.ov.com (4.1/4.7) id AA11237; Fri, 3 Feb 95 15:13:55 EST
Message-Id: <9502032013.AA11237 at dun-dun-noodles.cam.ov.com>
To: "John Wray, Digital DPE,\
(508) 486-5210 02-Feb-1995 0913" <wray at tuxedo.enet.dec.com>
Cc: cat-ietf at mit.edu
Subject: Re: Anonymity by mechanism ?
In-Reply-To: Your message of "Thu, 02 Feb 1995 09:50:57 EST."
<9502021450.AA11994 at us1rmc.bb.dec.com>
Date: Fri, 03 Feb 1995 15:13:54 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> One other question is, is it worth changing? What sort of application would
>> request out-of-order notification, and still want to deal with out-of-order
>> packets?
An application might want to log the contents of out-of-order
requests. This might be useful to determine the details of a
probabilistic attack, or for something as mundane as debugging a
protocol where things are supposed to come in in order, but aren't.
You are entirely correct that some mechanisms would always return
GSS_S_BAD_SIG with sequencing errors, but I don't see this as a
problem.
I believe this addresses Dennis's concerns, too. One app's errors are
another app's signal :-)
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12266;
3 Feb 95 17:10 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12260;
3 Feb 95 17:10 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01889;
3 Feb 95 17:10 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12236;
3 Feb 95 17:10 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12093;
3 Feb 95 17:06 EST
Received: from fnal.fnal.gov by CNRI.Reston.VA.US id aa01769; 3 Feb 95 17:06 EST
Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998)
id <01HMMA5NS05C004MXS at FNAL.FNAL.GOV>; Fri, 03 Feb 1995 16:06:58 -0500 (CDT)
Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m)
id AA18769; Fri, 3 Feb 95 16:06:09 CST
Date: Fri, 03 Feb 1995 16:06:09 -0600
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Matt Crawford <crawdad at fnal.fnal.gov>
Subject: Re: Local implications of CIDR
In-reply-to: Your message of Fri,
03 Feb 95 11:54:10 -0400. <9502031647.AA2203 at smtp.UB.com>
X-Orig-Sender: crawdad at munin.fnal.gov
To: Doug Corner/UB Networks <Doug_Corner at ub.com>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Message-id: <9502032206.AA18769 at munin.fnal.gov>
Content-transfer-encoding: 7BIT
> A user has a bridged network of 600 users [...] and is assigned four class C
> addresses. He finds now that he must install a local router in
> order for users to communicate between different class C subnets even though
> they are on the same physical network or are at the most separated by
> bridges. Because of the necessity to communicate through a router he must
> now take two hops across his backbone in order to send a packet.
Not at all! Read on.
> It should be possible to use a mask of 255.255.252.0 [...]
That would be a nice way to do it, but it isn't in the major IP stacks.
One can, hoever, get the same effect as far as routing is concerned by
adding "interface routes" to the other three networks. Suppose that the
four Cs are 222.0.0.0 through 222.0.3.0. A hypothetical unix machine at
222.0.0.9 would be configured to know about the other three networks as
follows:
route add 222.0.1.0 222.0.0.9 0
route add 222.0.2.0 222.0.0.9 0
route add 222.0.3.0 222.0.0.9 0
I know the same thing can be done in VMS. I don't know enough about the
other common stacks to say whether they can do this, but if they can't,
it *ought* to be just a matter of time until they are updated to do so.
_________________________________________________________
Matt Crawford crawdad at fnal.gov Fermilab
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13414;
3 Feb 95 18:00 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03175;
3 Feb 95 18:00 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13390;
3 Feb 95 18:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13322;
3 Feb 95 17:57 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03083;
3 Feb 95 17:57 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13309;
3 Feb 95 17:57 EST
To: IETF-Announce: ;
Reply-to: mwalnut at CNRI.Reston.VA.US
Subject: IETF MAILING 1a: INTRO: April 3-7, 1995/Danvers, MA USA
Date: Fri, 03 Feb 95 17:57:07 -0500
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut <mwalnut at CNRI.Reston.VA.US>
Message-ID: <9502031757.aa13309 at IETF.CNRI.Reston.VA.US>
Dear IETFers:
Following this message (1a), you will receive four more listed below:
IETF MAILING 1b: IETF RSVP FORM. US$130.00 postmarked on or BEFORE Friday,
March 3, 1995. US$150.00 Registration postmarked after
Friday, March 3, 1995. Registration Forms will be
accepted via electronic mail and facsimile until 13:00 ET
on Thursday, March 30, 1995. Registration and payment
will be accepted on-site.
IETF MAILING 1c: AT-A-GLANCE. (In remote directories,
0mtg-at-a-glance-95apr.txt)
IETF MAILING 1d: DRAFT AGENDA. Please keep in mind that this in ONLY
a DRAFT and subject to frequent changes. A copy of the
Agenda is also available from the remote on-line
directories, cd ietf, get 0mtg-agenda.txt.
(In remote directories, 0mtg-agenda.txt)
The IETF Social has been scheduled for: TBD
IETF MAILING 1e: DRAFT MULTICAST SCHEDULE: NOT READY YET.
IETF MAILING 1f: Travel Directions. (In remote directories,
0mtg-traveldirections-95apr.txt)
NOTE: WE CANNOT STRESS THIS ENOUGH. Though we'd prefer to have a payment
of the meeting fee as soon as possible, we definitely want immediate
notification that you are planning on coming. So even though you know
that payment will be delayed for one reason or another, SEND THE RSVP
FORM IN ANYWAY.
ACCESS METHODS:
FTP
-----
IETF Information is available by anonymous FTP from several sites.
US East Coast Address: ds.internic.net (198.49.45.10)
US West Coast Address: ftp.isi.edu (128.9.0.32)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
cd ietf
ls *0mtg*
Gopher
-------
Information pertaining to the 32nd IETF is available on the Gopher
Server running on IETF.CNRI.RESTON.VA.US (132.151.1.35) under
"Internet Society / IETF / IETF Meetings / Danvers April 1995".
WWW
-------
<http://www.ietf.cnri.reston.va.us/home.html> Click on the link
for "meetings" and you should find an entry for the Danvers meeting.
NOTE: if the information in the files you select is missing or reflects
data from past meetings it is because the Danvers information has not
yet been copied to the ds.internic.net site. That is an automated
process and should take place shortly.
Thank You,
Megan
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13515;
3 Feb 95 18:03 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03269;
3 Feb 95 18:03 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13499;
3 Feb 95 18:03 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13451;
3 Feb 95 18:01 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03198;
3 Feb 95 18:01 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13445;
3 Feb 95 18:01 EST
To: IETF-Announce: ;
Reply-To: ietf-rsvp at CNRI.Reston.VA.US
Subject: IETF MAILING 1b: RSVP FORM: April 3-7, 1995/Danvers, MA USA
Date: Fri, 03 Feb 95 18:01:28 -0500
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut <mwalnut at CNRI.Reston.VA.US>
Message-ID: <9502031801.aa13445 at IETF.CNRI.Reston.VA.US>
REGISTRATION FORM
32nd Internet Engineering Task Force - Page 1 of 2
April 3-7, 1995
Danvers, Massachusetts
Please print or type:
Name (Mr/Dr/Ms)__________________________________________________________
Title____________________________________________________________________
Organization_____________________________________________________________
Address__________________________________________________________________
_________________________________________________________________________
City_____________________________State_____________Postal Code___________
Country__________________________________________________________________
Telephone______________________________Fax_______________________________
Email____________________________________________________________________
Do you plan to attend the Sunday, APRIL 2nd NEWCOMER'S ORIENTATION at
1630?
YES___ NO___
Do you plan to attend the Sunday, APRIL 2nd reception at 18:00?
YES___ NO___
The IETF Proceedings are available electronically. Would you
still like a hard copy?
YES___ NO ___
US$130.00 Registration postmarked on or BEFORE, Friday, March 3, 1995.
US$150.00 (US$130.00 + US$20.00 late fee) Registration postmarked after
Friday, March 3, 1995.
Method of payment: ___AMEX ___VISA ___MC ___Diners ___Check
(U.S. dollars, drawn on a U.S. Bank), payable to:
Corporation for National Research Initiatives
Account No.____________________________ Expiration Date__________________
Cardholder Name__________________________________________________________
Cardholder Signature_____________________________________________________
Registration Forms can be sent via electronic mail, facsimile, or postal mail:
Electronic: ietf-rsvp at cnri.reston.va.us
Facsimile: +1-703-620-0913
Postal: Corporation for National Research Initiatives
Accounting Department - 32nd IETF Meeting
1895 Preston White Drive, Suite 100
Reston, VA 22091-5434 USA
REGISTRATION FORM
32nd Internet Engineering Task Force - Page 2 of 2
April 3-7, 1995
Danvers, Massachusetts
IMPORTANT:
1. Payment MAY, but does NOT have to, accompany the Form.
2. Register ONE person per form. Substitutions are NOT allowed.
3. Include a completed Registration Form with payment.
4. Purchase orders are NOT accepted.
5. DD Form 1556 IS accepted.
6. We CANNOT invoice for payment.
7. Registration Forms will be accepted via electronic mail and
facsimile until 13:00 ET on Thursday, March 30, 1995.
8. Requests for refunds must be received by Thursday, March 30, 1995.
9. Refund policy: Refunds are subject to a US$20.00 service charge.
Late fees will not be refunded.
10. Your registration fee includes Sunday evening reception (cash bar),
and a daily continental breakfast and coffee breaks.
For additional information or assistance, please contact +1-703-620-8990,
+1-703-620-0913 (Fax) or ietf-rsvp at cnri.reston.va.us. Direct all inquiries
to: 32nd IETF Meeting - Danvers, Massachusetts.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13595;
3 Feb 95 18:06 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03364;
3 Feb 95 18:06 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13577;
3 Feb 95 18:06 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13549;
3 Feb 95 18:04 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03291;
3 Feb 95 18:04 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13541;
3 Feb 95 18:04 EST
To: IETF-Announce: ;
Reply-To: mwalnut at CNRI.Reston.VA.US
Subject: IETF MAILING 1c: AT-A-GLANCE: April 3-7, 1995/Danvers, MA USA
Date: Fri, 03 Feb 95 18:04:30 -0500
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut <mwalnut at CNRI.Reston.VA.US>
Message-ID: <9502031804.aa13541 at IETF.CNRI.Reston.VA.US>
32nd INTERNET ENGINEERING TASK FORCE Mailing Date : 2/3/95
AT-A-GLANCE Mailing Number: 1c
DATES: April 3-7, 1995 HOST(S):
Stev Knowles/FTP Software, Inc.
John Curran/NEARNET
HOTEL/MEETING SITE: Sheraton Danvers Hotel & Resort
50 Ferncroft Road
Danvers, Massachusetts 01923
Phone: 1 (508) 750-7950 or 1 (508) 777-2500
{fax: 508-750-7959}
CI 15:00; CO 12:00
300 Rooms reserved until Friday, March 3, 1995.
US$99.00/single; US$99.00/double
(please add 9.7% tax).
Specify: IETF Group
ADDITIONAL ACCOM: Colonial Hilton Hotel
Rte. 128/95 Audubon Road
Wakefield, Massachusetts 01880
Phone: 1 (617) 245-9300 {fax: 617-245-0842}
CI 15:00; CO 12:00
150 Rooms reserved until
US$99.00/single; US$S99.00/double
(please add 9.7% tax)
Specify: IETF Group
NEWCOMER'S Sunday, April 2, 1995
ORIENTATION: 16:30 - 17:30
Room: Ferncroft Center
PRE-REGISTRATION: Sunday, April 2, 1995
18:00 - 20:00 (reception)
Sheraton Tara Hotel & Resort
Room: Tara Ballroom
REGISTRATION: Monday, April 3, 1995
and BREAKS 08:00 - 18:00
Tuesday, April 4 - Thursday, April 6, 1995
08:30 - 18:00
Friday, April 7, 1995
08:30 - 1730
Sheraton Tara Hotel & Resort
Room: Tara I, II, III Foyer
TERMINAL ROOM: Tara IV
ATTENDANCE FEE: PAYMENT BY: Credit Card or Check
US$130.00 if registered BEFORE March 3, 1995
US$150.00 if registered AFTER March 3, 1995
AIRLINE: United Airlines (special rate roundtrip only)
1 (800) 521-4041 Meeting ID: 577ZL (IETF)
We regret that discounted fares are not
available for international flights
AIRPORT: Logan International Airport (Boston)
PARKING: Complimentary
SHUTTLE: Granada shuttle, reservations required.
US$17.00/one way US$31.00/roundtrip
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13859;
3 Feb 95 18:17 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03571;
3 Feb 95 18:17 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13821;
3 Feb 95 18:17 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13763;
3 Feb 95 18:14 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03504;
3 Feb 95 18:14 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13758;
3 Feb 95 18:14 EST
To: IETF-Announce: ;
Reply-To: mwalnut at CNRI.Reston.VA.US
Subject: IETF MAILING 1d: DRAFT AGENDA: April 3-7, 1995/Danvers, MA USA
Date: Fri, 03 Feb 95 18:14:06 -0500
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut <mwalnut at CNRI.Reston.VA.US>
Message-ID: <9502031814.aa13758 at IETF.CNRI.Reston.VA.US>
Folks,
Please note that there have been several structural changees to the
agenda. Session start and end times are a bit different (we've
extended the dinner hour!), and we've taken out some technical
presentation slots.
Megan
****32nd IETF: April 3-7, 1995/Danvers, Massachusetts****
PLEASE NOTE THE FOLLOWING:
1. NEWCOMER's ORIENTATION: On Sunday, April 3rd at 16:30 we will be
holding an orientation session for newcomers (Room: Ferncroft Center)
ALL FIRST TIME ATTENDEES ARE ENCOURAGED TO RETRIEVE AND READ
RFC 1718 BEFORE ATTENDING THE MEETING.*
Entitled "The Tao of IETF: A Guide for New Attendees of the Internet
Engineering Task Force", this RFC is available by anonymous FTP. Login
with the username "anonymous" and password "guest". After logging in,
Type "cd rfc". "get rfc1718.txt".
3. The Social Event will take place either Monday or Tuesday evening.
More information should be available shortly.
--------
FYI.....
A reminder that the quality of these meetings (and in
particular the Working Group technical *working* sessions) is
dependent upon the informed, constructive participation of the
individual attendees. Please come prepared.
Information on the current status and progress of the individual
Working Groups can be obtained in several ways:
1. Working Group objectives and notes from previous sessions are
available online (send to ietf-info at cnri.reston.va.us for retrieval
instructions).
2. Working Group objectives and notes from previous meetings are
also reproduced in the hardcopy Proceedings (to order, send to
proceedings at cnri.reston.va.us).
3. Agendas and reading lists for Working Group meetings will also be
posted to the respective Working Group mailing lists.
IF YOU HAVE QUESTIONS REGARDING THE SCHEDULING OF A PARTICULAR WORKING
GROUP, PLEASE CONTACT THE CHAIR OF THAT GROUP DIRECTLY. A LISTING OF
WORKING GROUP MAILING LISTS IS AVAILABLE VIA ANONYMOUS FTP, CD IETF,
GET "1wg-summary.txt".
Draft Agenda of the Thirty-Second IETF - as of 2/3/95 3:05pm
(April 3-7, 1995)
MONDAY, April 3, 1995
0800-0900 IETF Registration and Continental Breakfast
0900-0930 Introductions
0930-1130 Morning Sessions
USV uri Uniform Resource Identifers WG
Break
1300-1500 Afternoon Sessions I
APP html HyperText Markup Language WG
USV uswg User Services Working Group WG
1500-1530 Break (Refreshments provided)
1530-1730 Afternoon Sessions II
APP http HyperText Transfer Protocol WG
1930-2200 Evening Sessions
TUESDAY, April 4, 1995
0830-0900 Continental Breakfast
0900-1130 Morning Sessions
OPS prottest Protocol Testing BOF
TSV intserv Integrated Services WG
USV iiir Integration of Internet Information Resources WG
Break
1300-1500 Afternoon Sessions I
OPS ospf Open Shortest Path First IGP WG
MGT rmonmib Remote Network Monitoring WG
USV uri Uniform Resource Identifers WG
1500-1530 Break (Refreshments provided)
1530-1730 Afternoon Sessions II
APP html HyperText Markup Language WG
SEC cat Common Authentication Technology WG
1930-2200 Tuesday, April 4, 1995 - Evening Sessions
RTG rreq Routing Requirements WG
WEDNESDAY, April 5, 1995
0800-0900 Working Group Workshop
0830-0900 Continental Breakfast
0900-1130 Morning Sessions
APP quis Quality Information Services WG
INT pppext Point-to-Point Protocol Extension WG
Break
1300-1500 Afternoon Sessions I
APP asid Access/Synch. of the Internet Directories WG
APP mimesgml Standard Generalized Markup Language WG
MGT isdnmib ISDN MIB BOF
MGT rmonmib Remote Network Monitoring WG
1500-1530 Break (Refreshments provided)
1530-1730 Afternoon Sessions II
APP notary Notifications and Acknowledgements Requirements WG
SEC cat Common Authentication Technology WG
TSV rsvp Resource Reservation Setup Protocol WG
USV ids Integrated Directory Services WG
1930-2200 Wednesday, April 5, 1995 - Evening Session
GEN iab Internet Architecture Board
OPS cidrd CIDR Deployment WG
TSV intserv Integrated Services WG **
** might change
THURSDAY, April 6, 1995
0830-0900 Continental Breakfast
0900-1130 Morning Sessions
APP edi Electronic Data Interchange WG
Break
1300-1500 Afternoon Sessions I
APP mailext Mail Extensions WG
RTG sdr Source Demand Routing WG
SEC saag Security Area Advisory Group
TSV rsvp Resource Reservation Setup Protocol WG
1500-1530 Break (Refreshments provided)
1530-1630 Technical Presentations
1630-1830 Open Plenary and IESG
FRIDAY, April 7, 1995
0830-0900 Continental Breakfast
0900-1130 Morning Sessions
Break
1300-1500 Afternoon Sessions I
1500-1530 Break (No Refreshments)
1530-1730 Afternoon Sessions II
Key to Abbreviations
APP Applications Erik Huizer/SURFnet and
John Klensin/MCI
GEN General Interest
INT Internet Stev Knowles/FTP Software and
Claudio Topolcic/BBN
IPNG IP: Next Generation Scott Bradner/Harvard and
Allison Mankin/ISI
MGT Network Management Marshall T. Rose/DBC
OPS Operational Requirements Scott Bradner/Harvard and
Michael O'Dell/UUNET Technologies
RTG Routing Joel Halpern/Newbridge Networks
SEC Security Jeff Schiller/MIT
TSV Transport Allison Mankin/ISI
USV User Services Joyce K. Reynolds/ISI
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13942;
3 Feb 95 18:20 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03682;
3 Feb 95 18:20 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13925;
3 Feb 95 18:19 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13845;
3 Feb 95 18:17 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03561;
3 Feb 95 18:17 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13835;
3 Feb 95 18:17 EST
To: IETF-Announce: ;
Reply-To: mwalnut at CNRI.Reston.VA.US
Subject: IETF MAILING 1f: DIRECTIONS: April 3-7, 1995/Danvers, MA USA
Date: Fri, 03 Feb 95 18:17:17 -0500
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut <mwalnut at CNRI.Reston.VA.US>
Message-ID: <9502031817.aa13835 at IETF.CNRI.Reston.VA.US>
Directions for the 32nd IETF
April 3-7, 1995
Directions to the Sheraton Tara Hotel & Resort from Logan Intntl Airport.
=========================================================================
Take Route 1A North to Route 60 West to Route 1 North.
Stay on 1 North approx. 20 minutes. Route 1 North goes over I95, at
that point get in left lane and take Route 1 South exit (hotel is
visible at this point). After exiting onto Route 1 South take
your first right onto Ferncroft Road.
Total driving time with little traffic is 30 minutes.
Rush hour extends from 7-9am and 4-6:30pm on weekdays.
Sunday evening there is a fair amount of traffic.
Sheraton Tara Hotel & Resort
50 Ferncroft Road
Danvers, MA 01923
+1 508 777 2500
Directions to the Colonial Hilton Hotel from Logan International Airport.
========================================================================
Take Route 1A North to Route 60 West to Route 1 North.
Stay on Route 1 North approx. 10minutes.
Take 128 South to exit 42. Turn right at the end of
the exit and another right into hotel driveway.
Total driving time same as above.
Colonial Hilton Hotel
Route 128/95 Audubon road
Wakefield, MA 01880
+1 617 245 9300
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15966;
3 Feb 95 20:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15962;
3 Feb 95 20:55 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06088;
3 Feb 95 20:55 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <UAA15803 at pad-thai.cam.ov.com>; Fri, 3 Feb 1995 20:23:35 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA25840; Fri, 3 Feb 95 20:20:40 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <UAA15776 at pad-thai.cam.ov.com>; Fri, 3 Feb 1995 20:21:00 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA18719; Fri, 3 Feb 95 20:20:58 EST
Message-Id: <9502040120.AA18719 at winkl.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com, cadams at bnr.ca
Subject: Forwarding: Carlisle Adams' QOP Structure Proposal
Date: Fri, 03 Feb 1995 20:20:57 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Carlisle (cadams at bnr.ca) wrote to me:
>I've tried twice now to send this to the CAT group without success. I
>have no idea what the trouble might be, but I'd like to get it out
>sooner, rather than later. John, would you mind posting this for me?
...and I hereby forward.
--jl
- ---forwarded-message---->
1995 Feb 02 at 14:25
to: cat-ietf at mit.edu (BNR400)
from: Carlisle (C.M.) Adams :9C21 (BNR)
subject: A Proposed QOP Structure...
Hello everyone,
If I may be so bold, let me try to summarize, clarify, paraphrase, and
interpret some of the discussion which I have seen/heard regarding the
infamous QOP parameter of GSS-API.
- There are some who want to use it simply to specify particular
algorithms within a mechanism (e.g., for mechanism "x", a QOP of 5
means DES-CBC).
- There are some who want to use it in a more qualitative sense (e.g.,
for mechanism "x", a QOP of 5 means "STRONG").
- There are some who want it to be mechanism independent (e.g., for the
most "security-unconcious" application which knows nothing whatsoever
about algorithms and has specified DEFAULT for its mechanism
selection, a QOP of 5 still means "STRONG").
- There are some who want it to be used for confidentiality as well as
for integrity.
- There are some who agree that a QOP for confidentiality would be
useful, but would rather use a second QOP parameter (i.e., change
the existing GSS interface).
Complicating all of this somewhat is the fact that certain QOP values
have already been specified and implemented ("0" for DEFAULT and "1",
"2", and "3" in Kerberos V5).
Although I recognize that it is impossible to satisfy everyone, our
implementation of SPKM needs to do *something* with QOP, and it is
difficult to choose something while this whole area is so unsettled.
The following is our proposal. I'm submitting it to the group in
advance of finalizing the SPKM spec. so that if there is violent
objection (along with positive suggestions for improvement!) I can make
the neceessary adjustments before submitting the spec..
The proposal has a number of advantages. Namely, it satisfies all the
bullets above without conflicting with previously-defined QOP values or
requiring any change to the current GSS-API. It also (I believe) leaves
enough room for future expansion.
Unless I see great dissent over the next week or so, the following text
will appear in the SPKM spec. and will be implemented in our GSS
product.
8<----------------------------------------------------------------------
The QOP parameter for SPKM is defined to be a 32-bit unsigned integer
(an OM_uint32) with the following bit-field assignments:
Confidentiality Integrity
31 (MSB) 16 15 (LSB) 0
- ------------------------------------|-----------------------------------
| TS (5) | U(3) | IA (4) | MA (4) | TS (5) | U(3) | IA (4) | MA(4) |
- ------------------------------------|-----------------------------------
where
TS is a 5-bit Type Specifier (a semantic qualifier whose value
specifies the type of algorithm which may be used to protect the
corresponding token -- see below for details);
U is a 3-bit Unspecified field (available for future
use/expansion);
IA is a 4-bit field enumerating Implementation-specific
Algorithms; and
MA is a 4-bit field enumerating Mechanism-defined Algorithms.
The interpretation of the QOP parameter is as follows (note that the
same procedure is used for both the confidentiality and the integrity
halves of the parameter). The MA field is examined first. If it is
non-zero then the algorithm used to protect the token is the
mechanism-specified algorithm corresponding to that integer value.
If MA is zero then IA is examined. If this field value is non-zero
then the algorithm used to protect the token is the implementation-
specified algorithm corresponding to that integer value (if this
algorithm is available over the established context). Note that use
of this field may hinder portability since a particular value may
specify one algorithm in one implementation of the mechanism and may
not be supported or may specify a completely different algorithm in
another implementation of the mechanism.
Finally, if both MA and IA are zero then TS is examined. A value of
zero for TS specifies the mechanism-defined default algorithm for the
established context (confidentiality or integrity, depending on which
half of QOP is being examined). A non-zero value for TS corresponds
to a particular algorithm qualifier and selects the first algorithm
supported over the context which satisfies that qualifier (note that
"first" is also mechanism-defined).
The following TS values (i.e., algorithm qualifiers) are specified;
other values may be added in the future.
For the Confidentiality TS field:
00001 (1) = SPKM_SYM_ALG_STRENGTH_STRONG
00010 (2) = SPKM_SYM_ALG_STRENGTH_MEDIUM
00011 (3) = SPKM_SYM_ALG_STRENGTH_WEAK
For the Integrity TS field:
00001 (1) = SPKM_INT_ALG_NON_REPUDIABLE
00010 (2) = SPKM_INT_ALG_REPUDIABLE
Clearly, qualifiers such as strong, medium, and weak are debatable
and likely to change with time, but for the purposes of this version
of the specification we define these terms as follows. A
confidentiality algorithm is "weak" if the effective key length of
the cipher is 40 bits or less; it is "medium-strength" if the
effective key length is strictly between 40 and 80 bits; and it is
"strong" if the effective key length is 80 bits or greater. (Note
that "effective key length" describes the computational effort
required to break a cipher using the best-known cryptanalytic attack
against that cipher.)
A five-bit TS field allows up to 31 qualifiers for each of
confidentiality and integrity (since "0" is reserved for "default").
This document specifies three for confidentiality and two for
integrity, leaving a lot of room for future specification.
Suggestions of qualifiers such as "fast", "medium-speed", and "slow"
have been made, but such terms are difficult to quantify (and in any
case are platform- and processor-dependent), and so have been left
out of this initial specification. The intention is that the TS
terms be quantitative, environment-independent qualifiers of
algorithms, as much as this is possible.
Use of the QOP structure as defined above is ultimately meant to be
as follows.
- TS values are specified at the GSS-API level and are therefore
portable across mechanisms. Applications which know nothing about
algorithms are still able to choose "quality" of protection for
their message tokens.
- MA values are specified at the mechanism level and are therefore
portable across implementations of a mechanism. For example, all
implementations of the Kerberos V5 GSS mechanism must support
GSS_KRB5_INTEG_C_QOP_MD5 (value: 1)
GSS_KRB5_INTEG_C_QOP_DES_MD5 (value: 2)
GSS_KRB5_INTEG_C_QOP_DES_MAC (value: 3).
(Note that these Kerberos-specified integrity QOP values do not
conflict with the QOP structure defined above.)
- IA values are specified at the implementation level (in user
documentation, for example) and are therefore typically non-
portable. An application which is aware of its own mechanism
implementation and the mechanism implementation of its peer,
however, is free to use these values since they will be perfectly
valid and meaningful over that context and between those peers.
The receiver of a token must pass back to its calling application a
QOP parameter with all relevant fields set. For example, if
triple-DES has been specified by a mechanism as algorithm 8, then
a receiver of a triple-DES-protected token must pass to its
application (QOP Confidentiality TS=1, IA=0, MA=8). In this way,
the application is free to read whatever part of the QOP it
understands (TS or IA/MA).
------- End of Forwarded Message
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15976;
3 Feb 95 20:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15972;
3 Feb 95 20:55 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06093;
3 Feb 95 20:55 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <UAA15791 at pad-thai.cam.ov.com>; Fri, 3 Feb 1995 20:22:33 -0500
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA25745; Fri, 3 Feb 95 20:19:24 EST
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4 + 8.6.9, dpg hack 5dec94) with UUCP id RAA27273; Fri, 3 Feb 1995 17:16:45 -0800
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA20889; Fri, 3 Feb 95 17:06:51 -0800
Date: Fri, 3 Feb 95 17:06:51 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9502040106.AA20889 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: "John Wray, Digital DPE,\
(508) 486-5210 03-Feb-1995 0809" <wray at tuxedo.enet.dec.com>
Subject: Re: A difference in the use of channel bindings
Cc: cat-ietf at mit.edu
Reply-To: dpg at ocsg.com
> >The difference is associated with the GSS-API function
> >gss_accept_sec_context(). The GSS channel bindings
> >passed to gss_accept_sec_context() are passed through
> >to the function krb5_gss_accept_sec_context().
> >There, if the bindings are not NULL, the binding's
> >initiator address is used to verify the AP-REQ token's
> >sender address.
> >
> >
> >The draft specifies the channel binding's role in the GSS
> >authenticator but not in address verification. Also,
> >since krb5_gss_accept_sec_context() is using the
> >initiator address to verify the token's sender address,
> >the contents and byte ordering of channel bindings need
> >to be specified.
>
> Content and byte-ordering are specified in RFC 1509.
> Addresses should be placed in the channel bindings data
> structure in network byte-order (big-endian for IP
> addresses). RFC 1509 also says that mechanisms are
> allowed to (but not required to) verify that the
> channel-bindings source address field is correct if you
> supply one, and that an application should either supply
> a correct address (in which case the Kerberos check would
> succeed), or a NULL_ADDR value (which the mechanism
> should ignore).
>
The draft specifies how channel bindings are used to
construct and verify a GSS authenticator. The
*implication* is that it is a redefinition of how channel
bindings are used in the Kerberos mechanism, not that it
is *in addition* to RFC-1509's specification. Either
address verification is or is not part of the Kerberos
mechanism, the draft should be clear.
> I don't think the Kerberos GSSAPI draft needs to be
> changed, at least not for interoperability or
> portability reasons.
>
This is an open issue. At least two CAT documents state
portability is one of their goals: RFC-1508 and the draft
Windows bindings. I don't believe issues bordering the
religious -- such as K&R vs ANSI C or Pepsi vs Coke -- is in
the spirt of the GSS-API but I do beleive
interoperability is.
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17688;
3 Feb 95 22:34 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17682;
3 Feb 95 22:34 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07340;
3 Feb 95 22:34 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17673;
3 Feb 95 22:34 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17634;
3 Feb 95 22:32 EST
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa07315;
3 Feb 95 22:32 EST
Received: by ginger.lcs.mit.edu
id AA04265; Fri, 3 Feb 95 22:32:39 -0500
Date: Fri, 3 Feb 95 22:32:39 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9502040332.AA04265 at ginger.lcs.mit.edu>
To: ietf at CNRI.Reston.VA.US
Subject: Re: Local implications of CIDR
Cc: jnc at ginger.lcs.mit.edu
From: Vince Fuller <vaf at valinor.barrnet.net>
> The problem is that essentially every host implementation I have found
> refuses to allow a configuration of an IP address with a Class C prefix
> and with a mask such that the host portion is to the left of the last
> byte, e.g. an address of 194.130.64.5 with a mask of 255.255.252.0.
This is a bug in host implementations of IP addressing ... This is a
well-known problem with many implementations that vendors should be aware
of by now and should be fixing - the code fix is rather simple, since it
involves removing some code which checks for proper "class" of an address.
As Bob Braden noted, this general approach ("IP addresses to be featureless
32-bit numbers") was something we were looking forward to - although obviously
without knowing about CIDR - at the time the Host Requirements RFC's were
done. It was done precisely to allow maximum flexibility in changing around
the way IP addressing worked, since it was obvious changes were going to have
to happen.
However, suggestions for the exact same scheme ("subnet" masks larger than a
classical network number) has been around for years, predating (if memory
serves) the Host Reqmts RFC, in the form of Carl-Hubert Rokitansky's clever
"cluster addressing" scheme (which he originally brought up to solve certain
problems in using IP over X.25 PDN's). So there was ample prior evidence of
a reasonable use for this feature.
While I understand the goals of host vendors in putting those checks in (to
find bogus configs), it's too bad they didn't put in a switch allowing the
check to be bypassed when it got in the way of legitimate uses. This would
have allowed painless evolution to the "featureless 32-bit numbers". Oh well,
no use crying about split milk now.
Hopefully there's a lesson for the future to be learned here, though: put in
flexibility wherever you reasonably can, even if you don't always know how
it's going to be used.
Also, those who say there's no such thing as an art of "large scale system
design", or the profession of "system architect" who applies them, ought to
look at this example. It was precisely by applying those design principles
that this path was pointed out. Too bad people didn't listen.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06101;
4 Feb 95 21:23 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06095;
4 Feb 95 21:23 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13855;
4 Feb 95 21:23 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06071;
4 Feb 95 21:23 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05977;
4 Feb 95 21:12 EST
Received: from rip.psg.com by CNRI.Reston.VA.US id aa13702; 4 Feb 95 21:12 EST
Received: by rip.psg.com (Smail3.1.29.1 #3)
id m0rawTE-00030KC; Sat, 4 Feb 95 18:13 PST
Message-Id: <m0rawTE-00030KC at rip.psg.com>
Date: Sat, 4 Feb 95 18:13 PST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Randy Bush <randy at psg.com>
To: namedroppers <namedroppers at internic.net>, ietf <ietf at CNRI.Reston.VA.US>
Subject: dnsind/dynupd interim 94.02.08 Stanford, new venue
Bob has found a place for us from which we can MBONE. What's even more
amazing is that there is parking, which is almost as scarce as water in
Califonia. :-)
Thanks, Bob.
Date: Sat, 4 Feb 95 16:03:02 -0800
From: RL "Bob" Morgan <morgan at networking.stanford.edu>
To: randy at psg.com (Randy Bush)
Subject: Re: meeting moving to med school
The meeting location is Room X303, Medical School Office Building, at the
corner of Campus Drive and Welch Road. Note that MSOB is a few buildings
west of the main part of the Stanford Medical Center. Referring to the
campus map (http://www.stanford.edu/map/campus-map.html) it's in section
C6. The most likely parking is in the large parking lot across Welch Road
from MSOB. We will have one-day parking stickers available for attendees.
We will try to start at 08:30, and go until dinnertime. We can scatter and
scrounge for lunch, or I know were to do a run to get take out burritos or
whatever.
What have I forgotten?
randy
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15357;
5 Feb 95 2:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15351;
5 Feb 95 2:33 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17793;
5 Feb 95 2:33 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15341;
5 Feb 95 2:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15300;
5 Feb 95 2:31 EST
Received: from post.demon.co.uk by CNRI.Reston.VA.US id aa17751;
5 Feb 95 2:31 EST
Received: from hedgehog.demon.co.uk by post.demon.co.uk id ac19554;
5 Feb 95 7:31 GMT
Received: by hedgehog.demon.co.uk (V1.16/Amiga)
id AA0007k; Sat, 4 Feb 95 11:30:27 GMT
Date: Sat, 4 Feb 95 11:30:27 GMT
Message-Id: <9502041130.AA0007j at hedgehog.demon.co.uk>
In-Reply-To: <9502040332.AA04265 at ginger.lcs.mit.edu>
Organization: Hedgehog Software
X-MailViewer: Mail 1.15
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Niall Teasdale <niall at hedgehog.demon.co.uk>
To: ietf at CNRI.Reston.VA.US
Subject: Host Requirements (Re: Local implications of CIDR)
I followed this discussion with interest since it seems to
reflect some of the opinions I've formed while looking into
various implementations of TCP/IP, and it reflects a
discussion I had in the comp.sys.amiga.networking
newsgroup. It would appear that most of the major vendors
don't follow Host Requirements.
Am I right? Does anyone know of an implementation that
actually does follow the STDs to the letter? And does it
interoperate with anything else?
I'd be interested to hear your opinions.
Niall.
--
~==========================================================================~
Niall Teasdale - niall at hedgehog.demon.co.uk
Hedgehog Software (at home) - Cogsys Ltd (at work)
PGP key available on request or from public key servers.
Any views expressed above are mine, and mine alone.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00764;
6 Feb 95 5:43 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00758;
6 Feb 95 5:43 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02038;
6 Feb 95 5:43 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00712;
6 Feb 95 5:43 EST
Received: from nw.com by IETF.CNRI.Reston.VA.US id aa00619; 6 Feb 95 5:28 EST
Received: from localhost (mkl at localhost) by nw.com (8.6.5/8.6.5) id CAA00254 for ietf at ietf.cnri.reston.va.us; Mon, 6 Feb 1995 02:30:07 -0800
Date: Mon, 6 Feb 95 2:30:07 PST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark Lottor <mkl at nw.com>
To: ietf at IETF.CNRI.Reston.VA.US
Subject: Internet Domain Survey, January 1995
Message-ID: <CMM.0.90.4.792066607.mkl at nw.com>
Internet Domain Survey Network Wizards January 1995
The Domain Survey attempts to discover every host on the Internet by doing
a complete search of the Domain Name System. The latest results gathered
during late January 1995 are listed. For more information see RFC 1296;
-- Mark Lottor
FOR THE COMPLETE REPORT AND RELATED INFO SEE:
http://www.nw.com
or
ftp://ftp.nw.com/zone
Number of Hosts, Domains, and Nets Advertised in the Domain Name System
Replied Network Class
Date | Hosts Domains ToPing* A B C
------+-----------------------------------------------------
Jan 95| 4,852,000 71,000 970,000 91 4979 34340
Oct 94| 3,864,000 56,000 1,024,000 93 4831 32098
Jul 94| 3,212,000 46,000 707,000 89 4493 20628
Apr 94| -N/A-
Jan 94| 2,217,000 30,000 576,000 74 4043 16422
Oct 93| 2,056,000 28,000 69 3849 12615
Jul 93| 1,776,000 26,000 464,000 67 3728 9972
Apr 93| 1,486,000 22,000 421,000 58 3409 6255
Jan 93| 1,313,000 21,000 54 3206 4998
[* estimated by pinging 1% of all hosts]
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02183;
6 Feb 95 9:23 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02177;
6 Feb 95 9:23 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05624;
6 Feb 95 9:23 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02166;
6 Feb 95 9:23 EST
Received: from note1.nsf.gov by IETF.CNRI.Reston.VA.US id aa02098;
6 Feb 95 9:19 EST
Received: from [128.150.55.4] (sgoldste.cise.nsf.gov) by note1.nsf.gov with SMTP id AA26404
(5.65c/IDA-1.4.4 for <ietf at IETF.CNRI.Reston.VA.US>); Mon, 6 Feb 1995 09:20:52 -0500
X-Sender: sgoldste at 128.150.11.1
Message-Id: <ab5bca3c0202100458b3 at [128.150.55.4]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 6 Feb 1995 09:19:45 -0500
To: Mark Lottor <mkl at nw.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Goldstein <sgoldste at nsf.gov>
Subject: Re: Internet Domain Survey, January 1995
Cc: ietf at IETF.CNRI.Reston.VA.US
>
> FOR THE COMPLETE REPORT AND RELATED INFO SEE:
> http://www.nw.com
> or
Everything about this page and the pages that flow from it is fresh and COOL!
The art.net started my Monday with warmth. BRAVO, Mark! --Steve G.
================================================================
Steven N. Goldstein
Program Director, Interagency & International Networking Coordination
Div. of Networking and Communications Research & Infrastructure
National Science Foundation
4201 Wilson Boulevard, Room 1175
Arlington, VA 22230
Tel: +1-703-306-1949 (Extension 1119)
FAX: +1-703-306-0621
sgoldste at NSF.GOV
================================================================
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03187;
6 Feb 95 10:29 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03183;
6 Feb 95 10:29 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa07023; 6 Feb 95 10:29 EST
Received: (from slist at localhost) by merit.edu (8.6.9/merit-2.0) id KAA17485; Mon, 6 Feb 1995 10:23:14 -0500
Resent-Date: Mon, 6 Feb 1995 10:23:14 -0500
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pppext-ipcp-00.txt
Date: Mon, 06 Feb 95 10:16:52 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502061016.aa03016 at IETF.CNRI.Reston.VA.US>
Resent-Message-ID: <"HmkaU3.0.4H4.SxZDl"@merit.edu>
Resent-From: ietf-ppp at merit.edu
X-Mailing-List: <ietf-ppp at MERIT.EDU> archive/latest/80
X-Loop: ietf-ppp at MERIT.EDU
Precedence: list
Resent-Sender: ietf-ppp-request at merit.edu
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : The PPP Internet Protocol Control Protocol (IPCP)
Author(s) : G. McGregor, G. Pall
Filename : draft-ietf-pppext-ipcp-00.txt
Pages : 14
Date : 02/03/1995
The Point-to-Point Protocol (PPP) [1] provides a standard method of
encapsulating Network Layer protocol information over point-to-point links.
PPP also defines an extensible Link Control Protocol, and proposes a family
of Network Control Protocols (NCPs) for establishing and configuring
different network-layer protocols.
This document defines the NCP for establishing and configuring the Internet
Protocol [2] over PPP, and a method to negotiate and use Van Jacobson
TCP/IP header compression [3] with PPP.
This document is a product of the Point-to-Point Protocol Working Group
of the Internet Engineering Task Force (IETF).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pppext-ipcp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-ipcp-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-ipcp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950203115949.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-ipcp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-ipcp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950203115949.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06973;
6 Feb 95 13:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06967;
6 Feb 95 13:50 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11348;
6 Feb 95 13:50 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06946;
6 Feb 95 13:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06806;
6 Feb 95 13:46 EST
Received: from halloran-eldar.lcs.mit.edu by CNRI.Reston.VA.US id aa11239;
6 Feb 95 13:46 EST
Received: by halloran-eldar.lcs.mit.edu; id AA26813; Mon, 6 Feb 1995 13:46:26 -0500
Date: Mon, 6 Feb 1995 13:46:26 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Garrett Wollman <wollman at halloran-eldar.lcs.mit.edu>
Message-Id: <9502061846.AA26813 at halloran-eldar.lcs.mit.edu>
To: Doug Corner/UB Networks <Doug_Corner at ub.com>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Subject: Local implications of CIDR
In-Reply-To: <9502031647.AA2203 at smtp.UB.com>
References: <9502031647.AA2203 at smtp.UB.com>
<<On 3 Feb 95 11:54:10 EDT, Doug Corner/UB Networks <Doug_Corner at ub.com> said:
> to a router as usual. The router could even be configured with four
> separate network numbers and a mask of 255.255.255.0. The problem
> is that essentially every host implementation I have found refuses
> to allow a configuration of an IP address with a Class C prefix and
> with a mask such that the host portion is to the left of the last
> byte, e.g. an address of 194.130.64.5 with a mask of 255.255.252.0.
Get your vendors to fix their software. (We believe FreeBSD gets it
right, and so should other 4.4-derived systems.)
-GAWollman
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wollman at lcs.mit.edu | Shashish is the bonding of hearts in spite of distance.
Opinions not those of| It is a bond more powerful than absence. We like people
MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09223;
6 Feb 95 15:42 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09218;
6 Feb 95 15:41 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14080;
6 Feb 95 15:41 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA12854 at pad-thai.cam.ov.com>; Mon, 6 Feb 1995 15:02:49 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA22308; Mon, 6 Feb 95 14:59:40 EST
Received: from dun-dun-noodles.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA12844 at pad-thai.cam.ov.com>; Mon, 6 Feb 1995 15:02:29 -0500
Received: by dun-dun-noodles.cam.ov.com (4.1/4.7) id AA11686; Mon, 6 Feb 95 15:02:26 EST
Message-Id: <9502062002.AA11686 at dun-dun-noodles.cam.ov.com>
To: dpg at ocsg.com
Cc: John Linn <linn at cam.ov.com>, cat-ietf at mit.edu
Subject: Re: A difference in the use of channel bindings
In-Reply-To: Your message of "Thu, 02 Feb 1995 11:44:31 PST."
<9502021944.AA19359 at war04.ocsg.com>
Date: Mon, 06 Feb 1995 15:02:26 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> The draft specifies the channel binding's role in the GSS
>> authenticator but not in address verification.
I agree with John Wray that the current use of channel bindings is
correct in the spirit of rfc1509, even if it is not specifically set
out in the krb5 mech draft. In the interest of reducing ambiguity,
I'd say that adding wording to the draft explaining the use of the
channel bindings in address verification would be a good thing. Of
course, if no channel bindings are provided to gss_accept_sec_context,
then no verification would be performed.
>> Also, since krb5_gss_accept_sec_context() is using the initiator
>> address to verify the token's sender address, the contents and byte
>> ordering of channel bindings need to be specified.
The contents, including format and byte order, are described in
section 1.1 of the draft.
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20405;
6 Feb 95 23:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20391;
6 Feb 95 23:46 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22109;
6 Feb 95 23:46 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <XAA27943 at pad-thai.cam.ov.com>; Mon, 6 Feb 1995 23:18:43 -0500
Received: from x400gate.bnr.ca by MIT.EDU with SMTP
id AA20575; Mon, 6 Feb 95 23:15:33 EST
X400-Received:
by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 6 Feb 1995 23:08:46 -0500
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 6 Feb 1995 17:21:48 -0500
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 6 Feb 1995 17:19:00 -0500
Date: Mon, 6 Feb 1995 17:19:00 -0500
X400-Originator: /dd.id=1651623/g=carlisle/i=cm/s=adams/@bnr.ca
X400-Mts-Identifier:
[/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.656:06.01.95.22.21.48]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: Draft of ...
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "carlisle (c.m.) adams" <cadams at bnr.ca>
X-Orig-Sender: "carlisle (c.m.) adams" <cadams at bnr.ca>
Message-Id: <"630 Mon Feb 6 17:21:59 1995"@bnr.ca>
To: linn at cam.ov.com
Cc: cat-ietf at mit.edu, "warwick (w.s.) ford" <wford at bnr.ca>,
"dragan (d.) grebovich" <dragan at bnr.ca>,
"alex (a.d.) brown" <alex at bnr.ca>, jis at mit.edu
Subject: Re: Draft of revised CAT WG charter statement
Hi,
>Jeff writes:
>
>>I don't have a problem with designing GSS-API mechanisms that are designed
>>for use in store and forward situations. However stating explicitly the the
>>WG charter gives the appearence of attempting to co-opt this area of work.
>>In other words I believe that the group can address store and forward
>>mechanisms, but would rather not go into such detail in the charter itself.
>
>I'm concerned that this approach could lead to a future conflict.
>We have a current I-D in the CAT WG, draft-ietf-cat-iop-gss-00.txt,
>which was presented at the December meeting, directly related to
>this topic. Issues were raised in discussion, and I expect that
>we'll see an updated I-D and follow-up debate. If the WG reaches
>consensus on a version of this document, and recommends it for
>advancement to Proposed Standard, would the fact of its topic
>being absent from our agreed charter create a problem at the IESG?
>
>My opinion is that this is a valuable work area and, along with
>authorization extensions, a natural outgrowth from where we are today;
>I'd like CAT to address both of these as foci after we stabilize GSS-V2.
>(As a particular motivator, I think the idea of being able to use
>common credentials for association-oriented and store-and-forward
>services (for mechanisms capable of so doing) is powerful in terms
>of avoiding the need for users to log in multiple times for
>different purposes.) Rather than co-opting, I'd seek to complement
>and cooperate with related activities in other groups, wonder
>if this can be reflected in a non-inflammatory way, and hereby solicit
>thoughts from other interested WG participants.
>
It seems clear to me that store-and-forward mechanisms fall under the scope
of "generic security services", and therefore within the mandate of the CAT
group. That is why I submitted the IOP draft to CAT as opposed to anywhere
else. I recognize that the new (if formed) IOS group and perhaps other
groups as well have an interest in similar work. Co-operation among all
such groups should be pursued strongly, but I think what John said is
correct: leaving it out of the charter completely could possibly lead to
conflict or problems in the future.
Carlisle.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab03102;
7 Feb 95 11:39 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03098;
7 Feb 95 11:39 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07747;
7 Feb 95 11:39 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <KAA14705 at pad-thai.cam.ov.com>; Tue, 7 Feb 1995 10:50:19 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA00404; Tue, 7 Feb 95 10:47:22 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <KAA14693 at pad-thai.cam.ov.com>; Tue, 7 Feb 1995 10:50:17 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA19720; Tue, 7 Feb 95 10:50:16 EST
Message-Id: <9502071550.AA19720 at winkl.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Kerberos V5 mechanism: tightening statements
Date: Tue, 07 Feb 1995 10:50:15 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
I'm trying to get the Kerberos V5 mechanism document ready for
a new I-D version based on recent discussion. Would inclusion of
the following statements be unacceptable to anyone or be in conflict
with existing implementations?
(1) A statement that address checks shall be performed against
input channel bindings on context establishment, unless the
caller passes GSS_C_NO_BINDINGS: i.e., requiring the ability
for an implementation to perform the address checking?
(2) A statement that implementations shall not perform per-message
replay or out-of-sequence detection if the caller of
GSS_Init_sec_context() passes FALSE to replay_det_req_flag and
sequence_req_flag, respectively: i.e, tightening the concept
of making provision of these services optional from the current
"highly recommended" status to a requirement?
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03838;
7 Feb 95 12:37 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03832;
7 Feb 95 12:37 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08978;
7 Feb 95 12:37 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA17286 at pad-thai.cam.ov.com>; Tue, 7 Feb 1995 12:10:18 -0500
Received: from Sun.COM by MIT.EDU with SMTP
id AA11695; Tue, 7 Feb 95 12:07:20 EST
Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
id AA09612; Tue, 7 Feb 95 09:07:01 PST
Received: from jurassic.Eng.Sun.COM (jurassic-248.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA07621; Tue, 7 Feb 1995 09:06:57 -0800
Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id JAA15269; Tue, 7 Feb 1995 09:06:52 -0800
Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id JAA17645; Tue, 7 Feb 1995 09:06:47 -0800
Date: Tue, 7 Feb 1995 09:06:47 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <199502071706.JAA17645 at elrond.Eng.Sun.COM>
To: cat-ietf at mit.edu
Subject: Re: Kerberos V5 mechanism: tightening statements
Cc: linn at cam.ov.com
X-Sun-Charset: US-ASCII
> From linn at cam.ov.com Tue Feb 7 08:09:59 1995
> To: cat-ietf at mit.edu
> Cc: linn at cam.ov.com
> Subject: Kerberos V5 mechanism: tightening statements
>
> I'm trying to get the Kerberos V5 mechanism document ready for
> a new I-D version based on recent discussion. Would inclusion of
> the following statements be unacceptable to anyone or be in conflict
> with existing implementations?
>
> (1) A statement that address checks shall be performed against
> input channel bindings on context establishment, unless the
> caller passes GSS_C_NO_BINDINGS: i.e., requiring the ability
> for an implementation to perform the address checking?
>
> (2) A statement that implementations shall not perform per-message
> replay or out-of-sequence detection if the caller of
> GSS_Init_sec_context() passes FALSE to replay_det_req_flag and
> sequence_req_flag, respectively: i.e, tightening the concept
> of making provision of these services optional from the current
> "highly recommended" status to a requirement?
>
> --jl
>
>
John,
Number 2 sounds great to me.
Dan
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04175;
7 Feb 95 12:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04171;
7 Feb 95 12:50 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09209;
7 Feb 95 12:50 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA17565 at pad-thai.cam.ov.com>; Tue, 7 Feb 1995 12:19:53 -0500
Received: from inet-gw-3.pa.dec.com by MIT.EDU with SMTP
id AA13051; Tue, 7 Feb 95 12:16:38 EST
Received: from us1rmc.bb.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94)
id AA10180; Tue, 7 Feb 95 09:06:31 -0800
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA07086; Tue, 7 Feb 95 12:06:20 -0500
Message-Id: <9502071706.AA07086 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Tue, 7 Feb 95 12:06:20 EST
Date: Tue, 7 Feb 95 12:06:20 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 07-Feb-1995 1130" <wray at tuxedo.enet.dec.com>
To: linn at cam.ov.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, linn at cam.ov.com
Subject: RE: Kerberos V5 mechanism: tightening statements
John,
>I'm trying to get the Kerberos V5 mechanism document ready for
>a new I-D version based on recent discussion. Would inclusion of
>the following statements be unacceptable to anyone or be in conflict
>with existing implementations?
>
>(1) A statement that address checks shall be performed against
>input channel bindings on context establishment, unless the
>caller passes GSS_C_NO_BINDINGS: i.e., requiring the ability
>for an implementation to perform the address checking?
I presume you mean "... unless the caller omits the source address field,
supplying GSS_C_NULL_ADDRTYPE for the source address-type...", as opposed to
omitting the channel bindings entirely?
I don't see a good reason to strengthen the requirements here. Address checks
don't really buy any security (since it's easy enough to fake the source
address as reported by the network), and may not be possible in many cases (if
the Kerberos token client-address field allows use from any address). If
you're operating in a multi-protocol environment (e.g. DCE), the address under
which you obtained the Keberos token may well be different (and most likely
drawn from an entirely different address family) to the address from which you
want to authenticate yourself.
If you feel that it's necessary for portability to mandate something in this
area, I'd strongly favor _prohibiting_ address verification, rather than
mandating it. I don't feel that any tightening is needed however - RFC-1509
does say that applications should use their correct address if they supply any
source address, so in single-address environments where address-verification is
reasonable it'll succeed, whereas in multiple-address environments it won't be
performed, so it won't fail.
>(2) A statement that implementations shall not perform per-message
>replay or out-of-sequence detection if the caller of
>GSS_Init_sec_context() passes FALSE to replay_det_req_flag and
>sequence_req_flag, respectively: i.e, tightening the concept
>of making provision of these services optional from the current
>"highly recommended" status to a requirement?
If we tighten this up, we should also state what happens when you do request
either replay or out-of-sequence detection. Does requesting either get you
both (and mutual authentication too, since we don't have any way of indicating
one-way security properties)?
The DCE Kerberos/GSSAPI implementation automatically gives you
message-sequencing (and therefore mutual authentication) whether or not you ask
for it. In retrospect, this may have been a bad decision, although one that is
unlikely to negatively affect any applications running over a
connection-oriented transport, and one that might even allow careless
applications to "fail-secure".
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06007;
7 Feb 95 14:19 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05998;
7 Feb 95 14:19 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11006;
7 Feb 95 14:19 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05943;
7 Feb 95 14:19 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05632;
7 Feb 95 14:00 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10597;
7 Feb 95 13:59 EST
Received: from relay1.pipex.net by venera.isi.edu (5.65c/5.61+local-20)
id <AA21011>; Tue, 7 Feb 1995 11:00:13 -0800
Received: from carmen.logica.co.uk by bath.pipex.net with SMTP (PP); Tue, 7 Feb 1995 19:00:01 +0000
Received: by carmen.logica.co.uk (4.1/SMI-4.1)
id AA22298; Tue, 7 Feb 95 19:01:16 GMT
Newsgroups: info.ietf
Path: news
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dirk Fieldhouse <Fieldhouse at logica.com>
Subject: Absent hosts? (was: Re: Internet Domain Survey, January 1995)
Message-Id: <D3n8u2.H6x at carmen.logica.co.uk>
X-Orig-Sender: News Manager Account <news at carmen.logica.co.uk>
Nntp-Posting-Host: pg039-wct.logica.co.uk
Organization: Logica plc - "These are just my opinions."
X-Newsreader: WinVN 0.93.10
References: <CMM.0.90.4.792066607.mkl at nw.com>
Date: Tue, 7 Feb 1995 19:01:13 GMT
Apparently-To: info-ietf at pipex.net
In article <CMM.0.90.4.792066607.mkl at nw.com>, mkl at nw.com says...
>
>[-- snip --]
>
> Number of Hosts, Domains, and Nets Advertised in the Domain Name System
>
> Replied Network Class
> Date | Hosts Domains ToPing* A B C
> ------+-----------------------------------------------------
> Jan 95| 4,852,000 71,000 970,000 91 4979 34340
>
> Oct 94| 3,864,000 56,000 1,024,000 93 4831 32098
>
>[-- snip --]
>
> [* estimated by pinging 1% of all hosts]
So why is the RepliedToPing value down by 300,000?
Was the survey by any chance conducted on Jan 2, or in the first week of
January?
Or have firewalls suddenly appeared all over the Internet?
--
Dirk Fieldhouse
fieldhouse at logica.com
c=gb;a=tmailuk;p=logica;
o=lg;ou1=lgwct;s=fieldhouse
+44 (171) 637 9111
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06350;
7 Feb 95 14:32 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11492;
7 Feb 95 14:32 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06321;
7 Feb 95 14:32 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05966;
7 Feb 95 14:18 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: sgml-internet at ebt.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mimesgml-multipart-rel-00.txt
Date: Tue, 07 Feb 95 14:18:20 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502071418.aa05966 at IETF.CNRI.Reston.VA.US>
--NextPart
Note: This announcement is being re-sent with a new filename.
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MIME and SGML Working Group
of the IETF.
Title : The MIME Multipart/Related Content-type
Author(s) : E. Levinson, H. Alvestrand
Filename : draft-ietf-mimesgml-multipart-rel-00.txt
Pages : 6
Date : 02/06/1995
The Multipart/Related content-type provides a common mechanism for
representing objects that are aggregates of related MIME body parts.
This document defines the Multipart/Related content-type and provides
examples of its use.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mimesgml-multipart-rel-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mimesgml-multipart-rel-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mimesgml-multipart-rel-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950206163831.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mimesgml-multipart-rel-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mimesgml-multipart-rel-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950206163831.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07032;
7 Feb 95 15:08 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12147;
7 Feb 95 15:08 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07004;
7 Feb 95 15:07 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06913;
7 Feb 95 15:03 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ip-atm at matmos.hpl.hp.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ipatm-ipmc-04.txt
Date: Tue, 07 Feb 95 15:03:05 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502071503.aa06913 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Over Asynchronous Transfer
Mode Working Group of the IETF.
Title : Support for Multicast over UNI 3.1 based ATM Networks.
Author(s) : G. Armitage
Filename : draft-ietf-ipatm-ipmc-04.txt
Pages : 36
Date : 02/06/1995
This memo describes a Multicast Address Resolution Server (MARS)
architecture that allows ATM based IP hosts to support RFC 1112 style Level
2 IP multicast using the ATM Forum's UNI 3.1 point to multipoint connection
service. It also describes how this architecture can be generalized to
support other protocols wishing to multicast over UNI 3.1 based ATM
service.
[Editorial note: The differences between this version and 03.txt are
substantial in the area of multicast server support. This impacts on
Chapter 8, and anything referring to MARS_MSERV. Two control VCs have been
identified and named, two sequence numbers are now used, and three
major appendices have been added discussing issues that cannot at this time
be standardized. The MARS_JOIN/LEAVE message format has been extended by
32 bits, and modified to support multiple address groups. Scattered
editorial/clarificatory changes have been made to the rest of the document.
Editorial notes will be removed.]
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipatm-ipmc-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipatm-ipmc-04.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipatm-ipmc-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950206153508.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipatm-ipmc-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipatm-ipmc-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950206153508.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07249;
7 Feb 95 15:15 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07245;
7 Feb 95 15:15 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12311;
7 Feb 95 15:15 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <OAA21762 at pad-thai.cam.ov.com>; Tue, 7 Feb 1995 14:24:22 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA00983; Tue, 7 Feb 95 14:21:25 EST
Received: from dun-dun-noodles.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <OAA21757 at pad-thai.cam.ov.com>; Tue, 7 Feb 1995 14:24:14 -0500
Received: by dun-dun-noodles.cam.ov.com (4.1/4.7) id AA00368; Tue, 7 Feb 95 14:24:13 EST
Message-Id: <9502071924.AA00368 at dun-dun-noodles.cam.ov.com>
To: "John Wray, Digital DPE,\
(508) 486-5210 07-Feb-1995 1130" <wray at tuxedo.enet.dec.com>
Cc: linn at cam.ov.com, cat-ietf at mit.edu
Subject: Re: Kerberos V5 mechanism: tightening statements
In-Reply-To: Your message of "Tue, 07 Feb 1995 12:06:20 EST."
<9502071706.AA07086 at us1rmc.bb.dec.com>
Date: Tue, 07 Feb 1995 14:24:13 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
(Take two. John Wray, take your email admin out back and shoot him :-)
>> I presume you mean "... unless the caller omits the source address field,
>> supplying GSS_C_NULL_ADDRTYPE for the source address-type...", as opposed to
>> omitting the channel bindings entirely?
I think that address verification would not occur in either case.
>> If you feel that it's necessary for portability to mandate something
>> in this area, I'd strongly favor _prohibiting_ address verification,
>> rather than mandating it. I don't feel that any tightening is needed
>> however - RFC-1509 does say that applications should use their correct
>> address if they supply any source address, so in single-address
>> environments where address-verification is reasonable it'll succeed,
>> whereas in multiple-address environments it won't be performed, so it
>> won't fail.
As you have pointed out, whether or not address verification makes
sense is an application concern. If IP security is in use, or the
environment is a small trusted LAN, then trusting IP addresses may be
legitimate. Also, an application will tend to know if it is running
in a multiprotocol environment. I believe that the spec should
require that *mechanisms* perform address verification if a source
address is passed in by the application, leaving the *application*
free to omit the channel bindings if it considers this level of
security to be irrelevant. I'm also not sure that this is a
krb5-specific issue, although clarification in the mechanism document
is a good thing.
I believe the general model here should be to provide as much security
as possible, turning off security features only when the application
requests doing so.
>(2) A statement that implementations shall not perform per-message
>replay or out-of-sequence detection if the caller of
>GSS_Init_sec_context() passes FALSE to replay_det_req_flag and
>sequence_req_flag, respectively: i.e, tightening the concept
>of making provision of these services optional from the current
>"highly recommended" status to a requirement?
This seems more like a generic issue than a krb5-specific issue, and
my objection is on this basis. A mechanism which uses cipher chaining
cannot turn off replay or sequence detection, since the underlying
crypto requires it. However, since each req flag has a corresponding
ret flag, an application can easily tell if a mechanism is honoring
its requests. I'd say the current requirement is fine, since an
application can fail out if the particular mechanism implementation is
not providing the features the application needs.
Marc
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07658;
7 Feb 95 15:41 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12952;
7 Feb 95 15:41 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07643;
7 Feb 95 15:41 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06941;
7 Feb 95 15:04 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ospf at gated.cornell.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ospf-demand-02.txt
Date: Tue, 07 Feb 95 15:04:18 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502071504.aa06941 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Open Shortest Path First IGP
Working Group of the IETF.
Title : Extending OSPF to support demand circuits
Author(s) : J. Moy
Filename : draft-ietf-ospf-demand-02.txt
Pages : 32
Date : 02/06/1995
This memo defines enhancements to the OSPF protocol that allow efficient
operation over "demand circuits". Demand circuits are network segments
whose costs vary with usage; charges can be based both on connect time and
on bytes/packets transmitted. Examples of demand circuits include ISDN
circuits, X.25 SVCs, and dial-up lines. The periodic nature of OSPF routing
traffic has until now required a demand circuit's underlying data-link
connection to be constantly open, resulting in unwanted usage charges. With
the modifications described herein, OSPF Hellos and the refresh of OSPF
routing information are suppressed on demand circuits, allowing the
underlying data-link connections to be closed when not carrying
application traffic.
Demand circuits and regular network segments (e.g., leased lines)
are allowed to be combined in any manner. In other words, there are
no topological restrictions on the demand circuit support. However, while
any OSPF network segment can be defined as a demand circuit, only
point-to-point networks receive the full benefit. When broadcast and NBMA
networks are declared demand circuits, routing update traffic is reduced
but the periodic sending of Hellos is not, which in effect still requires
that the data-link connections remain constantly open.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ospf-demand-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-demand-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ospf-demand-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950206161327.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-demand-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-demand-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950206161327.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07819;
7 Feb 95 15:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07815;
7 Feb 95 15:55 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13207;
7 Feb 95 15:55 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA23377 at pad-thai.cam.ov.com>; Tue, 7 Feb 1995 15:13:37 -0500
Received: from Sun.COM by MIT.EDU with SMTP
id AA07795; Tue, 7 Feb 95 15:10:38 EST
Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
id AA18209; Tue, 7 Feb 95 12:10:29 PST
Received: from jurassic.Eng.Sun.COM (jurassic-248.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA29579; Tue, 7 Feb 1995 12:10:21 -0800
Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id MAA22911; Tue, 7 Feb 1995 12:10:01 -0800
Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id MAA17808; Tue, 7 Feb 1995 12:09:55 -0800
Date: Tue, 7 Feb 1995 12:09:55 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <199502072009.MAA17808 at elrond.Eng.Sun.COM>
To: wray at tuxedo.enet.dec.com, marc at cam.ov.com
Subject: Re: Kerberos V5 mechanism: tightening statements
Cc: linn at cam.ov.com, cat-ietf at mit.edu
X-Sun-Charset: US-ASCII
> From marc at cam.ov.com Tue Feb 7 11:53:35 1995
> To: "John Wray, Digital DPE,
> (508) 486-5210 07-Feb-1995 1130" <wray at tuxedo.enet.dec.com>
> Cc: linn at cam.ov.com, cat-ietf at mit.edu
> Subject: Re: Kerberos V5 mechanism: tightening statements
[text deleted]
> This seems more like a generic issue than a krb5-specific issue, and
> my objection is on this basis. A mechanism which uses cipher chaining
> cannot turn off replay or sequence detection, since the underlying
> crypto requires it. However, since each req flag has a corresponding
> ret flag, an application can easily tell if a mechanism is honoring
> its requests. I'd say the current requirement is fine, since an
> application can fail out if the particular mechanism implementation is
> not providing the features the application needs.
>
> Marc
>
Marc,
I'm not sure what you mean. Your argument suggests it is a mechanism specific
issue. That is, if a mechanism, such as one based on cipher chaining, can't
turn off replay or out-of-sequence checking, then its mechanism specific
document should specify that. What John is suggesting is it should be
mandatory for Kerberos V5 to honor both replay_det_req_flag and
sequence_req_flag.
Regards,
Dan
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08213;
7 Feb 95 16:21 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13847;
7 Feb 95 16:21 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08196;
7 Feb 95 16:21 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07200;
7 Feb 95 15:12 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-simpson-ipv6-discov-process-02.txt
Date: Tue, 07 Feb 95 15:12:54 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502071512.aa07200 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IPv6 Neighbor Discovery -- Processing
Author(s) : W. Simpson
Filename : draft-simpson-ipv6-discov-process-02.txt
Pages : 47
Date : 02/06/1995
This document discusses the implementation techniques for identification of
and forwarding to adjacent IPv6 nodes, including Next Hop Determination and
Router Discovery.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-simpson-ipv6-discov-process-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-simpson-ipv6-discov-process-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-simpson-ipv6-discov-process-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950206164633.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-simpson-ipv6-discov-process-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-simpson-ipv6-discov-process-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950206164633.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03875;
8 Feb 95 12:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03869;
8 Feb 95 12:50 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08849;
8 Feb 95 12:50 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <LAA24183 at pad-thai.cam.ov.com>; Wed, 8 Feb 1995 11:33:52 -0500
Received: from inet-gw-1.pa.dec.com by MIT.EDU with SMTP
id AA27628; Wed, 8 Feb 95 11:30:44 EST
Received: from us1rmc.bb.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94)
id AA29826; Wed, 8 Feb 95 08:21:21 -0800
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA15855; Wed, 8 Feb 95 11:21:46 -0500
Message-Id: <9502081621.AA15855 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Wed, 8 Feb 95 11:21:47 EST
Date: Wed, 8 Feb 95 11:21:47 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 08-Feb-1995 0959" <wray at tuxedo.enet.dec.com>
To: marc at cam.ov.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, marc at cam.ov.com
Subject: Re: Kerberos V5 mechanism: tightening statements
>>> I presume you mean "... unless the caller omits the source address field,
>>> supplying GSS_C_NULL_ADDRTYPE for the source address-type...", as opposed to
>>> omitting the channel bindings entirely?
>
>>I think that address verification would not occur in either case.
Yes, I just want to make sure the spec explicitly covers both cases.
>As you have pointed out, whether or not address verification makes
>sense is an application concern. If IP security is in use, or the
>environment is a small trusted LAN, then trusting IP addresses may be
>legitimate. Also, an application will tend to know if it is running
>in a multiprotocol environment.
I disagree that the application would necessarily know, and I think it harms
application portability to force it to care. It's more a matter of system
policy. For example, in some environments, all machines might have a single IP
address, and the network policy would say that no "good-anywhere" tickets will
be issued. In such an environment, address-checking makes sense, so the
applications would have to supply a source-address via the channel bindings, as
that's the only way that the mechanism can find out the claimed client address
to perform the check. However, if we make address-verification a mandatory
part of the spec, this sort of application would break when moved into a
multi-address or multi-protocol environment.
That goes against the application portability goal of GSSAPI, particularly
when, by making the check optional, the implementation could do the right
thing, depending on its environment.
>I believe the general model here should be to provide as much security
>as possible, turning off security features only when the application
>requests doing so.
I agree, but "..as much security as possible.." is sometimes dependent on the
environment. We should allow applications to be written to take advantage of
security features if they are present, but not break if they're not.
Perhaps the spec should require address-verification if a source address is
presented in the channel bindings and if restrictions on client addresses are
present in the Kerberos token, but should also explicitly state that it is not
mandatory for implementations to use restricted-address tokens (and that no
address checks are to be performed on tokens without restrictions). That would
allow applications to use the source-address bindings field, thereby gaining
some security in environments where it makes sense, but without worrying that
doing so might retrict their portability.
We've been concentrating on the use of the client address field at the
context-acceptor side; how about at the initiator's side? Do we want GSSAPI to
verify that the address supplied is one of the valid host addresses of the
system, and reject the init_sec_context call if not? Should the
initiator-supplied address be put into the KRB_TGS_REQ as the sole requested
host-address, or should it be left up to the implementation to determine an
appropriate list of client addresses (which if we mandate address checking at
the acceptor should include the initiator's presented address)? What if the
client-presented address isn't in the list of valid addresses in the client's
TGT? Given that the channel bindings mechanism forces the same address to be
presented at initiator and acceptor, it is much more application-friendly to
let the initiator know if there's going to be a problem, rather than to
generate a token that isn't going to be usable.
I think there's more to this issue than simply saying "address checks shall be
performed". If we do need to mandate something, I think we need to do more
work first.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08234;
8 Feb 95 18:08 EST
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa08230;
8 Feb 95 18:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15328;
8 Feb 95 18:08 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <RAA06055 at pad-thai.cam.ov.com>; Wed, 8 Feb 1995 17:17:59 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA19930; Wed, 8 Feb 95 17:12:54 EST
Received: from dun-dun-noodles.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <RAA06034 at pad-thai.cam.ov.com>; Wed, 8 Feb 1995 17:15:50 -0500
Received: by dun-dun-noodles.cam.ov.com (4.1/4.7) id AA03646; Wed, 8 Feb 95 17:15:45 EST
Message-Id: <9502082215.AA03646 at dun-dun-noodles.cam.ov.com>
To: "John Wray, Digital DPE,\
(508) 486-5210 08-Feb-1995 0959" <wray at tuxedo.enet.dec.com>
Cc: cat-ietf at mit.edu
Subject: Re: Kerberos V5 mechanism: tightening statements
In-Reply-To: Your message of "Wed, 08 Feb 1995 11:21:47 EST."
<9502081621.AA15855 at us1rmc.bb.dec.com>
Date: Wed, 08 Feb 1995 17:15:44 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> That goes against the application portability goal of GSSAPI, particularly
>> when, by making the check optional, the implementation could do the right
>> thing, depending on its environment.
I think I see the fundamental disagreement between us. We both
believe that there is a need for differing levels of security even
within a mechanism, depending on the environment. Where we differ is
in where the determination and implementation of these differing
levels should occur. You believe that the determination and
implementation should be in the gssapi mechanism. I believe that the
determination should be in the application, and the implementation
should be in the mechanism.
I believe that determination belongs in the application for several
reasons:
1) Policy can vary from application to application within a site. If
the mechanism implementation determines policy, then either you need
hints from the application (which brings you back to what I want), or
you lose this flexibility.
2) Implementations of a given mechanism should be interchangeable.
In fact, entire mechanisms should be interchangeable. If policy is
determined the mechanism, than every mechanism needs to have policy
hooks in it. If determination is done by the application, and passed
in a standard way to the mechanism, implementations and mechanisms can
be freely switched around.
IMHO, GSSAPI is intended to eliminate the need for applications to
understand the specifics of particular cryptographic and key
management systems. It is not intended to remove the need for
application designers to consider what sort of environment in which
the application operates, nor is it intended to remove the need for
application designers to consider what level of security measures are
appropriate for the application.
I believe that a mechanism such as the krb5 mechanism should be
completely deterministic (with the exception that defaults may be
implementation-defined). This means that if I pass in a set of
explicit arguments (no defaults) the results should be identical
between implementations.
If you disagree with this, then we need to ask the larger group what
they all think, because I think that either your view or mine needs to
be adopted, and we could argue forever.
I think a suitable compromise is to allow non-"real" mechanisms to be
more flexible in their implementations. In particular, one could
conceive of a "policy mechanism" with its own OID, which would sit
alongside a real mechanism (or a negotiation mechanism!), interpreting
defaults and other "application"-defined inputs to the real mechanism
according to local policy considerations. In this way, I might layer
an application from one vendor, a policy mechanism, developed and/or
configured locally, and a real mechanism from another vendor to form a
complete system which is appropriate to my site's needs.
Marc
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa08575;
8 Feb 95 18:27 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15645;
8 Feb 95 18:27 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08548;
8 Feb 95 18:27 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08343;
8 Feb 95 18:17 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: idmr at cs.ucl.ac.uk
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-idmr-pim-mib-01.txt
Date: Wed, 08 Feb 95 18:17:04 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502081817.aa08343 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Multicast
Routing Working Group of the IETF.
Title : Protocol Independent Multicast MIB
Author(s) : K. McCloghrie, D. Farinacci
Filename : draft-ietf-idmr-pim-mib-01.txt
Pages : 16
Date : 02/07/1995
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
the Protocol Independent Multicast (PIM) protocol [5,6]. This MIB module
is applicable to IP multicast routers which implement PIM.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-idmr-pim-mib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-pim-mib-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-idmr-pim-mib-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950207125711.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-pim-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-pim-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950207125711.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa08622;
8 Feb 95 18:30 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15708;
8 Feb 95 18:30 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08604;
8 Feb 95 18:30 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08321;
8 Feb 95 18:16 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: idmr at cs.ucl.ac.uk
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-idmr-multicast-routmib-01.txt
Date: Wed, 08 Feb 95 18:16:31 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502081816.aa08321 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Multicast
Routing Working Group of the IETF.
Title : IP Multicast Routing MIB
Author(s) : K. McCloghrie, D. Farinacci
Filename : draft-ietf-idmr-multicast-routmib-01.txt
Pages : 17
Date : 02/07/1995
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
IP Multicast Routing [5], independent of the specific multicast routing
protocol [6,7] in use. Managed objects specific to particular multicast
routing protocols are specified elsewhere.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-idmr-multicast-routmib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-multicast-routmib-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-idmr-multicast-routmib-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950207125032.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-multicast-routmib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-multicast-routmib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950207125032.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa08779;
8 Feb 95 18:41 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15886;
8 Feb 95 18:41 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08760;
8 Feb 95 18:41 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08171;
8 Feb 95 18:02 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: idmr at cs.ucl.ac.uk
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-idmr-igmp-mib-01.txt
Date: Wed, 08 Feb 95 18:02:18 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502081802.aa08171 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Multicast
Routing Working Group of the IETF.
Title : Internet Group Management Protocol MIB
Author(s) : K. McCloghrie, D. Farinacci
Filename : draft-ietf-idmr-igmp-mib-01.txt
Pages : 12
Date : 01/07/1995
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
the Internet Group Management Protocol (IGMP). All of this MIB module is
applicable to IP multicast routers [6,7]; a subset is applicable to hosts
implementing IGMP [5].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-idmr-igmp-mib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-igmp-mib-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-idmr-igmp-mib-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950207124453.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-igmp-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-igmp-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950207124453.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04742;
9 Feb 95 12:05 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04738;
9 Feb 95 12:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08853;
9 Feb 95 12:05 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <KAA03249 at pad-thai.cam.ov.com>; Thu, 9 Feb 1995 10:58:12 -0500
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA18587; Thu, 9 Feb 95 10:55:13 EST
Received: from krypton.mcc.com (krypton.mcc.com [128.62.30.63]) by turtle.mcc.com (8.6.9/mcc.8.6.9) with SMTP id JAA14917; Thu, 9 Feb 1995 09:53:54 -0600
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA14724; Thu, 9 Feb 95 09:53:52 CST
Date: Thu, 9 Feb 95 09:53:52 CST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9502091553.AA14724 at krypton.mcc.com>
To: marc at cam.ov.com
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
In-Reply-To: <9502082215.AA03646 at dun-dun-noodles.cam.ov.com> (message from Marc Horowitz on Wed, 08 Feb 1995 17:15:44 -0500)
Subject: Re: Kerberos V5 mechanism: tightening statements
Marc> I think a suitable compromise is to allow non-"real"
Marc> mechanisms to be more flexible in their implementations. In
Marc> particular, one could conceive of a "policy mechanism" with
Marc> its own OID, which would sit alongside a real mechanism (or
Marc> a negotiation mechanism!), interpreting defaults and other
Marc> "application"-defined inputs to the real mechanism according
Marc> to local policy considerations. In this way, I might layer
Marc> an application from one vendor, a policy mechanism,
Marc> developed and/or configured locally, and a real mechanism
Marc> from another vendor to form a complete system which is
Marc> appropriate to my site's needs.
Wrt Marc's suggestion above, I wonder if the proposed "context QOP"
parameter for context establishment (that I mentioned in the mechanism
negotiation summary) could incorporate "policy" choices as well.
E.g., perhaps the address-verification issue could be addressed
through this context parameter.
Here's the relevant paragraph from the summary; also, it has been
suggested that this be called a "profile" or "quality of service
(QOS)" parameter rather than QOP.
> It is recommended that a QOP parameter be added to the context
> establishment functions, in the same manner as the QOP parameter
> currently supported by the message protection functions. This
> parameter may be used to influence the mechanism negotiation process,
> or to refine some aspect of context establishment after a mechanism
> has been selected. In the latter case, interpretation and use of the
> QOP value would be mechanism-dependent. For example, if a SPKM
> mechanism is selected, the QOP value could indicate whether to use RSA
> or Diffie-Hellman for key establishment. If a Kerberos mechanism is
> selected, the QOP value could determine whether a unique,
> connection-specific session key (i.e. subsession key) is generated
> during the authentication process.
- Doug
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05196;
9 Feb 95 12:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05192;
9 Feb 95 12:40 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09586;
9 Feb 95 12:40 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA05172 at pad-thai.cam.ov.com>; Thu, 9 Feb 1995 12:04:52 -0500
Received: from timbuk.cray.com by MIT.EDU with SMTP
id AA23299; Thu, 9 Feb 95 11:29:38 EST
Received: from sdiv.cray.com (ironwood.cray.com [128.162.21.36]) by timbuk.cray.com (8.6.9/CRI-fence-1.4) with SMTP id KAA00863; Thu, 9 Feb 1995 10:29:36 -0600
Received: from poplar020 by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA10338; Thu, 9 Feb 1995 10:29:35 -0600
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Grace Wiechman <gw at ironwood.cray.com>
Received: by poplar020 (5.0/btd-b3)
id AA05895; Thu, 9 Feb 1995 10:29:35 -0600
Message-Id: <9502091629.AA05895 at poplar020>
Subject: FTP security extensions
To: cat-ietf at mit.edu
Date: Thu, 9 Feb 1995 10:29:34 -0600 (CST)
Cc: sjogren at tgv.com
X-Mailer: ELM [version 2.4 PL24-CRI-b]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2314
I came across a problem with encrypted and safe proxy transfers that
should be addressed in the draft for FTP security transfers. The
implementation was with Kerberos V4 on Cray Research UNICOS.
During proxy transfers, the two servers attempt to send data to
each other. The data is encrypted using the krb_mk_safe or
krb_mk_priv. The service key that is used to encrypt the data
is that from the FTP client. When the data is sent to the proxy
server, the decryption fails because the data is encrypted with
the FTP client's session key, not the session key for the proxy
server. Proxy transfers succeed if the control connection
between the two servers is the same machine. (But why would
you want to do this in the first place?)
Prior to the exchange the control connections are set to private
or safe on both machine B and machine C.
The exchanges are as follows:
ftpd (machine B) ftp (machine A) ftpd (proxy) (machine C)
------------- ------------------ -------------------
proxy get filename
PASV ------>
<----- P:C:227 Entering Passive Mode
(xxx,xxx,xxx,x,x,xxx)
<---- PORT (xxx,xxx,xxx,x,x,xxx)
P:B:200 PORT command
successful. --->
<---- RETR filename
P:B:Opening BINARY mode
data connection for
filename (xxx bytes)
----> STOR filename
At this point, ftpd on machine B runs the file through krb_mk_priv,
and sends the file to machine C on the control connection. The krb_rd_priv
on machine C fails, because the data is encrypted with the session key
for the machine A to machine B connection.
I think it should be noted under appendix I for Kerberos V4
that safe and encrypted proxy transfers to different hosts
can not be implement with Kerberos V4.
Additionally there needs to be some mechanism specified for the servers to
receive an additional key to be used for encrypting the data on the
control channel for proxy transfers. Otherwise the RFC should state
that proxy transfers are not possible.
Grace
-------------------------------------------------------------------
Grace Wiechman, UNICOS Kerberos/RPC/XDR Cray Research, Inc.
Phone: (612) 683-5241 655F Lone Oak Drive
E-mail: gw at cray.com or uunet!cray!gw Eagan, MN 55121
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06297;
9 Feb 95 13:53 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06292;
9 Feb 95 13:53 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11039;
9 Feb 95 13:53 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA06903 at pad-thai.cam.ov.com>; Thu, 9 Feb 1995 12:53:58 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA05731; Thu, 9 Feb 95 12:50:58 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA06898 at pad-thai.cam.ov.com>; Thu, 9 Feb 1995 12:53:52 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA20463; Thu, 9 Feb 95 12:53:51 EST
Message-Id: <9502091753.AA20463 at winkl.cam.ov.com>
To: Marc Horowitz <marc at cam.ov.com>
Cc: "John Wray, Digital DPE,\
(508) 486-5210 08-Feb-1995 0959" <wray at tuxedo.enet.dec.com>,
cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Kerberos V5 mechanism: tightening statements
In-Reply-To: Your message of "Wed, 08 Feb 1995 17:15:44 EST."
<9502082215.AA03646 at dun-dun-noodles.cam.ov.com>
Date: Thu, 09 Feb 1995 12:53:50 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
My specific points regarding the Kerberos mechanism I-D:
>(1) A statement that address checks shall be performed against
>input channel bindings on context establishment, unless the
>caller passes GSS_C_NO_BINDINGS: i.e., requiring the ability
>for an implementation to perform the address checking?
>(2) A statement that implementations shall not perform per-message
>replay or out-of-sequence detection if the caller of
>GSS_Init_sec_context() passes FALSE to replay_det_req_flag and
>sequence_req_flag, respectively: i.e, tightening the concept
>of making provision of these services optional from the current
>"highly recommended" status to a requirement?
have generated broader discussion than I'd anticipated. I still
believe that we should revise and advance the I-D, in a manner which
is consistent with current practice.
Re (1), I'll now propose, seeking consensus:
(1a) a question: should the scope of valid address checking be confined
(as cited in discussion) to source addresses, or is there also
feasibility and value in checking caller-provided destination addresses
in order to catch a misdelivered or misrouted token?
(1b) to reflect that, for this purpose, input of GSS_C_NULL_ADDRTYPE
for source address-type is equivalent to passing GSS_C_NO_BINDINGS.
(1c) to state a recommendation, but not a strict conformance
requirement, that mechanism implementations should check non-null
channel binding address specifiers against received context
establishment tokens when those tokens bear address restrictions.
I propose that (2) should stand as written, within the current scope
of the Kerberos V5 mechanism.
Can we converge on this for purposes of the current spec?
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08542;
9 Feb 95 15:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08538;
9 Feb 95 15:55 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13787;
9 Feb 95 15:55 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA11505 at pad-thai.cam.ov.com>; Thu, 9 Feb 1995 15:18:25 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA26349; Thu, 9 Feb 95 15:15:25 EST
Received: from dun-dun-noodles.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA11501 at pad-thai.cam.ov.com>; Thu, 9 Feb 1995 15:18:21 -0500
Received: by dun-dun-noodles.cam.ov.com (4.1/4.7) id AA04356; Thu, 9 Feb 95 15:18:20 EST
Message-Id: <9502092018.AA04356 at dun-dun-noodles.cam.ov.com>
To: Doug Rosenthal <rosenthl at mcc.com>
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
Subject: Re: Kerberos V5 mechanism: tightening statements
In-Reply-To: Your message of "Thu, 09 Feb 1995 09:53:52 CST."
<9502091553.AA14724 at krypton.mcc.com>
Date: Thu, 09 Feb 1995 15:18:19 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> Wrt Marc's suggestion above, I wonder if the proposed "context QOP"
>> parameter for context establishment (that I mentioned in the mechanism
>> negotiation summary) could incorporate "policy" choices as well.
>> E.g., perhaps the address-verification issue could be addressed
>> through this context parameter.
That sounds like a fine way to implement my suggestion. I would think
that a policy mechanism could also go to outside sources such as
config files or policy servers for hints on what to do.
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08644;
9 Feb 95 15:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08639;
9 Feb 95 15:57 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13915;
9 Feb 95 15:57 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA11652 at pad-thai.cam.ov.com>; Thu, 9 Feb 1995 15:23:40 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA27203; Thu, 9 Feb 95 15:20:42 EST
Received: from dun-dun-noodles.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA11643 at pad-thai.cam.ov.com>; Thu, 9 Feb 1995 15:23:15 -0500
Received: by dun-dun-noodles.cam.ov.com (4.1/4.7) id AA04380; Thu, 9 Feb 95 15:23:14 EST
Message-Id: <9502092023.AA04380 at dun-dun-noodles.cam.ov.com>
To: John Linn <linn at cam.ov.com>
Cc: "John Wray, Digital DPE,\
(508) 486-5210 08-Feb-1995 0959" <wray at tuxedo.enet.dec.com>,
cat-ietf at mit.edu
Subject: Re: Kerberos V5 mechanism: tightening statements
In-Reply-To: Your message of "Thu, 09 Feb 1995 12:53:50 EST."
<9502091753.AA20463 at winkl.cam.ov.com>
Date: Thu, 09 Feb 1995 15:23:13 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> (1a) a question: should the scope of valid address checking be confined
>> (as cited in discussion) to source addresses, or is there also
>> feasibility and value in checking caller-provided destination addresses
>> in order to catch a misdelivered or misrouted token?
I don't think there are any destination addresses inside kerberos to
check. In short, no.
>> (1b) to reflect that, for this purpose, input of GSS_C_NULL_ADDRTYPE
>> for source address-type is equivalent to passing GSS_C_NO_BINDINGS.
I'd agree.
>> (1c) to state a recommendation, but not a strict conformance
>> requirement, that mechanism implementations should check non-null
>> channel binding address specifiers against received context
>> establishment tokens when those tokens bear address restrictions.
I'd like to see a note added that this issue is still contentious, and
subject to change.
>> I propose that (2) should stand as written, within the current scope
>> of the Kerberos V5 mechanism.
I'd agree.
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08694;
9 Feb 95 16:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08690;
9 Feb 95 16:00 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13991;
9 Feb 95 16:00 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA11519 at pad-thai.cam.ov.com>; Thu, 9 Feb 1995 15:19:44 -0500
Received: from x400gate.bnr.ca by MIT.EDU with SMTP
id AA26476; Thu, 9 Feb 95 15:16:42 EST
X400-Received:
by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 9 Feb 1995 15:15:11 -0500
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 9 Feb 1995 15:14:31 -0500
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 9 Feb 1995 15:13:00 -0500
Date: Thu, 9 Feb 1995 15:13:00 -0500
X400-Originator: /dd.id=1651623/g=carlisle/i=cm/s=adams/@bnr.ca
X400-Mts-Identifier:
[/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.224:09.01.95.20.14.31]
X400-Content-Type: P2-1984 (2)
Content-Identifier: fw:A Proposed...
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "carlisle (c.m.) adams" <cadams at bnr.ca>
X-Orig-Sender: "carlisle (c.m.) adams" <cadams at bnr.ca>
Message-Id: <"28245 Thu Feb 9 15:14:44 1995"@bnr.ca>
To: cat-ietf at mit.edu
Subject: fw:A Proposed QOP Structure...
Hi,
I've discovered that at least some people on the CAT group did not
receive this post, for not yet fully known reasons. Here's hoping
that this attempt works (apologies to anyone who is getting this a
second time...).
Carlisle.
---forwarded-message---->
1995 Feb 02 at 14:25
to: cat-ietf at mit.edu (BNR400)
from: Carlisle (C.M.) Adams :9C21 (BNR)
subject: A Proposed QOP Structure...
Hello everyone,
If I may be so bold, let me try to summarize, clarify, paraphrase, and
interpret some of the discussion which I have seen/heard regarding the
infamous QOP parameter of GSS-API.
- There are some who want to use it simply to specify particular
algorithms within a mechanism (e.g., for mechanism "x", a QOP of 5
means DES-CBC).
- There are some who want to use it in a more qualitative sense (e.g.,
for mechanism "x", a QOP of 5 means "STRONG").
- There are some who want it to be mechanism independent (e.g., for the
most "security-unconcious" application which knows nothing whatsoever
about algorithms and has specified DEFAULT for its mechanism
selection, a QOP of 5 still means "STRONG").
- There are some who want it to be used for confidentiality as well as
for integrity.
- There are some who agree that a QOP for confidentiality would be
useful, but would rather use a second QOP parameter (i.e., change
the existing GSS interface).
Complicating all of this somewhat is the fact that certain QOP values
have already been specified and implemented ("0" for DEFAULT and "1",
"2", and "3" in Kerberos V5).
Although I recognize that it is impossible to satisfy everyone, our
implementation of SPKM needs to do *something* with QOP, and it is
difficult to choose something while this whole area is so unsettled.
The following is our proposal. I'm submitting it to the group in
advance of finalizing the SPKM spec. so that if there is violent
objection (along with positive suggestions for improvement!) I can make
the neceessary adjustments before submitting the spec..
The proposal has a number of advantages. Namely, it satisfies all the
bullets above without conflicting with previously-defined QOP values or
requiring any change to the current GSS-API. It also (I believe) leaves
enough room for future expansion.
Unless I see great dissent over the next week or so, the following text
will appear in the SPKM spec. and will be implemented in our GSS
product.
8<----------------------------------------------------------------------
The QOP parameter for SPKM is defined to be a 32-bit unsigned integer
(an OM_uint32) with the following bit-field assignments:
Confidentiality Integrity
31 (MSB) 16 15 (LSB) 0
------------------------------------|-----------------------------------
| TS (5) | U(3) | IA (4) | MA (4) | TS (5) | U(3) | IA (4) | MA(4) |
------------------------------------|-----------------------------------
where
TS is a 5-bit Type Specifier (a semantic qualifier whose value
specifies the type of algorithm which may be used to protect the
corresponding token -- see below for details);
U is a 3-bit Unspecified field (available for future
use/expansion);
IA is a 4-bit field enumerating Implementation-specific
Algorithms; and
MA is a 4-bit field enumerating Mechanism-defined Algorithms.
The interpretation of the QOP parameter is as follows (note that the
same procedure is used for both the confidentiality and the integrity
halves of the parameter). The MA field is examined first. If it is
non-zero then the algorithm used to protect the token is the
mechanism-specified algorithm corresponding to that integer value.
If MA is zero then IA is examined. If this field value is non-zero
then the algorithm used to protect the token is the implementation-
specified algorithm corresponding to that integer value (if this
algorithm is available over the established context). Note that use
of this field may hinder portability since a particular value may
specify one algorithm in one implementation of the mechanism and may
not be supported or may specify a completely different algorithm in
another implementation of the mechanism.
Finally, if both MA and IA are zero then TS is examined. A value of
zero for TS specifies the mechanism-defined default algorithm for the
established context (confidentiality or integrity, depending on which
half of QOP is being examined). A non-zero value for TS corresponds
to a particular algorithm qualifier and selects the first algorithm
supported over the context which satisfies that qualifier (note that
"first" is also mechanism-defined).
The following TS values (i.e., algorithm qualifiers) are specified;
other values may be added in the future.
For the Confidentiality TS field:
00001 (1) = SPKM_SYM_ALG_STRENGTH_STRONG
00010 (2) = SPKM_SYM_ALG_STRENGTH_MEDIUM
00011 (3) = SPKM_SYM_ALG_STRENGTH_WEAK
For the Integrity TS field:
00001 (1) = SPKM_INT_ALG_NON_REPUDIABLE
00010 (2) = SPKM_INT_ALG_REPUDIABLE
Clearly, qualifiers such as strong, medium, and weak are debatable
and likely to change with time, but for the purposes of this version
of the specification we define these terms as follows. A
confidentiality algorithm is "weak" if the effective key length of
the cipher is 40 bits or less; it is "medium-strength" if the
effective key length is strictly between 40 and 80 bits; and it is
"strong" if the effective key length is 80 bits or greater. (Note
that "effective key length" describes the computational effort
required to break a cipher using the best-known cryptanalytic attack
against that cipher.)
A five-bit TS field allows up to 31 qualifiers for each of
confidentiality and integrity (since "0" is reserved for "default").
This document specifies three for confidentiality and two for
integrity, leaving a lot of room for future specification.
Suggestions of qualifiers such as "fast", "medium-speed", and "slow"
have been made, but such terms are difficult to quantify (and in any
case are platform- and processor-dependent), and so have been left
out of this initial specification. The intention is that the TS
terms be quantitative, environment-independent qualifiers of
algorithms, as much as this is possible.
Use of the QOP structure as defined above is ultimately meant to be
as follows.
- TS values are specified at the GSS-API level and are therefore
portable across mechanisms. Applications which know nothing about
algorithms are still able to choose "quality" of protection for
their message tokens.
- MA values are specified at the mechanism level and are therefore
portable across implementations of a mechanism. For example, all
implementations of the Kerberos V5 GSS mechanism must support
GSS_KRB5_INTEG_C_QOP_MD5 (value: 1)
GSS_KRB5_INTEG_C_QOP_DES_MD5 (value: 2)
GSS_KRB5_INTEG_C_QOP_DES_MAC (value: 3).
(Note that these Kerberos-specified integrity QOP values do not
conflict with the QOP structure defined above.)
- IA values are specified at the implementation level (in user
documentation, for example) and are therefore typically non-
portable. An application which is aware of its own mechanism
implementation and the mechanism implementation of its peer,
however, is free to use these values since they will be perfectly
valid and meaningful over that context and between those peers.
The receiver of a token must pass back to its calling application a
QOP parameter with all relevant fields set. For example, if
triple-DES has been specified by a mechanism as algorithm 8, then
a receiver of a triple-DES-protected token must pass to its
application (QOP Confidentiality TS=1, IA=0, MA=8). In this way,
the application is free to read whatever part of the QOP it
understands (TS or IA/MA).
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08773;
9 Feb 95 16:04 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08769;
9 Feb 95 16:04 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14088;
9 Feb 95 16:04 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA11609 at pad-thai.cam.ov.com>; Thu, 9 Feb 1995 15:20:49 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA26694; Thu, 9 Feb 95 15:17:51 EST
Received: from dun-dun-noodles.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA11600 at pad-thai.cam.ov.com>; Thu, 9 Feb 1995 15:20:41 -0500
Received: by dun-dun-noodles.cam.ov.com (4.1/4.7) id AA04372; Thu, 9 Feb 95 15:20:40 EST
Message-Id: <9502092020.AA04372 at dun-dun-noodles.cam.ov.com>
To: Grace Wiechman <gw at ironwood.cray.com>
Cc: cat-ietf at mit.edu, sjogren at tgv.com
Subject: Re: FTP security extensions
In-Reply-To: Your message of "Thu, 09 Feb 1995 10:29:34 CST."
<9502091629.AA05895 at poplar020>
Date: Thu, 09 Feb 1995 15:20:39 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> I think it should be noted under appendix I for Kerberos V4
>> that safe and encrypted proxy transfers to different hosts
>> can not be implement with Kerberos V4.
>>
>> Additionally there needs to be some mechanism specified for the servers to
>> receive an additional key to be used for encrypting the data on the
>> control channel for proxy transfers. Otherwise the RFC should state
>> that proxy transfers are not possible.
I think it would be better to state that that secure proxy ftp
transfers are not covered by this RFC, rather than excluding it
completely. Someone might come up with a clever way to implement
them, and I don't think we should prevent a future RFC from
documenting a suitable mechanism.
Marc
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09575;
9 Feb 95 16:48 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15100;
9 Feb 95 16:48 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09514;
9 Feb 95 16:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09177;
9 Feb 95 16:24 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa14596;
9 Feb 95 16:24 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA05501>; Thu, 9 Feb 1995 13:25:03 -0800
Message-Id: <199502092125.AA05501 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1736 on Recommendations for IRLs
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 09 Feb 95 13:26:11 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1736:
Title: Functional Recommendations for Internet Resource
Locators
Author: J. Kunze
Date: February 1995
Mailbox: jak at violet.berkeley.edu
Pages: 10
Characters: 22,415
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1736.txt
This document specifies a minimum set of requirements for Internet
resource locators (IRLs), which convey location and access information
for resources. Typical examples of resources include network
accessible documents, WAIS databases, FTP servers, and Telnet
destinations. This RFC is a product of the Uniform Resource
Identifiers Working Group of the IETF.
This memo provides information for the Internet community. This
memo does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <950209132234.RFC at ISI.EDU>
SEND /rfc/rfc1736.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1736.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <950209132234.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09574;
9 Feb 95 16:48 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15095;
9 Feb 95 16:47 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09511;
9 Feb 95 16:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09346;
9 Feb 95 16:33 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa14819;
9 Feb 95 16:33 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA06210>; Thu, 9 Feb 1995 13:34:11 -0800
Message-Id: <199502092134.AA06210 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1761 on Snoop Packet Capture File Format
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 09 Feb 95 13:35:20 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1761:
Title: Snoop Version 2 Packet Capture File Format
Author: B. Callaghan & R. Gilligan
Date: February 1995
Mailbox: brent.callaghan at eng.sun.com,
bob.gilligan at eng.sun.com
Pages: 6
Characters: 10,761
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1761.txt
This paper describes the file format used by "snoop", a packet
monitoring and capture program developed by Sun. This paper is
provided so that people can write compatible programs to generate and
interpret snoop packet capture files.
This memo provides information for the Internet community. This
memo does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <950209133212.RFC at ISI.EDU>
SEND /rfc/rfc1761.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1761.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <950209133212.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09576;
9 Feb 95 16:48 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15098;
9 Feb 95 16:48 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09515;
9 Feb 95 16:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09222;
9 Feb 95 16:27 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa14663;
9 Feb 95 16:27 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA05721>; Thu, 9 Feb 1995 13:28:04 -0800
Message-Id: <199502092128.AA05721 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1758 on NADF Standing Documents
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 09 Feb 95 13:29:12 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1758:
Title: NADF Standing Documents: A Brief Overview
Author: The North American Directory Forum
Date: February 1995
Mailbox: 0004454742 at mcimail.com
Pages: 4
Characters: 7,294
Obsoletes: 1417
URL: ftp://ds.internic.net/rfc/rfc1758.txt
The North American Directory Forum (NADF) is a collection of service
providers which plans to cooperatively offer a Public Directory
Service in North America using the CCITT X.500 Recommendations.
Although many groups are working on realizing X.500, the NADF is
unique in that it must achieve a cooperative service offered by
competing providers. The purpose of this document is to provide a
brief overview of the NADF's Standing Document series.
This memo provides information for the Internet community. This
memo does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <950209132714.RFC at ISI.EDU>
SEND /rfc/rfc1758.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1758.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <950209132714.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10092;
9 Feb 95 17:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10088;
9 Feb 95 17:12 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15564;
9 Feb 95 17:12 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <QAA14256 at pad-thai.cam.ov.com>; Thu, 9 Feb 1995 16:38:13 -0500
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA07624; Thu, 9 Feb 95 16:35:14 EST
Received: from krypton.mcc.com (krypton.mcc.com [128.62.30.63]) by turtle.mcc.com (8.6.9/mcc.8.6.9) with SMTP id PAA19578; Thu, 9 Feb 1995 15:33:05 -0600
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA16372; Thu, 9 Feb 95 15:33:04 CST
Date: Thu, 9 Feb 95 15:33:04 CST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9502092133.AA16372 at krypton.mcc.com>
To: linn at cam.ov.com
Cc: marc at cam.ov.com, wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
In-Reply-To: <9502091753.AA20463 at winkl.cam.ov.com> (message from John Linn on Thu, 09 Feb 1995 12:53:50 -0500)
Subject: Re: Kerberos V5 mechanism: tightening statements
>> (1) A statement that address checks shall be performed against
>> input channel bindings on context establishment, unless the
>> caller passes GSS_C_NO_BINDINGS: i.e., requiring the ability
>> for an implementation to perform the address checking?
>> (2) A statement that implementations shall not perform
>> per-message replay or out-of-sequence detection if the caller
>> of GSS_Init_sec_context() passes FALSE to replay_det_req_flag
>> and sequence_req_flag, respectively: i.e, tightening the
>> concept of making provision of these services optional from the
>> current "highly recommended" status to a requirement?
John> ...
John> (1b) to reflect that, for this purpose, input of
John> GSS_C_NULL_ADDRTYPE for source address-type is equivalent to
John> passing GSS_C_NO_BINDINGS.
Seems right.
John> (1c) to state a recommendation, but not a strict conformance
John> requirement, that mechanism implementations should check
John> non-null channel binding address specifiers against received
John> context establishment tokens when those tokens bear address
John> restrictions.
Yes.
John> I propose that (2) should stand as written, within the
John> current scope of the Kerberos V5 mechanism.
Agreed, especially since the corresponding *_state flags
(GSS_Init_sec_context() output parameters) can indicate if a given
mechanism implementation can't support the FALSE values (i.e. always
enforces sequence and/or replay checks).
John> Can we converge on this for purposes of the current spec?
I hope so ... :-)
- Doug
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10550;
9 Feb 95 17:28 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16046;
9 Feb 95 17:28 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10520;
9 Feb 95 17:28 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10279;
9 Feb 95 17:23 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-url-mailserver-01.txt
Date: Thu, 09 Feb 95 17:22:57 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502091723.aa10279 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Mailserver URL Specification
Author(s) : P. Hoffman
Filename : draft-ietf-uri-url-mailserver-01.txt
Pages : 3
Date : 02/08/1995
A new URL scheme, "mailserver", is defined. It allows mail client software
to create RFC822 mail messages from a URL.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-uri-url-mailserver-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-uri-url-mailserver-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-uri-url-mailserver-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950208175526.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-url-mailserver-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-url-mailserver-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950208175526.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10552;
9 Feb 95 17:28 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16047;
9 Feb 95 17:28 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10519;
9 Feb 95 17:28 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10229;
9 Feb 95 17:22 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: html-wg at oclc.org
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-html-spec-01.txt
Date: Thu, 09 Feb 95 17:22:01 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502091722.aa10229 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Markup Language
Working Group of the IETF.
Title : HyperText Markup Language Specification - 2.0
Author(s) : T. Berners-Lee, D. Connolly
Filename : draft-ietf-html-spec-01.txt
Pages : 80
Date : 02/08/1995
The HyperText Markup Language (HTML) is a simple markup language used to
create hypertext documents that are portable from one platform to another.
HTML documents are SGML documents with generic semantics that are
appropriate for representing information from a wide range of applications.
HTML markup can represent hypertext news, mail, documentation, and
hypermedia; menus of options; database query results; simple structured
documents with in-lined graphics; and hypertext views of existing bodies of
information.
HTML has been in use by the World Wide Web (WWW) global information
initiative since 1990. This specification roughly corresponds to the
capabilities of HTML in common use prior to June 1994. It is defined as
an application of ISO Standard 8879:1986 Information Processing Text
and Office Systems; Standard Generalized Markup Language (SGML).
The "text/html; version=2.0" Internet Media Type (RFC 1590) and
MIME Content Type (RFC 1521) is defined by this specification.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-html-spec-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-html-spec-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-html-spec-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950208174842.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-html-spec-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-html-spec-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950208174842.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11720;
9 Feb 95 18:49 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17495;
9 Feb 95 18:49 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11703;
9 Feb 95 18:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11606;
9 Feb 95 18:43 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17394;
9 Feb 95 18:43 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11601;
9 Feb 95 18:43 EST
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: bgp at ans.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: A Border Gateway Protocol 4 (BGP-4) to Draft
Standard
Date: Thu, 09 Feb 95 18:43:44 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9502091843.aa11601 at IETF.CNRI.Reston.VA.US>
The IESG has approved the following two Internet-Drafts:
1. A Border Gateway Protocol 4 (BGP-4)
<draft-ietf-idr-bgp4-00.txt>
2. Application of the Border Gateway Protocol in the Internet
<draft-ietf-bgp-app-00.txt>
as Draft Standards. The IESG also recommends that:
1. Experience with the BGP-4 protocol
<draft-ietf-idr-bgp4-experience-00.txt>
2. BGP-4 Protocol Analysis
<draft-ietf-idr-bgp4-analysis-00.txt>
be published as Informational RFCs. The four documents are the product
of the Inter-Domain Routing Working Groups. The IESG contact person is
Joel Halpern.
Technical Summary
BGP-4 is an inter-domain routing protocol. Revision 4 was created to
add CIDR support to the previous existing revision 3.
The change to BGP-4 from RFC 1654 is to extend the OPEN syntax in a
backwards compatible fashion. The Authentication Code and Data is
replaced with an Optional Parameters Length and Optional Paramters,
with Authentication as the only defined optional parameter.
The Informational documents cover the operational experience and
performance analysis. There are four interoperable implementations,
and deployed use of the protocol. All options have been tested by at
least two vendors.
Working Group Summary
These document reflects extensive discussion within the working group.
They also reflect the implementation experience which has been gained
with these protocols.
Protocol Quality
The Area Director has reviewed the latest updates to the protocol. It
remains a solid, sound, useful, protocol.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22909;
10 Feb 95 2:06 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22905;
10 Feb 95 2:06 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24395;
10 Feb 95 2:06 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <BAA28764 at pad-thai.cam.ov.com>; Fri, 10 Feb 1995 01:35:40 -0500
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA00295; Fri, 10 Feb 95 01:32:29 EST
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4 + 8.6.9, dpg hack 5dec94) with UUCP id WAA21693; Thu, 9 Feb 1995 22:31:41 -0800
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA12713; Thu, 9 Feb 95 22:31:37 -0800
Date: Thu, 9 Feb 95 22:31:37 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9502100631.AA12713 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: "carlisle (c.m.) adams" <cadams at bnr.ca>
Subject: Re: fw:A Proposed QOP Structure...
Cc: cat-ietf at mit.edu
Reply-To: dpg at ocsg.com
Carlisle,
Your QOP proposal may be a satisfactory solution for SPKM
however as a general solution it has some problems. I have
enclosed comments on your proposal based on its use as a
general solution.
> Hello everyone,
>
> If I may be so bold, let me try to summarize, clarify,
> paraphrase, and interpret some of the discussion which I
> have seen/heard regarding the infamous QOP parameter of
> GSS-API.
>
[ stuff deleted ]
> The QOP parameter for SPKM is defined to be a 32-bit
> unsigned integer (an OM_uint32) with the following
> bit-field assignments:
>
TS, U, IA, and MA fields are mutually exclusive. This is a
waste of space and limiting. You are using 16 bits to
represent something in which the worst case value
occupies only five of those bits. Is this good or bad? It's
hard to say but it is an area of concern.
[ stuff deleted ]
> Clearly, qualifiers such as strong, medium, and weak are
> debatable and likely to change with time, but for the
> purposes of this version of the specification we define
> these terms as follows. A confidentiality algorithm is
> "weak" if the effective key length of the cipher is 40 bits
> or less; it is "medium-strength" if the effective key
> length is strictly between 40 and 80 bits; and it is
> "strong" if the effective key length is 80 bits or
> greater. (Note that "effective key length" describes
> the computational effort required to break a cipher
> using the best-known cryptanalytic attack against that
> cipher.)
>
This argument is weak and unrealistic. First, you are
defining strength using measure you acknowledge will
change -- perhaps tomorrow (literally). Second, some
cryptographic algorithms do not use keys measured in bit
length. Code book (word substitution) algorithms are an
example.
[ stuff deleted ]
> - MA values are specified at the mechanism level and are
> therefore portable across implementations of a mechanism.
> For example, all implementations of the Kerberos V5 GSS
> mechanism must support
>
> GSS_KRB5_INTEG_C_QOP_MD5 (value: 1)
> GSS_KRB5_INTEG_C_QOP_DES_MD5 (value: 2)
> GSS_KRB5_INTEG_C_QOP_DES_MAC (value: 3).
>
I'm confused. This definition appears to conflict with
the structure you propose. Shouldn't DES be in the
confidentiality field and MD5 and MAC in the integrity
field?
[ stuff deleted ]
> The receiver of a token must pass back to its calling
> application a QOP parameter with all relevant fields
> set. For example, if triple-DES has been specified by a
> mechanism as algorithm 8, then a receiver of a
> triple-DES-protected token must pass to its
> application (QOP Confidentiality TS=1, IA=0, MA=8). In
> this way, the application is free to read whatever part of
> the QOP it understands (TS or IA/MA).
>
Some mechanisms may not know what algorithm was used. For
example, a mechanism that uses krb5_rd_priv() to decode
tokens is not returned an ETYPE.
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00787;
10 Feb 95 5:37 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00781;
10 Feb 95 5:37 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02115;
10 Feb 95 5:37 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00727;
10 Feb 95 5:37 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00665;
10 Feb 95 5:24 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01943;
10 Feb 95 5:24 EST
Received: from campino.Informatik.RWTH-Aachen.DE by venera.isi.edu (5.65c/5.61+local-20)
id <AA12551>; Fri, 10 Feb 1995 02:24:33 -0800
Received: from by campino.informatik.rwth-aachen.de
(4.1/campino-6) id AB11762; Fri, 10 Feb 95 11:24:23 +0100
Received: from IKARUS/TEMPQ by i4.informatik.rwth-aachen.de (Mercury 1.20);
10 Feb 95 11:25:50
Received: from TEMPQ by IKARUS (Mercury 1.20); 10 Feb 95 10:32:40
To: ietf at isi.edu
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Claudia Popien <popien at ikarus.informatik.rwth-aachen.de>
Organization: Informatik IV - RWTH Aachen
Date: 10 Feb 1995 10:33:35 GMT+1
Subject: CfP: ICDP96 (Germany)
Priority: normal
X-Mailer: Pegasus Mail/Mac v2.02
Message-Id: <1526A1B194E at i4.informatik.rwth-aachen.de>
__________________________________________________________________________
ANNOUNCEMENT AND CALL FOR PAPERS
ICDP '96:
IFIP/IEEE INTERNATIONAL CONFERENCE
ON DISTRIBUTED PLATFORMS
Client/Server and Beyond:
DCE, CORBA, ODP & Advanced Distributed Applications
__________________________________________________________________________
Dresden, Germany February 27 - March 1, 1996
__________________________________________________________________________
In continuation of International Workshop on OSF DCE, Karlsruhe, Germany,
1993
Organized by IFIP
IEEE Comm. Society Gesellschaft fuer Informatik
Dresden Univ. of Techn. Aachen Univ. of Technology
OBJECTIVES AND SCOPE
Client/Server applications are of increasing importance in industry, and
have been enhanced with advanced distributed object-oriented techniques,
dedicated tool support and both multimedia and mobil computing extensions.
Such solutions are a significant step towards a global distributed
processing model. Recent responses to this trend are standardized platforms
and models including the Distributed Computing Environment (DCE) of the Open
Software Foundation (OSF), Open Distributed Processing (ODP) and the Common
Object Request Broker Architecture (CORBA) of the Object Management Group
(OMG).
ICDP'96 will be a major forum for distributed systems researchers, network
developers, service providers, application designers and end users for
discussing the latest research and development results with respect to these
platforms. Topics of particular interest include, but are not limited to:
o Experiences with distributed applications and standardized platforms
(DCE, CORBA, ODP, ONC+, ANSAware and others)
o Distributed platforms in advanced development and research projects
o Network Services (directory, security, file management etc.)
o Distributed application management
o Objects in distributed environments
o Trading concepts and open markets of distributed services
o Quality of service in distributed applications
o Applications of mobile communication systems
STRUCTURE OF THE CONFERENCE
- Technical Stream: Latest research results will be presented.
- Industrial Stream: Industrial developments and trends will be discussed.
- Demonstration Stream: Exhibition around distributed processing.
Original full papers (max. 15 pages) will belong to the Technical Stream.
Furthermore, you are invited to submit extended abstracts focusing on
practical work for both the Industrial Stream and the Demonstration Stream
(max. 5 pages). Accepted papers will be published in the international
conference proceedings by Chapman & Hall.
All submissions must be sent online (postscript) to the following
email-address: ICDP96 at ibc.inf.tu-dresden.de
IMPORTANT DATES:
Deadline for Submission: June 15, 1995
Notification of Acceptance: September 15, 1995
Camera ready papers: October 15, 1995
Tutorials (one day): February 27, 1996
Conference (three days): February 28 - March 1, 1996
Location: Dresden has become famous above all as city of the arts and is
only a two hours drive from Berlin to the north and Prague to the south.
Major attractions are the Semper Opera, the baroque Zwinger, the art
collections (Gruenes Gewoelbe, Gemaeldegalerie) and the Frauenkirche that is
currently being rebuilt. The surrounding countryside also provides many
opportunities for sightseeing including Pillnitz castle, the china
manufacture in Meissen and Saxon Switzerland.
For further information please contact the program chairs:
Prof. Dr. Alexander Schill Prof. Dr. Otto Spaniol/Claudia Popien
Dresden Univ. of Technology RWTH Aachen
Dept. of Computer Science Computer Science IV
D-01062 Dresden D-52056 Aachen
GERMANY GERMANY
WWW: http://www.inf.tu-dresden.de/TU/Informatik/IBDR/lsrn/ICDP96
e-mail: ICDP96 at ibc.inf.tu-dresden.de
FAX: +49 / 351 / 4575 335
PROGRAMME COMMITTEE:
S.A. Aidarous, BNR, Ottawa (Canada)
M. Bever, IBM ENC Heidelberg (Germany)
P. Dasgupta, Arizona State Univ. (USA)
J. Dilley, HP Cupertino (USA)
R.L. Fike, RNF Systems (USA)
A. Gaylord, Univ. Massachussetts (USA)
K. Geihs, Univ. Frankfurt (Germany)
A. Herbert, ANSA (UK)
L. Heuser, DEC CEC, Karlsruhe (Germany)
J. Janacek, TU Prague (Czech Republic)
F. Kamoun, C.N. de l'Informatique (Tunisia)
J. Kiho, Univ. Tartu (Estonia)
D. Lin, IBM Austin (USA)
P. Linington, Univ. Kent (UK)
O. Martikainen, Telecom (Finland)
F. Miralles, SNI Munich (Germany)
B. Pehrson, Swedish Institute of Computer Science, Kista (Sweden)
R. Posch, TU Graz (Austria)
P. Radford, Logica (UK)
K. Raymond, Univ. Brisbane (Australia)
D. Ruddock, Bellcore, New Jersey (USA)
H. Rudin, IBM (Switzerland)
G. Schuermann, GMD FOKUS (Germany)
R. Soley, OMG (USA)
L. Svobodova, IBM (Switzerland)
R. Torbergsen, SINTEF RUNIT, Trondheim (Norway)
W. Tuvell, OSF Cambridge (USA)
__________________________________________________________________
Claudia Popien Tel.: +49 241 8021440
RWTH Aachen, Informatik IV FAX: +49 241 8888220
Ahornstr. 55 e-mail:
D-52056 Aachen GERMANY popien at informatik.rwth-aachen.de
__________________________________________________________________
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02400;
10 Feb 95 9:45 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02396;
10 Feb 95 9:45 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06140;
10 Feb 95 9:45 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <IAA07828 at pad-thai.cam.ov.com>; Fri, 10 Feb 1995 08:53:00 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA21218; Fri, 10 Feb 95 08:50:00 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <IAA07823 at pad-thai.cam.ov.com>; Fri, 10 Feb 1995 08:52:58 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA20760; Fri, 10 Feb 95 08:52:57 EST
Message-Id: <9502101352.AA20760 at winkl.cam.ov.com>
To: dpg at ocsg.com
Cc: "carlisle (c.m.) adams" <cadams at bnr.ca>, cat-ietf at mit.edu,
linn at cam.ov.com
Subject: Re: fw:A Proposed QOP Structure...
In-Reply-To: Your message of "Thu, 09 Feb 1995 22:31:37 PST."
<9502100631.AA12713 at war04.ocsg.com>
Date: Fri, 10 Feb 1995 08:52:57 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Dennis writes:
>> - MA values are specified at the mechanism level and are
>> therefore portable across implementations of a mechanism.
>> For example, all implementations of the Kerberos V5 GSS
>> mechanism must support
>>
>> GSS_KRB5_INTEG_C_QOP_MD5 (value: 1)
>> GSS_KRB5_INTEG_C_QOP_DES_MD5 (value: 2)
>> GSS_KRB5_INTEG_C_QOP_DES_MAC (value: 3).
>
>
>I'm confused. This definition appears to conflict with
>the structure you propose. Shouldn't DES be in the
>confidentiality field and MD5 and MAC in the integrity
>field?
These definitions correspond to the integrity choices defined
in the Kerberos mechanism draft. Choices 2 and 3 use DES as
part of the integrity computation; (2) uses DES in conjunction
with MD5 and (3) uses DES to compute a MAC. All of these are
options for how integrity is computed, not how confidentiality
is provided, so I think Carlisle's proposal groups them correctly.
>> The receiver of a token must pass back to its calling
>> application a QOP parameter with all relevant fields
>> set. For example, if triple-DES has been specified by a
>> mechanism as algorithm 8, then a receiver of a
>> triple-DES-protected token must pass to its
>
>> application (QOP Confidentiality TS=1, IA=0, MA=8). In
>> this way, the application is free to read whatever part of
>> the QOP it understands (TS or IA/MA).
>
>
>Some mechanisms may not know what algorithm was used. For
>example, a mechanism that uses krb5_rd_priv() to decode
>tokens is not returned an ETYPE.
Maybe we need a means to represent and return "undetermined"?
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03531;
10 Feb 95 11:06 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03527;
10 Feb 95 11:06 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07832;
10 Feb 95 11:06 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <JAA09559 at pad-thai.cam.ov.com>; Fri, 10 Feb 1995 09:52:45 -0500
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA27551; Fri, 10 Feb 95 09:49:42 EST
Received: from krypton.mcc.com (krypton.mcc.com [128.62.30.63]) by turtle.mcc.com (8.6.9/mcc.8.6.9) with SMTP id IAA26385; Fri, 10 Feb 1995 08:49:26 -0600
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA18283; Fri, 10 Feb 95 08:49:24 CST
Date: Fri, 10 Feb 95 08:49:24 CST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9502101449.AA18283 at krypton.mcc.com>
To: dpg at ocsg.com
Cc: cadams at bnr.ca, cat-ietf at mit.edu
In-Reply-To: <9502100631.AA12713 at war04.ocsg.com> (message from Dennis Glatting on Thu, 9 Feb 95 22:31:37 -0800)
Subject: Re: fw:A Proposed QOP Structure...
Dennis> Your QOP proposal may be a satisfactory solution for SPKM
Dennis> however as a general solution it has some problems. I have
Dennis> enclosed comments on your proposal based on its use as a
Dennis> general solution.
I appreciate your review of the proposal. However, I disagree with
your assessment above. I think the QOP proposal *does* provide a
general solution, especially given the constraints that Carlisle was
attempting to satisfy. Namely:
Carlisle> - There are some who want to use it simply to specify particular
Carlisle> algorithms within a mechanism (e.g., for mechanism "x", a QOP of 5
Carlisle> means DES-CBC).
Carlisle>
Carlisle> - There are some who want to use it in a more qualitative sense (e.g.,
Carlisle> for mechanism "x", a QOP of 5 means "STRONG").
Carlisle>
Carlisle> - There are some who want it to be mechanism independent (e.g., for the
Carlisle> most "security-unconcious" application which knows nothing whatsoever
Carlisle> about algorithms and has specified DEFAULT for its mechanism
Carlisle> selection, a QOP of 5 still means "STRONG").
Carlisle>
Carlisle> - There are some who want it to be used for confidentiality as well as
Carlisle> for integrity.
Carlisle>
Carlisle> - There are some who agree that a QOP for confidentiality would be
Carlisle> useful, but would rather use a second QOP parameter (i.e., change
Carlisle> the existing GSS interface).
Carlisle>
Carlisle> ...
Carlisle>
Carlisle> The proposal has a number of advantages. Namely, it satisfies all the
Carlisle> bullets above without conflicting with previously-defined QOP values or
Carlisle> requiring any change to the current GSS-API. It also (I believe) leaves
Carlisle> enough room for future expansion.
Dennis> TS, U, IA, and MA fields are mutually exclusive. This is a
Dennis> waste of space and limiting. You are using 16 bits to
Dennis> represent something in which the worst case value occupies
Dennis> only five of those bits. Is this good or bad? It's hard to
Dennis> say but it is an area of concern.
Wrt it being a "waste of space", I believe Carlisle was trying to not
introduce changes to the current API, i.e. just use the existing QOP
parameter. Wrt it being "limited", there is actually plenty of room
for expansion - as you even point out (e.g. 16 bits for current worst
case of 5 bits). Also, note that the values are integers; i.e. it is
*not* a bit mask. For example, each IA or MA field can handle up to
16 values, etc.
So, the fields accommodate qualitative values (TS) as well as specific
algorithms, including algorigthms which are standard for a mechanism
(MA) and those which are implementation-specific (IA); a very general
solution.
Dennis> This argument is weak and unrealistic. First, you are
Dennis> defining strength using measure you acknowledge will
Dennis> change -- perhaps tomorrow (literally). Second, some
Dennis> cryptographic algorithms do not use keys measured in bit
Dennis> length. Code book (word substitution) algorithms are an
Dennis> example.
Fine; the proposal simply provides a hook for qualitative values.
Interpretation of those values will be mechanism-dependent. So, while
the SPKM may use key length as a metric, other mechanisms can use
something else.
Dennis> I'm confused. This definition appears to conflict with the
Dennis> structure you propose. Shouldn't DES be in the
Dennis> confidentiality field and MD5 and MAC in the integrity
Dennis> field?
(John Linn already responded to this.)
Dennis> Some mechanisms may not know what algorithm was used. For
Dennis> example, a mechanism that uses krb5_rd_priv() to decode
Dennis> tokens is not returned an ETYPE.
How could a mechanism *not* know what algorithm it used to
encrypt/decrypt data?
- Doug
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04225;
10 Feb 95 11:38 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08480;
10 Feb 95 11:38 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04206;
10 Feb 95 11:38 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04066;
10 Feb 95 11:25 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08254;
10 Feb 95 11:25 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04059;
10 Feb 95 11:25 EST
To: IETF-Announce: ;
Subject: WG ACTION: Guidelines and Recommendations for Security
Incident Processing (grip)
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at IETF.CNRI.Reston.VA.US>
Date: Fri, 10 Feb 95 11:25:09 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9502101125.aa04059 at IETF.CNRI.Reston.VA.US>
A new working group has been formed in the Operational Requirements
Area of the IETF. For more information, please contact the working
group chairs or the Area Directors.
Guidelines & Recommendations for Security Incident Processing (grip)
--------------------------------------------------------------------
Chair(s):
Barbara Fraser <byf at cert.org>
K.P. Kossakowski <kpk at cert.dfn.de>
Louis Mamakos <louie at alter.net>
Operational Requirements Area Director(s):
Scott Bradner <sob at harvard.edu>
Michael O'Dell <mo at uunet.uu.net>
Area Advisor
Mike O'Dell <mo at uunet.uu.net>
Mailing lists:
General Discussion:grip-wg at uu.net
To Subscribe: grip-wg-request at uu.net
Archive: TBD
Description of Working Group:
Note: This Working Group is co-chartered by the Security Area.
The purpose of the Security Incident Response working group is to
provide guidelines and recommendations to facilitate the consistant
handling of security incidents in the Internet commnity. Guidelines
will address technology vendors, network service providers, response
teams in their roles assisting roles assisting organizations in
resolving security incidents. These relationships are functional and
can exist within and across ogranizational boundaries.
The working group will produce two quality documents:
1) Guidelines for security incident response teams.
2) Guidelines for vendors (this will include both technology producers
and network service providers).
Goals and Milestones:
Feb 95 Produce document describing problem statement and document
taxonomy/vocabulary. Also cite the Site Security Handlbook documents
to make clear the relationship and scope between the two working
groups and documents
Feb 95 Produce draft outline for remainder of Response Team Document
Apr 95 Meet at Danvers IETF to review full Internet-Draft of Response Team
Document
Jun 95 Produce final version of Response Team Internet-Draft
Jun 95 Produce Internet-Draft on Guidelines for vendors
Jul 95 Meet at Stockholm IETF. Review vendor Guideline Internet-Draft
Sep 95 Produce final version of Vendor Guideline Internet-Draft. Submit to
IESG for review.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05109;
10 Feb 95 12:21 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09370;
10 Feb 95 12:21 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05091;
10 Feb 95 12:21 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04923;
10 Feb 95 12:15 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09245;
10 Feb 95 12:15 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04915;
10 Feb 95 12:15 EST
To: IETF-Announce: ;
Subject: WG ACTION: ATM MIB (atommib)
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at IETF.CNRI.Reston.VA.US>
Date: Fri, 10 Feb 95 12:15:21 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9502101215.aa04915 at IETF.CNRI.Reston.VA.US>
The ATM MIB Working group has been reactiviated in the Network
Management Area of the IETF. For more information, please contact the
working group chairs or the Area Director.
ATM MIB (atommib)
-----------------
Chair(s):
Kaj Tesink <kaj at cc.bellcore.com>
Network Management Area Director(s):
Marshall Rose <mrose.iesg at dbc.mtview.ca.us>
Area Advisor
Keith McCloghrie <kzm at cisco.com>
Mailing lists:
General Discussion:atommib at thumper.bellcore.com
To Subscribe: atommib-request at thumper.bellcore.com
Archive:
Description of Working Group:
The AToM MIB working group is chartered to evaluate RFC 1695, a
proposed standard, with respect to the standards track. As a part
of its evaluation, the WG will prepare a revised version and
recommend a the appropriate level of standardization for this
revision to the IESG (i.e., that it be advanced to draft standard
status, or that it cycle at proposed standard status).
As a part of its evaluation, the AToM MIB Working Group
may also define additional sets of managed objects, to reflect
growing experience and industry requirements for management of:
o ATM SVCs
o the Frame based UNI (F-UNI)
o ATM tests
The objects defined by the working group will be consistent with
the Internet-standard Management framework.
Goals and Milestones:
Done Post an Internet-Draft of the ATM and SONET MIB.
Done Submit the ATM and SONET MIB to the IESG for consideration as a
Proposed Standard.
Mar 95 Begin developing Internet-Drafts for discussion
Jun 95 Revised Internet-Draft and make available for discussion
Oct 95 Submit Internet-Drafts to IESG for standards track evaluation
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06065;
10 Feb 95 13:16 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06061;
10 Feb 95 13:16 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10565;
10 Feb 95 13:16 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA14335 at pad-thai.cam.ov.com>; Fri, 10 Feb 1995 12:21:42 -0500
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA17885; Fri, 10 Feb 95 12:18:39 EST
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4 + 8.6.9, dpg hack 5dec94) with UUCP id JAA06977; Fri, 10 Feb 1995 09:17:03 -0800
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA13081; Fri, 10 Feb 95 09:17:21 -0800
Date: Fri, 10 Feb 95 09:17:21 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9502101717.AA13081 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: John Linn <linn at cam.ov.com>
Subject: Re: fw:A Proposed QOP Structure...
Cc: "carlisle (c.m.) adams" <cadams at bnr.ca>, cat-ietf at mit.edu
Reply-To: dpg at ocsg.com
> >> - MA values are specified at the mechanism level and are
> >> therefore portable across implementations of a mechanism.
> >> For example, all implementations of the Kerberos V5 GSS
> >> mechanism must support
> >>
> >> GSS_KRB5_INTEG_C_QOP_MD5 (value: 1)
> >> GSS_KRB5_INTEG_C_QOP_DES_MD5 (value: 2)
> >> GSS_KRB5_INTEG_C_QOP_DES_MAC (value: 3).
> >
> >
> >I'm confused. This definition appears to conflict with
> >the structure you propose. Shouldn't DES be in the
> >confidentiality field and MD5 and MAC in the integrity
> >field?
>
> These definitions correspond to the integrity choices
> defined in the Kerberos mechanism draft. Choices 2 and 3
> use DES as part of the integrity computation; (2) uses DES
> in conjunction with MD5 and (3) uses DES to compute a MAC.
> All of these are options for how integrity is computed,
> not how confidentiality is provided, so I think
> Carlisle's proposal groups them correctly.
>
You're right. I misunderstood.
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06117;
10 Feb 95 13:21 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06113;
10 Feb 95 13:21 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10707;
10 Feb 95 13:21 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA14338 at pad-thai.cam.ov.com>; Fri, 10 Feb 1995 12:21:54 -0500
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA17923; Fri, 10 Feb 95 12:18:51 EST
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4 + 8.6.9, dpg hack 5dec94) with UUCP id JAA06898; Fri, 10 Feb 1995 09:16:57 -0800
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA13070; Fri, 10 Feb 95 09:13:07 -0800
Date: Fri, 10 Feb 95 09:13:07 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9502101713.AA13070 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: Doug Rosenthal <rosenthal at mcc.com>
Subject: Re: fw:A Proposed QOP Structure...
Cc: cadams at bnr.ca, cat-ietf at mit.edu
Reply-To: dpg at ocsg.com
> Dennis> Your QOP proposal may be a satisfactory solution for
> Dennis> SPKM however as a general solution it has some
> Dennis> problems. I have enclosed comments on your proposal
> Dennis> based on its use as a general solution.
>
> I appreciate your review of the proposal. However, I
> disagree with your assessment above. I think the QOP
> proposal *does* provide a general solution, especially
> given the constraints that Carlisle was attempting to
> satisfy. Namely:
>
I like the proposal but, as it stands, it has some problems
when applied as a general solution. I believe those
"problems" are easily addressed and the proposal
refined. For example, 5 bits to represent a 16 bit value is
a waste of space and limiting but, do we care? My personal
feeling is: I don't think so, at least for the next several
years As for "weak" and "strong", I believe we would be
doing a dis-service to ourselves and the community by
defining them.
[ stuff deleted ]
> Dennis> Some mechanisms may not know what algorithm was used.
> Dennis> For example, a mechanism that uses krb5_rd_priv() to
> Dennis> decode tokens is not returned an ETYPE.
>
> How could a mechanism *not* know what algorithm it used to
> encrypt/decrypt data?
>
Using krb5_rd_priv() as an example, krb5_rd_priv()
indeed knows the algorithm -- it's encoded in the packet
-- but it does not return it. This behavior is not
uncommon.
-dpg
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06588;
10 Feb 95 13:52 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11453;
10 Feb 95 13:52 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06549;
10 Feb 95 13:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06456;
10 Feb 95 13:47 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11292;
10 Feb 95 13:47 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA20520>; Fri, 10 Feb 1995 10:47:39 -0800
Message-Id: <199502101847.AA20520 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1757 on Remote Network Monitoring MIB
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 10 Feb 95 10:48:47 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1757:
Title: Remote Network Monitoring Management Information
Base
Author: S. Waldbusser
Date: February 1995
Mailbox: waldbusser at cmu.edu
Pages: 91
Characters: 208,117
Obsoletes: 1271
URL: ftp://ds.internic.net/rfc/rfc1757.txt
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing remote network
monitoring devices. This RFC is the product of the Remote Network
Monitoring Working Group of the IETF.
This is now a Draft Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <950210104323.RFC at ISI.EDU>
SEND /rfc/rfc1757.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1757.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <950210104323.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07158;
10 Feb 95 14:17 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07154;
10 Feb 95 14:17 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11946;
10 Feb 95 14:17 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <NAA16670 at pad-thai.cam.ov.com>; Fri, 10 Feb 1995 13:28:28 -0500
Received: from [18.172.1.4] by MIT.EDU with SMTP
id AA07941; Fri, 10 Feb 95 13:25:16 EST
Received: by dcl.MIT.EDU (5.0/4.7) id AA03096; Fri, 10 Feb 1995 13:24:42 +0500
Date: Fri, 10 Feb 1995 13:24:42 +0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9502101824.AA03096 at dcl.MIT.EDU>
To: Marc Horowitz <marc at cam.ov.com>
Cc: gw at ironwood.cray.com, cat-ietf at mit.edu, sjogren at tgv.com
In-Reply-To: Marc Horowitz's message of Thu, 09 Feb 1995 15:20:39 -0500,
<9502092020.AA04372 at dun-dun-noodles.cam.ov.com>
Subject: Re: FTP security extensions
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Content-Length: 864
Date: Thu, 09 Feb 1995 15:20:39 -0500
From: Marc Horowitz <marc at cam.ov.com>
I think it would be better to state that that secure proxy ftp
transfers are not covered by this RFC, rather than excluding it
completely. Someone might come up with a clever way to implement
them, and I don't think we should prevent a future RFC from
documenting a suitable mechanism.
No, but we should say that using the mechanism defined in this RFC,
secure proxy ftp transfers aren't possible. Of course, a new mechanism
could be devised, but that doesn't change the truth value of the above
statement.
(It's also not all that hard to fix --- we just have to create a new
subsession key and get it distributed to the appropriate parties. An
extra command, maybe two, sent across the control channel should be all
you need to fix this problem.)
- Ted
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08010;
10 Feb 95 15:01 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12920;
10 Feb 95 15:01 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07973;
10 Feb 95 15:01 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07876;
10 Feb 95 14:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: imap at cac.washington.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-imap-mbox-00.txt
Date: Fri, 10 Feb 95 14:56:39 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502101456.aa07876 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message Access
Protocol Working Group of the IETF.
Title : IMAP4 Internationalized Mailboxes
Author(s) : J. Myers
Filename : draft-ietf-imap-mbox-00.txt
Pages : 3
Date : 02/09/1995
The Internet Message Access Protocol, Version 4 [RFC1730] contains a number
of commands which accept and/or manipulate mailbox names. In the base
IMAP4 protocol, mailbox names may only contain characters in the US-ASCII
character set. This document defines an extension to the IMAP4 protocol
whereby a client and a server may negotiate the use of some other character
set for use in mailbox names.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-imap-mbox-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-imap-mbox-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-imap-mbox-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950209161314.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-imap-mbox-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-imap-mbox-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950209161314.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08147;
10 Feb 95 15:07 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13055;
10 Feb 95 15:07 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08130;
10 Feb 95 15:07 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08074;
10 Feb 95 15:03 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: st at ibminet.awdpa.ibm.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-st2-spec-02.txt, .ps
Date: Fri, 10 Feb 95 15:03:44 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9502101503.aa08074 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Stream Protocol V2
Working Group of the IETF.
Title : Internet Stream Protocol Version 2 (ST2)
Protocol Specification - Version ST2+
Author(s) : L. Delgrossi, L. Berger
Filename : draft-ietf-st2-spec-02.txt, .ps
Pages : 97
Date : 02/09/1995
This memo contains a revised specification of the Internet STream Protocol
Version 2 (ST2). ST2 is an experimental resource reservation protocol
intended to provide end-to-end real-time guarantees over an internet. It
allows its applications to build multi-destination simplex data streams
with a desired quality of service. The revised version of ST2 specified in
this memo is called ST2+.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-st2-spec-02.txt".
Or
"get draft-ietf-st2-spec-02.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-st2-spec-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-st2-spec-02.txt".
Or
"FILE /internet-drafts/draft-ietf-st2-spec-02.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19950210150056.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-st2-spec-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-st2-spec-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950210150056.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08383;
10 Feb 95 15:22 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08379;
10 Feb 95 15:22 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13868;
10 Feb 95 15:22 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA14763 at pad-thai.cam.ov.com>; Fri, 10 Feb 1995 12:33:03 -0500
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA19334; Fri, 10 Feb 95 12:30:03 EST
Received: from krypton.mcc.com (krypton.mcc.com [128.62.30.63]) by turtle.mcc.com (8.6.9/mcc.8.6.9) with SMTP id LAA28688; Fri, 10 Feb 1995 11:27:32 -0600
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA18598; Fri, 10 Feb 95 11:27:30 CST
Date: Fri, 10 Feb 95 11:27:30 CST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9502101727.AA18598 at krypton.mcc.com>
To: dpg at ocsg.com
Cc: cadams at bnr.ca, cat-ietf at mit.edu
In-Reply-To: <9502101713.AA13070 at war04.ocsg.com> (message from Dennis Glatting on Fri, 10 Feb 95 09:13:07 -0800)
Subject: Re: fw:A Proposed QOP Structure...
Dennis> next several years As for "weak" and "strong", I believe
Dennis> we would be doing a dis-service to ourselves and the
Dennis> community by defining them.
Perhaps; I've always thought they were too subjective, but didn't see
any harm in allowing them a (future?) place in the QOP parameter.
Dennis> Using krb5_rd_priv() as an example, krb5_rd_priv() indeed
Dennis> knows the algorithm -- it's encoded in the packet -- but
Dennis> it does not return it. This behavior is not uncommon.
True, but someone implementing a Kerberos V5 version of the *GSSAPI*
could make the necessary changes to make it visible to the GSSAPI
layer.
- Doug
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10099;
10 Feb 95 16:51 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15812;
10 Feb 95 16:51 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10068;
10 Feb 95 16:51 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09985;
10 Feb 95 16:46 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15714;
10 Feb 95 16:46 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09980;
10 Feb 95 16:46 EST
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: mwalnut at CNRI.Reston.VA.US
Reply-To: mwalnut at CNRI.Reston.VA.US
Subject: Stockholm IETF (July 17-21, 1995): Preliminary Announcement
Date: Fri, 10 Feb 95 16:46:44 -0500
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9502101646.aa09980 at IETF.CNRI.Reston.VA.US>
Dear IETF'ers:
STOCKHOLM HOTEL INFO.
====================
The 33rd Internet Engineering Task Force will take place July 17-21, 1995
in Stockholm, Sweden at the Grand Hotel. The Grand Hotel is now accepting
reservations as are the other hotels we are working with in Stockholm.
All of the hotels prefer faxed reservations so we have provided forms to
assist you. Retrieval instructions are provided below.
Please Note: Continental Breakfast is included in each hotel's daily
rate. Because of this and as a cost control measure, we will limit
our morning fare (during registration) to hot and cold beverages.
Afternoon breaks remain unchanged.
IETF REGISTRATION
=================
The IETF Secretariat will NOT be registering folks (this means you:*),
for the STOCKHOLM meeting until AFTER the April meeting concludes.
Please do not "modify" old RSVP forms and send them in. Any "modified"
forms sent prior to the April meeting will, without exception, be deleted.
The standard IETF announcement will be sent when we are ready to register
folks for the July IETF. Registration, when taken, will be US$300
(US$320.00 for late registration).
Thank You,
Megan
FTP:
====
IETF Information is available by anonymous FTP from several sites.
US East Coast Address: ds.internic.net (198.49.45.10)
US West Coast Address: ftp.isi.edu (128.9.0.32)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
cd ietf
ls *0mtg*
(NOTE: 0mtg files are updated once a day. If you do not
find the file you are looking for, it will most likely show up within
24 hours.)
Gopher
========
Information pertaining to the 33rd IETF is available on the Gopher
Server running on IETF.CNRI.RESTON.VA.US (132.151.1.35) under
"Internet Engineering Task Force / IETF Meetings / Stockholm July 1995".
WWW
========
<http:///www.ietf.cnri.reston.va.us/home.html> Click on "meetings"
and then on "Stockholm, Sweden (July 1995)"
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10956;
10 Feb 95 17:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10950;
10 Feb 95 17:52 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16859;
10 Feb 95 17:52 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <OAA19582 at pad-thai.cam.ov.com>; Fri, 10 Feb 1995 14:50:35 -0500
Received: from x400gate.bnr.ca by MIT.EDU with SMTP
id AA10020; Fri, 10 Feb 95 14:47:31 EST
X400-Received:
by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 10 Feb 1995 14:46:49 -0500
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 10 Feb 1995 14:46:23 -0500
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 10 Feb 1995 14:45:00 -0500
Date: Fri, 10 Feb 1995 14:45:00 -0500
X400-Originator: /dd.id=1651623/g=carlisle/i=cm/s=adams/@bnr.ca
X400-Mts-Identifier:
[/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.607:10.01.95.19.46.23]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: fw:A Prop...
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "carlisle (c.m.) adams" <cadams at bnr.ca>
X-Orig-Sender: "carlisle (c.m.) adams" <cadams at bnr.ca>
Message-Id: <"5611 Fri Feb 10 14:46:29 1995"@bnr.ca>
To: rosenthl at mcc.com
Cc: cat-ietf at mit.edu, dpg at ocsg.com
Subject: Re: fw:A Proposed QOP Structure...
Hello,
Not surprisingly, I agree with the traffic I've seen so far which
defends the QOP proposal. Let me just add another couple of comments...
>
> Dennis> Your QOP proposal may be a satisfactory solution for SPKM
> Dennis> however as a general solution it has some problems. I have
> Dennis> enclosed comments on your proposal based on its use as a
> Dennis> general solution.
>
>I appreciate your review of the proposal. However, I disagree with
>your assessment above. I think the QOP proposal *does* provide a
>general solution, especially given the constraints that Carlisle was
>attempting to satisfy.
My entire goal in proposing this QOP structure was for it to be a
general solution which (simultaneously) does not conflict with the
way implementations are currently using the parameter. It was certainly
not intended to be only a "satisfactory solution for SPKM". Therefore,
if there are genuine problems with it, I will be happy to change it.
So far, however, I have not seen genuine problems.
>
> Dennis> TS, U, IA, and MA fields are mutually exclusive. This is a
> Dennis> waste of space and limiting. You are using 16 bits to
> Dennis> represent something in which the worst case value occupies
> Dennis> only five of those bits. Is this good or bad? It's hard to
> Dennis> say but it is an area of concern.
>
>Wrt it being a "waste of space", I believe Carlisle was trying to not
>introduce changes to the current API, i.e. just use the existing QOP
>parameter. Wrt it being "limited", there is actually plenty of room
>for expansion - as you even point out (e.g. 16 bits for current worst
>case of 5 bits). Also, note that the values are integers; i.e. it is
>*not* a bit mask. For example, each IA or MA field can handle up to
>16 values, etc.
>
>So, the fields accommodate qualitative values (TS) as well as specific
>algorithms, including algorigthms which are standard for a mechanism
>(MA) and those which are implementation-specific (IA).
It is certainly true that I did not want to change the current API in
any way, so 32 bits was all I had to work with. To get confidentiality
as well as integrity, I was down to 16 bits each.
It is also true that the fields are mutually exclusive and so from
one point of view may seem limiting. However, ignoring the "default"
value, a given GSS mechanism implementation can support up to 30
confidentiality algorithms (15 defined by the mechanism spec. and 15
totally the implementor's choice) and 30 integrity algorithms. GSS is
also able to define up to 31 qualitative terms for confidentiality and
31 for integrity. If this ends up not being enough in the future,
there are still 3 bits left over for growth (e.g., make MA and IA 5 bits
each and TS 6 bits).
It is not clear to me that more room than this is required in a QOP
parameter. Let's face it, there aren't *that* many good algorithms
out there to choose from...
>
> Dennis> This argument is weak and unrealistic. First, you are
> Dennis> defining strength using measure you acknowledge will
> Dennis> change -- perhaps tomorrow (literally). Second, some
> Dennis> cryptographic algorithms do not use keys measured in bit
> Dennis> length. Code book (word substitution) algorithms are an
> Dennis> example.
>
>Fine; the proposal simply provides a hook for qualitative values.
>Interpretation of those values will be mechanism-dependent. So, while
>the SPKM may use key length as a metric, other mechanisms can use
>something else.
There is quite an important distinction here which needs to be
highlighted. I tried to be very careful to not to talk about key
length, but rather to talk about "effective key length", the
definition of which I gave in the proposal -- "the computational
effort required to break the cipher using the best-known cryptanalytic
attact against that cipher".
Such a metric can be used universally, not just by SPKM. Note that by
this metric, it makes no difference what kind of cipher is used or
what kind of key. Note also that by this metric a code book cipher
must be classified as STRENGTH_WEAK, since such a cipher can always be
broken by a known- or chosen-plaintext attack, so it's "effective key
length" is zero bits.
My intention is to use only qualitative terms which can be defined
quantitatively, in a platform- and environment-independent way, so that
there is no fuzziness about the terms whatsoever (that's why I chose
"weak" and "strong" rather than "fast" and "slow"). The point is that
a given algorithm may move from one QOP definition to another, but the
definitions themselves don't change.
A concrete example may help. The last I heard, the linear cryptanalysis
attack on DES reduced the computational effort to break it to 2**43.
Therefore, the effective key length of DES is 43 bits, not 56. If
this attack is improved slightly so that the effective key length
drops to 40 bits or fewer, then DES should be moved from
STRENGTH_MEDIUM to STRENGTH_WEAK, but those QOP terms remain valid.
Applications are thus isolated from late-breaking results in
cryptanalysis (although, of course, the mechanisms will need to be
updated so that they can map algorithms to the correct QOP terms).
> Dennis> Some mechanisms may not know what algorithm was used. For
> Dennis> example, a mechanism that uses krb5_rd_priv() to decode
> Dennis> tokens is not returned an ETYPE.
>
>How could a mechanism *not* know what algorithm it used to
>encrypt/decrypt data?
>
I agree. If the mechanism cannot determine what algorithm was used to
encrypt or sign the data then no secure communication is possible. The
actual QOP parameter makes no difference in such a case (recall that
QOP is not transmitted from sender to receiver; QOP is always a purely
local parameter).
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01075;
11 Feb 95 7:32 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01069;
11 Feb 95 7:32 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03213;
11 Feb 95 7:32 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01051;
11 Feb 95 7:32 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00999;
11 Feb 95 7:19 EST
Received: from ceres.fokus.gmd.de by CNRI.Reston.VA.US id aa03065;
11 Feb 95 7:19 EST
Received: from ursa.fokus.gmd.de by ceres.fokus.gmd.de with SMTP (PP-ICR1v5);
Sat, 11 Feb 1995 13:19:26 +0100
X-Mailer: exmh version 1.5.3 12/28/94
To: ietf at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Henning Schulzrinne <schulzrinne at fokus.gmd.de>
Subject: RFC listing as BibTeX file
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 11 Feb 95 13:20:16 +0100
X-Orig-Sender: schulzrinne at fokus.gmd.de
Message-ID: <9502110719.aa03065 at CNRI.Reston.VA.US>
As part of my network bibliography (*), I have translated the RFC Index
into
BibTeX, combining it with abstracts of the RFCs where available.
The listing through RFC 1761 is in
ftp://gaia.cs.umass.edu/pub/hgschulz/rfc-1761.bib.gz
Comments appreciated. My comment: When trying to machine process RFCs,
the diversity of formats is somewhat amazing, even among the post-1200
generation...
(*) The network bibliography is at http://www.research.att.com/
----
Henning Schulzrinne email: hgs at fokus.gmd.de
GMD-Fokus phone: +49 30 25499 182
Hardenbergplatz 2 fax: +49 30 25499 202
D-10623 Berlin URL: http://www.fokus.gmd.de/htbin/info/step/hgs
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02285;
11 Feb 95 11:44 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02281;
11 Feb 95 11:44 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06252;
11 Feb 95 11:44 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <LAA19797 at pad-thai.cam.ov.com>; Sat, 11 Feb 1995 11:20:35 -0500
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA23256; Sat, 11 Feb 95 11:17:31 EST
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4 + 8.6.9, dpg hack 5dec94) with UUCP id IAA03903; Sat, 11 Feb 1995 08:16:51 -0800
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA13949; Sat, 11 Feb 95 07:21:21 -0800
Date: Sat, 11 Feb 95 07:21:21 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9502111521.AA13949 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: "carlisle (c.m.) adams" <cadams at bnr.ca>
Subject: Re: fw:A Proposed QOP Structure...
Cc: rosenthl at mcc.com, cat-ietf at mit.edu
Reply-To: dpg at ocsg.com
> Such a metric can be used universally, not just by SPKM.
> Note that by this metric, it makes no difference what kind
> of cipher is used or what kind of key. Note also that by this
> metric a code book cipher must be classified as
> STRENGTH_WEAK, since such a cipher can always be broken
> by a known- or chosen-plaintext attack, so it's
> "effective key length" is zero bits.
>
Not so. Code book cryptography is very strong. The method
of attack you mention is viable only if the cryptanalyst
discovers what book is used.
> My intention is to use only qualitative terms which can be
> defined quantitatively, in a platform- and
> environment-independent way, so that there is no
> fuzziness about the terms whatsoever (that's why I chose
> "weak" and "strong" rather than "fast" and "slow"). The
> point is that a given algorithm may move from one QOP
> definition to another, but the definitions themselves
> don't change.
>
Who will be the authoritative body and maintain the
algorithm-to-QOP assignment?
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03110;
11 Feb 95 15:06 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03104;
11 Feb 95 15:06 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08884;
11 Feb 95 15:06 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03089;
11 Feb 95 15:05 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03046;
11 Feb 95 15:01 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa08811;
11 Feb 95 15:01 EST
Received: from relay4.UU.NET by venera.isi.edu (5.65c/5.61+local-20)
id <AA17525>; Sat, 11 Feb 1995 12:02:20 -0800
Received: from gaia.internex.net by relay4.UU.NET with SMTP
id QQycqy19013; Sat, 11 Feb 1995 15:02:17 -0500
Received: from news.internex.net.noname by gaia.internex.net (5.x/SMI-SVR4)
id AA28883; Sat, 11 Feb 1995 12:02:32 -0800
Received: by news.internex.net.noname (4.1/SMI-4.1)
id AA17496; Sat, 11 Feb 95 12:06:32 PST
To: info-ietf at uunet.uu.net
Path: usenet
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: muzaffer at smixedsignal.com
Newsgroups: info.ietf
Subject: Re: <ad> GUARANTEED CREDIT REPAIR BY LAW FIRM
Date: Sat, 11 Feb 95 11:49:51 PDT
Organization: InterNex Information Services, Inc.
Lines: 14
Message-Id: <NEWTNews.22297.792532312.muzaffer at omer1.smixedsignal.com>
References: <3hcqbr$k7r at panix.com>
Nntp-Posting-Host: omer1.smixedsignal.com
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Newsreader: NEWTNews & Chameleon -- TCP/IP for MS Windows from NetManage
In article <3hcqbr$k7r at panix.com>, <ccapc at cyber.sell.com> writes:
I have been reading this list for a while and then noticed these
guys spamming all over usenet. I think people like these are a
clear and present danger to the liveliness (sp?) of the internet/usenet
and before doing any more work on any thing else, you should think
about what can be done to stop them; IMHO of course
Muzaffer
standard disclaimer
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03693;
11 Feb 95 17:02 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03689;
11 Feb 95 17:02 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10317;
11 Feb 95 17:02 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <QAA27795 at pad-thai.cam.ov.com>; Sat, 11 Feb 1995 16:37:42 -0500
Received: from Sun.COM by MIT.EDU with SMTP
id AA10852; Sat, 11 Feb 95 16:34:36 EST
Received: from Eng.Sun.COM (engmail1.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
id AA19165; Sat, 11 Feb 95 13:34:34 PST
Received: from jurassic.Eng.Sun.COM (camilla.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
id AA19405; Sat, 11 Feb 1995 13:34:31 -0800
Received: from elrond.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id NAA20170; Sat, 11 Feb 1995 13:34:14 -0800
Received: by elrond.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id NAA17384; Sat, 11 Feb 1995 13:34:10 -0800
Date: Sat, 11 Feb 1995 13:34:10 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <199502112134.NAA17384 at elrond.Eng.Sun.COM>
To: marc at cam.ov.com, linn at cam.ov.com
Subject: Re: Kerberos V5 mechanism: tightening statements
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
X-Sun-Charset: US-ASCII
John,
I support the restatement as presented in point 2. I have no opinion on the
other issue.
Dan
> From linn at cam.ov.com Thu Feb 9 11:24:24 1995
> To: Marc Horowitz <marc at cam.ov.com>
> Cc: "John Wray, Digital DPE,
> (508) 486-5210 08-Feb-1995 0959" <wray at tuxedo.enet.dec.com>,
> cat-ietf at MIT.EDU, linn at cam.ov.com
> Subject: Re: Kerberos V5 mechanism: tightening statements
>
> My specific points regarding the Kerberos mechanism I-D:
>
> >(1) A statement that address checks shall be performed against
> >input channel bindings on context establishment, unless the
> >caller passes GSS_C_NO_BINDINGS: i.e., requiring the ability
> >for an implementation to perform the address checking?
>
> >(2) A statement that implementations shall not perform per-message
> >replay or out-of-sequence detection if the caller of
> >GSS_Init_sec_context() passes FALSE to replay_det_req_flag and
> >sequence_req_flag, respectively: i.e, tightening the concept
> >of making provision of these services optional from the current
> >"highly recommended" status to a requirement?
>
> have generated broader discussion than I'd anticipated. I still
> believe that we should revise and advance the I-D, in a manner which
> is consistent with current practice.
>
> Re (1), I'll now propose, seeking consensus:
>
> (1a) a question: should the scope of valid address checking be confined
> (as cited in discussion) to source addresses, or is there also
> feasibility and value in checking caller-provided destination addresses
> in order to catch a misdelivered or misrouted token?
>
> (1b) to reflect that, for this purpose, input of GSS_C_NULL_ADDRTYPE
> for source address-type is equivalent to passing GSS_C_NO_BINDINGS.
>
> (1c) to state a recommendation, but not a strict conformance
> requirement, that mechanism implementations should check non-null
> channel binding address specifiers against received context
> establishment tokens when those tokens bear address restrictions.
>
> I propose that (2) should stand as written, within the current scope
> of the Kerberos V5 mechanism.
>
> Can we converge on this for purposes of the current spec?
>
> --jl
>
>
>
>
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03755;
11 Feb 95 17:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03749;
11 Feb 95 17:08 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10417;
11 Feb 95 17:08 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03730;
11 Feb 95 17:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03703;
11 Feb 95 17:05 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10368;
11 Feb 95 17:05 EST
Received: from relay3.UU.NET by venera.isi.edu (5.65c/5.61+local-20)
id <AA20214>; Sat, 11 Feb 1995 14:05:56 -0800
Received: from Mordor.Stanford.EDU by relay3.UU.NET with SMTP
id QQycrg09276; Sat, 11 Feb 1995 17:06:04 -0500
Received: from [198.120.32.31] (arc-tac1-slip7.nsi.nasa.gov [198.120.32.27]) by Mordor.Stanford.EDU (8.6.9/8.6.6) with SMTP id OAA27715; Sat, 11 Feb 1995 14:05:44 -0800
Message-Id: <v03001502ab62da90f99d at [198.120.32.31]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 11 Feb 1995 14:05:51 -0800
To: muzaffer at smixedsignal.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: <ad> GUARANTEED CREDIT REPAIR BY LAW FIRM
Cc: info-ietf at uunet.uu.net
At 10:49 AM 2/11/95, muzaffer at smixedsignal.com wrote:
>clear and present danger to the liveliness (sp?) of the internet/usenet
>and before doing any more work on any thing else, you should think
>about what can be done to stop them; IMHO of course
There is a simple way to deal with spamming: respond to it.
Respond quietly and politely. Reply to the inidividual who
spammed, indicating that you consider it to be a gross violation of
acceptable behavior on the Internet. Do not copy the mailing list, since
there is no need to burden all of the other recipients with your note.
Howwever, you probably DO want to include a copy of the original
note, so that the offenders will know to which message you are referring.
You also probably want to send to postmaster at the machine from
which the spam occurred, so that those with administrative responsibility
for the system will be aware of the violation.
You probably want to quietly ask those you know who also got the
note to do the same.
The net is very large. If people who receive spamming notes make a
point of responding, the senders will usually get the, ummmmmmm, message.
In fact, they will usually gets lots of them.
And if they don't, the postmaster will.
Curiously, the problem tends to self-correct, after that.
d/
--------------------
Dave Crocker
Brandenburg Consulting +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086 dcrocker at mordor.stanford.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04132;
11 Feb 95 18:02 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04126;
11 Feb 95 18:02 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11174;
11 Feb 95 18:02 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04110;
11 Feb 95 18:02 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04076;
11 Feb 95 18:00 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa11130;
11 Feb 95 18:00 EST
Received: from relay1.UU.NET by venera.isi.edu (5.65c/5.61+local-20)
id <AA21555>; Sat, 11 Feb 1995 15:00:41 -0800
Received: from SEARN.SUNET.SE by relay1.UU.NET with SMTP
id QQycrk08078; Sat, 11 Feb 1995 18:00:35 -0500
Message-Id: <QQycrk08078.199502112300 at relay1.UU.NET>
Received: from SEARN.SUNET.SE by SEARN.SUNET.SE (IBM VM SMTP V2R2)
with BSMTP id 7845; Sat, 11 Feb 95 23:57:14 +0100
Received: from SEARN.SUNET.SE (NJE origin ERIC at SEARN) by SEARN.SUNET.SE (LMail V1.2a/1.8a) with RFC822 id 1325; Sat, 11 Feb 1995 23:57:14 +0100
Date: Sat, 11 Feb 1995 23:29:45 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Eric Thomas <ERIC at searn.sunet.se>
Subject: Re: <ad> GUARANTEED CREDIT REPAIR BY LAW FIRM
To: muzaffer at smixedsignal.com, Dave Crocker <dcrocker at mordor.stanford.edu>
Cc: info-ietf at uunet.uu.net
In-Reply-To: Message of Sat, 11 Feb 1995 14:05:51 -0800 from
ietf-request at IETF.CNRI.Reston.VA.US
On Sat, 11 Feb 1995 14:05:51 -0800 Dave Crocker
<dcrocker at mordor.stanford.edu> said:
>At 10:49 AM 2/11/95, muzaffer at smixedsignal.com wrote:
>
> Respond quietly and politely. Reply to the inidividual who
>spammed, indicating that you consider it to be a gross violation of
>acceptable behavior on the Internet. Do not copy the mailing list, since
>there is no need to burden all of the other recipients with your note.
>
> Howwever, you probably DO want to include a copy of the original
>note, so that the offenders will know to which message you are
>referring.
>
> You also probably want to send to postmaster at the machine from
>which the spam occurred, so that those with administrative
>responsibility for the system will be aware of the violation.
End results:
1. The temporary public provider account opened by the spammer for the
purposes of sending the spam gets flooded with mail, as anticipated.
The spammer, having no plans to read the account in question, which is
going to be closed within the hour anyway, couldn't care less.
2. The postmaster account of the provider in question gets flooded with
mail. The spammer couldn't care less.
So, you have inconvenienced the service provider, who couldn't know what
the account was going to be used for, and you haven't even begun to annoy
the spammer, who followed the instructions in C&S's book about "Making
money on the Information SuperHighway". The large amount of complaints
generated by C&S's spamming, by the way, is a selling point for the book,
some sort of evidence that the Internet is a lawless frontier and it's
high time people fought for their rights. The days of random spamming by
clueless non-technical folks are over. Nowadays this is turning into an
organized industry. You can buy books that tell you exactly what to do to
maximize your coverage, minimize your costs and make sure you can't be
sued. These aren't people who don't know it's not ok, these are people
who're after ultra-cheap advertisement and quite frankly, they couldn't
care less whether it's ok or not as long as the operation results in
increased sales.
There are two possible responses to that which make sense in a global
context. The first is to ignore it completely, and make sure never to buy
anything from that company. This saves bandwidth for everyone and the
spammer doesn't get your business. The second is to call the 800 number
listed in the ad, say that you're very interested, and ask that they send
you a brochure by snail mail (you heard of the ad from a colleague but
don't have e-mail yourself). This is going to cost them money but they
still won't get your business. If everyone did that they'd have to answer
millions of phone calls and send millions of glossies, and they'd only
collect on a relatively small amount of them.
Naturally people should also take steps to prevent spams from happening
in the first place. Providers of shell accounts could place limits on the
amount of mail a single account can send in one day, prohibit telnet to
port 25 using a firewall (you'd use a central mail machine with no user
accounts to actually send/receive mail), and so on. The same limits could
be placed in news servers, the list of things to do is endless. LISTSERV
has already been modified to detect and neutralize mailing list spams.
The last 4 spams were successfully detected by the beta sites and when
the new version is released, the spammers will need to be a lot more
clever to get through to LISTSERV lists. Everyone has to do his part, and
I do think it is important and urgent. Imagine what would happen if there
were 2-3 spams every day, and not one law had been broken... It's only a
matter of time. The "How to make money" books are selling and more will
be printed. The instructions are easy to follow and there is no shortage
of competent hackers who will do it for $200 an hour.
Eric
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05114;
11 Feb 95 20:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05108;
11 Feb 95 20:52 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13362;
11 Feb 95 20:52 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05093;
11 Feb 95 20:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05063;
11 Feb 95 20:48 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa13309;
11 Feb 95 20:48 EST
Received: from relay2.UU.NET by venera.isi.edu (5.65c/5.61+local-20)
id <AA25299>; Sat, 11 Feb 1995 17:49:06 -0800
Received: from Mordor.Stanford.EDU by relay2.UU.NET with SMTP
id QQycrv09740; Sat, 11 Feb 1995 20:49:00 -0500
Received: from [198.120.32.37] (arc-tac1-slip10.nsi.nasa.gov [198.120.32.30]) by Mordor.Stanford.EDU (8.6.9/8.6.6) with SMTP id RAA28235; Sat, 11 Feb 1995 17:48:52 -0800
Message-Id: <v03001503ab630f7629c1 at [198.120.32.37]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 11 Feb 1995 17:48:56 -0800
To: Eric Thomas <ERIC at searn.sunet.se>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: <ad> GUARANTEED CREDIT REPAIR BY LAW FIRM
Cc: muzaffer at smixedsignal.com, info-ietf at uunet.uu.net
At 2:29 PM 2/11/95, Eric Thomas wrote:
>1. The temporary public provider account opened by the spammer for the
> purposes of sending the spam gets flooded with mail, as anticipated.
> The spammer, having no plans to read the account in question, which is
> going to be closed within the hour anyway, couldn't care less.
Well, this is an interesting point. To date, my view has been that
spamming is from ignorance. You observe the possibility of a far more
calcuated stance. Given that the legal system has just re-affirmed the
unacceptability of sending unsolicited advertising over fax phone lines,
one suspects there is a likely extension to the rule brewing...
d/
--------------------
Dave Crocker
Brandenburg Consulting +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086 dcrocker at mordor.stanford.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13910;
12 Feb 95 0:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13904;
12 Feb 95 0:48 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16346;
12 Feb 95 0:48 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13885;
12 Feb 95 0:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13858;
12 Feb 95 0:45 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa16319;
12 Feb 95 0:45 EST
Received: from relay3.UU.NET by venera.isi.edu (5.65c/5.61+local-20)
id <AA29440>; Sat, 11 Feb 1995 21:45:49 -0800
Received: from mailhost1.cac.washington.edu by relay3.UU.NET with SMTP
id QQycsl04899; Sun, 12 Feb 1995 00:46:02 -0500
Received: from tomobiki-cho.cac.washington.edu by mailhost1.cac.washington.edu
(5.65+UW94.10/UW-NDC Revision: 2.32 ) id AA00734;
Sat, 11 Feb 95 21:45:40 -0800
Date: Sat, 11 Feb 1995 21:45:40 -0800 (PST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark Crispin <mrc at cac.washington.edu>
To: Dave Crocker <dcrocker at mordor.stanford.edu>
Cc: Eric Thomas <ERIC at searn.sunet.se>, muzaffer at smixedsignal.com,
info-ietf at uunet.uu.net
Subject: Re: <ad> GUARANTEED CREDIT REPAIR BY LAW FIRM
In-Reply-To: <v03001503ab630f7629c1 at [198.120.32.37]>
Message-Id: <Pine.NXT.3.92.950211200711.9260B-100000 at Tomobiki-Cho.CAC.Washington.EDU>
Organization: Pandamonium Reigns
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 11 Feb 1995, Dave Crocker wrote:
> Well, this is an interesting point. To date, my view has been that
> spamming is from ignorance. You observe the possibility of a far more
> calcuated stance.
This is almost certainly the case with the recent spammers, and
especially those from cyber.sell.com (a.k.a. the Green Card Lawyers).
> Given that the legal system has just re-affirmed the
> unacceptability of sending unsolicited advertising over fax phone lines,
> one suspects there is a likely extension to the rule brewing...
Unfortunately, the legal system is of, by, and for lawyers. So it is
unlikely that it is going to do anything to hurt the business of their
colleagues. I see nothing good coming out of the system system becoming
involved in Internet operations, and a lot of harm.
Unfortunately, certain people seem to be determined to force the issue.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01118;
13 Feb 95 9:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ac01097;
13 Feb 95 9:49 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa01849;
13 Feb 95 5:12 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <EAA18069 at pad-thai.cam.ov.com>; Mon, 13 Feb 1995 04:36:05 -0500
Received: from clbull.frcl.bull.fr by MIT.EDU with SMTP
id AA15768; Mon, 13 Feb 95 04:33:00 EST
Received: from emsc.frcl.bull.fr by clbull.frcl.bull.fr; Mon, 13 Feb 1995 10:31:24 +0100 (MET)
Received: by emsc.frcl.bull.fr (AIX 3.2/UCB 5.64/4.03)
id AA22436; Mon, 13 Feb 1995 10:32:51 +0100
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Denis Pinkas <pinkas at emsc.frcl.bull.fr>
Message-Id: <9502130932.AA22436 at emsc.frcl.bull.fr>
Subject: Re: fw:A Proposed QOP Structure...
To: carlisle <cadams at bnr.ca>
Date: Mon, 13 Feb 1995 10:32:50 +0100 (NFT)
Cc: cat-ietf at mit.edu
In-Reply-To: <"28245.Thu.Feb..9.15:14:44.1995"@bnr.ca>. from "carlisle" at Feb 9, 95 03:13:00 pm
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 2.4
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 5300
February 13, 1995
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
