Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1591C1A041C for ; Mon, 17 Mar 2014 07:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5hXzTU91rS6 for ; Mon, 17 Mar 2014 07:42:23 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id E3F1B1A041B for ; Mon, 17 Mar 2014 07:42:22 -0700 (PDT) Received: from mail11-co9-R.bigfish.com (10.236.132.252) by CO9EHSOBE036.bigfish.com (10.236.130.99) with Microsoft SMTP Server id 14.1.225.22; Mon, 17 Mar 2014 14:42:14 +0000 Received: from mail11-co9 (localhost [127.0.0.1]) by mail11-co9-R.bigfish.com (Postfix) with ESMTP id CA9B03A0359; Mon, 17 Mar 2014 14:42:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz98dI9371Ic85fh4015I1447I14ffIzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzc2hdchz8275ch1d7338h1de098h1033IL1b1984h17326ah8275bh1bc7b9h8275dh18c673h1de097h186068h18602eh1d68deh19bc52i19bc50iz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1a24h1a82h1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h9a9j1155h) Received-SPF: pass (mail11-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(24454002)(51914003)(164054003)(199002)(189002)(53754006)(377454003)(74876001)(85306002)(87266001)(19273905006)(33646001)(81342001)(74316001)(69226001)(17760045001)(74366001)(2656002)(16236675002)(76786001)(54356001)(76482001)(53806001)(76576001)(76796001)(56776001)(83322001)(87936001)(74706001)(81542001)(19300405004)(94316002)(20776003)(65816001)(93516002)(86362001)(80022001)(66066001)(54316002)(59766001)(77982001)(95416001)(93136001)(63696002)(95666003)(85852003)(81816001)(83072002)(74502001)(94946001)(50986001)(49866001)(56816005)(2201001)(92566001)(81686001)(19580405001)(80976001)(19580395003)(90146001)(79102001)(47736001)(47976001)(97186001)(47446002)(15202345003)(31966008)(46102001)(4396001)(97336001)(15975445006)(74662001)(18206015023)(24736002)(16866105001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB040; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:347CF164.A0F6931D.11D1F543.42E7F383.2067D; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail11-co9 (localhost.localdomain [127.0.0.1]) by mail11-co9 (MessageSwitch) id 1395067331781182_5438; Mon, 17 Mar 2014 14:42:11 +0000 (UTC) Received: from CO9EHSMHS015.bigfish.com (unknown [10.236.132.228]) by mail11-co9.bigfish.com (Postfix) with ESMTP id B8444C00C3; Mon, 17 Mar 2014 14:42:11 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS015.bigfish.com (10.236.130.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 17 Mar 2014 14:42:10 +0000 Received: from BLUPR05MB040.namprd05.prod.outlook.com (10.255.210.156) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.423.0; Mon, 17 Mar 2014 14:42:09 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB040.namprd05.prod.outlook.com (10.255.210.156) with Microsoft SMTP Server (TLS) id 15.0.898.11; Mon, 17 Mar 2014 14:42:08 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0898.005; Mon, 17 Mar 2014 14:42:08 +0000 From: John E Drake To: Gert Grammel , "Gabriele Maria Galimberti (ggalimbe)" , Fatai Zhang , Dieter Beller , "RKunze@telekom.de" , "ccamp@ietf.org" Thread-Topic: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Thread-Index: Ac8+yaJXH8vwWfWRQbyQfVfsHVxr9AABaYCAABUjWwAADUUFgAAAg5QAAAndvDAAgP56AAAMmJwAAAG0MCAAC51uIA== Date: Mon, 17 Mar 2014 14:42:07 +0000 Message-ID: <64a07142428748ed9fb480c70ff97d91@BLUPR05MB562.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] x-forefront-prvs: 0153A8321A Content-Type: multipart/related; boundary="_004_64a07142428748ed9fb480c70ff97d91BLUPR05MB562namprd05pro_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/5rgPRvItE3_1efp3q0heQFDXlfY Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 14:42:30 -0000 --_004_64a07142428748ed9fb480c70ff97d91BLUPR05MB562namprd05pro_ Content-Type: multipart/alternative; boundary="_000_64a07142428748ed9fb480c70ff97d91BLUPR05MB562namprd05pro_" --_000_64a07142428748ed9fb480c70ff97d91BLUPR05MB562namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gert, This is a good point. LMP was designed to allow a pair of nodes to manage = the link between them such that both have the same understanding of its cha= racteristics. I think it is either a red herring or a blue whale to contin= ue using the terms UNI/ENNI/INNI in our work as they were not defined by th= e IETF and their definitions are not necessarily aligned with what we want = to do. As another reminder, up until the time it was published, RFC 4208's title w= as 'GMPLS Support for the Overlay Model'. Yours Irrespectively, John From: Gert Grammel Sent: Monday, March 17, 2014 4:39 AM To: Gabriele Maria Galimberti (ggalimbe); Fatai Zhang; John E Drake; Dieter= Beller; RKunze@telekom.de; ccamp@ietf.org Subject: RE: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi Fatai & Gabriele, given the lack of definition for UNI/ENNI/INNI in IETF, we better focus on = protocols in this discussion. As a reminder: LMP is described in RFC4204 a= nd doesn't contain any of the 3 buzzwords just mentioned. Gert From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Gabriele Maria Gal= imberti (ggalimbe) Sent: 17 March 2014 09:14 To: Fatai Zhang; John E Drake; Dieter Beller; RKunze@telekom.de; ccamp@ietf.org Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi Fatai, Black link lies between a DWDM transceiver and a DWDM network (e.g. ROADM). So on UNI for sure. But, if You have Regenerators in the DWDM network the = black link can be on the E-NNI and I-NNI. Regards, Gabriele [http://www.cisco.com/swa/i/logo.gif] Gabriele Galimberti Technical Leader Cisco Photonics Srl Via Philips, 12 20900 - Monza (MI) Italy www.cisco.com/global/IT/ ggalimbe@cisco.com Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049 From: Fatai Zhang > Date: Monday, March 17, 2014 3:12 AM To: John Drake >, Gabriele Ga= limberti >, Dieter Beller >, "= RKunze@telekom.de" >, "ccamp@ietf.org" > Subject: RE: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi John, Thanks, I knew RFC4207 & RFC4209 and LMP is optional and more (~100%) used = in I-NNI context. My concern could be stated in another way more explicitly: Usecases or scenarios are needed to describe where the black link lies, UNI= , E-NNI or I-NNI, and then describe why LMP ext is needed, rather than brin= g out a lot of parameters to be carried in LMP protocol without justificati= on. Best Regards Fatai From: John E Drake [mailto:jdrake@juniper.net] Sent: Friday, March 14, 2014 8:44 PM To: Fatai Zhang; Gabriele Maria Galimberti (ggalimbe); Dieter Beller; RKunz= e@telekom.de; ccamp@ietf.org Subject: RE: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Fatai, LMP already has technology specific extensions for SDH and WDM. Yours Irrespectively, John From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang Sent: Friday, March 14, 2014 12:57 AM To: Gabriele Maria Galimberti (ggalimbe); Dieter Beller; RKunze@telekom.de<= mailto:RKunze@telekom.de>; ccamp@ietf.org Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi Gabriele, I prefer the first option, because CCAMP always follow the *G*MPLS principl= e: generic/generalized->specific. Note that you did not clarify how to justify which parameters can/(can not)= be exchanged. Best Regards Fatai From: Gabriele Maria Galimberti (ggalimbe) [mailto:ggalimbe@cisco.com] Sent: Friday, March 14, 2014 3:42 PM To: Fatai Zhang; Dieter Beller; RKunze@telekom.de= ; ccamp@ietf.org Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi All, Thanks for the comments and suggestion. The first action I would take is update the draft with the explanations req= uested during the ccamp session and in mailing list. I'm not aware of any LMP extensions to support other technologies as Fatai = is asking (apart the recent draft on sson), I think this can be a matter o= f collaboration Discussing also whether to extend the existing draft or propose a new one. I prefer the second option. I'd also note that the LMP is not an extension of the UNI, LMP is a managem= ent protocol to help interface management: Discovery, negotiation, alarm correlation, etc. It can run on interfaces not "served" by UNI e.g. On spans between ROADMS. Regards, Gabriele [http://www.cisco.com/swa/i/logo.gif] Gabriele Galimberti Technical Leader Cisco Photonics Srl Via Philips, 12 20900 - Monza (MI) Italy www.cisco.com/global/IT/ ggalimbe@cisco.com Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049 From: Fatai Zhang > Date: Friday, March 14, 2014 2:22 AM To: Dieter Beller >, "RKunze@telekom.de" >, "ccamp@ietf.org" > Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi Ruediger and other authors, I agree with Dieter's point. Is it really known what information can/should be exchanged and what can/sh= ould not? How to justify? In addition, do you see any draft about LMP ext over UNI for other technolo= gies such as OTN, WSON, SDH, etc. defined in CCAMP? If no, why not make this draft more generic? I would also kindly suggest the authors have a look at the OIF UNI IAs (UNI= 1.0 & UNI 2.0 and their difference) to see if it really makes sense to hav= e LMP ext over UNI. Best Regards Fatai From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller Sent: Thursday, March 13, 2014 11:17 PM To: RKunze@telekom.de; ccamp@ietf.org Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleagues Hi Ruediger, On 13.03.2014 15:36, RKunze@telekom.de wrote: Hi all, Huub and Dieter mentioned during the CAMP session in London that ITU-T Q6 h= as some concerns about additional values in document. Huub mentioned that - I asked a follow-up question regarding the exchange o= f power values (see below). Gabriele mentioned the reason for adding these values and we will update th= e documents with explaining text. During our common meeting with ITU-T at I= ETF 86 Pete Anslow mentioned: Transmit power may be useful, beyond that I = cannot think of anything else you may want to set. If you guys have still concerns lets discuss these points on the list. The question I have is the following: The draft defines LMP protocol messages (sub-objects) to convey the (curren= t?) Output Power at the Ss reference point and the Current Input Power at the Rs reference point from = OXC1 to OLS1 and OXC2 to OLS2, respectively. This is my interpretation. Now, I would like to understand fo= r what purposes these power values are exchanged. My suggestion at the meeting was to add some explanatory text to the draft = describing the application that makes use of these values, i.e., that motivates the definition of these LMP= extensions. Thanks, Dieter Best regards Ruediger _______________________________________________ CCAMP mailing list CCAMP@ietf.org --_000_64a07142428748ed9fb480c70ff97d91BLUPR05MB562namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gert,

 <= /p>

This is a good point.&nbs= p; LMP was designed to allow a pair of nodes to manage the link between the= m such that both have the same understanding of its characteristics.  I think it is either a red herring or a blue whale to continue using the t= erms UNI/ENNI/INNI in our work as they were not defined by the IETF and the= ir definitions are not necessarily aligned with what we want to do.

 <= /p>

As another reminder, up u= ntil the time it was published, RFC 4208’s title was ‘GMPLS Support for the Overlay Model= ’.

 <= /p>

Yours Irrespectively,

 <= /p>

John

 <= /p>

From: Gert Grammel
Sent: Monday, March 17, 2014 4:39 AM
To: Gabriele Maria Galimberti (ggalimbe); Fatai Zhang; John E Drake;= Dieter Beller; RKunze@telekom.de; ccamp@ietf.org
Subject: RE: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleag= ues

 

Hi Fatai & Gabriele,<= o:p>

 <= /p>

given the lack of definit= ion for UNI/ENNI/INNI in IETF, we better focus on protocols in this discuss= ion. As a reminder:  LMP is described in RFC4204 and doesn’t contain any of the 3 buzzwords just mentioned.

 <= /p>

Gert

 <= /p>

 <= /p>

From: CCAMP [= mailto:ccamp-bounces@ietf.org] On Behalf Of Gabriele Maria Galimberti (ggalimbe)
Sent: 17 March 2014 09:14
To: Fatai Zhang; John E Drake; Dieter Beller; RKunze@telekom.de; ccamp@ietf.org=
Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleag= ues

 

Hi Fatai, <= /span>

 

Black link lies between a D= WDM transceiver and a DWDM network (e.g. ROADM).

 

So on UNI for sure.  B= ut, if You have Regenerators in the DWDM network the black link can be on t= he E-NNI and I-NNI.

 

Regards, 

 

Gabriele<= /p>

3D"http://www.c=

 

 

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

 

Via Phili= ps, 12

20900 - Monza (MI)
Italy
w= ww.cisco.com/global/IT/

 

ggalimbe@cisco.com
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049

 

 

 

 

 

 

 

 

 

 

From: Fatai Zhang <zhangfatai@huawei.com>
Date: Monday, March 17, 2014 3:12 AM
To: John Drake <jdrake@juni= per.net>, Gabriele Galimberti <ggalimbe@cisco.com>, Dieter Beller <Dieter.Beller@alcatel-lucent.com>, "RKunze@telekom.de" <= ;RKunze@telekom.de>, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleag= ues

 

=

=

My concern could be stated in another way mo= re explicitly:

 

Usecases or scenarios are needed to describe= where the black link lies, UNI, E-NNI or I-NNI, and then describe why LMP ext is needed, rather than bring out a lot of parameters = to be carried in LMP protocol without justification.  

 

 

 

Best Regards

 

Fatai

=

From: John E Drake [mailto:jdrake@juniper.= net]
Sent: Friday, March 14, 2014 8:44 PM
To: Fatai Zhang; Gabriele Maria Galimberti (ggalimbe); Dieter Beller= ; RKunze@telekom.de; ccamp@ietf.org=
Subject: RE: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleag= ues

 

=

=

=

=

=

From: CCAMP [mailto:ccamp-bounces@ietf= .org] On Behalf Of Fatai Zhang
Sent: Friday, March 14, 2014 12:57 AM
To: Gabriele Maria Galimberti (ggalimbe); Dieter Beller; RKunze@telekom.de; ccamp@ietf.org=
Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleag= ues

 

=

 

Note that you did not clarify how to justify= which parameters can/(can not) be exchanged.

 

 

Best Regards

 

Fatai

=

From: Gabriele Maria Galimberti (ggalimbe) [mailto:ggalimbe@cisco.com]
Sent: Friday, March 14, 2014 3:42 PM
To: Fatai Zhang; Dieter Beller; RKunze@telekom.de; ccamp@ietf.org
Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleag= ues

 

Hi All, =

 =

Thanks for th= e comments and suggestion.

The first act= ion I would take is update the draft with the explanations requested during= the ccamp session and in mailing list.

 =

I'm not aware= of any LMP extensions to support other technologies as Fatai is asking (ap= art the recent draft on sson),  I think this can be a matter of collaboration

Discussing al= so whether to extend the existing draft or propose a new one.

I prefer the = second option.

 =

I'd also note= that the LMP is not an extension of the UNI, LMP is a management protocol = to help interface management:

Discovery, ne= gotiation, alarm correlation, etc.  

It can run on= interfaces not "served" by UNI e.g. On spans between ROADMS.

 =

Regards, = ;<= /span>

 =

Gabriele=

3D"http://www.c=

 

 

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

 

Via Phili= ps, 12

20900 - Monza (MI)
Italy
w= ww.cisco.com/global/IT/

 

ggalimbe@cisco.com
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049

 

 

 

 

 

 

 

 

 

 =

From: Fatai Zhang <zhangfatai@huawei.com>
Date: Friday, March 14, 2014 2:22 AM
To: Dieter Beller <Dieter.Beller@alcatel-lucent.com>, "RKunze@telekom.de" <RKunze@telekom.de>, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleag= ues

 =

=

=

=

In addition, do you see any draft about LMP = ext over UNI for other technologies such as OTN, WSON, SDH, etc. defined in CCAMP?

 

If no, why not make this draft more generic?=

 

I would also kindly suggest the authors have= a look at the OIF UNI IAs (UNI 1.0 & UNI 2.0 and their difference) to see if it really makes sense to have LMP ext over UNI.

 

 

Best Regards

 

Fatai

=

From: CCAMP [mailto:ccamp-bounces@ietf= .org] On Behalf Of Dieter Beller
Sent: Thursday, March 13, 2014 11:17 PM
To: RKunze@telekom.de; ccamp@ietf.org
Subject: Re: [CCAMP] G.698.2 MIB concerns addressed by ITU-T colleag= ues

 

Hi Ruediger,=

On 13.03.= 2014 15:36, RKunze@telekom.de wrote:

Hi all,=

 <= span lang=3D"DE" style=3D"mso-fareast-language:ZH-CN">

Huub and Diete= r mentioned during the CAMP session in London that ITU-T Q6 has some concerns about additional values in document.


Huub mentioned that - I asked a follow-up question regarding the exchange o= f power values (see below).

 <= span lang=3D"DE" style=3D"mso-fareast-language:ZH-CN">

Gabriele menti= oned the reason for adding these values and we will update the documents wi= th explaining text. During our common meeting with ITU-T at IETF  86 Pete Anslow mentioned: Transmit power may be useful, beyo= nd that I cannot think of anything else you may want to set.

 <= span lang=3D"DE" style=3D"mso-fareast-language:ZH-CN">

If you guys ha= ve still concerns lets discuss these points on the list.

The question I have is the following:

The draft defines LMP protocol messages (sub-objects) to convey the (curren= t?) Output Power at the Ss
reference point and the Current Input Power at the Rs reference point from = OXC1 to OLS1 and OXC2 to OLS2,
respectively. This is my interpretation. Now, I would like to understand fo= r what purposes these power values
are exchanged.

My suggestion at the meeting was to add some explanatory text to the draft = describing the application that
makes use of these values, i.e., that motivates the definition of these LMP= extensions.


Thanks,
Dieter

 <= span lang=3D"DE" style=3D"mso-fareast-language:ZH-CN">

Best regards

 <= span lang=3D"DE" style=3D"mso-fareast-language:ZH-CN">

Ruediger<= /p>

 <= span lang=3D"DE" style=3D"mso-fareast-language:ZH-CN">

 <= span lang=3D"DE" style=3D"mso-fareast-language:ZH-CN">

 <= span lang=3D"DE" style=3D"mso-fareast-language:ZH-CN">

 <= span lang=3D"DE" style=3D"mso-fareast-language:ZH-CN"> 



___________________________=
____________________
CCAMP mailing list

CCAMP@ietf.org
--_000_64a07142428748ed9fb480c70ff97d91BLUPR05MB562namprd05pro_-- --_004_64a07142428748ed9fb480c70ff97d91BLUPR05MB562namprd05pro_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=1632; creation-date="Mon, 17 Mar 2014 14:42:07 GMT"; modification-date="Mon, 17 Mar 2014 14:42:07 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAG4AAABJCAIAAABTkIQiAAAGJ0lEQVR4nO2be0xTVxzHv30gcHk5 bRmKyMCJrhDsNi0xzldikE2dZr5mSEnm/poylxi3ZAuOkhhjspANZ0zUhT9GyNwMzoHDSHD4GEGI QGtGAQ10iEyg1a1Cy50tdH9cd7kqRVp+5WHO54/m9HDOl3M+nHvP6W2QeTweMCiQT/YAXhyYSjKY SjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjImQWXLnXvTOt8bE62yxtz2 XfnvNea2aZo/CsoJ/n0lVxsqG5sBLNcsmI75ozDRq1KYp/A6HfNHgW07ZDCVZDCVZARQpa+HkqnW 3lcCpdLXQ8lUa+8HgToM+XoomWrt/SBQq9LXQ8lUa+8HBCqn+wdBqvzxqpzuHwQJ88d7r/yooBhA ZWOz8cSX4x/NtM5n50oymEoymEoyxqty3euvia9jqafKCXS+H4x329m66g3xdSz1VDmBzveD8apc rlnwUji3eP6cMdZT5QQ63w8I7pXexjFi/SgXlE85E5DvKxP9hQThBTUp+aMgm/h/Nmm5c49qIUxK vjcmQeWLCjtXksFUkhHYbeevy5fF8tw1a8g7jqWZ32PwlYCodPN8x5Wrt4qL79fXO81NADhNctL2 bTqDwTM4KFMoANQZDMa8PADa3NxlBw8KlQBsLa2N3x7ruVwldnx5zdoVhlxOrRoxn7daAYSo1Unb t2kPfDojPExs1lVb13Wh3FJRaa+plqujI15dmJC+LvH9XarFiwIxa3qVbp5vOHnK+Mk+aaXT3HS3 PlEHeAAZgCf3useVgK2l9dLuD+011dKOFnPTss8OcFBJ828eOjRk7R1uZu29W5+YMjAgqmy7WFGz f7/w9wAwZO21W3uNNdW3z/2y9puvA7E86VU+5TFsiVbJhUntAIBM9mxHz+Bge0WF2DJOn6WMiATw oLFxBje81hpOnmr4/Au5sx8AgoLCNMlKLsx+o04a1VVbdyljvbRGro4W1DtMxt/2ZmeUlJCvTWKV TqvtdmGh+FZbcDQxPR2AvaPjkd2O/1ffiLgGeHvrLaGs2rhpdX6+cFE7rbbgmVHSfMGjXB2dmpMj zVeGhgJw87z5+yIxNmFPdvL2rQCazpRYTp2Ay+U0N7Wf/kFlMFDOnFxlR1WVw2QUytqCo7p9Hwtl cQmI98QRhhIaEqWeLZRt58uqDXnzVq+ak6abGR8vzf/3TwsABAWl5uQ8ne/xAOjv6bEcPybUJ+zJ Xpv/lTIkBMDM5BR338POou8BWCoqddQqiQ9Dfd3dYjll1y7fhqJQxL79jvjWcvzYtZ07ft28pfmn M9J8t9MJQMlxI+TLZAAc3T1ihSZLL3gEwKlVSZmZCAoCwHfTf/UWwHOlcLn5xNylb264XqvauEms cZiM13buaLtYQZIfUIhVRsTEiOW28nJfu8sUitg03ZZzP2+4XqvNzRXr20vLPIODQr6S4wC4nU5v +cFRUWK560K50BHAo35He2kZXC4AyshIX8f2XIhVqlNTw5ZohXLD4cNtFyucVpvTarO1tHbV1gEQ JzYCHo+b5908LwNi03S63Fxxebr7Hg4NDQn5wa8kAIDL9Wy+m+cBRM6bF6fPEjoa8/JaSs46rbZ/ OjqMhYWdxY+3o+gVb9FOHOTbjmrxooVbNhtNRgAOk/FSxnpBx0BnZ2hc3HtlpR7vm/ig2327tOzu latRi5IA4MF92/myx6OMiJTL5cP55ia4XA6TsUqvn5WWJuZnFBYqQ0JmhIct2f2BsL0AuLZzx83l KwDYb9QJSzI4IVGTpaedOAJxrkzZm32/3SLORNQRGhc33MjL46g+c5O4+YpwmmRNll7c+oX8jpKz cmf/kLV3xPyYlSu1BUfF4630VBuckKg7ciQ2Tefv/LxCr5JTq1bn5/+xdKnl9I/SOUTMj4eXJSlU yuVyzJr91I/i9FlJmZnSmUvz/zaZhDPmEBceMT9e3IjkCsWyvXsiYmKai4qGl3ZU1Jx3NydlZi5Y n0412SdmEdDnlX48SpB2eW6vKfU4gz36JYM9rySDqSSDqSSDqSSDqSSDqSSDqSSDqSSDqSSDqSSD qSSDqSSDqSSDqSSDqSTjP8P5+2z4huMfAAAAAElFTkSuQmCC --_004_64a07142428748ed9fb480c70ff97d91BLUPR05MB562namprd05pro_--